Представим, что у вас появилось непреодолимое желание обновить ПО в сети до самой последней версии, а также внедрить все мыслимые и немыслимые 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.0R3#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.0R2#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 160R2#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/1R3 снова может добраться до 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
