Технологии коммутируемого доступа в сеть : "Технология ISDN, CAS"

Блок-схема исправления ошибок ISDN BRI

<концерн> <концерн> <концерн> <концерн>

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

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

Измените определение содержательного трафика (настроенный с dialer-list команда. В данном примере определите трафик OSPF и NTP как несодержательный. Здесь определение эталонного интересующего трафика:

<блок цитирования> <пред> access-list 101 отмечают Представляющий интерес трафик для dialer-list 1 access-list 101 запрещает ospf любой любой
<цвет шрифта = "#0000FF">!---отмечают OSPF как неинтересный
!---Это предотвратит OSPF hellos от хранения соединения.

access-list 101 запрещают udp любые любые ntp eq <цвет шрифта = "#0000FF">! - Определяют трафик ntp как НЕ содержательный.
! - Это будет препятствовать тому, чтобы поддержал периодический трафик ntp ! - соединение неопределенно.

ip разрешения access-list 101 любой любой <цвет шрифта = "#0000FF">
! - Весь другой IP - трафик является содержательным.
! - Изменяют это в зависимости от потребностей трафика.

список protocol ip dialer-list 1 101 <цвет шрифта = "#0000FF"> ! - этот представляющий интерес трафик применен к интерфейсу номеронабирателя ! - использование dialer-group 1

Для получения дополнительной информации обратитесь к документу Коммутируемый доступ Технология: обзоры и пояснения .

Примечание: OSPF имеет функцию, названную линией связи по требованию, которая может также использоваться здесь. Обратитесь к документу Почему OSPF Канал требования поддерживает Внедрение Ссылка для получения дополнительной информации

<название = "problem8"> Признак: Второй B-канал не Соединяется

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

<название = "problems9"> Невозможность IP-подключения

Если соединение ISDN подходит, но вы не можете передать трафик accross ссылка тогда проблема является, вероятно, связанной проблемой NAT или маршрутизацией. Обратитесь к Сообщество Cisco Support для большего количества сведений об устранении проблем.

При использовании соединение ISDN в качестве резервной копии к подключению к глобальной сети (WAN), то отнеситесь к документу Настройка и устранение проблем резервирования DDR .

<НАЗВАНИЕ = "информация"> Дополнительные сведения

<час width=100%>

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

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


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

<тело bgcolor = "#FFFFFF">

блок-схема устранения проблем ISDN BRI

<идентификатор отделения = "поддержка-toc">

Содержание

    <класс отделения = "toc-h2"> Введение <класс отделения = "toc-h2"> Блок-схема <класс отделения = "toc-h2"> Устранение проблем: Как Войти и Перехватить Эти Отладки <класс отделения = "toc-h2"> Устранение проблем: Пытается ли маршрутизатор выполнить набор номера? <класс отделения = "toc-h2"> Признак: Маршрутизатор не Пытается Набрать <класс отделения = "toc-h2"> Устранение проблем: Правильно ли подключен ISDN-вызов? <класс отделения = "toc-h2"> Устранение проблем: Выполнен ли этап PPP LCP? <класс отделения = "toc-h2"> Признак: Фаза LCP PPP не Следует <класс отделения = "toc-h2"> Устранение проблем: Успешно ли прошла PPP-аутентификация? <класс отделения = "toc-h2"> Признак: Аутентификация "PPP" Не Следует <класс отделения = "toc-h2"> Устранение проблем: Фаза PPP NCP (IPCP) завершена? <класс отделения = "toc-h2"> Признак: NCP PPP (IPCP) Согласование Не Следует <класс отделения = "toc-h3"> Признак: Вызовите Разъединения Преждевременно, или Вызов Не Разъединяет во Всем <класс отделения = "toc-h3"> Признак: Маршрутизатор Периодически Наборы Соединение <класс отделения = "toc-h3"> Признак: Второй B-канал не Подключает <класс отделения = "toc-h3"> Невозможность IP-подключения <класс отделения = "toc-h2"> Дополнительные сведения

<название = "введение"> Введение

Этот документ помогает вам устранять неполадки коммутируемого доступа Интерфейса (BRI) ISDN доступ. В блок-схеме и примере выходных данных, показанном ниже, мы установили ISDN Подключение BRI к другому использованию Профили DDR. Однако то же устранение проблем шаги применяются к соединениям с другими маршрутизаторами (такими как филиалы компании) и когда использование Устаревшей Технологии DDR.

примечание : можно также использовать Сообщество Cisco Support , чтобы помочь вам решать Проблему ISDN.

Для вводных сведений на ISDN и DDR, обратитесь к расположенному обучению работе с аудио в Подключение Cisco Learning .

<название = "блок-схема"> Блок-схема

Щелкните по ссылке ниже для получения дополнительных сведений об элементе. Используйте браузер кнопка "Назад" для возврата к этой блок-схеме.

<имя карты = "Карта"> <форма области = "rect" coords = "15 1 267 189" href = "#debugs"> <форма области = "poly" coords = "374,49,374,48,445,92,375,143,299,93" href = "#attempttodial"> <форма области = "rect" coords = "473 7 684 160" href = "#problems1"> <форма области = "poly" coords = "299,717,370,668,441,717,371,763" href = "#ncpup"> <форма области = "poly" coords = "293,252,368,202,438,252,367,296" href = "#isdnconnect"> <форма области = "rect" coords = "467,170,680,316" href = "#problems2"> <форма области = "poly" coords = "299,434,372,384,441,436,371,484" href = "#lcpup"> <форма области = "poly" coords = "299,570,371,527,438,569,368,612" href = "#authen"> <форма области = "rect" coords = "468,332,678,493" href = "#problems3"> <форма области = "rect" coords = "476,499,694,640" href = "#problems4"> <форма области = "rect" coords = "474,646,692,811" href = "#problems5"> <форма области = "rect" coords = "10,874,168,995" href = "#problem6"> <форма области = "rect" coords = "179,873,345,994" href = "#problem6"> <форма области = "rect" coords = "349,874,518,998" href = "#problem7"> <форма области = "rect" coords = "532,875,696,995" href = "#problems9">

<час>

<название = "отладки"> Устранение проблем: Как Войти и Перехватить Эти Отладки

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

Если необходимо соединиться с маршрутизатором через консоль, см. Применение Корректные Параметры эмуляция терминала для Консольных соединений . Если маршрутизатор уже установлен для подключения на Ethernet, и вы хотите соединиться с маршрутизатор с помощью telnet, просто используйте клиента Telnet для соединения с маршрутизатором IP-адрес Ethernet.

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

Активируйте миллисекунды на выходных данных отладки и сообщениях журнала. После появления приглашения, введите пароль, настроенный на маршрутизаторе, и войдите в привилегированный режим: <блок цитирования> <пред> маршрутизатор> включает Password: (вводят enable password) router# router# configure terminal Введите команды конфигурирования, по одной в каждую строку. В конце введите CNTL/Z. маршрутизатор (config) # service timestamps debug datetime msec маршрутизатор (config) # service timestamps регистрирует datetime msec

Если вы связаны с помощью telnet, введите terminal monitor следующим образом:

<блок цитирования> <пред> router# terminal monitor router#

После этого введите отладку команды ниже:

<блок цитирования> <пред> router# debug isdn q931 Пакетная отладка ISDN Q931 идет router# debug ppp negotiation Отладка согласования протокола PPP идет router# пакет debug dialer Пакетная отладка установления соединения по запросу идет router# debug dialer Отладка событий установления соединения по запросу идет router# debug ppp authenticaion Отладка аутентификации "PPP" идет router# Затем инициируйте эхо-запрос на вызывающем маршрутизаторе. Ниже пример отладочных выходных данных успешный вызов. Как показано на блок-схеме, выделены различные фазы. <блок цитирования> <пред> router# пропинговывают 194.183.201.1 Для завершения введите последовательность для выхода. Передавая 5, 100-байтовый ICMP Echos к 194.183.201.1, таймаут составляет 2 секунды: *1 марта 0:06:36.383: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 байтов, выход содержательного (IP РАЗРЕШЕНИЕ) <цвет шрифта = "#0000FF">! - Эхо-запрос для 194.183.201.1 является представляющим интерес трафиком и использует Номеронабирателя 1 (Di1) *1 марта 0:06:36.387: BR0 DDR: подключение к внешней службе ротора [приоритет] *1 марта 0:06:36.391: BR0 DDR: ip Причины внешнего доступа по телефонной линии (s=10.1.0.1, d=194.183.201.1) *Mar 1 0:06:36.395: BR0 DDR: Попытка набрать 8134 <цвет шрифта = "#0000FF"> ! - Количество использовало набирать.
! - Это настроено с помощью команды dialer string or dialer map ! - Если вы не видите, что это сообщение продолжает разделять ! - Признак: Маршрутизатор Не Пытается Набрать
*1 марта 0:06:36.411: ISDN BR0: TX-> УСТАНАВЛИВАЕТ фунт = 8 callref = 0x02 *1 марта 0:06:36.415: Пропускная способность информационного канала i = 0x8890 *1 марта 0:06:36.423: Идентификатор канала i = 0x83 *1 марта 0:06:36.427: Номер вызываемого абонента i = 0x80, '8134', Plan:Unknown, Type:Unknown *1 марта 0:06:36.519: ISDN BR0: RX <-фунт CALL_PROC = 8 callref = 0x82 *1 марта 0:06:36.527: Идентификатор канала i = 0x89 *1 марта 0:06:36.727: ISDN BR0: RX <-ПОДКЛЮЧАЕТ фунт = 8 callref = 0x82 *1 марта 0:06:36.743: ISDN BR0: TX-> CONNECT_ACK фунт = 8 callref = 0x02 *Mar 1 0:06:36.751: %LINK-3-UPDOWN: Интерфейс BRI0: 1, измененное состояние к <цвет шрифта = "#0000FF">! - Уровень ISDN 3 сообщения CONNECT и сообщение Соединения ! - Если вы не видите, что это сообщение продолжает разделять ! - Признак: ВЫЗОВ ISDN Не Соединяется Успешно *1 марта 0:06:36.767: BR0:1: интерфейс должен быть очередью FIFO, FIFO силы *1 марта 0:06:36.775: %DIALER-6-BIND: Интерфейсный BR0:1, связанный представлять Di1 *1 марта 0:06:36.787: BR0:1 PPP: Обработка соединения как выноска *1 марта 0:06:36.791: BR0:1 PPP: Фаза УСТАНАВЛИВАЕТ, Активный Открытый <цвет шрифта = "#0000FF">! - Согласование LCP начинает *1 марта 0:06:36.791: BR0:1 PPP: Никакая удаленная аутентификация для выноски *1 марта 0:06:36.795: BR0:1 LCP: O CONFREQ [Закрытый] идентификатор 3 len 10 *1 марта 0:06:36.799: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *1 марта 0:06:36.859: BR0:1 LCP: Я CONFREQ [REQsent] идентификатор 59 len 15 *1 марта 0:06:36.863: BR0:1 LCP: CHAP AuthProto (0x0305C22305) *1 марта 0:06:36.867: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *1 марта 0:06:36.871: BR0:1 LCP: O CONFACK [REQsent] идентификатор 59 len 15 *1 марта 0:06:36.875: BR0:1 LCP: CHAP AuthProto (0x0305C22305) *1 марта 0:06:36.875: BR0:1 LCP: MagicNumber 0x10D36A4C (0x050610D36A4C) *1 марта 0:06:36.879: BR0:1 LCP: Я CONFACK [ACKsent] идентификатор 3 len 10 *1 марта 0:06:36.883: BR0:1 LCP: MagicNumber 0x0012586A (0x05060012586A) *Mar 1 0:06:36.887: BR0:1 LCP: Состояние Открыто <цвет шрифта = "#0000FF">! - Согласование LCP завершено. Любое состояние LCP кроме , Открытого , указывает ! - что отказало согласование LCP. ! - Если вы не видите, что это сообщение продолжает разделять ! - Признак: Фаза LCP PPP Не Следует *1 марта 0:06:36.903: BR0:1 PPP: Фаза ПОДТВЕРЖДАЕТ ПОДЛИННОСТЬ узлом *1 марта 0:06:36.907: BR0:1 CHAP: Я БРОСАЮ ВЫЗОВ идентификатору 38 len 24 от "интернет-провайдера" <цвет шрифта = "#0000FF">! - Поступающий запрос вызова CHAP *1 марта 0:06:36.915: BR0:1 CHAP: Использование альтернативного имени хоста XXXXX <цвет шрифта = "#0000FF">! - Использование альтернативного имени хоста, настроенного с командой ppp chap hostname *1 марта 0:06:36.915: BR0:1 CHAP: интернет-провайдер Имени пользователя, не найденный *1 марта 0:06:36.919: BR0:1 CHAP: Использование пароля по умолчанию <цвет шрифта = "#0000FF">! - Использование пароля, настроенного с командой ppp chap password *1 марта 0:06:36.923: BR0:1 CHAP: O ОТВЕТ идентификатор 38 len 26 от "XXXXX" <цвет шрифта = "#0000FF">! - Передача ответа от " XXXXX" который является альтернативным именем хоста для маршрутизатора *1 марта 0:06:36.939: BR0:1 CHAP: Я идентификатор УСПЕХА 38 len 4 <цвет шрифта = "#0000FF">! - NAS имеет succesfully, подтвердил подлинность маршрутизатора *Mar 1 0:06:36.943: BR0:1 PPP: Фаза произошла <цвет шрифта = "#0000FF">! - Аутентификация "PPP" успешна ! - NCP PPP (IPCP) согласование начинает *1 марта 0:06:36.947: BR0:1 IPCP: O CONFREQ [Не договорной] идентификатор 3 len 10 *1 марта 0:06:36.951: BR0:1 IPCP: обратитесь 0.0.0.0 (0x030600000000) <цвет шрифта = "#0000FF">! - Этому маршрутизатору не настраивали адрес, таким образом, он передает a ! - CONFREQ с адресом 0.0.0.0. Это говорит другому узлу назначать адрес ! - который выполнен передачей CONFNAK с соответствующим адресом. *1 марта 0:06:36.955: BR0:1 IPCP: я CONFREQ [REQsent] идентификатор 26 len 10 *1 марта 0:06:36.963: BR0:1 IPCP: обращаются 194.183.201.1 (0x0306C2B7C901) <цвет шрифта = "#0000FF">! - Входящий CONFREQ, указывающий на IP-адрес узла *1 марта 0:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] идентификатор 26 len 10 *1 марта 0:06:36.971: BR0:1 IPCP: обращаются 194.183.201.1 (0x0306C2B7C901) <цвет шрифта = "#0000FF">! - Маршрутизатор принимает IP-адрес узла ! - (так как это не пытается назначить то на узел), ! - Как только вызов связан, маршрут к этому адресу будет установлен *1 марта 0:06:36.975: BR0:1 IPCP: я CONFNAK [ACKsent] идентификатор 3 len 10 *1 марта 0:06:36.979: BR0:1 IPCP: обращаются 194.183.201.2 (0x0306C2B7C902) <цвет шрифта = "#0000FF">! - Одноранговые CONFNAK наш запрос начального адреса 0.0.0.0 ! - Это отвечает адресом, который мог использовать этот маршрутизатор ! - NAS может назначить это использование команды peer default ip address or dialer map *1 марта 0:06:36.983: BR0:1 IPCP: O CONFREQ [ACKsent] идентификатор 4 len 10 *1 марта 0:06:36.987: BR0:1 IPCP: обращаются 194.183.201.2 (0x0306C2B7C902) <цвет шрифта = "#0000FF">! - Это запросы маршрутизатора адрес, ранее предложенный NAS *1 марта 0:06:37.011: BR0:1 IPCP: я CONFACK [ACKsent] идентификатор 4 len 10 *1 марта 0:06:37.015: BR0:1 IPCP: обращаются 194.183.201.2 (0x0306C2B7C902) <цвет шрифта = "#0000FF">! - NAS принимает адрес, который запрашивает клиент *Mar 1 0:06:37.015: BR0:1 IPCP: Состояние Открыто <цвет шрифта = "#0000FF">! - NCP PPP (IPCP) согласование завершено <цвет шрифта = "#0000FF">! - Если вы не видите, что это сообщение продолжает разделять ! - Признак: NCP PPP (IPCP) согласование не следует *1 марта 0:06:37.019: Di1 IPCP: Установите договорной адрес IP - интерфейс 194.183.201.2 *1 марта 0:06:37.031: BR0:1 DDR: протокол дозвона *1 марта 0:06:37.039: Di1 IPCP: маршрут Установки к 194.183.201.1 <цвет шрифта = "#0000FF">! - Направляют для пиринга, установлен *1 марта 0:06:37.943: %LINEPROTO-5-UPDOWN: Протокол линии связи на Интерфейсном BRI0:1, измененное состояние к *1 марта 0:06:38.383: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 байтов, исходящий содержательный (IP РАЗРЕШЕНИЕ) *1 марта 0:06:38.427: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 байтов, исходящий содержательный (IP РАЗРЕШЕНИЕ) *1 марта 0:06:38.471: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 байтов, исходящий содержательный (IP РАЗРЕШЕНИЕ) *1 марта 0:06:38.515: Di1 DDR: ip (s=194.183.201.2, d=194.183.201.1), 100 байтов, исходящий содержательный (IP РАЗРЕШЕНИЕ) router# *Mar 1 0:06:42.783: %ISDN-6-CONNECT: Интерфейс BRI0: 1 теперь связан с 8134 неизвестный router#

Назад к блок-схеме устранения проблем <час> <название = "attempttodial">

Устранение проблем: Пытается ли маршрутизатор выполнить набор номера?

Чтобы узнать, пытается ли маршрутизатор заказать телефонный разговор, проверьте ли у вас есть придерживающиеся линии в выходных данных отладки вызывающего маршрутизатора: <блок цитирования> <пред> *1 марта 0:06:36.395: BR0 DDR: Попытка набрать 8134 В выходных данных отладки, 8134 Номер каталога ISDN, которого делает попытку маршрутизатор набрать. Это количество было задано с помощью строки номеронабирателя или номеронабирателя карта команда.

Назад к блок-схеме устранения проблем <час> <название = "problems1">

Признак: Маршрутизатор не Пытается Набрать

Если ваш маршрутизатор не пытается набрать номер, существует несколько возможностей:

Выходные данные No Debug вообще

Если существуют выходные данные no debug вообще, это наиболее вероятно потому что пакет IP вы, даже передаете не маршрутизируется к Интерфейсу номеронабирателя. Наиболее распространенное причины для этого:

    Проверяет, что IP настроен на Интерфейсе номеронабирателя. Вы должны также имейте IP-адрес на интерфейсе номеронабирателя или ip, ненумерованном интерфейс (где интерфейс является полной работоспособностью интерфейса, такой как ethernet x , loopback x и т.д.) или ip address negotiated (если клиент получит IP-адрес от NAS). При использовании унаследованный профиль DDR, то IP-адрес должен будьте настроены на физическом интерфейсе (пример, interface BRI 0).

    Проверяет, что настроен ip routing команды . Когда вы смотрите на конфигурация с помощью команды show running-config , вы должны не видят команду никакой ip, направляющий .

    Проверяет, что существует статический маршрут, указывающий в интерфейсе номеронабирателя или следующий переход (при использовании cхем набора номеров).

    Следующий пример (для профиля DDR) является статическим маршрутом для 172.22.53.0/24 с Номеронабирателем следующего перехода 1:

    <блок цитирования> <пред> maui-soho-01 (config) # ip route 172.22.53.0 255.255.255.0 номеронабирателей 1

    Следующий пример (для унаследованного профиля DDR) является статическим маршрутом для 172.22.53.0/24 со следующим переходом 172.16.1.1. Адрес следующего узла должен совпасть с IP-адресом в инструкции схемы набора номеров, которая используется для набора:

    <блок цитирования> <пред> maui-soho-01 (config) # ip route 172.22.53.0 255.255.255.0 172.16.1.1 Проверяет, что интерфейс номеронабирателя или физический интерфейс не находятся в административно вниз или резервное состояние. Используйте show interface dialer X , или показывают interface bri команда X , чтобы гарантировать, что интерфейс находится в государственный up/up (spoofing).

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

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

Там являются Выходные данные отладки, но никакой " Попытка Набрать" сообщение

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

Пример 1

<блок цитирования> <пред> *Mar 13 10:43:50.253: Di1 DDR: ip (s=10.1.1.1, d=172.22.53.1), 100 байтов, исходя неинтересный ( перечисляют 101 ).

Генерируемый трафик не совпадает с определением содержательного трафика. Для данного примера модифицируйте access-list 101 .

Простой представляющий интерес трафик defintion должен был бы разрешить весь IP - трафик как в:

<блок цитирования> <пред> maui-soho-01 (config) # dialer-list 1 protocol ip permit

Предупреждение : Маркировка всего IP - трафика как содержательный может вызвать ISDN ссылка, чтобы не лечь спать неопределенно, особенно если у вас есть протокол маршрутизации или другой периодический трафик. Отрегулируйте определение содержательного трафика для удовлетворения потребности.

Для получения дополнительной информации о представляющем интерес трафике обратитесь к документу Коммутируемый доступ Технология: обзоры и пояснения .

Пример 2

<блок цитирования> <пред> *1 марта 0:07:22.255: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 байтов, исходя неинтересный (никакой определенный dialer-group).

Нет никакого dialer-group, настроенного на интерфейсе номеронабирателя. Добавьте dialer-group как в следующем примере:

<блок цитирования> <пред> interface Dialer1 dialer-group X <блок цитирования>

примечание : значение для X должно быть тем же самым используемым с dialer-list команда.

Пример 3

<блок цитирования> <пред> *1 марта 0:08:24.919: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 байтов, исходя неинтересный (dialer-list 1, не определенный).

Существует оператор dialer-group на интерфейсе номеронабирателя, но dialer-list упомянутый не существует. Настройте список набираемых номеров, как показано в примере:

<блок цитирования> <пред> разрешение на ip X-протокола dialer-list

примечание : значение для X должно быть тем же самым используемым с dialer-group команда под интерфейсом номеронабирателя.

Пример 4

<блок цитирования> <пред> *1 марта 0:25:32.551: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 байтов, исходящих содержательный (IP РАЗРЕШЕНИЕ) *1 марта 0:25:32.555: Di1 DDR: Никакой свободный номеронабиратель - начало быстрого счетчика простоя.

В этом случае исходящий пакет нужно считать достаточно содержательным переведите ссылку в рабочее состояние, но нет никакого физического интерфейса, доступного для размещения звонить. Удостоверьтесь, что член пула программ набора номеров X настроен в медосмотре взаимодействуйте и пул программ для набора номера x настроен в Интерфейсе номеронабирателя. Пример:

<блок цитирования> <пред> интерфейс BRI0 член пула программ набора номеров 1 ! interface Dialer1 dialer pool 1

Кроме того, проверьте, что интерфейс BRI не находится в состоянии завершения работы.

Пример 5

<блок цитирования> <пред> *1 марта 0:37:24.235: Di1 DDR: ip (s=10.1.0.1, d=194.183.201.1), 100 байтов, исходящих содержательный (IP РАЗРЕШЕНИЕ) *1 марта 0:37:24.239: Di1 DDR: не Может разместить вызов, никакой набор строки номеронабирателя.

В этом случае никакая строка номеронабирателя не настроена на интерфейсе номеронабирателя. Маршрутизатор хочет заказать телефонный разговор, но не знает, что звонит Номер каталога ISDN. Определить строка номеронабирателя:

<блок цитирования> <пред> interface Dialer1 строка номеронабирателя 8134

Для большего количества сведений об устранении проблем обратитесь к разделу " Вызов Маршрутизатор не передает НАСТРОЙКЕ Message" в документе Устранение проблем Уровень 3 ISDN BRI с помощью Команды debug isdn q931 .

Назад к блок-схеме устранения проблем <час> <название = "isdnconnect">

Устранение проблем: Правильно ли подключен ISDN-вызов?

Для того чтобы определить, когда вызов ISDN устанавливает соединение, см. сообщения CONNECT_ACK и %LINK-3-UPDOWN в отладочной информации: <блок цитирования> <пред> *1 марта 0:06:36.743: ISDN BR0: TX-> фунт CONNECT_ACK = 8 callref = 0x02 *1 марта 0:06:36.751: %LINK-3-UPDOWN: Интерфейс BRI0: 1, измененное состояние к Если вы видите это сообщение, вызов ISDN, связанный успешно, и можно продолжиться к следующему шагу. Если вы не видите сообщение как это, читайте ниже для возможного причины.

Назад к блок-схеме устранения проблем <час> <название = "problems2">

Признак: ВЫЗОВ ISDN не Подключает Успешно

    , Если вы видите выходные данные, подобные придерживающемуся, проверяет, что кабель ISDN включенный и маршрутизатор и Разъем Telco. <блок цитирования> <пред> *1 марта 21:31:18.190: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 байтов, исходящих содержательный (IP РАЗРЕШЕНИЕ) *1 марта 21:31:18.190: BR0 DDR: подключение к внешней службе ротора [приоритет] *1 марта 21:31:18.198: BR0 DDR: ip Причины внешнего доступа по телефонной линии (s=x1.x2.x3.x4, d=y1.y2.y3.y4) *1 марта 21:31:18.198: BR0 DDR: Попытка набрать 8134. *1 марта 21:31:20.186: Di1 DDR: ip (s=x1.x2.x3.x4, d=y1.y2.y3.y4), 100 байтов, исходящих содержательный (IP РАЗРЕШЕНИЕ). *1 марта 21:31:26.226: ISDN BR0: не Мог перевести интерфейс в рабочее состояние *1 марта 21:31:26.226: BRI0: ждите таймаута носителя ISDN, вызовите id=0x849E *1 марта 21:31:26.246: ISDN BR0: не Мог перевести интерфейс в рабочее состояние. Доля успешных попыток составляет 0 процентов (0/5) Проверяет, что должным образом функционирует цепь ISDN. Используйте show isdn статус дает команду, чтобы проверить, что Уровень 1 АКТИВЕН, Уровень 2 является MULTIPLE_FRAME_ESTABLISHED и SPID (в случае необходимости) допустимы. Для получения дополнительной информации сошлитесь на документ Использование статуса show isdn Команда для устранения проблем BRI .

    Если у вас есть выходные данные команды show isdn status от Cisco устройство, можно использовать <язык сценария = src "JavaScript" = "/public/technotes/javascript/oi.js"> для получения наглядной информации о возможных проблемах и способах их устранения. Для работы с <язык сценария = src "JavaScript" = "/public/technotes/javascript/oi.js"> необходимо быть зарегистрировал пользователя, войтись, и включите JavaScript.

    Проверяет, что настроенная строка Номеронабирателя ISDN корректна. Следует иметь в виду это вам, вероятно, придется добавить начальный нуль, девять или другие цифры для получения внешней стороны выровняйте, когда вы будете связаны через УАТС.

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

    В США, и в ситуациях, где Telco (телефонная компания) или провайдер удаленного доступа неспособно исправить проблему, можно хотеть использовать Предварительно подписанное Межстанционное Носитель (PIC). Коды PIC являются семизначными префиксами, которые определяют США. долгий носители расстояния к местным телефонным компаниям (LEC). Это позволяет клиентам использовать других поставщиков услуг дальней связи для отдельных вызовов. Код PIC настроен как префикс к набранному номеру. Большинство PIC имеет формат 1010xxx.

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

    Например, строка номеронабирателя 10103215125551111 .

    Ищет Сообщение отключения ISDN.

    Cisco IOS® программное обеспечение декодирует код причины в этом сообщении разъединения и дает вам сообщение открытого текста, которое часто содержит полезные сведения приведение к причине проблемы. Возможные строки, которые можно найти здесь включайте:

      Невыделенный или свободный номер

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

      Номер занят (который указывает, что вызванная сторона занята)

      Временный сбой (который указывает на простой простой на Сети telco),

    <блок цитирования>


    Для обнаружения возможной причины для определенной причины разъединения, обратитесь к Понимание Коды причины разъединения debug isdn q931 .

    Например, разъединение из-за неверного номера ISDN может быть обозначено с:

    <блок цитирования> <пред> *3 марта 0:10:38.756: ISDN BR0: RX <-РАЗЪЕДИНЯЕТ фунт = 8 callref = 0xEB *3 марта 0:10:38.764: Причина i = 0x84D8 - Несовместимое назначение

    Что касается Разъединение Коды причин документ, на который ссылаются ранее, мы можем решить что код разъединения был вызван попыткой соединиться с отличным от ISDN оборудование (Например, аналоговая линия.).

    Разъединение из-за неправильно формата номера может быть обозначено с:

    <блок цитирования> <пред> 13 августа 18:23:14.734: ISDN BR0: RX < - фунт RELEASE_COMP = 8 callref = 0x86
    13 августа 18:23:14.742: Причина i = 0x829C - Недопустимый формат номера (неполное количество)

    Что касается документа Понимание Коды причины разъединения debug isdn q931 , мы можем решить что разъединение код был вызван недопустимым форматом для удаленного Номера "ISDN". Соединение отказывает, потому что адрес назначения (DA) представлен (коммутатору) в неизвестный формат или адрес назначения (DA) является неполным.

    Следующий пример показывает отклоненный вызов из-за неверного номера ISDN:

    <пред> *13 марта 11:29:04.758: ISDN BR0: RX <-RELEASE_COMP фунт = 8 callref = 0x83 *13 марта 11:29:04.769: Причина i = 0x8295 - Вызов отклонил

    , Если Telco (телефонная компания) предоставил вас идентификаторами профиля сервиса (SPID) чтобы использоваться, удостоверьтесь, что эти SPID настроены на интерфейсе BRI. SPID обычно используются только в США и с NRS и типами коммутатора DMS (5ess типы коммутаторов не требую SPID). <блок цитирования> <пред> интерфейс BRI0 isdn spid1 51255511110101 5551111 isdn spid2 51255511120101 5551112 <блок цитирования>

    Можно использовать команду show isdn status , чтобы проверить если SPID корректны.

    Для получения дополнительной информации обратитесь к документу Устранение проблем SPID ISDN BRI .

    Если у вас есть выходные данные команды show isdn status от Cisco устройство, можно использовать <язык сценария = src "JavaScript" = "/public/technotes/javascript/oi.js"> для получения наглядной информации о возможных проблемах и способах их устранения. Для работы с <язык сценария = src "JavaScript" = "/public/technotes/javascript/oi.js"> необходимо быть зарегистрировал пользователя, войтись, и включите JavaScript.

    , Если вышеупомянутая процедура не решила проблему, использует документ Устранение проблем Уровень 3 ISDN BRI с помощью Команды debug isdn q931 для дальнейшего устранения проблем.

Назад к блок-схеме устранения проблем <час> <название = "lcpup">

Устранение проблем: Выполнен ли этап PPP LCP?

В выходе отладки должна отображаться следующая строка сообщения: <блок цитирования> <пред> *1 марта 0:06:36.887: BR0:1 LCP: Состояние Открыто Если вы видите эту линию, это указывает, что о Протоколе управления каналом (LCP) выполнили согласование успешно. Любое состояние кроме открытого указывает на неудачноесогласование LCP.

Назад к блок-схеме устранения проблем <час> <название = "problems3">

Признак: Фаза LCP PPP не Следует

<цвет шрифта = "#000000"> Возможная причина: PPP не Настроен

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

<блок цитирования> <пред> *Mar 2 19:34:21.761: Di1 DDR: протокол дозвона. *2 марта 19:34:23.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 байты, исходящие содержательный (IP РАЗРЕШЕНИЕ). *2 марта 19:34:25.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 байты, исходящие содержательный (IP РАЗРЕШЕНИЕ). *2 марта 19:34:27.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 байты, исходящие содержательный (IP РАЗРЕШЕНИЕ) * 2 марта 19:34:27.753: %ISDN-6-CONNECT: Интерфейс BRI0: 1 теперь связанный с 8101.
<цвет шрифта = "#0000FF">! - Вызывают подключения, но маршрутизатор не передает пакетов CONFREQ PPP *2 марта 19:34:29.397: Di1 DDR: ip (s=10.48.74.9, d=10.0.0.14), 100 байты, исходящие содержательный (IP РАЗРЕШЕНИЕ). Success rate is 0 percent (0/5)

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

В этом случае проверьте настройку команды encapsulation ppp под интерфейсом номеронабирателя и физическим интерфейсом. Примеры приведены ниже:

<блок цитирования> <пред> интерфейсный Dialer1 encapsulation ppp или
interface BRI 0
encapsulation ppp

возможная причина: несоответствие скорости ISDN

Иногда можно видеть только исходящие сообщения LCP CONFREQ, но никакой входящий LCP сообщения. Ниже приводится пример:

<блок цитирования> <пред> 1:49:10 *Mar 14.160: %LINK-3-UPDOWN: Интерфейс BRI0: 1, измененное состояние к <цвет шрифта = "#0000FF">! - Вызов связан. Согласование PPP начнет
1:49:10 *Mar 14.168: %DIALER-6-BIND: Интерфейсный BR0:1, связанный представлять Di1.
1:49:10 *Mar 14.188: BR0:1 PPP: Обработка соединения как выноска
1:49:10 *Mar 14.188: BR0:1 PPP: Фаза УСТАНАВЛИВАЕТ , Активный Открытый [0 sess, 0 загрузок] <цвет шрифта = "#0000FF">! - Согласование PPP начинает
1:49:10 *Mar 14.196: BR0:1 LCP: O CONFREQ [Закрытый] идентификатор 24
len 15 1:49:10 *Mar 14.200: BR0:1 LCP: CHAP AuthProto (0x0305C22305)
1:49:10 *Mar 14.204: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A). <цвет шрифта = "#0000FF">! - Исходящий Configure-Request (CONFREQ)
1:49:12 *Mar 14.176: BR0:1 LCP: ТАЙМАУТ: Состояние REQsent <цвет шрифта = "#0000FF">! - Маршрутизатор не получил CONFREQ от узла, следовательно таймаут
1:49:12 *Mar 14.180: BR0:1 LCP: O CONFREQ [REQsent] идентификатор 25
len 15 1:49:12 *Mar 14.184: BR0:1 LCP: CHAP AuthProto (0x0305C22305)
1:49:12 *Mar 14.188: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A).
1:49:14 *Mar 14.160: BR0:1 LCP: ТАЙМАУТ: Состояние REQsent
1:49:14 *Mar 14.164: BR0:1 LCP: O CONFREQ [REQsent] идентификатор 26
len 15 1:49:14 *Mar 14.168: BR0:1 LCP: CHAP AuthProto (0x0305C22305)
1:49:14 *Mar 14.172: BR0:1 LCP: MagicNumber 0x545D708A (0x0506545D708A) Эта проблема могла быть вызвана следующим:
    удаленный конец, не настраиваемый для PPP. Настройте инкапсуляцию команды ppp на удаленном конце Пакеты, не проходящие через средства передачи. Наиболее распространенная причина поскольку это - Несоответствие скорости ISDN

Природа проблемы, из точки зрения ISDN, то, что одна сторона, вероятно, соединение в 56k, в то время как другая сторона соединяется в 64k. Это возможно то, что локальный или удаленный канал не поддержит по умолчанию 64K соединения. Попытайтесь настроить на обоих концах скорость передачи в 56 кбит/с.

Для Профилей DDR:

<блок цитирования> <пред> <цвет шрифта = "#000000"> maui-soho-01 (config) # интерфейсный Dialer1 <цвет шрифта = "#000000"> maui-soho-01 (config-if) # строка номеронабирателя 81560 классов 56k
<цвет шрифта = "#0000FF"> ! - Набирают 81560 и используют класс сопоставления, названный " 56k" (определенный ниже) <цвет шрифта = "#000000"> maui-soho-01 (config-if) # выход <цвет шрифта = "#000000"> maui-soho-01 (config) # map-class dialer 56k
<цвет шрифта = "#0000FF">! - класс сопоставления, названный " 56k" это использовалось со строкой номеронабирателя ! - в международном Dialer1
maui-soho-01 (config-map-clas) # скорость dialer isdn 56
<цвет шрифта = "#0000FF">! - Устанавливают скорость вызова быть 56k (по умолчанию является 64k)

<цвет шрифта = "#000000"> Для Унаследованного профиля DDR (cхемы набора номеров):

<блок цитирования> <пред> <цвет шрифта = "#000000"> maui-soho-01 (config) # interface bri 0 maui-soho-01 (config-if) # ip cхемы набора номеров 10.1.1.1 скорости названия maui-nas-08 56 81560 <цвет шрифта = "#0000FF"> ! - Скорость ключевого слова 56 устанавливает скорость исходящего вызова в 56k

Возможная причина: Эти Два Маршрутизатора не Договариваются о Протоколе аутентификации (CHAP или PAP) для Использования

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

<блок цитирования> <пред> *Mar 1 0:07:24.051: BR0:1 LCP: я CONFREQ [ACKrcvd] идентификатор 136 len 14 *1 марта 0:07:24.055: BR0:1 LCP: PAP AuthProto (0x0304C023) *1 марта 0:07:24.059: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) <цвет шрифта = "#0000FF">! - Входящий CONFREQ (Запрос конфигурации), указывающий на узел, ! - готовый сделать PAP *1 марта 0:07:24.063: BR0:1 LCP: O CONFNAK [ACKrcvd] идентификатор 136 len 9 *1 марта 0:07:24.063: BR0:1 LCP: CHAP AuthProto (0x0305C22305) <цвет шрифта = "#0000FF"> ! - Маршрутизатор передают Настраивать-отрицательное-квитирование (CONFNAK) PAP отклонения ! - Маршрутизатор предлагает CHAP вместо этого *1 марта 0:07:24.087: BR0:1 LCP: я CONFREQ [ACKrcvd] идентификатор 137 len 14 *1 марта 0:07:24.091: BR0:1 LCP: PAP AuthProto (0x0304C023) *1 марта 0:07:24.091: BR0:1 LCP: MagicNumber 0x1110C3C5 (0x05061110C3C5) <цвет шрифта = "#0000FF">! - Узел еще раз запрашивает PAP ! - Это, вероятно, потому что PAP является единственным протоколом, настроенным на узле ! - Маршрутизатор будет еще раз PAP CONFNAK и предлагать CHAP *1 марта 0:07:24.095: BR0:1 LCP: O CONFNAK [ACKrcvd] идентификатор 137 len 9 *1 марта 0:07:24.099: BR0:1 LCP: CHAP AuthProto (0x0305C22305) <цвет шрифта = "#0000FF">! - NAK маршрутизатора PAP, и предлагает CHAP в 2-й раз *1 марта 0:07:24.119: BR0:1 LCP: Я TERMREQ [ACKrcvd] идентификатор 138 len 4 *1 марта 0:07:24.123: BR0:1 LCP: O TERMACK [ACKrcvd] идентификатор 138 len 4 <цвет шрифта = "#0000FF"> ! - Эти два маршрутизатора не могут договориться о параметрах LCP, таким образом, вызов разъединен

В этом случае проверьте настройку придерживающегося:

<блок цитирования> <пред> interface Dialer1 encapsulation ppp вызов pap аутентификации ppp chap <цвет шрифта = "#0000FF"> ! - Это разрешает и CHAP и PAP и одностороннюю проверку подлинности

Для получения дополнительной информации о Протоколе аутентификации по квитированию вызова (CHAP) или Протокол аутентификации пароля (PAP), обратитесь к следующим документам:

    Понимание и Проверка подлинности CHAP PPP Настройки Аутентификация "PPP" использование ppp chap hostname и вызова аутентификации ppp chap Команды Настройка и устранение проблем протокола аутентификации пароля PPP (PAP)

Можно также использовать Сообщество Cisco Support для дальнейшего Устранения проблем PPP.

Назад к блок-схеме устранения проблем <час> <название = "authen">

Устранение проблем: Успешно ли прошла PPP-аутентификация?

Проверьте результаты отладки для линии, похожей на следующую: <блок цитирования> <пред> *1 марта 0:06:36.943: BR0:1 PPP: Фаза произошла

Назад к блок-схеме устранения проблем <час> <название = "problems4">

Признак: Аутентификация "PPP" Не Следует

Удостоверьтесь, что вы настроили придерживающиеся линии:

<блок цитирования> <пред> interface Dialer1 ppp chap hostname XXXXX пароль "ppp chap" YYYYY ppp pap sent-username XXXXX паролей YYYYY

В примере, XXXXX имя пользователя, и YYYYY является вашим паролем.

примечание : Настройте только имя пользователя и пароль для аутентификации метод вы и одноранговая работа. Например, если вы оба не будете использовать PAP, тогда вы не требуете команды ppp pap sent-username . Однако, если вы не уверены ли одноранговый PAP поддержки или CHAP, затем настраивают обоих.

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

<блок цитирования> <пред> interface Dialer1 пароль "ppp chap" 7 140005

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

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

Пример 1

Сообщение как то ниже средств, что пароль CHAP не допустим.

<блок цитирования> <пред> *Mar 1 0:16:54.403: BR0:1 CHAP: Я БРОСАЮ ВЫЗОВ идентификатору 94 len 24 от "интернет-провайдера" <цвет шрифта = "#0000FF">! - Поступающий запрос вызова CHAP *1 марта 0:16:54.407: BR0:1 CHAP: Использование альтернативного имени хоста XXXXX <цвет шрифта = "#0000FF">! - Использование альтернативного имени хоста, настроенного с командой ppp chap hostname *1 марта 0:16:54.411: BR0:1 CHAP: интернет-провайдер Имени пользователя, не найденный *1 марта 0:16:54.415: BR0:1 CHAP: Использование пароля по умолчанию <цвет шрифта = "#0000FF">! - Использование пароля, настроенного с командой ppp chap password *1 марта 0:16:54.415: BR0:1 CHAP: O ОТВЕТ идентификатор 94 len 26 от "XXXXX" <цвет шрифта = "#0000FF">! - Передача ответа от " XXXXX" который является альтернативным именем хоста для маршрутизатора *1 марта 0:16:54.439: BR0:1 CHAP: Я СБОЙ идентификатор 94 сообщения len 25 "MD/DES выдерживают сравнение подведенный" <цвет шрифта = "#0000FF">! - Сбой приема данных по протоколу CHAP. Удаленный маршрутизатор был не в состоянии подтверждать подлинность этого маршрутизатора . <цвет шрифта = "#0000FF">! - Проверяют имя пользователя и пароль, настроенное на обоих маршрутизаторах *1 марта 0:16:54.447: BR0:1 LCP: Я TERMREQ [Открытый] идентификатор 165 len 4 *1 марта 0:16:54.451: BR0:1 LCP: O TERMACK [Открытый] идентификатор 165 len 4

Совет: сбой приема данных по протоколу CHAP (обозначенный CHAP: Я СБОЙ ) означает, что узел был неспособен подтвердить подлинность маршрутизатора. Используйте debug ppp согласование на равном маршрутизаторе для определения точной причины сбоя.

Для получения дополнительной информации обратитесь к документу PPP Аутентификация с помощью ppp chap hostname и аутентификации "PPP" вызов парня Команды .

Пример 2

Сообщение как то ниже могло означать, что имя пользователя CHAP не допустимо:

<блок цитирования> <пред> *Mar 1 0:18:34.831: BR0:1 CHAP: я БРОСАЮ ВЫЗОВ идентификатору 97 len 24 от "интернет-провайдера" <цвет шрифта = "#0000FF">! - Поступающий запрос вызова CHAP *1 марта 0:18:34.835: BR0:1 CHAP: Использование альтернативного имени хоста Xdwqdqw <цвет шрифта = "#0000FF">! - Использование альтернативного имени хоста, настроенного с командой ppp chap hostname *1 марта 0:18:34.839: BR0:1 CHAP: интернет-провайдер Имени пользователя, не найденный *1 марта 0:18:34.839: BR0:1 CHAP: Использование пароля по умолчанию <цвет шрифта = "#0000FF">! - Использование пароля, настроенного с командой ppp chap password *1 марта 0:18:34.843: BR0:1 CHAP: O ОТВЕТ идентификатор 97 len 28 от" Xdwqdqw " <цвет шрифта = "#0000FF">! - Передача ответа от " Xdwqdqw" который является альтернативным именем хоста ! - для маршрутизатора *1 марта 0:18:34.867: BR0:1 CHAP: Я СБОЙ идентификатор 97 len 26 сообщением является "Ошибка проверки подлинности" <цвет шрифта = "#0000FF">! - Сбой приема данных по протоколу CHAP. Удаленный маршрутизатор был не в состоянии подтверждать подлинность ! - этот маршрутизатор. Проверьте имя пользователя и пароль, настроенное на обоих маршрутизаторах *1 марта 0:18:34.875: BR0:1 LCP: Я TERMREQ [Открытый] идентификатор 171 len 4 *1 марта 0:18:34.879: BR0:1 LCP: O TERMACK [Открытый] идентификатор 171 len 4 <блок цитирования>

Совет: сбой приема данных по протоколу CHAP (обозначенный CHAP: Я СБОЙ ) означает, что узел был неспособен подтвердить подлинность маршрутизатора. Используйте debug ppp согласование на равном маршрутизаторе для определения точной причины сбоя.

Для получения дополнительной информации обратитесь к документу PPP Аутентификация с помощью ppp chap hostname и аутентификации "PPP" вызов парня Команды .

Пример 3

Сообщение как ниже средств, что пароль PAP не допустим:

<блок цитирования> <пред> *Mar 1 0:21:33.927: BR0:1 PAP: O AUTH-REQ идентификатор 3 len 18 от "XXXXX" <цвет шрифта = "#0000FF">! - Исходящий Запрос Аутентификации PAP от XXXXX ! - XXXXX имя пользователя, настроенное в ! - ppp pap sent-username XXXXX паролей YYYYY *1 марта 0:21:33.947: BR0:1 PAP: я AUTH-NAK идентификатор 3 сообщения len 27 "Ошибка проверки подлинности" <цвет шрифта = "#0000FF">! - Входящий сбой PAP. Узел не мог подтвердить подлинность этого маршрутизатора ! - Проверяют, что имя пользователя и пароль настроило на обоих маршрутизаторах ! - идентичен *1 марта 0:21:33.955: BR0:1 LCP: Я TERMREQ [Открытый] идентификатор 182 len 4 *1 марта 0:21:33.955: BR0:1 LCP: O TERMACK [Открытый] идентификатор 182 len 4 *1 марта 0:21:33.959: BR0:1 PPP: Фаза ЗАВЕРШАЕТСЯ <блок цитирования> Для получения дополнительной информации обратитесь к документу Настройка и устранение проблем протокола аутентификации пароля PPP (PAP) .

Пример 4

Сообщение как ниже средств, что имя пользователя PAP не допустимо:

<блок цитирования> <пред> *1 марта 0:20:41.023: BR0:1 PPP: Фаза ПОДТВЕРЖДАЕТ ПОДЛИННОСТЬ узлом *1 марта 0:20:41.031: BR0:1 PAP: O идентификатор AUTH-REQ 1 len 17 от "ewddew" <цвет шрифта = "#0000FF">! - Исходящий Запрос Аутентификации PAP от ewddew ! - ewddew является именем пользователя, настроенным в ! - ppp pap sent-username ewddew пароль YYYYY *1 марта 0:20:41.047: BR0:1 PAP: я AUTH-NAK идентификатор 1 len 27 сообщением является "Ошибка проверки подлинности" <цвет шрифта = "#0000FF">! - Входящий сбой PAP. Удаленный маршрутизатор не мог подтвердить подлинность ! - этот маршрутизатор. Проверьте имя пользователя и пароль, настроенное на обоих маршрутизаторах ! - Примечание сбой Аутентификации PAP в примере 3 и 4 идентичны. ! - Следовательно единственный способ определить, ли имя пользователя, пароль или оба ! - неправильно должен выполнить debug ppp negotiation на маршрутизаторе аутентификации *1 марта 0:20:41.055: BR0:1 LCP: Я TERMREQ [Открытый] идентификатор 178 len 4 *1 марта 0:20:41.059: BR0:1 LCP: O TERMACK [Открытый] идентификатор 178 len 4 *1 марта 0:20:41.063: BR0:1 PPP: Фаза ЗАВЕРШАЕТСЯ <блок цитирования>

Для получения дополнительной информации обратитесь к документу Настройка и устранение проблем протокола аутентификации пароля PPP (PAP) .

Можно также использовать Сообщество Cisco Support для дальнейшего Устранения проблем PPP.

Назад к блок-схеме устранения проблем

<час> <название = "ncpup">

Устранение проблем: Фаза PPP NCP (IPCP) завершена?

Ключевой элемент, о котором выполняют согласование в IPCP, является адресом каждого узла. Перед согласованием IPCP, каждый узел находится в одном из двух возможных состояний; или это имеет IP-адрес или это не делает. Если узел уже имеет адрес, он передает тот адрес в CONFREQ к другому узлу. Если адрес приемлем для другого узла, CONFACKis возвращенный. Если адрес не приемлем, ответ является CONFNAK, содержащим адрес для узла для использования.

Это - единственная фаза, которая не может быть должным образом определена путем взгляда на просто одна линия. Чтобы быть уверенным, что IP Control Protocol (IPCP) подходит должным образом, необходимо проверить, что о IP-адресах выполнили согласование в обоих направлениях. Найдите в отладочных данных следующие строки:

<блок цитирования> <пред> *1 марта 0:06:36.967: BR0:1 IPCP: O CONFACK [REQsent] идентификатор 26 len 10 *1 марта 0:06:36.971: BR0:1 IPCP: обратитесь 194.183.201.1 (0x0306C2B7C901) и <блок цитирования> <пред> *1 марта 0:06:37.011: BR0:1 IPCP: Я CONFACK [ACKsent] идентификатор 4 len 10 *1 марта 0:06:37.015: BR0:1 IPCP: обратитесь 194.183.201.2 (0x0306C2B7C902) и <блок цитирования> <пред> *1 марта 0:06:37.015: BR0:1 IPCP: Состояние Открыто

Эти три набора линий могут не сразу придерживаться друг друга. Это важно то, что вы проверяете, существует ли выход, Настраивают, Подтверждают (O CONFACK) это имеет, среди других опций, адреса ниже его.

Должно также быть поступление, Настраивают, Подтверждают (я CONFACK) с другим IP-адрес ниже его.

Наконец, должна быть линия, сообщая, что состояние IPCP открыто. После этого, должна существовать возможность так успешно пропинговывают оба IP-адреса непосредственно от маршрутизатор.

Назад к блок-схеме устранения проблем <час>

<название = "problems5"> Признак: NCP PPP (IPCP) Согласование Не Следует

проблема: сбои согласования IP-адреса

Одна из причины, почему IPCP мог отказать, происходит из-за сбоя согласования IP-адреса. Например, NAS может пытаться назначить адрес на клиент в то время как клиентскому маршрутизатору настроили другой IP-адрес или другую типичную проблему когда запросы клиента адрес и NAS не имеют никаких адресов, доступный клиенту.

На Вызывающем маршрутизаторе:

Если вызываемый маршрутизатор назначает IP-адрес динамично на вызывающий маршрутизатор, проверьте, что у вас есть ip address negotiated команды в номеронабирателе интерфейс .

Если Поставщик/ИНТЕРНЕТ-ПРОВАЙДЕР NAS дал вам статический IP - адрес, проверьте что этот ip адрес (и маска подсети) настроен в интерфейсе номеронабирателя с командой IP-адрес обращается к subnet_mask .

На Вызываемом маршрутизаторе:

Гарантируйте, что интерфейс, управляющий соединением (например, int Dialer x), имеет IP-адрес и назначает адрес на узел с помощью одноранговый по умолчанию IP-адрес команда address .

примечание : Если клиентскому маршрутизатору настроили IP-адрес тогда, вы делаете не должен назначить адрес с помощью команды peer default ip address

Для получения дополнительной информации обратитесь к документу Коммутируемый доступ Технология: методики поиска и устранения проблем .

проблема: Вызываемый маршрутизатор отказывает Привязку профиля DDR

Если проверенное имя пользователя не совпадает с dialer remote-name настроенный под интерфейсом номеронабирателя, тогда вызов будет разъединен вызываемый маршрутизатор. Ниже приводится выходные данные номеронабирателя примера отладки для такого ошибка:

на вызывающем маршрутизаторе :

Придерживающаяся отладка показывает разъединение, вызванное плохой привязкой профиля DDR На вызванном маршрутизаторе; <блок цитирования> <пред> *Mar 15 3:19:13.050: BR0:1 CHAP: O БРОСАЮТ ВЫЗОВ идентификатору 32 len 33 от " maui-soho-03"
*Mar 15 3:19:13.094: BR0:1 CHAP: Я БРОСАЮ ВЫЗОВ идентификатору 32 len 33 от " maui-soho-01"
*Mar 15 3:19:13.094: BR0:1 CHAP: O идентификатор ОТВЕТА 32 len 33 от " maui-soho-03"
*Mar 15 3:19:13.134: BR0:1 CHAP: Я УСПЕХ идентификатор 32 len 4 <цвет шрифта = "#0000FF">! - Аутентификация CHAP успешна
*Mar 15 3:19:13.222: ISDN BR0: RX < - РАЗЪЕДИНЕНИЕ фунт = 8 callref = 0xA0
*Mar 15 3:19:13.226: Причина i = 0x8090 - Обычный сброс вызова <цвет шрифта = "#0000FF">! - Мы получили (RX) РАЗЪЕДИНЕНИЕ от узла ! - Мы должны переместить устранение проблем в вызываемый маршрутизатор
*Mar 15 3:19:13.238: ISDN BR0: TX-> фунт ВЫПУСКА = 8 callref = 0x20
*Mar 15 3:19:13.242: %LINK-3-UPDOWN: Интерфейс BRI0: 1, измененное состояние к вниз
*Mar 15 3:19:13.250: BR0 DDR: имеет общие 2 вызова (а), dial_out 0, dial_in 0
*Mar 15 3:19:13.254: BR0:1 PPP: Фаза ЗАВЕРШАЕТ
*Mar 15 3:19:13.254: BR0:1 LCP: Состояние Закрыто
*Mar 15 3:19:13.254: BR0:1 PPP: Фаза ВЫКЛЮЧЕНА
*Mar 15 3:19:13.254: BRI0:1 DDR: разъединение вызова

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

На Вызываемом маршрутизаторе:

Придерживающаяся отладка показывает вызов, отказывающий из-за проблем привязки профиля DDR:

<блок цитирования> <пред> *15 марта 3:54:09.804: BR0:1 CHAP: O идентификатор УСПЕХА 33
len 4 *Mar 15 3:54:09.808: BR0:1 CHAP: Обрабатывая сохраненную проблему, идентификатор 33
*Mar 15 3:54:09.812: BR0:1 DDR: Заверенный хост maui-soho-03 без соответствующего профиля DDR <цвет шрифта = "#0000FF">! - обязательный сбой, потому что dialer remote-name ! - не совпадает с проверенным именем пользователя
*Mar 15 3:54:09.816: BR0:1 DDR: разъединение вызова
*Mar 15 3:54:10.086: %LINK-3-UPDOWN: Интерфейс BRI0: 1, измененное состояние к вниз
*Mar 15 3:54:10.093: BR0:1 PPP: Фаза ЗАВЕРШАЕТ [0 sess, 0 загрузок]

Решение:

Настройте команду dialer pool number на интерфейсе номеронабирателя. Этот номер пула должен совпадать с номером пула, настроенным в физическом интерфейсе.

Настройте команду dialer remote-name на интерфейсе номеронабирателя. заданное название должно точно совпасть с именем пользователя, введенным удаленным маршрутизатором для аутентификации. В данном примере аутентифицированным именем пользователя является maui-soho-03.

Поскольку больше дополнительных сведений об устранении проблем на проблемах связывания обращается к документ <цвет шрифта = "#000000"> Настройка и Устранение проблем Профилей DDR .

Можно также использовать Сообщество Cisco Support для дальнейшего Устранения проблем PPP.

Назад к блок-схеме устранения проблем


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

<название = "problem6"> Признак: Вызовите Разъединения Преждевременно, или Вызов Делает Не разъединяют во всем

Если вызов неожиданно разъединяет, или вызов никогда не разъединяет, проверьте idle-timeout номеронабирателя и представляющий интерес трафик defintion. Можно использовать отладку пакет номеронабирателя дает команду, чтобы видеть, является ли определенный пакет содержательным или нет. Например: :

<пред> 26 апреля 1:57:24.483: Di1 DDR: ip (s=192.168.1.1, d=224.0.0.5) , 64 байта, выход неинтересного (перечисляют 101) 26 апреля 1:57:26.225: Di1 DDR: ip (s=192.168.1.1, d=10.1.1.1) , 100 байтов, содержательный выход (перечисляют 101) В вышеупомянутом примере OSPF hellos является неинтересным на access-list 101, в то время как второй пакет является содержательным на access-list 101.
    Отрегулировал idle-timeout номеронабирателя в конфигурации интерфейса программы для набора номера. По умолчанию составляет 120 секунд, но можно хотеть повысить или понизить это значение в зависимости от потребностей.

    Изменение определение содержательного трафика (настроенный с dialer-list команда. Если вызов разъединяет преждевременно, можно хотеть определить содержательное торгуйте более свободно. Если вызов никогда не разъединяет изменение, содержательный определение трафика, чтобы быть более строгим. Например, можно определить маршрутизацию трафик протокола как неинтересный. Ниже представлено определение образца содержательного трафика: <блок цитирования> <пред> access-list 101 отмечают Представляющий интерес трафик для dialer-list 1 access-list 101 запрещает ospf любой любой
    <цвет шрифта = "#0000FF">!---отмечают OSPF как неинтересный
    !---Это предотвратит OSPF hellos от хранения соединения.

    access-list 101 запрещают udp любые любые ntp eq <цвет шрифта = "#0000FF">! - Определяют трафик ntp как НЕ содержательный.
    ! - Это будет препятствовать тому, чтобы поддержал периодический трафик ntp ! - соединение неопределенно.

    ip разрешения access-list 101 любой любой <цвет шрифта = "#0000FF">
    ! - Весь другой IP - трафик является содержательным.
    ! - Изменяют это в зависимости от потребностей трафика.

    список protocol ip dialer-list 1 101 <цвет шрифта = "#0000FF"> ! - этот представляющий интерес трафик применен к номеронабирателю ! - интерфейс с помощью dialer-group 1

    Для получения дополнительной информации обратитесь к документу Коммутируемый доступ Технология: обзоры и пояснения .

<название = "problem7"> Признак: Маршрутизатор Периодически Наборы Соединение

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

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

    Определяет трафик, который заставляет ссылку набирать. Определяет тот трафик как неинтересный.

Определяют Трафик который Причины Ссылка на Набор.

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

Совет : Пока в частности не необходимый, назовите все протоколы маршрутизации настроенными на маршрутизаторе как неинтересный.

Следующий пример показывает периодический OSPF hellos отмечаемый как содержательный:

<блок цитирования> <пред> *Mar 15 0:25:58.865: Di1 DDR: ip (s=172.22.25.1, d=224.0.0.5 ), 64 байта, выход содержательного (IP РАЗРЕШЕНИЕ)

Единственный способ определить это, которое вышеупомянутый пакет приветствие OSPF, от адрес назначения (DA) (d=224.0.0.5), который определен для OSPF. Следующая таблица перечисляет адреса, используемые для некоторых общих протоколов маршрутизации:

<ширина таблицы = "43%" граничат = "1"> <концерн bgcolor = "#f5f5f5">
<отделение выравниваются = "центр"> Протокол маршрутизации <отделение выравниваются = "центр"> Адрес назначения (DA) для Периодического
Обновления или Пакеты Keepalive
<отделение выравниваются = "центр"> RIPv1 <отделение выравниваются = "центр"> 255.255.255.255 <отделение выравниваются = "центр"> RIPv2 <отделение выравниваются = "центр"> 224.0.0.9 <отделение выравниваются = "центр"> EIGRP <отделение выравниваются = "центр"> 224.0.0.10 <отделение выравниваются = "центр"> OSPF <отделение выравниваются = "центр"> 224.0.0.5