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

Почему OSPF не образует смежности на PRI, BRI или интерфейсе устройства для набора номера?

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


Содержание


Введение

Когда интерфейсы номеронабирателя настроены как каналы типа точка-точка, эти Технические примечания объясняют проблему с формированием соседства OSPF.

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

Требования

Для этого документа отсутствуют особые требования.

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

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

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

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

Проблема

Тип сети OSPF на Primary Rate Interface (PRI), Интерфейсе (BRI) и интерфейсах номеронабирателя является точка-точка, что означает, что интерфейс не может сформировать смежность с несколькими соседними узлами. Типичная проблема, когда PRI, BRI или интерфейсы номеронабирателя пытаются сформировать соседство OSPF, является соседним узлом, застревает в exstart/процессе обмена. Рассмотрим пример.

/image/gif/paws/13691/20a.gif

Использование команды show ip ospf neighbor, мы видим, что режим работы с соседними узлами застревает в "Exstart".

RTR-A# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.3           1   EXSTART/  -     00:00:37    3.3.3.3         Serial6/0:23
3.3.3.4           1   EXSTART/  -     00:00:39    3.3.3.4         Serial6/0:23

RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:36    3.3.3.2         BRI0

RTR-C# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
3.3.3.2           1   EXSTART/  -     00:00:35    3.3.3.2         BRI0

Конфигурация RTR-B показывает, что network-type является точка-точка:

RTR-B# show ip ospf interface bri0 
     BRI0 is up, line protocol is up (spoofing) 
       Internet Address 3.3.3.3/24, Area 2 
       Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_POINT, Cost: 1562 
       Transmit Delay is 1 sec, State POINT_TO_POINT, 
       Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 
         Hello due in 00:00:06 
       Index 1/1, flood queue length 0 
       Next 0x0(0)/0x0(0) 
       Last flood scan length is 1, maximum is 1 
       Last flood scan time is 0 msec, maximum is 0 msec 
       Neighbor Count is 1, Adjacent neighbor count is 0 
       Suppress hello for 0 neighbor(s) 

Мы можем отладить эту ситуацию с помощью команды debug ip ospf adj. Давайте посмотреть на некоторый пример выходных данных, взятый при выполнении этой команды на RTR-B на рисунке выше:

1: Send DBD to 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x7 len 32 
2: Rcv DBD from 3.3.3.2 on BRI0 seq 0x1D06 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXSTART 
3: First DBD and we are not SLAVE 
4: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB41 opt 0x42 flag 0x2 len 92 mtu 
   1500 state EXSTART 
5: NBR Negotiation Done. We are the MASTER 
6: Send DBD to 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x3 len 92 
7: Database request to 3.3.3.2 
8: sent LS REQ packet to 3.3.3.2, length 12 
9: Rcv DBD from 3.3.3.2 on BRI0 seq 0x250 opt 0x42 flag 0x7 len 32 
   mtu 1500 state EXCHANGE 
10: EXCHANGE - inconsistent in MASTER/SLAVE 
11: Bad seq received from 3.3.3.2 on BRI0 
12: Send DBD to 3.3.3.2 on BRI0 seq 0x2441 opt 0x42 flag 0x7 len 32 
13: Rcv DBD from 3.3.3.2 on BRI0 seq 0x152C opt 0x42 flag 0x2 len 92 
    mtu 1500 state EXSTART 
14: Unrecognized dbd for EXSTART 
15: Rcv DBD from 3.3.3.2 on BRI0 seq 0xB42 opt 0x42 flag 0x0 len 32 
    mtu 1500 state EXSTART 
16: Unrecognized dbd for EXSTART 

Линии 1 - 3: RTR-B передает первый DBD к 3.3.3.2 (RTR-A) с seq 0xB41 и получает первый DBD от 3.3.3.2 (RTR-A) с seq# 0x1D06. Согласование с соседними устройствами все еще не завершено.

Линии 4 - 6: RTR-B получает ответ от указания 3.3.3.2 (RTR-A) что первый DBD полученного RTR-B RTR-A. Так как RTR-B имеет более высокий идентификатор маршрутизатора, RTR-A выбирает себя ведомым устройством. После получения подтверждения от RTR-A RTR-B объявляет себя ведущее устройство и передает первый DBD с данными в нем. Примечание порядковый номер, который является 0xB42. Так как RTR-B является ведущим устройством, только он может инкрементно увеличить порядковый номер.

Линия 7: RTR-B запрашивает данные от RTR-A, так как RTR-A указал, что это имеет больше данных для передачи (набор флага к 0x2 дюймам последний DBD, полученный от RTR-A).

Линия 8: RTR-B передает пакет запроса состояния соединения к 3.3.3.2 (RTR-A). Это - тип пакета OSPF 3. Этот пакет обычно передается к IP-адресу соседнего узла. В этом случае IP-адрес соседнего узла является своим идентификатором маршрутизатора.

Линии 9 - 11: RTR-B получает ответ от ведомого устройства (RTR-A) с полностью количество другой последовательности и флаг 0x7, который является флагом Init. Этот DBD был предназначен для другого маршрутизатора (наиболее вероятный RTR-C), но RTR-B неправильно получил его. RTR-B объявляет, что существует несоответствие, потому что флаг 0x7 означает, что ведомое устройство изменило свой статус на ведущее устройство путем установки MS (Основной/Ведомый) бит во время обмена смежности. RTR-B также жалуется на порядковый номер, потому что это неисправно. Ведомое устройство должно всегда придерживаться порядкового номера ведущего устройства.

Линия 12: RTR-B повторно инициализирует смежность путем передачи первого DBD к 3.3.3.2 для переизбирания ведущего устройства и ведомого устройства.

Линии 13 - 14: RTR-B получает DBD от 3.3.3.2 (RTR-A), указывая, что это - ведомое устройство, не распознавая порядковый номер RTR-B. RTR-B Объявляет, что не распознает этот DBD, так как основное и ведомое согласование еще не завершено. Этот Пакет dbd был предназначен для другого маршрутизатора.

Линия 15: RTR-B получает ответ от 3.3.3.2 (RTR-A) для старого DBD, но слишком поздно, потому что RTR-B уже повторно инициализировал процесс смежности.

Линия 16: RTR-B не в состоянии распознавать этот DBD, потому что это для "старой" смежности, которую уже разъединил RTR-B.

Этот процесс повторится бесконечно.

Решение

Согласно разделу 8.1 из RFC 2328 leavingcisco.com, OSPF передает пакет групповой адресации за network-type "точка-точка" даже после того, как интерфейс достигнет 2-канального состояния. Так как RTR-A пытается сформировать смежности и с RTR-B и с RTR-C, RTR-B получает Пакеты dbd, предназначенные для RTR-C, и RTR-C получает Пакеты dbd, предназначенные для RTR-B.

Для решения этой проблемы измените тип сети на всех маршрутизаторах к точка - многоточка. Это изменяет поведение OSPF передать одноадресные пакеты после 2-канального состояния. Теперь RTR-B получает только пакеты, предназначенные для себя, и RTR-C получает пакеты, предназначенные для себя. Изменение network-type таким образом гарантирует, что маршрутизатор OSPF сформирует смежность на PRI, BRI или интерфейсе номеронабирателя.

Для изменения network-type введите придерживающиеся команды настройки, заканчивая каждую линию путем нажимания ENTER. Мы изменим RTR-B как пример.

RTR-B# configure terminal 
RTR-B(config)# int bri 0 
RTR-B(config-if)# ip ospf network point-to-multipoint 
RTR-B(config-if)# end 

Теперь, если мы посмотрели на команды показа для RTR-B, мы можем проверить, что network-type является точка - многоточка, и состояние полно.

RTR-B# show ip ospf interface bri0 
BRI0 is up, line protocol is up (spoofing) 
  Internet Address 3.3.3.3/24, Area 2 
  Process ID 1, Router ID 3.3.3.3, Network Type POINT_TO_MULTIPOINT, Cost: 1562 
  Transmit Delay is 1 sec, State POINT_TO_MULTIPOINT, 
  Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 
    Hello due in 00:00:16 
  Index 1/1, flood queue length 0 
  Next 0x0(0)/0x0(0) 
  Last flood scan length is 1, maximum is 1 
  Last flood scan time is 0 msec, maximum is 0 msec 
  Neighbor Count is 1, Adjacent neighbor count is 1 
    Adjacent with neighbor 172.16.141.10 
  Suppress hello for 0 neighbor(s) 
  
RTR-B# show ip ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.141.10     1   FULL/  -        00:01:36    3.3.3.2         BRI0 

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

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


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


Document ID: 13691