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

Почему канал по требованию OSPF продолжает поддерживать канал

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


Содержание


Введение

Когда ссылка Протокола OSPF настроена как канал требования, OSPF, Hellos подавлены, и периодические обновления lsa не лавинно рассылаются по ссылке. Эти пакеты переводят ссылку в рабочее состояние только, когда ими обмениваются впервые, или когда изменение происходит в информации, они содержат. Когда топология сети стабильна, это позволяет базовому Канальному уровню быть закрытым. Канал требования, который идет вверх и вниз, указывает на проблему, которая должна быть исследована. Этот документ демонстрирует некоторые возможные причины и предлагает решения.

Для получения дополнительной информации о канале требования обратитесь к Характеристике линия связи по требованию OSPF.

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

Требования

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

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

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

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

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

Сеть выборки

Упомянутая выше проблема описана со следующей схемой сети и конфигурацией.

/image/gif/paws/4808/dc1.gif

Маршрутизатор 1 Маршрутизатор 2
interface BRI1/1
 ip address 192.158.254.13 255.255.255.252
 ip ospf demand-circuit

router ospf 20
 network 192.158.254.0 0.0.0.255 area 0
interface BRI1/0
 ip address 192.158.254.14 255.255.255.252
 
 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

Примечание: Необходимо настроить канал требования в одном конце ссылки только. Однако при настройке этой команды на обоих концах, она не наносит ущерба.

В схеме выше, Маршрутизаторы 1 и 2 выполняют канал требования OSPF по соединению ISDN. Ссылка между Маршрутизаторами 1 и 2 продолжает подходить, который побеждает цель канала требования OSPF. Выходные данные команды show dialer показывают, что ссылка подошла из-за многоадресного пакета запроса приветствия OSPF.

Router1# show dialer
BRI1/1:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (2 secs)
Dialer state is data link layer up
Dial reason: ip (s=192.168.254.13, d=224.0.0.5)

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

Причина 1: Изменение сетевой топологии

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

Решение

Чтобы определить, переведена ли ссылка в рабочее состояние из-за изменения в топологии сети, используйте команду debug ip ospf monitor. Это показывает, какой LSA изменяется, как замечено ниже:

Router1# debug ip ospf monitor
OSPF: Schedule SPF in area 0.0.0.0
      Change in LS ID 192.168.246.41, LSA type R,
OSPF: schedule SPF: spf_time 1620348064ms wait_interval 10s

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

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

Причина 2: Тип сети определен как "Широковещание"

При настройке канала требования на ссылке тип канала должен быть определен как точка-точка или точка - многоточка. Любой другой тип канала может заставить ссылку подходить излишне, потому что OSPF, Hellos не подавлены, если тип сети - что-нибудь кроме точка-точка или точка - многоточка. Придерживающееся является примером конфигурации для иллюстрирования этой проблемы на Маршрутизаторах 1 и 2.

Маршрутизатор 1 Маршрутизатор 2
interface BRI1/1
 ip address 192.158.254.13 255.255.255.252
 ip ospf network broadcast

router ospf 20
 network 192.158.254.0 0.0.0.255 area 0
interface BRI1/0
 ip address 192.158.254.14 255.255.255.252
 ip ospf network broadcast
 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

С типом сети, определенным, как передано, OSPF, Hellos приносят соединение в каждом Интервале приветствия. Выходные данные show dialer показывают, что прошлый раз ссылка была переведена в рабочее состояние, был из-за Приветствие OSPF.

Router1# show dialer
BRI1/1:1 - dialer type = ISDN
Idle timer (120 secs), Fast idle timer (20 secs)
Wait for carrier (30 secs), Re-enable (2 secs)
Dialer state is data link layer up
Dial reason: ip (s=192.168.254.13, d=224.0.0.5)
Interface bound to profile Di1
Current call connected 00:00:08
Connected to 57654 (R2)

Решение

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

Маршрутизатор 1 Маршрутизатор 2
interface BRI1/1
 ip address 192.158.254.13 255.255.255.252

router ospf 20
 network 192.158.254.0 0.0.0.255 area 0
interface BRI1/0
 ip address 192.158.254.14 255.255.255.252
 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

Путем изменения типа сети на точка-точка или точка - многоточка, OSPF Hellos подавлены на ссылке, и соединение по требованию прекращает колебаться.

Причина 3: Один или несколько маршрутизаторов не понимают канал, устанавливаемый по требованию

Когда один или несколько маршрутизаторов в домене OSPF не понимают канал требования, периодическое обновление lsa происходит. Посмотрите, Когда Периодическое обновление lsa будет Передаваться По Каналу Требования OSPF? раздел этого документа, чтобы изучить, как решить этот вопрос.

Причина 4: Перераспределение маршрута хоста в OSPF-базу данных

Давайте рассматривать следующую схему сети как пример:

/image/gif/paws/4808/dc2.gif

Ссылка между Маршрутизаторами 1 и 2 является 131.108.1.0/24, и канал требования настроен между Маршрутизаторами 1 и 2. Маршрутизатор 1 перераспределяет маршруты Протокола RIP в OSPF.

Маршрутизатор 1
router ospf 1
 redistribute rip subnets
 network 131.108.1.0 0.0.0.255 area 1
!
router rip
 network 131.108.0.0

Так как тип инкапсуляции ссылки является PPP, оба маршрутизатора устанавливают маршрут хоста для другой стороны ссылки как показано ниже.

Router1# show ip route 131.108.1.2
Routing entry for 131.108.1.2/32
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via BRI1/1
      Route metric is 0, traffic share count is 1

Протокол IGRP и RIP являются протоколами классовой маршрутизации \(classful \), и поэтому инструкция сети в конфигурации для сети с разделением трафика по полосам 131.108.0.0. Из-за этого маршрут хоста 131.108.1.2/32, как полагают, инициируется RIP и перераспределен в OSPF как внешний маршрут как показано ниже.

Router1# show ip ospf database external 131.108.1.2

       OSPF Router with ID (131.108.3.1) (Process ID 1)


                Type-5 AS External Link States

  LS age: 298
  Options: (No TOS-capability, DC)
  LS Type: AS External Link
  Link State ID: 131.108.1.2 (External Network Number )
  Advertising Router: 131.108.3.1
  LS Seq Number: 80000001
  Checksum: 0xDC2B
  Length: 36
  Network Mask: /32
        Metric Type: 2 (Larger than any link state path)
        TOS: 0 
        Metric: 20 
        Forward Address: 0.0.0.0
        External Route Tag: 0

Когда ссылка выключается,/32 исчезает, и OSPF понимает это как изменение в топологии. Канал требования приносит соединение снова для размножения версии MAXAGE маски/32 ее соседнему узлу. Когда ссылка подходит, маска/32 становится допустимой снова, таким образом, перезагружен возраст LSA. Затем после того, как таймер простоя ссылки умирает, ссылка выключается снова. Этот процесс повторяет себя, и соединение по требованию продолжает колебаться. Существует три способа решить эту проблему, показанную ниже.

Решение 1: Используйте команду no peer neighbor-route

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

R1# configure terminal
R1(config)# interface BRI1/1
R1(config-if)# no peer neighbor-route

Решение 2: Используйте команду route-map

При перераспределении от RIP в OSPF используйте команду route-map и запретите/32, таким образом, это не становится введенным в базу данных OSPF. Эта команда настройки требуется только на маршрутизаторе, который делает перераспределение, которое в нашем примере является Маршрутизатором 1.

Сначала мы должны создать список доступа для соответствия с маской/32. Затем мы применяем этот список доступа к Карте маршрутизации и используем Карту маршрутизации при применении команды перераспределения как показано ниже.

R1# configure terminal
R1(config)# access-list 1 deny host 131.108.1.2
R1(config)# access-list 1 permit any

R1# configure terminal
R1(config)# route-map rip-ospf
R1(config-route-map)# match ip address 1

R1(config)# router ospf 1
R1(config-router)# redistribute rip subnets route-map rip-ospf

Решение 3: Использование другой крупной сети

Используйте другую крупную сеть или для RIP или для домена OSPF. Идея состоит в том, чтобы иметь другую крупную сеть на соединении по требованию поэтому, когда ссылка подходит при инкапсуляции PPP, это устанавливает маршрут хоста для другой стороны ссылки. Если маршрут хоста находится в другой крупной сети, чем та, используемая в RIP, RIP не владеет этим установленным PPP маршрутом хоста, потому что это не имеет инструкции сети для крупной сети. Схема сети ниже показов пример.

/image/gif/paws/4808/dc3.gif

В то время как домен OSPF (и соединение по требованию) находится под 131.108.0.0 сетями, домен протокола RIP теперь находится под 141.108.0.0 сетями.

Причина 5: OSPF-канал, устанавливаемый по требованию, настраивается через асинхронный интерфейс

При настройке канала требования через асинхронный (асинхронный) интерфейс тогда когда Уровень 2 выключается, фактический физический интерфейс выключается. Это вызывает изменение в базе данных OSPF, и асинхронный интерфейс возвращается снова для обмена базой данных. Уровень 2 выключается снова, и это вызовет изменение в базе данных снова, таким образом, этот процесс продолжит повторять себя.

Придерживающийся сценарий используется для репродуцирования вышеупомянутой проблемы.

/image/gif/paws/4808/dc4.gif

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

Маршрутизатор 1 Маршрутизатор 2
interface Async 1
 ip address 192.158.254.13 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 dialer in-band
 async default routing
 async mode dedicated
 ppp authentication chap
 ppp chap hostname Router1
 ppp chap password 7 13061E010803
!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1
interface Async 1
 ip address 192.158.254.14 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 dialer in-band
 dialer map ip 192.158.254.13 broadcast 12345
 dialer-group 2
 async default routing
 async mode dedicated
 ppp authentication chap callin
!
 dialer-list 2 protocol ip permit
!  
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

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

Rouer1# show ip ospf interface Async1
 Async1 is up, line protocol is up (spoofing)
   Internet Address 192.158.254.13/32, Area 1
   Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:869
   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:02
   Index 1/2, flood queue length 0
   Next 0x0(0)/0x0(0)
   Last flood scan length is 0, maximum is 1
   Last flood scan time is 0 msec, maximum is 0 msec
   Neighbor Count is 0, Adjacent neighbor count is 0
   Suppress hello for 0 neighbor(s)

Решение

Причина канал требования поддерживает внедрение ссылкой, состоит в том, потому что, когда Уровень 2 выключается после того, как время простоя истекает, целый интерфейс выключается. Но в случае BRI или PRI, когда один из каналов выключается, интерфейс все еще остается (в режиме спуфинга). Для решения проблемы, необходимо настроить интерфейс номеронабирателя, потому что она никогда не выключается. Интерфейс номеронабирателя остается (в режиме спуфинга).

Маршрутизатор 1 Маршрутизатор 2
interface Async 1
 no ip address 
 encapsulation ppp
 async default routing
 async mode dedicated
 dialer in-band
 dialer rotary-group 0 
!
interface Dialer0
 ip address 192.158.254.13 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 ppp authentication chap
 ppp chap hostname Router1
 ppp chap password 7 13061E010803
!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0
interface Async 1
 no ip address 
 encapsulation ppp
 async default routing
 async mode dedicated
 dialer in-band
 dialer rotary-group 0 
!
interface Dialer0
 ip address 192.158.254.14 255.255.255.252
 encapsulation ppp
 ip ospf demand-circuit
 dialer map ip 192.158.254.13 broadcast 12345
 dialer-group 2
 ppp authentication callin
!
dialer-list 2 protocol ip permit
! 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 0

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

Причина 6: Настройка канала связи по запросу протокола OSPF выполняется через многоканальный протокол РРР

Функция протокола PPP может быть использована для распределения нагрузки целей в случаях существуют несколько каналов глобальной сети. Одна важная вещь для запоминания с точки зрения OSPF является пропускной способностью протокола PPP. Когда сложные соединения будут объединены, пропускная способность многоканального интерфейса изменится.

Придерживающийся сценарий используется для репродуцирования вышеупомянутой проблемы.

/image/gif/paws/4808/dc5.gif

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

Маршрутизатор 1 Маршрутизатор 2
interface Multilink1 
 ip address 192.158.254.1 255.255.255.0 
 no cdp enable 
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
interface Serial0/1/0:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/1:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/2:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 

!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1
interface Multilink1 
 ip address 192.158.254.2 255.255.255.0 
 no cdp enable 
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
interface Serial0/1/0:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/1:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 
! 
interface Serial0/1/2:0 
 no ip address 
 ip route-cache distributed 
 encapsulation ppp 
 tx-queue-limit 26 
 no fair-queue 
 ppp multilink 
 multilink-group 1 

!
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

Следующий результат показывает, что существует три последовательных интерфейса, связанные вместе в протоколе PPP.

Router1# show ppp multilink   
 Multilink1, bundle name is Router2 
   Bundle up for 00:05:35 
   Bundle is Distributed 
   0 lost fragments, 0 reordered, 0 unassigned 
   0 discarded, 0 lost received, 3/255 load 
   0x1226 received sequence, 0x1226 sent sequence 
   Member links: 3 active, 0 inactive (max not set, min not set) 
     Serial1/0/0:0, since 00:05:35, no frags rcvd 
     Serial1/0/1:0, since 00:05:35, no frags rcvd 
     Serial1/0/2:0, since 00:05:35, no frags rcvd

Полоса пропускания интерфейса будет представлять объединенную пропускную способность ссылки, и эта пропускная способность будет использоваться в Расчете затрат для протокола OSPF.

Router1# show interface multilink 1 
Multilink1 is up, line protocol is up 
  Hardware is multilink group interface 
  Internet address is 192.168.254.1/24 
  MTU 1500 bytes, BW 5952 Kbit, DLY 100000 usec, 
     reliability 255/255, txload 3/255, rxload 3/255 
  Encapsulation PPP, loopback not set 
  Keepalive set (10 sec) 
  DTR is pulsed for 2 seconds on reset 
  LCP Open, multilink Open 
  Open: IPCP 
  Last input 00:00:00, output never, output hang never 
  Last clearing of "show interface" counters 00:06:39 
  Input queue: 1/75/0/0 (size/max/drops/flushes); Total output drops: 0 
  Queueing strategy: fifo 
  Output queue :0/40 (size/max) 
  5 minute input rate 241000 bits/sec, 28 packets/sec 
  5 minute output rate 241000 bits/sec, 28 packets/sec 
     6525 packets input, 9810620 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     6526 packets output, 9796112 bytes, 0 underruns 
     0 output errors, 0 collisions, 0 interface resets 
     0 output buffer failures, 0 output buffers swapped out 
     0 carrier transitions

Выходные данные show ip ospf interface показывают текущую стоимость OSPF, которая равняется 16.

Router1# show ip ospf interface multilink 1
      Multilink1 is up, line protocol is up 
        Internet Address 192.158.254.13/24, Area 1
       Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:16
       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:02
       Index 1/2, flood queue length 0
       Next 0x0(0)/0x0(0)
       Last flood scan length is 0, maximum is 1
       Last flood scan time is 0 msec, maximum is 0 msec
       Neighbor Count is 0, Adjacent neighbor count is 0
       Suppress hello for 0 neighbor(s)

Теперь ссылка выключается, и мы видим что в журнале:

Router1# show log | include down 
 
%LINK-3-UPDOWN: Interface Serial1/0/0:0, changed state to down 
%LINEPROTO-5-UPDOWN: Line protocol on Interface Serial1/0/0:0, changed state to down

Если мы проверим пропускную способность снова, то это будет другим, чем, что мы видели ранее. Теперь это показывает 3968, и связка (bundle) имеет только два интерфейса вместо три, потому что выключился один интерфейс. Примечание ниже интерфейса все еще:

Router1# show ppp multilink   
 Multilink1, bundle name is Router2 
   Bundle up for 00:05:35 
   Bundle is Distributed 
   0 lost fragments, 0 reordered, 0 unassigned 
   0 discarded, 0 lost received, 3/255 load 
   0x1226 received sequence, 0x1226 sent sequence 
   Member links: 2 active, 1 inactive (max not set, min not set) 
     Serial1/0/1:0, since 00:05:35, no frags rcvd 
     Serial1/0/2:0, since 00:05:35, no frags rcvd 
     Serial1/0/0:0 (inactive)

Кроме того, PPP multilink все еще обнаруживается, но стоимость OSPF теперь изменена на 25, так как одна ссылка не работает

Router1# show ip ospf interface multilink 1
      Multilink1 is up, line protocol is up 
        Internet Address 192.158.254.13/24, Area 1
       Process ID 1, Router ID 1.1.1.1, Network Type POINT_TO_POINT, Cost:25
       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:02
       Index 1/2, flood queue length 0
       Next 0x0(0)/0x0(0)
       Last flood scan length is 0, maximum is 1
       Last flood scan time is 0 msec, maximum is 0 msec
       Neighbor Count is 0, Adjacent neighbor count is 0
       Suppress hello for 0 neighbor(s)

Это, что вызовет вычисление SPF и OSPF, переведет канал требования в рабочее состояние. Если ссылка продолжает колебаться тогда, мы можем видеть, что канал требования продолжает колебаться, потому что стоимость будет изменена каждый раз, когда ссылка складывает или удалена из пакет протокола PPP.

Решение

PPP multilink поддерживается в OSPF, но, пока вся ссылка в связке (bundle) не ложится спать, канал требования будет стабилен. Как только ссылка выключается, даже при том, что существует no IP address, привязанный к ней, она будет влиять на Расчет затрат для протокола OSPF, и из-за этого, OSPF выполнит SPF, чтобы повторно вычислить оптимальные пути. Для решения этой проблемы единственное решение состоит в том, чтобы настроить стоимость OSPF вручную со следующей командой.

Маршрутизатор 1 Маршрутизатор 2
interface Multilink1 
 ip address 192.158.254.1 255.255.255.0 
 no cdp enable  
 ip ospf cost 10
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1
interface Multilink1 
 ip address 192.158.254.2 255.255.255.0 
 no cdp enable  
 ip ospf cost 10
 ppp multilink 
 no ppp multilink fragmentation 
 multilink-group 1 
! 
router ospf 20
 network 192.158.254.0 0.0.0.255 area 1

Эта команда удостоверится, что каждый раз существует ссылка, которая добавлена или удалена в пакете протокола PPP, на стоимость OSPF не будут влиять. Это будет стабилизировать канал требования OSPF по PPP multilink.

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

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


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


Document ID: 4808