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

Устранение проблем ISDN BRI уровня 3 при помощи команды debug isdn q931

14 мая 2010 - Перевод, выполненный профессиональным переводчиком
Другие версии: PDF-версия:pdf | Машинный перевод (13 сентября 2013) | Английский (4 февраля 2010) | Отзыв

Содержание

Введение
Предварительные условия
      Требования
      Используемые компоненты
      Conventions
Предварительные условия для устранения неполадок: активация отладки ISDN на 3-м уровне
      Инициирование вызова ISDN
Общий принцип устранения неполадок. Признаки и порядок действий.
Устранение неполадок. Описание признаков и подробный порядок действий.
      Вызывающий маршрутизатор не отправляет сообщение SETUP
      Вызываемый маршрутизатор не получает сообщение SETUP
      Вызываемый маршрутизатор не получает сообщение CONNECT
      Вызывающий маршрутизатор не получает сообщение CONNECT
      Вызывающий маршрутизатор получает сообщение CONNECT, но вызов по-прежнему не проходит
Связанные обсуждения сообщества поддержки Cisco
Дополнительные сведения

Введение

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

  • маршрут с соединением по требованию;

  • ISDN уровней 1, 2 и 3;

  • протокол "точка-точка" (PPP), в т.ч. проблемы, связанные с протоколом управления каналом (LCP), аутентификацией или протоколом управления IP (IPCP).

В этом документе внимание акцентируется на проблемах с ISDN, которые являются причиной сбоев вызовов. Этот документ также предполагает, что проверена работоспособность уровней 1 и 2 ISDN на обоих концах цепи. Подробная процедура проверки состояния ISDN на 1-м и 2-м уровнях изложена в разделе Использование команды show isdn status для диагностики неполадок BRI.

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

Требования

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

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

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

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

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

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

Предварительные условия для устранения неполадок. Активация отладки ISDN на 3-м уровне

Для активации отладки на 3-м уровне с обеих сторон ISDN-соединения необходимо выполнить команду debug isdn q931. При включенной отладке на обоих маршрутизаторах следует иметь штамп времени (миллисекунды). Временные метки нужны для анализа относительной последовательности событий в процессе поиска неполадок.

Note: Активируйте для отладки миллисекундные метки времени, используя следующие команды:

maui-soho-01(config)#service timestamps debug datetime msec
maui-soho-01(config)#service timestamps log datetime msec

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

Инициирование вызова ISDN

Отправьте эхозапрос ICMP на IP-адрес удаленного маршрутизатора. Это должно инициировать вызов ISDN на этот маршрутизатор. Оба маршрутизатора сгенерируют отладочные сообщения debug isdn q931.

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

/image/gif/paws/9495/isdn_q931_ts_1.gif

Примечание. Некоторые из приведенных далее строк протокола отладки разбиты на несколько строк для удобства печати.

Вызывающий маршрутизатор

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

maui-soho-01#
18:39:29.425: ISDN BR0: TX -> SETUP
    pd = 8  callref = 0x10

!-- The Calling Router Transmits
!-- (indicated by TX) the SETUP message

18:39:29.433:
         Bearer Capability i = 0x8890
18:39:29.441: Channel ID i = 0x83
18:39:29.449:
         Keypad Facility i = '5558888'
18:39:29.822: ISDN BR0: RX <- CALL_PROC
    pd = 8  callref = 0x90

!-- The telco switch responds with a
!-- Call Proceeding. This indicates the 
!-- network is processing the call.

18:39:29.830:
         Channel ID i = 0x89
.
.
.

!-- Nothing has been omitted here. The
!-- dots were put in place to align
!-- the Called and Calling Routers.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18:39:30.000: ISDN BR0: RX <- CONNECT
    pd = 8  callref = 0x90

!-- Received a CONNECT from the remote 
!-- router. The ISDN connection has been
!-- established. Any failures of the call
!-- past this point are due to higher
!-- level issues such as DDR, PPP, 
!-- Authentication, IPCP/IP Addressing

18:39:30.036: ISDN BR0: TX -> CONNECT_ACK
    pd = 8  callref = 0x10

!--- The Router responds with a Connect
!--- Acknowledgment (CONNECT_ACK) 
!--- to the telco.

maui-nas-08#
18:39:29.647: ISDN BR2/0: RX <- SETUP
    pd = 8  callref = 0x08

!-- The Called Router receives
!-- (indicated by RX) a SETUP message 
!-- from the switch

18:39:29.647:
    Bearer Capability i = 0x8890

!-- The incoming call is 64k Digital. 

18:39:29.647: Channel ID i = 0x89
18:39:29.647:
    Signal i = 0x40 - Alerting on -
    pattern 0 
18:39:29.647:
    Called Party Number i = 0xC1,'5558888',
    Plan:ISDN, Type:Subscriber(local)
18:39:29.647:
    Locking Shift to Codeset 5
18:39:29.647:
    Codeset 5 IE 0x2A  
    i = 0x808001038001118001, '<'
18:39:29.651:
    ISDN BR2/0: Event: Received a DATA 
    call from  on B1 at 64 Kb/s
18:39:29.651: ISDN BR2/0: TX -> CALL_PROC
    pd = 8  callref = 0x88

!--- Router transmits a Call Proceeding
 
18:39:29.655:
         Channel ID i = 0x89
18:39:29.655: %LINK-3-UPDOWN:
 Interface BRI2/0:1, changed state to up
18:39:29.955: ISDN BR2/0: TX -> CONNECT
    pd = 8  callref = 0x88

!--- Call is accepted and the routers sends
!--- a CONNECT message to the remote end

18:39:29.955:  Channel ID i = 0x89
18:39:29.995: ISDN BR2/0: RX <- CONNECT_ACK
    pd = 8  callref = 0x08

!--- Called device receives a CONNECT_ACK
!--- from the switch

18:39:29.995:
         Channel ID i = 0x89
18:39:29.995:
         Signal i = 0x4F - Alerting off 
18:39:35.655: %ISDN-6-CONNECT:
 Interface BRI2/0:1 is now
 connected to unknown 

При анализе выходных данных команды debug isdn q931 на вызывающей и вызываемой сторонах следует иметь в виду следующее.

  • Обращайте внимание на направление сообщений. В отладочных сообщениях указано, созданы ли они этим маршрутизатором (это обозначается «TX ->») или получены маршрутизатором (это обозначается «RX ->»). В следующем примере первое сообщение (CONNECT) принято маршрутизатором от коммутатора ISDN, тогда как второе сообщение (CONNECT_ACK) отправлено маршрутизатором:

    18:39:30.000: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x90
    18:39:30.036: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x10
    
    

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

  • Убедитесь, что полученное или отправленное сообщение является ожидаемым. Например, если вызываемая сторона получает сообщение SETUP, однако в ответ оправляет DISCONNECT вместо CONNECT, причину следует искать на стороне вызывающего маршрутизатора, а не сети ISDN. В следующей таблице перечислены сообщения Q.931, которые могут появляться при установлении и разрыве соединения.

Сообщение

Описание

SETUP

Подготовка. Показывает, что устройство собирается установить соединение на 3-м уровне.

CALL_PROC

Выполняется вызов. Сообщение SETUP получено и обрабатывается сетью и/или удаленным устройством.

ALERTING

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

CONNECT

Соединение. Вызов принят.

CONNECT_ACK

Подтверждение соединения. Устройство получило сообщение CONNECT. Высокоуровневый протокол (например, PPP) теперь должен начать согласование.

DISCONNECT

Разъединение. Маршрутизатор инициировал сообщение разъединения. Обычно это сообщение показывает, что сеть ISDN функционирует и разъединение произошло в результате проблем какого-то более высокого уровня (DDR, PPP и так далее). 3-стороннее согласование разъединения сопровождается сообщениями RELEASE и RELEASE_COMP.

Сообщение DISCONNECT может также сопровождаться кодом причины разъединения (Disconnect Cause Code). Код разъединения можно использовать для нахождения места разъединения вызова (например, вызов был разъединен на маршрутизаторе, на локальном или удаленном коммутаторе телефонной компании, и т.д.). Дополнительные сведения см. в документе Описание кодов причин разъединения для команды «debug isdn q931»

RELEASE

Освобождение. Подтверждение сообщения DISCONNECT и продолжение разрыва цепи. Сообщение RELEASE помещается между сообщениями DISCONNECT и RELEASE_COMP.

Сообщение RELEASE может сопровождаться кодом причины разъединения. Код разъединения можно также использовать для нахождения места разъединения вызова (например, вызов был разъединен на маршрутизаторе, на локальном или удаленном коммутаторе телефонной компании). Дополнительные сведения см. в документе Описание кодов причин разъединения для команды debug isdn q931.

RELEASE_COMP

Освобождение завершено. Цепь разорвана. Обычно это сообщение возникает:

а) во время стандартной отмены вызова, инициированной одним из маршрутизаторов;

б) в ответ на сообщение SETUP от маршрутизатора, осуществляющего вызов. Оно часто вызывается несогласованностью пропускной способности однонаправленного канала между коммутатором и маршрутизатором. Сообщение RELEASE_COMP также может возникнуть из-за ошибок протокола, если код сообщения SETUP несовместим со стандартом Q.931 или с конфигурацией коммутатора.

Сообщение RELEASE_COMP может сопровождаться кодом причины разъединения. Код разъединения можно также использовать для нахождения места разъединения вызова (например, вызов был разъединен на маршрутизаторе, на локальном или удаленном коммутаторе телефонной компании). Дополнительные сведения см. в документе Описание кодов причин разъединения для команды debug isdn q931.

Общий принцип устранения неполадок. Признаки и порядок действий

Проанализируйте выходные данные отладочной команды debug isdn q931, как описано в предыдущих разделах, и перейдите к описанию одного из следующих признаков, приведенных ниже.

Примечание.  В этом документе, маршрутизатор, инициирующий вызов, именуется вызывающим маршрутизатором, а маршрутизатор, отвечающий на вызов, именуется вызываемым маршрутизатором.

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

Вызывающий маршрутизатор не отправляет сообщение SETUP

/image/gif/paws/9495/isdn_q931_ts_table1.GIF

Если маршрутизатор вызова не отправил сообщение SETUP в сеть ISDN, то проблема, скорее всего, связана с уровнями ISDN 1, 2 либо с неполадками маршрутизации с соединением по запросу (DDR), а не с уровнем 3.

Выполните следующие задачи на вызывающем маршрутизаторе.

  • Проверьте, правильно ли настроен тип коммутации ISDN.

    Тип коммутации для ISDN можно проверить с помощью команды show isdn status. Телефонная компания должна четко указать тип коммутатора, который нужно настроить. В некоторых случаях (особенно в Северной Америке) телефонная компания может указать тип коммутатора Custom (специальный) или National (национальный). В таких случаях для определения конфигурации типа коммутатора используйте следующие правила.

    • Специальный коммутатор. Если телефонная компания указывает, что значение switch-type равно Custom, то задайте значение switchtype маршрутизатора равное basic-5ess (для BRI с коммутатором 5ess), primary-5ess (для PRI с 5ess), basic-dms (для BRI с коммутатором DMS) или primary-dms (для PRI с DMS).

    • Национальный коммутатор. Соответствие типа коммутатора стандарту NI-1 для BRI и стандарту NI-2 для PRI (стандарта NI-1 для PRI не существует). Если телефонная компания сообщает, что тип коммутатора "Национальный", то конфигурация маршрутизатора Cisco должна быть "basic-ni" (для BRI) или "primary-ni" (для PRI).

    Чтобы настроить тип коммутатора, воспользуйтесь командой isdn switch-type тип-коммутатора в режиме настройки интерфейса BRI. Пример см. в документе Устранение неполадок интерфейса ISDN BRI на 1-м уровне.

  • Проверьте функционирование уровней 1 и 2 ISDN на вызывающем маршрутизаторе.

    Можно проверить работоспособность уровней ISDN 1 и 2 по команде show isdns status. Используйте процедуру, описанную в разделах устранения неполадок для ISDN уровней 1 и 2.

  • При помощи команды show ip route убедитесь в наличии у маршрутизатора маршрута к месту назначения.

    Команда show ip route укажет, есть ли маршрут к удаленной сети маршрутизатора. Если маршрут не существует, добавьте статический маршрут к удаленной сети командой ip route. Убедитесь, что маршрут указывает на правильный интерфейс вызывающего маршрутизатора.

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

    При наличии профилей номеронабирателя следующим узлом обычно является интерфейс Dialer x, используемый для внешнего телефонного соединения. Например,

    maui-soho-01#show ip route
    ...
    ...
    !-- Output omitted
    
    ...
    
         10.0.0.0/24 is subnetted, 1 subnets
    C       10.0.0.0 is directly connected, Ethernet0
    S*   0.0.0.0/0 is directly connected, Dialer1
    

    Обратите внимание, что в приведенном выше примере следующим узлом маршрута по умолчанию является интерфейс Dialer 1 (логический интерфейс номеронабирателя для этого подключения).

  • Проверьте, правильно ли идентифицирован содержательный трафик.

    Перед началом вызова маршрутизатор проверяет наличие в пакете содержательного трафика. Таким образом, маршрутизатор может не начать набор номера, если представляющий значимость трафик определен неверно либо если условие dialer-list номер (определение трафика, представляющего значимость) не применено к физическому интерфейсу или интерфейсу номеронабирателя (посредством команды dialer-group номер). Например, если для определения подключения DDR используется эхозапрос ICMP, убедитесь, что ICMP разрешен в определении представляющего значимость трафика.

    Дополнительные сведения см. в документе Настройка коммутируемой телефонной связи BRI-BRI со схемами набора номера DDR (маршрутизация вызовов по запросу).

  • Убедитесь в том, что соответствующая строка номеронабирателя (или схема номеронабирателя) включает номер ISDN удаленного устройства.

    Строка (или схема) номеронабирателя должна содержать номер ISDN удаленного маршрутизатора. Например,

    dialer string 5551111
    or
    dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
    
  • Проверьте конфигурацию DDR и при помощи команды «debug dialer» убедитесь в том, что маршрутизатор инициирует вызов.

    Убедитесь, что настройки DDR верны. За дополнительной информацией о надлежащем порядке настройки DDR обратитесь к документу «Технология коммутируемой связи. Обзор и пояснения».

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

    См. следующие примеры правильной конфигурации DDR:

    Профили номеронабирателя: Настройка ISDN DDR с использованием профилей номеронабирателя Старая схема DDR (таблицы номеронабирателя): Настройка коммутируемой телефонной связи между двумя интерфейсами BRI при помощи схем номеронабирателя DDR.

    Совет. Для проверки можно отменить DDR командой isdn call (пояснение см. в следующем разделе), чтобы сгенерировать вызов ISDN на удаленное устройство. Если этот вызов будет выполнен успешно, то с большой долей уверенности можно считать, что цепь ISDN исправна. Продолжайте устранение неполадок DDR.

  • Выполните проверочный кольцевой вызов.

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

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

    Ниже приведен снабженный комментариями пример проверочного кольцевого вызова. Команда isdn call (введенная в программном обеспечении IOS Cisco версии 12.0(3)T) разрешает исходящие вызовы ISDN, не требуя обязательных параметров DDR, таких как определение представляющего значимость трафика и маршрутов. Данная команда может использоваться только для тестирования канала ISDN и не может использоваться для пересылки трафика или в качестве подстановки для допустимой конфигурации DDR. Эта команда позволяет убедиться, что сеть ISDN, а в особенности уровень 3, работает.

maui-soho-04#isdn call interface bri 0 5551111

!--- the router will dial 5551111 (the ISDN number of the router's own BRI)

maui-soho-04#
*Mar  1 17:55:08.344: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x09

!--- Q931 Setup message is Transmitted (TX) to the telco switch

*Mar  1 17:55:08.360:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.360:         Channel ID i = 0x83
*Mar  1 17:55:08.364:         Keypad Facility i = '5551111'
*Mar  1 17:55:08.484: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x89

!--- Call Proceeding message is Received (RX) from the telco switch.
!--- The switch is now processing the call.

*Mar  1 17:55:08.488:         Channel ID i = 0x89
*Mar  1 17:55:08.516: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x12

!--- A Setup message is Received (RX) from the switch. This message is for the 
!--- incoming call. Remember that the router sent a Setup message (for the
!--- outgoing call) and now receives a SETUP message for the same call

*Mar  1 17:55:08.516:         Bearer Capability i = 0x8890
*Mar  1 17:55:08.520:         Channel ID i = 0x8A
*Mar  1 17:55:08.520:         Signal i = 0x40 - Alerting on - pattern 0 
*Mar  1 17:55:08.532:         Called Party Number i = 0xC1, '5551111'
*Mar  1 17:55:08.532:         Locking Shift to Codeset 5
*Mar  1 17:55:08.532:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
*Mar  1 17:55:08.564: ISDN BR0: Event: 
Received a DATA call from  on B2 at 64 Kb/s
*Mar  1 17:55:08.620: %DIALER-6-BIND: Interface BRI0:2 bound to profile Dialer1
*Mar  1 17:55:08.652: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0x92

! --- Transmit (TX) a Call Proceeding message for the incoming call

*Mar  1 17:55:08.652:         Channel ID i = 0x8A
*Mar  1 17:55:08.700: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
*Mar  1 17:55:08.988: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0x92

! --- Transmit (TX) a Connect message for the incoming call

*Mar  1 17:55:08.988:         Channel ID i = 0x8A
*Mar  1 17:55:09.040: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x12

! --- Receive (RX) a Connect Acknowledgment for the incoming call

*Mar  1 17:55:09.040:         Channel ID i = 0x8A
*Mar  1 17:55:09.040:         Signal i = 0x4F - Alerting off 
*Mar  1 17:55:09.064: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x89

! --- Receive (RX) a Connect for the outgoing call

*Mar  1 17:55:09.076: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x09
*Mar  1 17:55:09.080: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  1 17:55:09.104: %DIALER-6-BIND: Interface BRI0:1 bound to profile BRI0
*Mar  1 17:55:09.112: %ISDN-6-CONNECT: 
Interface BRI0:1 is now connected to 5551111 

! ---  Call is now connected. Loopback call is successful

Примечания.

  • Во время проверочного вызова маршрутизатор выступает в роли одновременно вызываемого и вызывающего маршрутизатора (хотя и на разных B-каналах). Важно отслеживать эти «двойные роли» при интерпретации выходных данных команды debug isdn q931. Например, маршрутизатор передает сообщение настройки (TX -> SETUP) и принимает такое же сообщение (RX <- SETUP). Переданное сообщение SETUP должно связываться с исходящим вызовом, а полученное сообщение SETUP – с входящим вызовом.

  • В приведенном выше примере был набран номер для первого B-канала. Однако поставщик услуг телефонной связи, определив, что первый B-канал занят (поскольку он делал вызов), переключил вызов на второй B-канал, и соединение было выполнено успешно. Однако неверная настройка коммутатора телефонной компании может привести к отказу проверочного кольцевого вызова из-за того, что коммутатор предпримет попытку назначить вызов на первый канал (который занят исходящим вызовом). Телефонная компания должна исправить эту проблему. В качестве временного решения в этом случае можно указать в команде isdn call номер второго B-канала.

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

Вызываемый маршрутизатор не получает сообщение SETUP

/image/gif/paws/9495/isdn_q931_ts_table2.GIF

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

Выполните следующие задачи на вызываемом маршрутизаторе.

  • Проверьте, правильно ли настроен тип коммутации ISDN.

    Тип коммутации для ISDN можно проверить с помощью команды show isdn status. Телефонная компания должна четко указать тип коммутатора, который нужно настроить. В некоторых случаях (особенно в Северной Америке) телефонная компания может указать тип коммутатора Custom (специальный) или National (национальный). В таких случаях для определения конфигурации типа коммутатора используйте следующие правила.

    • Специальный коммутатор. Если телефонная компания указывает, что значение switch-type равно Custom, то задайте значение switchtype маршрутизатора равное basic-5ess (для BRI с коммутатором 5ess), primary-5ess (для PRI с 5ess), basic-dms (для BRI с коммутатором DMS) или primary-dms (для PRI с DMS).

    • Национальный коммутатор. Соответствие типа коммутатора стандарту NI-1 для BRI и стандарту NI-2 для PRI (стандарта NI-1 для PRI не существует). Если телефонная компания сообщает, что тип коммутатора "Национальный", то конфигурация маршрутизатора Cisco должна быть "basic-ni" (для BRI) или "primary-ni" (для PRI).

    Чтобы настроить тип коммутации, используйте команду isdn switch-type тип коммутации в режиме конфигурации интерфейса BRI. Пример см. в документе Устранение неполадок интерфейса ISDN BRI на 1-м уровне.

  • Проверьте функционирование уровней 1 и 2 ISDN на вызывающем маршрутизаторе.

    Можно проверить работоспособность уровней ISDN 1 и 2 по команде show isdns status. Для устранения проблем BRI, связанных с уровнями 1 и 2 ISDN используйте процедуру, описанную в разделе Использование команды show isdn status для устранения неполадок с интерфейсом BRI.

  • Проверьте, правильно ли настроен локальный номер каталога SPID (LDN).

    Некоторые типы коммутаторов для приема входящих вызовов требуют правильной настройки параметров spid и ldn. Дополнительные сведения см. в разделе «Устранение неполадок, связанных с идентификаторами ISDN BRI SPID».

Выполните следующие задачи на вызывающем маршрутизаторе.

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

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

  • Убедитесь, что номер ISDN получателя задан правильно.

    Проверьте конфигурацию вызывающего маршрутизатора и убедитесь, что номер ISDN, заданный для удаленного маршрутизатора, верен. Очень часто цепи ISDN после АТС требуют перед номером ISDN набирать 9. Кроме того, если вызов является междугородным (в США), то перед номером ISDN удаленной стороны следует набирать 1 (по аналогии с обычным вызовом по междугородной телефонной связи). Например, рассмотрим ситуацию, когда локальный объект находится за пределами PBX, и для вызова удаленного сайта необходимо выполнить междугородний вызов. Номер ISDN удаленной стороны – 5551111 в коде города 512. В этом случае, с учетом соответствующих цифр для АТС и междугородной телефонной связи, набираемый номер должен выглядеть как 915125551111.

    Причина разъединения debug isdn q931 также позволяет определить, обусловлен ли сбой вызова неверно набранным номером ISDN удаленной стороны или ненадлежащим форматом номера. Более подробные сведения о способе интерпретации кодов причин разъединения ISDN q931 см. в документе Описание кодов причин разъединения для команды debug isdn q931.

    Отключение из-за неверного номера ISDN может сопровождаться сообщением:

    Aug 13 18:20:01.100: ISDN BR0: RX <-  DISCONNECT pd = 8  callref = 0x85
    Aug 13 18:20:01.112: Cause i = 0x81D8 - Incompatible destination
    

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

    Отключение вследствие неправильного формата номера может быть указано с помощью:

    Aug 13 18:23:14.734: ISDN BR0: RX <-  RELEASE_COMP pd = 8  callref = 0x86
    Aug 13 18:23:14.742: Cause i = 0x829C - Invalid number format 
    (incomplete number)
    

    Руководствуясь документом Описание кодов причин разъединения для команды debug isdn q931, мы можем определить, что код разъединения вызван неверным форматом удаленного номера ISDN. Подключение не удалось, так как адрес назначения подан (на коммутатор) в нераспознаваемом формате или адрес назначения неполон.

  • По возможности определите, активна ли служба междугородной связи.

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

    При связи абонент-оператор и в ситуациях, где телефонная компания или удаленный поставщик не может исправить проблему, можно использовать PIC. Коды PIC представляют собой префиксы из 7 цифр, которые определяют операторов междугородней и международной связи США для местных операторов телефонных сетей (LEC). Благодаря этому клиенты могут использовать разных поставщиков услуг дальней связи для различных звонков. Код PIC настраивается в качестве префикса набираемого номера. Большинство кодов PIC имеют формат 1010xxx. Список PIC см. на странице Коды PIC в США (в числовом порядке) /images/exit.gif

  • Настройте две таблицы номеронабирателя или два строковых оператора номеронабирателя – по отдельности для каждого номера ISDN удаленного В-канала.

    Настройка таблицы номеронабирателя (или строки номеронабирателя – в случае использования профилей номеронабирателя) для каждого удаленного В-канала позволяет выполнять соединение даже в том случае, если телефонная компания не может коммутировать второй вызов на второй В-канал ISDN.

    Примечание. Это временное решение требуется только в том случае, если на данном интерфейсе BR1 принимает вызовы только 1 B-канал. Данная проблема часто возникает в многоканальных подключениях.

    Образец конфигурации (с использованием таблиц номеронабирателя):

    dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551111
    dialer map ip 172.20.10.1 name maui-nas-05 broadcast 5551112
    
    !--- dialer map statements for the remote router 
    !--- The two different phone numbers correspond
    !--- to the b-channels of the remote side. The multiple statements allow
    !--- the router to dial the second number if the first number is busy. 
    
    

Вызываемый маршрутизатор не отправляет сообщение CONNECT

/image/gif/paws/9495/isdn_q931_ts_table3.GIF

Если вызываемый маршрутизатор получает сообщение SETUP, но не отвечает сообщением CONNECT, то это может свидетельствовать о том, что маршрутизатор не принимает вызов (по неизвестным причинам).

Выполните следующие задачи на вызываемом маршрутизаторе.

  • Проверьте, не вызвано ли отклонение вызова фильтрацией на основе автоматического определителя номера (АОН) или службы определения набранного номера (DNIS).

    Фильтрация по АОН или DNIS позволяет маршрутизатору выборочно принимать или отклонять отдельные вызовы без затрат на оплату соединений. Если используется функция фильтрации по АОН, вызываемый маршрутизатор принимает в сообщении установления соединения SETUP номер вызываемой стороны. Это позволяет маршрутизатору разрешать вызовы от определенных номеров, что делает процесс более безопасным. При помощи контроля на основе DNIS вызванный маршрутизатор дифференцирует входящие вызовы по набранному номеру.

    Необходимо учитывать два основных момента в отношении экранирования на основе АОН/DNIS:

    1) телефонная компания должна предоставить точные сведения АОН/DNIS в сообщении установки (SETUP). Если на маршрутизаторе включена фильтрация по АОН, но ему не передаются номера от АОН, то все без исключения входящие вызовы будут «отфильтровываться» маршрутизатором, т.е. ни один вызов принят не будет;

    2) проверьте формат номера АОН/DNIS, сообщаемого телефонной компанией (в выводе команды debug isdn q931). Например, некоторые телефонные компании включают в номер АОН/DNIS код города, в то время как другие так не делают. Исправьте ту или иную конфигурацию АОН/DNIS по необходимости.

    Ниже приведен пример сбоя вызова. У маршрутизатора отключен анализ на основе АОН, однако, поскольку телефонная компания не предоставила цифры АОН, маршрутизатор отклоняет вызов.

    maui-nas-08#
    05:46:33: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x4E
    
    ! --- The router receives (RX) a SETUP message
    
    05:46:33:         Bearer Capability i = 0x8890
    05:46:33:         Channel ID i = 0x89
    05:46:33:         Signal i = 0x40 - Alerting on - pattern 0 
    05:46:33:         Called Party Number i = 0xC1, '5558888', Plan:ISDN,
      Type:Subscriber(local)
    
    ! --- The Called Number (DNIS) is delivered to the router
    ! --- Note that CLID information is not delivered
    
    05:46:33:         Locking Shift to Codeset 5
    05:46:33:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
    05:46:33: ISDN BR2/0: TX ->  RELEASE_COMP pd = 8  callref = 0xCE
    05:46:33:         Cause i = 0x8095 - Call rejected
    
    ! --- Calls is Rejected due to screening
    
    

    Дополнительные сведения об АОН см. в документации Аутентификация ISDN и обратный вызов с АОН.

  • Убедитесь в правильности SPID.

    При помощи команды show isdn status убедитесь, что идентификаторы SPID вызываемого маршрутизатора верны. Дополнительную информацию об устранении проблем, связанных с идентификаторами SPID, см. в документе Использование команды show isdn status для устранения неполадок с интерфейсом BRI.

  • Убедитесь, что на набранном канале есть свободные B-каналы.

    Чтобы узнать, есть ли в используемой для вызова цепи доступные каналы, воспользуйтесь командой show isdn status. Если доступных каналов больше не осталось, освободите каналы командой clear.

  • Если доступно несколько BRI, пусть телефонная компания настроит их в группе последовательного поиска.

    Наличие нескольких BRI в поисковой группе позволяет Telco коммутировать вызов для любого свободного канала BRI на этом маршрутизаторе. Свяжитесь с телефонной компанией для получения этой функциональной возможности.

  • Проверьте, есть ли проблемы, связанные с флажками конфигурации информационного канала.

    Флажки конфигурации информационного канала (bearer cap) – это служебный индикатор 3-го уровня, определяющий характеристики данного вызова. Конфигурация информационного канала указывается телефонной компанией в сообщениях Q.931 SETUP. Она часто используется для того, чтобы различать голосовые (аналоговые) вызовы с полосой 64 кбит/с, вызовы для передачи данных (56 кбит/с) и вызовы для передачи данных (64 кбит/с). Наиболее распространенные флажки конфигурации канала имеют следующий вид:

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

    Описание

    0x8890

    Вызов ISDN 64 кбит/с

    0x8890218F

    Вызов ISDN 56 кбит/сек

    0x8090A2

    Голосовой/речевой вызов (кодирование с u-характеристикой)

    0x9090A2

    Голосовой/речевой вызов (кодирование с u-характеристикой) – аудиотракт 3,1 кГц

    0x8090A3

    Голосовой/речевой вызов (кодирование с A-характеристикой)

    0x9090A3

    Голосовой/речевой вызов (кодирование с A-характеристикой) – аудиотракт 3,1 кГц

    Ниже приведен пример вызова ISDN 64 кбит/с.

    Aug  8 18:49:48.246: ISDN BR2/0: RX <-  SETUP pd = 8  callref = 0x6F
    
    !-- Incoming SETUP messages
    
    Aug  8 18:49:48.246:         Bearer Capability i = 0x8890
    
    !-- The bearer cap indicates the incoming call is ISDN 64k
    
    Aug  8 18:49:48.246:         Channel ID i = 0x89......
    

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

    Конфигурация информационного канала – 0x8890218F: вызов – цифровой ISDN 56 кбит/с.

    • Проверьте, правильно ли настроен тип коммутации ISDN.

      Тип коммутации для ISDN можно проверить с помощью команды show isdn status. Телефонная компания должна четко указать тип коммутатора, который нужно настроить. В некоторых случаях (особенно в Северной Америке) телефонная компания может указать тип коммутатора Custom (специальный) или National (национальный). В таких случаях для определения конфигурации типа коммутатора используйте следующие правила.

      • Специальный коммутатор. Если телефонная компания указывает, что значение switch-type равно Custom, то задайте значение switchtype маршрутизатора равное basic-5ess (для BRI с коммутатором 5ess), primary-5ess (для PRI с 5ess), basic-dms (для BRI с коммутатором DMS) или primary-dms (для PRI с DMS).

      • Национальный коммутатор. Соответствие типа коммутатора стандарту NI-1 для BRI и стандарту NI-2 для PRI (стандарта NI-1 для PRI не существует). Если телефонная компания сообщает, что тип коммутатора "Национальный", то конфигурация маршрутизатора Cisco должна быть "basic-ni" (для BRI) или "primary-ni" (для PRI).

      Чтобы настроить тип коммутации, используйте команду isdn switch-type тип коммутации в режиме конфигурации интерфейса BRI. Пример см. в документе Устранение неполадок интерфейса ISDN BRI на 1-м уровне.

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

      Параметр скорости (speed) в команде dialer map configuration позволяет установить скорость исходящих вызовов в 56 кбит/с, как показано ниже:

      maui-soho-01(config)#interface bri 0
      maui-soho-01(config-if)#dialer map ip 10.1.1.1 name 
      Maui-NAS-08 speed 56 5551111
      
      !-- The keyword speed 56 sets the outgoing call rate at 56k
      
      

      В данном примере иллюстрируется настройка профиля номеронабирателя Cisco IOS для совершения исходящих вызовов на скорости 56 Кбит/с:

      maui-soho-01(config)#interface dialer 1
      maui-soho-01(config-if)#dialer string 5558888 class 56k     
      
      !-- Use the map-class named "56k" when dialing number 5558888   
                 
      maui-soho-01(config-if)#exit
      maui-soho-01(config)#map-class dialer 56k
      
      !-- map-class named "56k" that was used with the dialer string above
      
      maui-soho-01(config-map-clas)#dialer isdn speed 56
      
      !-- Set the speed of the call to be 56k (default is 64k)
      
      
    • На принимающей стороне выполните настройку командой isdn not-end-to-end 56 под интерфейсом BRI.

      Maui-NAS-08(config)#interface bri 2/0
      Maui-NAS-08(config-if)#isdn not-end-to-end 56
      

      Конфигурация информационного канала ISDN Q.931 и другие информационные элементы (IE) используются для определения скорости входящего вызова и в большинстве случаев работают правильно. Однако в некоторых ориентированных на определенные страны приложениях (или при использовании унаследованных коммутаторов) входящее сообщение настройки вызова будет доставляться при конфигурации информационного канала, не соответствующей исходному вызову. При получении сообщения, указывающего на отсутствие сквозного соединения ISDN, маршрутизатор может принудительно изменить полученное значение конфигурации информационного канала, используя команду конфигурации IOS Cisco isdn not end-to-end.

      Конфигурация информационного канала – 0x8090A2 или 0x9090A2: голосовой или речевой вызов (кодирование с u-характеристикой)

      Конфигурация информационного канала – 0x8090A3 или 0x9090A3: голосовой или речевой вызов (кодирование с A-характеристикой)

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

      1. На стороне получателя убедитесь в том, что физический интерфейс ISDN (например, interface bri 0) настроен командой isdn incoming-voice modem.

      2. Проверьте, заданы ли модемные линии командой modem inout.

      Пример конфигурации см. в документе Настройка BRI в Cisco 3640.

    • Отправленный (от вызываемого маршрутизатора вызывающему маршрутизатору) код причины разъединения интерпретируется по сообщению DISCONNECT или RELEASE.

      Если вызываемый маршрутизатор не отправляет сообщения CONNECT вызывающему маршрутизатору, он должен возвратить сообщение DISCONNECT или RELEASE. Это сообщение DISCONNECT или RELEASE должно также содержать код причины разъединения. В приведенном ниже примере код причины разъединения 0x8090. Для интерпретации причины отключения третьего уровня следует также использовать документ Описание кодов причин разрыва соединения для команды «debug isdn q931».

      Aug 22 19:25:24.290: ISDN BR0: TX ->  DISCONNECT pd = 8  
      callref = 0x06
      Aug 22 19:25:24.298:         Cause i = 0x8090 - Normal call clearing
      

Вызывающий маршрутизатор не получает сообщение CONNECT

/image/gif/paws/9495/isdn_q931_ts_table4.gif

Если вызываемый маршрутизатор отправляет сообщение CONNECT, но сообщение не принимается вызывающим маршрутизатором, то наиболее вероятно, что проблема связана с телефонной компанией.

  • Определите, получает ли маршрутизатор сообщение CONNECT_ACK от локального коммутатора ISDN.

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

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

Маршрутизатор вызова получает сообщение CONNECT, но вызов по-прежнему не проходит

Если вызывающий маршрутизатор получает сообщение CONNECT, это означает, что соединение ISDN активно и функционирует исправно. Обратитесь в телефонную компанию, чтобы выяснить, нет ли проблем с B-каналом, ненадлежащим образом сопоставленным для данных. После этой стадии любые сбои вызовов будут обусловлены проблемами на вышестоящих уровнях, в частности, на уровне PPP, аутентификации или согласования IPCP/IP-адресов. Для дальнейшей диагностики неполадок PPP следует использовать команду «debug ppp negotiation».

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


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

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


Document ID: 9495