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

Один из моих читателей прислал мне любопытный вопрос об NSSA (подробнее в будущей статье), который побудил меня копнуть глубже, зачем понадобилось поле OSPF Forwarding Address (FA) в Type-5 и Type-7 LSA.

Типовой сценарий для объяснения OSPF FA, который можно найти в интернете, выглядит так:

Источник: blog.ipspace.net

Два OSPF ASBR подключены к одному и тому же внешнему сегменту сети, однако только на одном из ASBR запущен протокол маршрутизации с этим сегментом (на схеме это BGP); этот же ASBR выполняет redistrubute внешних маршрутов в OSPF. Хотелось бы уметь отправлять трафик в сторону внешних префиксов через оба ASBR, но это невозможно, так как только один из ASBR объявляет внешние маршруты в сегмент OSPF.

Основные моменты по настройке E1 и E2:

hostname E1
!
interface Loopback0
 description Loopback
 ip address 192.168.0.1 255.255.255.255
 ip ospf 1 area 1
!
interface GigabitEthernet0/1
 description to C1
 ip address 10.0.128.1 255.255.255.252
 ip ospf 1 area 1
 ip ospf cost 1
!
interface GigabitEthernet0/2
 description to External_LAN
 ip address 10.0.0.1 255.255.128.0
!
router ospf 1
 redistribute bgp 65000 subnets
 passive-interface Loopback0
!
router bgp 65000
 bgp log-neighbor-changes
 redistribute ospf 1
 neighbor 10.0.0.2 remote-as 65001

hostname E2
!
interface Loopback0
 description Loopback
 ip address 192.168.0.4 255.255.255.255
 ip ospf 1 area 1
!
interface GigabitEthernet0/1
 description to C1
 ip address 10.0.128.6 255.255.255.252
 ip ospf 1 area 1
 ip ospf cost 1
!
router ospf 1

BGP (соответственно, и redistribution) настроены на E1, но не на Е2.

А теперь к интересующей нас части базы данных OSPF. Маршрут 192.168.0.2/32, который объявлен X1 по eBGP, попадает в OSPF как Type-5 LSA на E1 (192.168.0.1).

Type-5 LSA в БД OSPF:

C1#show ip ospf database external

            OSPF Router with ID (192.168.0.3) (Process ID 1)

    Type-5 AS External Link States

  LS age: 301
  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

Если есть желание воспроизвести полученные результаты самостоятельно, можете скачать файлы для VIRL из репозитория на Github.

Познакомьтесь с Его Величеством Костылём: что если один ASBR анонсирует внешний next-hop (Forwarding Address) в Type-5 LSA, и при этом оба пограничных маршрутизатора анонсируют внешний префикс (надеюсь, как stub network)? Рекурсивный поиск next-hop должен справиться с задачей, так что C1 получит два равноценных маршрута к внешнему префиксу в таблицу маршрутизации.

Чтобы такая конструкция заработала, E1 и E2 должны анонсировать внешнюю подсеть как внутренний префикс в OSPF, поэтому нужно включить OSPF на внешних интерфейсах E1 и E2:

interface GigabitEthernet0/2
 description to External_LAN
 ip ospf cost 1

Внешний интерфейс нельзя сделать пассивным (= stub network). Как минимум, последние версии Cisco IOS не выставляют FA, если next-hop известен через passive interface; внешняя сеть должна быть доступна через полноценный интерфейс с OSPF. Мне не удалось найти соответствующих требований в RFC2328 – если я что-то упустил, пожалуйста, дайте знать в комментариях.

После этой настройки, Type-5 LSA получают ненулевое значение Forwarding Address, и C1 устанавливает два равноценных пути до внешнего маршрута в таблицу маршрутизации.

C1>show ip ospf database external

            OSPF Router with ID (192.168.0.3) (Process ID 1)

Type-5 AS External Link States

  LS age: 907
  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: 0x2CBD
  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

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.6 on GigabitEthernet0/2, 00:15:21 ago
  Routing Descriptor Blocks:
    10.0.128.6, from 192.168.0.1, 00:15:21 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:15:21 ago, via GigabitEthernet0/1
      Route metric is 1, traffic share count is 1

Проблема решена? НЕТ, КОНЕЧНО ЖЕ НЕТ. Мы сделали только хуже:

• Даже если на первый взгляд всё работает, как надо, E1 – всё ещё единая точка отказа: если он упадёт, конец redistribution маршрута, и, как следствие, связности до внешних префиксов.

• И так сложный link-state протокол маршрутизации получил ещё один неочевидный костыль. Вспомните про нюанс с passive interface, а ещё посмотрите на дополнительные детали при выборе лучшего маршрута в OSPF (RFC 2328).

• Чтобы костыль работал, OSPF должен быть активен на внешних интерфейсах (по крайней мере в последних версиях Cisco IOS). Не самый лучший вариант с точки зрения безопасности (пожалуйста, даже не упоминайте, что можно было бы использовать ACL для фильтрации пакетов OSPF, пока не прочтёте эту заметку).

Правильным решением было бы запустить BGP и redistribution на обоих ASBR (да, есть сюрпризы с two-way redistribution). Если кто-то стал бы возмущаться подобным недосмотром в OSPF, то лучше нанести ему добро и исправить кривой дизайн.

К сожалению, стандарты рождаются иначе. Неудивительно, что научная среда посмеивается над громоздкостью распределённых протоколов маршрутизации (параллельно нахваливая своё болото), а мы последовательно упражняемся в YAK shaving.

Ах да, поскольку мы получили такую замечательную функцию в OSPF, отладка стала ещё более увлекательной. Ура!