Disclaimer: только для гиков; устаревшая технология; статья в режиме “just for fun”.
Разобравшись со смузи и подворотами, можем приступить к сути статьи – BGP synchronization в связке с OSPF. Стоит сразу отметить, что технология BGP sync действительно не является актуальной уже лет дцать и многие современные платформы даже не поддерживают её. В своё время я наткнулся на довольно занятное описание одной особенности BGP sync при использовании с OSPF в качестве IGP и хотел бы поделиться полученным опытом.
Впрочем, займёмся лабой; чем меньше топология, тем проще её анализировать:
На данный момент настроена лишь базовая адресация:
R1(config)#int f0/0
R1(config-if)#ip address 192.168.12.1 255.255.255.0
R1(config-if)#no shutdown
R2(config)#int f0/0
R2(config-if)#ip address 192.168.12.2 255.255.255.0
R2(config-if)#no shutdown
R2(config)#int f0/1
R2(config-if)#ip address 192.168.23.2 255.255.255.0
R2(config-if)#no shutdown
R3(config)#int f0/1
R3(config-if)#ip address 192.168.23.3 255.255.255.0
R3(config-if)#no shutdown
Включим BGP вместе с synchronization на R1 и R3:
R1(config)#router bgp 1
R1(config-router)#synchronization
R1(config-router)#neighbor 192.168.23.3 remote 1
R3(config)#router bgp 1
R3(config-router)#synchronization
R3(config-router)#neighbor 192.168.12.1 remote 1
Самое время добавить щепотку тестовых маршрутов. Создадим loopback 0 на R1 с адресом 1.1.1.1/32 и добавим его в BGP:
R1(config)#interface Loopback 0
R1(config-if)#ip address 1.1.1.1 255.255.255.255
R1(config)#router bgp 1
R1(config-router)#network 1.1.1.1 mask 255.255.255.255
Теперь можно включить в схеме OSPF, чтобы обеспечить связность между BGP маршрутизаторами:
R1(config)#int f0/0
R1(config-if)#ip ospf 1 area 0
R2(config)#router ospf 1
R2(config-router)#network 0.0.0.0 255.255.255.255 area 0
R3(config)#int f0/1
R3(config-if)#ip ospf 1 area 0
На данный момент маршрут должен быть в BGP RIB на R3, однако он не может быть установлен в global RIB вследствие BGP sync:
R3#sho ip bgp 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 0
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
Local
192.168.12.1 (metric 2) from 192.168.12.1 (192.168.12.1)
Origin IGP, metric 0, localpref 100, valid, internal, not synchronized
R3#sho ip bgp
<output omitted>
Синхронизация в своё время была призвана защитить сеть от возникновения дыр маршрутизации, когда маршрут известен на оконечных BGP маршрутизаторах, но не на транзитных устройствах. Исправим возникшую “проблему”, добавив 1.1.1.1/32 в сеть OSPF c помощью переноса этого маршрута из BGP:
R1(config)#router ospf 1
R1(config-router)#redistribute bgp 1 subnets
На данный момент iBGP маршрут известен и по BGP, и по OSPF, поэтому он должен пройти проверку BGP sync, однако по какой-то причине 1.1.1.1/32 до сих пор находится в состоянии not synchronized:
R3#sho ip bgp
<output omitted>
R3# sho ip bgp 1.1.1.1/32
BGP routing table entry for 1.1.1.1/32, version 3
Paths: (1 available, no best path)
Not advertised to any peer
Refresh Epoch 1
Local
192.168.12.1 (metric 2) from 192.168.12.1 (192.168.12.1)
Origin IGP, metric 0, localpref 100, valid, internal, not synchronized
Мне не удалось найти сколько-то внятного дебага, который пролил бы свет на причину этого поведения. Впрочем, существует довольно любопытная заметка по отладке BGP:
If BGP synchronization is enabled, there must be a match for the prefix in the IP routing table in order for an internal BGP (iBGP) path to be considered a valid path. <...> If the matching route is learned from an Open Shortest Path First (OSPF) neighbor, its OSPF router ID must match the BGP router ID of the iBGP neighbor.
Вольный перевод
Если функция BGP synchronization включена, должно быть соответствие между маршрутом в базе данных BGP и таблице маршрутизации, чтобы такой маршрут, полученный по iBGP, считался корректным. <...> В случае, если маршрут известен по OSPF, то OSPF RID соседа должен совпадать с RID соседа iBGP.
Мне кажется, что было бы несколько точнее сформулировать вышеизложенную мысль следующим образом: BGP RID должен совпадать с OSPF RID внутри соответствующего LSA5, в нашем случае – 1.1.1.1/32. Разница между двумя формулировками заключается в том, что iBGP сосед не обязан быть OSPF соседом. Также стоит отметить, что в силу применения BGP sync на стыке транзитной и внешней сетей эта функция учитывает только LSA5, внутренние OSPF маршруты при этом она игнорирует (я оставлю проверку этого факта на совести внимательного читателя).
Сможете, вооружившись этим знанием, определить RID для OSPF и BGP? Если вы полагаете, что это 1.1.1.1/32 для OSPF и 192.168.12.1 для BGP – вы угадали:
R3#sho ip bgp neighbors | i ID
BGP version 4, remote router ID 192.168.12.1
R3#sho ip ospf database external | i Advertising
Advertising Router: 1.1.1.1
Поскольку мы создали loopback после инициализации процесса BGP, последний использовал наименьший IP адрес на физических интерфейсах в качестве RID; что касается OSPF, то он уже мог выбрать RID среди интерфейсов типа loopback. Проверим, что корень проблемы - это несовпадение RID:
R1(config)#router bgp 1
R1(config-router)#bgp router-id 1.1.1.1
R3#sho ip bgp
<output omitted>
R3#sho ip bgp nei | i ID
BGP version 4, remote router ID 1.1.1.1
R3#sho ip ospf database external | i Advertising
Advertising Router: 1.1.1.1
Как мы видим, теперь маршрут является корректным с точки зрения BGP, и его можно передавать дальше.
BGP synchronization, хоть и кошмарил раньше кандидатов на CCIE, теперь ушёл на покой, так что эта тема сейчас находится под грифом “just for fun” в библиотеке сетевых знаний.
