From: Mask Of Zorro (ciscokid00@xxxxxxxxxxx)
Date: Tue Apr 17 2001 - 12:45:13 GMT-3
Here we go again with the OSPF Demand Circuit thing again...
OK - you have an issue on the router where you have configured an OSPF
demand circuit over your ISDN link, but it keeps flapping up and down. The
issue is that this router is an ASBR between your OSPF domain and some other
routing protocol domain, let's say IGRP. On this ASBR you are performing
mutual redistribution - routes from OSPF are passed into IGRP, and routes
from IGRP are passed into OSPF.
On this particular ASBR with an OSPF Demand Circuit you have defined
interesting traffic which will bring up the ISDN link. Usually this
interesting traffic is anything IP. You test the link with a ping. The link
comes up, the pings are successful, and after the desgnated time-out period
the layer 2 link drops. The OSPF Demand Circuit configuration quiets the
LSA's that would normally keep the link up, so the link drops as desired.
Suddenly, the link comes back up again! Then after the timeout, it drops
again, and almost immediately comes right back up! Why?!?!?
Here's why - External LSA's are bringing up the link. These LSA's are the
result of a topology change. What change? The change that occurs whenever
the layer 2 ISDN link drops. Hmmm... The OSPF Demand Circuit is supposed to
let that link drop, so why is my OSPF process flooding type 5 LSA'a over the
link? It is learning about the change from another process! The IGRP process
notes the ISDN link dropping and is redistributing it's change into OSPF.
Think about this for a minute.
OK - now we know what is happening, how do we stop it. We COULD simply
eliminate OSPF traffic from what is interesting. In this case, OSPF LSA's
would no longer bring up the link. The problem is that OSPF LSA's would
NEVER bring up the link, even if a topology change occurs elsewhere in the
network and we want that change to reach the neighbor over the ISDN link.
This is not good...
What else can we do? If you consider the problem it becomes evident that we
really only want to stop LSA's from bringing up the link in one case: when
the ISDN link goes down. The solution, then, is to prevent the ISDN link
drop from turning into an OSPF LSA flood. Filter your redistribution such
that the OSPF process does not receive an update from your IGRP process
regarding THE ISDN LINK ONLY.
This will stop the flapping of the demand circuit without preventing other,
potentially important, topology changes from bringing up the link.
There are numerous practice labs available with examples of this, showing a
sample config in the answer key. CCBootCamp labs and SolutionLabs come to
mind.
So there you go - problem solved. Next!
Z
>From: "Chuck Larrieu" <chuck@cl.cncdsl.com>
>Reply-To: "Chuck Larrieu" <chuck@cl.cncdsl.com>
>To: "Rick Burts" <burts@mentortech.com>, "Jay Hennigan" <jay@west.net>
>CC: "Chris Mott" <cmott@home.com>, "CCIE" <ccielab@groupstudy.com>
>Subject: RE: External LSAs keeping ISDN line up!!!
>Date: Mon, 16 Apr 2001 17:20:36 -0700
>
>Isn't this where the IP OSPF demand circuit command comes into play?
>
>Chuck
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
>Rick
>Burts
>Sent: Monday, April 16, 2001 5:05 PM
>To: Jay Hennigan
>Cc: Chris Mott; CCIE
>Subject: RE: External LSAs keeping ISDN line up!!!
>
>Jay
>
>There is one aspect of your reasoning that I do not understand.
>Assuming your scenario: the dialer list will deny ospf as interesting
>traffic, and a ping brings up the line so adjacencies are formed and
>ospf routes are added to the table. What happens when the line has gone
>inactive and some link change generates an LSA which we need to
>transmit to the neighbor on the demand circuit but ospf cannot bring
>up the link because it is not interesting ? I think this may appear
>to work in a limited lab scenario but ultimately I think this is a
>broken implementation. I agree with Chris that the better
>implementation has ospf as interesting traffic in the dialer list.
>
>Rick
>
>Rick Burts, CCSI CCIE 4615 burts@mentortech.com
>Mentor Technologies 240-568-6500 ext 6652
>133 National Business Parkway 240-568-6515 fax
>Annapolis Junction, Md 20701
>
>Chesapeake Network Solutions has now become Mentor Technologies.
>Mentor Technologies is a certified Cisco Training Partner and also
>a Cisco Professional Services partner.
>We offer most of the Cisco training courses.
>We also offer training in Checkpoint Firewall software and
>Fore Systems (now Marconi) and MicroMuse.
>We also provide network consulting services including
>design, management, and problem solving.
>We have 20 CCIEs on our staff.
>We offer the breakthrough VLAB remote access technology for
>access to practice configuration on real equipment.
>
>On Sun, 15 Apr 2001, Jay Hennigan wrote:
>
> > On Sun, 15 Apr 2001, Chris Mott wrote:
> >
> > > I've never understood the reasoning behind a dialer-list that has
>"deny
>ospf
> > > any any", as I thought the whole reason for an OSPF demand-circuit was
>that
> > > OSPF could bring up the link if a routing decision deemed it necessary
>...
> > > please correct me if I'm wrong ...
> >
> > The dialer-list keeps the OSPF multicast traffic from bringing up the
>link,
> > but doesn't deny it from traversing the link. Once the link has been
> > established once (like by a ping), then the OSPF routes will be learned
> > and retained.
> >
> > Normal IP traffic destined for that link (if not denied by an access
> > list) will then bring up the dialer.
> >
> > --
> > Jay Hennigan - Network Administration - jay@west.net
> > NetLojix Communications, Inc. NASDAQ: NETX - http://www.netlojix.com/
> > WestNet: Connecting you to the planet. 805 884-6323
> > **Please read:http://www.groupstudy.com/list/posting.html
>**Please read:http://www.groupstudy.com/list/posting.html
>**Please read:http://www.groupstudy.com/list/posting.html
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:47 GMT-3