Один из моих читателей прислал мне любопытный вопрос об NSSA (подробнее в будущей статье), который побудил меня копнуть глубже, зачем понадобилось поле OSPF Forwarding Address (FA) в Type-5 и Type-7 LSA.
Типовой сценарий для объяснения OSPF FA, который можно найти в интернете, выглядит так:
![Источник: blog.ipspace.net Источник: blog.ipspace.net](https://habrastorage.org/getpro/habr/upload_files/0b9/7eb/96b/0b97eb96b904aa405d101e9de9c1dc36.png)
Два 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, отладка стала ещё более увлекательной. Ура!
kterik
Спасибо за информацию про forwarding address в LSA 5 анонсах. Это новая для меня вещь.
В лабораторной схеме из этой статьи анонс пути до внешнего узла, имеющего этот самый forwarding address, практически бесполезен, поскольку обычно внутренние линки в сети надёжнее, чем внешние, а таким хаком резевируются именно внутренние связи, а не внешние.
Также надо учитывать, что в принципе использование поля forwarding address в анонсах LSA 5 является крайне нетиповой вещью и может вызвать много головной боли для людей, впоследствии поддерживающих такую сеть. Об этом, собственно, и сам автор написал, спасибо ему за это.