Как следует из названия статьи, сегодня мы займёмся некой функцией, которая включена по умолчанию на большинстве платформ Cisco IOS. Преследуемых целей две: встать на грабли, а потом выяснить их модель (производитель уже известен).
Топология лабы представлена ниже:
Все маршрутизаторы на схеме – это Cisco 7200 с прошивкой 15.2(4)M11. R3 выполняет роль конечного устройства (например, сервера), а R4 притворяется интернетом. Фильтр для соединения R1-Switch1 вносит дополнительную задержку для проходящего через него трафика. Актуальные выдержки из настроек маршрутизаторов:
R4(config)# interface Loopback0
R4(config-if)# ip address 4.4.4.4 255.255.255.255
R4(config)# interface FastEthernet1/0
R4(config-if)# ip address 192.168.14.4 255.255.255.0
R4(config)# router eigrp 1
R4(config-router)# network 0.0.0.0
R3(config)# interface FastEthernet0/0
R3(config-if)# ip address 192.168.0.3 255.255.255.0
R3(config)# ip route 0.0.0.0 0.0.0.0 192.168.0.1
R2(config)# interface FastEthernet0/0
R2(config-if)# ip address 192.168.0.2 255.255.255.0
R2(config)# interface FastEthernet0/1
R2(config-if)# ip address 192.168.12.2 255.255.255.0
R2(config)# router eigrp 1
R2(config-router)# network 0.0.0.0
R2(config)# interface FastEthernet0/0
R2(config-if)# ip address 192.168.0.1 255.255.255.0
R2(config)# interface FastEthernet0/1
R2(config-if)# ip address 192.168.12.1 255.255.255.0
R4(config)# interface FastEthernet1/0
R4(config-if)# ip address 192.168.14.1 255.255.255.0
R2(config)# router eigrp 1
R2(config-router)# network 0.0.0.0
В неопределённый момент в прошлом R2 был выключен, и сейчас его вернули снова в строй. Инженер наблюдает большой поток однонаправленного трафика из интернета в сторону R3, причём этот трафик чувствителен к задержкам. Канал между R1 и Switch1 оказывается перегружен, поэтому инженер принимает решение перенаправить проблемный поток через R2. Обратный трафик в сторону интернета незначителен, так что R1 остаётся на время единственным шлюзом по умолчанию.
Самый очевидный способ завернуть трафик для R3 в сторону R2 – статический маршрут на R1:
- R1 шлёт трафик для R3 через R2 согласно /32 маршруту;
- R2 использует локальный /24 маршрут, чтобы передать трафик R3.
Сказано – сделано:
R1(config)# ip route 192.168.0.3 255.255.255.255 192.168.12.2
Однако, как только инженер внёс необходимые изменения, R3 полностью пропал с радаров:
R3#ping 4.4.4.4
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 4.4.4.4, timeout is 2 seconds:
..…
Success rate is 0 percent (0/5)
R4#ping 192.168.0.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.3, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
.....
Success rate is 0 percent (0/5)
Ближайшие 2 маршрутизатора, R1 и R2, также недоступны:
R3#ping 192.168.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
R3#ping 192.168.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Никаких проблем на Switch1 не зафиксировано, CAM-таблица содержит в себе корректную информацию. Запустим traceroute на R3 и R4:
R3#traceroute 4.4.4.4
Type escape sequence to abort.
Tracing the route to 4.4.4.4
VRF info: (vrf in name/id, vrf out name/id)
1 * * *
2 * * *
3 * * *
<output trimmed>
R4#traceroute 192.168.0.3 source loopback 0
Type escape sequence to abort.
Tracing the route to 192.168.0.3
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.14.1 16 msec 12 msec 8 msec
2 192.168.12.2 20 msec 20 msec 20 msec
3 192.168.0.1 1388 msec 1300 msec 1296 msec
4 192.168.12.2 1420 msec 1296 msec 1300 msec
5 192.168.0.1 2696 msec 2604 msec 2696 msec
6 192.168.12.2 2612 msec 2704 msec 2696 msec
<output trimmed>
Очевидно, что в сеть прокралась петля – R2 сошёл с ума и шлёт трафик обратно на R1. Каких-либо конкретных симптомов, впрочем, обнаружить не удаётся; IP адрес попадает в connected сеть, R2 выполняет ARP-запрос и обрабатывает последующий ARP-ответ:
R2#sho ip cef 192.168.0.3
192.168.0.3/32
attached to FastEthernet0/0
R2#sho adjacency 192.168.0.3
Protocol Interface Address
IP FastEthernet0/0 192.168.0.3(7)
Маршрутизация в полном порядке, поэтому займёмся последней милей:
R2#sho ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.0.1 53 ca01.221b.0008 ARPA FastEthernet0/0
Internet 192.168.0.2 - ca02.224b.0008 ARPA FastEthernet0/0
Internet 192.168.0.3 54 ca01.221b.0008 ARPA FastEthernet0/0
Internet 192.168.12.1 55 ca01.221b.0006 ARPA FastEthernet0/1
Internet 192.168.12.2 - ca02.224b.0006 ARPA FastEthernet0/1
Коллеги, видите ли вы что-то странное? Всё верно, 192.168.0.1 и 192.168.0.3 соответствуют одному и тому же MAC адресу, ca01.221b.0008, который принадлежит R1. Запахло жуками, поэтому попробуем очистить ARP-таблицу в надежде, что проблема исчерпает себя:
R2#clear arp
R2#sho ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.0.1 0 ca01.221b.0008 ARPA FastEthernet0/0
Internet 192.168.0.2 - ca02.224b.0008 ARPA FastEthernet0/0
Internet 192.168.0.3 0 ca01.221b.0008 ARPA FastEthernet0/0
Internet 192.168.12.1 0 ca01.221b.0006 ARPA FastEthernet0/1
Internet 192.168.12.2 - ca02.224b.0006 ARPA FastEthernet0/1
Слишком настойчивый баг, не находите? Напоминание для тех, кто ожидал увидеть пустую таблицу, а не нулевой возраст записей: при очистке ARP-таблицы IOS шлёт unicast (да-да) ARP запросы, чтобы обновить соответствующие записи. Выключение и включение интерфейса на R2, впрочем, даёт лучик надежды:
R4#ping 192.168.0.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.3, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
...!.
Похоже, что изначально трафик ведёт себя так, как и было задумано; однако впоследствии что-то нарушает желаемый порядок вещей, переписывая на R2 ARP запись для R3 на MAC адрес, принадлежащий R1.
Помните настройку по умолчанию, связанную с ARP, которую обычно рекомендуют отключать? Да, речь о Proxy ARP, который мог предоставить связность для устройств без шлюза по умолчанию или с некорректной настройкой маски подсети:
Since the router knows that the target address (172.16.20.200) is on another subnet and can reach Host D, it replies with its own MAC address to Host A.
Вольный перевод:
Поскольку маршрутизатор знает, что целевой адрес (172.16.20.200) находится в другой подсети, он отвечает собственным MAC адресом на запрос Host A.
Впрочем, это лишь первая половина загадки; вторая относится к тому, как положено обрабатывать ARP пакеты. Согласно RFC826, сообщения ARP могут быть использованы для двух целей:
- обновление существующей ARP записи;
- создание новой ARP записи на том устройстве, которое послало ARP запрос.
В нашем случае это означает, что ARP ответ R1 от лица R3 не может создать новую запись в ARP таблице на R2; к сожалению, это также означает, что R1 может «обновить» соответствующую запись. Получается следующая последовательность событий:
- R2 получает пакет, предназначенный для R3, но не находит нужной ARP записи;
- R2 посылает ARP запрос и получает корректный ARP ответ от R3, что проявляется в краткосрочной связности для R3;
- поскольку ARP запрос является широковещательным, R1 также получает ARP запрос от R2 после определённой задержки на канале R1-Switch1;
- в таблице маршрутизации на R1 присутствует 192.168.0.3/32, что активирует ARP ответ в рамках Proxy ARP, т.к. R1 считает, что 192.168.0.3 находится в другой подсети;
- ARP ответ от R1 достигает R2 позже, чем ARP ответ от R3, благополучно переписывая ARP запись на R2 для R3, используя MAC адрес R1;
- Петля маршрутизации, приятно познакомиться.
Проверим, что дело действительно в Proxy ARP и его отключение разрешит проблему:
R1(config)#int f0/0
R1(config-if)#no ip proxy-arp
R2#clear arp
R4#ping 192.168.0.3 source loopback 0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.0.3, timeout is 2 seconds:
Packet sent with a source address of 4.4.4.4
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 116/120/124 ms
R2#sho ip arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 192.168.0.1 1 ca01.221b.0008 ARPA FastEthernet0/0
Internet 192.168.0.2 - ca02.224b.0008 ARPA FastEthernet0/0
Internet 192.168.0.3 1 ca03.225a.0008 ARPA FastEthernet0/0
Internet 192.168.12.1 1 ca01.221b.0006 ARPA FastEthernet0/1
Internet 192.168.12.2 - ca02.224b.0006 ARPA FastEthernet0/1
Наконец, решение в виде статического маршрута заработало. Может показаться, что причина такого некорректного поведения – неисправный канал R1-Switch1 и что в современной сети рассмотренная проблема невозможна. Однако если учесть длину L2 сегмента и задержки, вносимые оборудованием, становится очевидно, что ARP ответ от Proxy ARP может случайным образом прийти позже корректного ARP ответа, что приведёт к недоступности соответствующего хоста. Современные сети действительно построены без опоры на асимметричную маршрутизацию на шлюзе по умолчанию. Однако вряд ли даже в таких сетях кто-то сможет дать гарантию, что все возможные сценарии учтены и не придётся впоследствии вносить изменения, противоречащие, хотя бы и на непродолжительное время, общему духу симметричной маршрутизации. Вывод: стоит отключить Proxy ARP, если он не выполняет критических задач.
Статья вдохновлена книгой Routing TCP/IP, Volume 1, 2nd Edition, особенно разделом про отладку статических маршрутов.
