Один из моих читателей прислал мне любопытный вопрос об NSSA (подробнее в будущей статье), который побудил меня копнуть глубже, зачем понадобилось поле OSPF Forwarding Address (FA) в Type-5 и Type-7 LSA.
Типовой сценарий для объяснения OSPF FA, который можно найти в интернете, выглядит так:
Два 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, отладка стала ещё более увлекательной. Ура!
