Ну там, например, тоже не p2mp для type3

Ну там, например, тоже не p2mp для type3

Ну там, например, тоже не p2mp для type3

Можно было и их спросить на этот счёт

кто о чем, а вшивый.. голанг, а9к, евпн, вобщем кони и люди в куче :)

но когда с сетью работаешь, например куда-нить много запросов шлешь или слушаешь наоборот - евентлупы конеш ваще киллерфича

это типа как неблокируемые сокеты и селекты, а просто звучит модно?

ну да, это просто обвязка для облегчения. там сразу указываешь колбеки (которые запускаются в файберах или горутинах, ну или как в вашем языке называется кооперативная многозадачность) плюс есть таймеры типа высокоуровневая фича )

По умолчанию igp shortcut только для хостраутов для резолва некстхопов, да, но это можно исправить

Но это rsvp-related, для ldp можно посмотреть в сторону traffic-engineering вариантов https://www.juniper.net/documentation/en_US/junos/topics/usage-guidelines/mpls-configuring-traffic-engineering-for-lsps.html

@schors всё не успокоится никак.

Холмс, но зачем? а потом обижаются что им сетевого архитектора надо

Он же не спрашивал зачем, спросил как)

Вредные советы

Кто вы, люди

я Бендер Сгибатель

я Бендер Сгибатель

@riddler63 ты зачем усы сбрил?

Ещё немного про EVPN: в прошлый раз я вскользь упомянул проблему неэффективности выбора DF, рассказав, что существуют черновики стандартов, нацеленные на её исправление. Но пока умнейшие мира сего совещаются, Juniper реализовал достаточно простое «решение», которое позволяет описывать ES на уровне логического, а не физического, интерфейса. То есть, например, если раньше для instance типа virtual-switch (VLAN-bundle в терминах RFC 7432) в качестве DF выбирался один PE для всех принадлежащих этому instance VLAN, то теперь, распределив эти VLAN между логическими интерфейсами, можно получить несколько DF на разных PE для пары ES/virtual-switch. Такой трюк позволяет передавать BUM-трафик в рамках ES более «равномерно», платой за что будет выделение дополнительных логических интерфейсов (элегантным такое «решение» точно не назовёшь). На практике это реализуется простым увеличением количества маршрутов типов 1 и 4 (словно у вас много различных физических ES), что в общей массе маршрутов типа 2 скорее всего будет не так и значимо, чтобы создать видимые проблемы со скейлингом. Интересует другое. Помимо вопросов по взаимодействию с другими вендорами (которые, возможно, подтянутся), в RFC 7432 указаны различные типы ESI и способы их генерации (пункт 5). Например, для ESI типов 1 и 2 значение генерируется автоматически на основе данных протоколов LACP и MSTP, и будет одинаковое для всех логических интерфейсов. Не думаю, что вообще где-либо используется автоматическая генерация ESI, но всё таки это создаёт определённое противоречие с действующим стандартом. С другой стороны, всегда можно пойти дальше и отгрузить в оставшийся октет ESI, например, номер логического интерфейса, но это уже совершенно другая история. P.S. Проверяя работу «логических» ES на vMX 17.2R1.13, заметил, что Juniper наконец-то реализовали выделение split-horizon метки для single-active сегментов, идут в ногу со стандартом :)

@blademd фу тебе за "возможно, подтянутся"

@gngbng а мне не подскажешь?

@SergeyF а есть драфт ? я не нагуглил

evpn virtual segment

а кто подскажет по VPLS я правильно понимаю, что VPLS работает по такому же принципу как и вланы и если я сделаю топологию как на картинке это будет петля? и что мне лучше делать с PE pw в сторону BRAS а на BRAS уже через H-VPLS с mesh-group (в моем случае BRAS - это МХ)

@gngbng

Год уже как работает :)

а кто подскажет по VPLS я правильно понимаю, что VPLS работает по такому же принципу как и вланы и если я сделаю топологию как на картинке это будет петля? и что мне лучше делать с PE pw в сторону BRAS а на BRAS уже через H-VPLS с mesh-group (в моем случае BRAS - это МХ)

Если у тебя bgp ad, то отработает split horizont

ldp :(