ISDN BRI layer 1 & layer 2 do not sustain "active" statuses

[jasonpeh123]

Hi Expert,

I have some routers which can not sustain the ISDN layer 1 & layer 2 statuses correctly. Whenever, the ISDN line is manually activated or the ISDN BRI ports are manually reset, the layer 1 & layer 2 statuses become active but they become deactivated after a while. I have changed the ISDN module and the same symptom is observed. Would you advise what is the cause and resolution. Your advice in this matter is greatly appreciated.

Thanks and Regards,

Jason Peh

[Georg Pauwen]

Hello Jason,

there are numerous possible reasons for the Layer 1 status to be 'deactivated', such as wrong cabling, or incorrectly configured ISDN switch types. Check the document below for a detailed explanation of the various causes:

Troubleshooting ISDN BRI Layer 1

http://www.cisco.com/warp/public/129/bri-layer1.html

HTH,

GP

[jasonpeh123]

Hi GP,

Thanks for your reply. There are neither physical connection nor the switch-type problem as I can still be able to establish the connection. The problem is that the layer 1 and layer 2 statuses do not show "active" & "multi_frame_established" respectively which are normally we see when issuing the "show isdn status" command. The statuses become deactivated completedly after a while when the link is disconnected. When I debugged ISDN q921 & q931, I do not see "keep alive packets" are going on as what others routers do. Please let me know if I need to provide more information to help me. Thanks in advance.

With Regards,

Jason Peh

[Georg Pauwen]

Hello Jason,

some ISDN switches deactivate Layer 1 when there are no active calls. Try to configure the following under your BRI interface:

ISDN_Router(config)#interface bri 0

ISDN_Router(config-if)#isdn tei-negotiation first-call

Can you post your configuration ?

Regards,

GP

[jasonpeh123]

Hi GP,

Below is the configuration,

username router_1 password password_only

!

interface Serial0/1

bandwidth 1984

backup interface Dialer1

ip address xx.xx.xx.xx 255.255.255.252

no ip directed-broadcast

ip ospf cost 500

no cdp enable

!

!

interface BRI1/0

no ip address

no ip directed-broadcast

encapsulation ppp

dialer pool-member 1

isdn switch-type basic-net3

isdn tei-negotiation first-call

no cdp enable

ppp authentication chap

!

!

interface Dialer1

bandwidth 128

ip address xx.xx.xx.xx 255.255.255.252

no ip directed-broadcast

encapsulation ppp

ip ospf cost 2000

no ip mroute-cache

dialer remote-name router_1

dialer idle-timeout 60

dialer string 03xxxxxxx

dialer load-threshold 1 either

dialer pool 1

dialer-group 1

no fair-queue

no cdp enable

ppp authentication chap

ppp multilink

!

dialer-list 1 protocol ip permit

Below is the debug messages,

router_2#

24w4d: ISDN BR1/0: L1 is IF_ACTIVE

24w4d: ISDN BR1/0: Incoming call id = 0x9CB, dsl 8

24w4d: ISDN BR1/0: TX -> SABMEp sapi = 0 tei = 66

24w4d: ISDN BR1/0: RX <- UAf sapi = 0 tei = 66 *Aug 20 03:12:58.648 UTC: %ISDN-6-LAYER2UP: Layer 2 for Interface BR1/0, TEI 66 changed to up kaosr1#

24w4d: ISDN BR1/0: RX <- DISCp sapi = 0 tei = 66 *Aug 20 03:13:08.869 UTC: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR1/0, TEI 6

6 changed to down

24w4d: ISDN BR1/0: TX -> UAf sapi = 0 tei = 66

24w4d: ISDN BR1/0: RX <- IDCKRQ ri = 0 ai = 66

24w4d: ISDN BR1/0: TX -> IDCKRP ri = 43027 ai = 66

24w4d: ISDN BR1/0: Recvd MPH_EI1_IND from L1

24w4d: ISDN BR1/0: Physical layer is IF_DOWN

24w4d: ISDN BR1/0: Shutting down ME

24w4d: ISDN BR1/0: Shutting down ISDN Layer 3

I've configured the command "isdn tei-negotiation first-call" but the problem persists.

If you need more information, please let me know.

With Regards,

Jason Peh

[Georg Pauwen]

Hello Jason,

I think the 'backup interface' command under your Serial0/1 interface is causing the issue, it deactivates the interface until the backup is initiated. That is actually expected behaviour. Try and remove the command from the Serial0/1 interface and see if that changes the Layer 1 status (for testing purposes only, since otherwise, obviously, your backup won't work anymore)...

HTH,

GP

[jasonpeh123]

Hi GP,

Thanks for your prompt reply.

I've removed the command "backup interface xxx" in the main link and the problem does not seem to go away.

From CISCO website, it mentions that a circuit is properly functioning (Layer 2 is Multiple Frame Established), I should have periodic exchanges of RRp sapi = 0 and RRf sapi = 0 messages between the router and the ISDN switch, indicating that the link is up. However, I do not see any periodic exchanges when I turn on the degugging.

Thanks,

Jason Peh

[Richard Burts]

Georg's suggestion would be exactly right if your backup interface pointed to the BRI. But your backup interface pointed to the dialer virtual inteface and this avoids the problem of deactivating the ISDN connection.

Perhaps it would be helpful if you post the output of show isdn status and also the output of show interface for the BRI1/0 and BRI1/0:1 interfaces.

HTH

Rick

[jasonpeh123]

Hi Rick,

Below is the show interface for BRI1/0,

router_2#sh isdn status

Global ISDN Switchtype = basic-net3

ISDN BRI1/0 interface

dsl 8, interface ISDN Switchtype = basic-net3

Layer 1 Status:

DEACTIVATED

Layer 2 Status:

TEI = 66, Ces = 1, SAPI = 0, State = TEI_ASSIGNED

Layer 3 Status:

0 Active Layer 3 Call(s)

Activated dsl 8 CCBs = 0

The Free Channel Mask: 0x80000003

router_2#sh int BRI1/0

BRI1/0 is up (spoofing), line protocol is up (spoofing)

Hardware is BRI

MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

Last input 00:04:39, output 00:04:39, output hang never

Last clearing of "show interface" counters 24w4d

Input queue: 0/75/0 (size/max/drops); Total output drops: 0

Queueing strategy: weighted fair

Output queue: 0/1000/64/0 (size/max total/threshold/drops)

Conversations 0/1/16 (active/max active/max total)

Reserved Conversations 0/0 (allocated/max allocated)

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

27807 packets input, 207167 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

27921 packets output, 209138 bytes, 0 underruns

0 output errors, 0 collisions, 551 interface resets

0 output buffer failures, 0 output buffers swapped out

1680 carrier transitions

router_2#sh int BRI1/0:1

BRI1/0:1 is down, line protocol is down

Hardware is BRI

MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

LCP Closed, multilink Closed

Last input 04:59:17, output 04:59:17, output hang never

Last clearing of "show interface" counters never

Queueing strategy: fifo

Output queue 0/40, 108 drops; input queue 0/75, 1 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

7434 packets input, 1689890 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

2 input errors, 0 CRC, 1 frame, 1 overrun, 0 ignored, 1 abort

10743 packets output, 782350 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

4682 carrier transitions

router_2#sh int BRI1/0:2

BRI1/0:2 is down, line protocol is down

Hardware is BRI

MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation PPP, loopback not set

Keepalive set (10 sec)

LCP Closed, multilink Closed

Last input 04:59:22, output 04:59:22, output hang never

Last clearing of "show interface" counters never

Queueing strategy: fifo

Output queue 0/40, 3 drops; input queue 0/75, 3 drops

5 minute input rate 0 bits/sec, 0 packets/sec

5 minute output rate 0 bits/sec, 0 packets/sec

6902 packets input, 1530090 bytes, 0 no buffer

Received 0 broadcasts, 0 runts, 0 giants, 0 throttles

3 input errors, 0 CRC, 3 frame, 0 overrun, 0 ignored, 3 abort

7527 packets output, 594592 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 output buffer failures, 0 output buffers swapped out

25 carrier transitions

I have another router with the same configuration and the statuses are able to sustain correctly. Thus, I doubt that the backup interface command has any effect on the layer 1 & layer 2 statuses.

Best Regards,

Jason Peh

[johansens]

It's perfectly normal for the ISDN to deactivate L1 and L2 as long as it's a point-to-multipoint connection and you don't have any calls coming in or going out.

On standard BRI-circuits delivered from telco's it's a point-to-multipoint link. If you have a PRI, it's a point-to-point and the L1/L2 will be kept alive at all time. If you run the PRI into a PABX and take a single BRI out from this on a separate interface, in many (most) cases the PABX will keep the L1/L2 active at all times.

The question is, when you try to use the BRI-link, does it work? If so, what's the problem? :)

On a sidenote:

There is a bug in 12.3(11)T2 which makes the router establish the L2 connection every time the ISDN Switch tears it down. This is a confirmed bug (http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCeg55098&Submit=Search) and is resolved in 12.4(1a).

[jasonpeh123]

Hi,

Due to the instability of the Telco circuit, the customers requested to monitor all the ISDN lines to ensure that the lines are readily available to connect when the main link goes down. The statuses of layer 1 & layer 2 should be active under the normal circumstances. I know the ISDN can establish and I have no doubt it works. Since the customer has requested to monitor the statuses and all of us know that the layer 1 and layer 2 should exbibit the correct statuses. We would like to know and investigate why some circuits behave so differently from others. Please advise me on what is the cause and the resolutions. Thanks.

[Richard Burts]

I believe that the show interface that you posted does conclusively demonstrate that it is not an issue with backup interface.

I am wondering why some routers with similar configurations are able to sustain the active status while this router is not. Is there perhaps a difference in IOS version between the routers? Would it be possible to swap in a different router and see if that affected the problem?

The other possibility that is occuring to me is that there might be some issue with the circuit or with the ISDN switch. Perhaps you could open a ticket with the provider and ask them to check the circuit carefully.

HTH

Rick

[jasonpeh123]

Hi Everyone,

I've logged a ticket to the provider before I put up this issue in the FORUM. The Sercive Provider said that the functionality of the ISDN is in working condition. From my observation, there is no signalling between the router and the ISDN switch to be seen during the debugging. Do you have any advice as what could the provider do more to rectify the issue?

[johansens]

What you need to do is compare a ISDN Switch which L1/L2 is constantly "up" with one which is not.. what's the difference.. I would guess the answer to this will be your solution...

In summary; You can't do anything about it, the telco must change it's setting as it's they who tear down the link.. (You can see this in the debug's as "RX <- DISC", you are receiving a DISConnect from the ISDN switch... ie. you don't have a choice.

[pwilson7270]

If you make up an rj45 loopback plug(pin 1> pin5 and pin 2> pin 4)then plug this into you BRI INTERFACE it should bring your interface up then do an isdn statusto see if layer 1 and 2 stay up.If so then there is nothing wrong with the interface on the router.I would then confirm with your provider that you have configured the correct switch type,if this is okay get your provider to test the line and prve they can make isdn calls from their demarc without the call dropping.