23.12.2022 17:10
braonle 0 1200 Источник

Не так давно я рассказал про одну из причин появления RFC 2328 на смену RFC 1583. Впрочем, описанный сценарий возникновения петли маршрутизации совсем не единственный. Те из вас, кто посмотрел на RFC 2178, скорее всего, уже догадываются, о чем пойдёт речь дальше.

Помимо изменения метрики агрегированных маршрутов, RFC 2328 также изменил процесс выбора лучшего маршрута для внешних префиксов.

Otherwise, compare the cost of this new AS external path to the ones present in the table. Type 1 external paths are always shorter than type 2 external paths. Type 1 external paths are compared by looking at the sum of the distance to the forwarding address and the advertised type 1 metric (X+Y). Type 2 external paths are compared by looking at the advertised type 2 metrics, and then if necessary, the distance to the forwarding addresses.

RFC 1583, section 16.4

Compare the AS external path described by the LSA with the existing paths in N's routing table entry, as follows. If the new path is preferred, it replaces the present paths in N's routing table entry. If the new path is of equal preference, it is added to N's routing table entry's list of paths.

(a) Intra-area and inter-area paths are always preferred over AS external paths.

(b) Type 1 external paths are always preferred over type 2 external paths. When all paths are type 2 external paths, the paths with the smallest advertised type 2 metric are always preferred.

(c) If the new AS external path is still indistinguishable from the current paths in the N's routing table entry, and RFC1583Compatibility is set to "disabled", select the preferred paths based on the intra-AS paths to the ASBR/forwarding addresses, as specified in Section 16.4.1.

(d) If the new AS external path is still indistinguishable from the current paths in the N's routing table entry, select the preferred path based on a least cost comparison. Type 1 external paths are compared by looking at the sum of the distance to the forwarding address and the advertised type 1 metric (X+Y). Type 2 external paths advertising equal type 2 metrics are compared by looking at the distance to the forwarding addresses.

RFC 2328, section 16.4

1. Intra-area paths using non-backbone areas are always the most preferred.
2. The other paths, intra-area backbone paths and inter-area paths, are of equal preference.

RFC 2328, section 16.4.1

Вместо прямого перевода я предпочту обобщить суть различий:

  1. RFC 1583 сравнивает одинаковые маршруты от разных ASBR сугубо по метрике.

  2. RFC 2328, в свою очередь, отдаёт предпочтение ASBR, находящимся внутри той же неопорной зоны; если сделать выбор всё ещё не удалось, тогда OSPF сравнивает метрики до ASBR так же, как и RFC 1583.

Получается, что нас интересуют следующие элементы выбора лучшего маршрута:

  1. приоритет ASBR, находящихся в той же неопорной зоне;

  2. равенство ASBR, находяшихся в зоне 0, и ASBR из других зон.

Рассмотрим простой сценарий:

ASBR обмениваются несколькими префиксами с узлом BGP: получают 1.1.1.1/32 и анонсируют 3.3.3.3/32. Помимо этого, ASBR объявляют маршрут по умолчанию в OSPF домен. Два соединения имеют нестандартный вес, их значения отмечены красным цветом. Остальная настройка не представляет существенного интереса, все значения оставлены по умолчанию – только ловкость рук и никакой магии.

BGP#sho run | section interface|router
interface Loopback0
 ip address 1.1.1.1 255.255.255.255
interface FastEthernet0/0
 ip address 192.168.16.1 255.255.255.0
interface FastEthernet0/1
 ip address 192.168.12.1 255.255.255.0
router bgp 1
 no bgp default ipv4-unicast
 neighbor 192.168.12.2 remote-as 100
 neighbor 192.168.16.6 remote-as 100
 !
 address-family ipv4
  network 1.1.1.1 mask 255.255.255.255
  neighbor 192.168.12.2 activate
  neighbor 192.168.16.6 activate
ASBR1#sho run | s interface|router
interface Loopback0
 ip address 2.2.2.2 255.255.255.255
 ip ospf 1 area 0
interface FastEthernet0/0
 ip address 192.168.23.2 255.255.255.0
 ip ospf 1 area 0
 ip ospf cost 10
interface FastEthernet0/1
 ip address 192.168.12.2 255.255.255.0
router ospf 1
 default-information originate always
router bgp 100
 no bgp default ipv4-unicast
 neighbor 192.168.12.1 remote-as 1
 !
 address-family ipv4
  network 3.3.3.3 mask 255.255.255.255
  neighbor 192.168.12.1 activate
ASBR2#sho run | section interface|router
interface Loopback0
 ip address 6.6.6.6 255.255.255.255
 ip ospf 1 area 1
interface FastEthernet0/0
 ip address 192.168.16.6 255.255.255.0
interface FastEthernet0/1
 ip address 192.168.56.6 255.255.255.0
 ip ospf 1 area 1
interface FastEthernet1/0
 ip address 192.168.46.6 255.255.255.0
 ip ospf 1 area 1
 ip ospf cost 100
router ospf 1
 default-information originate always
router bgp 100
 no bgp default ipv4-unicast
 neighbor 192.168.16.1 remote-as 1
 !
 address-family ipv4
  network 3.3.3.3 mask 255.255.255.255
  neighbor 192.168.16.1 activate
ABR1#sho run | section interface|router
interface Loopback0
 ip address 4.4.4.4 255.255.255.255
 ip ospf 1 area 0
interface FastEthernet0/0
 ip address 192.168.45.4 255.255.255.0
 ip ospf 1 area 0
interface FastEthernet0/1
 ip address 192.168.34.4 255.255.255.0
 ip ospf 1 area 0
interface FastEthernet1/0
 ip address 192.168.46.4 255.255.255.0
 ip ospf 1 area 1
 ip ospf cost 100
router ospf 1
ABR2#sho run | section interface|router
interface Loopback0
 ip address 5.5.5.5 255.255.255.255
 ip ospf 1 area 0
interface FastEthernet0/0
 ip address 192.168.45.5 255.255.255.0
 ip ospf 1 area 0
interface FastEthernet0/1
 ip address 192.168.56.5 255.255.255.0
 ip ospf 1 area 1
router ospf 1
R#sho run | section interface|router
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
interface FastEthernet0/0
 ip address 192.168.23.3 255.255.255.0
 ip ospf cost 10
interface FastEthernet0/1
 ip address 192.168.34.3 255.255.255.0
router ospf 1
 network 0.0.0.0 255.255.255.255 area 0

Может показаться, что при такой невинной настройке узел BGP должен иметь связность до 3.3.3.3/32, устанавливая соединение с использованием 1.1.1.1/32 в качества адреса источника.

BGP#ping 3.3.3.3 so lo 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1 
.....
Success rate is 0 percent (0/5)

Что, впрочем, совершенно не мешает сети добросовестно терять трафик. Может быть, где-то по пути не хватает маршрутов?

BGP#traceroute 3.3.3.3 source 1.1.1.1
Type escape sequence to abort.
Tracing the route to 3.3.3.3
VRF info: (vrf in name/id, vrf out name/id)
  1 192.168.16.6 12 msec 24 msec 20 msec
  2 192.168.56.5 56 msec 16 msec 36 msec
  3  *  *  * 
<output omitted>

Похоже на то, что ABR1 отбрасывает приходящие к нему пакеты. Однако первое впечатление обманчиво, особенно если запустить traceroute с другой стороны:

R#traceroute 1.1.1.1 source 3.3.3.3
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.4 16 msec 16 msec 20 msec
  2 192.168.34.3 20 msec 24 msec 16 msec
  3 192.168.34.4 32 msec 36 msec 40 msec
  4 192.168.34.3 36 msec 40 msec 36 msec
<ну вы поняли>

Если посмотреть на схему, то выбор маршрута по умолчанию в сторону ASBR2 маршрутизатором R выглядит разумным: 

R#sho ip ospf border-routers    

            OSPF Router with ID (3.3.3.3) (Process ID 1)


		Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 4.4.4.4 [1] via 192.168.34.4, FastEthernet0/1, ABR, Area 0, SPF 12
i 5.5.5.5 [2] via 192.168.34.4, FastEthernet0/1, ABR, Area 0, SPF 12
i 2.2.2.2 [10] via 192.168.23.2, FastEthernet0/0, ASBR, Area 0, SPF 12
I 6.6.6.6 [3] via 192.168.34.4, FastEthernet0/1, ASBR, Area 0, SPF 12
I 6.6.6.6 [101] via 192.168.34.4, FastEthernet0/1, ASBR, Area 0, SPF 12

А вот ABR1 ведёт себя несколько странно, по крайней мере на первый взгляд:

ABR1#sho ip ospf border-routers 

            OSPF Router with ID (4.4.4.4) (Process ID 1)


		Base Topology (MTID 0)

Internal Router Routing Table
Codes: i - Intra-area route, I - Inter-area route

i 5.5.5.5 [101] via 192.168.46.6, FastEthernet1/0, ABR, Area 1, SPF 8
i 5.5.5.5 [1] via 192.168.45.5, FastEthernet0/0, ABR, Area 0, SPF 9
i 2.2.2.2 [11] via 192.168.34.3, FastEthernet0/1, ASBR, Area 0, SPF 9
i 6.6.6.6 [100] via 192.168.46.6, FastEthernet1/0, ASBR, Area 1, SPF 8

Обратите пристальное внимание на значение метрики до ASBR2 с точки зрения обоих маршрутизаторов. R выбирает путь через ABR2 с весом, равным 3; в свою очередь, ABR1 не имеет ни малейшего представления о маршруте через ABR2 и видит только путь с весом, равным 101. Причина такого поведения прозаична: ASBR2 и ABR1 находятся в одной зоне, поэтому ABR1 обязан использовать внутризональный маршрут. Как следствие, предпочтительность ASBR в очередной раз меняется по пути следования пакета, что и приводит к петле маршрутизации.

Переключим все маршрутизаторы домена в режим совместимости с RFC 2328:

R(config)#router ospf 1
R(config-router)#no compatible rfc1583
R#traceroute 1.1.1.1 so 3.3.3.3
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.4 20 msec 32 msec 12 msec
  2 192.168.46.6 12 msec 20 msec 8 msec
  3 192.168.16.1 4 msec 28 msec 16 msec
ABR1#sho ip ro os                              
<output omitted>
Gateway of last resort is 192.168.46.6 to network 0.0.0.0

O*E2  0.0.0.0/0 [110/1] via 192.168.46.6, 00:02:00, FastEthernet0/1
<output omitted>

Несмотря на то, что нам удалось побороть петлю, маршрутизация стала неоптимальной. R считает маршруты до ASBR1 (внутри опорной зоны) и ASBR2 (межзональный) равноценными, поэтому сравнивает их только по метрике. Не лучше ли было отдать предпочтение маршруту внутри опорной зоны? Именно так и думали авторы RFC 2178:

1. Intra-area paths using non-backbone areas are always the most preferred.
2. Otherwise, intra-area backbone paths are preferred.
3. Inter-area paths are the least preferred.

RFC 2178, section 16.4.1

Впрочем, нашлась весомая причина использовать текущий процесс выбора лучшего маршрута:

There is still the possibility of a routing loop in RFC 2178 when both

1. virtual links are in use and
2. the same external route is being imported by multiple ASBRs, each of which is in a separate area.

To fix this problem, Section 16.4.1 has been revised. To choose the correct ASBR/forwarding address, intra-area paths through non-backbone areas are always preferred. However, intra-area paths through the backbone area (Area 0) and inter-area paths are now of equal preference, and must be compared solely based on cost.

The reasoning behind this change is as follows. When virtual links are in use, an intra-area backbone path for one router can turn into an inter-area path in a router several hops closer to the destination. Hence, intra-area backbone paths and inter-area paths must be of equal preference. We can safely compare their costs, preferring the path with the smallest cost, due to the calculations in Section 16.3.

RFC 2328, section G.2

Насколько мне известно, реализаций OSPF в соответствии с RFC 2178 в природе не существует. Тут на помощь может прийти богатое воображение. Рассмотрим такую схему:

Процесс выбора по RFC 2178:

  1. R1 сравнивает ASBR1 из другой зоны с ASBR2 в опорной зоне (через virtual-link).

  2. ASBR2 в опорной зоне лучше, поэтому R1 шлёт пакет ему.

  3. R2 сравнивает ASBR1 и ASBR2, каждый из которых находится в другой зоне.

  4. ASBR1 ближе, поэтому R2 отправляет ему пакет – назад в сторону R1.

Процесс выбора по RFC 2328:

  1. R1 сравнивает ASBR1 из другой зоны с ASBR2 в опорной зоне и считает их равноценными.

  2. R1 сравнивает метрики до ASBR1 (2) и ASBR2 (13).

  3. ASBR1 ближе, поэтому R1 отправляет ему пакет через ABR2.

Корень зла в описанных сценариях – понижение приоритета ASBR по пути следования пакета. RFC 2328 исключает такие ситуации ценой неоптимальной маршрутизации. Авторы RFC посчитали, что неэффективный путь обычно лучше отсутствующего.

OSPF – достаточно сложный протокол с ограниченной гибкостью. Конечно, до определённой степени его поведение можно оптимизировать, однако нужно очень хорошо понимать последствия, чтобы не попасть впросак. В целом, принцип KISS как нельзя лучше подходит к OSPF. Если же необходим более гибкий протокол, выбор очевиден: вам нужен или BGP, или сетевой архитектор получше.

Спасибо за рецензию: Анастасии Куралёвой

Канал в Телеграме: https://t.me/networking_it_ru

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