I am using BRI isdn as a backup method for my remote branches. I feel a bit uneasy about the solution. My concern is there are these ISDN switch boxes. The boxes are there to introduce human intervention. If the primary interface goes down the user must switch the dial to an on position. What I have noticed is that the Layer 2 does not always come up. Could it be possible that these switch boxes are causing a problem? If the router is rebooted it comes right. It looks like every time you have to reboot the router in order for it to work. It basicaly looks like the ISDN will work once and then you have to reboot it in order for it to work again.
I used to experience similar problems with ISDN some years ago, backup lines apperared to go to sleep. Reboot all kit, no more problem. This was caused by noise on the ISDN circuit, this upset the TEI relationship, rebooting reset the TEI. Instead of rebooting the router try disconecting and reconnecting ISDN lead once the ISDN switch box has been moved to backup position. If this brings up L2 then the problem may well be with the switch box not making a clean switch over.
I experienced a similar problem, but with a router connecting to a Siemens Hicom PABX. I changed the IOS and never had problems again. At the same time the guys that support the Siemens Hicom went there, so I am not certain what really solved the problem, the IOS upgrade or something changed on the Siemens Hicom.
Anyway, iF it is a TEI negotiation problem, try to change the TEI negotiation from the default, which happens when a router boots up, to TEI negotiation at call establishment.
I will play with the TEI negotion. This does make sence. I have also spoken to some people about this problem. They say that there is a bug with the 1751's with regards to ISDN, this on any version of code. If find this hard to believe for numerous reasons. 1) The BRI WIC can be used on any platform. 2) This sort of problem would be picked up when the code was written. What is your view? I have never really had code related problems on Cisco kit.
The first thing to check at the first suspicion of an ISDN failure, either on a BRI or a PRI, is the output from show isdn status. The key things to note are that Layer 1 should be Active and Layer 2 should be in a state of MULTIPLE_FRAME_ESTABLISHED/TEI_ASSIGNED.
Hi;As for the layer 1 not always up that could be because of the way you purchased the ISDN service, you can have layer 1 come up upon sending data only.what you might need to do is check the ISDN port status after using the ISDN connection and as soon as you turn the ISDN switch box OFF...try to clear the ISDN port or the dialer and notice the difference.you can also try to setup the following command on the ISDn port which will delay the BRI interface to make an ISDN connection. " dialer wait-for-carrier-time seconds " this might be helpfull
I hate to state the obvious but unless there is a critical need to have human intervention in your backup solution you should get rid of the switchboxes. I've seen more trouble with similar solutions than it's worth.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...