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

Выполнение замыканий на себя для проверки линий связи BRI

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


Содержание


Введение

Этот документ содержит указания по организации петли для тестирования каналов интерфейса BRI.

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

Требования

Читатели данного документа должны обладать знаниями по следующим темам:

  • Выходные данные debug isdn q931 и команд debug ppp negotiation.

  • Общие понятия настройки профиля программы набора номеров DDR. Для получения дополнительной информации о профилях DDR посмотрите Профили DDR Устранения проблем и Настройка.

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

  • Switch-type, который должен быть настроен.

  • Идентификаторы профиля услуги (SPID) и Местный абонентский номер (LDN). SPID и LDN требуются в Соединенных Штатах Америки.

  • Являются ли оба B-канала в группе последовательного поиска. Если они находятся в группе слежения, мы только должны набрать один номер для достижения любого B-канала.

  • Должен ли запрос к линии BRI быть сделан в 56k или 64k

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

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

  • Программное обеспечение Cisco IOS версии 12.0(3)T, и позже. Это вызвано тем, что команда вызова ISDN была представлена в программном обеспечении Cisco IOS версии 12.0(3)T.

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

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

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

Общие сведения

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

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

Существует два типа Вызовов петли, которые можно выполнить для тестирования цепи с интерфейсом BRI:

  • Уровень ISDN 3 вызова петли??? для которого можно использовать команду isdn call interface . Этот вызов петли может помочь вам проверять, функциональны ли Уровни ISDN 1, 2, и 3 между маршрутизатором и локальным коммутатором ISDN. Этот тест использует Канал D и не делает тестовых данных через B-каналы. Это не включает изменений к конфигурации маршрутизатора. Выполните этот тест сначала. Если это успешно выполняется, делайте попытку теста вызова обратной связи для данных.

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

Эти процедуры только позволяют вам тестировать, функциональна ли цепь с интерфейсом BRI к локальному коммутатору. Это не тестирует сквозное Подключение ISDN или проблемы, отнесенные к технологии DDR. Для получения дополнительной информации об устранении проблем BRIs обращаются к следующим документам:

Выполните уровень ISDN 3 вызова петли

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

Рисунок 1 отображает поток вызовов и некоторые сообщения debug isdn q931:

Рисунок 1 - Поток вызовов и Некоторые сообщения debug isdn q931

/image/gif/paws/22802/bri_loopback_call1.gif

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

!--- The router dials 5551111 (the ISDN number of the router's own BRI).
!--- If the BRI circuit has two different phone numbers for each B-channel,
!--- use the number that belongs to the second B-channel.
!--- You can use this command to make calls at 56k, with the speed 56 option
.
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 now processes 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 message 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. Например, маршрутизатор передает сообщение SETUP (TX-> НАСТРОЙКА) и получает ту также (RX <-НАСТРОЙКА). В то время как полученное сообщение установки привязано к входящему вызову, переданная НАСТРОЙКА должна быть привязана к исходящему вызову.

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

  • Выполните вызов петли на другом маршрутизаторе.

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

Для получения информации о том, как решить любые проблемы, обратитесь к этим документам:

Выполните вызов обратной связи для данных

Вызовы обратной связи для данных полезны для теста, могут ли B-каналы должным образом передать данные. Во многих ситуациях может постоянно отказывать debug ppp negotiation. Этот тест может использоваться для проверки целостности данных на B-канале.

Примечание: Этот тест, в отличие от предшествующего теста, включает изменение конфигурации к маршрутизатору.

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

Создайте профиль DDR для набора номера другого профиля DDR на том же маршрутизатор.

Настройте маршрутизатор

Для настройки маршрутизатора для вызова петли выполните эти шаги:

  1. Сохраните рабочую конфигурацию с помощью команды copy running-config startup-config. Когда вы делаете так, можно перезагрузить и восстановить текущую конфигурацию к предварительной версии после того, как тест завершен.

  2. Настройте физический интерфейс.

    Примечание: Этот раздел предполагает, что вы знаете о необходимой СВЯЗАННОЙ С ISDN информации такой как, switch-type и SPID.

    interface BRI0
     no ip address
     
    !--- Do not configure an IP address on the physical interface.
     !--- The IP address will be configured on the dialer. 
    
     encapsulation ppp
     !--- physical interface uses PPP encapsulation
     dialer pool-member 1
     
    !--- Assign BRI0 as member of dialer pool 1.
     !--- Dialer pool 1 is specified in interface Dialer 1, and 
     !--- interface Dialer 2.
    
     isdn switch-type basic-ni
     isdn spid1 71355511110101 5551111
     isdn spid2 71355511120101 5551112
     
    !--- switch-type and SPID configuration.
     !--- Contact the telco for this information. 
    
     ppp authentication chap callin   
     
    !--- The physical interface uses CHAP authentication.
     !--- Authentication is required on the physical interface to bind the 
     !--- incoming call to the right dialer profile.
    
    
  3. Настройте первый интерфейс номеронабирателя:

    interface Dialer1
     ip address 1.1.1.1 255.255.255.0
     
    !--- Assign an IP address to the dialer interface.
     !--- In this example, the IP addresses for both dialers
     !---  are in the same subnet.
    
     encapsulation ppp
     
    !--- The dialer interface uses PPP (same as the physical BRI interface).
    
     dialer pool 1
    
     !--- his defines Dialer pool 1. BRI 0 is a member of this pool.
    
     dialer remote-name dialer2
     
    !--- This name must match the name used by the other dialer interface to
     !--- authenticate itself. Dialer string 7135551112.
     !--- Phone number for the other B-channel.
     !--- If your connection only needs one number for both B-channels
     !--- (that is, they are in a hunt-group), use that number here.
    
     dialer-group 1
     
    !--- Apply interesting traffic definition from dialer-list 1.
    
     ppp authentication chap callin
    
     !--- Use one-way CHAP authentication. This is sufficient for this test.
    
     ppp chap hostname dialer1
    
     !--- CHAP hostname to be sent out for authentication.
    
     ppp chap password dialer1
    
     !--- CHAP Password to be sent out for authentication.
    
    
  4. Настройте второй интерфейс номеронабирателя:

    interface Dialer2
     ip address 1.1.1.2 255.255.255.0
    
     !--- Assign an IP address to the dialer interface.
     !--- In this example, IP address for both dialers are in the same subnet.
    
     encapsulation ppp
     dialer pool 1
    
     !--- This defines Dialer pool 1.
     !--- BRI 0 is a member of this pool.
    
     dialer remote-name dialer1
    
     !--- This name must match the name used by the other dialer interface 
     !--- (dialer1) to authenticate itself. Dialer string 7135551111.
     !--- Phone number for the other B-channel.
     !--- If your connection only has one number for both B-channels 
     !--- (that is, they are in a hunt-group), use that number here.
    
     dialer-group 1
    
     !--- Apply interesting traffic definition from dialer-list 1.
    
     ppp authentication chap callin
     ppp chap hostname dialer2
    
     !--- CHAP hostname to be sent out for authentication.
    
     ppp chap password dialer2
    
     !--- CHAP Password to be sent out for authentication.
    
    
  5. Настройте имя пользователя и пароли для аутентификации:

    username dialer1 password 0 dialer1
    username dialer2 password 0 dialer2
    

    Имя пользователя и пароли совпадают с теми, вы настроили с помощью команд ppp chap hostname и ppp chap password под каждым интерфейсом номеронабирателя.

  6. Настройте статические маршруты для ясности:

    ip route 1.1.1.1 255.255.255.255 Dialer1
    
    !--- Note that the route for 1.1.1.1 points to dialer1.
    
    ip route 1.1.1.2 255.255.255.255 Dialer2
    
    !--- Note that the route for 1.1.1.2 points to dialer2.
    !--- The routes are used to determine which dialer interface is 
    !--- used for dialout.
    
    

    Совет: При настройке IP-адресов для interface Dialer 1 (Шаг 3) и interface Dialer 2 (Шаг 4) в отдельные подсети статические маршруты не необходимы.

  7. Настройте определение содержательного трафика.

    dialer-list 1 protocol ip permit

    Примечание: номер списка программ для набора номера должен совпасть с тем, настроенным в dialer-group под интерфейсом номеронабирателя. В данном примере настройте dialer-list 1.

  8. Когда тест завершен, перезагрузитесь, маршрутизатор (не сохраняйте конфигурацию) возвратиться к оригинальной конфигурации, используемой до теста.

Инициируйте вызов обратной связи для данных

Мы будем теперь инициировать вызов обратной связи для данных и искать успешное завершение согласования PPP. Успешное согласование PPP указывает, что B-каналы могут должным образом передать данные.

Рисунок 2 - инициирует вызов обратной связи для данных

bri_loopback_call2.gif

Активируйте эти отладки:

  • debug dialer –

  • debug isdn q931

  • debug ppp negotiation –

  • (дополнительный) debug ppp authenticaion

Примечание: Когда вызов петли происходит, маршрутизатор выполняет и как Вызываемый маршрутизатор и как Вызывающий маршрутизатор на других B-каналах. Важно, чтобы вы отслеживали эти "двойные роли" при интерпретации выходных данных команд debug ppp negotiation и debug isdn q931. Например, маршрутизатор передает сообщение SETUP (TX-> НАСТРОЙКА) и получает ту также (RX <-НАСТРОЙКА). В то время как полученное сообщение установки привязано к входящему вызову, переданная НАСТРОЙКА должна быть привязана к исходящему вызову.

Вот отладки для встречно-параллельного вызова ISDN:

router#show debug
Dial on demand:
  Dial on demand events debugging is on
PPP:
  PPP protocol negotiation debugging is on
ISDN:
  ISDN Q931 packets debugging is on
  ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-)
  DSL  0 --> 1
  1 -

router#ping 1.1.1.1

!--- Because of the static route entry shown in step 6 above,
!--- the call is made out from dialer 1.


Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:

03:40:41: BR0 DDR: rotor dialout [priority]
03:40:41: BR0 DDR: Dialing cause ip (s=1.1.1.1, d=1.1.1.1)
03:40:41: BR0 DDR: Attempting to dial 7135551112
03:40:41: ISDN BR0: TX ->  SETUP pd = 8  callref = 0x08

!--- Outgoing SETUP message.

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x83
03:40:41:         Keypad Facility i = '7135551112'
03:40:41: ISDN BR0: RX <-  CALL_PROC pd = 8  callref = 0x88
03:40:41:         Channel ID i = 0x89
03:40:41: ISDN BR0: RX <-  SETUP pd = 8  callref = 0x2A

!--- Incoming SETUP message on the other B-channel.

03:40:41:         Bearer Capability i = 0x8890
03:40:41:         Channel ID i = 0x8A
03:40:41:         Signal i = 0x40 - Alerting on - pattern 0
03:40:41:         Called Party Number i = 0xC1, '5551112', Plan:ISDN,
  Type:Subscriber(local)
03:40:41:         Locking Shift to Codeset 5
03:40:41:         Codeset 5 IE 0x2A  i = 0x808001038001118001, '<'
03:40:42: ISDN BR0: Event: Received a DATA call from  on B2 at 64 Kb/s

!--- Note that the call comes in on the second B-channel (BRI0:2).
!--- Hence the outgoing call must have been on BRI0:1.

03:40:42: ISDN BR0: Event: Accepting the call id 0xB
03:40:42: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up.
03:40:42: BR0:2 PPP: Treating connection as a callin
03:40:42: BR0:2 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load]
03:40:42: BR0:2 LCP: State is Listen

!--- PPP LCP negotiations begin. 

03:40:42: ISDN BR0: TX ->  CALL_PROC pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: TX ->  CONNECT pd = 8  callref = 0xAA
03:40:42:         Channel ID i = 0x8A
03:40:42: ISDN BR0: RX <-  CONNECT_ACK pd = 8  callref = 0x2A
03:40:42:         Channel ID i = 0x8A
03:40:42:         Signal i = 0x4F - Alerting off
03:40:42: ISDN BR0: RX <-  CONNECT pd = 8  callref = 0x88
03:40:42: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
03:40:42: BR0:1: interface must be fifo queue, force fifo
03:40:42: %DIALER-6-BIND: Interface BR0:1 bound to profile Di1
03:40:42: BR0:1 PPP: Treating connection as a callout
03:40:42: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
03:40:42: BR0:1 PPP: No remote authentication for call-out

!--- One-way authentication (configured with PPP authentication CHAP callin).

03:40:42: BR0:1 LCP: O CONFREQ [Closed] id 11 len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: ISDN BR0: TX ->  CONNECT_ACK pd = 8  callref = 0x08
03:40:42: BR0:2 LCP: I CONFREQ [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:2 LCP: O CONFREQ [Listen] id 11 Len 15
03:40:42: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:2 LCP: O CONFACK [Listen] id 11 Len 10
03:40:42: BR0:2 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: I CONFREQ [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: O CONFACK [REQsent] id 11 Len 15
03:40:42: BR0:1 LCP:    AuthProto CHAP (0x0305C22305)
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:42: BR0:1 LCP: I CONFACK [ACKsent] id 11 Len 10
03:40:42: BR0:1 LCP:    MagicNumber 0x513D7870 (0x0506513D7870)
03:40:42: BR0:1 LCP: State is Open
03:40:42: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 1 load]
03:40:43: BR0:2 LCP: I CONFACK [ACKsent] id 11 Len 15
03:40:43: BR0:2 LCP:    AuthProto CHAP (0x0305C22305)
03:40:43: BR0:2 LCP:    MagicNumber 0x513D7A45 (0x0506513D7A45)
03:40:43: BR0:2 LCP: State is Open
03:40:43: BR0:2 PPP: Phase is AUTHENTICATING, by this end [0 sess, 1 load]

!--- Authentication begins.

03:40:43: BR0:2 CHAP: O CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: I CHALLENGE id 7 Len 26 from "router"
03:40:43: BR0:1 CHAP: Using alternate hostname dialer1

!--- Use the alternate hostname specified with PPP CHAP hostname 
!--- under int Dialer 1.

03:40:43: BR0:1 CHAP: Username router not found
03:40:43: BR0:1 CHAP: Using default password
03:40:43: BR0:1 CHAP: O RESPONSE id 7 Len 28 from "dialer1"

!--- Outgoing CHAP response sent on B-channel 1. 

03:40:43: BR0:2 CHAP: I RESPONSE id 7 Len 28 from "dialer1"

!--- Incoming CHAP response seen on B-channel 2.

03:40:43: BR0:2 CHAP: O SUCCESS id 7 Len 4

!--- Authentication is successful

03:40:43: BR0:2: interface must be fifo queue, force FIFO
03:40:43: %DIALER-6-BIND: Interface BR0:2 bound to profile Di2

!--- Call (from Dialer 1) is bound to int Dialer 2. 
!--- This is because the dialer remote-name dialer1 command is 
!--- configured under int dialer 2. Binding fails when the dialer remote-name 
!--- command is omitted, or is incorrect, .

03:40:43: BR0:2 PPP: Phase is UP [0 sess, 0 load]

!--- IPCP negotiation begins.

03:40:43: BR0:2 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 CHAP: I SUCCESS id 7 Len 4
03:40:43: BR0:1 PPP: Phase is UP [0 sess, 1 load]
03:40:43: BR0:1 IPCP: O CONFREQ [Not negotiated] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 CDPCP: O CONFREQ [Closed] id 1 Len 4
03:40:43: BR0:1 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:1 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:1 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFREQ [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 IPCP: O CONFACK [REQsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:2 CDPCP: I CONFREQ [REQsent] id 1 Len 4
03:40:43: BR0:2 CDPCP: O CONFACK [REQsent] id 1 Len 4
03:40:43: BR0:2 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:2 IPCP:    Address 1.1.1.2 (0x030601010102)
03:40:43: BR0:2 IPCP: State is Open

!--- IPCP on B-channel 2 is Open.

03:40:43: BR0:1 IPCP: I CONFACK [ACKsent] id 1 Len 10
03:40:43: BR0:1 IPCP:    Address 1.1.1.1 (0x030601010101)
03:40:43: BR0:1 IPCP: State is Open

!--- IPCP on B-channel 1 is Open.

03:40:43: BR0:2 DDR: dialer protocol up
03:40:43: BR0:1 DDR: dialer protocol up
03:40:43: Di2 IPCP: Install route to 1.1.1.1
03:40:43: Di1 IPCP: Install route to 1.1.1.2
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:2, 
changed state to up
03:40:44: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, 
changed state to up

!--- Both B-channels are up.

...
Success rate is 0 percent (0/5)
router#

Примечание: Эхо-запросы могут отказать из-за проблем, отнесенных к маршрутизации. Можно ожидать это. Успешное согласование PPP является настоящим тестом того, могут ли B-каналы должным образом передать данные ссылке. Если вызов отказывает, свяжитесь с telco (телефонная компания) для получения дополнительной информации о том, как устранить неполадки линии.


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


Document ID: 22802