OSPF Forwarding Address: ещё один костыль, часть 2

В первой заметке я описал типичный (насколько его проповедуют в интернете) сценарий использования 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: 65001

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 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).