RE: Dialer Watch [bcc][faked-from]

From: marvin greenlee (marvin@ccbootcamp.com)
Date: Mon Mar 14 2005 - 19:28:09 GMT-3


With legacy DDR, the map is needed for the watched route, and needs to match
the route. Which side is causing the link to flap? Often times, the remote
side will cause the link to flap if interesting traffic is not defined.

Cisco - ISDN/CHANNEL ASSOCIATED SIGNALLING Configuration Examples -
http://www.cisco.com/en/US/tech/tk801/tk379/tech_configuration_examples_list
.html

Cisco - Configuring DDR Backup using BRIs and Dialer Watch -
http://www.cisco.com/en/US/tech/tk801/tk379/technologies_configuration_examp
le09186a0080094143.shtml

Marvin Greenlee, CCIE#12237, CCSI# 30483
Network Learning Inc
marvin@ccbootcamp.com
www.ccbootcamp.com (Cisco Training)

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
simon hart
Sent: Monday, March 14, 2005 2:14 PM
To: Group Study
Subject: Dialer Watch [bcc][faked-from]
Importance: Low

Hi Group,

I am going over IE lab 11 (again), and am confused with the Dialer watch
setup.

Within this lab there is a requirement to watch a a number of routes
(150.1.3.3 being one of them) and bring up the ISDN if the routes are lost.
So far so good, however there is a dialer map statement i.e

dialer map ip 187.1.45.5 name Rack1R5 broadcast xxxxxx .............(normal
map statement)
dialer map ip 150.1.3.3 name Rack1R5 broadcast
xxxxxx................(additional map statment for dialer watch)

Why is this needed? Does this not cause more problems.

I have found that once the dialer watch is invoked because of the lost route
the ISDN link starts to flap.
After doing a an ip route debug it appears that the routing table will
install the 150.1.3.3 route as directly connected route because of the
dialer map statement. When the old route comes back on line, it is not
prefered because it is a route known via a routing protocol, however the
link will idle timeout after a set period, but will immediately come up
again because of the loss of the now directly connected route.

Any pointers appreciated

Simon
Simon

--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.2 - Release Date: 11/03/2005


This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:45 GMT-3