cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
241
Views
0
Helpful
2
Replies

Serious Bug in Cisco IOS 12.2(19) ISDN Issue

i70881
Level 1
Level 1

We recently encountered a serious problem with Cisco IOS 12.2(19) and ISDN connections. Our setup was a 7206vxr router with 2 inbound PRIs.

When a remote site would fail over to ISDN backup (from frame relay) and call in to the 7206, the connection would come up correctly. When frame relay service returns, the ISDN connection is supposed to drop after 15 minutes and the ISDN interface on the remote router should return to a standby mode.

After 15 minutes what we saw was the remote ISDN interface indeed going into standby mode, and the frame interface up/up. However looking at the local 7206, we still saw the ISDN connection in a connected state. Thinking that was quite odd, we bounced the PRI interface, which killed all connections (sh isdn serv, etc showed no active lines).

Or so we thought.

When we got a large bill for ISDN usage the next month, we started investigating.

It seems what happens is even though the local and remote routers see no sign of an ISDN connection, it is STILL THERE (confirmed by ISDN provider). So basically we had calls up 24x7 that were not being used.

The reason for this post is to query the user community if anyone else has ever experienced this problem before. Cisco has not yet found this is a bug in their IOS 12.2(19).

This bug started occuring right after we upgraded to 12.2(19), and stopped as soon as we rolled back to our old IOS. This is how we know that it is an IOS bug.

So, any thoughts?

Thanks!

2 Replies 2

nikhil_m
Level 1
Level 1

I am not sure if this is a bug at all.

After extensive testing, there is indeed a difference between 12.2(19) and our previous code. For some reason 12.2(19) in our implementation did not send out ISDN keepalive packets. The result of this was that when the remote side went in to standby mode, the connection was never dropped. Normally the remote side will go into standby mode and stop responding to keepalives. After 5 keepalives are missed, the local side will tear down the call. Since the 12.2(19) code was not checking the connection, the connection remained up indefinitely.

I would call an IOS not sending out keepalives when it is configured to do so a bug.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco