Bgp - протокол маршрутизации между as. Path-vector protocol.Ibgp - соседство внутри as. Соседство строится как правило, на lo адресах.Ebgp - соседство между разными as. Соседство построено на p2p адресах.Поддерживает аутентификацию: md5. Необходимо настроить key-chain, с указанием когда каков ключик использовать. Аутентификация применяется на множестве уровнях protocols bgp.1 состояния соседства 1.1 tips4.1 local preference4.2 autonomous system path 4.2.1 операторы регулярных выражений4.3.1 next-hop resolution4.7.1 no-export (0xffffff01)4.7.2 no-advertise (0xffffff02)4.7.3 no-export-subconfed (0xffffff03)4.7.4 примеры4.7.5 список операторов регулярных выражений для community4.7.6 действия с community4.8.1 возможные манипуляции с med5.1 входящим5.2 исходящим7.1 link bandwidth extended community9.1 option 1: remove-private9.2 option 2: local-as9.3 as-override9.4 loops11.1 распространение маршрутов при помощи rr11.2 configuration11.3 hierarchical route reflection11.4 modifying attributes on the rr12.1 configuration14.1 as-path segment14.2 configuration15.1 configСостояния соседстваhttp://habrastorage.Org/getpro/habr/post_images/442/780/549/442780549c2f45cdda10773121b2800d.PngДля установления соседства используется tcp:179.Idle: all incoming connections - refused. Инициализация bgp ресурсов и подготовление к установлению tcp. Если роутер завис в силах idle - уточнить наличие маршрута к соседу.Connect: процесс установления tcp сессии. Роутер слушает tcp 179. Если сессия установилась, то роутер отправляет open message и переходит в opensent состояние. Если tcp не установилась, то роутер перейдет в active больного и запускает заново connectretrytimer.Active: local router становится активным инициатором tcp-сессии. В состоянии active - когда ответил на прилетевший tcp. Если роутер завис в active, проверяем: связность, просиживание на подготовительных курсов tcp:179, корректность настройки bgp с двух боков.Opensent: open отправлен локальным роутером и роутер ждет ответа (open) от соседа.Openconfirm: open сообщение получено от соседа и роутер ждет keepalive или notification message. Если от соседа не приходит keepalive до истечения hold timer, то роутер генерирует notification message, с инфо, что hold timer expired и переведет сессию в idle. Если keepalive получен, то соседство перейдет в established state.Established: bgp сессия установлена, пиры начинают обмениваться сообщениями, используя: update, keepalive, notification сообщений.Hold timer бывает разным у пиров. При установлении сессии будет избран наименьший.TipsЕсли сессия установилась в established, но через несколько дней перешла в idle по hold timer expared (пожалуй через 90sec = 3*keepalive), то прежде всего проверьте mtu на канале между роутерами.Если mtu как-то по маршруту зарезан/не соответствует mtu на интерфейсах bgp-пиров, можно либо решить вопрос с mtu на найденном проблемном участке или можно установить для сессии вручную размер mss (maximum segment size):Признаки такой болезни в логах:СообщенияВсе сообщения имеют headerBgp header содержит:Marker - 16 октетов, установлены в 1". Значит, что это bgp-пакетlenght - размер пакета (16bit)type - тип сообщения - 1 - open- 2 - update- 3 - notification- 4 - keepalive- 5 - route-refresh Типы пакетов:Open (type 1) - отправляется отдельно на этапе установления соседства. Содержит параметры bgp соседа: as, auth-type ( ключ, если есть аутентификация).Update (type 2) - передает info о добавлении или удалении маршрутов между соседями. Update включает в себя path, его атрибуты и вложенные префиксы, у которых эти атрибуты одинаковые. Не отправляются по таймеру, приходят, только когда стал иным сам префикс, его атрибуты или bgp-сессия. Исходя из policy, на локальном роутере, часть routing info может быть отброшена и помещена в hidden.Notification (type 3) - и, если что-то пошло абсолютно не так: провалил keepalive или update, пришла не поддерживаемая опция, ... Существуют стандартизированные коды ошибок (operation code opcode). Пакет в него входят header opcode subcode data (описание ошибки - для мониторинга).Keepalive (type 4)- в целях подтверждения, что с соседством все ok. Отправляется каждые 30 sec. По дефолту hold-timer = 3 * keepalive = 90sec - временной промежуток после которого соседи рушат соседство (ежели в этот период не прошло ни единого keepalive). Реально выставить holdtimer = 0. В том случае, если у одного соседа = 0, у другого ответ отрицательный, то станет согласовано ненулевое значение holdtimer для сессии.Keepalive message = bgp header без payloadRefresh - soft clearing bgp сессии.Bgp operationsBgp хранит маршруты в 3-х местах:- Adjacency-rib-in: все полученные маршруты от пиров- rib-local: маршруты локального роутера, предназначенные для передачи трафика. Тут хранятся только активные маршруты.- Adjacency-rib-out: маршруты, что станут отправляться пирам. Передаваться могут только активные маршруты. (Advertise-inactive исправляет данную ситуацию).Передача маршрутов идет правильное (дабы исключить routing loops):1. Ibgp пиры передают маршруты, полученные от ebgp другим ibgp пирам.2. Ebgp пиры передают маршруты, полученные от ebgp и ibgp другим ebgp пирам3. Ibgp пиры не передают маршруты, полученные от прочих ibgp пиров. Поэтому затем чтобы получить какую угодно маршрутную информацию, требуется full-mesh связность. Либо использование rr.По умолчанию ibgp пиры не меняют next-hop для маршрутов, предоставляемых ebgp.Решается:- Настройкой next-hop self в рамках export policy к remote pe/rr.- Добавить p2p интерфейс с ebgp пиром в igp как passive.- Анонс p2p инфекции по igp. Export policy для igp протокола.- Настройки статического маршрута на любом из ibgp до удаленного ebgp пира.- Настроить igp соседство с ebgp пиром.Атрибуты (bgp attributes)Включаются в update сообщения и описывают bgp префиксы. Атрибуты нужны без оплаты активного пути.Атрибуты пути подразделяются на 4 категории:Well-known mandatory - все маршрутизаторы, работающие по протоколу bgp, должны распознавать эти атрибуты. Должны присутствовать здесь обновлениях (update).Well-known discretionary - все маршрутизаторы, работающие по протоколу bgp, должны распознавать эти атрибуты. Могут присутствовать в обновлениях (update), но их присутствие не принципиально.Optional transitive - могут не распознаваться всеми реализациями bgp. Если маршрутизатор не распознал атрибут, он помечает обновление как частичное (partial) и отправляет его дальше соседям, сохраняя не распознанный атрибут.Optional non-transitive - в состоянии не распознаваться всеми реализациями bgp. Если маршрутизатор не распознал атрибут, то атрибут игнорируется а также передаче соседям отбрасывается.Local preference- Указывает маршрутизаторам внутри автономной системы как выйти за её пределы.- Больший приоритет выигрывает.- Этот атрибут передается исключительно в пределах одной автономной системы => работает лишь только для ibgp.- На маршрутизаторах cisco и juniper по умолчанию значение атрибута - 100.- Если ebgp-сосед получает обновление с выставленным значением local preference, он игнорирует этот атрибут.- В junos lpf можно задать через policy и в protocol bgp. Если задан и так, и так, то собрался назначен lpf из policy.- Чаще всего используется на бордерах.Когда в интернете есть 2 бордера, которые были произведены только один и тот же маршрут извне, и бордеры навешивают одинаковый повышенный lpf через export policy, в таком случае соседи ibgp получат маршрут с измененным lpf, но трафик не сможет по правильному ссылке разрешить as. По той причине что бордеры тоже одна от другой будут получить маршрут с особым lpf. Решение: правильно менять lpf через import policy.Autonomous system path- Описывает через какие автономные системы следует преодолеть, дабы дойти до сети назначения.- Номер as добавляется при получении обновления из одной as ebgp-соседу в требуемый as.Используется для:- Обнаружения петель- воздействие на path selection с помощью prepending (делается через export policy)обозначение:- - Local as- - as sets - группы as, порядок не ограничено значение. Появляется при агрегировании маршрутов.- () - Confederation- () - confederation setsкаждый сегмент атрибута as path сделан в форме поля tlv (path segment type, path segment length, path segment value):Path segment type - поле размером 1 байт и здесь определены такие значения: - 1 - as_set: неупорядоченное множество изолированных систем, через которые прошел маршрут в сообщении update,- 2 - as_sequence: упорядоченное множество автономных систем, через которые прошел маршрут в сообщении updateОператоры регулярных выражений. - Любой знак (одна точка - один любой знак, 3 точки - три любых символа).Next-hop- Это айпи ebgp-маршрутизатора, через который ведется путь к интернету назначения.- Атрибут меняется при передаче префикса в другую as (по умолчанию подставляется айпи bgp-соседа)- атрибут не меняется при передаче префикса в технических условиях же asnext-hop resolutionNext-hop selfexport direct into igp: проанонсировать p2p интернет с ebgp peer, который прислал префикс.Igp passive interface: интерфейс в сторонку ebgp соседа.Static routes: сразу же образуется проблема, с тем, что надо: на любом из ibgp роутерах прописывать такой путь. Эффективнее установить другой способ.Igp adjacency on inter-as links to ebgp peers: тоже неподходящий вариант. Опсано и зачем тогде вообще разные as. Лучше выбрать еще один способ.Можно изменить с помощью policy на выходе (export к ibgp):Или таки, около двери (import от ebgp peer):OriginАтрибут origin - указывает на то, равно как был получен маршрут в обновлении. Меняется при помощи policy.Atomic aggregateAggregatorCommunities- Тегирование маршрутов- существуют предопределенные значения (famous), которые не придется определять локально на вашем оборудовании- в автоматическом режиме не пересылаются соседям- одному маршруту может быть присвоено несколько communities- community могут быть критерием в policy для изменения иных атрибутов bgp, например lpf.- Один из предложений применения: передается соседней as для координирования входящим трафикомзначения от 0x00000000 до 0x0000ffff и от 0xffff0000 до 0xffffffff зарезервированы.Как правило community отображаются в формате asn:value. В конкретном формате, доступны для использования community от одного:0 до 65534:65535. В первой части указывается номер автономной системы, а во второй значение community, которое определяет политику маршрутизации трафика.Некоторые значения communities предопределены. Rfc1997 определяет три значения таких community. Эти значения должны одинаково распознаваться и обрабатываться всеми реализациями bgp, которые распознают атрибут community.Если маршрутизатор получает маршрут, в котором указано предопределенное значение communities, то он выполняет специфическое, предопределенное действие основанное на значении атрибута.Предопределенные значения communities (well-known communities):No-export (0xffffff01)Все маршруты которые передаются с настоящим значением атрибута community не можете анонсироваться за границы as. Иначе говоря, маршруты не анонсируются ebgp-соседям, но анонсируются внешним соседям в конфедерации.Пример использованияAs1 подключена к as2 двумя линками (multinoming). As1 анонсирует 172.17.0/16 в as2. Для комфортной маршрутизации, as1 хочет посылать некоторые более специфичные маршруты через один из проверенных линков, но остальному интернету вовсе не обязательно получать эти специфики. Для этого as1 использует community no-export, и посылает 172.17.0/17 в какой-нибудь из стыков с as2, и 172.17.128/17 во второй стык. As2 видит эти рейсы и выбирает их как довольно специфичные. Ещё, подобные рейсы видят все ibgp-соседи подле as2. Но, за границы as2 в виртуальном анонсируется только 172.17.0/16.As customer имеет 2 isp (as1, as2). As1 - основной. Если as customer хочет заработать коннект с всемирная паутина только посредством as1, даже то, в сторонку as2 достаточно просто посылать маршруты с no-export. И в тот же момент к тому же, при падении as1, as customer будет доступна только локальным пользователям as2, но не всему инету.No-advertise (0xffffff02)Все маршруты которые передаются с данным значением атрибута community не должны анонсироваться другим bgp-соседям.No-export-subconfed (0xffffff03)Все маршруты которые передаются с таким значением атрибута community не можете анонсироваться внешним bgp-соседям (ни внешним для конфедерации, ни настоящим внешним соседям). В cisco это значение распространена и под названием local-as.Маршрутизаторы, которые не поддерживают атрибут community, будут передавать его далее, ведь это transitive атрибут.С communities широко применяются регулярные выражения.Примеры100:* - all posible community values with as 100.11.1:666 - 1101:666, 1111:666, 1121:666, etc.Список операторов регулярных выражений для communityДействия с community- Add - включает в текущим community префикса указанное community- delete - удаляет только указанное community- set - заменяет существующие community на указанноеmulti exit discriminator (med)- Актуален для информирования ebgp-соседей о том, какой путь в автономную по более предпочтительный.- Атрибут передается между автономными системами, но, в junos передается только ebgp пиру и не распространяется далее по as.- Маршрутизаторы внутри соседней автономной системы предлагают такой атрибут, но все же после того как обновление покидает пределы as, атрибут med отбрасывается.- Чем меньше значение атрибута, тем более предпочтительна точка входа в автономную по.- Зависимо от названия - применяется лишь в тех случаях, когда между as имеется ряд линков.- Можно использовать для балансировки.Сравнение med (при прочих равных) происходит, ежели один и тот же префикс приходит от единственной as.Если будет анонс этого префикса с более низким med, но из другой as, то он не окажется быть расценены как вероятный альтернатива для майнинга.Это дефолтное поведение, которое можно изменить с помощью:Always-compare-med: при этом не получит значение разные as или одна, просто активным станет маршрут с максимально низким med.Cisco-non-determenistic: выбор создан по том, в какой срок маршрут пришел. Juniper не рекомендует использовать.Med назначается с помощью policy.Возможные действия с medВнутри policy metric - это обозначение med атрибута.Можно использовать, как в from, так и в then. Then: назначение метки - metric 50, приобщить к существующей метки - metric add 50, вычесть из metric subtract 50.Med можно назначить внутри protocols bgp:Med еще можно назначить аналогичным образом через policy:При использовании metric igp на префикс вешается med, равный igp метрики до роутера, который прислал этот префикс. При изменениях igp metric, будет модифицироваться и med.При использовании metric minimum-igp med не будет меняться при изменениях igp метрики.При агрегировании маршрутов - med становится = 0.Если между роутерами передаются агрегированный маршрут и вложенный в него в med, то вложенный будет передан с med, а агрегированный - с med = 0.Это дефолтное повадки и альтернатив этому нет.Weight (проприетарный атрибут cisco)Атрибут weight:- Позволяет назначить "вес" различным путям локально на маршрутизаторе.- Используется тогда, если у единственного маршрутизатора в наличии несколько выходов из автономной системы (сам маршрутизатор является точкой выхода).- Значим только локально, около маршрутизатора.- Не передается в обновлениях.- Чем больше значение атрибута, тем более предпочтителен путь выхода.Механизмы управления трафикомВходящим- As path prepend- community (если поддерживает провайдер)- med (подключение к одной и той же as)- анонс разных префиксов через разных ispисходящим- Проприетарный атрибут cisco weight (локально на маршрутизаторе)- local preference (локально в as)- косвенно можно политикой навешивать med на префиксы от пира и в зависимости поэтому будет еще регулироваться исходящий трафик.Выбор лучшего пути (bgp active route selection)1. Проверяем, что резолвится next-hop (без это направление и энергичным все равно не будет :/ )2. Route preference (admin distance)3. Больший local preference (inactive reason: local preference)4. Кратчайший as-path (inactive reason: as path)5. Меньший origin value (inactive reason: origin)6. Меньший med value (inactive reason: route metric or med comparison)7. Ebgp peer предпочтительней ibgp peer (inactive reason: interior > exterior > exterior via interior)8. C кратчайшей igp метрикой к protocol next-hop (inactive reason: not best in its group - igp metric)9. Если префикс взят из ibgp, то используем префикс от пира с минимальным rid (inactive reason: not best in its group - router id)10. Если префикс получен по ebgp, то используем более старый активный префикс (считается более стабильным) (inactive reason: not best in its group - active preferred)11. При использовании rr: кратчайший cluster list length (inactive reason: not best in its group - cluster list length)12. Наименьший router-id (inactive reason: not best in its group - router id)13. Наименьший source ip address (inactive reason: not best in its group - update source)в juniper вы можете просмотреть причину неактивности маршрута: inactive reason в выводе sh route protocol bgp x.X.X.X extensiveДефолтное поведение для ebgp маршрутов возможно изменено: path-selection external-router-id. При включении этом функционале для роутера выбор активного ebgp маршрута от собственных роутеров будет делаться по минимальному router-id.- Route preference (admin distance) - не попадет по ibgp, ebgp. Может только навешиваться через import-policy и в настройках bgp на любом уровне иерархии.MultipathОдин такой же маршрут прилетает с 2 пиров одной as либо несколько копий маршрута прилетает с одного пира. Активный маршрут будет вставлен в routing table с несколькими next-hop и трафик будет балансироваться между двумя пирами (в forwarding table все-таки будет вставляться один next-hop). Для inactive маршрутов будет указан один next-hop. Multipath не вставит маршруты с одинаковым med-plus-igp cost, при разных igp метриках до пиров. На роутере глобально должен быть включен load-balancing.При включенном multipath, алгоритм выбора оптимального пути игнорирует router id» и peer id.До включения:После:Link bandwidth extended communityПри включенном multipath можно задать желаемую балансировку между линками через extended community.Это механизм описан в draft-ietf-idr-link-bandwidth-06, и поэтому не считается стандартизированным, следовательно, возможно, он не сможет функционировать с некоторыми вендорами. В junos поддерживается.Позволяет делать балансировку пропорционально заданным в community скоростям.Пример использования:R1 и r2 соединены сразу же через два сабинтерфейса, на каждом из которых висит своя /30 сетьКонфиг r1:Конфиг r2:Что получилось:MultihopВозможность поднять ebgp peering между роутерами, без прямого физического соединения. Сессия прикручивается на lo интерфейсах.Важно в конфиге задать multihop. В таблице маршрутизации должен быть маршрут до пира.При поднятии сессии на lo интерфейсах используем:Set system default-address-selection - будет браться адрес lo автоматически- local-address (bgp, group или neighbor) - более специфичен, и если надо будет - перебьет уже настроенный default-address-selectionttl = 1 задаем, чтобы соседство установилось точно с кем-то ближайшим роутером. (Или иное значение, если роутер далеко)ConfigТ.К. Между роутерами теперь 2 физических линка, то можно балансировать трафик между ними.Modifying as pathOption 1: remove-privateДиапазон: 64512 - 65534Роутер, где настроен remove-private перед передачей префиксов удаляет из as path as из указанного выше диапазона.Можно настроить на всех уровнях: protocols bgp, group, neighbor.Option 2: local-asПри такой конфигурации r1, ebgp-сосед, который ждет, что у r1 будет as3333 сможет установить соседство с r1, хотя, после r1 принадлежит as1111. Результат:Зачем это нужноПредположим, оператор с as1111 купил сеть оператора с as3333. У as3333 были свои клиенты, подключенные по bgp, что не стали либо стесняются изменять конфигурацию на своих роутерах. В этом случае можно временно применить опцию local-as, чтобы выступить для таких дорог от лица предыдущей as (в примере - 3333), но внутри аппаратуры перевести инфораструктуру на as1111.Если добавить главное слово private:То r1 практически не будет добавлять as3333 при анонсе маршрутов, получаемых от 10.1.0.2 своим соседям.As-overrideЕсли на сети isp существуют 2два сессии с пирами из одной as, то при передаче маршрутов, предоставляемых одного site этой as второму site'у, второй site не примет такой префикс, потому как в as path будет дважды указана его as - это routing loop.Можно конфигурировать для группы или соседа.Роутер isp на полученном префиксе пыхтит в as path, as пира заменяем на личную. При получении префикса второму site isp делает стандартный prepend своей as. В следствии пиру в as 65500 прилетит префикс с таким as path:LoopsЕще один шанс решения ситуации, описанной в примере выше - чтобы ce2 получил маршрут своего удаленного site:На ce2:Тогда на ce2 прилетит префикс с as path:И роутер это сожрет.Опции настройки для пировPassive - локальный роутер перестает слать open message. Чтобы сессия поднялась, open message теперь должно прийти от удаленного пира.После задания passive для пира:Allow - принимает open message только из указанной сети. Возможно выбрать лишь для определенной группы:prefix-limit: ограничивает значение полученных префиксов от пира. Можно задействовать в зависимости от уровнях иерархии.Hold-time: меняем hold timer. По дефолту 90 sec. Разрешается применять на разных уровнях иерархии.Advertise-peer-as: позволяет ebgp маршруты передавать обратно ebgp пиру. Но тогда также у пира должен быть настроен as loops, чтобы он не отбросил префикс с лупом в as-path.Route reflectionОписан в rfc 4456КонцепцияЗаменяем full-mesh на сети между pe.- Позволяет ibgp-спикеру анонсировать другим ibgp-маршрутизаторам маршруты, полученные через ibgp- rr пересылает только активные маршруты пользователям ресурса, это ibgp соседи rr, которые не являются rr)- rr в автоматическом режиме не меняет ibgp атрибуты.- Для недопущения петель работают два новых атрибута:cluster list (1 либо более cluster id)originator id - id роутера, который сиюминутно переслал маршрут в as.Распространение маршрутов при обращении по rrБудем использовать следующие обозначения:- Ibgp rr-client - ibgp сосед в кластере- ibgp non-rr-client - ibgp сосед не в кластере- ebgp - ebgp соседраспространение маршрутов происходит следующим образом:- Ibgp rr-client > ibgp rr-client ibgp non-rr-client- ibgp non-rr-client > igbp rr-client- ibgp non-rr-client ibgp non-rr-client - не передается- egbp > ibgp rr-client non-rr-clientесли включить no-client-reflect, то такой шаг запретит анонсить префиксы между покупателями кластера.В такой ситуации, если требуется сохранить связность между этими клиентами - нужно настроить между ними full-mesh. Этот вариант развитий по идее может стать необходимым лишь при иерархичном роут-рефлектинге (о нем ниже).Rr добавляет/изменяет атрибуты (без политик по дефолту):Originator idrouter id первого роутера, который заслал маршрут в as.Cluster list (cluster id)список, включающий id всех rr, которые обрабатывали данный префикс. Если rr получит маршрут, у которого в cluster list будет id этого rr, то он его дропнет. Принимает участие в выборе активного маршрута (активным становится с минимальным cluster list). Cluster id добавляется к cluster list, когда маршрут отправляется. Cluster id должен быть уникальным в рамках as. Пользовании система навигации нескольких rr, можно для любых использовать одинаковый cluster id. Такой способы в таблице останется меньше на пути доставки а также подобной схеме вы сможете добиться хорошей отказоустойчивости онлайн.Правила выполнения работ, с originator и cluster list:- Для ebgp либо любого другого протокола, отличного от ibgp, originator и сluster list не добавляются- для ibgp clientclient / clientnon-client:- originator добавится только в том случае, когда до того его не было.- Cluster list дополнится новым cluster id.- Cluster id будет смонтирован, ежели его не бывало ранее.2 rr в кластереСоседство между rr рекомендуется монтировать как внутри отдельной группы для кластера, так и в выделенной группе. В обоих случаях при передаче маршрутов между rr петель не будет, т.К. Cluster id будет одинаковыми. Всякий из rr в кластере устанавливает ibgp с остальными rr, не включенных в кластер. В подобных схемах все таки тоже стараются использовать собственные cluster id.Если на сети несколько rr, то соседство из них может быть как в выделенной группе от rr-clients (ibgp), также и в этой же группе что и клиенты. Между rr - full-mesh.Rr-clients конфигурируются в особой группе, где должен быть включен: "cluster x.X.X.X"Со стороны клиентов конфигурация стандартная для ibgp - простое близость к rr на lo0 адресах (с включенным multihop!!)Hierarchical route reflectionОтличие от предшествующих: в схеме появляются не только rr и client, но еще и роутеры, выполняющие обе функции в рамках разных кластеров. Clients могут устанавливать ibpg по разным параметрам full-mesh. Это удобно применять, чтобы clients могли использовать маршруты от всех остальных clients нативно, без обработки rr. Чтобы rr не флудил копиями маршрутов, на нем можно отобрать no-client-reflect, это отключит пересылку маршрутов, полученных внутри кластера. Внешние маршруты одновременно с этим продолжают пересылаться.Modifying attributes on the rrВсе атрибуты bgp изменяются через policy. Ежели на rr есть ebgp, этап, с двуспальной вероятностью будет активна ф-ия: next-hop-self. В то же время у маршрутов, предоставляемых client, также next-hop будет меняться. Что ведет к не оптимальному форвардингу трафика (обязан идти напрямую к original роутеру, а будет идти через rr). Чтобы менять next-hop только у external: в policy матчим по interface ли neighbor.Fake-groupДанная проблема описана в kb20870 (https://kb.Juniper.Net/infocenter/index?Page=content