В первой заметке я описал типичный (насколько его проповедуют в интернете) сценарий использования Forwarding Address (FA): два ASBR подключены к одному внешнему сегменту, причём redistribution маршрутов настроен только на одном из них.
Очевидно, что такой дизайн плох с точки зрения отказоустойчивости, но, возможно, существуют сценарии, когда использование OSPF FA уместно?
Рассмотрим более хитрую ситуацию: 2 ASBR подключены к одному внешнему сегменту, реализованному в виде Metro Ethernet. Один ASBR использует подключение 1 Gbps, другой – 100 Mbps.
Задавшись целью исправить огрехи предыдущего дизайна, мы используем BGP на обоих ASBR, которые выполняют redistribute маршрутов из BGP в OSPF. Отказоустойчивость налажена, однако ценой оптимальной маршрутизации: на C1 присутствуют два равноценных маршрута, тогда как в действительности один из них имеет в 10 раз меньшую пропускную способность.
Посмотрим на базу данных OSPF и таблицу маршрутизации C1:
C1#show ip ospf data external
OSPF Router with ID (192.168.0.3) (Process ID 1)
Type-5 AS External Link States
LS age: 40
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 192.168.0.2 (External Network Number )
Advertising Router: 192.168.0.1
LS Seq Number: 80000001
Checksum: 0xA154
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 65001
LS age: 25
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 192.168.0.2 (External Network Number )
Advertising Router: 192.168.0.4
LS Seq Number: 80000002
Checksum: 0x8D64
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1
Forward Address: 0.0.0.0
External Route Tag: 65001C1#show ip route 192.168.0.2
Routing entry for 192.168.0.2/32
Known via "ospf 1", distance 110, metric 1
Tag 65001, type extern 2, forward metric 1
Last update from 10.0.128.6 on GigabitEthernet0/2, 00:00:47 ago
Routing Descriptor Blocks:
10.0.128.6, from 192.168.0.4, 00:00:47 ago, via GigabitEthernet0/2
Route metric is 1, traffic share count is 1
Route tag 65001
* 10.0.128.1, from 192.168.0.1, 00:01:01 ago, via GigabitEthernet0/1
Route metric is 1, traffic share count is 1
Route tag 65001Время для очередного трюка:
Включаем OSPF на (внешних) соединениях Metro Ethernet LAN, которые связывают нашу OSPF-сеть с внешним маршрутизатором (да, это действительно плохая затея с точки зрения безопасности).
Выставим правильные веса OSPF (или пропускную способность) на интерфейсах.
Расчехлим бубен, чтобы ASBR начал выставлять корректный Forwarding Address в Type-5 LSA и процесс выбора лучшего внутреннего маршрута OSPF сошелся на самом быстром доступном пути.
Невероятно, но факт – это работает:
C1#show ip route 192.168.0.2
Routing entry for 192.168.0.2/32
Known via "ospf 1", distance 110, metric 1
Tag 65001, type extern 2, forward metric 2
Last update from 10.0.128.1 on GigabitEthernet0/1, 00:01:13 ago
Routing Descriptor Blocks:
* 10.0.128.1, from 192.168.0.4, 00:01:13 ago, via GigabitEthernet0/1
Route metric is 1, traffic share count is 1
Route tag 65001Если есть желание воспроизвести полученные результаты самостоятельно,
начните с OSPF-Forwarding-Address-Bandwidth-Mismatch топологии для VIRL из репозитория на Github.
Также можно наблюдать увлекательное (aka как мы вообще в таком закопались) поведение:
Если раньше оба ASBR анонсировали Type-5 LSA, то после включения OSPF на внешних интерфейсах только один из них продолжает анонсировать внешние маршруты.
C1#show ip ospf data external
OSPF Router with ID (192.168.0.3) (Process ID 1)
Type-5 AS External Link States
LS age: 272
Options: (No TOS-capability, DC, Upward)
LS Type: AS External Link
Link State ID: 192.168.0.2 (External Network Number )
Advertising Router: 192.168.0.4
LS Seq Number: 80000003
Checksum: 0x16CE
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 1
Forward Address: 10.0.0.2
External Route Tag: 65001В нашей сети Type-5 LSA анонсирован ASBR, который вообще не находится на пути трафика в сторону внешних префиксов (я уверен, что где-то в OSPF RFC есть раздел, согласно которому выбор сделан по наибольшему ASBR Router ID).
Ура, мы сэкономили немного памяти на Type-5 LSA и снова усложнили использование протокола.
А теперь вишенка на торте: в описанной схеме OSPF FA не нужен в принципе. Правильным решением было бы увеличить метрику внешнего маршрута, а также использовать тип E1 вместо E2, чтобы другие маршрутизаторы сети учитывали полный вес пути (внутренний + внешний) до импортных маршрутов. К сожалению, в реальной жизни проблемы решаются иначе (по крайней мере в лабе CCIE).
