From: kym blair (kymblair@xxxxxxxxxxx)
Date: Wed Mar 06 2002 - 09:44:37 GMT-3
Merete,
1) Be sure to put "passive-interface bri0" under all your routing protocols
that are not suppose to go across the ISDN link.
2) If you are not required to keep the ISDN link in area 0, change it to
another area number, and set that area to a stub no-summary. That will
prevent the LSA summary advertisements from being multicast to 224.0.0.5
multicast.
3) If that is not allowed, set the ospf cost to a high number (Solie
suggests "ip ospf cost 9999") so the Frame Relay link is preferred.
4) You've already done "no peer neighbor-route"
5) Try removing authentication until you get this settled.
Good luck. Kym
>From: James.Irwin@us.didata.com
>Reply-To: James.Irwin@us.didata.com
>To: ccielab@groupstudy.com
>Subject: RE: flapping ospf demand circuit
>Date: Tue, 5 Mar 2002 21:30:26 -0500
>
>IOS 12.1(2), from what I understand is used in the lab and I have it on all
>my routers.
>With all of the suggestions listed so far, none of them have been
>effective.
>
>I found this caveat in release 12.1(2) on Cisco's website:
>
>*******************************************
>CSCdr06681
>
>If there is a link flap somewhere in the network between the area border
>router (ABR) and an autonomous system boundary router (ASBR), the ABR may
>not generate a type 4 summary ASBR link-state advertisement (LSA) to other
>areas after the link is restored. The net effect is that routes being
>redistributed by the ASBR into Open Shortest Path First (OSPF) will not be
>installed in the routing tables in the affected areas.
>
>
>Workaround: Restart OSPF on the ABR by using the clear ip ospf proc
>command.
>
>
>Alternate Workaround: On the ABR, restart OSPF for the affected areas only
>by removing and restoring the network statements under the router ospf
>global configuration command for the impacted areas.
>
>
>Alternate Workaround: For this workaround, perform the action only after
>the
>subject ASBR LSA has been removed from the database of the affected areas
>(no longer seen in the show ip ospf database EXEC command).
>
>
>On the affected OSPF routers (that are not seeing the routes and the ASBR
>LSA) adjacent to the ABR, reestablish adjacencies with the ABR. One way to
>temporarily change the hello-interval to some other value. After the
>adjacency is taken down, change the hello-interval back to the original
>value to reestablish the adjacency. This action causes the ABR to
>regenerate
>and resend the LSAs. On the ABR, create and temporarily remove a router
>ospf
>global configuration command (for example, router ospf 1234 and no router
>ospf 1234).
>
>********************************************
>
>Good luck,
>Jim
>
>
>
>-----Original Message-----
>From: Michael C. Popovich [mailto:mpopovich@layer3.biz]
>Sent: Tuesday, March 05, 2002 4:28 PM
>To: Louis Krucker; ccielab@groupstudy.com
>Subject: RE: flapping ospf demand circuit
>
>
>I think I remember reading that for ospf demand circuit you can't have
>Type 5 or Type 7 LSA's in the area. Does this sound right?
>If so, check your area configuration for the network on the demand
>circuit. Make sure that both sides of the router have the same area
>configuration.
>
>MP
>
>-----Original Message-----
>From: Louis Krucker [mailto:lkrucker@swissonline.ch]
>Sent: Tuesday, March 05, 2002 2:36 PM
>To: ccielab@groupstudy.com
>Subject: AW: flapping ospf demand circuit
>
>Hi,
>
>enter the command ip ospf network point-to-point on both bri's and it
>will
>work. By default this int is point to point but who knows why, IOS dont
>understand the default behavior.
>
>regards
>
>Louis
>
>
>
>-----Urspr|ngliche Nachricht-----
>Von: Jens Niklaus Fischer, IKOM Kommunikations- und Unternehmensberatung
>[mailto:jfischer@ikom.ch]
>Gesendet: Dienstag, 5. Mdrz 2002 17:42
>An: lkrucker@swissonline.ch
>Betreff: Re: flapping ospf demand circuit
>
>
>Hi,
>
>On the second router in bri i can not see any
>ppp authen chap .... (did you snip it ?)
>
>Or maybye you have some pbm with ospf authentication (usualy that make
>the
>link
>flapping till there is adjancies, and your routers don't seemes to build
>an
>adjacencies accross the bri).
>
>Best regards
>
> --- Merete Asak <merete@privat.sysedata.no> a icrit : > This is my
>scenario-lab:
> >
> > R2 is connected to a frame-relay cloud to R3. This connection does
>also
>have
> > a
> > ISDN between them where I have configured ip ospf demand circuit.
> > R2 is running IGRP as well and there is redistribution between OSPF
>and
>IGRP.
> > I
> > have done no peer neighbour-route on both the bri0 interfaces to make
>sure
> > that
> > there will be noe flapping in IGRP. I have done debugging, and IGRP is
>not
> > learning any routes as dead while the ospf demand circuit is flapping.
> > I have checked that all my routers have the demand circuit feature
>loaded
>as
> > well. THe bri0 is a point-to-point so there should not be a problem
>with
> > broadcast over the link (I have also seen this in the debug that
>broadcast
>is
> >
> > not brining up the link)
> > When I debug there is the ospf mulicast address 224.0.0.5 that is
>brining
>up
> > the link. There is no changes in the topology.
> >
> > The net of the frame-relay network is a /24 and the net for the ISDN
>is a
> > /30.
> > I have made a summary-address for this net as a /24 on the R2 so that
>the
> > IGRP-part of the network will learn about the ISDN-link.
> >
> > My R2 Bri0 configuration looks like this:
> > interface BRI0
> > ip address 133.3.35.1 255.255.255.252
> > encapsulation ppp
> > no ip route-cache
> > ip ospf message-digest-key 1 md5 cisco
> > ip ospf demand-circuit
> > no ip mroute-cache
> > dialer string 67839066
> > dialer-group 1
> > isdn switch-type basic-net3
> > no peer neighbor-route
> > no cdp enable
> > ppp authentication chap callin
> > ppp chap hostname bjarte
> > ppp chap password 7 070C285F4D06
> >
> > dialer-list 1 protocol ip list 102
> >
> > access-list 102 deny ip any host 255.255.255.255
> > access-list 102 permit ip any any
> >
> >
> > Router3 that I'm calling :
> >
> > interface BRI0
> > ip address 133.3.35.2 255.255.255.252
> > no ip directed-broadcast
> > encapsulation ppp
> > ip ospf message-digest-key 1 md5 cisco
> > ip ospf priority 0
> > dialer-group 1
> > isdn switch-type basic-net3
> > no peer neighbor-route
> > no cdp enable
> >
> > dialer-list 1 protocol ip permit
> >
> > Output of debug dialer and debug ip ospf event and lsa generation is:
> > (133.3.2.0 - loopback net on R2 133.3.3.0 is loopback net on R3)
> >
> > 21:30:08: OSPF: Send with youngest Key 1
> > 21:30:13: OSPF: Rcv hello from 133.3.7.7 area 0 from Serial0.2
>133.3.235.1
> > 21:30:13: OSPF: End of hello processing
> > 21:30:17: OSPF: Rcv hello from 133.3.3.3 area 0 from Serial0.2
>133.3.235.3
> > 21:30:17: OSPF: End of hello processing
> > R2#
> > R2#
> > 21:30:38: OSPF: Send with youngest Key 1
> > 21:30:43: OSPF: Rcv hello from 133.3.7.7 area 0 from Serial0.2
>133.3.235.1
> > 21:30:43: OSPF: End of hello processing
> > 21:30:47: OSPF: Rcv hello from 133.3.3.3 area 0 from Serial0.2
>133.3.235.3
> > 21:30:47: OSPF: End of hello processing
> > 21:31:03: OSPF: Generate external LSA 133.3.2.0, mask 255.255.255.0,
>type
>5,
> > age 0, metric 100, seq 0x80000020
> > 21:31:03: OSPF: Send with youngest Key 1
> > 21:31:03: BR0 DDR: ip (s=133.3.35.1, d=224.0.0.5), 160 bytes, outgoing
> > interesting (list 102)
> > 21:31:03: BR0 DDR: sending broadcast to default destination
> > 21:31:03: BR0 DDR: Dialing cause ip (s=133.3.35.1, d=224.0.0.5)
> > 21:31:03: BR0 DDR: Attempting to dial 67839066 -- failed, not
>connected
> > 21:31:03: OSPF: Send with youngest Key 1
> > 21:31:04: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 83 changed
>to
>up
> > 21:31:05: %LINK-3-UPDOWN: Interface BRI0:2, changed state to up
> > 21:31:06: %LINK-3-UPDOWN: Interface BRI0:2, changed state to down
> > 21:31:06: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
> > 21:31:07: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
>changed
> > state
> > to up
> > 21:31:08: OSPF: Send with youngest Key 1
> > 21:31:08: OSPF: Send with youngest Key 1
> > 21:31:08: BR0 DDR: ip (s=133.3.35.1, d=224.0.0.5), 160 bytes, outgoing
> > interesting (list 102)
> > 21:31:08: BR0 DDR: sending broadcast to default destination
> > 21:31:12: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to
>67839066
> > 21:31:13: OSPF: Rcv hello from 133.3.7.7 area 0 from Serial0.2
>133.3.235.1
> > 21:31:13: OSPF: End of hello processing
> > 21:31:17: OSPF: Rcv hello from 133.3.3.3 area 0 from Serial0.2
>133.3.235.3
> > 21:31:17: OSPF: End of hello processing
> > 21:32:43: OSPF: Rcv hello from 133.3.7.7 area 0 from Serial0.2
>133.3.235.1
> > 21:32:43: OSPF: End of hello processing
> > 21:32:47: OSPF: Rcv hello from 133.3.3.3 area 0 from Serial0.2
>133.3.235.3
> > 21:32:47: OSPF: End of hello processing
> > 21:33:08: OSPF: Send with youngest Key 1
> > 21:33:13: OSPF: Rcv hello from 133.3.7.7 area 0 from Serial0.2
>133.3.235.1
> > 21:33:13: OSPF: End of hello processing
> > 21:33:17: OSPF: Rcv hello from 133.3.3.3 area 0 from Serial0.2
>133.3.235.3
> > 21:33:17: OSPF: End of hello processing
> > 21:33:38: OSPF: Send with youngest Key 1
> > R2#
> > R2#
> > 21:33:43: OSPF: Rcv hello from 133.3.7.7 area 0 from Serial0.2
>133.3.235.1
> > 21:33:43: OSPF: End of hello processing
> > 21:33:44: %ISDN-6-DISCONNECT: Interface BRI0:1 disconnected from
>67839066
>,
> > call lasted 158 secpf lsa
> > 21:33:44: %LINK-3-UPDOWN: Interface BRI0:1, changed state to down
> > 21:33:45: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1,
>changed
> > state
> > to down
> > 21:33:47: OSPF: Rcv hello from 133.3.3.3 area 0 from Serial0.2
>133.3.235.3
> > 21:33:47: OSPF: End of hello processing
> > 21:34:00: %ISDN-6-LAYER2DOWN: Layer 2 for Interface BR0, TEI 83
>changed to
> > down
> > 21:34:08: OSPF: Send with youngest Key 1
> > 21:34:13: OSPF: Rcv hello from 133.3.7.7 area 0 from Serial0.2
>133.3.235.1
> > 21:34:13: OSPF: End of hello processing
> >
> > What am I missing?
> > Anyone?
> >
> > Merete
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:56:54 GMT-3