Re: How Dialer Watch Actually Works

From: ccie2be (ccie2be@nyc.rr.com)
Date: Tue Jul 06 2004 - 09:40:14 GMT-3

Next message: Kenneth Wygand: "RE: dhcp default-router"
Previous message: Asep Ruhimat: "RE: Trunking dot1Q between catalyst and Bay 350T"
Maybe in reply to: Kenneth Wygand: "How Dialer Watch Actually Works"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Hey Ken,

What a great explanation. You've completely addressed my concern which was
to account for all the time between when the primary links go down and when
dialer watch kicks in. I wasn't sure that the only default delay was how
long it takes for the routing protocol to flush the routes from the route
table. But, now it's clear I only need to be able to determine that time
period for each protocol and how to adjust those times as required.

thanks, tim

----- Original Message -----
From: "Kenneth Wygand" <KWygand@customonline.com>
To: "ccie2be" <ccie2be@nyc.rr.com>; "Group Study" <ccielab@groupstudy.com>
Sent: Monday, July 05, 2004 9:41 PM
Subject: How Dialer Watch Actually Works

Hey Tim,

The dialer watch implementation actually creates a virtual "interface", the
up/down status of which is dependent on the existance of one of a set of
particular routes in the routing table. There is no polling interval or
similar activity to check the status of the route. Consider the situation
that dialer watch is configured to watch route a set of routes listed in the
dialer watch-list. I don't know (nor would I be allowed to disclose)
Cisco's proprietary implemention of how it is done behind the scenes, but
for arguments sake, say a virtual interface is created
"Interface_Watched_Routes". The status of the interface has some logical
pointers to active routes in the routing table. Certain "if / then"
criteria must be performed to maintain accurate up/down status of this
interface, while dialer-watch just looks to see if the
"Interface_Watched_Routes" is down or up. It's basically a layered approach
(does OSI model come to mind again? :). When this virtual interface goes
down, the "dial now trigger" is sent to the dialer-watch process, which will
dial immediately (as soon as resources are available and the necessary
internal processing takes place). Again, this "immediately" is only in
absense of non-default "dialer watch connect delay" configuration.

The decision tree to determine the up/down status of the
"Interface_Watched_Routes" is something similar to the following (keeping in
mind that multiple routes can be listed in the dialer watch-list).

1) Check the IP Routing table for the existence of the first route in the
dialer watch-list.
2a) If the route exists in the IP routing table, go to step 2b. If the
route does not exist, check the next route in the dialer watch-list and
perform step 2a again. If there are no routes remaining in the dialer
watch-list, go to step 3.
2b) Check to see what the next-hop interface is for the route. If the
next-hop interface is any interface other than the interface on which dialer
watch is configured, the "Interface_Watched_Routes" interface should be put
in the UP state. If the next-hop interface for the watched route -IS- the
interface on which dialer watch is configured, check to see if there are
more routes listed in the dialer watch-list. If there are more routes listed
in the dialer watch-list, perform step 2a on the next route in the list. If
there are no more routes listed in the dialer watch-list, proceed to step 3.
3) Since all routes listed in the dialer watch-list are not available via
any interfaces other than the interface on which dialer watch is configured,
the "Interface_Watched_Routes" interface should be put in DOWN status.

This process is somehow tied internally into the IP routing table, so it is
not polled at certain intervals. Whenever the routing table changes, this
check is performed. This is also the same check that is performed at
expiration of the "dialer idle-timeout" when the backup interface is active.

Hope this helps clarify some things,
Ken

________________________________

From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Mon 7/5/2004 9:06 PM
To: Kenneth Wygand; Group Study
Subject: Re: Dialer Watch

Hey Ken,

Thanks for that very thorough explanation. However, there's still one
detail I don't understand.

How does dialer watch know when a route is no longer in the route table.

I can imagine only 2 possibilities:

a) Some type of s/w process *informs* dialer watch that a watched route has
been removed from the route table.
b) Dialer Watch checks the route table periodically to see if the route is
still there.

Between these 2 possibilities, I certainly don't know for sure, but it would
seem to me that if dialer watch checks
periodically to see if a route has returned to the route table, it would
probably check periodically to see if the route
has been removed from the route table in the first place.

On the other hand, if it's true that dialer watch triggers a call
*immediately* once a route is flushed form the route table, then it seems
like there must be some mechanism through which dialer watch is informed
that a route of interest has been flushed from the route table.

Below you stated out that once a route is flushed from the route table,
dialer watch *immediately* triggers a call. How do you know that? And, how
immediate is immediate? (Note that I'm not looking for a specific answer
like 17.2 ms, but rather an explanation of the interaction between the time
a watched route is flushed from the route table and dialer watch triggering
a call.)

Thanks again for the great explanation.

Tim

Tim,

There are a total of three timers associated with Dialer Watch:

1) Idle-timeout - this is how often the routing table is checked to see if
the watched route has returned to the IP routing table. Essentially this
checks to see what next-hop interfaces are available to the watched route
and if there is a route available using an alternate interface, it will
trigger a disconnect request for the ISDN circuit. This is not an immediate
disconnect, rather a request that must still pass through the "dialer
watch-disable" command. It should also be noted that an "alternate
interface" should be understood as any interface other than the one on which
the dialer-watch feature is configured.

2) dialer watch-disable - this is how long the ISDN circuit should stay
active after receiving a disconnect request due to reachability to the
watched route into the IP routing table. Note that this timer will only
start after receiving notification that the primary route has returned,
which is only checked at expiration of the idle-timeout.

3) dialer watch connect delay (12.2(8)T) - this is how long the router will
wait to dial the backup circuit once the watched route has been removed from
the IP routing table. At the end of this timer, the IP routing table is
checked again to see if the route has returned. If not, the backup interface
is kicked in and the idle-timeout starts.

Your question pertains to the new "dialer watch connect delay" command. If
this command is not configured, the ISDN circuit is dialed immediately after
the watched routes are removed from the IP routing table. This command
allows routing protocols to converge to determine if your IGP can find an
alternate route to the watched network.

The following are the sequence of events as per the Doc CD:

1. Whenever a watched route is deleted, Dialer Watch checks whether there is
at least one valid route for any of the defined watched IP addresses.
2. If no valid route exists, the primary line is considered down and
unusable.
3. If a valid route exists for at least one of the defined IP addresses and
if the route is pointing to an interface other than the backup interface
configured for Dialer Watch, the primary link is considered up.
4. If the primary link goes down, Dialer Watch is immediately notified by
the routing protocol and the secondary link is brought up.
5. Once the secondary link is up, at the expiration of each idle timeout,
the primary link is rechecked.
6. If the primary link remains down, the idle timer is indefinitely reset.
7. If the primary link is up, the secondary backup link is disconnected.
Additionally, you can set a disable timer to create a delay for the
secondary link to disconnect, after the primary link is reestablished.

Note that step 4 indicates that the ISDN circuit is immediately brought up
when the watched route disappears. Of course, since this is 12.2
documentation, it doesn't account for the "dialer watch connect delay"
command
(http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/12
2t/122t8/ftdialwl.htm)

Now I will answer your other direct questions inline:

In addition, once the dialer watch has triggered a call, I know that dialer
watch checks the route table everytime the dialer idle-timeout expires.

But, what about before dialer watch has triggered a call? How often does
dialer watch check the route table in this case?

***Immediately, see description above.

I assume that the dialer idle-timeout timer isn't active before isdn has an
active call. Is this true?

***True

Here's the problem.

Let's say I want dialer watch to trigger a call in the shortest amount of
time
possible.

Depending the routing protocol being used, what is the shortest amount of
time?

***Immediately, this is default without using the "dialer watch connect
delay" command.

Hope this helps!
Ken

________________________________

From: nobody@groupstudy.com on behalf of ccie2be
Sent: Mon 7/5/2004 4:55 PM
To: Group Study
Subject: Dialer Watch

Hi guys,

Assume dialer watch is configured to trigger an isdn call if the primary
connection goes down.

It seems to me that there are 2 time intervals that determine how long after
the primary connection goes down dialer watch kicks in:

a) how often dialer watch checks the route table for the watched route and

b) how long after the primary connection goes down before a route learned
via
the primary connection is removed from the route table.

So far, does everyone agree with this?