Давным-давно в беседе на 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.
Написать драфт, что ли?
меня всегда (слегка) напрягало, что в BGP переплетены функции сигнализации (чего угодно) и распределения топологической информации/вычисления маршрутов.
Вробе бы семантически связь (между сигнальной и топологической информацией) почти всегда есть, но то, что вся дистрибуция сигнальной информации (броадкастная по своей природе) прикреплена к фиксированному best-path selection process (который вроде имеет отношение только к маршрутизации,) несколько затрудняет восприятие.
В общем яркий пример инженерного решения - раз эта хрень хорошо работает, то давайте к ней прикрутим еще кучу другого добра :) Получается в итоге совсем неплохо (обычно), но каши в голове прибавляет :)
Нравиццо мне вот читать таких пацанофф.
Помимо прочего, узнаю не столько самой информации, сколько источников ее получения. Ну вот откуда фрателло узнал о наличии "отличный 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 проглядываю по возможности. Очень много подкидывают коллеги. Это очень важно, обсуждать с коллегами прочитанное - среди коллег на работе, коллег в компаниях-клиентах, коллег в вендорах, корреспондентов по онлайн и оффлайн профессиональному общению много очень умных и знающих людей, которые всегда подкинут мысль, статью, ключевое слово для поиска. Ну и главный секрет - это, когда что-нибудь читаешь, заглядывать в список литературы в конце, там можно найти много чего интересного. Ну и если что-то заинтересовало, обязательно погуглить, что на эту тему писалось-говорилось.
Инженерное решение и есть. Рехтер на этом особо заостряет внимание.
А best path selection - это ключевая фича. Без этого информации было бы слишком много.
Вот кстати мыслишко не много не в тему но про БГП и про капабилити...
Тут высказалась версия, подтверждение которой хотелось бы услыхать.
Версия следующая: в новых ИОСах "СРВ" цисковские 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
Если я не ошибаюсь, то вот эта годовалая фитча как раз использует в том числе и вышеупомянутый драфт.
Да, похоже на то.