Рекурсивная аббревиатура?

Она самая.

Очередной форк зебры?

Zebra — это слой абстракции в Quagga. Сабж — самостоятельный и тоже весьма популярный проект, полноценный BGP-демон. На мой вкус удобнее Quagga хотя бы тем, что не копирует синтаксис IOS. По производительности они примерно одинаковы, если не изменяет память.

Кстати, а разве в BGP так уж важна производительность? Или имеется в виду не скорость обновления таблиц роутинга, а скорость самой маршрутизации?

ну тащемта когда у вас десяток-два пиров с фулвью (500+ тыс. маршрутов каждый) и с несколько десятков (или сотен) даунстримов которые периодически флапают, производительность таки важна.

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

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

Записи в таблицы устанавливает ядро и делает это очень быстро. А вот вот скорость самой маршрутизации зависит от демона и это требует довольно много вычислений. К счастью, всё не так плохо, CPU в роутере обычно значительно слабее, чем в среднем лаптопе модератора, и всё же как-то справляется с роутингом интернета ;)

Чем именно не готов BIRD? Кроме консерватизма его пользователей, конечно ;)

Важно то, насколько быстро процесс маршрутизации выполнит алгоритм поиска наилучшего пути, среди нескольких пиров объявляющих полную таблицу маршрутизации Интернета, для заполнения RIB, с учётом политики маршрутизации, фильтрации и так далее.

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

Дело в том, что в ней multiprotocol bgp реализовали. Уже хорошо. И деже вроде как реализовали что-то связанное с MPLS.

Как минимум, касающиеся MPLS, - поддержка анонсирования IPv4 и IPv6 VPN и судя по всему самих меток, для этих префиксов.

А почему бы им бы ldpd не реализовать. А не кто не знает, с чем связанно такое активное внимание к mpls? То, что в bird это всё появилась, это уже хорошо. А то я bird чуть в г... не списал после того, как мне не удалось через bird не удалось поднять ipv6 bgp.

Хороший вопрос, RFC 5036: LDP Specification, описывающие Label Distribution Protocol, весьма обширное, с огромным количеством всевозможных вариаций на тему, General или ATM/Frame Relay LSR.

Плюс к тому, BIRD позиционирует себя, как демон Интернет маршрутизации. А LDP же отвечает за распространение соотношения FEC к меткам, тем самым реализуя динамическое создание LSP. К тому же это не единственный возможный для этого протокол. Есть же ещё RSVP-TE и конечно MP-BGP, я само-собой не утверждаю, что они прямые конкуренты друг-другу, скорее хочу сказать, что каждый занял свою нишу.

Вот видимо разработчики BIRD и решили, что MP-BGP это их вариант, без него MPLS L3 VPN будет весьма затруднительно реализовать, как и MPLS L2 Ethernet VPN, не VPLS, последний и с LDP можно построить.

У MPLS есть один огромный плюс, он позволяет строить BGP Free Core, а значит P маршрутизаторы, могут исполнять только какой-то IGP процесс маршрутизации, OSPF или IS-IS, последнее на мой взгляд дело вкуса. Всё, что нужно знать P маршрутизатору, - loopback IP PE маршрутизатора и, как его достичь, через какой next-hop.

А поскольку BIRD используется в среде ISP, то кто-то решил, что не плохо было бы, чтобы его можно было применять и для реализации MPLS Applications. :)

Bird решил быть похожим на frrouting наверное. Самое интересное то, что в интернете есть документация только по настройке bird 1.x. Но, самое интересное то, почему то раньше этого не реализовали. Теперь тем у кого был bird 1.x, придтся заново переписывать конфиг. А это как минимум отсутствие интернета на одни сутки.

отсутствие интернета на одни сутки

С появлением нового BIRD старый никто не отбирает. Можно спокойно переписать конфиг, оттестировать всё и потом уже переключать. Хотя, конечно, разработка и отладка на проде всяко увлекательнее, тут не поспоришь.

BGP Free Core

Мечты уровня районного ISP :) Пацаны из Tier1 просили передать, что MPLS не нужен и даже немножечко вредит.

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

Кстати, linux не поддерживает multicast MPLS (0x8848). От поддерживает только MPLS (0x8847). Ну, правда OVS и VPP(fd.io) его плддерживает.

А почему в dedian до сих пор 1.6.3?

Согласно RFC 5332: MPLS Multicast Encapsulation, Ethertype 0x8847 используется, как для Unicast, так и Multicast MPLS пакетов. Хотя изначально да, планировалось, что для Multicast будет свой собственный Ethertype, но суровая реальность победила ожидания.

Ethertype 0x8848 используется в случае upstream-assigned MPLS labels. Видимо поддержка upstream-label-distribution просто пока не реализована в Linux.

Зато в VPP реализованна.

sed 's/dedian/debian/'

утечки памяти, краши birdc, рестарт всех протоколов при реконфигурации (независимо от изменений настроек протокола), и прочее.

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

А что ставить в продакшен (кроме cisco)

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

Даже если они будут, в Debian они все равно не появятся (или появятся не скоро.)

Теперь демоны bird и bird6 совмещены

Джва года ждал!

А ты что, mpls хотел у себя делать?

пока - 1.6.3. ну или ждать 2.0.1 хотя бы (лучше - 2.0.2-2.0.3).

А если апстрим потребует подключение через MP-BGP? Тогда что?

Rust

Когда они в своём CZ.NIC растишку для себя открют?

вопрос из серии «а если бы у бабушки был х*й»...

а зачем им эта хипстерская поделка, которая не умеет в сколь-либо нормальную кросскомпиляцию (статическую линковку не рассматриваем)?

Поздравляю, гражданин, до лужи взбзднумши.

Кросскомпиляция в cargo искаропки, динамическая линковка как работала, так и работает.

влажные фантазии

MP-BGP это не только MPLS. Это ещё и IPv6 анонсированный через IPv4.

Кросскомпиляция в Rust же.

ну и да, как там у растишки с компиляцией под uclibc? тоже никак? ах да, хипстеры же такой мелочью, как экономия ресурсов, не заморачиваются...

Она под musl собирается, так что все ок.

Кросскомпиляция в Rust же

Очередной бред sd-positive шизофреника, и что?

musl местами довольно корявый.

А что тогда делает mldp в cisco. И с каким MPLS он работает. С 0x8847 или 0x8848?

Multipoint LDP, - расширение LDP протокола, которое позволяет осуществить создание point-to-multipoint и multipoint-to-multipoint LSP, к уже имеющейся возможности создания point-to-point и multipoint-to-point LSP с помощью данного протокола.

Изначально поддержка создания данных, новых типов LSP, была реализована через сигнализацию их в RSVP-TE.

При этом, Ethertype, как и в целом вообще инкапсуляция пакетов, как в MPLS SHIM, так и ATM/Frame Relay, с введением данного расширения не затрагивалась, то есть иными словами правила не изменились.

В отдельном Ethertype для Multicast MPLS нет необходимости. Когда LSR получает пакет с MPLS label, то он обращается к Incoming Label Map, которая отвечает за биндинг входящих label к одному или нескольким Next Hop Label Forwarding Entry. NHLFE содержит исчерпывающую информацию о том, как именно выполняется дальнейшая обработка данного пакета, - работа с метками, адрес следующего перехода, в числе прочего там же может быть указана и какая-то специфичная Layer 2 информация, а так же информация о типе LSP, Unicast/Multicast.

Ссылка на что? На разговоры в курилке о тяжких буднях?

Давай иначе поставим вопрос: какую проблему успешно решает MPLS?

А если не потребует?

Bird 1.6 умеет анонсировать v6 через v4 сессию уже прямо сейчас. Пользуемся в проде, брат жив, зависимости нет.

А ты случайно не путаешь 1.6 и 2.0? Если так говоришь, покажи в действии.

MPLS эффективно решает проблему изоляции, транспорта, соблюдения политик QoS для клиентского L2/L3 трафика через ядро оператора, при этом позволяя строить BGP Free Core.

Вы утверждаете, что это всё не нужно и даже немножко вредно. Изложите свою позицию, раз у вас нет ссылки на позицию инженеров Tier 1 SP, от которых вы передавали привет, если вы сам таковой инженер, то я с радостью послушаю вас.

BIRD supports all requirements of the BGP4 standard as defined in RFC 4271 It also supports the community attributes (RFC 1997), capability negotiation (RFC 5492), MD5 password authentication (RFC 2385), extended communities (RFC 4360), route reflectors (RFC 4456), graceful restart (RFC 4724), multiprotocol extensions (RFC 4760), 4B AS numbers (RFC 4893), and 4B AS numbers in extended communities (RFC 5668).

For IPv6, it uses the standard multiprotocol extensions defined in RFC 4760 and applied to IPv6 according to RFC 2545.

http://bird.network.cz/?get_doc&v=16&f=bird-6.html#ss6.3

BIRD 1.x supported either IPv4 or IPv6 protocol, but had to be compiled separately for each one. BIRD 2 supports both of them with a possibility of further extension. BIRD 2 supports Linux at least 3.16, FreeBSD 10, NetBSD 7.0, and OpenBSD 5.8. Anyway, it will probably work well also on older systems.

http://bird.network.cz/?get_doc&v=20&f=bird-1.html

Однако же, в таком случае забираю свою цитату обратно, она нечего не подтверждает, вы правы.