BGP отражает маршруты к одноранговому узлу, от которого он их получил.
-
Здравствуйте, Давайте начнем с топологии, чтобы было легче понять, о чем я говорю: ![Topology.png] Между всеми соседними маршрутизаторами, за исключением R1 и R4, существуют сеансы BGP. Эти маршрутизаторы не имеют настроенного пиринга, и это сделано специально. При выполнении
лабораторных работ по BGP я столкнулся со следующей проблемой: я объявил маршрут по умолчанию от маршрутизатора R1 и R4 на основе соседства. Маршрутизатор R2 повторно объявляет маршрут по умолчанию, полученный от R1, для R3, но не получает маршрут по умолчанию, исходящий от R4. Под «не получает» я имею в виду, что он не появляется в таблице BGP.
Я попробовал выполнить жесткий сброс пиринга BGP между R2 и R3, и это сработало на некоторое время, но через несколько мгновений маршрут по умолчанию от R4 снова был удален из таблицы BGP R2 из-за получения обратно маршрута по умолчанию от собственного AS R2. По сути, маршрутизатор R3 отразил маршрут по умолчанию, который он узнал от R2, обратно в R2, что привело к удалению маршрута по умолчанию, исходящего из R4, из таблицы BGP, несмотря на то, что это другой маршрут с другим AS-Path. Вот соответствующие фрагменты конфигурации маршрутизаторов: R1:
interface GigabitEthernet0/0 ip address 10.0.0.1 255.255.255.252 duplex auto speed auto media-type rj45
!
interface GigabitEthernet0/2 ip address 150.1.1.1 255.255.255.0 duplex auto speed auto media-type rj45
!
router bgp 1 bgp router-id 1.1.1.1 bgp log-neighbor-changes neighbor 10.0.0.2 remote-as 2 neighbor 10.0.0.2 default-originate R2:
interface GigabitEthernet0/0 ip address 10.0.0.2 255.255.255.252 duplex auto speed auto media-type rj45
!
interface GigabitEthernet0/1 ip address 10.0.0.9 255.255.255.252 duplex auto speed auto media-type rj45
!
interface GigabitEthernet0/2 ip address 150.2.2.2 255.255.255.0 duplex auto speed auto media-type rj45
!
router bgp 2 bgp router-id 2.2.2.2 bgp log-neighbor-changes network 150.2.2.0 mask 255.255.255.0 neighbor 10.0.0.1 remote-as 1 neighbor 10.0.0.10 remote-as 3 R3:
interface GigabitEthernet0/0 ip address 10.0.0.10 255.255.255.252 duplex auto speed auto media-type rj45
!
interface GigabitEthernet0/1 ip address 10.0.0.13 255.255.255.252 duplex auto speed auto media-type rj45
!
interface GigabitEthernet0/2 ip address 150.3.3.3 255.255.255.0 duplex auto speed auto media-type rj45
!
router bgp 3 bgp router-id 3.3.3.3 bgp log-neighbor-changes network 150.3.3.0 mask 255.255.255.0 neighbor 10.0.0.9 remote-as 2 neighbor 10.0.0.14 remote-as 1 R4:
interface GigabitEthernet0/0 ip address 10.0.0.14 255.255.255.252 duplex auto speed auto media-type rj45
!
interface GigabitEthernet0/2 ip address 150.1.1.4 255.255.255.0 duplex auto speed auto media-type rj45
!
route-map DEFAULT-SECONDARY permit 10 set as-path prepend 1 1
router bgp 1 bgp log-neighbor-changes neighbor 10.0.0.13 remote-as 3 neighbor 10.0.0.13 default-originate route-map DEFAULT-SECONDARY Вот состояние таблицы BGP на каждом устройстве перед очисткой сеанса BGP между R2 и R3: R1# sh ip bgp
BGP table version is 7, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path 0.0.0.0 0.0.0.0 0 i *> 150.2.2.0/24 10.0.0.2 0 0 2 i *> 150.3.3.0/24 10.0.0.2 0 2 3 i R2#sh ip bgp
BGP table version is 6, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0 10.0.0.1 0 1 i - here you can see that there is only the route received from R1 but no route from R4 *> 150.2.2.0/24 0.0.0.0 0 32768 i *> 150.3.3.0/24 10.0.0.10 0 0 3 i R3#sh ip bgp
BGP table version is 8, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0 10.0.0.9 0 2 1 i * 10.0.0.14 0 1 1 1 i *> 150.2.2.0/24 10.0.0.9 0 0 2 i *> 150.3.3.0/24 0.0.0.0 0 32768 i R4# sh ip bgp
BGP table version is 7, local router ID is 150.1.1.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path 0.0.0.0 0.0.0.0 0 i *> 150.2.2.0/24 10.0.0.13 0 3 2 i *> 150.3.3.0/24 10.0.0.13 0 0 3 i Вот состояние таблицы BGP на R2 вскоре после жесткого сброса сеанса между R2 и R3: R2#sh ip bgp
BGP table version is 6, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * 0.0.0.0 10.0.0.10 0 3 1 1 1 i - the route has appeared *> 10.0.0.1 0 1 i *> 150.2.2.0/24 0.0.0.0 0 32768 i *> 150.3.3.0/24 10.0.0.10 0 0 3 i Вот сообщения отладки обновления BGP, которые появились после сброса сеанса, непосредственно перед удалением маршрута из R4: *Jan 31 09:51:09.936: BGP(0): 10.0.0.10 rcv UPDATE w/ attr: nexthop 10.0.0.10, origin i, originator 0.0.0.0, merged path 3 2 1, AS_PATH , community , extended community , SSA attribute *Jan 31 09:51:09.937: BGPSSA ssacount is 0, Tunnel attribute *Jan 31 09:51:09.937: Tunnel encap type: 0, encap size: 0
*Jan 31 09:51:09.937: BGP(0): 10.0.0.10 rcv UPDATE about 0.0.0.0/0 -- DENIED due to: AS-PATH contains our own AS;
*Jan 31 09:51:09.937: BGP(0): 10.0.0.10 rcv UPDATE w/ attr: nexthop 10.0.0.10, origin i, originator 0.0.0.0, merged path 3 2, AS_PATH , community , extended community , SSA attribute *Jan 31 09:51:09.938: BGPSSA ssacount is 0, Tunnel attribute R2#
*Jan 31 09:51:09.938: Tunnel encap type: 0, encap size: 0
*Jan 31 09:51:09.938: BGP(0): 10.0.0.10 rcv UPDATE about 150.2.2.0/24 -- DENIED due to: AS-PATH contains our own AS;
*Jan 31 09:51:10.369: BGP(0): (base) 10.0.0.1 send UPDATE (format) 150.3.3.0/24, next 10.0.0.2, metric 0, path 3 Я заметил, что R3 рекламирует маршрут по умолчанию, который он получил от R2, обратно R2: R3#sh ip bgp neighbors 10.0.0.9 advertised-routes BGP table version is 8, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, t secondary path, Origin codes: i - IGP, e - EGP, ? - incomplete
RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 0.0.0.0 10.0.0.9 0 2 1 i *> 150.2.2.0/24 10.0.0.9 0 0 2 i *> 150.3.3.0/24 0.0.0.0 0 32768 i Total number of prefixes 3 Мой вопрос: является ли это правильным поведением BGP, и если да, то почему оно работает именно так? Или это программная ошибка? Моя версия IOS — Cisco IOS Software, IOSv Software (VIOS-ADVENTERPRISEK9-M), версия 15.9(3)M8, RELEASE SOFTWARE (fc1).
Заранее спасибо,
Алекс
-
Привет,
@a-dreszler
, Важно помнить, что BGP рекламирует только лучший путь для каждого префикса. R3 видит лучший путь от R2, поскольку путь, полученный от R4, имеет более длинный AS Path. Для R3 нормальным поведением является рекламирование лучшего пути всем своим соседям, включая R2. R2 просто игнорирует это обновление, поскольку его собственный номер AS присутствует в AS Path. Это называется обнаружением петли AS Path. С уважением,
Гарольд Риттер, CCIE #4168 (EI, SP) -
Здравствуйте. Спасибо за ответ, я думаю, что теперь я все понял. Я упустил тот факт, что BGP рекламирует только лучший путь.
С уважением, -
Спасибо,
@a-dreszler,
и спасибо за отзыв. С уважением,
Гарольд Риттер, CCIE #4168 (EI, SP) -
Здравствуйте
[, @a-dreszler] Нормальное и ожидаемое поведение... это следствие нормального выбора оптимального пути + правил объявления eBGP + предотвращения циклов... как объяснил г-н Риттер. С уважением
.ı|ı.ı|ı. Если это помогло, пожалуйста, оцените.ı|ı.ı|ı. -
Здравствуйте.
Приношу извинения, я уже писал ранее, но неправильно прочитал ваш пост, поэтому удалил его, однако с тех пор другие пользователи уже ответили.
Хочу только добавить, что поведение, которое вы наблюдаете,
ТАКЖЕ
связано с тем, что вы добавляете префикс из R4. Если бы вы не добавляли префикс в R4, я бы сказал, что и R2, и R3 имели бы двойные записи в своем bgp rib для полученных маршрутов по умолчанию. Пожалуйста, оцените и отметьте как принятое решение, если вы нашли какую-либо из предоставленной информации полезной.
Это поможет другим участникам форума найти ценный ответ и расширит глобальную сеть сообщества.
С уважением,
Пол -
Привет, @a-dreszler
Я хотел бы прокомментировать причину, по которой R3 отправляет обновление для маршрута по умолчанию обратно в R2, даже несмотря на то, что лучший путь BGP для маршрута по умолчанию в R3 проходит через R2. 1. Можете ли вы подтвердить, что R3 не имеет исходящих фильтров для пиринга с R2 и R4? 2. Повторите сценарий, выполнив следующие действия на
R3
: настройте две фиктивные карты маршрутов (например,
route-map TO-R2 permit any
и
route-map TO-R4 permit any
), примените первую карту маршрутов в исходящем направлении к R2, а вторую карту маршрутов — в исходящем направлении к R4, подождите некоторое время, выполните на R3 команду
show bgp ipv4 unicast update-group
и подтвердите, что R2 и R4 находятся в отдельных группах обновлений, выполните команду
show bgp ipv4 unicast neighbors x.x.x.x advertised-routes
и замените x.x.x.x адресами пиринга R2 и R4, вы больше не должны видеть, что R3 рекламирует маршрут по умолчанию обратно к R2. Спасибо, Кристиан.
Здравствуйте! Похоже, вам интересна эта беседа, но у вас пока нет учетной записи.
Вы устали просматривать одни и те же посты каждый раз, когда заходите на сайт? После регистрации, вам не придётся искать обсуждения в которых вы принимали участие, настройте уведомления о новых сообщениях так как вам это удобно (по электронной почте или уведомлением). У вас появится возможность сохранять закладки и ставить лайки постам, чтобы выразить свою благодарность другим участникам сообщества.
С вашими комментариями этот пост может стать ещё лучше 💗
Зарегистрироваться Войти