Протокол IP : Технология CEF

Устранение циклических маршрутов Cisco Express Forwarding

21 октября 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв


Содержание


Введение

Этот документ помогает устранять неполадки циклов маршрутизации технологии CEF и субоптимальной маршрутизации, вызванной допустимой кэшируемой смежностью скоростной маршрутизации Cisco, которая указывает на неверный интерфейс. Смежность с неверным интерфейсом создана из-за этих причин:

Предварительные условия

Требования

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

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Условные обозначения

Дополнительные сведения об условных обозначениях см. в документе Технические рекомендации Cisco. Условные обозначения.

Схема сети

Маршрутизатор R1 соединяется с R3 через Последовательный 8/0 и подключениями маршрутизатора R2 к R4 через Последовательный 8/0. R1 и R2 связаны через Ethernet 0/0, поскольку эти данные показывают.

/image/gif/paws/26083/trouble_cef_01.gif

  • R2 получает обновления префикса внешнего пограничного межсетевого протокола (eBGP) для 10.10.34.0/24 от R4. R2 распространяется этот префикс к R1 через внутренний BGP (iBGP).

  • R2 имеет статический маршрут по умолчанию (0.0.0.0/0), который указывает к Последовательному 8/0 IP-адресу R4 10.10.24.4.

  • R2 также имеет резервный плавающий маршрут по умолчанию (IP route 0.0.0.0 0.0.0.0 Ethernet0/0 10), который указывает к интерфейсу "Ethernet" 0/0 к маршрутизированным пакетам, если отказывает последовательное подключение между R2 и R4.

  • R1 имеет маршрут по умолчанию, который указывает к Последовательному 8/0 R3 с IP-адресом 10.10.13.3.

Проблема

IP - трафик, предназначенный для 10.10.34.0/24, циклично выполнен между R1 и R2. Наблюдайте выходные данные команды traceroute относительно R1.

R1#traceroute 10.10.34.4 
 
Type escape sequence to abort. 
Tracing the route to 10.10.34.4 
 
  1 192.168.12.2 20 msec 20 msec 20 msec 
  2 192.168.12.1 8 msec 12 msec 8 msec 
  3 192.168.12.2 8 msec 8 msec 12 msec 
  4 192.168.12.1 12 msec ...

Обратите внимание, что трафик, достигший 10.10.34.4 пересылается между R1s Ethernet 0/0 (IP-адрес 192.168.12.1) и R2s Ethernet 0/0 (IP-адрес 192.168.12.2). Идеально, трафик от R1, предназначенного для 10.10.34.0/24, должен перейти к R2 из-за iBGP изученный префикс 10.10.34.0/24. Затем от R2 трафик должен направить к R4. Однако выходные данные команды traceroute подтверждают цикл маршрутизации между R1 и R2.

_________________________ М1
hostname R1 
! 
ip subnet-zero 
! 
ip cef 
! 
interface Ethernet0/0 
 ip address 192.168.12.1 255.255.255.0 
! 
interface Serial8/0 
 ip address 10.10.13.1 255.255.255.0 
! 
router bgp 11 
 no synchronization 
 bgp log-neighbor-changes 
 neighbor 10.10.13.3 remote-as 12
 neighbor 192.168.12.2 remote-as 11 
 no auto-summary 
!  
ip route 0.0.0.0 0.0.0.0 10.10.13.3

R2
hostname  R2 
! 
ip cef 
! 
interface Ethernet0/0 
  ip address 192.168.12.2 255.255.255.0 
! 
interface Serial8/0 
 ip address 10.10.24.2 255.255.255.0 
! 
router bgp 11 
 no synchronization 
bgp log-neighbor-changes 
 network 192.168.12.0 
 neighbor 10.10.24.4 remote-as 10 
 neighbor 192.168.12.1 remote-as 11 
 neighbor 192.168.12.1 next-hop-self 
 no auto-summary 
! 
ip route 0.0.0.0 0.0.0.0 10.10.24.4 
ip route 0.0.0.0 0.0.0.0 Ethernet0/0 10 
!

Устранение неполадок

Так как пакеты, предназначенные для 10.10.34.4, циклично выполнены между R1 и R2, начните устранять неполадки. Первая проверка IP-маршрутизация на R1. Выходные данные команды show ip route 10.10.34.0 подтверждают следующий переход 192.168.12.2 для пакетов, предназначенных к 10.10.34.0/24. Это совпадает с командой traceroute, сначала скачкообразно двигаются, где пакеты переданы к следующему переходу 192.168.12.2, который подтверждает, что пакеты коммутированы правильно на R1.

R1#show ip route 10.10.34.0 
Routing entry for 10.10.34.0/24
  Known via "bgp 11", distance 200, metric 0
  Tag 10, type internal
  Last update from 192.168.12.2 00:22:59 ago
  Routing Descriptor Blocks:
  * 192.168.12.2, from 192.168.12.2, 00:22:59 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1

Следующий шаг – проверить таблицу IP-маршрутизации R2. Поскольку эти выходные данные команды show ip route 10.10.34.0 показывают, пакеты, предназначенные к 10.10.34.0, должны быть подняты с постели к следующему переходу 10.10.24.4 на Последовательном 8/0. Однако команда traceroute показывает пакеты, коммутированные назад к R1 к IP-адресу 192.168.12.1. Дополнительное исследование необходимо в то, почему пакеты, предназначенные к 10.10.34.0, коммутированы на R2 к следующему переходу 192.168.12.1 (как в выходных данных команды traceroute) вместо к 10.10.24.4.

R2#show ip route 10.10.34.0
Routing entry for 10.10.34.0/24
  Known via "bgp 11", distance 20, metric 0
  Tag 10, type external
  Last update from 10.10.24.4 00:42:32 ago
  Routing Descriptor Blocks:
  * 10.10.24.4, from 10.10.24.4, 00:42:32 ago
      Route metric is 0, traffic share count is 1
      AS Hops 1

На этом этапе важно понять, что в Cisco IPCC Express коммутируемая по технологии переадресации сеть, решение о пересылке пакетов состоит из:

  • Таблица маршрутизации ищет совпадение с наибольшей длиной префикса.

  • Поиск базы данных переадресации (FIB).

Так как таблица маршрутизации проверена, посмотрите на FIB скоростной маршрутизации Cisco. В результатах команды show ip cef 10.10.34.4 detail обратите внимание, что скоростная маршрутизация Cisco переключается 10.10.34.4 Ethernet 0/0 вместо следующего перехода 10.10.24.4 Последовательных 8/0 (как показано в выходных данных команды show ip route 10.10.34.0). Это несоответствие создает петли в сети.

R2#show ip cef 10.10.34.4 detail
10.10.34.4/32, version 19, cached adjacency 10.10.34.4
0 packets, 0 bytes
  via 10.10.34.4, Ethernet0/0, 0 dependencies
    next hop 10.10.34.4, Ethernet0/0
    valid cached adjacency

Следующий шаг должен посмотреть на таблицу соседей скоростной маршрутизации Cisco и видеть, как скоростная маршрутизация Cisco учится коммутировать пакеты Ethernet 0/0. Заметьте, что смежность создана из-за ARP.

R2#show adjacency ethernet 0/0 detail | begin  10.10.34.4 
IP       Ethernet0/0               10.10.34.4(5)
                                   50 packets, 2100 bytes
                                   AABBCC006500AABBCC0066000800
                                   ARP        03:02:00

Эти выходные данные команды show ip arp являются подтверждением.

R2#show ip arp 10.10.34.4
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  10.10.34.4             60   aabb.cc00.6500  ARPA   Ethernet0/0

Затем, узнайте, почему эта Запись ARP была создана, когда существует IP-маршрут в таблице маршрутизации. Посмотрите на таблицу маршрутизации снова.

R2#show run | include ip route 0.0.0.0
ip route 0.0.0.0 0.0.0.0 10.10.24.4
ip route 0.0.0.0 0.0.0.0 Ethernet0/0 10

Если сбои последовательного подключения между R2 и R4, весь трафик маршрутизируется с использованием плавающего статического маршрута Ethernet 0/0, потому что R2 имеет плавающий статический маршрут, который указывает к Ethernet мультиинтерфейса доступа 0/0, а не к IP-адресу Ethernet 192.168.12.1 из R1. Поэтому для всех неизвестных назначений, маршрутизатор R2 отсылает запрос ARP через интерфейс Ethernet0/0. В этом случае R2 потерял уточненный маршрут 10.10.34.0 сетям. Поэтому, когда пакет данных поступает для хостов в эту сеть, он генерирует запрос ARP через Интерфейс Ethernet. Так как Прокси - протокол преобразования адресов включен по умолчанию на Интерфейсе Ethernet R1, и это имеет маршрут по умолчанию, который указывает к R3, это отвечает назад Ответом прокси ARP с его собственным MAC-адресом. Следовательно, R2 передает весь трафик к R1, и R1 передает весь трафик с использованием его маршрута по умолчанию (0.0.0.0/0) к AS 12, и следовательно к 10.10.34.4 через Интернет.

Когда R2 получает ответ прокси ARP от R1, это создает/32 допустимую смежность скоростной маршрутизации Cisco, которая указывает на интерфейс "Ethernet" 0/0. Эта запись скоростной маршрутизации Cisco убирает не возраст, пока маршрутизатор R1 прокси - протокола преобразования адресов не присутствует на Сегменте Ethernet. Таким образом/32 запись скоростной маршрутизации Cisco продолжает использоваться к коммутатору скоростной маршрутизации Cisco, пакеты, даже после последовательного подключения между R2 и R4 являются резервным копированием, и маршрут по умолчанию таблицы маршрутизации указывает на Последовательный 8/0 к AS 10. Результатом является цикл маршрутизации.

В заключение просмотрите журналы и удостоверьтесь, переброшен ли последовательный канал (s8/0). Это заставляет плавающий статический маршрут быть установленным в таблице маршрутизации, которая тогда приводит к прокси - протоколу преобразования адресов и приводит к установке записи скоростной маршрутизации Cisco 10.10.34.4/32 в FIB скоростной маршрутизации Cisco.

R2#show log | beg Ethernet0/0
[..]
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial8/0, changed state to down
%BGP-5-ADJCHANGE: neighbor 10.10.24.4 Down Interface flap
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial8/0, changed state to up
%BGP-5-ADJCHANGE: neighbor 10.10.24.4 Up

Журналы подтверждают причину. Таким образом, эти шаги показывают последовательность событий:

  1. Последовательный интерфейс 8/0 на R2 выключается.

  2. R2 предназначили пакет к 10.10.34.4.

  3. R2 придерживается резервного маршрута по умолчанию, указанного непосредственно к Ethernet 0/0.

  4. R2 передает запрос ARP за 10.10.34.4.

  5. R1 (Прокси) отвечает на запрос ARP с его собственным MAC-адресом к R2.

  6. R2 теперь имеет Запись ARP для 10.10.34.4 с MAC-адресом R1.

  7. R2 создает смежность скоростной маршрутизации Cisco для 10.10.34.4, и 10.10.34.4/32 запись установлена в таблице скоростной маршрутизации Cisco (FIB) для этого назначения через Ethernet 0/0. Эта запись скоростной маршрутизации Cisco поддержана столько, сколько Запись ARP допустима или пока R1 не присутствует на Сегменте Ethernet.

  8. Последовательный порт 8/0 появляется на R2.

  9. R2 получает маршрут eBGP 10.10.34.0/24 от R4 со следующим узлом 10.10.24.4 и помещает маршрут в таблицу маршрутизации IP.

  10. R1 изучает префикс 10.10.34.0/24 через iBGP от R2 и устанавливает его в таблице IP-маршрутизации.

  11. R1 предназначили пакет для 10.10.34.4.

  12. R1 изучает свою таблицу маршрутизации, маршруты префикса iBGP соответствий к R2, и направляет к R2.

  13. R2 получает пакет, предназначенный для 10.10.34.4. Так как это уже имеет запись скоростной маршрутизации Cisco для 10.10.34.4/32, который указывает к Ethernet 0/0 в ее Таблице FIB с MAC-адресом R1, это передает пакет обратно в R1, не смотря на таблицу маршрутизации. Это приводит к образованию петли.

Решение

Замените плавающий статический маршрут, который указывает непосредственно к Ethernet 0/0 с той, которая указывает к адресу следующего узла.

R2(config)#no ip route 0.0.0.0 0.0.0.0 ethernet 0/0 10
R2(config)# ip route 0.0.0.0 0.0.0.0 192.168.12.1 10

Когда у вас есть статический маршрут, который указывает к IP-адресу следующего перехода вместо Ethernet мультиинтерфейса доступа 0/0, он мешает R2 передать запросы ARP за всеми назначениями. Пакеты маршрутизируются и коммутируются на основе следующего перехода 192.168.12.1. Поэтому любых записей скоростной маршрутизации Cisco ARP и петель избегают.

Наблюдайте запись скоростной маршрутизации Cisco относительно R2, который указывает к корректному interface Serial 8/0.

R2#show ip cef 10.10.34.4
10.10.34.0/24, version 32, cached adjacency to Serial8/0
0 packets, 0 bytes
  via 10.10.24.4, 0 dependencies, recursive
    next hop 10.10.24.4, Serial8/0 via 10.10.24.0/24
    valid cached adjacency

Дополнительные сведения


Document ID: 26083