OSPF 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 subnets

R2#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 0

R3#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 0

R4#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:

1. основной – через R3, благодаря LSA5, созданному R1;

2. запасной – через 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 shutdown

R4#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