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