EIGRP named mode: засада с миграцией / forpes.ru

Главная
EIGRP named mode: засада с миграцией

EIGRP named mode: засада с миграцией +1

25.04.2023 16:16

braonle 0 734 Источник

Представим, что у вас появилось непреодолимое желание обновить ПО в сети до самой последней версии, а также внедрить все мыслимые и немыслимые best practice (вы ещё не вышли на рынок труда, пока что). Первый подопытный кролик – EIGRP в классическом режиме: его нужно во что бы то ни стало перевести в named режим, потому что вы прямо кушать не можете без его новых функций. Более того, достаточно одного росчерка пера в виде команды eigrp upgrade-cli – что может пойти не так? Как вы могли догадаться по предыдущим статьям, такой сценарий вполне может оставить вас у разбитой сети при неудачном стечении обстоятельств.

Что может быть проще сети из четырёх маршрутизаторов? Именно, сеть из трех! Каждое из устройств участвует в EIGRP, на R1 и R3 настроен классический режим, а вот R2 только что очнулся новым маршрутизатором с named режимом.

R1#show run | section router eigrp|interface
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
router eigrp 1
 network 0.0.0.0

R3#show run | section router eigrp|interface
interface Loopback0
 ip address 3.3.3.3 255.255.255.255
interface FastEthernet0/1
 ip address 192.168.23.3 255.255.255.0
router eigrp 1
 network 0.0.0.0

R2#show run | section router eigrp|interface
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
interface FastEthernet0/1
 ip address 192.168.23.2 255.255.255.0
router eigrp NAMED
 address-family ipv4 unicast autonomous-system 1
  network 0.0.0.0

На данном этапе поведение сети предсказуемо – связность R1 и R3 в полном порядке:

R3#show ip route eigrp
<output omitted>
      1.0.0.0/32 is subnetted, 1 subnets
D        1.1.1.1 [90/158720] via 192.168.23.2, 00:03:32, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
D        2.2.2.2 [90/28160] via 192.168.23.2, 00:03:37, FastEthernet0/1
D     192.168.12.0/24 [90/30720] via 192.168.23.2, 00:03:37, FastEthernet0/1
R3#  
R3#ping 1.1.1.1 source lo 0
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 3.3.3.3 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/28/36 ms

Остаётся лишь ввести upgrade-cli на остальных маршрутизаторах, но не тут-то было: получен срочный запрос на снижение приоритета 1.1.1.1/32 для каких-то там манипуляций с трафиком. Мелочь, скажете вы, и будете правы: нужно всего лишь поправить bandwidth на интерфейсе:

R1(config)# interface lo0
R1(config-if)# bandwidth ?
  <1-10000000>   Bandwidth in kilobits
  inherit        Specify how bandwidth is inherited
  qos-reference  Reference bandwidth for QOS test
  receive        Specify receive-side bandwidth

R1(config-if)# bandwidth 1

БУМ! R3 потерял связность с R1:

R3#ping 1.1.1.1 so lo 0
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 3.3.3.3 
UUUUU
Success rate is 0 percent (0/5)
R3#
R3#show ip route eigrp 
<output omitted>
      1.0.0.0/32 is subnetted, 1 subnets
D        1.1.1.1 [90/2560133120] via 192.168.23.2, 00:00:56, FastEthernet0/1
      2.0.0.0/32 is subnetted, 1 subnets
D        2.2.2.2 [90/28160] via 192.168.23.2, 00:09:42, FastEthernet0/1
D     192.168.12.0/24 [90/30720] via 192.168.23.2, 00:09:42, FastEthernet0/1

По всем правилам отладки дело должно быть в EIGRP, однако маршрут всё ещё находится в RIB, причём уже с новой метрикой:

R3#traceroute 1.1.1.1 source lo0 numeric 
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.23.2 12 msec 16 msec 16 msec
  2 192.168.23.2 !H  !H  !H

В то же время R2 прилежно игнорирует попытки пропихнуть через него трафик, потому что...

R2#show ip route eigrp
<output omitted>
      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/2662400] via 192.168.23.3, 00:14:07, FastEthernet0/1

Он потерял маршрут! Впрочем, потеря маршрута не настолько тотальная, как может показаться на первый взгляд. Префикс всё ещё в таблице EIGRP, причём так же с обновлёнными компонентами метрики:

R2#show ip eigrp topology 1.1.1.1/32
EIGRP-IPv4 VR(NAMED) Topology Entry for AS(1)/ID(2.2.2.2) for 1.1.1.1/32
  State is Passive, Query origin flag is 1, 0 Successor(s), FD is Infinity, RIB is 4294967295
  Descriptor Blocks:
  192.168.12.1 (FastEthernet0/0), from 192.168.12.1, Send flag is 0x0
      Composite metric is (655694233600/655687680000), route is Internal
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 5100000000 picoseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
        Originating router is 1.1.1.1

Данные маршрутизации, похоже, в порядке. На данном этапе у нас две загадки:

Почему R2 потерял маршрут?
Почему R3 НЕ потерял маршрут?

Решение первого вопроса прямо связано с восстановлением связности, поэтому в первую очередь займёмся именно им. Заметили что-нибудь необычное у метрики EIGRP? Она существенно больше “RIB is 4294967295” – верхней границы 32-битной метрики RIB. EIGRP не может впихнуть 64-битную метрику в 32 бита, поэтому маршрут и не попадает в таблицу маршрутизации. Решение? Уменьшить метрику до удобоваримого размера, поделив на некий параметр metric rib-scale, равный 128 по умолчанию:

R2#show ip protocols 
Routing Protocol is "eigrp 1"
  Outgoing update filter list for all interfaces is not set
  Incoming update filter list for all interfaces is not set
  Default networks flagged in outgoing updates
  Default networks accepted from incoming updates
  EIGRP-IPv4 VR(NAMED) Address-Family Protocol for AS(1)
    Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
    Metric rib-scale 128
    Metric version 64bit
    NSF-aware route hold timer is 240
    Router-ID: 2.2.2.2
    Topology : 0 (base) 
      Active Timer: 3 min
      Distance: internal 90 external 170
      Maximum path: 4
      Maximum hopcount 100
      Maximum metric variance 1
      Total Prefix Count: 5
      Total Redist Count: 0

  Automatic Summarization: disabled
  Maximum path: 4
  Routing for Networks:
    0.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.12.1          90      00:17:36
    192.168.23.3          90      00:17:36
  Distance: internal 90 external 170

Как ни странно, коэффициента, равного 128, не хватает, чтобы привести метрику в 32-битные границы, а вот 160 уже подходит:

R2(config)#router eigrp NAMED  
R2(config-router)#address-family ipv4 autonomous-system 1
R2(config-router-af)#metric rib-scale 160

R2#show ip route eigrp 
<output omitted>
      1.0.0.0/32 is subnetted, 1 subnets
D        1.1.1.1 [90/4098088960] via 192.168.12.1, 00:00:49, FastEthernet0/0
      3.0.0.0/32 is subnetted, 1 subnets
D        3.3.3.3 [90/2129920] via 192.168.23.3, 00:00:49, FastEthernet0/1

R3 снова может добраться до 1.1.1.1/32:

R3#ping 1.1.1.1 so lo 0                  
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 3.3.3.3 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/32/52 ms

Итак, первая тайна разгадана. Что насчёт второй: с какого перепугу R3 сохранил маршрут после того, как тот пропал на R2? Вопрос далеко не праздный: такое поведение легко может спровоцировать неверный вывод о том, что маршрутизация в порядке, так как нужный маршрут установлен в RIB.

При пропаже всех successor для маршрута EIGRP запускает процесс синхронизации, известный как DUAL. Наш случай не исключение, поэтому присмотримся к сообщениям между R2 и R3 в этот момент:

R2 теряет successor для 1.1.1.1/32 из-за полученного Query от R1, поэтому R2 шлёт R3 свой собственный Query.

Обратите внимание на метрику: задержка равна действительной величине на R2, а не константе Infinity.

R3 обновляет свою таблицу EIGRP, сохраняя новые значения компонентов метрики:

R3#show ip eigrp topology 1.1.1.1/32
EIGRP-IPv4 Topology Entry for AS(1)/ID(3.3.3.3) for 1.1.1.1/32
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2560133120
  Descriptor Blocks:
  192.168.23.2 (FastEthernet0/1), from 192.168.23.2, Send flag is 0x0
      Composite metric is (2560133120/2560130560), route is Internal
      Vector metric:
        Minimum bandwidth is 1 Kbit
        Total delay is 5200 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 2
        Originating router is 1.1.1.1

Каких-либо альтернатив R2 в роли successor у R3 нет, как нет и других соседей для дальнейшего опроса через Query, поэтому R3 отвечает на Query метрикой Infinity вследствие split horizon:

R2 получает Reply на все отправленные Query, так что теперь он может выбрать маршрут без петель маршрутизации. Единственный маршрут в наличии не лезет в RIB, поэтому на нет и суда нет.

Занятно следующее: если дёрнуть настройки RIB scale таким образом, чтобы R2 потерял уже установленный в RIB маршрут, то R2 шлёт «правильный» Query, сигнализируя о пропаже префикса:

Причина разной обработки событий, мне кажется, довольно проста: первоначальный Query вызван получением Query от successor R1 до попытки обновить RIB (нет причины указывать Infinity в качестве метрики); второй же Query происходит после потери маршрута с точки зрения таблицы маршрутизации. Первый Query не может сам по себе инициировать обновление RIB, потому что маршрутную информацию нужно вначале актуализировать через DUAL. Я бы предположил два возможных решения этой проблемы:

слать Update с метрикой Infinity после неудачной попытки установить маршрут в RIB
или
всегда слать Query с метрикой Infinity согласно EIGRP RFC.

Вероятен ли такой сценарий отказа? Сомнительно, всё-таки в современных сетях сложно получить настолько большую метрику, чтобы она не поместилась в 32 бита. Сценарий, тем не менее, вполне реален, особо вкупе с неряшливым управлением трафиком. Впрочем, защита от подобных инцидентов широко известна – это пилотное тестирование, окна для проведения работ, плюс автоматизированные проверки до и после внедрения изменений.

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

EIGRP named mode: засада с миграцией +1

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