From: Curtis Lindsay (clindsay_98@xxxxxxxxx)
Date: Wed Apr 18 2001 - 18:30:04 GMT-3
Your problem is simple to solve. Make sure that your
external LSAA'a do not show up as internal LSA's as
well. If you are doing redistribution from ospf into
igrp and vice versa with out filtering connected
routes you will have that problem. For example:
interface s0.1111 multipoint
ip address 172.16.10.1 255.255.255.0
frame-relay map ip 172.16.10.2 102 broadcast
frame-relay map ip 172.16.10.3 103 broadcast
interface s0.1112 point-to-point
ip address 172.16.11.1 255.255.255.0
frame-relay intf-dlci 104
router ospf 100
Redistribute igrp 100 metric-type 1 route-map igrp
network 172.16.10.1 0.0.0.0 area 0.0.0.0
router igrp 100
redistribute ospf 100 1544 20000 255 1 1500 route-map
ospf
network 172.16.0.0
route-map igrp
match ip address 1
access-list 1 deny 172.16.10.0 0.0.0.255
access-list 1 permit any
A distance vector protocol will put every subnet that
is within the classful boundary in your network
statement as in the above example.
Do a show ospf database and make sure you do not have
an internal lsa that shows up as an external as well.
This will cause the isdn to bounce.
Curtis Lindsay
CCIE #7047
--- daneyon hansen <daneyonhansen@hotmail.com> wrote:
> Never mind I completely understand what u are
> saying....Thanks!
>
>
>
> Daneyon
>
> Never >From: "Mask Of Zorro" >Reply-To: "Mask Of
> Zorro" >To:
> chuck@cl.cncdsl.com, burts@mentortech.com,
> jay@west.net >CC:
> cmott@home.com, ccielab@groupstudy.com >Subject: RE:
> External LSAs
> keeping ISDN line up!!! >Date: Tue, 17 Apr 2001
> 11:45:13 -0400 > >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" >>Reply-To: "Chuck Larrieu" >>To: "Rick
> Burts" , "Jay Hennigan"
> >> >>CC: "Chris Mott" , "CCIE" >>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:49 GMT-3