From: Nnanna Obuba (obuba@xxxxxxxxx)
Date: Thu Sep 21 2000 - 16:21:53 GMT-3
It's not stopped by split-horizon cos the 2 protocols
run on the same router (where redisribution is
configured)
Nnanna
--- "Connary, Julie Ann" <jconnary@cisco.com> wrote:
> forgive me if I missed something, but it appears
> that this is a
> route-feedback problem and what
> you are doing is not allowing the "re-distribution"
> of the 172.17.2.240
> network back into OSPF from
> IGRP. But why is this not stopped by split-horizon
> anyways? Also where is
> the interface with network
> 20 that you are routing igrp? And why are you
> running igrp on network
> 172.17.0.0 if you made
> all the interfaces passive?
>
> Just trying to understand why this works at all - I
> guess I'll have to go
> to the lab and hook it up.
>
> Julie Ann
>
>
> At 09:03 AM 9/21/2000 -0700, Kevin Baumgartner
> wrote:
> >I think I have solved the problem. I have set my
> routers to be as close
> >as possible to what you where doing.
> >
> >IGRP
> > \ AREA 2
> AREA 3
> > R1----s0/0-----------------------------
> s0/0 ---- R2---e0/0
> > ------- e0/0 ---- R4
> > A | |
> |
> > R | | AREA 2
> |
> > E | -----BRI2/0 ------------------------
> BRI1/0 --
> > A |
> > 0 |
> > R3
> >
> >So the first thing I tried was defining the OSPF
> virtual-link on R1 and R2
> >for Area3
> >with OSPF demand circuit. It worked as expected.
> The ISDN line would come up
> >once to do a topology update and then the line
> would go down and stay down.
> >
> > The next step was to try redistributing IGRP
> into OSPF on R1. This
> > caused the
> >line to always stay up. As soon as the dialer
> timeout expired it would
> >call again.
> >
> > So I did some debugging to see what was
> happening
> >
> >debug dialer
> >debug ip ospf lsa-generation
> >
> >And I saw a message of "Generating external LSA for
> 172.17.2.253
> >255.255.255.255 Type 5"
> >
> >So I created a route-map that deny any
> redistribution of the 172.17.2.240
> >(ISDN Network) into OSPF.
> >Worked like a charm. The ISDN link stayed down and
> only came up when I
> >took the Serial link down.
> >Still a little fussy what happening here with
> redistribution and OSPF
> >demand circuits but my theory
> >is that OSPF demand circuits only suppress internal
> LSA's not external
> >LSA's. Hence the need for
> >this route filter as redistributing other routing
> protocols into OSPF is
> >going to generate external LSA
> >updates.
> >
> > Configurations
> >
> > R1
> >
> > interface Ethernet0/0
> > ip address 172.17.1.3 255.255.255.240
> >!
> >interface Serial0/0
> > bandwidth 2000
> > ip address 172.17.2.1 255.255.255.240
> > clockrate 2000000
> >!
> >interface BRI2/0
> > bandwidth 56
> > ip address 172.17.2.254 255.255.255.240
> > encapsulation ppp
> > ip ospf demand-circuit
> > dialer map ip 172.17.2.253 name R2 broadcast
> 87772002
> > dialer-group 1
> > isdn switch-type basic-5ess
> > ppp authentication chap
> >!
> >username R2 password cisco
> >dialer-list 1 protocol ip permit
> >!
> >router ospf 1
> > area 0 range 172.17.1.0 255.255.255.0
> > area 2 range 172.17.2.0 255.255.255.0
> > area 2 virtual-link 172.17.3.1
> > redistribute igrp 1 metric 1 subnets route-map
> igrp-ospf
> > passive-interface TokenRing1/0
> > network 172.17.1.3 0.0.0.0 area 0
> > network 172.17.2.1 0.0.0.0 area 2
> > network 172.17.2.254 0.0.0.0 area 2
> > network 172.17.193.1 0.0.0.0 area 0
> >!
> >access-list 1 permit 172.17.2.240 0.0.0.15
> >access-list 2 permit any
> >!
> >route-map igrp-ospf deny 10
> > match ip address 1 <<<<<
> Deny sending LSA external
> > onto ISDN.
> >!
> >route-map igrp-ospf permit 20
> > match ip address 2
> >!
> >
> >router igrp 1
> > redistribute ospf 1 metric 10000 200 255 1 1500
> > passive-interface Ethernet0/0
> > passive-interface Serial0/0
> > passive-interface BRI2/0
> > network 20.0.0.0
> > network 172.17.0.0
> >!
> >ip classless
> >
> >R2
> >----
> >
> >interface Ethernet0/0
> > ip address 172.17.3.1 255.255.255.252
> >!
> >interface Serial0/0
> > bandwidth 2000
> > ip address 172.17.2.2 255.255.255.240
> >!
> >interface BRI1/0
> > bandwidth 56
> > ip address 172.17.2.253 255.255.255.240
> > encapsulation ppp
> > ip ospf demand-circuit
> > dialer map ip 172.17.2.254 name R1 broadcast
> 87772001
> > dialer-group 1
> > isdn switch-type basic-5ess
> > ppp authentication chap
> >!
> >username R1 password cisco
> >dialer-list 1 protocol ip permit
> >!
> >router ospf 1
> > area 2 virtual-link 172.17.2.254
> > network 172.17.2.2 0.0.0.0 area 2
> > network 172.17.2.253 0.0.0.0 area 2
> > network 172.17.3.1 0.0.0.0 area 3
> >
> >
> >
> >
> >At 05:26 PM 9/20/00 -0700, you wrote:
> > >That's correct. It is very close to a real lab
> > >scenario according to some romours I heard.
> > >
> > >An the thing is, I had it working once. This time
> it
> > >doesn't work.
> > >
> > >Sam
> > >--- Daniel Keller <DMKeller@comdisco.com> wrote:
> > > > The problem is that area 2 is a virtual link.
> > > > Because of this, LS updates will always keep
> the
> > > > line dialing. Can you place the bri
> connections
> > > > into a different area? If not you will need
> to find
> > > > an alternative, such as using backup
> interface. Is
> > > > this from a lab that you have?
> > > >
> > > > Dan Keller
> > > >
> > > > >>> Sam Munzani <smunzani@yahoo.com> 09/20/00
> > > > 05:50PM >>>
> > > > Hi Group,
> > > >
> > > > I have attached my configs with e-mail. Tell
> me what
> > > > am I doing wrong? ISDN keeps flapping.
> Scenario is
> > > > as
> > > > below.
> > > >
> > > > Grumpy--(Bri 0) ------ (Bri 0 )-- Sleepy
> > > >
> > > > The BRI link is in OSPF area 2. I used OSPF
> demmand
> > > > circuit and also used no peer neighbor route.
> > > > Bandwidth is not specified on serial link so
> it will
> > > > be default T1 for frame link.
> > > >
> > > > I have also attached "ip ospf data" results on
> each
> > > > router. I had it working some time ago but
> this time
> > > > it doesn't work.
> > > >
> > > > Rather than throwing some hints please justify
> > > > proper
> > > > methodology for this configuration. I am sure
> > > > everybody will get hit by this scenario in
> some
> > > > flavor
> > > > so it is important.
> > > >
> > > > Sam
> > > >
> > > >
> > > > --- Daniel Keller <DMKeller@comdisco.com>
> wrote:
> > > > > Because the BRI's are in area 0, OSPF
> updates will
> > > > > constantly be triggering the ISDN line. How
> do
> > > > you
> > > > > keep this line from always coming up?
> > > > >
> > > > > >>> Kevin Baumgartner <kbaumgar@cisco.com>
> > > > 09/19/00
> > > > > 09:42PM >>>
> > > > > Why do say that OSPF demand circuit won't
> cut it?
> > > > > The key to using demand circuit is
> > > > >
> > > > > 1. Define the bandwidth on the BRI
> interface to
> > > > be
> > > > > less that serial interface
> > > > > 2. If doing any redistribution on either of
> the
> > > > BRI
> > > > > routers
> > > > > filter such that IP subnet between the
> two BRI
> > > > > router
> > > > > interfaces doesn't get redistributed. If
> you
> > > > let
> > > > > this route
> > > > > through the BRI interface will flap
> because of
> > > > > routing updates.
> > > > > 3. Define OSPF demand circuit on only one
> router
> > > > > (optional).
> > > > >
> > > > > The other two methods to do this is like you
> said
> > > > > dialer watch-list
> > > > > and backup interface.
> > > > >
> > > > > Kevin
> > > > >
> > > > >
> > > > > >
> > > > > > Hey bud, got a good config for the
> following ?
> > > > > >
> > > > > > s0 & bri0 are in the same area 0 of OSPF
> > > > > >
> > > > > > what's a good dial backup config for this
> for
> > > > when
> > > > > s0 goes down without bri0
> > > > > > flapping? demand circuit doesn't seem to
> cut
> > > > it,
> > > > > floating statics are out of
> > > > > > the question, leaving only dialer
> watch-list
> > > > (IOS
> > > > > 12.3 & higher) or backup
> > > > > > interface - but what other way is there if
> any
> > > > !?
> > > > > >
> > > > > >
> > > > > > Mike L. Chase
> > > > > > Sr. Network Architect
> > > > > > ISG: Information Services Group
> > > > > > Broadcom Corporation World Headquarters,
> BLDG
> > > > > A-1050
> > > > > > 16215 Alton Parkway, Irvine, California
> > > > > 92618-3616
> > > > > >
> > > > >
> > > >
> >
>
>OFFICE:949-585-6057|CELL:949-283-4254|FAX:949-585-6227
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: nobody@groupstudy.com
> > > > > [mailto:nobody@groupstudy.com]On Behalf Of
> > > > > > Kevin Baumgartner
> > > > > > Sent: Tuesday, September 19, 2000 7:10 PM
> > > > > > To: Steve McNutt
> > > > > > Cc: ccielab@groupstudy.com
> > > > > > Subject: Re: Hello, new on list
> > > > > >
> > > > > >
> > > > > > Yes in theory ISDN is simple but I would
> be
> > > > able
> > > > > to do the following
> > > > > > and have practiced the following on
> routers.
> > > > > >
> > > > > > 1. OSPF on demand circuit
> > > > > > 2. Dial backup
> > > > > > 3. Appletalk over ISDN (and how to filter
> so
> > > > ISDN
> > > > > is not up all the time)
> > > > > > 4. IPX over ISDN (also how to filter so
> ISDN is
> > > > > not up all the time)
> > > > > > 5. Dialer watch
> > > > > > 6. PPP Multilink
> > > > > > 7. PPP CHAP/PAP
> > > > > > 8. PPP Callback
> > > > > > 9. Snapshot routing
> > > > > >
> > > > > > Kevin
> > > > > >
> > > > > > >
> > > > > > > practice ISDN? ISDN is pretty simple to
> > > > > configure and troubleshoot. DOD
> > > > > > > routing using rotary groups and dialer
> > > > profiles
> > > > > gives me fits though hehe.
> > > > > > > If you don't build your configs in the
> correct
> > > > > order the dialer interfaces
> > > > > > > never seem to work right.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: nobody@groupstudy.com
> > > > > [mailto:nobody@groupstudy.com]On Behalf Of
> > > > > > > Kevin Baumgartner
> > > > > > > Sent: Tuesday, September 19, 2000 9:30
> PM
> > > > > > > To: jix@netrue.com
> > > > > > > Cc: ccielab@groupstudy.com
> > > > > > > Subject: Re: Hello, new on list
> > > > > > >
> > > > > > >
> > > > > > > If you don't practice ISDN, ATM or FR
> you
> > > > have
> > > > > no chance of passing.
> > > > > > > They have to be part of your practice
> lab.
> > > > > > >
> > > > > > > Kevin
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> >
>
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:25:00 GMT-3