Звезда не активнаЗвезда не активнаЗвезда не активнаЗвезда не активнаЗвезда не активна
 

Как следует из названия статьи, сегодня мы займёмся некой функцией, которая включена по умолчанию на большинстве платформ 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:

  1. R1 шлёт трафик для R3 через R2 согласно /32 маршруту;
  2. 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 могут быть использованы для двух целей:

  1. обновление существующей ARP записи;
  2. создание новой ARP записи на том устройстве, которое послало ARP запрос.

В нашем случае это означает, что ARP ответ R1 от лица R3 не может создать новую запись в ARP таблице на R2; к сожалению, это также означает, что R1 может «обновить» соответствующую запись. Получается следующая последовательность событий:

  1. R2 получает пакет, предназначенный для R3, но не находит нужной ARP записи;
  2. R2 посылает ARP запрос и получает корректный ARP ответ от R3, что проявляется в краткосрочной связности для R3;
  3. поскольку ARP запрос является широковещательным, R1 также получает ARP запрос от R2 после определённой задержки на канале R1-Switch1;
  4. в таблице маршрутизации на R1 присутствует 192.168.0.3/32, что активирует ARP ответ в рамках Proxy ARP, т.к. R1 считает, что 192.168.0.3 находится в другой подсети;
  5. ARP ответ от R1 достигает R2 позже, чем ARP ответ от R3, благополучно переписывая ARP запись на R2 для R3, используя MAC адрес R1;
  6. Петля маршрутизации, приятно познакомиться.

Проверим, что дело действительно в 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, особенно разделом про отладку статических маршрутов.

Добавить комментарий


Защитный код
Обновить

Если заметили ошибку, выделите фрагмент текста и нажмите Ctrl+Enter