Оптические сети : Synchronous Optical NETwork (SONET)

Устранение проблем "Line Protocol is Down" в интерфейсах POS

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


Содержание


Введение

В этом документе описано устранение неполадок интерфейса маршрутизатора пакетной связи по SONET (POS) в состоянии канального протокола «down» (отключено).

Кроме помощи в определении отключения протокола канала, в нем объяснено использование команд show и debug для устранения проблемы при инкапсуляции протокола Point-to-Point Protocol (PPP) и Высокоуровневое Управление Каналом Передачи Данных (HDLC). Это также обходит вас через типичный сценарий устранения проблем на основе задокументированной лабораторной установки.

Интерпретируйте Команду show interface pos

В целях документа выходные данные show interface на месте продажи как показано в выходных данных ниже. Обратите внимание на выделенные элементы на экране и комментарии:

RTR12410-2#show interface pos 6/0 
   POS6/0 is up, line protocol is down 

!---  The line protocol is down
.
     Hardware is Packet over SONET 
  MTU 4470 bytes, BW 2488000 Kbit, DLY 100 usec, rely 255/255, load 1/255 
     Encapsulation HDLC, crc 32, loopback not set 

!---  The loopback has not been set.

     Keepalive set (10 sec) 

!---  The keepalive is set as every ten seconds.

     Scramble disabled 
  Last input never, output 00:00:05, output hang never 
  Last clearing of "show interface" counters never 
  Queueing strategy: fifo 
  Output queue 0/40, 0 drops; input queue 0/75, 0 drops 
  5 minute input rate 0 bits/sec, 0 packets/sec 
  5 minute output rate 0 bits/sec, 0 packets/sec 
     0 packets input, 0 bytes, 0 no buffer 
     Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 
              0 parity 
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 
     3 packets output, 1074 bytes, 0 underruns 
     0 output errors, 0 applique, 1 interface resets 
     0 output buffer failures, 0 output buffers swapped out 
     2 carrier transitions

Справочник по командам IOS� Cisco сообщает, что поле status протокола линии связи "указывает, считают ли программные процессы, которые обрабатывают протокол линии связи, линию применимой (т.е. пакеты Keepalive успешны), или было ли это приведено в нерабочее состояние администратором".

Кроме того, в выводе команды "show interface pos" следует обратить внимание на следующие поля:

  • Encapsulation — Метод инкапсуляции, назначенный на интерфейс.

  • loopback – показывает, настроена ли обратная петля.

  • команда keepalive – указывает, установлены ли элементы поддержки установленного соединения.

Обзор пакета протоколов POS

Эта схема иллюстрирует стек протоколов, используемый на Интерфейсе пакетной передачи POS (по сети Sonet).

/image/gif/paws/16152/gspos_a0.gif

Интерфейсы POS поддерживают различные инкапсуляции - HDLC, PPP и Frame Relay. Таким образом передачей пакета по сети SONET является более точно PPP OVER SONET или HDLC OVER SONET. Этот документ не покрывает Инкапсуляцию Frame Relay.

PPP и HDLC тесно связаны и совместно используют эти характеристики:

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

  • Обеспечивает функцию выявления кадра, которая однозначно определяет для принимающего устройства, где начинается и заканчивается пакет или кадр. В HDLC и PPP, выявление кадра предоставлено посредством специального шаблона межкадрового заполнения или холостой комбинации. Образец является 0x7E, или 0111 1110.

  • Определение минимальной и максимальной длины пакета.

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

Однако, несмотря на схожесть, PPP и HDLC – это не одно и то же, и, кроме того, для устранения неисправностей в них используются разные команды отладки.

Используйте команды отладки

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

caution Внимание.  : Так как выводу отладки назначают высокий приоритет в Процессе ЦПУ, он может представить неприменимую систему. По этой причине использовать команды debug рекомендуется только для устранения конкретных проблем или во время сеансов по устранению проблем совместно с персоналом технической поддержки Cisco. Более того, лучше всего использовать команды отладки в периоды низкого сетевого трафика и присутствия в сети небольшого количества пользователей. Отладка в эти периоды уменьшает вероятность того, что возросшие требования к ресурсам для использования команды debug повлияют на использование системы. Закончив использование команды "debug", не забудьте отключить ее с помощью специальной команды "no debug" или "no debug all".

Эти команды отладки полезны для того, когда вы устраняете проблемы Интерфейса пакетной передачи POS (по сети Sonet). Дополнительную информацию о функции и результатах выполнения каждой из этих команд см. справочных руководствах по командам отладки Cisco:

  • debug serial interface - проверяет, увеличивается ли количество пакетов проверки активности HDLC. Если приращения не происходит, на интерфейсной карте или в сети возникла проблема синхронизации.

  • debug ppp negotiation - показывает пакеты PPP, переданные при запуске PPP, в которых согласовывались параметры PPP.

  • пакет debug ppp — Показывает пакеты PPP, передаваемые и полученные. Эта команда показывает дампы пакетов нижнего уровня.

  • debug ppp errors – отображает ошибки PPP (например, недопустимые или неправильно сформированные кадры), связанные с процессом согласования и поддержания соединения PPP.

Обратитесь к Устранению проблем Проблем последовательного канала для получения дополнительной информации.

Отключение линейного протокола с HDLC

HDLC - тип инкапсуляции по умолчанию на интерфейсе POS маршрутизатора. HDLC – международный стандарт, но реализация поставщика изменяет одно или несколько полей, заголовок или трейлер в размере и формате. Спецификация GR-253 Telecordia, которая определяет SONET, обсуждает Отображение HDLC на SONET (см. Проблему 3, Раздел 3.4.2.3, pp.3-59.) Это указывает, что кадр HDLC выровнен байтом с Кадром SONET, и также задает самосинхронизирующийся скремблер, Cyclic Redundancy Checks (CRC) и использование образца флага HDLC как межкадровое заполнение для составления переменной природы поступающих кадров HDLC.

Если команда show interface pos показывает, что линия и протокол болеют инкапсуляцией HDLC, можно использовать команду debug serial interface для изоляции неполадок на линии как причины ошибки подключения. HDLC использует пакеты keepalive и сообщает значения трех счетчиков в выходе отладки:

  • myseq — Увеличивается к одному каждому разу, когда маршрутизатор передает пакет keepalive к удаленному маршрутизатору.

  • mineseen – Значение счетчика mineseen соответствует последнему порядковому номеру счетчика myseq, получение которого от маршрутизатора подтвердил удаленный маршрутизатор. Удаленный маршрутизатор хранит эту величину в счетчике yourseen и посылает ее маршрутизатору в пакеты keepalive.

  • yourseen - Отражает значение номера последовательности myseq, полученного маршрутизатором в пакете keepalive от удаленного маршрутизатора.

Если значения keepalive в mineseq, yourseen, и поля myseen не инкрементно увеличиваются в каждой каждой следующей линии выходных данных, существует проблема в одном конце соединения. Когда различие в значениях в myseq и полях mineseen превышает три, линия выключается, и интерфейс перезагружен.

Когда пакеты Keepalive получены должным образом обоими концами, это - пример выходных данных от команды debug serial interface для подключения HDLC.

hswan-12008-2a#debug serial interface 
Serial network interface debugging is on 
hswan-12008-2a# 
Oct 31 11:47:16: POS4/0: HDLC myseq 180, mineseen 0*, yourseen 1, line up 
Oct 31 11:47:17: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!---  Local router sees a remote keepalive with a sequence number of 1. 

Oct 31 11:47:26: POS4/0: HDLC myseq 181, mineseen 181*, yourseen 2, line up 
Oct 31 11:47:36: POS4/0: HDLC myseq 182, mineseen 182*, yourseen 3, line up 
Oct 31 11:47:46: POS4/0: HDLC myseq 183, mineseen 183*, yourseen 4, line up 
Oct 31 11:47:56: POS4/0: HDLC myseq 184, mineseen 184*, yourseen 5, line up 
Oct 31 11:48:06: POS4/0: HDLC myseq 185, mineseen 185*, yourseen 6, line up 

!---  Keepalives are sent every 10 seconds by default. 
!---  Both sides report incrementing sequence numbers. 

Это - пример выходных данных от команды debug serial interface для подключения HDLC, когда удаленный интерфейс закрыт, и локальный интерфейс пропускает больше чем три пакетов Keepalive.

hswan-12008-2a# 
Oct 31 11:49:46: POS4/0: HDLC myseq 195, mineseen 192, yourseen 13, line down 
Oct 31 11:49:47: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to down 

!---  The local router has failed to receive three keepalives and 
!---  brings down the line protocol.  Note the difference between 
!---  "myseq 195" and "mineseen 192". 

Oct 31 11:49:56: POS4/0: HDLC myseq 196, mineseen 192, yourseen 13, line down 
Oct 31 11:50:06: POS4/0: HDLC myseq 197, mineseen 192, yourseen 13, line down 
Oct 31 11:50:16: POS4/0: HDLC myseq 198, mineseen 192, yourseen 13, line down 
Oct 31 11:50:26: POS4/0: HDLC myseq 199, mineseen 192, yourseen 13, line down 
Oct 31 11:50:36: POS4/0: HDLC myseq 200, mineseen 0*, yourseen 1, line up 
Oct 31 11:50:37: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS4/0, 
changed state to up 

!---  After you execute the no shut command on the remote router, 
!---  the local router receives a keepalive again and brings up 
!---  the line protocol. 

Oct 31 11:50:46: POS4/0: HDLC myseq 201, mineseen 201*, yourseen 2, line up 
Oct 31 11:50:56: POS4/0: HDLC myseq 202, mineseen 202*, yourseen 3, line up 
Oct 31 11:51:06: POS4/0: HDLC myseq 203, mineseen 203*, yourseen 4, line up 
Oct 31 11:51:16: POS4/0: HDLC myseq 204, mineseen 204*, yourseen 5, line up 
Oct 31 11:51:26: POS4/0: HDLC myseq 205, mineseen 205*, yourseen 6, line up 
Oct 31 11:51:36: POS4/0: HDLC myseq 206, mineseen 206*, yourseen 7, line up 

!---  After the shut/no shut, the remote router re-initialized its 
!---  sequence number.
 

Линейный протокол неактивен при использовании PPP

RFC 1661 leavingcisco.com определяет PPP как протокол. Интерфейсы пакетной передачи POS (по сети Sonet) поддерживают PPP в High-Level Data Link Control (HDLC) - как формирование кадров, как задано в RFC 1662 leavingcisco.com, для инкапсуляции данных на Уровне 2. Формат фрейма для PPP в Кадрировании по типу HDLC показывают на этом рисунке.

gspos_a2.gif

RFC 2615 задает использование инкапсуляции PPP через каналы SONET или SDH. PPP был разработан для использования на каналах типа точка-точка и подходит для SONET или ссылок SDH, которые обеспечены как двухточечные тракты даже в топологиях кольца.

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

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

Эта таблица приводит три класса пакетов LCP:

Класс пакета LCP Типы пакетов LCP Цель
Конфигурация канала Configure-Request, Configure-Ack, Configure-Nak и Configure-Reject Используется для установки и настройки канала.
Завершение канала Terminate-Request и оконечный Ack Используемый для завершения ссылки.
Обслуживание канала Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request Используется для управления каналом и его отладки.

Конфигурация канала

LCP используется для установления связи через обмен пакетами конфигурации. Обмен завершается и выполняется переход в состояние LCP Opened, как только происходит отправка и получение пакета Configure-Ack.

Этот пример выходных данных перехватывает этап конфигурации канала LCP на Интерфейсе пакетной передачи POS (по сети Sonet):

4d01h: PO3/1 LCP: State is Open 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 LCP_UP 
(0x639FCAD8) id 0 (0s.) queued 1/1/2 
4d01h: PO3/1 PPP: Phase is UP 
4d01h: PO3/1 IPCP: O CONFREQ [Closed] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 PPP: I pkt type 0x8021, datagramsize 14 
4d01h: PO3/1 IPCP: I CONFREQ [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: O CONFACK [REQsent] id 1 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.2 (0x0306AC100102) 
4d01h: PO3/1 IPCP: I CONFACK [ACKsent] id 152 len 10 
4d01h: PO3/1 IPCP:    Address 172.16.1.1 (0x0306AC100101) 
4d01h: PO3/1 IPCP: State is Open 
4d01h: PO3/1 IPCP: Install route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to up 

Примечание: Интерфейс пакетной передачи POS (по сети Sonet), настроенный с инкапсуляцией PPP непрерывно, пытается установить сеанс PPP. Поэтому в случае постоянных неполадок протокол линии связи будет периодически ненадолго активизироваться, даже если отсоединить оптоволоконный кабель.

Обслуживание связи (с поддержкой активности)

Запрос эха LCP и пакеты Эха - ответа предоставляют механизм кольцевой проверки Уровня 2 для обоих направлений ссылки. При получении эхо-запроса в открытом состоянии LCP должен быть передан эхо-ответ.

Эта схема от RFC 1661 иллюстрирует формат пакета keepalive PPP.

/image/gif/paws/16152/16152a.gif

Эти пакеты LCP включают эти ключевые поля:

  • Code - 9 для эхо-запроса и 10 для эхо-ответа.

  • Identifier — На передаче должно быть изменено поле Identifier каждый раз, когда содержание Изменений поля данных и каждый раз, когда допустимый ответ был получен для предыдущего запроса. Для повторных передач Идентификатор может остаться неизменным. На приеме поле Identifier Запроса эха скопировано в поле Identifier пакета Эха - ответа.

  • Системный код — Поле системного кода является четырьмя октетами и способствует обнаружению ссылок, которые находятся в состоянии обратной передачи. Пока о Параметре конфигурации системного кода успешно не выполняют согласование, Системный код должен быть передан как ноль. Подробное объяснение см. в разделе "Параметр настройки системного кода в RFC 1661".

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

Когда пакеты Keepalive включены, вот пример debug ppp negotiation:

4d01h: PO3/1 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x1A45933B 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 16 
4d01h: PO3/1 LCP: I ECHOREP [Open] id 1 len 12 magic 0x00000002 
4d01h: PO3/1 LCP: Received id 1, sent id 1, line up 

Завершение канала

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

LCP использует Оконечные пакеты для закрытия ссылки. Отправитель Terminate-Request должен разъединить после получения Оконечного Ack, или после того, как истечет счетчик Перезапуска. Устройство-получатель запроса Terminate-Request ожидает отключения другого устройства и не отключается до тех пор, пока не пройдет хотя бы один период до перезагрузки после отправки Terminate-Ack.

/image/gif/paws/16152/16152a.gif

Оконечные пакеты LCP включают эти ключевые поля:

  • Код — 5 для Terminate-Request и 6 для оконечного Ack.

  • Identifier — На передаче должно быть изменено поле Identifier каждый раз, когда содержание Изменений поля данных, и каждый раз, когда допустимый ответ был получен для предыдущего запроса. Для повторных передач Идентификатор может остаться неизменным. При приеме значение поля идентификатора запроса Terminate-Request копируется в поле идентификатора пакета Terminate-Ack.

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

Вот пример выходных данных debug ppp negotiation при получении пакета TERMREQ:

4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 8 
4d01h: PO3/1 LCP: I TERMREQ [Open] id 4 len 4 
4d01h: PO3/1 LCP: O TERMACK [Open] id 4 len 4 
4d01h: PO3/1 PPP: I pkt type 0xC021, datagramsize 18 
4d01h: PO3/1 IPCP: State is Closed 
4d01h: PO3/1 PPP: Phase is TERMINATING 
4d01h: PO3/1 LCP: I CONFREQ [TERMsent] id 1 len 14 
4d01h: PO3/1 LCP:    MRU 1500 (0x010405DC) 
4d01h: PO3/1 LCP:    MagicNumber 0x00000002 (0x050600000002) 
4d01h: PO3/1 LCP: Dropping packet, state is TERMsent 

!---  While in the TERMsent state, PPP should drop all other packets. 

4d01h: PO3/1 IPCP: Remove route to 172.16.1.2 
4d01h: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS3/1, 
changed state to down 

Пример последовательности диагностики

В этом разделе описываются пример сценария устранения проблем для ссылки POS с помощью инкапсуляции PPP. Это использует эти конфигурации:

Конфигурация маршрутизатора A
interface POS1/0 
 ip address 1.1.1.6 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16 
 clock source internal

Конфигурация маршрутизатора B
interface POS2/0 
 ip address 1.1.1.5 255.255.255.0 
 no ip directed-broadcast 
 encapsulation ppp 
 crc 16

Примечание: Эти отладки были перехвачены на двух маршрутизаторах во встречно-параллельной лабораторной установке. Таким образом синхронизация установлена во внутренний на одной стороне и не выполнять своих обязательств для выравнивания на другом конце.

debug ppp negotiation

Эти выходные данные иллюстрируют обмен пакетами, перехваченный с debug ppp negotiation во время этапа установления соединения LCP.

Выходные данные отладки маршрутизатора RouterA
Router A Debug Output  
(1)  

!---  The router sends an outgoing confreq.

hswan-12008-2a#
*Nov  7 08:27:00: %LINK-3-UPDOWN: Interface POS1/0, changed state to up
*Nov  7 08:27:00: PO1/0 PPP: Treating connection as a dedicated line
*Nov  7 08:27:00: PO1/0 PPP: Phase is ESTABLISHING, Active Open
*Nov  7 08:27:00: PO1/0 LCP: O CONFREQ [Closed] id 7 len 14 
*Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D)
(4)  

!---  Router A receives an incoming confreq from router B. 

*Nov  7 08:27:00: PO1/0 LCP: I CONFREQ [REQsent] id 45 len 14 
*Nov  7 08:27:00: PO1/0 LCP: MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP: MagicNumber 0x2631E6D2 (0x05062631E6D2)
(5) 

!---  Router A responds with a confack and receives a 
!---  confack from Router B.  The LCP state is open. 
 
*Nov  7 08:27:00: PO1/0 LCP: O CONFACK [REQsent] id 45 len 14 
*Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 08:27:00: PO1/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2) 
*Nov  7 08:27:00: PO1/0 LCP: I CONFACK [ACKsent] id 7 len 14 
Nov  7 08:27:00: PO1/0 LCP:    MRU 4470 (0x01041176)
*Nov  7 08:27:00: PO1/0 LCP: MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
*Nov  7 08:27:00: PO1/0 LCP: State is Open
*Nov  7 08:27:00: PO1/0 PPP: Phase is UP
(7) 

!---  Router A begins the IPCP stage and negotiates an IP address. 
!---  In this setup, the peer router already has an address and 
!---  sends it in a confreq. If the peer router accepts the address, 
!---  it responds with a confack.

*Nov  7 08:27:00: PO1/0 IPCP: O CONFREQ [Closed] id 7 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106)
*Nov  7 08:27:00: PO1/0 CDPCP: O CONFREQ [Closed] id 7 len 4 
*Nov  7 08:27:00: PO1/0 IPCP: I CONFREQ [REQsent] id 9 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105)
*Nov  7 08:27:00: PO1/0 IPCP: O CONFACK [REQsent] id 9 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.5 (0x030601010105)
*Nov  7 08:27:00: PO1/0 CDPCP: I CONFREQ [REQsent] id 9 len 4 
*Nov  7 08:27:00: PO1/0 CDPCP: O CONFACK [REQsent] id 9 len 4 
*Nov  7 08:27:00: PO1/0 IPCP: I CONFACK [ACKsent] id 7 len 10 
*Nov  7 08:27:00: PO1/0 IPCP: Address 1.1.1.6 (0x030601010106)
*Nov  7 08:27:00: PO1/0 IPCP: State is Open
*Nov  7 08:27:00: PO1/0 CDPCP: I CONFACK [ACKsent] id 7 len 4 
*Nov  7 08:27:00: PO1/0 CDPCP: State is Open
*Nov  7 08:27:00: PO1/0 IPCP: Install route to 1.1.1.5
*Nov  7 08:27:01: %LINEPROTO-5-UPDOWN: Line protocol on 
Interface POS1/0, changed state to up

Отладочные выходные данные для маршрутизатора B
(2) 

!---  Router  B receives an incoming  confrq from Router A. 

hswan-12008-2b#
Nov  7 10:29:19.043: PO2/0 LCP: I CONFREQ [Open] id 7 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
Nov  7 10:29:19.043: PO2/0 IPCP: State is Closed
Nov  7 10:29:19.043: PO2/0 CDPCP: State is Closed
Nov  7 10:29:19.043: PO2/0 PPP: Phase is TERMINATING
Nov  7 10:29:19.043: PO2/0 PPP: Phase is ESTABLISHING
(3) 

!---  Router B sends its own LCP confreq.
  
Nov  7 10:29:19.043: PO2/0 LCP: O CONFREQ [Open] id 45 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2)
(6) 

!---  Router B responds with a confack and receives a confack from Router A. 
 
The LCP state is open.  
Nov  7 10:29:19.043: PO2/0 LCP: O CONFACK [Open] id 7 len 14 
Nov  7 10:29:19.043: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.043: PO2/0 LCP:    MagicNumber 0x4F46AF4D (0x05064F46AF4D) 
Nov  7 10:29:19.043: PO2/0 IPCP: Remove route to 1.1.1.6
Nov  7 10:29:19.047: PO2/0 LCP: I CONFACK [ACKsent] id 45 len 14 
Nov  7 10:29:19.047: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 10:29:19.047: PO2/0 LCP:    MagicNumber 0x2631E6D2 (0x05062631E6D2) 
Nov  7 10:29:19.047: PO2/0 LCP: State is Open
Nov  7 10:29:19.047: PO2/0 PPP: Phase is UP
(8) 

!---  Router B also begins the IPCP stage and negotiates an IP address.
  
Nov  7 10:29:19.047: PO2/0 IPCP: O CONFREQ [Closed] id 9 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 10:29:19.047: PO2/0 CDPCP: O CONFREQ [Closed] id 9 len 4 
Nov  7 10:29:19.047: PO2/0 IPCP: I CONFREQ [REQsent] id 7 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 10:29:19.047: PO2/0 IPCP: O CONFACK [REQsent] id 7 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 10:29:19.047: PO2/0 CDPCP: I CONFREQ [REQsent] id 7 len 4 
Nov  7 10:29:19.047: PO2/0 CDPCP: O CONFACK [REQsent] id 7 len 4 
Nov  7 10:29:19.047: PO2/0 IPCP: I CONFACK [ACKsent] id 9 len 10 
Nov  7 10:29:19.047: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 10:29:19.047: PO2/0 IPCP: State is Open
Nov  7 10:29:19.047: PO2/0 CDPCP: I CONFACK [ACKsent] id 9 len 4 
Nov  7 10:29:19.047: PO2/0 CDPCP: State is Open
Nov  7 10:29:19.047: PO2/0 IPCP: Install route to 1.1.1.6
*Nov  7 10:29:19.048: %LINEPROTO-5-UPDOWN: Line protocol on 
Interface POS2/0, changed state to up

debug ppp packet

В то время как ссылка устанавливается, эти выходные данные иллюстрируют обмен пакетами, перехваченный с пакетом debug ppp. Эта отладочная программа собирает значение протокольных полей в пакете PPP. RFC 1661 выделяет для поля протокола один или два байта. Значение этого поля определяет дейтаграмму, заключенную в информационное поле пакета.

Величины поля протокола в диапазоне 0***" - "3*** идентифицируют протокол уровня сети специальных пакетов, а величины в диапазоне 8***" - "b*** идентифицируют пакеты, принадлежащие протоколам управления сетью (NCP), если такие есть в наличии. Значения полей протокола в диапазоне от "c***" до "f***" используются для определения пакетов с протоколом управления на уровне канала (как LCP). Также существуют различные определяемые поставщиком значения. Щелкните здесь для полного списка значений поля Протокола PPP leavingcisco.com.

Выходные данные отладки маршрутизатора RouterA
(1) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 

!---  0xC021 identifies LCP. 

*Nov  7 10:19:58: PO1/0 LCP: I CONFREQ [Closed] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFREQ [Closed] id 57 len 14^Z
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 LCP: O CONFACK [REQsent] id 7 len 14 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
*Nov  7 10:19:58: %LINK-3-UPDOWN: Interface POS1/0, changed state to up
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0xC021, datagramsize 18 
*Nov  7 10:19:58: PO1/0 LCP: I CONFACK [ACKsent] id 57 len 14ppp
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 

!---  0x8021 identifies IPCP, PPP internet protcol control protocol. 
 
*Nov  7 10:19:58: PO1/0 LCP:    MRU 4470 (0x01041176) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 

!---  0x8207 identifies Cisco discovery protocol control.
  
*Nov  7 10:19:58: PO1/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFREQ [Closed] id 15 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFREQ [Closed] id 13 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFREQ [REQsent] id 14 len 10packet
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 IPCP: O CONFACK [REQsent] id 14 len 10 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8021, datagramsize 14 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFREQ [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 CDPCP: O CONFACK [REQsent] id 15 len 4 
*Nov  7 10:19:58: PO1/0 IPCP: I CONFACK [ACKsent] id 15 len 10 
*Nov  7 10:19:58: PO1/0 PPP: I pkt type 0x8207, datagramsize 8 
*Nov  7 10:19:58: PO1/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
*Nov  7 10:19:58: PO1/0 CDPCP: I CONFACK [ACKsent] id 13 len 4 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 

!---  0x0207 identifies Cisco Discovery Protocol (CDP). 
 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: PO1/0 PPP: I pkt type 0x0207, datagramsize 376 
*Nov  7 10:19:59: %LINEPROTO-5-UPDOWN: Line protocol on Interface 
POS1/0, changed state to up
(3) 

!---  ECHOREQand ECHOREP packets for PPP keepalives use packet type values 
!---  of 0xC021.
 
*Nov  7 10:20:05: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:05: PO1/0 LCP: I ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:05: PO1/0 LCP: O ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x4FAE1B0C 
*Nov  7 10:20:07: PO1/0 PPP: I pkt type 0xC021, datagramsize 16 
*Nov  7 10:20:07: PO1/0 PPP: O pkt type 0x0207, datagramsize 376 
*Nov  7 10:20:07: PO1/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x269933F4 
*Nov  7 10:20:07: PO1/0 LCP: Received id 1, sent id 1, line up

Отладочные выходные данные для маршрутизатора B
(2) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFREQ [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0xC021, datagramsize 18 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: O CONFACK [REQsent] id 57 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x4FAE1B0C (0x05064FAE1B0C) 
Nov  7 12:22:16.947: PO2/0 LCP: I CONFACK [ACKsent] id 7 len 14 
Nov  7 12:22:16.947: PO2/0 LCP:    MRU 4470 (0x01041176) 
Nov  7 12:22:16.947: PO2/0 LCP:    MagicNumber 0x269933F4 (0x0506269933F4) 
Nov  7 12:22:16.947: PO2/0 IPCP: O CONFREQ [Closed] id 14 len 10 
Nov  7 12:22:16.947: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.947: PO2/0 CDPCP: O CONFREQ [Closed] id 15 len 4 
Nov  7 12:22:16.947: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFREQ [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 IPCP: O CONFACK [REQsent] id 15 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.6 (0x030601010106) 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8021, datagramsize 14 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFREQ [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 CDPCP: O CONFACK [REQsent] id 13 len 4 
Nov  7 12:22:16.951: PO2/0 PPP: I pkt type 0x8207, datagramsize 8 
Nov  7 12:22:16.951: PO2/0 IPCP: I CONFACK [ACKsent] id 14 len 10 
Nov  7 12:22:16.951: PO2/0 IPCP:    Address 1.1.1.5 (0x030601010105) 
Nov  7 12:22:16.951: PO2/0 CDPCP: I CONFACK [ACKsent] id 15 len 4 
Nov  7 12:22:17.947: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up
(4) 

!---  ECHOREQ and ECHOREP packets for PPP keepalives use packet type 
!---  values of 0xC021. 

Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:17.947: PO2/0 PPP: O pkt type 0x0207, datagramsize 376 
Nov  7 12:22:23.403: PO2/0 LCP: O ECHOREQ [Open] id 1 len 12 magic 0x269933F4 
Nov  7 12:22:23.403: PO2/0 PPP: I pkt type 0xC021, datagramsize 16 
Nov  7 12:22:23.403: PO2/0 LCP: I ECHOREP [Open] id 1 len 12 magic 0x4FAE1B0C 
Nov  7 12:22:23.403: PO2/0 LCP: Received id 1, sent id 1, line up
Nov  7 12:22:25.595: PO2/0 PPP: I pkt type 0xC021, datagramsize 16

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

Интерфейс пакетной передачи POS (по сети Sonet) с PPP или инкапсуляцией HDLC поддерживает два механизма для предупреждения вас отказа соединения: пакеты Keepalive Уровня 2 и сигналы тревоги уровня SONET. Средства поддержания активности (keepalives) тратят больше времени на отчет об ошибке по сравнению с внутренней структурой сигнального оповещения SONET. Однако пакеты Keepalive Уровня 2 полезны, потому что они проверяют путь от ЦП линейной карты до ЦП линейной карты, а не станка для заделки крепи к станку для заделки крепи, как сигналы тревоги уровня SONET делают. PPP реагирует более быстро на изменения состояния канала, так как LCP сразу снижается. По контрасту, HDLC должен прерывать соединения по таймауту.

В настройке со встречно-параллельным подключением между двумя маршрутизаторами, вытягивая одну из волоконных жил ломает подключение Уровня 1 и оба состояния изменения Интерфейсов пакетной передачи POS (по сети Sonet) к вниз/вниз. Однако, когда два POS-интерфейса маршрутизаторов соединяются через глобальную сеть телефонной компании с оборудованием SONET/SDH, сведения о потере связи на уровне 1 не передаются на удаленную сторону канала. В этой конфигурации пакеты Keepalive являются mechansim для перевода в нерабочее состояние ссылки.

Рассмотрите эту настройку.

/image/gif/paws/16152/16152b.gif

Здесь показано, что происходит при извлечении волоконной жилы передачи на канале из SDHb в SDHa:

  • Маршрутизатор 7507a не получает пакетов Keepalive.

  • Маршрутизатор 7507b видит пакеты Keepalive от 7507a, так как все еще работает получить волокно. Используйте отладку последовательный интерфейс для подтверждения этого.

В качестве альтернативы при выполнении этого теста можно подать команду show controller pos, которая отобразит сигналы тревоги SONET. На маршрутизаторе 7507a должен загореться индикатор аварийного состояния пути (P-AIS), а на 7507b – индикатор удаленной неисправности пути (P-RDI).

Кольцевая проверка линий

Если вывод команды show interfaces pos указывает, что последовательная линия включена, но протокол линии отключен, используйте кольцевой тест для определения источника проблемы. Выполните проверку локального зацикливания сначала, и затем удаленный тест. Обратитесь к Пониманию Режимов обратной связи на маршрутизаторах Cisco для руководства.

Примечание: Измените инкапсуляцию от PPP до HDLC при использовании loopback. Протокол линии связи на интерфейсе, настроенном с PPP, подходит только, когда обо всем LCP и сеансах NCP выполняют согласование успешно.

Статус протокола линии при использовании APS

Если интерфейс является защищать каналом а не рабочим каналом, Интерфейс пакетной передачи POS (по сети Sonet), настроенный для автоматического переключения на резерв (APS), приносит по линии протокол. Рассмотрите этот пример топологии:

/image/gif/paws/16152/16152c.gif

Этот типовой вывод лога был перехвачен после того, как разводка оптоволоконных кабелей на POS GSRB 1/0 интерфейс была удалена. Обратите внимание на изменения в состоянии протокола линии на обоих интерфейсах при переключении APS. Также обратите внимание на изменения в состояниях смежности протокола OSPF. (Обратитесь к Странице поддержки технологии APS для получения дополнительной информации.)

*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: SLOS 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS2/0: APS enabling channel 
*Sep  5 17:41:46: %SONET-6-APSREMSWI: POS2/0: Remote APS status now Protect 
*Sep  5 17:41:46: %SONET-4-ALARM:  POS1/0: APS disabling channel 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS2/0, 
changed state to up 
*Sep  5 17:41:46: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS1/0, 
changed state to down 
*Sep  5 17:41:48: %LINK-3-UPDOWN: Interface POS1/0, changed state to down 
*Sep  5 17:41:48: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS1/0 
from FULL to DOWN, Neighbor Down: Interface down or detached 
*Sep  5 17:41:56: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.100.100 on POS2/0 
from LOADING to FULL, Loading Done 

Избегите настраивать APS на Интерфейсе пакетной передачи POS (по сети Sonet) с инкапсуляцией PPP. PPP не знает о APS. Если интерфейс/вниз из-за отмены выбора APS, PPP пытается перезагрузить интерфейс и постоянно передает Пакеты согласования PPP.

Кроме того, отключите пакеты Keepalive для предотвращения ненужных откидных створок протокола линии связи. Пакеты Keepalive автоматически отключены на большинстве ПО маршрутизаторов POS.

Интерфейс пакетной передачи POS (по сети Sonet) Серии Cisco 12000 в APS в рабочем или защищенном режиме может стать всунутым состояние включения/отключения (даже с loopback), когда отключен APS. Другая карта, вставленная в тот же слот, испытывает эту проблему. Переместите карту в новый слот для восстановления надлежащего статуса протокола линии. Эта проблема решена в программном обеспечении Cisco IOS версии 12.0(19)S под идентификатором ошибки Cisco CSCdt43759 (только зарегистрированные клиенты).

Используйте эти шаги в качестве обходного пути:

  1. Настройте команду aps protect.

  2. Подайте команду aps force 1.

  3. Настройте команду no aps protect.

Типичные ошибки

Примечание эти предупреждения, когда вы устраняете проблемы протокола линии связи с Интерфейсами пакетной передачи POS (по сети Sonet):

  • ИНТЕРФЕЙС ПАКЕТНОЙ ПЕРЕДАЧИ POS (ПО СЕТИ SONET) PA мог бы перезагружать постоянно после того, как инкапсуляция изменена от PPP до HDLC. Об этой проблеме сообщают против PA POS в идентификаторе ошибки Cisco CSCdk30893 (только зарегистрированные клиенты) и решают в идентификаторе ошибки Cisco CSCdk18777 (только зарегистрированные клиенты) и идентификатор ошибки Cisco CSCdk13757 (только зарегистрированные клиенты) для различных интерфейсов, которые поддерживают PPP и инкапсуляцию HDLC. Проблема вызвана, когда PPP не полностью закрыт, когда была изменена инкапсуляция.

  • Когда пакеты Keepalive не получены от удаленного конца, Интерфейс пакетной передачи POS (по сети Sonet), настроенный с инкапсуляцией HDLC и пакетами Keepalive, подвергается повторенным интерфейсным откидным створкам вместо того, чтобы принести по линии протокол. Эта проблема решена в идентификаторе ошибки Cisco CSCdp86387 (только зарегистрированные клиенты).

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

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


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


Document ID: 16152