28.11.2023 12:38
braonle 1 4500 Источник

В интернете можно найти множество статей, которые демонстрируют, что мудрёный дизайн с использованием 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

Комментарии (1)


  1. donlocura
    29.11.2023 10:51
    #26210802
    +1

    Тут проблема больше не в NSSA, а в схеме сети, т.к. протокол предполагает схему соединения area типа 'звезда', т.е. backbone в центре, а остальные area контактируют только с ней (возможно, через транзит). Достаточно разделить NSSA зону на две или объединить две другие не backbone зоны в одну - проблемы не будет. Но, если прицелиться себе в ногу и нажать на курок - выстрел произойдет)