ISDN disconnet

[mr7]

Hi group,

I have a case from A dials to B by ISDN, A with idle-timeout of 30 sec and B has idle-timeout of 6o sec. They are both in 12.3 IPBase image

A can place call to B successfully by PING as interesting traffic, I keeping from router to router, but strange is that the call will drop every 60 sec and then re-activated as I keep pinging. This 60 sec will change is I change the idle-timeout in B to some other value.

Debug with q931 in B side shows it's normal call clearing initiated from B, i.e. 0x8090 for cause.

I just want to ask, at before, I remeber that the called side will not drop call if there is inbound traffic even the inbound traffic is not the same as the interesting traffic, but in this case, I test that if I define echo reply as interesting traffic in B, the call initiated from A's Ping will not drop.

Is it normal?

Thx,

BBD

[Georg Pauwen]

Hello,

can you post the configurations of your routers, as well as the output of ´debug dialer events´ ?

Regards,

Georg

[mr7]

I just want to simply ask do you think you should include inbound traffics definition in interesting traffic dialer-group setting if you are the called side router but not the calling side in order to prevent the ISND line drop after idle-timeout?

That is, what's the definition of interesting traffic: if the outbound traffic not defined by the dialer-group, can it reset the idle-timeout in the called end router? (So that no matter what traffic can reset the idle timout?)

Also, if there is only inbound traffic but no outbound traffic in the called end router, will these traffic reset the idle timeout?

I will try to get the config to you as they are now in my customer site.

[aacole]

As I understand this the interesting traffic definition is for traffic that is outbound from the router only.

So if your router A makes a call due to an interesting packet, the call comes up for 30 seconds. If more traffic flows from router A then the idle timer is reset on each interesting packet. However at B if no interesting traffic is outgoing to A then the idle timer will time out and B will drop the call.

There is a show command that will indicate how much idle time is left, SH DIALER INT Dn

Look for `Time until disconnect 1796 secs'

Andy

[mr7]

Hi aacole, thx

How about if A calls B, but only traffic from A to B without return traffic from site B should back to A site? In this case, B will no way to define interesting traffic and actively reset the ISDN call to A. But in this case, A will constantly been reset by B even A has continuously sending traffic?

Is there any way to define in called end so that whenever there is inbound traffic in called end (i.e. B), it will not regard the link as idle and reset the ISDN call? (even no outbound interesting traffic to A)

[Kevin Dorrell]

I have spoken to people in Cisco several times about this. I reckon it would be useful to define tha timeout according to who placed the call. In fact, in an ideal world it should be possible to configure it so that only the caller can take down the call for a timeout. But that's not the way it's done; it is based entirely on outbound traffic resetting the "interesting traffic" timer. :-(

Kevin Dorrell

Luxembourg

[aacole]

Im thinking if it may be possible to use the object tracking feature in 12.3.8(T) to assist with this.

Set A to send an SAA probe (ICMP echo) over the ISDN to B. On B configure the interesting traffic to match ICMP echo replies only. On A make sure that the ICMP echo is not defined as interesting.

The idea is that A calls B using say a TCP packet as interesting, when the link is up the traffic and the SAA probes go across the ISDN. Then the echo replies reset B's idle timer, so B never closes the link. That is done by A when there is no more interesting traffic to send, in this case TCP.

However, how usual is it to have unidirectional traffic?

Andy

[Kevin Dorrell]

That should work. It's quite a clever workaround; a sort of keepalive.

In answer to your last question ... very rare. With TCP you are practially guarenteed packets in both directions, UDP usually goes in pairs, as does ICMP. And those ICMP that don't go in pairs are usually not work keeping the line open for.

Kevin Dorrell

Luxembourg

[mr7]

Thx, Andy;

For the method you mentioned, am I need to define ICMP echo as interesting traffic at A? If yes then A will continuously activate the ISDN line even I have no TCP interesting traffic. If no, can you tell how can I make the router probes once the ISDN line activated without define echo as interesting? Can SAA perform this?

Also copy to Kevin Dorrell, in TCP, I think you're right, but it will be no way to keep the link up for one way UDP traffic.

Thanks all,

BBD

[aacole]

At A define the interesting traffic as that which will activate the line, eg TCP. So only TCP traffic in this scenario would activate the line, the ICMP SAA probes wont bring the line up. They will pass across once the line is activated though.

B will respond to the probes, so if his interesting traffic definition only matches the reply traffic his idle timer will never expire.

May need some tweaking to get this to work. There was quite a lot of information on object tracking in packet magazine 2nd quarter this year. The URL's are:

cisco.com/packet/162_4a1

cisco.com/packet/162_4a2

cisco.com/packet/162_4a3

Also, not mentioned in the articles, you need 12.38(T) or later IOS for some of the latest features.

Andy