расстояние администратора в BGP

[Cristian Matei]

Здравствуйте, Настройка локального административного расстояния в BGP — одна из многих тем, которые часто неправильно понимают, в основном потому, что в документации и доступных учебных материалах постоянно повторяется одно и то же, и я бы сказал, что это неверное представление. Чтобы понять и обосновать это, я бы хотел сначала уточнить кое-что дополнительно. Хотя мы настраиваем параметры административной дистанции на уровне протокола маршрутизации, административная дистанция не является атрибутом протокола маршрутизации, а скорее атрибутом RIB. Мы все знаем, что RIB решает, будет ли для любого заданного префикса/длины префикса устанавливать путь OSPF или EIGRP, сравнивая административные расстояния протоколов, так как же AD может быть атрибутом протокола маршрутизации? Протокол маршрутизации не заботится о значении AD, а RIB — заботится. Протокол маршрутизации отвечает только за определение лучшего пути из заданного набора допустимых путей и отправку этого пути в RIB со всеми связанными атрибутами, которые являются специфическими для протокола маршрутизации, но протокол маршрутизации не прикрепляет значение AD при отправке пути в RIB. Вернемся к локальному AD BGP. В документации указано, что он предназначен для локально созданных префиксов (что является одновременно ложным и истинным). Приведен пример локально введенных префиксов через сетевые заявления или перераспределение в BGP (ложное заявление). Префиксы, локально введенные в таблицу BGP, берутся из RIB, поэтому с точки зрения RIB AD этих префиксов является AD протокола маршрутизации, которому принадлежат записи, в то время как после появления этих префиксов в BGP RIB значение AD отсутствует. Итак, какова же цель BGP Local AD? Это префиксы BGP / лучшие пути, отправленные BGP в RIB и установленные в RIB, если эти префиксы / лучшие пути не были получены через EBGP или IGBP. Какие префиксы соответствуют этим критериям? Очень немногие, одним из примеров является результат BGP summary / aggregate, поскольку это префикс / лучший путь BGP, который BGP вводит (он не берет его из RIB), и когда / если RIB устанавливает его, он будет использовать для него значение BGP Local AD. Возьмите маршрутизатор IOS-XE или коммутатор уровня 3 с следующей простой конфигурацией: interface GigabitEthernet0/0 no shutdown ip address 10.10.10.1 255.255.255.0
!
interface GigabitEthernet0/1 no shutdown ip address 10.10.20.1 255.255.255.0
!
router bgp 100 network 10.10.10.0 mask 255.255.255.0 network 10.10.20.0 mask 255.255.255.0 aggregate-address 10.10.0.0 255.255.0.0 distance bgp 20 200 210 Подождите до 60 секунд, время по умолчанию для таймера агрегирования BGP, и выполните следующую команду, чтобы увидеть 10.10.0.0/16, присутствующий в BGP RIB: show bgp ipv4 unicast 10.10.0.0 Затем выполните следующую команду, чтобы увидеть 10.10.0.0/16, установленный в RIB со значением 210, значением BGP Local AD. show ip route 10.10.0.0 Спасибо, Кристиан.

[balaji.bandi]

Идентифицирует маршруты, созданные локально
. Применяется конкретно к маршрутам, которые являются частью локальной автономной системы (AS) и были созданы на этом конкретном маршрутизаторе. Local- Расстояние для маршрутов, сгенерированных локально маршрутизатором. По умолчанию: 200 Регулировка локального расстояния обычно необходима при перераспределении маршрутов или миграции. Если маршрутизатор получает один и тот же префикс от BGP (локального происхождения) и другого протокола маршрутизации (например, OSPF или EIGRP), он использует AD, чтобы решить, какой из них установить в базе маршрутизации (RIB). Снижение локального расстояния BGP ниже расстояния IGP (например, ниже 110 для OSPF) гарантирует, что маршрутизатор будет предпочитать свой собственный маршрут, сгенерированный BGP, маршруту IGP. Иногда можно изменить локальный AD, чтобы предотвратить возникновение циклов. BB
=====Preenayamo Vasudevam=====
***** Оценить все полезные ответы *****
Как обратиться за помощью к сообществу Cisco

[Cristian Matei]

Привет, Несмотря на то, что существует множество документов и учебных материалов, посвященных использованию/изменению значения AD при перераспределении маршрутов с целью предотвращения циклов маршрутизации или неоптимальной маршрутизации, это всего лишь учебное упражнение, позволяющее ознакомиться с возможными вариантами и лучше понять функциональность. И ничего больше. Использование/изменение значения AD для устранения циклов уровня 3 — это путь к катастрофе: либо цикл не устраняется, либо устраняется временно, пока не возникнет ситуация конкуренции. Почему? Цикл маршрутизации был создан вашей сетевой архитектурой и конфигурацией протокола маршрутизации, а не RIB. Так можно ли утверждать, что для устранения цикла нам нужно изменить атрибуты RIB, то есть значение AD, поскольку RIB изначально не отвечает за цикл? Я не хочу быть грубым или резким, просто хочу убедиться, что мы не будем продолжать распространять ту же дезинформацию, которая существует уже много лет. Спасибо, Кристиан.

[balaji.bandi]

Not trying to be rude or harsh here, just ensuring we don't keep on propagating the same misinformation which has been done for years now. Здесь это не нужно, поскольку у каждого свой образ мышления и подход, мои взгляды могут отличаться от ваших, поэтому это и есть сообщество, мы не изобретаем ничего нового (а вы?), мы используем то, что было написано в RFC, некоторые могут думать иначе (возможно, я прав в своей точке зрения), но ваш случай может быть другим, это не означает, что конечная цель меняется (это другой способ решения). Я добавил свои комментарии на основе документации, которую использовал во время обучения. Я рад тому, как вы комментируете пост OP (это ваши взгляды), и всегда приветствую правильный подход. Здесь все быстро меняется, поэтому разные точки зрения решают разные проблемы. Мы говорим только о том, на чем основан RFC; реальный результат может быть другим для конкретного случая использования (не обязательно всегда правильным). BB
=====Preenayamo Vasudevam=====
***** Оцените все полезные ответы *****
Как обратиться за помощью к сообществу Cisco

[Cristian Matei]

Привет, Хотя я согласен, что есть разные способы жевать жвачку, в данном конкретном случае я категорически не согласен. Не существует RFC, в котором были бы описаны административные расстояния, а также их внутреннее функционирование, к которому мы могли бы отнестись. AD началось как специфическая вещь для поставщиков много десятилетий назад, а затем было в основном скопировано всеми другими поставщиками, чтобы сохранить совместимость между поставщиками и, таким образом, упростить внедрение продукта. Идея использования AD в качестве методологии для предотвращения циклов возникла несколько десятилетий назад как лабораторное упражнение, в конечном итоге она была использована для того, чтобы показать, чего можно достичь и почему ее не следует использовать для разрыва циклов, поскольку она не может этого сделать, а когда она это делает, то это лишь временное решение, а не постоянное. Впоследствии детали были утрачены, и появились тысячи документов и учебных материалов с такими примерами, в которых не упоминалось, что ее не следует использовать и почему. И вот мы сегодня здесь. Я остаюсь при своем мнении и готов как теоретически, так и практически продемонстрировать, почему это не является постоянным решением и, следовательно, бесполезно для использования. Спасибо, Кристиан.

[paul driver]

Здравствуйте
[, @Cristian Matei] @Cristian Matei
написал:
Я подтверждаю свои слова и готов как теоретически, так и практически продемонстрировать, почему это не является постоянным решением и,
следовательно
,
бесполезно для использования. Но согласитесь ли вы, что оно может быть полезно в определенных случаях, например, при интеграции/миграции протоколов? Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.
С уважением,
Пол

[Cristian Matei]

Привет, @paul driver
Мое сообщение о том, что AD никогда не следует использовать, касалось использования этого механизма для предотвращения/прерывания циклов. Для миграции/интеграции маршрутизационных протоколов изменение значения AD является вполне приемлемым решением (единственным, позволяющим обеспечить плавную миграцию и иметь в распоряжении быстрый и работающий резервный вариант), с тем замечанием, что по окончании миграции настоятельно рекомендуется вернуть AD протокола к значению по умолчанию. Спасибо, Кристиан.

[paul driver]

Здравствуйте.
Как указано, эта команда может использоваться для изменения административного расстояния маршрутов, полученных по протоколу BGP, для выбора оптимального пути.
Значения по умолчанию:
внешний
(ebgp = 20),
внутренний
(iBGP = 200),
локальный
(локально введенный = 200)
.
Примечание:
локально введенные маршруты происходят либо из использования команды network/aggregation в процессе BGP, либо из перераспределения маршрутов в BGP. Пожалуйста, оцените и отметьте как принятое решение, если вы нашли полезной какую-либо из предоставленной информации.
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.
С уважением,
Пол

[daniel ng]

Очень информативно. Всегда приятно увидеть интересные идеи, выходящие за рамки цитат из книг или документации. Поскольку RIB показывает только выученный маршрут, а BGP RIB не показывает AD, как еще можно проще проверить локальный AD? Каковы последствия изменения этого локального AD?

[Cristian Matei]

Привет, В IOS-XE вы можете увидеть AD по умолчанию или настроенные AD с помощью команды
show ip protocols
; другой вариант — использовать команду
show running-config | section router
, однако она не покажет вам AD, если вы используете AD по умолчанию, что в целом и следует делать. Что касается последствий изменения BGP AD для локального, то это влияет на значение агрегированного AD BGP: 1. Установка значения 255, в результате чего агрегат больше не будет установлен в RIB, может привести к блокировке трафика, поскольку в RIB через BGP больше не будет установлен маршрут NULL 0, и если в RIB установлен другой, менее конкретный маршрут, с которым теперь будет совпадать входящий трафик, маршрутизатор будет направлять трафик этим путем; в то же время, возможно, это именно то, что вы намеренно хотите, чтобы объявить агрегат через BGP, однако не имея маршрута NULL 0, установленного в RIB, чтобы входящий трафик маршрутизировался через записи RIB IGP. 2. Установка значения меньше, чем AD вашего домена IGP, в котором работает/подключен маршрутизатор, может привести к блокированию трафика, так как теперь агрегат BGP с NH или NULL 0 будет установлен в RIB вместо записи IGP (если было идеальное совпадение префикса/длины префикса, объявленного IGP); в то же время, возможно, это именно то, что вы намеренно хотите, установив маршрут NULL 0 в RIB, чтобы входящий трафик был отброшен/отклонен. 3. Установка любого другого значения, кроме вышеупомянутых случаев использования, как правило, предназначена только для лабораторных исследований / тестирования / практики, см. изменение значения AD, не известно о каких-либо реальных случаях его использования. Спасибо, Кристиан.