Протокол IP : Протокол EIGRP

Решите общие проблемы EIGRP

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

Содержание

Связанные обсуждения сообщества поддержки Cisco

Введение

Этот документ описывает, как решить наиболее распространенные проблемы Протокола EIGRP.

Примечание: Этот документ использует примеры и реализацию в Cisco IOS® для иллюстрирования различных способов поведения, с которыми можно встретиться.

Внесенный Люком Де Гееном, специалистом службы технической поддержки Cisco.

Общие сведения

Это - топология, которая используется для этого документа:

Разделы, которые придерживаются, описывают некоторые наиболее распространенные проблемы EIGRP и некоторые советы о том, как решить проблемы.

Соседняя переброска

Одиночная наиболее распространенная проблема, с которой встречаются с использованием EIGRP, - то, что это не устанавливает соседство должным образом. Существует несколько возможных причин для этого:

  • Проблема Максимального размера передаваемого блока данных (MTU)

  • Связь в одном направлении (однонаправленные соединения)

  • На ссылке существует проблема групповой адресации

  • Проблемы индивидуальной рассылки

  • Проблемы качества канала

  • Проблемы аутентификации

  • Проблемы неверной конфигурации

Если вы не получаете Приветственное сообщение EIGRP, вы не видите соседний узел в соседнем списке. Введите команду show ip eigrp neighbors, чтобы просмотреть информацию о Соседнем eigrp и определить проблему:

R2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1
H  Address Interface Hold Uptime  SRTT  RTO Q Seq
                       (sec)        (ms)      Cnt Num
3  10.1.1.1 Et0/0     12 00:00:48   1 5000 1 0
2  10.1.1.3 Et0/0     12 02:47:13  22  200 0 339
1  10.2.1.4 Et1/0     12 02:47:13  24  200 0 318
0  10.2.1.3 Et1/0     12 02:47:13  20  200 0 338 13  20  200 0 338

Если вы думаете, что соседство было сформировано, но у вас нет префиксов, которые необходимо изучить от того соседнего узла, проверить выходные данные предыдущей команды: Если Q-количество является всегда ненулевым, это могла бы быть индикация, что те же пакеты EIGRP ретранслируются постоянно. Введите подробную команду show ip eigrp neighbors, чтобы проверить, передается ли всегда тот же пакет. Если порядковый номер первого пакета всегда является тем же, то тот же пакет ретранслируется неопределенно:

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H  Address                Interface      Hold Uptime  SRTT  RTO Q Seq
                                           (sec)        (ms)      Cnt Num
3  10.1.1.1               Et0/0            11 00:00:08   1 4500 1 0
  Version 12.4/1.2, Retrans: 2, Retries: 2, Waiting for Init, Waiting for Init Ack
   UPDATE seq 350 ser 0-0 Sent 8040 Init Sequenced
2  10.1.1.3               Et0/0            11 02:47:56  22  200 0 339
  Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1  10.2.1.4               Et1/0            10 02:47:56  24  200 0 318
  Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0  10.2.1.3               Et1/0            11 02:47:56  20  200 0 338
  Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

Вы видите в выходных данных, что у первого соседнего узла есть проблема, и Время работы без сбоев перезагружено.

Важно, чтобы вы проверили, имеет ли router EIGRP процесса команду eigrp log-neighbor-changes. Однако это включено по умолчанию начиная с идентификатора ошибки Cisco CSCdx67706, таким образом, это не обнаруживается в конфигурации в этом случае. Проверьте запись в журналах для обоих из Соседних eigrp на каждой стороне ссылки. В по крайней мере одном из журналов должна быть значимая запись.

Вот все возможные причины для изменения смежности EIGRP и их записей журнала:

  • Никакой пакет EIGRP не был получен в течение времени удержания:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    holding time expired
  • EIGRP надежный пакет не был подтвержден в пределе повторной попытки:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    retry limit exceeded
  • EIGRP видит интерфейс в нерабочем состоянии:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:
    interface down
  • Маршрутизатор получил начальный обновленный пакет и перезапустил соседство:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    peer restarted
  • Маршрутизатор получил начальный обновленный пакет и сформировал новую смежность:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
    new adjacency
  • Ясная IP команда соседнего eigrp была введена, который привел к ясному руководству:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 172.16.1.4 (Serial2/0) is down:
    manually cleared
  • IP-адрес на интерфейсе был изменен:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.5 (Serial3/0) is down:
    address changed
  • На интерфейсе была задержка/изменение пропускной способности:

    Примечание: Это только происходит в более старых версиях кода. Нет никакой соседней откидной створки начиная с идентификатора ошибки Cisco CSCdp08764.

    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.3.1.6 (Serial2/0) is down:
    metric changed
  • Значения K неправильно сконфигурированы, или мягкое выключение происходит:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
    K-value mismatch
  • Мягкое выключение происходит:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
    Interface Goodbye received
  • Ip authentication mode eigrp 1 команда md5 был настроен на интерфейсе:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is down:
    authentication mode changed
  • Произошел постепенный Перезапуск/Непрерывная передача (NSF):
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.2 (FastEthernet1) is resync:
    peer graceful-restart
  • Соседние узлы, к которым существуют запросы, передаваемые без полученного ответа, очищены:
    %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.16 (Serial3/0) is down:
    stuck in active

Проблемы сети

Эти пять проблем указывают на проблему сети:

  • Stuck-Active (SIA) состояние

  • Таймер холдинга с истекшим сроком

  • Превышенный предел повторной попытки

  • Перезапущенный узел

  • Начальное Обновление передается перед Пакетом приветствия

SIA

См. раздел SIA этого документа.

Таймер холдинга с истекшим сроком

Таймер холдинга с истекшим сроком указывает, что маршрутизатор не получил пакета EIGRP (т.е. EIGRP Hello или любой другой пакет EIGRP) во время интервала времени удержания. Существуют больше, чем, вероятно, проблема на ссылке в этом случае.

Проверьте, что маршрутизатор получает Пакеты приветствия EIGRP на этой ссылке и что другая сторона передает им. Для проверки этого введите команду hello debug eigrp packet.

Как альтернатива использованию команды отладки, вы можете адрес ping IP 224.0.0.10 и проверять, отвечает ли тот соседний узел.

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

Другой быстрый тест, который можно выполнить, должен попробовать другой протокол, который использует другой IP-адрес групповой адресации. Например, можно настроить Версию 2 Протокола RIP, которая использует IP-адрес групповой адресации 224.0.0.9.

Превышенный предел повторной попытки

Превышенный предел повторной попытки указывает, что EIGRP надежный пакет не был подтвержден многократно. EIGRP надежный пакет является одним из этих пяти типов пакетов:

  • Обновление

  • Запрос

  • Ответ

  • Запрос SIA

  • Ответ SIA

Надежный пакет EIGRP ретранслировался по крайней мере 16 раз. Пакет ретранслируется каждый Таймаут retransmit (RTO). Минимальный RTO составляет 200 мс, и максимум составляет 5,000 мс. RTO увеличивается или уменьшается динамично через наблюдение за разницей во времени между временем, когда надежный пакет EIGRP передается и время, когда получено подтверждение. Когда надежный пакет не подтвержден, увеличения RTO. Если это сохраняется, то RTO увеличивает до пяти секунд быстро, таким образом, предел повторной попытки может достигнуть 16 x 5 секунд = 80 секунд. Однако, если время удержания EIGRP больше, чем 80 секунд, соседство не выключается, пока время удержания не истекло. Это может произойти на соединениях медленной глобальной сети (WAN), где, например, время удержания по умолчанию составляет 180 секунд.

Для ссылок с временами ожидания ниже, чем 80 секунд, это эффективно означает, что, если время удержания не истекает, оно поддержано на высоком уровне Пакетами приветствия EIGRP. Предел повторной попытки может тогда быть превышен. Это указывает, что существует или проблема MTU или проблема индивидуальной рассылки. Пакеты приветствия EIGRP являются маленькими; (первый) пакет Обновления EIGRP может быть до полного MTU. Если будет достаточно префиксов для заполнения обновления, это будет полный максимальный размер передаваемого блока данных. Соседний узел может быть изучен через прием Пакетов приветствия EIGRP, но полная смежность не могла бы успешно выполниться, если не подтвержден пакет Обновления EIGRP.

Как правило, это - выходные данные, которые появляются:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
retry limit exceeded
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
new adjacency

Примечание: С идентификатора ошибки Cisco CSCsc72090 EIGRP также использует параметры настройки IP MTU интерфейса. Прежде чем это исправление было применено, пакеты EIGRP стали бы фрагментированными, если бы IP MTU был настроен со значением, которое было ниже, чем 1,500. Эта проблема может, как правило, происходить в сетях Динамической многоточечной VPN (DMVPN).

Вторая возможность состоит в том, что Пакеты приветствия EIGRP делают его, потому что они многоадресно переданы к IP-адресу 224.0.0.10. Некоторые пакеты Обновления EIGRP могли бы сделать его, поскольку они могут быть многоадресно переданы. Однако ретранслируемый EIGRP надежные пакеты всегда одноадресно передается. Если путь многоадресных данных к соседнему узлу сломан, ретранслируемый надежный пакет не обрабатывает должным образом. Пропингуйте IP-адрес индивидуальной рассылки Соседнего eigrp (с размером набора эхо-запроса к полному максимальному размеру передаваемого блока данных ссылки, и с Не, Фрагмент укусил (бит DF) набор) для проверки.

Односторонняя связь может вызвать эту проблему также. Маршрутизатор EIGRP мог бы получить Пакеты приветствия EIGRP, но пакеты, которые переданы от этого соседнего узла, не делают его через ссылку. Если Пакеты приветствия не делают его, маршрутизатор не сознает, потому что ненадежно передаются Пакеты приветствия. Пакеты Обновления EIGRP, которые переданы, не будут подтверждены.

EIGRP надежные пакеты или подтверждение может стать поврежденным. Быстрый тест должен передать эхо-запросы с включенной проверкой ответа:

R1#ping
Protocol [ip]:
Target IP address: 10.1.1.2
Repeat count [5]: 10
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface:
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]: yes
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
Reply data will be validated
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 1/24/152 ms

Выполните команду debug eigrp packet для проверки передачи и приема Пакетов приветствия EIGRP и пакетов Обновления EIGRP как минимум:

R1#debug eigrp packets ?

 SIAquery EIGRP SIA-Query packets
 SIAreply EIGRP SIA-Reply packets
 ack      EIGRP ack packets
 hello     EIGRP hello packets
 ipxsap   EIGRP ipxsap packets
 probe    EIGRP probe packets
 query    EIGRP query packets
 reply    EIGRP reply packets
 request  EIGRP request packets
 retry    EIGRP retransmissions
 stub     EIGRP stub packets
 terse    Display all EIGRP packets except Hellos
 update   EIGRP update packets
 verbose  Display all EIGRP packets

Вот типичный пример превышенной проблемы предела повторной попытки:

R2#show ip eigrp neighbors

IP-EIGRP neighbors for process 1
H  Address  Interface Hold Uptime  SRTT  RTO Q Seq
                       (sec)        (ms)      Cnt Num
3  10.1.1.1  Et0/0     12 00:00:48   1 5000 1 0
2  10.1.1.3  Et0/0     12 02:47:13  22  200 0 339
1  10.2.1.4  Et1/0     12 02:47:13  24  200 0 318
0  10.2.1.3  Et1/0     12 02:47:13  20  200 0 338 13  20  200 0 338

Примечание: Всегда существуют один или несколько пакетов в очереди (Q Cnt).

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H  Address                Interface      Hold Uptime  SRTT  RTO Q Seq
                                           (sec)        (ms)      Cnt Num
3  10.1.1.1               Et0/0            10 00:00:59   1 5000 1 0
  Version 12.4/1.2, Retrans: 12, Retries: 12, Waiting for Init, Waiting for Init Ack
   UPDATE seq 349 ser 0-0 Sent 59472 Init Sequenced
2  10.1.1.3               Et0/0            11 02:47:23  22  200 0 339
  Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1  10.2.1.4               Et1/0            11 02:47:23  24  200 0 318
  Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0  10.2.1.3               Et1/0            10 02:47:23   20  200 0 338
  Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

Как показано в выходных данных, R2 ждет первого Обновленного пакета (установленный бит Init) от соседнего узла в IP-адресе 10.1.1.1.

В этих следующих выходных данных R2 ждет подтверждения первого Обновленного пакета (установленный бит Init) от соседнего узла в IP-адресе 10.1.1.1.

Примечание: RTO в его максимуме 5,000 мс, который указывает, что EIGRP надежные пакеты не подтвержден в течение этих пяти секунд.

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H  Address                Interface      Hold Uptime  SRTT  RTO Q Seq
                                           (sec)        (ms)      Cnt Num
3  10.1.1.1               Et0/0            11 00:01:17   1 5000 1 0
  Version 12.4/1.2, Retrans: 16, Retries: 16, Waiting for Init, Waiting for Init Ack
   UPDATE seq 349 ser 0-0 Sent 77844 Init Sequenced
2  10.1.1.3               Et0/0            12 02:47:42  22  200 0 339
  Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1  10.2.1.4               Et1/0            10 02:47:42  24  200 0 318
  Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0  10.2.1.3               Et1/0            11 02:47:42  20  200 0 338
  Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

Число повторных передач постоянно увеличивается. Это всегда - тот же пакет в очереди (seq 349). После того, как R2 передал этот тот же пакет 16 раз, соседство выключается:

R2#
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
retry limit exceeded
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
new adjacency

Процесс начинается еще раз:

R2#show ip eigrp neighbors detail

IP-EIGRP neighbors for process 1
H  Address                Interface      Hold Uptime  SRTT  RTO  Q Seq
                                           (sec)        (ms)      Cnt Num
3  10.1.1.1               Et0/0            11 00:00:08   1 4500 1 0
  Version 12.4/1.2, Retrans: 2, Retries: 2, Waiting for Init, Waiting for Init Ack
   UPDATE seq 350 ser 0-0 Sent 8040 Init Sequenced
2  10.1.1.3               Et0/0            11 02:47:56  22  200 0 339
  Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 10
1  10.2.1.4               Et1/0            10 02:47:56  24  200 0 318
  Version 12.4/1.2, Retrans: 10, Retries: 0, Prefixes: 8
0  10.2.1.3               Et1/0            11 02:47:56  20  200 0 338
  Version 12.4/1.2, Retrans: 11, Retries: 0, Prefixes: 2

Выходные данные debug eigrp packet, краткая команда показывает, что R2 передает тот же пакет много раз:

Примечание: Увеличения значения повтора, значение Флагов является 0x1, и Init укусил, установлен.

R2#debug eigrp packets terse

EIGRP Packets debugging is on
   (UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

R2#
EIGRP: Sending UPDATE on Ethernet0/0 nbr 10.1.1.1, retry 14, RTO 5000
AS 1, Flags 0x1, Seq 350/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
EIGRP: Sending UPDATE on Ethernet0/0 nbr 10.1.1.1, retry 15, RTO 5000
AS 1, Flags 0x1, Seq 350/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1

Время удержания не истекает, потому что Пакеты приветствия переданы и получены должным образом:

R2#debug eigrp packets hello
EIGRP Packets debugging is on
   (HELLO)

EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.1
 AS 1, Flags 0x0, Seq 0/0 idbQ 0/0

Перезапущенный узел

Если вы наблюдаете узел, перезапускаемый неоднократно на одном маршрутизаторе, это указывает, что маршрутизатор получает начальные Обновленные пакеты от своего соседнего узла. Знайте о Флаге 1 в полученных Обновленных пакетах.

R2#deb eigrp packets terse

EIGRP Packets debugging is on
   (UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)

R2#
EIGRP: Received Sequence TLV from 10.1.1.1
      10.1.1.2
      address matched
     clearing CR-mode
EIGRP: Received CR sequence TLV from 10.1.1.1, sequence 479
EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1
 AS 1, Flags 0xA, Seq 479/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0,
not in CR-mode, packet discarded
EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1
 AS 1, Flags 0x1, Seq 478/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
peer restarted
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is up:
new adjacency
EIGRP: Enqueueing UPDATE on Ethernet0/0 nbr 10.1.1.1 iidbQ un/rely 0/1
peerQ un/rely 0/0

Начальное обновление перед Hello

Вот пример, где начальный Обновленный пакет получен перед Пакетом приветствия:

EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2
 AS 1, Flags 0x1, Seq 3/0 idbQ 0/0
EIGRP: Neighbor(10.1.1.2) not yet found

Если это происходит однажды после соседней откидной створки, то эта ситуация не является проблемой. Однако при испытании его часто это указывает, что индивидуальная рассылка на ссылке в рабочем состоянии, но сломана групповая адресация на ссылке. Другими словами, маршрутизатор получает Обновленный пакет индивидуальной рассылки, но не Пакеты приветствия.

Другие проблемы

Другие типы проблем включают:

  • Изменения в конфигурации

  • Проблемы аутентификации

  • Несоответствия на основном и вторичных IP - адресах

  • Проблемы DMVPN

Эти проблемы объяснены более подробно в разделах, которые придерживаются.

Изменения в конфигурации

Примечание: Результатами команд, которые используются всюду по этому разделу, является то же при настройке отрицания вместо этого (никакая команда).

При настройке итогового оператора (или автосуммирование) на интерфейсе вы наблюдаете это сообщение относительно маршрутизатора:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:
summary configured

Вот пример, который показывает конфигурацию глобального списка распределения для процесса EIGRP:

R1(config-router)#distribute-list 1 out
R1(config-router)#

Это сообщение наблюдается относительно маршрутизатора:

Примечание: То же происходит при настройке distribute-list <> в также.

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.3 (Ethernet0/0) is resync:
route configuration changed

Все Соседние eigrp тогда выключаются при настройке интерфейсного distribute-list для процесса EIGRP:

R1(config-router)#distribute-list 1 out ethernet 0/0

В этом случае только смежности EIGRP на этом интерфейсе перезагружены.

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

Аутентификация

Аутентификация может быть неправильно сконфигурирована или пропавшие без вести. Это может заставить смежность EIGRP выключаться из-за превышенного retry-limit. Выполните команду debug eigrp packet, чтобы подтвердить, что это - аутентификация алгоритма представления сообщения в краткой форме 5 (MD5), которая вызывает проблему:

R1#debug eigrp packets

EIGRP Packets debugging is on
   (UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY,
SIAREPLY)

EIGRP: Ethernet0/0: ignored packet from 10.1.1.3, opcode = 1 (missing
authentication or key-chain missing)

Несоответствие на основном и вторичных IP - адресах

EIGRP отсылает Hello и все другие пакеты от основного IP - адреса. Если IP - адреса источника попадают в диапазон основного IP - адреса или один из диапазонов вторичного IP - адреса на интерфейсе, пакеты приняты от другого маршрутизатора. В противном случае это сообщение об ошибках (когда eigrp log-neighbor-warnings включен) наблюдается:

IP-EIGRP(Default-IP-Routing-Table:1): Neighbor 10.1.1.2 not on common subnet
for Ethernet0/0

DMVPN

Проверьте для проблем IPSec в сетях DMVPN. Если шифрование не является чистым, IPSec может заставить EIGRP колебаться:

show crypto ipsec sa

  protected vrf:
  local ident (addr/mask/prot/port): (10.10.110.1/255.255.255.255/47/0)
  remote ident (addr/mask/prot/port): (10.10.101.1/255.255.255.255/47/0)
  current_peer: 144.23.252.1:500
    PERMIT, flags={origin_is_acl,}
   #pkts encaps: 190840467, #pkts encrypt: 190840467, #pkts digest 190840467
   #pkts decaps: 158102457, #pkts decrypt: 158102457, #pkts verify 158102457
   #pkts compressed: 0, #pkts decompressed: 0
   #pkts not compressed: 0, #pkts compr. failed: 0
   #pkts not decompressed: 0, #pkts decompress failed: 0
   #send errors 5523, #recv errors 42

Объясненные флаги

В заголовке пакета EIGRP существует 32-разрядное поле Flags, и полезно понять индикации относительно различных Флаговых значений.

  • 0x1 Init флага укусил

    Этот Флаг установлен в начальном Обновленном пакете.
    EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.1
    AS 1, Flags 0x1, Seq 478/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
  • Флаг 0x2 

    Этот Флаг указывает на Условный Режим приема (режим CR). Это - часть надежного процесса групповой адресации EIGRP и используется, чтобы позволить соседним узлам, которые не признали, что предыдущий надежный пакет нагоняет в совместном канале. Адреса в Type Length Value (TLV) Последовательности являются узлами, кто должен проигнорировать пакеты групповой адресации, пока они не нагоняют через одноадресные пакеты.
    EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2
     AS 1, Flags 0x2, Seq 21/0 idbQ 1/0 iidbQ un/rely 0/0 peerQ un/rely 0/1,
    not in CR-mode, packet discarded
  • Флаг 0x4

    Этот Флаг является битом Перезапуска (RS укусил). Когда NSF сообщен, это установлено в Пакетах приветствия и Обновленных пакетах. Осведомленный о NSF маршрутизатор просматривает этот бит, чтобы обнаружить, если соседний маршрутизатор перезапускает. Соседний узел, который обнаруживает тогда, знает для поддержания на высоком уровне смежности EIGRP. Маршрутизатор, который перезапускает представления этот Флаг, чтобы определить, помогает ли узел с перезапуском.
    EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.2
    AS 1, Flags 0x4, Seq 0/0 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
  • Флаг 0x8

    Это - бит Конца таблицы (EOT). Этот бит указывает, что полная таблица маршрутизации была передана соседнему узлу. Способный к NSF маршрутизатор просматривает этот бит, чтобы определить, завершил ли соседний маршрутизатор свой перезапуск. Способный к NSF маршрутизатор ждет этого бита, прежде чем это удалит устаревшие маршруты из маршрутизатора, который перезапускает.
    EIGRP: Received UPDATE on Ethernet0/0 nbr 10.1.1.2
     AS 1, Flags 0x8, Seq 4/33 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
    EIGRP: NSF: AS1. Receive EOT from 10.1.1.2

Флаги распечатаны в одном Шестнадцатеричном числе. Таким образом Флаг 0x5 означает, что установлены Флаги 4 и 1; Отметьте средства 0x9, что установлены Флаги 8 и 1; Отметьте средства 0xA, что установлены Флаги 8 и 2.

Можно использовать эти команды для устранения проблем колеблющихся соседних узлов:

  • покажите подробность eigrp interface

  • сведения о соседе show ip eigrp

  • эхо-запрос одноадресно передан

  • эхо-запрос с размером полный MTU

  • эхо-запрос с "проверяет данные ответа"

  • эхо-запрос передан в многоадресном режиме

  • debug eigrp packet (привет)

  • show ip eigrp traffic

  • show ip traffic | начинает EIGRP

SIA

Этот раздел предоставляет обзор состояния SIA, некоторых возможных симптомов и причин, и как устранить неполадки его.

Определение SIA

Состояние SIA означает, что маршрутизатор EIGRP не получил ответ на запрос от одного или более соседних узлов в течение выделенного времени (приблизительно три минуты). Когда это происходит, EIGRP очищает соседние узлы, которые не передают ответ, и регистрирует сообщение об ошибках DUAL-3-SIA для маршрута, который пошел активный.

Признаки

Эти сообщения могут быть замечены на одном или нескольких маршрутизаторах:

%DUAL-3-SIA: Route 10.100.1.1/32 stuck-in-active state in IP-EIGRP(0) 1. Cleaning up

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.6 (Serial3/0) is down:
stuck in active

Если это только происходит спорадически, это может быть проигнорировано. Если это часто происходит, это указывает на персистентную проблему сети.

Возможные причины

Вот некоторые возможные причины для состояния SIA:

  • Каналы с периодической потерей соединения

  • Неработающие каналы

  • Пульсации маршрута

  • Перегруженные каналы

  • Диаметр большой сети (диапазон выполнения больших запросов)

  • Недостаточная память

  • Высокая загрузка CPU

  • Неверная конфигурация (неправильное значение пропускной способности)

Советы по поиску и устранению неполадок

Когда ситуация с SIA происходит, существует проблема где-нибудь в сети. Точную причину может быть трудно обнаружить. Существует два подхода:

  • Просмотрите префиксы, о которых последовательно сообщают как SIA и определяют общности.

  • Найдите маршрутизатор, который последовательно не в состоянии отвечать на запросы для этих маршрутов.

Определите, имеют ли все префиксы, для которых сообщают о SIA, общности. Например, они все могли бы быть маршрутами/32 от края сети (такой как в коммутируемых сетях). Если так, это могло бы указать на проблемное местоположение в сети (а именно, где эти префиксы произошли).

В конечном счете необходимо обнаружить местоположение, куда один или несколько маршрутизаторов передают запросы и не получают ответы, в то время как нижестоящий маршрутизатор не находится в этом состоянии. Например, маршрутизатор мог передать запросы, и они подтверждены, но не получен ответ от нижестоящего маршрутизатора.

Можно использовать команду show ip eigrp topology active, чтобы помочь решать проблему SIA. Ищите маленький r в выходных данных команды. Это означает, что маршрутизатор ждет ответа на запрос для того префикса от того соседнего узла.

Например. Просмотрите топологию. Ссылки R1-R6 и R1-R5 закрыты. Когда интерфейс обратной связи маршрутизатора R1 закрыт, R1 передает запрос за префиксом 10.100.1.1/32 к R2 и R3. Маршрутизатор R1 теперь активен для этого префикса. Маршрутизаторы R2 и R3 идут активные и сделали запрос в свою очередь маршрутизатора R4, который идет активный и передает запрос к R5. Маршрутизатор R5 наконец идет активный и передает запрос к R6. Маршрутизатор R6 должен возвратить ответ на R5. Маршрутизатор R5 идет пассивный и отвечает на R4, который в свою очередь идет пассивный и передает ответ на R2 и R3. Наконец, R2 и R3 идут пассивные и передают ответ на R1, который идет пассивный снова.

Если с проблемой встречаются, то маршрутизатор может оставаться активен в течение расширенного времени, поскольку это должно ждать ответа. Для предотвращения маршрутизатора, ждущего ответа, который никогда не мог бы получаться, маршрутизатор может объявить SIA и уничтожить соседство, через которое это ждет ответа. Для устренения проблемы просмотрите выходные данные команды show ip eigrp topology active и придерживайтесь следа r.

Вот выходные данные для маршрутизатора R1:

R1#show ip eigrp topology active
IP-EIGRP Topology Table for AS 1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
     r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible
   1 replies, active 00:01:11, query-origin: Local origin
       via Connected (Infinity/Infinity), Loopback0
     Remaining replies:
        via 10.1.1.2, r, Ethernet0/0

Маршрутизатор R1 активен и ждет ответа от R2. Вот выходные данные для маршрутизатора R2:

R2#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.2)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
      r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible
   1 replies, active 00:01:01, query-origin: Successor Origin
       via 10.1.1.1 (Infinity/Infinity), Ethernet0/0
       via 10.2.1.4 (Infinity/Infinity), r, Ethernet1/0, serno 524
       via 10.2.1.3 (Infinity/Infinity), Ethernet1/0, serno 523

Маршрутизатор R2 активен и ждет ответа от R4. Вот выходные данные для маршрутизатора R4:

R4#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.4)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
      r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible
   1 replies, active 00:00:56, query-origin: Successor Origin
       via 10.2.1.2 (Infinity/Infinity), Ethernet1/0
       via 172.16.1.5 (Infinity/Infinity), r, Serial2/0, serno 562
       via 10.2.1.3 (Infinity/Infinity), Ethernet1/0, serno 560

Маршрутизатор R4 активен и ждет ответа от R5. Вот выходные данные для маршрутизатора R5:

R5#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(172.16.1.5)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
      r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible, Q
   1 replies, active 00:00:53, query-origin: Successor Origin
       via 172.16.1.4 (Infinity/Infinity), Serial2/0
     Remaining replies:
        via 192.168.1.6, r, Serial3/0

Маршрутизатор R5 активен и ждет ответа от R6. Вот выходные данные для маршрутизатора R6:

R6#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(192.168.1.6)
R6#

Как показано маршрутизатор R6 не активен для префикса, таким образом, проблема должна быть между маршрутизаторами R5 и R6. Через какое-то время мы видим, что R5 уничтожает соседство к R6 и объявляет состояние SIA:

R5#
%DUAL-3-SIA: Route 10.100.1.1/32 stuck-in-active state in IP-EIGRP(0) 1.
 Cleaning up
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 192.168.1.6 (Serial3/0) is down:
stuck in active

При просмотре выходных данных для маршрутизатора R5 вы видите, что существуют проблемы на ссылке к R6.

Это - новый код SIA, и как таковой, SIA произошел на маршрутизаторе, который был рядом с проблемой. В данном примере это - ссылка между маршрутизаторами R5 и R6. В более старых версиях кода SIA мог быть объявлен на любом маршрутизаторе вдоль пути (такой как на R2), который мог бы быть удален от проблемы. Таймер SIA составлял три минуты. Любой маршрутизатор вдоль пути мог быть первым, чтобы пойти SIA и уничтожить соседство (соседства). С более новым кодом маршрутизатор ждет ответа, косвенно передает запрос SIA его соседнему узлу, и соседний узел сразу отвечает с ответом SIA. Например, в то время как в активном состоянии, маршрутизатор R4 передает запрос SIA к R5 и ответы R5 с ответом SIA.

R5#
EIGRP: Received SIAQUERY on Serial2/0 nbr 172.16.1.4
 AS 1, Flags 0x0, Seq 456/447 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
EIGRP: Enqueueing SIAREPLY on Serial2/0 nbr 172.16.1.4 iidbQ un/rely 0/1
peerQ un/rely 0/0 serno 374-374
EIGRP: Sending SIAREPLY on Serial2/0 nbr 172.16.1.4
 AS 1, Flags 0x0, Seq 448/456 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
serno 374-374

Маршрутизатор R5 также передает запросы SIA к R6, но это не получает ответ SIA от R6.

R5#
EIGRP: Enqueueing SIAQUERY on Serial3/0 nbr 192.168.1.6 iidbQ un/rely 0/2
peerQ un/rely 5/0 serno 60-60

Как только маршрутизатор передает запрос SIA, но не получает ответ SIA, s появляется для того соседнего узла:

R5#show ip eigrp topology active
IP-EIGRP Topology Table for AS(1)/ID(172.16.1.5)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
      r - reply Status, s - sia Status

A 10.100.1.1/32, 1 successors, FD is Inaccessible, Qqr
   1 replies, active 00:02:36, query-origin: Successor Origin, retries(1)
       via 1172.16.1.4 (Infinity/Infinity), Serial2/0, serno 61
       via 192.168.1.6 (Infinity/Infinity), rs, q, Serial3/0, serno 60, anchored

С новым кодом SIA SIA должен быть объявлен на маршрутизаторе R5, когда это не получает ответ SIA. Необходимо тогда включить отладку для этих двух пакетов SIA EIGRP:

R2#debug eigrp packets SIAquery SIAreply

EIGRP Packets debugging is on
   (SIAQUERY, SIAREPLY)

R2#show deb
EIGRP:
 EIGRP Packets debugging is on
   (SIAQUERY, SIAREPLY)

Таким образом, можно использовать эти команды для решения проблемы SIA:

  • show ip eigrp topology active

  • событие show ip eigrp (возможно увеличивают размер журнала событий),

  • show ip eigrp traffic (ищут много запросов SIA и ответов SIA),

  • show proc mem

  • покажите сумму mem

Вот некоторые возможные решения для проблемы SIA:

  • Исправьте проблему канала.

  • Примените суммирование (ручной или автоматический) в сетях со многими префиксами или глубоким диапазоном запроса.

  • Используйте заказ distribute-list in уменьшить диапазон запроса.

  • Определите удаленные маршрутизаторы как фиктивные модули.

Пропавшие без вести префиксов

Существует два типа недостающих префиксов: те, которые отсутствуют в таблице маршрутизации (или Routing Information Base (RIB)), и те, которые отсутствуют в таблице топологии.

Пропавшие без вести префиксов в RIB

Может быть несколько причин, что префикс не включен в RIB:

  • Префикс установлен в таблице маршрутизации другим протоколом маршрутизации с меньшим административным расстоянием.

  • Distribute-list блокирует префикс.

  • Разделение горизонта блокирует префикс.

Префикс, установленный протоколом маршрутизации с меньшим административным расстоянием

В данном примере префикс установлен в таблице маршрутизации статическим маршрутом или протоколом маршрутизации с меньшим административным расстоянием.

Как правило, когда это происходит, префикс находится в таблице топологии, но не имеет никакого преемника. Можно просмотреть все эти записи с командой нулевых преемников show ip eigrp topology. Допустимое расстояние (FD) должно иметь бесконечное значение.

Введите команду <prefix> show ip route и проверьте протоколы маршрутизации, которые владеют маршрутом в RIB:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32
 State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
 Routing Descriptor Blocks:
 10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
     Composite metric is (2297856/128256), Route is Internal
     Vector metric:
       Minimum bandwidth is 1544 Kbit
       Total delay is 25000 microseconds
       Reliability is 255/255
       Load is 1/255
      Minimum MTU is 1500
       Hop count is 1
R1#show ip eigrp topology zero-successors
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
      r - reply Status, s - sia Status

P 192.168.1.0/24, 0 successors, FD is Inaccessible
       via 10.3.1.6 (2681856/2169856), Serial2/0
P 192.168.100.6/32, 0 successors, FD is Inaccessible
       via 10.3.1.6 (2297856/128256), Serial2/0

Distribute-List блокирует префикс

EIGRP является протоколом маршрутизации вектора пути. Можно использовать distribute-list на любом маршрутизаторе чтобы к префиксам блока. Можно использовать его на интерфейсе, чтобы мешать префиксам быть отосланными или быть полученными, или можно настроить distribute-list глобально при процессе router EIGRP для применения фильтра маршрутов на все поддерживающие EIGRP интерфейсы.

Например:

R1#show running-config | begin router eigrp

router eigrp 1
network 10.0.0.0
distribute-list 1 in
no auto-summary
!
access-list 1 deny  192.168.100.6
access-list 1 permit any

Пропавшие без вести префиксов в таблице топологии

В этом разделе описываются некоторые причины, которые префикс мог бы пропускать от таблицы топологии.

Спецификация маски для надлежащих выходных данных команды

Не делайте типичную ошибку; при проверке префикса в таблице топологии всегда задавайте маску. Если вы не используете маску, это происходит:

R1#show ip eigrp topology 192.168.100.6  
% IP-EIGRP (AS 1): Route not in topology table

Когда маска задана, вот выходные данные команды show ip eigrp topology:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
 Routing Descriptor Blocks:
 10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
     Composite metric is (2297856/128256), Route is Internal
     Vector metric:
       Minimum bandwidth is 1544 Kbit
       Total delay is 25000 microseconds
       Reliability is 255/255
       Load is 1/255
       Minimum MTU is 1500
       Hop count is 1
 10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x
     Composite metric is (2323456/2297856), Route is Internal
     Vector metric:
       Minimum bandwidth is 1544 Kbit
       Total delay is 26000 microseconds
       Reliability is 255/255
       Load is 1/255
      Minimum MTU is 1500
       Hop count is 2

Как показано префикс присутствует в таблице топологии.

Разделение горизонта блокирует префикс

В этом разделе описываются другую общую ошибку. EIGRP не является протоколом маршрутизации на основе состояния соединений, а скорее это - протокол маршрутизации вектора пути. Таблица топологии должна использоваться для нормальной работы Рассеянного Алгоритма обновления (DUAL), не потому что EIGRP является протоколом маршрутизации на основе состояния соединений; следовательно, это требует базы данных. Таблица топологии требуется, потому что только лучшие маршруты установлены в таблице маршрутизации, в то время как DUAL требует, чтобы допустимые маршруты были проверены также. Они сохранены в таблице топологии.

Вы должны всегда сделать, чтобы преемник направил и допустимые маршруты в таблице топологии. В противном случае существует дефект. Однако могли также быть недопустимые маршруты в таблице топологии, пока они получены. Если они не получены от соседнего узла, могло бы быть разделение горизонта, которое блокирует префикс.

Выходные данные команды show ip eigrp topology показывают только префиксные записи, которые указывают преемникам и возможным преемникам. Если вы хотите просмотреть префиксы, которые получены по всем путям (также недопустимые пути), то вводят  команду show ip eigrp topology all-links вместо этого.

Например:

R1#show ip eigrp topology         
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
      r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856
       via Connected, Serial2/0
P 10.2.1.0/24, 2 successors, FD is 307200
       via 10.1.1.2 (307200/281600), Ethernet0/0
       via 10.1.1.3 (307200/281600), Ethernet0/0
P 10.1.1.0/24, 1 successors, FD is 281600
       via Connected, Ethernet0/0
P 172.16.1.0/24, 1 successors, FD is 2195456
       via 10.4.1.5 (2195456/2169856), Ethernet1/0
P 192.168.1.0/24, 1 successors, FD is 2195456
      via 10.4.1.5 (2195456/2169856), Ethernet1/0
       via 10.3.1.6 (2681856/2169856), Serial2/0
P 10.4.1.0/24, 1 successors, FD is 281600
       via Connected, Ethernet1/0
P 172.16.100.5/32, 1 successors, FD is 409600
       via 10.4.1.5 (409600/128256), Ethernet1/0
P 10.100.1.4/32, 2 successors, FD is 435200
       via 10.1.1.2 (435200/409600), Ethernet0/0
       via 10.1.1.3 (435200/409600), Ethernet0/0
P 10.100.1.3/32, 1 successors, FD is 409600
       via 10.1.1.3 (409600/128256), Ethernet0/0
P 10.100.1.2/32, 1 successors, FD is 409600
       via 10.1.1.2 (409600/128256), Ethernet0/0
P 10.100.1.1/32, 1 successors, FD is 128256
       via Connected, Loopback0
P 192.168.100.6/32, 1 successors, FD is 2297856
       via 10.3.1.6 (2297856/128256), Serial2/0

В этих выходных данных вы видите, что часть все-ссылок команды включает больше путей:

R1#show ip eigrp topology all-links  
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
      r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856, serno 43
       via Connected, Serial2/0
P 10.2.1.0/24, 2 successors, FD is 307200, serno 127
       via 10.1.1.2 (307200/281600), Ethernet0/0
       via 10.1.1.3 (307200/281600), Ethernet0/0
P 10.1.1.0/24, 1 successors, FD is 281600, serno 80
       via Connected, Ethernet0/0
P 172.16.1.0/24, 1 successors, FD is 2195456, serno 116
       via 10.4.1.5 (2195456/2169856), Ethernet1/0
       via 10.3.1.6 (3193856/2681856), Serial2/0
       via 10.1.1.2 (2221056/2195456), Ethernet0/0
       via 10.1.1.3 (2221056/2195456), Ethernet0/0
P 192.168.1.0/24, 1 successors, FD is 2195456, serno 118
       via 10.4.1.5 (2195456/2169856), Ethernet1/0
       via 10.3.1.6 (2681856/2169856), Serial2/0
P 10.4.1.0/24, 1 successors, FD is 281600, serno 70
       via Connected, Ethernet1/0
P 172.16.100.5/32, 1 successors, FD is 409600, serno 117         
       via 10.4.1.5 (409600/128256), Ethernet1/0
       via 10.3.1.6 (2809856/2297856), Serial2/0
P 10.100.1.4/32, 2 successors, FD is 435200, serno 128
       via 10.1.1.2 (435200/409600), Ethernet0/0
       via 10.1.1.3 (435200/409600), Ethernet0/0
P 10.100.1.3/32, 1 successors, FD is 409600, serno 115
       via 10.1.1.3 (409600/128256), Ethernet0/0
P 10.100.1.2/32, 1 successors, FD is 409600, serno 109
       via 10.1.1.2 (409600/128256), Ethernet0/0
P 10.100.1.1/32, 1 successors, FD is 128256, serno 4
       via Connected, Loopback0
P 192.168.100.6/32, 1 successors, FD is 2297856, serno 135
       via 10.3.1.6 (2297856/128256), Serial2/0
       via 10.4.1.5 (2323456/2297856), Ethernet1/0

Рассмотрите последний префикс в предыдущих выходных данных; путь через 10.4.1.5 имеет (2323456/2297856). Объявленное расстояние (открытая метрика) 2297856, который не меньше, чем FD 2297856, таким образом, путь не выполним.

P 192.168.100.6/32, 1 successors, FD is 2297856, serno 135
       via 10.3.1.6 (2297856/128256), Serial2/0
       via 10.4.1.5 (2323456/2297856), Ethernet1/0

Вот пример, где разделение горизонта заставляет путь быть исключенным из таблицы топологии для одного маршрута. При просмотре топологии вы видите, что маршрутизатор R1 имеет префикс 192.168.100.6/32 через R6 и R5 в таблице топологии, но не через R2 или R3:

R1#show ip eigrp topology 192.168.100.6 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.100.6/32
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
 Routing Descriptor Blocks:
 10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
     Composite metric is (2297856/128256), Route is Internal
     Vector metric:
       Minimum bandwidth is 1544 Kbit
       Total delay is 25000 microseconds
       Reliability is 255/255
       Load is 1/255
       Minimum MTU is 1500
       Hop count is 1
 10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
     Composite metric is (2323456/2297856), Route is Internal
     Vector metric:
       Minimum bandwidth is 1544 Kbit
       Total delay is 26000 microseconds
       Reliability is 255/255
       Load is 1/255
       Minimum MTU is 1500
       Hop count is 2

Это вызвано тем, что маршрутизатор R1 никогда не получал префикс 192.168.100.6/32 через R2 или R3, поскольку у них есть префикс 192.168.100.6/32 через R1 в таблице маршрутизации.

R2#show ip route 192.186.100.6 255.255.255.255
Routing entry for 192.168.100.6/32
 Known via "eigrp 1", distance 90, metric 2323456, type internal
 Redistributing via eigrp 1
 Last update from 10.1.1.1 on Ethernet0/0, 00:02:07 ago
 Routing Descriptor Blocks:
 * 10.1.1.1, from 10.1.1.1, 00:02:07 ago, via Ethernet0/0
     Route metric is 2323456, traffic share count is 1
     Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit
     Reliability 255/255, minimum MTU 1500 bytes
     Loading 1/255, Hops 2

R3#show ip route 192.168.100.6 255.255.255.255
Routing entry for 192.168.100.6/32
 Known via "eigrp 1", distance 90, metric 2323456, type internal
 Redistributing via eigrp 1
 Last update from 10.1.1.1 on Ethernet0/0, 00:01:58 ago
 Routing Descriptor Blocks:
 * 10.1.1.1, from 10.1.1.1, 00:01:58 ago, via Ethernet0/0
     Route metric is 2323456, traffic share count is 1
     Total delay is 26000 microseconds, minimum bandwidth is 1544 Kbit
     Reliability 255/255, minimum MTU 1500 bytes
     Loading 1/255, Hops 2

Для проверки этого используйте ключевое слово все-ссылок на R1 при просмотре таблицы топологии. Это показывает все пути для всех префиксов, которые включают недопустимые пути. Можно тогда видеть, что префикс 192.168.100.6/32 не был изучен маршрутизатором R1 из R2 или R3.

Метрики

Примечание: MTU и счетчик переходов не включены в вычисление показателей.

Это формулы, которые используются для вычисления метрики пути маршрута:

  • Если K5 является ненулевым значением:

    Метрика EIGRP = 256* (((K1*Bw) + (K2*Bw) / (С 256 загрузками) + (K3*Delay)) * (K5 / (Надежность + K4)))

  • Если K5 равен нулю:

    Метрика EIGRP = 256* (K1*Bw) + (K2*Bw) / (С 256 загрузками) + (K3*Delay))

Значения K являются весами, которые используются для надбавки четырех компонентов метрики EIGRP: задержка, пропускная способность, надежность и загрузка. Это Значения K по умолчанию:

  • K1 = 1

  • K2 = 0

  • K3 = 1

  • K4 = 0

  • K5 = 0

Со Значениями K по умолчанию (только использующий пропускную способность и задержку), формула становится:

Метрика EIGRP = 256 * (ширина полосы частот + задержка)

Ширина полосы частот = (Ширина полосы частот 10^7/minimum в килобитах в секунду)

Примечание: Задержка измерена в десяти микросекунд; однако, на интерфейсе, это измерено в микросекундах.

Все эти четыре компонента могут быть проверены с командой show interface:

 R1#show interface et 0/0
Ethernet0/0 is up, line protocol is up
 Hardware is AmdP2, address is aabb.cc00.0100 (bia aabb.cc00.0100)
 Internet address is 10.1.1.1/24
 MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec,
    reliability 255/255, txload 1/255, rxload 1/255
 Encapsulation ARPA, loopback not set Keepalive set (10 sec)
 ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:02, output 00:00:02,
output hang never
 Last clearing of "show interface" counters never
 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
 Queueing strategy: fifo
 Output queue: 0/40 (size/max)
 5 minute input rate 0 bits/sec, 0 packets/sec
 5 minute output rate 0 bits/sec, 0 packets/sec
    789 packets input, 76700 bytes, 0 no buffer
    Received 707 broadcasts, 0 runts, 0 giants, 0 throttles
    0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
    0 input packets with dribble condition detected
    548 packets output, 49206 bytes, 0 underruns
    0 output errors, 0 collisions, 1 interface resets
    0 unknown protocol drops
    0 babbles, 0 late collision, 0 deferred
    0 lost carrier, 0 no carrier
    0 output buffer failures, 0 output buffers swapped out

Задержка кумулятивна, что означает, что вы добавляете задержку каждой ссылки вдоль пути. Пропускная способность не кумулятивна, таким образом, пропускная способность, которая используется в формуле, является самой маленькой пропускной способностью любой ссылки вдоль пути.

Дублирование идентификатора маршрутизатора

Для просмотра идентификатора маршрутизатора, который EIGRP использует, введите команду show ip eigrp topology в маршрутизатор и просмотрите первую линию выходных данных:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(1)/ID(10.100.1.1)

Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
      r - reply Status, s - sia Status

P 10.3.1.0/24, 1 successors, FD is 2169856
       via Connected, Serial2/0

ID маршрутизатора EIGRP не используется вообще для внутренних маршрутов в более старых версиях Cisco IOS. Если только внутренние маршруты используются, дублирование идентификатора маршрутизатора для EIGRP не должно вызывать проблемы. В более новом программном обеспечении Cisco IOS внутренние маршруты EIGRP действительно несут ID маршрутизатора EIGRP.

Идентификатор маршрутизатора для внешних маршрутов может быть просмотрен в этих выходных данных:

R1#show ip eigrp topology 192.168.1.4 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 192.168.1.4/32
 State is Passive, Query origin flag is 1, 2 Successor(s), FD is 435200
 Routing Descriptor Blocks:
 10.1.1.2 (Ethernet0/0), from 10.1.1.2, Send flag is 0x0
     Composite metric is (435200/409600), Route is External
     Vector metric:
       Minimum bandwidth is 10000 Kbit
       Total delay is 7000 microseconds
       Reliability is 255/255
       Load is 1/255
       Minimum MTU is 1500
       Hop count is 2
     External data&colon;
       Originating router is 10.100.1.4 
      AS number of route is 0
       External protocol is Connected, external metric is 0
       Administrator tag is 0 (0x00000000)

Если (внешний) маршрут EIGRP с тем же ID маршрутизатора EIGRP как маршрутизатор получен, это не генерирует запись журнала. Однако журнал События EIGRP действительно перехватывает это. Когда вы проверяете для (внешнего) маршрута EIGRP, он не обнаруживается в таблице топологии.

Проверьте журнал События EIGRP для возможных сообщений дублирования идентификатора маршрутизатора:

R1#show ip eigrp events                            
Event information for AS 1:
1   08:36:35.303 Ignored route, metric: 10.33.33.33 3347456
2   08:36:35.303 Ignored route, neighbor info: 10.3.1.6 Serial2/1
3   08:36:35.303 Ignored route, dup router: 10.100.1.1
4   08:36:35.303 Rcv EOT update src/seq: 10.3.1.6 143
5   08:36:35.227 Change queue emptied, entries: 2
6   08:36:35.227 Route OBE net/refcount: 10.100.1.4/32 3
7   08:36:35.227 Route OBE net/refcount: 10.2.1.0/24 3
8   08:36:35.227 Metric set: 10.100.1.4/32 435200
9   08:36:35.227 Update reason, delay: nexthop changed 179200
10  08:36:35.227 Update sent, RD: 10.100.1.4/32 435200
11  08:36:35.227 Route install: 10.100.1.4/32 10.1.1.3
12  08:36:35.227 Route install: 10.100.1.4/32 10.1.1.2
13  08:36:35.227 RDB delete: 10.100.1.4/32 10.3.1.6

Несоответствие/Мягкое выключение значений K

Когда Значения K не являются тем же на соседних маршрутизаторах, это сообщение наблюдается:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch

Значения K настроены с этой командой (с возможными значениями K между 0 и 255):

metric weights tos k1 k2 k3 k4 k5

!
router eigrp 1
network 10.0.0.0
metric weights 0 1 2 3 4 5
!

Сообщение указывает, что смежность EIGRP не установлена из-за несоответствия в Значениях K. Когда другие маршрутизаторы используют вычисления другой метрики, Значения K должны быть тем же на всех маршрутизаторах EIGRP в одной автономной системе для предотвращения проблем маршрутизации.

Проверьте, являются ли Значения K тем же на соседних маршрутизаторах. Если Значения K являются тем же, проблема могла бы быть вызвана функцией мягкого выключения EIGRP. В этом случае маршрутизатор передает Пакет приветствия EIGRP с набором Значений K к 255 так, чтобы несоответствие Значений K произошло преднамеренно. Это должно указать к соседнему маршрутизатору EIGRP, что он выключается. На соседнем маршрутизаторе вы видели бы это полученное сообщение при закрытии:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down:
Interface Goodbye received

Однако, если соседний маршрутизатор выполняет более старую версию кода (до идентификатора ошибки Cisco CSCdr96531), это не распознает это как сообщение мягкого выключения, но как несоответствие в Значениях K:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.4.1.5 (Ethernet1/0) is down:
K-value mismatch

Это - то же сообщение как в случае истинного несоответствия Значений K на соседних маршрутизаторах.

Это триггеры для мягкого выключения:

  • Никакая команда router eigrp не введена.

  • Никакая сетевая команда не введена.

  • Ясная IP команда соседнего eigrp введена.

  • Маршрутизатор повторно загружен.

Мягкое выключение используется для ускорения обнаружения соседнего нерабочего состояния. Без мягкого выключения должен ждать соседний узел, пока время удержания не истекает, прежде чем оно объявит, что соседний узел не работает.

Распределение нагрузки неодинаковой стоимости (различие)

Распределение нагрузки неодинаковой стоимости возможно в EIGRP с командой variance, но должны быть встречены и различие и условия осуществимости.

Условие различия означает, что метрика маршрута не больше, чем лучшая метрика, умноженная на различие. Для маршрута, который будут считать выполнимым, маршрут, должно быть, был объявлен с объявленным расстоянием, которое ниже, чем Допустимое расстояние (FD). Например:

!
router eigrp 1
variance 2
network 10.0.0.0
no auto-summary
!

Маршрутизатор R1 имеет различие 2 настроенных. Это означает, что, если маршрутизатор имеет другой путь для маршрута с метрикой, которая не больше , чем дважды лучшая метрика для того маршрута, должно быть распределение нагрузки неодинаковой стоимости для того маршрута.

R1#show ip eigrp topology 172.16.100.5 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 172.16.100.5/32
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
 Routing Descriptor Blocks:
 10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
     Composite metric is (409600/128256), Route is Internal
     Vector metric:
       Minimum bandwidth is 10000 Kbit
       Total delay is 6000 microseconds
       Reliability is 255/255
       Load is 1/255
       Minimum MTU is 1500
       Hop count is 1
 10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
     Composite metric is (435200/409600), Route is Internal <<< RD = 409600
     Vector metric:
       Minimum bandwidth is 10000 Kbit
       Total delay is 7000 microseconds
       Reliability is 255/255
       Load is 1/255
       Minimum MTU is 1500
       Hop count is 2

Если вторая запись топологии установлена в таблице маршрутизации, метрика второй записи топологии 435200. Так как дважды лучшая метрика является 2 x 409600 = 819200, и 435200 <819200, вторая запись топологии в диапазоне различия. Объявленное расстояние второй записи топологии 409600, который не меньше, чем FD = 409600. Второе условие (выполнимость) не соблюдают, и вторая запись не может быть установлена в RIB.

R1#show ip route 172.16.100.5
Routing entry for 172.16.100.5/32
 Known via "eigrp 1", distance 90, metric 409600, type internal
 Redistributing via eigrp 1
 Last update from 10.4.1.5 on Ethernet1/0, 00:00:16 ago
 Routing Descriptor Blocks:
 * 10.4.1.5, from 10.4.1.5, 00:00:16 ago, via Ethernet1/0
     Route metric is 409600, traffic share count is 1
     Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
     Reliability 255/255, minimum MTU 1500 bytes
     Loading 1/255, Hops 1

Если бы RD второй записи топологии меньше тогда FD, как в следующем примере, было бы распределение нагрузки неодинаковой стоимости.

R1#show ip eigrp topology 172.16.100.5 255.255.255.255
IP-EIGRP (AS 1): Topology entry for 172.16.100.5/32
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 409600
 Routing Descriptor Blocks:
 10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
     Composite metric is (409600/128256), Route is Internal
     Vector metric:
       Minimum bandwidth is 10000 Kbit
       Total delay is 6000 microseconds
       Reliability is 255/255
       Load is 1/255
       Minimum MTU is 1500
       Hop count is 1
 10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
     Composite metric is (434944/409344), Route is Internal <<< RD = 409344
     Vector metric:
       Minimum bandwidth is 10000 Kbit
       Total delay is 6990 microseconds
       Reliability is 255/255
       Load is 1/255
       Minimum MTU is 1500
       Hop count is 2

Обе записи топологии находятся теперь в таблице маршрутизации:

R1#show ip route 172.16.100.5                       
Routing entry for 172.16.100.5/32
 Known via "eigrp 1", distance 90, metric 409600, type internal
 Redistributing via eigrp 1
 Last update from 10.3.1.6 on Serial2/0, 00:00:26 ago
 Routing Descriptor Blocks:
 * 10.4.1.5, from 10.4.1.5, 00:00:26 ago, via Ethernet1/0
     Route metric is 409600, traffic share count is 120
     Total delay is 6000 microseconds, minimum bandwidth is 10000 Kbit
     Reliability 255/255, minimum MTU 1500 bytes
     Loading 1/255, Hops 1
   10.3.1.6, from 10.3.1.6, 00:00:26 ago, via Serial2/0
     Route metric is 434944, traffic share count is 113
     Total delay is 6990 microseconds, minimum bandwidth is 10000 Kbit
     Reliability 255/255, minimum MTU 1500 bytes
     Loading 1/255, Hops 2

Статические соседи

EIGRP поддерживает конфигурации с одним или более статическими соседями на том же интерфейсе. Как только вы настраиваете один статический Соседний eigrp на интерфейсе, маршрутизатор больше не передает пакеты EIGRP, как передано в многоадресном режиме на том интерфейсе или обрабатывает полученные многоадресно переданные пакеты EIGRP. Это означает, что теперь одноадресно переданы Hello, Обновление и Пакеты запроса. Никакие дополнительные соседства не могут быть сформированы, пока команда статического соседа явно не настроена для тех соседних узлов на том интерфейсе.

Это - то, как настроить статический Соседний eigrp:

router eigrp 1
passive-interface Loopback0
network 10.0.0.0
no auto-summary
neighbor 10.1.1.1 Ethernet0/0
!

Когда маршрутизаторы с обеих сторон ссылки имеют команду статического соседа, соседство сформировано:

R1#show ip eigrp neighbors detail
IP-EIGRP neighbors for process 1
H  Address                Interface      Hold Uptime  SRTT  RTO Q Seq
                                         (sec)        (ms)      Cnt Num
1  10.1.1.2               Et0/0            14 00:00:23  27  200 0 230
  Static neighbor
  Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1
0  10.3.1.6               Se2/0            14 1d02h     26  200 0 169
  Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 12
3  10.4.1.5               Et1/0            10 1d02h     16  200 0 234
  Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 7

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

R1#
EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.2
 AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
EIGRP: Ignore multicast Hello Ethernet0/0 10.1.1.2
R2#
EIGRP: Received HELLO on Ethernet0/0 nbr 10.1.1.1
 AS 1, Flags 0x0, Seq 0/0 idbQ 0/0
EIGRP: Ignore unicast Hello from Ethernet0/0 10.1.1.1

Существует специальная команда отладки для статических соседей EIGRP:

R2#debug eigrp neighbors static
EIGRP Static Neighbors debugging is on

R2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
R2(config)#router eigrp 1              
R2(config-router)#neighbor 10.1.1.1 et 0/0
R2(config-router)#end
R2#

EIGRP: Multicast Hello is disabled on Ethernet0/0!
EIGRP: Add new static nbr 10.1.1.1 to AS 1 Ethernet0/0

Вот некоторые причины, что могли бы быть настроены статические Соседние eigrp:

  • Вы хотите ограничить или избежать широковещательных сообщений в сетях Non-Broadcast Multi-Access (NBMA).

  • Вы хотите ограничить или избежать многоадресных сообщений на средствах широковещания (Ethernet).

  • Для целей устранения проблем (использующий индивидуальную рассылку вместо групповой адресации).

Внимание: Не настраивайте команду passive-interface вместе со статической командой Соседнего eigrp.

Перераспределение статического маршрута

Когда вы настраиваете статический маршрут, который указывает к интерфейсу, и маршрут охвачен инструкцией сети под router EIGRP, тогда статический маршрут объявлен EIGRP, как будто это был связанный маршрут. Команда redistribute static или метрика по умолчанию не требуются в этом случае.

router eigrp 1
network 10.0.0.0
network 172.16.0.0
no auto-summary
!
ip route 172.16.0.0 255.255.0.0 Serial2/0
!
R1#show ip eigrp top 172.16.0.0 255.255.0.0     
IP-EIGRP (AS 1): Topology entry for 172.16.0.0/16
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2169856
 Routing Descriptor Blocks:
 0.0.0.0, from Rstatic, Send flag is 0x0
     Composite metric is (2169856/0), Route is Internal
     Vector metric:
       Minimum bandwidth is 1544 Kbit
       Total delay is 20000 microseconds
       Reliability is 255/255
       Load is 1/255
       Minimum MTU is 1500
       Hop count is 0

Надежность и загрузка для вычисления показателей

Внимание: Не используйте надежность и/или загружайтесь для вычисления метрик.

Надежность и параметры нагрузки появляются в выходных данных команды show interface. Когда загрузка и надежность изменяются, нет никаких динамических обновлений для этих параметров. Если загрузка и изменение надежности, это не инициирует непосредственное изменение в метрике. Только если EIGRP решает передать обновления своим соседним узлам из-за изменений топологии, будет изменение в загрузке и надежности распространиться. Кроме того, использование загрузки и надежности для вычисления метрики может представить нестабильность, поскольку тогда выполнена адаптивная маршрутизация. Если вы желаете изменить маршрутизацию в соответствии с трафиком, то необходимо рассмотреть использование регулирования трафика Многопротокольной коммутации по меткам (MPLS) или Производительность, Направляющую (PfR).

Высокая загрузка CPU

Существует три процесса EIGRP, которые работают одновременно:

  • Маршрутизатор – Этот процесс держит пулы совместно используемой памяти.

  • Hello – Этот процесс передает и получает Пакеты приветствия и поддерживает одноранговые соединения.

  • Зависимый от протокола модуль (PDM) – EIGRP поддерживает четыре набора протоколов: IP, IPv6, IPX и AppleTalk. Каждый комплект имеет свой собственный PDM. Вот первичные функции PDM:

    • Поддерживает соседний узел и таблицы топологии маршрутизаторов EIGRP, которые принадлежат тому набору протоколов.

    • Создает и преобразовывает определяемые протоколом пакеты для DUAL (передача и прием пакетов EIGRP).

    • Интерфейсы DUAL к определяемой протоколом таблице маршрутизации.

    • Вычисляет метрику, и передайте информацию к DUAL (DUAL только выбирает преемников и возможных преемников).

    • Внедряет фильтрацию и access-lists.

    • Выполняет функции перераспределения к и от других протоколов маршрутизации.

Вот пример выходных данных, который показывает эти три процесса:

R1#show proc cpu | include EIGRP
 89          4       24       166 0.00% 0.00% 0.00%  0 IP-EIGRP Router 
 90       1016     4406       230 0.00% 0.03% 0.00%  0 IP-EIGRP: PDM   
 91       2472     6881       359 0.00% 0.07% 0.08%  0 IP-EIGRP: HELLO

Высокая загрузка CPU в EIGRP не обычна. Если это происходит, или EIGRP имеет слишком много, чтобы сделать или в EIGRP существует дефект. В первом случае проверьте количество префиксов в таблице топологии и количество узлов. Проверьте для нестабильности среди маршрутов EIGRP и соседних узлов.

EIGRP в сетях Frame Relay (очередь широковещательных пакетов)

В сетях Frame Relay, где существуют несколько соседей маршрутизаторы на одном многоадресном интерфейсе (точка-многие точки), могут быть многие широковещание или пакеты групповой адресации, которые должны быть переданы. Поэтому существует разделять очередь широковещательных пакетов с ее собственными буферами. Очередь широковещательных пакетов имеет приоритет, когда это передает на скорости ниже настраиваемого максимального значения и имеет выделение гарантированной минимальной полосы пропускания.

Вот команда, которая используется в этом сценарии:

frame-relay broadcast-queue size byte-rate packet-rate

Как правило начните с двадцати пакетов на Идентификатор подключения Канала Передачи Данных (DLCI) (DLCI). Скорость передачи байтов должна быть меньше, чем оба из них:

  • Времена N/4 минимальная скорость удаленного доступа (измеренный в байтах в секунду), где N является количеством DLCI, в которые должно быть реплицировано широковещание.

  • Одна четверть скорости локального доступа (измеренный в байтах в секунду).

Если вы наблюдаете большое число переброски Соседних eigrp, увеличиваете размер frame-relay broadcast-queue. Эта проблема не присутствует, если существуют подинтерфейсы Frame Relay, потому что каждый соседний маршрутизатор находится на одном подинтерфейсе с другой IP-подсетью. Рассмотрите это как обходной путь, когда будет большая, полностью объединенная сеть Frame Relay.

Несогласованные номера AS

При вводе команды hello debug eigrp packet она показывает, что маршрутизатор не получает Пакеты приветствия.

Auto-summary

EIGRP использовал выполнять суммирование в крупной сети (сети A, B, и C) границы по умолчанию. Это означает, что уточненные маршруты, чем/8 префиксы для типа A крупной сети, уточненные маршруты, чем/16 префиксы для типа B крупной сети, и уточненные маршруты, чем/24 префиксы для типа C крупных сетей, потеряны, когда они пересекают свои границы. Вот пример, где автосуммирование вызывает проблему:

Как показано маршрутизаторы R1 и R3 имеют автосуммирование под router EIGRP. Маршрутизатор R2 получает 10.0.0.0/8 от обоих маршрутизаторов R2 и R3, потому что и R2 и R3 являются граничными маршрутизаторами между главной сетью класса A 10.0.0.0/8 и 172.16.0.0/16. Если метрика, оказывается, то же, маршрутизатор R2 может иметь маршрут 10.0.0.0/8 через R1 и R3. В противном случае R2 имеет маршрут 10.0.0.0/8 или через R1 или через R3, зависящий от пути, который производит наименьшее количество стоимость. В любом случае, если R2 должен передать трафик к определенным подсетям 10.0.0.0/8, это не может быть абсолютно уверено, что трафик достигает своего назначения, как одна подсеть 10.0.0.0/8 может быть только или на левых или на правильной распределенной сети, основанной на ретрансляции кадров.

Для облегчения этой проблемы просто введите никакое автосуммирование при процессе router EIGRP. Маршрутизатор тогда распространяется подсети крупных сетей через границу. В более новых версиях Cisco IOS значение никакого автосуммирования является поведением по умолчанию.

Журнал СОБЫТИЯ EIGRP

Журнал События EIGRP перехватывает События EIGRP. Это подобно тому, когда отладки включены для EIGRP. Однако это является менее подрывным и выполняется по умолчанию. Это может использоваться для получения событий, которых более трудно устранить неполадки или больше неустойчивых событий. Этот журнал является по умолчанию только 500 линиями. Для увеличения его введите команду <0 - 209878> eigrp event-log-size. Можно увеличить размер журнала так, как желаемый, но имеют в виду количество памяти, которое маршрутизатор должен сэкономить для этого журнала. Для очистки журнала События EIGRP введите ясную IP команду событий EIGRP.

Например:

R1#show ip eigrp events
Event information for AS 1:
1   09:01:36.107 Poison squashed: 10.100.1.3/32 reverse
2   09:01:35.991 Update ACK: 10.100.1.4/32 Serial2/0
3   09:01:35.967 Update ACK: 10.100.1.4/32 Ethernet0/0
4   09:01:35.967 Update ACK: 10.100.1.4/32 Ethernet1/0
5   09:01:35.943 Update delay/poison: 179200 FALSE
6   09:01:35.943 Update transmitted: 10.100.1.4/32 Serial2/0
7   09:01:35.943 Update delay/poison: 179200 TRUE
8   09:01:35.943 Update transmitted: 10.100.1.4/32 Ethernet0/0
9   09:01:35.943 Update delay/poison: 179200 FALSE
10  09:01:35.943 Update transmitted: 10.100.1.4/32 Ethernet1/0
11  09:01:35.923 Update packetized: 10.100.1.4/32 Ethernet0/0
12  09:01:35.923 Update packetized: 10.100.1.4/32 Ethernet1/0
13  09:01:35.923 Update packetized: 10.100.1.4/32 Serial2/0
14  09:01:35.903 Change queue emptied, entries: 1
15  09:01:35.903 Route OBE net/refcount: 10.100.1.4/32 3
16  09:01:35.903 Metric set: 172.16.1.0/24 2195456
17  09:01:35.903 Route install: 172.16.1.0/24 10.4.1.5
18  09:01:35.903 FC sat rdbmet/succmet: 2195456 2169856
19  09:01:35.903 FC sat nh/ndbmet: 10.4.1.5 2195456
20  09:01:35.903 Find FS: 172.16.1.0/24 2195456

Новые события появляются наверху журнала. Можно фильтровать определенные типы Событий EIGRP, такие как DUAL, Xmit и транспорт:

eigrp log-event-type {dual | xmit | transport}

Кроме того, вы можете enable logging для одного из этих трех типов, комбинации двух типов, или для всех трех. Вот пример, где включены два типа регистрации:

router eigrp 1
redistribute connected
network 10.0.0.0
no auto-summary
eigrp log-event-type dual xmit
eigrp event-logging
eigrp event-log-size 100000
!

Внимание: При включении регистрации событий eigrp она распечатывает регистрацию событий и хранит его в конечном счете таблица. Это может привести к большому количеству печатных выходных данных на консоли, подобной тому, когда включена тяжелая отладка EIGRP.

Та же сеть, изученная двумя анонимными системами EIGRP

Если маршрут изучен через два процесса EIGRP, то только один из процессов EIGRP может установить маршрут в RIB. Процесс с кратчайшим административным расстоянием устанавливает маршрут. Если административное расстояние является тем же, то процесс с наименьшей метрикой устанавливает маршрут. Если метрика совпадает с хорошо, то процесс EIGRP с самым низким ID процесса EIGRP устанавливает маршрут в RIB. Таблице топологии другого процесса EIGRP установят маршрут с нулевыми преемниками и бесконечным значением FD.

Например:

R1#show ip eigrp topology 192.168.1.0 255.255.255.0
IP-EIGRP (AS 1): Topology entry for 192.16.1.0/24
 State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2681856
 Routing Descriptor Blocks:
 10.3.1.6 (Serial2/0), from 10.3.1.6, Send flag is 0x0
     Composite metric is (2681856/2169856), Route is Internal
     Vector metric:
       Minimum bandwidth is 1544 Kbit
       Total delay is 40000 microseconds
       Reliability is 255/255
       Load is 1/255
       Minimum MTU is 1500
       Hop count is 1
IP-EIGRP (AS 2): Topology entry for 192.16.1.0/24
 State is Passive, Query origin flag is 1, 0 Successor(s), FD is 4294967295
 Routing Descriptor Blocks:
 10.4.1.5 (Ethernet1/0), from 10.4.1.5, Send flag is 0x0
     Composite metric is (2681856/2169856), Route is Internal
     Vector metric:
       Minimum bandwidth is 1544 Kbit
       Total delay is 40000 microseconds
       Reliability is 255/255
       Load is 1/255
       Minimum MTU is 1500
       Hop count is 1
R1#show ip route 192.168.1.0 255.255.255.0

Routing entry for 192.168.1.0/24
 Known via "eigrp 1", distance 90, metric 2681856, type internal
 Redistributing via eigrp 1
 Last update from 10.3.1.6 on Serial2/0, 00:04:16 ago
 Routing Descriptor Blocks:
 * 10.3.1.6, from 10.3.1.6, 00:04:16 ago, via Serial2/0
     Route metric is 2681856, traffic share count is 1
     Total delay is 40000 microseconds, minimum bandwidth is 1544 Kbit
     Reliability 255/255, minimum MTU 1500 bytes
     Loading 1/255, Hops 1


Document ID: 118974