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

Почему для соседних узлов OSPF сохраняется состояние Exstart/Exchange?

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


Содержание


Введение

В OSPF для формирования смежности используются следующие состояния: Down (отключение), Init (инициализация), Attempt (попытка), 2-way (двухстороннее согласование), Exstart (запуск обмена), Exchange (обмен), Loading (загрузка) и Full (заполненное состояние). Зависание соседних узлов OSPF в состоянии Exstart/Exchange может быть вызвано многими причинами. В этом документе основное внимание уделяется несоответствию размеров MTU между соседними узлами OSPF, приводящему к состоянию Exstart/Exchange. Дополнительные сведения об устранении неполадок, связанных с OSPF, см. в разделе Устранение неполадок OSPF.

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

Требования

Читатели данной документации shoud быть familar с операцией основного протокола OSPF и конфигурацией, особенно о состояниях соседей OSPF.

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

Сведения, содержащиеся в данном документе, касаются следующих версий программного и аппаратного обеспечения:

  • Маршрутизаторы Cisco 2503

  • Cisco Выпуск ПО IOS� 12.2 (24a) работающий на обоих маршрутизаторах

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

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

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

Состояние Exstart

После того как два соседних маршрутизатора OSPF устанавливают двустороннюю связь и завершают выбор DR/BDR (на сетях множественного доступа), эти маршрутизаторы переходят в состояние exstart. В этом состоянии соседние маршрутизаторы устанавливают ведущее устройство/подчиненное отношение и определяют начальный дескриптор базы данных (DBD) порядковый номер для использования при обмене Пакетами dbd.

Состояние обмена

Как только о ведущем устройстве/подчиненном отношении выполнили согласование (маршрутизатор с самым высоким Router-ID становится ведущим устройством), переход соседних маршрутизаторов в состояние обмена. В этом состоянии маршрутизаторы обмениваются пакетами DBD, которые описывают всю их базу данных состояний каналов. Маршрутизаторы также передают пакеты запроса состояния канала, в которых запрашиваются последние анонсы состояния канала (LSA) от соседей.

Несмотря на то, что переход окружений OSPF через состояния Exstart/Exchange во время обычного процесса создания смежностей OSPF, это не обычно для окружений OSPF для застревания в этом состоянии. Далее описывается наиболее распространенная причина, по которой соседние узлы OSPF продолжают оставаться в этом состоянии. Обратитесь к Состояниям соседей OSPF для узнавания больше о других состояниях OSPF.

Стек соседних узлов в состоянии обмена Exstart/Exchange

Проблема происходит наиболее часто при попытке выполнить OSPF между маршрутизатором Cisco и маршрутизатором другого поставщика. Когда параметры настройки максимального размера передаваемого блока данных (MTU) для интерфейсов соседнего маршрутизатора не совпадают, проблема происходит. Если маршрутизатор с более высоким MTU передает пакет, больше, который MTU установил на соседнем маршрутизаторе, соседний маршрутизатор игнорирует пакет 0, Когда эта проблема происходит, выходные данные показов команды show ip ospf neighbor вывели подобный показанный ниже.

Реальное повторное создание этой проблемы описано в этом разделе.

/image/gif/paws/13684/12a_01.gif

Маршрутизатор 6 и Маршрутизатор 7 в вышеупомянутой топологии связаны через Frame Relay, и Маршрутизатор 6 был настроен с 5 статическими маршрутами, перераспределенными в OSPF. В то время как последовательный интерфейс на Маршрутизаторе 7 имеет MTU 1450, последовательный интерфейс на Маршрутизаторе 6 имеет MTU по умолчанию 1500. Каждую конфигурацию маршрутизатора показывают в таблице ниже (только информацию о необходимой конфигурации показывают):

Конфигурация маршрутизатора 6 Конфигурация маршрутизатора 7
interface Serial2

!--- MTU sets to it's default value of 1500.

no ip address
no ip directed-broadcast
encapsulation frame-relay
no ip mroute-cache
frame-relay lmi-type ansi
!
interface Serial2.7 point-to-point
ip address 170.170.11.6 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 101
!
router ospf 7
redistribute static subnets
network 170.170.11.0 0.0.0.255 area 0

ip route 192.79.34.0 255.255.255.0 Null0
ip route 192.79.35.0 255.255.255.0 Null0
ip route 192.79.36.0 255.255.255.0 Null0
ip route 192.79.37.0 255.255.255.0 Null0
ip route 192.79.38.0 255.255.255.0 Null0
!
interface Serial0
mtu 1450
no ip address
no ip directed-broadcast
encapsulation frame-relay
frame-relay lmi-type ANSI

!
interface Serial0.6 point-to-point
ip address 170.170.11.7 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 110!
!

router ospf 7
network 170.170.11.0 0.0.0.255 area 0

Выходные данные команды show ip ospf neighbor для каждого маршрутизатора:

router-6# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
170.170.11.7      1   EXCHANGE/  -    00:00:36    170.170.11.7    Serial2.7
router-6#

router-7# show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
170.170.11.6      1   EXSTART/  -     00:00:33    170.170.11.6    Serial0.6
router-7#

Проблема возникает, когда маршрутизатор 6 в состоянии обмена отправляет пакет DBD, размер которого превышает 1450 байт (MTU маршрутизатора 7). Используйте debug ip packet и команды debug ip ospf adj на каждом маршрутизаторе для наблюдения процесса соседства OSPF, как это имеет место. Выходные данные от Маршрутизатора 6 и 7 от шагов 1 - 14:

  1. Выходные данные отладки маршрутизатора 6:

    ***ROUTER6 IS SENDING HELLOS BUT HEARS NOTHING, 
    STATE OF NEIGHBOR IS DOWN
    00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 on 
    Serial2.7 is dead
    00:03:53: OSPF: 170.170.11.7 address 170.170.11.7 on 
    Serial2.7 is dead, state DOWN
  2. Выходные данные отладки маршрутизатора 7:

    OSPF NOT ENABLED ON ROUTER7 YET
  3. Выходные данные отладки маршрутизатора 6:

    ***ROUTER6 SENDING HELLOS
    00:03:53: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), len 64, sending broad/multicast, proto=89
    00:04:03: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 64, sending broad/multicast, proto=89
  4. Выходные данные отладки маршрутизатора 7:

    OSPF NOT ENABLED ON ROUTER7 YET
  5. Выходные данные отладки маршрутизатора 7:

    ***OSPF ENABLED ON ROUTER7, BEGINS SENDING 
    HELLOS AND BUILDING A ROUTER LSA
    00:17:44: IP: s=170.170.11.7 (local), d=224.0.0.5 
    (Serial0.6), Len 64, sending broad/multicast, proto=89
    00:17:44: OSPF: Build router LSA for area 0, 
    router ID 170.170.11.7, seq 0x80000001
  6. Выходные данные отладки маршрутизатора 6:

    ***RECEIVE HELLO FROM ROUTER7
    00:04:04: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, 
    Len 64, rcvd 0, proto=89
    00:04:04: OSPF: Rcv hello from 170.170.11.7 area 0 from 
    Serial2.7 170.170.11.7
    00:04:04: OSPF: End of hello processing
  7. Выходные данные отладки маршрутизатора 6:

    ***ROUTER6 SEND HELLO WITH ROUTER7 ROUTERID 
    IN THE HELLO PACKET
    00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 68, sending broad/multicast, proto=89
  8. Выходные данные отладки маршрутизатора 7:

    ***ROUTER7 RECEIVES HELLO FROM ROUTER6 CHANGES 
    STATE TO 2WAY
    00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
    Len 68, rcvd 0, proto=89
    00:17:53: OSPF: Rcv hello from 170.170.11.6 area 0 from 
    Serial0.6 170.170.11.6
    00:17:53: OSPF: 2 Way Communication to 170.170.11.6 on 
    Serial0.6, state 2WAY
  9. Выходные данные отладки маршрутизатора 7:

    ***ROUTER7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD
    00:17:53: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
    seq 0x13FD opt 0x2 flag 0x7 Len 32
    00:17:53: IP: s=170.170.11.7 (local), d=224.0.0.5 
    (Serial0.6), Len 52, sending broad/multicast, proto=89
    00:17:53: OSPF: End of hello processing
  10. Выходные данные отладки маршрутизатора 6:

    ***ROUTER6 RECEIVES ROUTER7'S INITIAL DBD PACKET 
    CHANGES STATE TO 2-WAY
    00:04:13: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:04:13: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
    00:04:13: OSPF: 2 Way Communication to 170.170.11.7 on 
    Serial2.7, state 2WAY
  11. Выходные данные отладки маршрутизатора 6:

    ***ROUTER6 SENDS DBD PACKET TO ROUTER7 
    (MASTER/SLAVE NEGOTIATION - ROUTER6 IS SLAVE)
    00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
    seq 0xE44 opt 0x2 flag 0x7 Len 32
    00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 52, sending broad/multicast, proto=89
    00:04:13: OSPF: NBR Negotiation Done. We are the SLAVE
  12. Выходные данные отладки маршрутизатора 7:

    ***RECEIVE ROUTER6'S INITIAL DBD PACKET 
    (MTU MISMATCH IS RECOGNIZED)
    00:17:53: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
    Len 52, rcvd 0, proto=89
    00:17:53: OSPF: Rcv DBD from 170.170.11.6 on Serial0.6 
    seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART
    00:17:53: OSPF: Nbr 170.170.11.6 has larger interface MTU 
  13. Выходные данные отладки маршрутизатора 6:

    ***SINCE ROUTER6 IS SLAVE SEND DBD PACKET WITH 
    LSA HEADERS, 
    SAME SEQ# (0x13FD) TO ACK ROUTER7'S DBD. (NOTE SIZE OF PKT)
    00:04:13: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
    seq 0x13FD opt 0x2 flag 0x2 Len 1472
    00:04:13: IP: s=170.170.11.6 (local), d=224.0.0.5 
    (Serial2.7), Len 1492, sending broad/multicast, proto=89
  14. Выходные данные отладки маршрутизатора 7:

    ***NEVER RECEIVE ACK TO ROUTER7'S INITIAL DBD, 
    RETRANSMIT
    00:17:54: IP: s=170.170.11.7 (local), d=224.0.0.5 
    (Serial0.6), Len 68, sending broad/multicast, proto=89
    00:18:03: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
    seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
    Retransmitting DBD to 170.170.11.6 on Serial0.6 [1]

На этом этапе Маршрутизатор 6 продолжает пробовать к ACK начальный Пакет dbd от Маршрутизатора 7.

00:04:13: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5,
Len 68, rcvd 0, proto=89
00:04:13: OSPF: Rcv hello from 170.170.11.7 area 0 from
Serial2.7 170.170.11.7
00:04:13: OSPF: End of hello processing

00:04:18: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:18: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

00:04:18: OSPF: Send DBD to 170.170.11.7 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:18: IP: s=170.170.11.6 (local), d=224.0.0.5 
(Serial2.7), Len 1492, sending broad/multicast, proto=89

00:04:23: IP: s=170.170.11.6 (local), d=224.0.0.5 
(Serial2.7), Len 68, sending broad/multicast, proto=89

00:04:23: IP: s=170.170.11.7 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:23: OSPF: Rcv DBD from 170.170.11.7 on Serial2.7
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

Маршрутизатор 7 никогда не получает ACK от Маршрутизатора 6, потому что Пакет dbd от Маршрутизатора 7 является слишком большим для MTU Маршрутизатора 7. Маршрутизатор 7 неоднократно повторно передает Пакет dbd.

0:17:58: IP: s=170.170.11.7 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 170.170.11.6 on Serial0.6 [2]

00:18:03: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: IP: s=170.170.11.6 (Serial0.6), d=224.0.0.5, 
Len 68, rcvd 0, proto=89
00:18:03: OSPF: Rcv hello from 170.170.11.6 area 0 from
Serial0.6 170.170.11.6
00:18:03: OSPF: End of hello processing

00:18:04: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 68, sending broad/multicast, proto=89

00:18:03: OSPF: Send DBD to 170.170.11.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 170.170.11.6 on Serial0.6 [3]

00:18:08: IP: s=170.170.11.7 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
router-7#

Поскольку Маршрутизатор 6 имеет более высокий MTU, он продолжает принимать Пакет dbd от Маршрутизатора 7, пытается подтвердить их и остается в СОСТОЯНИИ ОБМЕНА.

Поскольку Маршрутизатор 7 имеет более низкий MTU, он игнорирует Пакеты dbd вместе с ACK от Маршрутизатора 6, продолжает повторно передавать начальный Пакет dbd и остается в состоянии Exstart.

Давайте посмотреть на некоторые шаги выше. В шаге 9 и 11 Маршрутизатор 7 и Маршрутизатор 6 передают их первые Пакеты dbd с флагом 0x7 набор как часть Основного/Ведомого согласования. После Основного/Ведомого определения Маршрутизатор 7 избран Ведущим устройством из-за, он - более высокий Router-ID. Флаги в шагах 13 и 14 ясно показывают, что Маршрутизатор 7 является Ведущим устройством (Флаг 0x7), и Маршрутизатор 6 является Ведомым устройством (Флаг 0x2).

В шаге 10 Маршрутизатор 6 получает Пакет dbd начальной буквы Маршрутизатора 7 и переходит его состояние к с 2 путями.

В шаге 12 Маршрутизатор 7 получает Пакет dbd начальной буквы Маршрутизатора 6 и распознает несоответствие MTU. (Маршрутизатор 7 распознает несоответствие MTU, так как маршрутизатор 6 включает MTU интерфейса в поле MTU интерфейса пакета DBD.). DBD начальной буквы Маршрутизатора 6 отклонен Маршрутизатором 7. Маршрутизатор 7 повторно передает начальный Пакет dbd.

Шаг 13 показывает, что Маршрутизатор 6, как ведомое устройство, принимает порядковый номер Маршрутизатора 7 и передает его второй Пакет dbd, содержащий заголовки его LSA, который увеличивает размер пакета. Однако Маршрутизатор 7 никогда не получает этот Пакет dbd, потому что это больше, чем MTU Маршрутизатора 7.

После п. 13 маршрутизатор 7 продолжает передавать исходные DBD пакеты маршрутизатору 6, тогда как маршрутизатор 6 продолжает передавать пакеты DBD, которые следуют номеру главной последовательности. Эта петля продолжается неопределенно, который препятствует любому маршрутизатору переход из состояния Exstart/Exchange.

Решение

Так как проблема вызвана несоответствием максимальных размеров блока данных (MTU), решение состоит в том, чтобы изменить любой MTU маршрутизатора для соответствия с соседним MTU. Обратите внимание на то, что Cisco IOS не поддерживает chang физического MTU на интерфейсе LAN (локальной сети) (таком как Ethernet или Token Ring). Когда проблема произойдет между маршрутизатором Cisco и другим маршрутизатором поставщика по Средам LAN, отрегулируйте MTU на другом маршрутизаторе поставщика.

Примечание: Программное обеспечение Cisco IOS версии 12.0(3) представило обнаружение несоответствия максимального размера блока данных (MTU) интерфейса. Это обнаружение включает OSPF, объявляя максимальный размер блока данных (MTU) интерфейса в Пакетах dbd, который является в соответствии с OSPF RFC 2178 leavingcisco.com, приложением G.9. Когда маршрутизатор получает пакет DBD, объявляющий MTU больше, чем допустимо для маршрутизатора, то последний игнорирует пакет DBD и соседний узел остается в состоянии exstart. Это предотвращает формирование смежности. Для решения этой проблемы гарантируйте, что MTU является тем же на обоих концах ссылки.

В программном обеспечении Cisco IOS 12.01 (3), команда настройки интерфейса ip ospf mtu-ignore была также представлена для выключения обнаружения несогласованности MTU; однако, это только необходимо в редких случаях, как показано в этой схеме:

12b.gif

Вышеупомянутая схема показывает порт Интерфейса для передачи распределенных данных по волоконно-оптическим каналам (FDDI) на Cisco Catalyst 5000 с Модульным коммутатором с функциями маршрутизатора (RSM), связанным с интерфейсом FDDI на Маршрутизаторе 2. Виртуальная локальная сеть (VLAN) на RSM является виртуальным интерфейсом Ethernet с MTU 1500, и интерфейс FDDI на Маршрутизаторе 2 имеет MTU 4500. Когда пакет получен на порту FDDI коммутатора, это переходит к объединительной плате, и FDDI к преобразованию/фрагментации Ethernet происходит в самом коммутаторе. Это - допустимая настройка, но с функцией обнаружения несогласованности MTU, соседство OSPF не сформировано промежуток маршрутизатор и RSM. Так как MTU для FDDI и Ethernet различны, команду ip ospf mtu-ignore целесообразно использовать на интерфейсе VLAN RSM, так чтобы OSPF перестал обнаруживать несовпадение MTU и сформировал смежность.

Следует отметить, что несоответствие MTU, невзирая на то, что наиболее распространенное, не является единственной причиной, что окружения OSPF застревают в состоянии Exstart/Exchange. Эта проблема чаще всего вызвана тем, что успешный обмен пакетами DBD невозможен. Однако основная причина могла быть любым из них:

  • Несоответствие MTU

  • Одноадресная передача не работает. В состоянии exstart маршрутизатор передает одноадресный пакет соседнему узлу для избрания ведущего устройства и ведомого устройства. Это не относится к соединению точка-многие точки, когда он отправляет многоадресный пакет. Возможные причины указаны ниже:

    • Неверное сопоставление виртуального канала (VC) в Технологии ATM или среды Frame Relay в избыточной сети.

    • Проблема MTU, заключающаяся в том, что маршрутизаторы могут передавать пакеты определенной длины.

    • Список доступа блокирует одноадресный пакет.

    • NAT работает на маршрутизаторе и преобразовывает одноадресный пакет.

  • Соседний узел между PRI и BRI/номеронабирателем.

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

Кроме того, OSPF RFC 2328 leavingcisco.com, раздел 10.3, сообщает, что exstart/процесс обмена инициируется для любого из этих событий (любой из которых мог быть вызван проблемами внутреннего программного обеспечения):

  • SequenceNumberMismatch

    • Неожиданный Порядковый номер DD

    • "I" бит неожиданно установлен

    • Поле параметра, отличающееся от поля последнего параметра, получено в Пакете dbd

  • BadLSReq

    • Сосед отправляет неопознанный LSA во время обмена.

    • Соседний узел запросил LSA во время процесса обмена, который не может быть найден

Когда OSPF не формирует соседние узлы, считает факторы упомянутыми выше, такие как физические средства связи и оборудование для организации сетей, для устренения проблемы.

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

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


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


Document ID: 13684