[Перевод] OSFP NSSA: ещё один способ выстрелить себе в ногу
В интернете можно найти множество статей, которые демонстрируют, что мудрёный дизайн с использованием OSPF обычно приносит больше головной боли, нежели пользы. Одна из функций, способствующих переусложению OSPF, — not-so-stubby area (NSSA). Если название выглядит недостаточно устрашающе, прочтите статью Пепельняка на этот счёт. Всё ещё зудит внедрить в свою сеть? Тогда у меня для вас дополнительный пример самострела, который может переубедить ярых сторонников «простого» OSPF использовать «сложный» BGP в нестандартных сценариях.
Как обычно, тестовая схема:
Зона 1 — NSSA, поэтому R1 и R2 являются ABR. R1 также выполняет роль ASBR за счёт redistribution префикса 1.1.1.1/32. У всех соединений между маршрутизаторами одинаковый вес, равный 1; исключение — R1-R2, которое является запасным путём с увеличенным весом. Ниже базовые настройки такой схемы:
R1#show run | section interface FastEthernet|router ospf|Loopback
interface Loopback0
ip address 1.1.1.1 255.255.255.255
interface FastEthernet0/0
ip address 192.168.12.1 255.255.255.0
ip ospf 1 area 1
ip ospf cost 10
interface FastEthernet0/1
ip address 192.168.13.1 255.255.255.0
ip ospf 1 area 0
router ospf 1
router-id 1.1.1.1
area 1 nssa
redistribute connected subnetsR2#show run | section interface FastEthernet|router ospf|Loopback
interface Loopback0
ip address 2.2.2.2 255.255.255.255
interface FastEthernet0/0
ip address 192.168.12.2 255.255.255.0
ip ospf 1 area 1
ip ospf cost 10
interface FastEthernet0/1
ip address 192.168.24.2 255.255.255.0
router ospf 1
router-id 2.2.2.2
area 1 nssa
network 0.0.0.0 255.255.255.255 area 0R3#show run | section interface FastEthernet|router ospf|Loopback
interface Loopback0
ip address 3.3.3.3 255.255.255.255
interface FastEthernet0/0
ip address 192.168.34.3 255.255.255.0
interface FastEthernet0/1
ip address 192.168.13.3 255.255.255.0
router ospf 1
router-id 3.3.3.3
network 0.0.0.0 255.255.255.255 area 0R4#show run | section interface FastEthernet|router ospf|Loopback
interface Loopback0
ip address 4.4.4.4 255.255.255.255
interface FastEthernet0/0
ip address 192.168.34.4 255.255.255.0
interface FastEthernet0/1
ip address 192.168.24.4 255.255.255.0
router ospf 1
router-id 4.4.4.4
network 0.0.0.0 255.255.255.255 area 0У R4 должно быть два пути до 1.1.1.1/32:
основной — через R3, благодаря LSA5, созданному R1;
запасной — через R2, благодаря LSA5, сгенерированному R2 на основе содержимого LSA7.
Однако в действительности это не так:
R4#show ip os database | begin Type-5
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
1.1.1.1 1.1.1.1 876 0x80000002 0x0099FD 0Возможно, LSA функционально эквивалентны? Маловероятно, поскольку в этом случае должен был бы остаться LSA5 от R2 (1.1.1.1 меньше 2.2.2.2). Проверим для начала связность:
R4#traceroute 1.1.1.1 source 4.4.4.4
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.34.3 48 msec 44 msec 52 msec
2 192.168.13.1 44 msec 48 msec 48 msecОсновной путь определённо в порядке, поэтому протестируем переключение на запасной маршрут:
R3(config)#interface FastEthernet 0/1
R3(config-if)#ip ospf shutdownR4#ping 1.1.1.1 source 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
.....
Success rate is 0 percent (0/5)
R4#
R4#show ip route 1.1.1.1
% Network not in tableОчевидно, с запасным маршрутом что-то пошло не так. В LSDB — шаром покати:
R4#show ip ospf database
OSPF Router with ID (4.4.4.4) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 1186 0x80000005 0x0092A2 1
2.2.2.2 2.2.2.2 1437 0x80000006 0x006991 2
3.3.3.3 3.3.3.3 90 0x80000007 0x0032A8 2
4.4.4.4 4.4.4.4 1293 0x80000004 0x00AD0A 3
Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
192.168.13.1 1.1.1.1 1186 0x80000004 0x00E8C2
192.168.24.2 2.2.2.2 1437 0x80000002 0x009FF5
192.168.34.3 3.3.3.3 1357 0x80000002 0x002B57
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
192.168.12.0 1.1.1.1 1446 0x80000002 0x009721
192.168.12.0 2.2.2.2 1437 0x80000003 0x00773C
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
1.1.1.1 1.1.1.1 1446 0x80000002 0x0099FD 0Обратите внимание, что LSA от R1 может отозвать только тот, кто их сгенерировал. Связность в двунаправленном графе нарушена (ребро между R1 и R3 анонсировано только R1 в «старом» LSA1), поэтому 1.1.1.1/32 недоступен через R3. Детали построения графа из LSA я описывал в одной из предыдущих статей. Впрочем, тайна пропавшего LSA всё ещё не раскрыта.
Хэппи-энда, однако, не будет: R2 никогда не сгенерирует LSA5 согласно RFC 1587 (да и RFC 3101 тоже):
If a router is attached to another AS and is also an NSSA area border router, it may originate a both a type-5 and a type-7 LSA for the same network. The type-5 LSA will be flooded to the backbone (and all attached type-5 capable areas) and the type-7 will be flooded into the NSSA. If this is the case, the P-bit must be reset in the type-7 NSSA so the type-7 LSA isn’t again translated into a type-5 LSA by another NSSA area border router.
Вольный перевод:
Если маршрутизатор граничит с другой AS и является ABR в NSSA зоне, он может создать type-5 и type-7 LSA для одного и того же префикса. Type-5 LSA распространится по backbone зоне (а также по другим зонам, способным обработать type-5), тогда как type-7 будет использован в рамках NSSA. В этом случае P-bit должен быть очищен в type-7 NSSA, чтобы предотвратить трансляцию type-7 LSA в type-5 LSA другим NSSA ABR.
Вы уже наверняка догадались, что это именно наш случай (опция No Type 7/5 translation):
R2#show ip ospf database nssa-external
OSPF Router with ID (2.2.2.2) (Process ID 1)
Type-7 AS External Link States (Area 1)
Routing Bit Set on this LSA in topology Base with MTID 0
LS age: 248
Options: (No TOS-capability, No Type 7/5 translation, DC, Upward)
LS Type: AS External Link
Link State ID: 1.1.1.1 (External Network Number )
Advertising Router: 1.1.1.1
LS Seq Number: 80000005
Checksum: 0x771B
Length: 36
Network Mask: /32
Metric Type: 2 (Larger than any link state path)
MTID: 0
Metric: 20
Forward Address: 0.0.0.0
External Route Tag: 0Вывод? Не стоит усложнять использование и без того перегруженного протокола. Если же этого не избежать, то стоит придерживаться дизайнов, описанных вендорами, тестировать всё, до чего дотянутся руки, а также не отклоняться от этих двух принципов — на кону стабильность инфраструктуры и её поддержка вендором.
Спасибо за рецензию: Анастасии Куралёвой
Канал в Телеграме: https://t.me/networking_it_ru
