Дума о BGP
Давным-давно в беседе на IRC с одним коллегой из циски я сказал, что BGP - давно уже не только и не столько routing protocol, собеседник помялся-помялся, но согласился. Сейчас вот мне эта беседа чего-то вспомнилась и я решил написать немного подробней.
Почему же BGP не только routing protocol. Дело в том, что этот замечательный протокол давно уже приспособили для переноса очень разной информации (я как-то упоминал отличный Google Tech Talk с Яковом Рехтером - он там про это немного говорит). Действительно: QoS Policy Propagation, BGP-based VPLS, autodiscovery всех типов, you name it. То, что нынче ездит по BGP, с трудом можно назвать "маршрутом". Т.е. в современной сети BGP (iBGP, если быть точным, с eBGP есть ) - это не просто способ донести какие-то маршруты отсюда досюда, а универсальная инфраструктура для распространения практически произвольной информации в сети.
Рехтер утверждает, что BGP делает это эффективно. Я почти согласен. BGP, как инфраструктура распространения произвольной информации, очень хорош: можно переносить практически все что угодно, ограничений на количество переносимой информации практически не существует (важна частота изменений, но не само количество), можно всячески фильтровать, кто хочет, тот эту информацию слушает и хранит, а кому какая-то не информация не нужна - так не слушает и не хранит. Все здорово. Почти.
Я могу назвать лишь только одну проблему, но эта проблема меня часто выводит из себя.
Дело вот в чем. Когда появляется очередное приложение BGP, разработчики протокола берут AFI/SAFI, изобретают NLRI с какой-то структурой, возможно придумывают еще один-два extended community со специальной семантикой - и вперед.
Естественно, для того, чтобы новый address family заработал, надо, чтобы его понимали оба BGP пира - ведь если один не понимает этот AF, то эта информация ему и не нужна. Казалось бы, логично. Но нет. Есть исключение - route reflectors. Им на самом деле пофигу на address family, их роль проста - принять анонсы, прогнать BGP decision process и раздать анонс, а что внутри, им по барабану. В нынешней схеме для поддержки новой address family приходится апгрейдить и конфигурить route reflector'ы - во-первых лишняя, а во-вторых рискованная работа: баги, недосып, похмелье, кривые руки.
Что бы спасло положение? Wildcard address family capability. Все просто: отдельный AFI/SAFI для использования в capability advertisement и небольшое дополнение к decision process, типа просто пояснение о том, как его делать на неизвестном типе NLRI.
Написать драфт, что ли?
Почему же BGP не только routing protocol. Дело в том, что этот замечательный протокол давно уже приспособили для переноса очень разной информации (я как-то упоминал отличный Google Tech Talk с Яковом Рехтером - он там про это немного говорит). Действительно: QoS Policy Propagation, BGP-based VPLS, autodiscovery всех типов, you name it. То, что нынче ездит по BGP, с трудом можно назвать "маршрутом". Т.е. в современной сети BGP (iBGP, если быть точным, с eBGP есть ) - это не просто способ донести какие-то маршруты отсюда досюда, а универсальная инфраструктура для распространения практически произвольной информации в сети.
Рехтер утверждает, что BGP делает это эффективно. Я почти согласен. BGP, как инфраструктура распространения произвольной информации, очень хорош: можно переносить практически все что угодно, ограничений на количество переносимой информации практически не существует (важна частота изменений, но не само количество), можно всячески фильтровать, кто хочет, тот эту информацию слушает и хранит, а кому какая-то не информация не нужна - так не слушает и не хранит. Все здорово. Почти.
Я могу назвать лишь только одну проблему, но эта проблема меня часто выводит из себя.
Дело вот в чем. Когда появляется очередное приложение BGP, разработчики протокола берут AFI/SAFI, изобретают NLRI с какой-то структурой, возможно придумывают еще один-два extended community со специальной семантикой - и вперед.
Естественно, для того, чтобы новый address family заработал, надо, чтобы его понимали оба BGP пира - ведь если один не понимает этот AF, то эта информация ему и не нужна. Казалось бы, логично. Но нет. Есть исключение - route reflectors. Им на самом деле пофигу на address family, их роль проста - принять анонсы, прогнать BGP decision process и раздать анонс, а что внутри, им по барабану. В нынешней схеме для поддержки новой address family приходится апгрейдить и конфигурить route reflector'ы - во-первых лишняя, а во-вторых рискованная работа: баги, недосып, похмелье, кривые руки.
Что бы спасло положение? Wildcard address family capability. Все просто: отдельный AFI/SAFI для использования в capability advertisement и небольшое дополнение к decision process, типа просто пояснение о том, как его делать на неизвестном типе NLRI.
Написать драфт, что ли?
0 TrackBacks
Listed below are links to blogs that reference this entry: Дума о BGP.
TrackBack URL for this entry: http://net-geek.org/cgi-bin/mt/mt-tb.cgi/250
меня всегда (слегка) напрягало, что в BGP переплетены функции сигнализации (чего угодно) и распределения топологической информации/вычисления маршрутов.
Вробе бы семантически связь (между сигнальной и топологической информацией) почти всегда есть, но то, что вся дистрибуция сигнальной информации (броадкастная по своей природе) прикреплена к фиксированному best-path selection process (который вроде имеет отношение только к маршрутизации,) несколько затрудняет восприятие.
В общем яркий пример инженерного решения - раз эта хрень хорошо работает, то давайте к ней прикрутим еще кучу другого добра :) Получается в итоге совсем неплохо (обычно), но каши в голове прибавляет :)
Инженерное решение и есть. Рехтер на этом особо заостряет внимание.
А best path selection - это ключевая фича. Без этого информации было бы слишком много.
Нравиццо мне вот читать таких пацанофф.
Помимо прочего, узнаю не столько самой информации, сколько источников ее получения. Ну вот откуда фрателло узнал о наличии "отличный Google Tech Talk с Яковом Рехтером", и уж тем более сам спитч надыбал? Постоянно какие-то прикольные презенташки и ссылки на них тут побликуются. Ну ладно, понятно, подписался на ИЕТФ, но там нихуя такого похожего даже нельзя встретить. На ИЕЕЕ ровно как и на ИТУК походу у пацанофф денег нет ровно как и у меня. Вот и сижу в недоумении, откудова у челов столько инфы? В каких мэйл-листах они состоят? Как влиться в подобную тусу. только на серьезе? А то дико не хватает информации.... Был бы признателен.
Ну, про существование гуглевых tech talks я просто знал от гуглеров. Соответсвенно, поискать в них чего-нибудь интересное - это автоматическая реакция. Вот и нарылось.
А вообще, я читаю дофига чего. NANOG mailing list, cisco-nsp, juniper-nsp, избранные IETF'овские рассылки, около IETF'овские - RRG, например. Фиды с IETF: New RFCs и New Current Internet Drafts. Слежу за конференциями, хоть и не езжу, но стараюсь просматривать материалы NANOG'а, Cisco Networkers, MPLS conference и других. Light reading проглядываю по возможности. Очень много подкидывают коллеги. Это очень важно, обсуждать с коллегами прочитанное - среди коллег на работе, коллег в компаниях-клиентах, коллег в вендорах, корреспондентов по онлайн и оффлайн профессиональному общению много очень умных и знающих людей, которые всегда подкинут мысль, статью, ключевое слово для поиска. Ну и главный секрет - это, когда что-нибудь читаешь, заглядывать в список литературы в конце, там можно найти много чего интересного. Ну и если что-то заинтересовало, обязательно погуглить, что на эту тему писалось-говорилось.
Вот кстати мыслишко не много не в тему но про БГП и про капабилити...
Тут высказалась версия, подтверждение которой хотелось бы услыхать.
Версия следующая: в новых ИОСах "СРВ" цисковские 7-тонники когда пирятся друг с другом по БГП открывают более чем одну адресс-фамили. Зафиксированно что открывают две (сперва одну, а потом после обмена капабилитями вторую), якобы одну на адрес-фамили мультикастную, одну на все остальные. Кто-нить может дать сцылку где это может быть написанно? При пиринге с устройствами не поддерживающими такие дабл-коннеты якобы капабилити все показывают и соединение так и остается одно. Подтверждения этому в ИЕТФе тоже не нашел...
Не совсем понял. Про какие дабл-коннеты речь? Две BGP-сессии между парой устройств? Хочу видеть tcpdump такого обмена - лучше всего tcpdump -s0 -w somefile.pcap.
Да да, именно 2 БГП сесии между парой устройств.
дамп хотел бы и сам посмотреть... По ответу понял, что никто тоже не в курсе данной ахинеи, что увеличивает вероятность лживости утверждения.
Ну на самом деле, попытки специфицировать такое были. Причем относительно недавно. Можно покопаться и найти драфт. Но в то, что циска это реализовала вот так вот втихую, я верю слабо. Поэтому очень хочу видеть свидетельство. А откуда слушок пошел?
А можно сцылко на драфт...? Потому что я как-то не сумел найти.
Слушок пошол от продакшен сетки, в которой это наблюдаеццо. Кастомер даже сказал что где-то на сайте циско или типа того видел подобную инфу; я че-то опять-таки не нашел.
В обмен на tcpdump. Шучу :)
Multisession BGP
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122sr/newft/122srb33/srbgpmtr.htm
Если я не ошибаюсь, то вот эта годовалая фитча как раз использует в том числе и вышеупомянутый драфт.
Да, похоже на то.