From: marvin greenlee (marvin@ccbootcamp.com)
Date: Tue Mar 01 2005 - 22:38:19 GMT-3
Another point to keep in mind is the difference between Dialer Watch and
Backup Interface.
Dialer watch will dial when the watched route disappears, regardless of what
is defined as interesting traffic.
Backup Interface will make the BRI interface available for use, but is still
dependent on interesting traffic for the line to be brought up.
If, for example, the requirement stated that only DLSW and the routing
protocol traffic could bring the line up, I would lean towards Backup
Interface over Dialer Watch.
Cisco - DIALER WATCH -
http://www.cisco.com/en/US/tech/tk801/tk133/tk161/tech_protocol_home.html
"...Dialer Watch is a backup feature that integrates dial backup with
routing capabilities. Dialer Watch provides reliable connectivity without
relying solely on defining interesting traffic to trigger outgoing calls at
the central router. Hence, dialer watch also can be considered regular DDR
with no requirement for interesting traffic, just lost routes. By
configuring a set of watched routes that define the primary interface, you
are able to monitor and track the status of the primary interface as watched
routes are added and deleted..."
Marvin Greenlee, CCIE#12237, CCSI# 30483
Network Learning Inc
marvin@ccbootcamp.com
www.ccbootcamp.com (Cisco Training)
-----Original Message-----
From: ccie2be [mailto:ccie2be@nyc.rr.com]
Sent: Tuesday, March 01, 2005 3:43 PM
To: marvin greenlee; John Murphy
Cc: Group Study
Subject: RE: dlsw and backup [bcc][faked-from]
Marvin,
Thanks for jumping in and for reminding me again of the basics. It's always
good to keep the basics in mind.
Perhaps I'm just confusing myself and over thinking this thing.
There are 2 conditions I'm trying to meet to have the isdn link brought up.
1. The primary link is down and
2. There's dlsw traffic that has to cross
The way I understand it, dlsw will always try to establish a peering once
the remote peer statement is configured - even if there's no dlsw traffic to
send.
So, once one of those methods (ospf demand circuit, dialer watch, etc)
releases the isdn interface to bring up the isdn circuit, because dlsw is
defined as interesting, the isdn link will come up.
One potential solution to this problem is perhaps to use the dynamic keyword
in the remote peer statement, but if there's only one remote peer, the
dynamic keyword will apply regardless of whether the primary link is being
used or the isdn link is being used. Ideally, dynamic should only apply
when the isdn link is used.
But, here's something good I realize from this discussion.
Just because isdn is being used for backup doesn't mean that the backup
keyword should be used in the remote peer statement.
I guess I again made a bad assumption.
Any thought?
Tim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
marvin greenlee
Sent: Tuesday, March 01, 2005 6:13 PM
To: 'ccie2be'; John Murphy
Cc: Group Study
Subject: RE: dlsw and backup [bcc][faked-from]
Interesting traffic defines what traffic can bring the link up. The router
would still need to make a routing decision to send the traffic out that
interface.
Routing decision - Which interface do I need to send this traffic out of?
Dialing decision - can I dial because of this traffic?
Both conditions need to be met in order to bring up the ISDN line. If only
one is met, the router will not dial. Unless you have routes learned over
the BRI, the ISDN will not be the path in the routing table, and DLSW
traffic would not be routed out the BRI interface.
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
ccie2be
Sent: Tuesday, March 01, 2005 2:54 PM
To: John Murphy
Cc: Group Study
Subject: RE: dlsw and backup [bcc][faked-from]
Importance: Low
Hey John,
I don't know about that.
With dlsw traffic defined as interesting, I think the isdn link will be
coming up and going down all the time.
I think the dlsw remote-peer 0 tcp <bkup ip addr of R2> backup-peer < pri ip
addr of R2> is required because that prevents dlsw from trying to use the
backup path when the primary is up. Without this command and with dlsw
defined as interesting, what stops dlsw traffic from bringing up the isdn
link?
Unless maybe because the metric over the f/r link is better, the isdn link
won't be used until the f/r goes down. As I said, I'm not too sure about
this one.
Tim
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of John
Murphy
Sent: Tuesday, March 01, 2005 5:28 PM
To: ccie2be
Cc: Group Study
Subject: Re: dlsw and backup
How about just using the ethernet addresses?
R1(config)dlsw local-peer peer-id 11.1.1.1
R1 (config) dlsw remote-peer 0 22.2.2.2
Frame goes down, ISDN comes up, IGP reconverges, dlsw circuit comes back
up across ISDN link.
Or did I miss something - aside from assuming your ethernets are in your
IGP?
jm
ccie2be wrote:
>Hi guys,
>
>
>
>Here's a simple dlsw scenario that I'm not sure how to configure. Any
>ideas?
>
>
>
>R1 <--> R2 have 2 links between them: 1 f/r and 1 isdn
>
>
>
>
>
>I want R1 to use the isdn link if the f/r link goes down.
>
>
>
>Both R1 and R2 need to pass dlsw traffic from their single LAN interface
>across the ip cloud.
>
>
>
>
>
>Here are the ip addresses being used:
>
>
>
>R1:
>
>
>
>lo0 = 1.1.1.1
>
>
>
>E0 = 11.1.1.1
>
>
>
>R2:
>
>
>
>Lo0 = 2.2.2.2
>
>
>
>E0 = 22.2.2.2
>
>
>
>f/r = 12.0.0.0
>
>
>
>isdn = 21.0.0.0
>
>
>
>
>
>My problem is that I can't figure out what addresses I should use with
which
>commands.
>
>
>
>Assume a single routing protocol and both routers know how to reach all ip
>addresses when the f/r is up.
>
>
>
>And, assume that only dlsw traffic is defined as interesting. If possible,
>also assume that R2 is configured as promiscuous.
>
>
>
>I know I need to use the following commands on R1:
>
>
>
>dlsw remote-peer 0 tcp <pri ip addr of R2>
>
>dlsw remote-peer 0 tcp <bkup ip addr of R2> backup-peer < pri ip addr of
R2>
>
>
>
>But, I'm not sure what addresses I should use.
>
>
>
>Also, note that once the primary f/r link goes down, both R1 and R2 won't
>know what networks are reachable on the other side of the isdn link until
>the isdn link comes up and the routing protocol reconverges. (As usual,
>static routes aren't allowed.)
>
>
>
>Any suggestions?
>
>
>
>TIA, Tim
>
>_______________________________________________________________________
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sun Apr 03 2005 - 17:56:38 GMT-3