I have an ISDN problem with a 2500 router running 12.1(5)T9. About 10 seconds into each call, my ISDN provider sends me an AOC-D packet, and this causes my router to clear its call. (Or is it a "display" packet that causes the problem?) The result is that my ISDN connection flaps at 10 second intervals.
To demonstrate this problem, I set up the router to call itself, and the result is in attached file R1.121.txt, showing the call cleared after 10 seconds. I set up an identical configuration on a 2610 running 12.2(17a), and that did not do it - it waited the full 120 seconds before clearing the call - see file R4.122.txt.
From the Q931 debug, it looks like the software does not recognise the AOC-D signal (or the "display" packet?) in this state, and so disconnects the call. This looks especially strange to me as the 12.1 documentation actually contains a section about how to exploit the AOC-D signal to minimise call charges.
Thank you for the suggestion. I was considering doing that, but I was hesitating; the line is actually my private home ISDN connection, and I might like to keep the AOC for other equipment on the line. On the other hand, if is a choice between doing my lab practice and the family seeing how much they are spending on phone call ... ;-). Maybe the PTT can remove the AOC-D without removing the AOC-E.
I was actually wondering whether it really is the AOC-D that is upsetting the router. It is clearly getting upset by the packet:
AOC servicing for NET3 switches seems to be in the code as early as the 11.3 release. I am guessing that maybe there was something buggy about that specific code train you have running on the 2500. Just to get it to work, you might want to try playing with these commands and see if the IOS will respect them and act on them:
dialer idle-timeout 300 (set it there just for test purposes)
dialer isdn short-hold 300 (set it there just for test purposes)
Make sure to remove these after testing so your ISDN bills do not increase. If the IOS does respect these commands, I can only conclude that maybe the default was set to something other than the default (120 seconds). Since you and I don't get access to the source code, they why part will remain a mystery ;-)
If that still does not fix it, you may wish to consider temporarily loading a different version of IOS, just to see if the version you have is just plain buggy for this feature. I am guessing a good place to start would be a known good value of IOS 12.2(17a) if you have it. Of course, if this is a production network, that might be a little harder to do (possibly off hours maybe?)
Thanks for the reply. I did actually try playing with the idle timers, changing them to 40 seconds and 30 seconds to see if that was the problem, but it made no difference. Also, the Q931 and dialer event debug looks rather different for an idle timeout - more like the one in the 12.2 terminal log I posted.
I am convinced the router is getting upset by the packet from the exchange:
But whether this is actually an AOC-D packet, I am not sure. I need to know more about the Q931 debug.
I was looking at the documentation for my ISDN-2a/b box (an NT1, Siemens SANTIS) to see if there was any way I could filter out the AOC signal. The nearest I could see was a feature to enable or disable toll charging pulses, but I think that refers to the analog side rather than to the S/T bus.
Unfortunately the router is a 2500, so AFAIK there is no 12.2 available for it. The 12.2(17a) is more useful on the 2600 series.
If I read the disconnect code right, it would seem that, "The switch receives the ISDN number in the correct format. However, the number does not belong to destination equipment." That almost sounds like the configured number on your router is not spitting back a result the telco switch expects and is unhappy and disconnects the circuit. If it were a DSL connection, I would say throw a hub between the router and the ethernet interface and try to capture the PPPoE traffic, but it is a little harder with ISDN unless you have a WAN sniffer.
I am not sure what type of 2500 series router you have or what version of code you are running, but I have this running on my 2520:
Cisco Internetwork Operating System Software
IOS (tm) 2500 Software (C2500-JS-L), Version 12.2(5), RELEASE SOFTWARE (fc1)
16384K bytes of processor board System flash (Read ONLY)
Configuration register is 0x2102
Keep in mind, this is running the enterprise feature set, also known as the "kitchen sink version" - it's in there. That is not to say that the usability of the IOS stopped for 2500s at 12.2(5), but my guess is that if you booost the gain on your DRAM to the max allowed, you might be able to run that version of IOS. It just takes a while to load.
Thanks again, this time for the document. With the help of the document, the way I interpret the disconnect code 0x80E27B is:
CauseOrigin = 0x80, i,e. the router cleared the call,
DisconnectCause = 0xE2, I look it up in the big table at the end of the document, and I find more or less the same text as in the Q931 debug, but expanded: "Message not compatible with call state etc." The router seems to be interpreting the packet from the PTT as a D-channel error. I am guessing that the PTT is sending a signal that was not forseen when 12.1 was written.
Interesting about the IOS versions for the 2500 series. The release notes stop at 12.1(5)T:
But as you observe, there are 12.2 versions, and even 12.3 versions out there in the routers on eBay, and these would probably know about the offending packet and handle it without clearing the call. Unfortunately, the Cisco Software adviser no longer gives any matches at all for 2500 seftware, which I guess is Cisco's way of saying "throw it away and buy a new one." I am quite hesitant to do that because it is part of my home lab and so cost is a consideration.
How big is 12.2(5)? I know that 12.1(5)T9 is already 15.680.044 bytes in the -JS- version, so it is already getting pretty near the max flash.
My options are now either to ask the PTT to remove the AOC-D and see if that does the trick, or to modify that part of the lab exercise.
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 ...