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

Устранение неполадок при дозвоне - IOS DDR инициирует вызов

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


Содержание


Введение

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

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

Требования

Этот документ покрывает три главных сценария; прежде чем вы начнете устранять неполадки, определять, какой вызов предпринимается, и перейдите к тому разделу:

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

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

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

History

Коммутируемый доступ является просто приложением открытой коммутируемой телефонной сети (PSTN), которая несет данные от имени конечного пользователя. Это включает устройство Customer Premises Equipment (CPE), передавая телефонному коммутатору (АТС) номер телефона, к которому можно направить соединение. AS3600, AS5200, AS5300 и AS5800 являются всеми примерами маршрутизаторов, которые имеют способность выполнить Primary Rate Interface (PRI) наряду с банками цифровых модемов. AS2511, с другой стороны, является примером маршрутизатора, который связывается с внешними модемами.

Рынок поставщиков услуг связи вырос значительно, и рынок теперь требует более высоких плотностей модемов. Ответ на эту потребность является более высокой степенью взаимодействия с оборудованием телефонной компании и разработкой цифрового модема. Это - модем, который способен к прямому цифровому доступу к PSTN. В результате более быстрые модемы CPE были теперь разработаны, которые используют преимущества качества сигнала, которым обладают цифровые модемы. Факт, что цифровые модемы, соединяющиеся в PSTN через PRI или Интерфейс (BRI), могут передать данные в по 53k с помощью стандарта связи V.90, свидетельствует об успехе идеи.

Первые серверы доступа были AS2509 и AS2511. AS2509 мог поддержать 8 входящих соединений с помощью внешних модемов, и AS2511 мог поддержать 16. AS5200 был начат с 2 PRI и мог поддержать 48 пользователей, использующих цифровые модемы, и он представлял крупный шаг вперед вперед в технологии. Плотности модемов постоянно увеличивались с AS5300, поддерживающим 4 и затем 8 PRI. Наконец, AS5800 был представлен для удовлетворения потребностей установок для нужд поставщика услуг, бывших должных обработать T1s множеств входящих данных и сотни подключений пользователя.

Несколько упоминаний переноса устаревших технологий в обсуждении истории технологии набора номера. 56Kflex более старое (предварительный v.90) 56k модемный стандарт, который был предложен Роквеллом. Cisco поддерживает версию 1.1 56Kflex стандарт на его внутренних модемах, но рекомендует переместить модемы CPE на V.90 как можно скорее. Другая устаревшая технология является AS5100. AS5100 был совместным предприятием между Cisco и изготовителем модема. AS5100 был создан как способ увеличить плотность модемов с помощью квадратических модемных карт. Это вовлекло группу AS2511, созданных как карты, которые вставили в объединительную плату, разделенную квадратическими модемными картами и двойной картой T1.

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

Дополнительные сведения об условных обозначениях в документах см. Cisco Technical Tips Conventions.

Устройство прямой записи на диск Cisco IOS запускает вызов

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

Общий поток обоснования напоминает придерживающееся:

  1. Технология DDR инициирует вызов? (Да отвечает на усовершенствования на следующий вопрос.)

  2. Если это - асинхронный модем, сценарии диалогового взаимодействия выполняют ожидаемые команды?

  3. Вызов разбирает его к PSTN?

  4. Удаленный конец отвечает на звонок?

  5. Вызов завершает?

  6. Данные передают по ссылке?

  7. Сеанс установлен? (PPP или Терминал)

Чтобы видеть, пытается ли номеронабиратель позвонить его удаленному назначению, используйте события номеронабирателя для отладки команды. Более подробная информация может быть получена от пакета debug dialer, но команда debug dialer packet является загруженностью ресурсов и не должна использоваться на занятой системе, которая имеет работу интерфейсов программы для набора номера.

Следующая линия выходных данных debug dialer events для пакета IP перечисляет название интерфейса DDR и адреса источника и назначения пакета:

Dialing cause: Async1: ip (s=172.16.1.111 d=172.16.2.22)

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

Таблица 1: Трафик не инициирует набираемую попытку

Возможные причины Предлагаемые действия
Пропавшие без вести или неправильные определения "представляющего интерес трафика"
  1. Использование команды show running-config, гарантируйте, что интерфейс настроен с dialer-group и что существует dialer-list глобального уровня , настроенный с соответствующим номером.
  2. Гарантируйте, что команда dialer-list настроена, чтобы разрешить или полный протокол или разрешить трафик, совпадающий со списком доступа
  3. Проверьте, что access-list объявляет пакеты, собирающиеся через ссылку быть содержательными. Один полезный тест должен использовать привилегированный debug ip packet [номер списка] команды exec с помощью количества соответствующего списка доступа. Затем попытайтесь пропинговать, или иначе передать трафик через ссылку. Если фильтрации содержательного трафика были должным образом определены, вы будете видеть пакеты в выходных данных отладки. Если существуют выходные данные no debug от этого теста, access-list не совпадает с пакетами.
Состояние интерфейса Используйте команду show interfaces <имя интерфейса>, чтобы гарантировать, что интерфейс находится в "up/up (spoofing)" состояния.
  • Интерфейс в режиме "standby"
Другой (основной) интерфейс на маршрутизаторе был настроен для использования интерфейса номеронабирателя в качестве резервного интерфейса. Кроме того, основной интерфейс не в состоянии "вниз/вниз", который требуется, чтобы приносить интерфейс номеронабирателя из режима ожидания. Кроме того, задержка резервного копирования должна быть настроена на основном интерфейсе, или команда резервного интерфейса никогда не будет принуждаться. Чтобы проверить, что интерфейс номеронабирателя изменится от "резерва" до "up/up (spoofing)", обычно необходимо вытянуть кабель от основного интерфейса. Просто завершение основного интерфейса с configuration command shutdown не поместит основной интерфейс во "вниз/вниз", но вместо этого поместит его в "административно выключенный"? не та же вещь. Кроме того, если первичное соединение через Frame Relay, Конфигурация Frame Relay должна быть сделана на последовательном подчиненном интерфейс типа точка-точка, и телефонная компания должна передавать "Активный" бит. Эта практика также известна как "сквозной Интерфейс локального управления (LMI)".
  • Интерфейс "административно выключен"
Интерфейс номеронабирателя был настроен с командой shutdown. Когда маршрутизатор Cisco загружен в самый первый раз, это - также состояние по умолчанию любого интерфейса. Используйте команду настройки интерфейса никакое завершение для удаления этого препятствия.
Неправильная маршрутизация Выполните ip route exec command show [a.b. c . d], где a.b. c . d является адресом интерфейса номеронабирателя удаленного маршрутизатора. Если ненумерованный ip используется на удаленном маршрутизаторе, используйте адрес интерфейса, перечисленного в команде ip unnumbered. Выходные данные должны показать маршрут удаленному адресу через интерфейс номеронабирателя. Если существует никакой маршрут, гарантируйте, что статичный или плавающие статические маршруты были настроены путем исследования выходных данных show running config. Если существует маршрут через интерфейс кроме интерфейса номеронабирателя, результат - то, что DDR используется в качестве резервной копии. Исследуйте конфигурацию маршрутизатора, чтобы удостовериться, что статичный или плавающие статические маршруты были настроены. Надежный способ для тестирования маршрутизации, в этом случае, должен отключить первичное соединение и выполнить show ip route [a.b. c . d] команда, чтобы проверить, что правильный маршрут был установлен в таблице маршрутизации.

Примечание: При попытке этого во время операций действующей сети событие dial может быть инициировано. Этот вид тестирования лучше всего выполнен во время циклов планового технического обслуживания.

Выполнение вызова

Если маршрутизация и фильтрации содержательного трафика корректны, вызов должен инициироваться. Это может быть замечено при помощи debug dialer events:

Async1 DDR: Dialing cause ip (s=10.0.0.1, d=10.0.0.2)



Async1 DDR: Attempting to dial 5551212

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

Таблица 2: Назовите не размещенными

Возможная проблема Предлагаемые действия
Неправильная cхема набора номеров Используйте команду show running-config, чтобы гарантировать, что интерфейс набора номера настроен по крайней мере с одной инструкцией схемы набора номеров , которая указывает к адресу и вызываемому номеру удаленного узла.
Неверно настроенное профиль системы набора номера Используйте команду show running-config, чтобы гарантировать, что Интерфейс номеронабирателя настроен с командой dialer pool X и что интерфейс номеронабирателя на маршрутизаторе настроен с соответствующим членом пула программ набора номеров X . Если профили DDR должным образом не настроены, можно видеть сообщение отладки как:
Dialer1: Can't place call, no dialer pool set
Удостоверьтесь, что настроена строка номеронабирателя.

Затем, определите тип сред, который используется:

DDR внешнего асинхронного модема

  1. Для определения DDR внешнего асинхронного модема используйте следующие команды, затем попытайтесь позвонить:

    router# debug modem
    router# debug chat line <n>
    
    
  2. Для модемных вызовов сценарий диалогового взаимодействия должен выполниться для вызова продолжиться. Для номеронабирателя на основе схемы DDR, сценарий диалогового взаимодействия вызван параметром сценария модема в команде cхемы набора номеров. Если DDR основан на профиле DDR, это выполнено номеронабирателем командного сценария, настроенным на линии TTY. Оба метода полагаются на сценарий диалогового взаимодействия, существующий в глобальной конфигурации маршрутизатора, например:

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
    

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

    CHAT1: Attempting async line dialer script
    
    
    CHAT1: Dialing using Modem script: callout & System script: none
    CHAT1: process started
    CHAT1: Asserting DTR
    CHAT1: Chat script callout started
    CHAT1: Sending string: AT
    CHAT1: Expecting string: OK
    CHAT1: Completed match for expect: OK
    CHAT1: Sending string: atdt5551212
    CHAT1: Expecting string: CONNECT
    CHAT1: Completed match for expect: CONNECT
    CHAT1: Chat script callout finished, status = Success
    
  3. Гарантируйте, что сценарий диалогового взаимодействия делает попытку ожидаемого вызова (т.е. верный номер) на основе "Передачи строки". Если сценарий диалогового взаимодействия не пытается сделать ожидаемый вызов, проверьте конфигурацию сценария диалогового взаимодействия. Используйте команду start-chat в подсказке командной строки для инициирования сценария диалогового взаимодействия вручную.

  4. Наблюдение "Таймаута, ожидающего: ПОДКЛЮЧЕНИЕ" может описать несколько других возможностей:

    • Возможность 1: локальный модем фактически не размещает вызов. Проверьте, что модем может заказать телефонный разговор путем выполнения обратного доступа по протоколу Telnet к модему и вручную инициирования набора. Если удаленный конец, кажется, не отвечает, не проверяет, что вызов размещается вызывающим модемом путем вызова локального номера вручную с <number> команды ATDT и прислушивания к вызову.

    • Возможность 2: удаленный модем не отвечает. Протестируйте это путем набора номера удаленного модема с обычным телефоном POTS. Попробуйте это:

      1. Гарантируйте, что номер вызываемого телефона корректен. Используйте телефон для вызова номера получения. Обязательно используйте тот же кабель для стены, которую использовал модем. Если вызов в ручном режиме в состоянии достигнуть асинхронного модема получения, вызывающий модем может не работать правильно. Проверьте модем и замените при необходимости.

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

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

      4. Если это - междугородний вызов, имейте попытку вызывающей стороны другой (известная польза) междугородный номер. Если это работает, средство получения или линия не могут быть настроены для получения междугородних вызовов. Если линия, инициировавшая передачу данных не может достигнуть никаких других междугородных номеров, ей нельзя было включить большое расстояние. Попробуйте 1010 кодов за другие междугородные компании.

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

    • Возможность 3: набранный номер является неправильным. Проверьте номер, набрав его вручную. Исправьте конфигурацию, при необходимости.

    • Возможность 4: пробное подключение модема занимает слишком много времени, или ЗНАЧЕНИЕ ТАЙМАУТА слишком низко. Попытайтесь увеличить ЗНАЧЕНИЕ ТАЙМАУТА в команде chat-script. Если ТАЙМАУТ уже является 60 секундами или больше, может быть проблема с кабелем между модемом и DTE, к которому это подключено. Сбои пробного включения могут также указать на проблему с каналом или несовместимость модема.

      Для добираний до сути относительно ошибок отдельного модема перейдите к приглашению AT в вызывающем модеме с обратным доступом по протоколу Telnet. Если возможно, доберитесь до приглашения AT модема получения также. Большинство модемов укажет на вызов к терминальной сессии, подключенной к их подключению DTE. ATM1 использования для имения модема передает звуки своему динамику так, чтобы люди в каждом конце могли услышать то, что происходит на линии.

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

  5. Если все хорошо работает, и вы все еще не можете соединиться на своем асинхронном модеме DDR CAS, попробовать Отладку PPP. Используйте команды:

    router# debug ppp negotiation
         router# debug ppp authentication
    

    Если сценарий диалогового взаимодействия завершает успешно, модемы связаны. Консультируйтесь с Разделом "Устранение проблем PPP" в Главе 17 Межсетевого Руководства по поиску и устранению проблем для следующего шага в устранении проблем соединения.

Маршрутизация вызовов по запросу (DDR) на асинхронном модеме CAS T1/E1

  1. Для определения асинхронного модема DDR T1/E1 CAS используйте следующие команды, затем попытайтесь позвонить:

    warning % Warning:  Выполнение отладок на занятой системе могло завершиться катастрофическим отказом маршрутизатор путем перегрузки ЦП или переполнения буфера консоли!

    router# debug modem
    router# debug chat or debug chat line n
    
    router# debug modem csm
    router# debug cas
    

    Примечание: Команда debug cas доступна на платформах Cisco AS5200 и AS5300 рабочая Cisco IOS?? Выпуск ПО 12.0 (7) T и позже. В предыдущих версиях IOS команда service internal должна была бы быть введена в основной уровень конфигурации маршрутизатора, и mgmt модема csm отладка-rbs должен будет быть введен в подсказку командной строки. Отладка на Cisco AS5800 требует соединения с магистральной картой. (Используйте mgmt модема csm No-debug-rbs для выключения отладки.)

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

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
    

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

    CHAT1: Attempting async line dialer script
    
    
    CHAT1: Dialing using Modem script: callout & System script: none
    CHAT1: process started
    CHAT1: Asserting DTR
    CHAT1: Chat script callout started
    CHAT1: Sending string: AT
    CHAT1: Expecting string: OK
    CHAT1: Completed match for expect: OK
    CHAT1: Sending string: atdt5551212
    CHAT1: Expecting string: CONNECT
    CHAT1: Completed match for expect: CONNECT
    CHAT1: Chat script callout finished, status = Success
    
  3. Гарантируйте, что сценарий диалогового взаимодействия делает попытку ожидаемого вызова (т.е. верный номер) на основе "Передачи строки". Если сценарий диалогового взаимодействия не пытается сделать ожидаемый вызов, проверьте конфигурацию сценария диалогового взаимодействия. Используйте команду start-chat в подсказке командной строки для инициирования сценария диалогового взаимодействия вручную.

  4. Наблюдение "Таймаута, ожидающего: ПОДКЛЮЧЕНИЕ" может описать несколько других возможностей:

    • Возможность 1: локальный модем фактически не размещает вызов. Проверьте, что модем может заказать телефонный разговор путем выполнения обратного доступа по протоколу Telnet к модему и вручную инициирования набора. Если удаленный конец, кажется, не отвечает, не проверяет, что вызов размещается модемом путем вызова локального номера вручную с <number> команды ATDT и прислушивания к вызову.

      Для исходящих вызовов через T1 или E1 CAS и интегрированные цифровые модемы, большая часть устранения проблем подобна другому Устранению проблем DDR. То же сохраняется, также, для исходящих перекличек интегрированного модема линия PRI. Уникальные функции, вовлеченные в звонка этим способом, требуют специальной отладки в случае ошибки вызова.

      Что касается других ситуаций DDR, необходимо гарантировать, что потребована попытка вызова. Используйте debug dialer events для этой цели. См. DDR IOS , ранее в этой статье.

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

      router# debug modem
      router# debug modem csm
      router# debug cas 
      

      Примечание: Команда debug cas впервые появилась в версии IOS 12.0 (7) T для AS5200 и AS5300. Более ранние версии IOS используют system-level configuration command service internal наряду с exec command modem-mgmt debug rbs:

      Включение отладок:

      router#conf t 
      Enter configuration commands, one per line.  End with CNTL/Z. 
      router(config)#service internal 
      router(config)#^Z 
      router#modem-mgmt csm ? 
        debug-rbs     enable rbs debugging 
        no-debug-rbs  disable rbs debugging 
      router#modem-mgmt csm debug-rbs 
      router# 
      neat msg at slot 0: debug-rbs is on 
      neat msg at slot 0: special debug-rbs is on 
      

      Выключение отладок:

      router#modem-mgmt csm no-debug-rbs 
      neat msg at slot 0: debug-rbs is off 

      Отладка этой информации о AS5800 требует соединения с магистральной картой. Ниже приводится пример обычного исходящего вызова по T1 CAS, который настроен и настроен для Сигнализации с заземлением FXS:

      Mica Modem(1/0): Rcvd Dial String(5551111) 
      [Modem receives digits from chat script]
      
      CSM_PROC_IDLE: CSM_EVENT_MODEM_OFFHOOK at slot 1, port 0 
      
      CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
      EVENT_CHANNEL_LOCK at slot 1 and port 0 
      
      CSM_PROC_OC4_DIALING: 
      CSM_EVENT_DSX0_BCHAN_ASSIGNED at slot 1, port 0 
      
      Mica Modem(1/0): Configure(0x1) 
      
      Mica Modem(1/0): Configure(0x2) 
      
      Mica Modem(1/0): Configure(0x5) 
      
      Mica Modem(1/0): Call Setup 
      
      neat msg at slot 0: (0/2): Tx RING_GROUND 
      
      Mica Modem(1/0): State Transition to Call Setup 
      
      neat msg at slot 0: (0/2): Rx TIP_GROUND_NORING 
      [Telco switch goes OFFHOOK]
      
      CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
      EVENT_START_TX_TONE at slot 1 and port 0 
      
      CSM_PROC_OC5_WAIT_FOR_CARRIER: 
      CSM_EVENT_DSX0_START_TX_TONE at slot 1, port 0 
      
      neat msg at slot 0: (0/2): 
      Tx LOOP_CLOSURE [Now the router goes OFFHOOK]
      
      Mica Modem(1/0): Rcvd Tone detected(2) 
      
      Mica Modem(1/0): Generate digits:called_party_num=5551111 len=8 
      
      Mica Modem(1/0): Rcvd Digits Generated 
      
      CSM_PROC_OC5_WAIT_FOR_CARRIER: 
      CSM_EVENT_ADDR_INFO_COLLECTED at slot 1, port 0 
      
      CSM_RX_CAS_EVENT_FROM_NEAT:(A003):  
      EVENT_CHANNEL_CONNECTED at slot 1 and port 0 
      
      CSM_PROC_OC5_WAIT_FOR_CARRIER: 
      CSM_EVENT_DSX0_CONNECTED at slot 1, port 0 
      
      Mica Modem(1/0): Link Initiate 
      
      Mica Modem(1/0): State Transition to Connect 
      
      Mica Modem(1/0): State Transition to Link 
      
      Mica Modem(1/0): State Transition to Trainup 
      
      Mica Modem(1/0): State Transition to EC Negotiating 
      
      Mica Modem(1/0): State Transition to Steady State 
      
      Mica Modem(1/0): State Transition to Steady State Speedshifting 
      
      Mica Modem(1/0): State Transition to Steady State
      

      Отладки для T1s и E1 с другими типами передачи сигналов подобны.

      Получение к этой точке в отладке указывает, что вызов и модемы с автоответом обучались и соединились и что высокоуровневые протоколы могут начать выполнять согласование. Если модем должным образом выделен для исходящего вызова, но связь прерывается добираться настолько далеко, T1 должен быть исследован. Используйте команду show controller t1/e1, чтобы проверить, что работает T1/E1. Посмотрите Последовательные линии Устранения проблем для пояснения выходных данных show controller. Если T1/E1 не работает должным образом, Устранение проблем t1/e1 необходимо.

    • Возможность 2: удаленный модем не отвечает. Протестируйте это путем набора номера удаленного модема с обычным телефоном. Попробуйте это:

      1. Гарантируйте, что номер вызываемого телефона корректен. Используйте телефон для вызова номера получения.

      2. Гарантируйте, что вызов в ручном режиме в состоянии достигнуть асинхронного модема ответа. Если вызов в ручном режиме в состоянии достигнуть асинхронного модема ответа, линия CAS не может быть настроена для разрешения исходящих голосовых вызовов.

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

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

      5. Если это - междугородний звонок, имейте попытку вызывающей стороны другой (известная польза) номер для междугороднего звонка. Если это работает, средство получения или линия не могут быть настроены для получения междугородних звонков. Если инициирующее (CAS), линия не может достигнуть никаких других междугородных номеров, ей нельзя было включить большое расстояние. Попробуйте 10-10 кодов за другие междугородные компании.

      6. Наконец, попробуйте другого (известная польза) локальный номер от инициирующей линии CAS. Если связь все еще прерывается, имейте проверку telco (телефонная компания) CAS.

    • Возможность 3: набранный номер является неправильным. Проверьте номер, набрав его вручную. Исправьте конфигурацию, при необходимости.

    • Возможность 4: пробное подключение модема занимает слишком много времени, или ЗНАЧЕНИЕ ТАЙМАУТА слишком низко. Попытайтесь увеличить ЗНАЧЕНИЕ ТАЙМАУТА в команде chat-script. Если ТАЙМАУТ уже является 60 секундами или больше, может быть проблема с кабелем между модемом и DTE, к которому это подключено. Сбои пробного включения могут также указать на проблему с каналом или несовместимость модема.

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

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

  5. Если все хорошо работает, и вы все еще не можете соединиться на своем асинхронном модеме DDR CAS, попробовать Отладку PPP. Если сценарий диалогового взаимодействия завершает успешно, и отладки PPP указывают на сбой, консультируются с Разделом "Устранение проблем PPP" в Главе 17 Межсетевого Руководства по поиску и устранению проблем.

Маршрутизация вызовов по запросу (DDR) на асинхронном модеме PRI

  1. Для определения асинхронного модема DDR PRI используйте следующие команды, затем попытайтесь позвонить:

    warning % Warning:  Выполнение отладок на занятой системе могло завершиться катастрофическим отказом маршрутизатор путем перегрузки ЦП или переполнения буфера консоли!

    router# debug modem
    router# debug chat
    router# debug modem csm
    router# debug isdn q931
    router# debug isdn
    router# debug ppp negotiate
    router# debug ppp authenticate
    
  2. Для модемных вызовов сценарий диалогового взаимодействия должен выполниться для вызова продолжиться. Для номеронабирателя на основе схемы DDR, сценарий диалогового взаимодействия вызван параметром сценария модема в команде cхемы набора номеров. Если DDR основан на профиле DDR, это выполнено номеронабирателем командного сценария, настроенным на линии TTY. Оба метода полагаются на сценарий диалогового взаимодействия, существующий в глобальной конфигурации маршрутизатора, такой как:

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c

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

    CHAT1: Attempting async line dialer script
    
    
    CHAT1: Dialing using Modem script: callout & System script: none
    CHAT1: process started
    CHAT1: Asserting DTR
    CHAT1: Chat script callout started
    CHAT1: Sending string: AT
    CHAT1: Expecting string: OK
    CHAT1: Completed match for expect: OK
    CHAT1: Sending string: atdt5551212
    CHAT1: Expecting string: CONNECT
    CHAT1: Completed match for expect: CONNECT
    CHAT1: Chat script callout finished, status = Success
    
  3. Гарантируйте, что сценарий диалогового взаимодействия делает попытку ожидаемого вызова (верный номер) на основе "Передачи строки". Если сценарий диалогового взаимодействия не пытается сделать ожидаемый вызов, проверьте конфигурацию сценария диалогового взаимодействия. Используйте команду start-chat в подсказке командной строки для инициирования сценария диалогового взаимодействия вручную.

  4. Наблюдение "Таймаута, ожидающего: ПОДКЛЮЧЕНИЕ" может описать несколько других возможностей:

    • Возможность 1: локальный модем фактически не размещает вызов. Проверьте, что модем может заказать телефонный разговор путем выполнения обратного доступа по протоколу Telnet к модему и вручную инициирования набора. Если удаленный конец, кажется, не отвечает, не проверяет, что вызов размещается модемом путем вызова локального номера вручную с <number> команды ATDT и прислушивания к вызову. Если никакой вызов не выходит, включите отладки ISDN. На первое подозрение в сбое ISDN на BRI всегда проверяйте выходные данные от статуса show isdn. Ключевые вещи обратить внимание состоят в том, что Уровень 1 должен быть Активным, и Уровень 2 должен быть в состоянии MULTIPLE_FRAME_ESTABLISHED. См. Межсетевого Главу Руководства по поиску и устранению проблем 16, "Интерпретацию команды show isdn status" для получения информации о чтении этих выходных данных, а также для корректирующих показателей.

      Для исходящих вызовов ISDN debug isdn q931 и debug isdn event являются лучшими программными средствами для использования. К счастью, отладка исходящих вызовов подобно отладке входящих вызовов. Обычный успешный вызов мог бы быть похожим на это:

      *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
      Call to 5553759 at 64 Kb/s
      
      *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
      callref = 0x2C
      *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
      *Mar 20 21:07:45.041:         Channel ID i = 0x83
      *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
      *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
      callref = 0xAC
      *Mar 20 21:07:45.145:         Channel ID i = 0x89
      *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
              Channel ID i = 0x0101
      *Mar 20 21:07:45.161:   -------------------
              Channel ID i = 0x89
      *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
      callref = 0xAC
      *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
      

      Обратите внимание на то, что сообщение CONNECT является Индикатором успеха. Если ПОДКЛЮЧЕНИЕ не получено, можно видеть РАЗЪЕДИНЕНИЕ или RELEASE_COMP (завершенный выпуск) сообщение, придерживавшееся кодом причины:

      *Mar 20 22:11:03.212: ISDN SE0:23: 
      RX <-RELEASE_COMP pd = 8 callref = 0x8F
      *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
      

      Оценка причины указывает на две вещи:

      • Второй байт 4-или 6 значений в байтах указывает на точку в пути сквозного вызова, от которого были получены РАЗЪЕДИНЕНИЕ или RELEASE_COMP. Это может помочь вам локализовать проблему.

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

    • Возможность 2: удаленный модем не отвечает. Протестируйте это путем набора номера удаленного модема с обычным телефоном. Попробуйте это:

      1. Гарантируйте, что номер вызываемого телефона корректен. Используйте телефон для вызова номера получения.

      2. Гарантируйте, что вызов в ручном режиме в состоянии достигнуть асинхронного модема ответа. Если вызов в ручном режиме в состоянии достигнуть асинхронного модема ответа, линия BRI не может быть настроена для разрешения исходящих голосовых вызовов.

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

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

      5. Если это - междугородний звонок, имейте попытку вызывающей стороны другой (известная польза) номер для междугороднего звонка. Если это работает, средство получения или линия не могут быть настроены для получения междугородних звонков. Если инициирующее (BRI), линия не может достигнуть никаких других номеров для междугороднего звонка, ей нельзя было включить большое расстояние. Попробуйте 1010 кодов за другие компании для дальней связи.

      6. Наконец, попробуйте другого (известная польза) локальный номер от инициирующей линии BRI. Если связь все еще прерывается, имейте проверку telco (телефонная компания) BRI.

    • Возможность 3: набранный номер является неправильным. Проверьте номер, набрав его вручную. Исправьте конфигурацию, при необходимости.

    • Возможность 4: пробное подключение модема занимает слишком много времени, или ЗНАЧЕНИЕ ТАЙМАУТА слишком низко. Попытайтесь увеличить ЗНАЧЕНИЕ ТАЙМАУТА в команде chat-script. Если ТАЙМАУТ уже является 60 секундами или больше, может быть проблема с кабелем между модемом и DTE, к которому это присоединено. Сбои пробного включения могут также указать на проблему с каналом или несовместимость модема.

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

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

  5. Если все хорошо работает, и вы все еще не можете соединиться на своем DDR асинхронного модема BRI, попробовать Отладку PPP. Если сценарий диалогового взаимодействия завершает успешно, и отладки PPP указывают на сбой, консультируются с Разделом "Устранение проблем PPP" в Главе 17 Межсетевого Руководства по поиску и устранению проблем.

DDR модем c асинхронным интерфейсом BRI

Эта функция только работает на платформу Cisco 3640 с помощью программного обеспечения Cisco IOS версии 12.0(3)T или позже. Это требует более поздней проверки оборудования сетевого модуля BRI. Это не будет работать с Интерфейсной картой WAN (WIC).

  1. Гарантируйте, что код страны корректен с командой show modem. Используйте следующие команды, затем попытайтесь позвонить:

    warning % Warning:  Выполнение отладок на занятой системе могло завершиться катастрофическим отказом маршрутизатор путем перегрузки ЦП или переполнения буфера консоли!

    router# debug modem
    router# debug chat
    router# debug modem csm
    router# debug isdn q931
    router# debug bri
    router# debug ppp negotiate
    router# debug ppp authenticate
    
  2. Для модемных вызовов сценарий диалогового взаимодействия должен выполниться для вызова продолжиться. Для номеронабирателя на основе схемы DDR, сценарий диалогового взаимодействия вызван параметром сценария модема в команде cхемы набора номеров. Если DDR основан на профиле DDR, это выполнено номеронабирателем командного сценария, настроенным на линии TTY. Оба использования полагается на сценарий диалогового взаимодействия, существующий в глобальной конфигурации маршрутизатора, такой как:

    chat-script callout AT OK atdt\T TIMEOUT 60 CONNECT \c
    

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

    CHAT1: Attempting async line dialer script
    
    CHAT1: Dialing using Modem script: callout & System script: none
    CHAT1: process started
    CHAT1: Asserting DTR
    CHAT1: Chat script callout started
    CHAT1: Sending string: AT
    CHAT1: Expecting string: OK
    CHAT1: Completed match for expect: OK
    CHAT1: Sending string: atdt5551212
    CHAT1: Expecting string: CONNECT
    CHAT1: Completed match for expect: CONNECT
    CHAT1: Chat script callout finished, status = Success
    
  3. Гарантируйте, что сценарий диалогового взаимодействия делает попытку ожидаемого вызова (верный номер) на основе "Передачи строки". Если сценарий диалогового взаимодействия не пытается сделать ожидаемый вызов, проверьте конфигурацию сценария диалогового взаимодействия. Используйте команду start-chat в подсказке командной строки для инициирования сценария диалогового взаимодействия вручную.

  4. Наблюдение "Таймаута, ожидающего: ПОДКЛЮЧЕНИЕ" может описать несколько других возможностей:

    • Возможность 1: локальный модем фактически не размещает вызов. Проверьте, что модем может заказать телефонный разговор путем выполнения обратного доступа по протоколу Telnet к модему и вручную инициирования набора. Если удаленный конец, кажется, не отвечает, не проверяет, что вызов размещается модемом путем вызова локального номера вручную с <number> команды ATDT и прислушивания к вызову. Если никакой вызов не выходит, включите отладки ISDN. На первое подозрение в сбое ISDN на BRI всегда проверяйте выходные данные от статуса show isdn. Ключевые вещи обратить внимание состоят в том, что Уровень 1 должен быть Активным , и Уровень 2 должен быть в состоянии MULTIPLE_FRAME_ESTABLISHED . См. Межсетевого Главу Руководства по поиску и устранению проблем 16, "Интерпретацию команды show isdn status" для получения информации о чтении этих выходных данных и корректирующих показателей.

      Для исходящих вызовов ISDN debug isdn q931 и debug isdn event являются лучшими программными средствами для использования. К счастью, отладка исходящих вызовов подобно отладке входящих вызовов. Обычный успешный вызов мог бы быть похожим на это:

      *Mar 20 21:07:45.025: ISDN BR0: Event: 
      Call to 5553759 at 64 Kb/s
      
      *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  
      callref = 0x2C
      *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
      *Mar 20 21:07:45.041:         Channel ID i = 0x83
      *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
      *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  
      callref = 0xAC
      *Mar 20 21:07:45.145:         Channel ID i = 0x89
      *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
              Channel ID i = 0x0101
      *Mar 20 21:07:45.161:   -------------------
              Channel ID i = 0x89
      *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  
      callref = 0xAC
      *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
      

      Обратите внимание на то, что сообщение CONNECT является Индикатором успеха. Если ПОДКЛЮЧЕНИЕ не получено, можно видеть РАЗЪЕДИНЕНИЕ или RELEASE_COMP (завершенный выпуск) сообщение, придерживавшееся кодом причины:

      *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
      callref = 0x8F
      *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected 
      

      Оценка причины указывает на две вещи.

      • Второй байт 4-или 6 значений в байтах указывает на точку в пути сквозного вызова, от которого были получены РАЗЪЕДИНЕНИЕ или RELEASE_COMP. Это может помочь вам локализовать проблему.

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

    • Возможность 2: удаленный модем не отвечает. Протестируйте это путем набора номера удаленного модема с обычным телефоном. Попробуйте это:

      1. Гарантируйте, что номер вызываемого телефона корректен. Используйте телефон для вызова номера получения.

      2. Гарантируйте, что вызов в ручном режиме в состоянии достигнуть асинхронного модема ответа. Если вызов в ручном режиме в состоянии достигнуть асинхронного модема ответа, линия BRI не может быть настроена для разрешения исходящих голосовых вызовов.

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

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

      5. Если это - междугородний звонок, имейте попытку вызывающей стороны другой (известная польза) номер для междугороднего звонка. Если это работает, средство получения или линия не могут быть настроены для получения междугородних звонков. Если инициирующее (BRI), линия не может достигнуть никаких других номеров для междугороднего звонка, ей нельзя было включить большое расстояние. Попробуйте 10-10 кодов за другие компании для дальней связи.

      6. Наконец, попробуйте другого (известная польза) локальный номер от инициирующей линии BRI. Если связь все еще прерывается, имейте проверку telco (телефонная компания) BRI.

    • Возможность 3: набранный номер является неправильным. Проверьте номер, набрав его вручную. Исправьте конфигурацию, при необходимости.

    • Возможность 4: пробное подключение модема занимает слишком много времени, или ЗНАЧЕНИЕ ТАЙМАУТА слишком низко. Попытайтесь увеличить ЗНАЧЕНИЕ ТАЙМАУТА в команде chat-script. Если ТАЙМАУТ уже является 60 секундами или больше, может быть проблема с кабелем между модемом и DTE, к которому это присоединено. Сбои пробного включения могут также указать на проблему с каналом или несовместимость модема.

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

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

  5. Если все хорошо работает, и вы все еще не можете соединиться на своем DDR асинхронного модема BRI, попробовать Отладку PPP. Если сценарий диалогового взаимодействия завершает успешно, и отладки PPP указывают на сбой, консультируются с Разделом "Устранение проблем PPP" в Главе 17 Межсетевого Руководства по поиску и устранению проблем.

PRI ISDN DDR

  1. На первое подозрение в сбое ISDN на PRI всегда проверяйте выходные данные от статуса show isdn. Ключевые вещи обратить внимание состоят в том, что Уровень 1 должен быть Активным, и Уровень 2 должен быть в состоянии MULTIPLE_FRAME_ESTABLISHED. См. Межсетевого Главу Руководства по поиску и устранению проблем 16, "Интерпретацию команды show isdn status" для получения информации о чтении этих выходных данных и корректирующих показателей.

    Для исходящих вызовов ISDN debug isdn q931 и debug isdn event являются лучшими программными средствами для использования. К счастью, отладка исходящих вызовов подобно отладке входящих вызовов. Обычный успешный вызов мог бы быть похожим на это:

    *Mar 20 21:07:45.025: ISDN SE0:23: Event: 
    Call to 5553759 at 64 Kb/s
    
    *Mar 20 21:07:45.033: ISDN SE0:23: TX ->  SETUP pd = 8  
    callref = 0x2C
    *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
    *Mar 20 21:07:45.041:         Channel ID i = 0x83
    *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
    *Mar 20 21:07:45.141: ISDN SE0:23: RX <-  CALL_PROC pd = 8  
    callref = 0xAC
    *Mar 20 21:07:45.145:         Channel ID i = 0x89
    *Mar 20 21:07:45.157: ISDN SE0:23: received HOST_PROCEEDING
            Channel ID i = 0x0101
    *Mar 20 21:07:45.161:   -------------------
            Channel ID i = 0x89
    *Mar 20 21:07:45.313: ISDN SE0:23: RX <-  CONNECT pd = 8  
    callref = 0xAC
    *Mar 20 21:07:45.325: ISDN SE0:23: received HOST_CONNECT
    

    Обратите внимание на то, что сообщение CONNECT является Индикатором успеха. Если ПОДКЛЮЧЕНИЕ не получено, можно видеть РАЗЪЕДИНЕНИЕ или RELEASE_COMP (завершенный выпуск) сообщение, придерживавшееся кодом причины:

    *Mar 20 22:11:03.212: ISDN SE0:23: RX <-  RELEASE_COMP pd = 8  
    callref = 0x8F
    *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
    

    Оценка причины указывает на две вещи.

    • Второй байт 4-или 6 значений в байтах указывает на точку в пути сквозного вызова, от которого были получены РАЗЪЕДИНЕНИЕ или RELEASE_COMP. Это может помочь вам локализовать проблему.

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

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

    Cause i = 0x8090 - Normal call clearing

    Сбой проверки подлинности PPP является типичной причиной. Включите debug ppp negotiation и debug ppp authenticaion прежде, чем предположить, что ошибка подключения является обязательно проблемой ISDN.

  2. Если сообщение ISDN CONNECT замечено, и отладки PPP указывают на сбой, консультируются с Разделом "Устранение проблем PPP" в Главе 17 Межсетевого Руководства по поиску и устранению проблем.

BRI ISDN DDR

  1. На первое подозрение в сбое ISDN на BRI всегда проверяйте выходные данные от статуса show isdn. Ключевые вещи обратить внимание состоят в том, что Уровень 1 должен быть Активным, и Уровень 2 должен быть в состоянии MULTIPLE_FRAME_ESTABLISHED. См. Межсетевого Главу Руководства по поиску и устранению проблем 16, "Интерпретацию команды show isdn status" для получения информации о чтении этих выходных данных и корректирующих показателей.

    Для исходящих вызовов ISDN debug isdn q931 и debug isdn event являются лучшими программными средствами для использования. К счастью, отладка исходящих вызовов подобно отладке входящих вызовов. Обычный успешный вызов мог бы быть похожим на это:

    *Mar 20 21:07:45.025: ISDN BR0: Event: Call to 5553759 at 64 Kb/s
    
    *Mar 20 21:07:45.033: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x2C
    *Mar 20 21:07:45.037:         Bearer Capability i = 0x8890
    *Mar 20 21:07:45.041:         Channel ID i = 0x83
    *Mar 20 21:07:45.041:         Keypad Facility i = 0x35353533373539
    *Mar 20 21:07:45.141: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0xAC
    *Mar 20 21:07:45.145:         Channel ID i = 0x89
    *Mar 20 21:07:45.157: ISDN BR0: received HOST_PROCEEDING
            Channel ID i = 0x0101
    *Mar 20 21:07:45.161:   -------------------
            Channel ID i = 0x89
    *Mar 20 21:07:45.313: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0xAC
    *Mar 20 21:07:45.325: ISDN BR0: received HOST_CONNECT
    

    Обратите внимание на то, что сообщение CONNECT является Индикатором успеха. Если ПОДКЛЮЧЕНИЕ не получено, можно видеть РАЗЪЕДИНЕНИЕ или RELEASE_COMP (завершенный выпуск) сообщение, придерживавшееся кодом причины:

    *Mar 20 22:11:03.212: ISDN BR0: RX <-  RELEASE_COMP pd = 8  
    callref = 0x8F
    *Mar 20 22:11:03.216:         Cause i = 0x8295 - Call rejected
    

    Оценка причины указывает на две вещи.

    • Второй байт 4-или 6 значений в байтах указывает на точку в пути сквозного вызова, от которого были получены РАЗЪЕДИНЕНИЕ или RELEASE_COMP. Это может помочь вам локализовать проблему.

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

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

      Cause i = 0x8090 - Normal call clearing

      Сбой проверки подлинности PPP является типичной причиной. Включите debug ppp negotiation и debug ppp authenticaion прежде, чем предположить, что ошибка подключения является обязательно проблемой ISDN.

  2. Если сообщение ISDN CONNECT замечено, и отладки PPP указывают на сбой, консультируются с Разделом "Устранение проблем PPP" в Главе 17 Межсетевого Руководства по поиску и устранению проблем.


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


Document ID: 14954