From: David Russell (drussell@xxxxxxxxxxx)
Date: Mon Mar 13 2000 - 16:04:54 GMT-3
Here is my WAT (wild ... theory):
when the ISDN link goes down IGRP detects it and tells OSPF which decides
that there is a topology change and so must send the info to the remote
router which causes the link to come up again.
Dave
-----Original Message-----
From: Paul Martinez <pmartinez@tns-inc.com>
To: ccielab@groupstudy.com <ccielab@groupstudy.com>
Date: Monday, March 13, 2000 7:04 AM
Subject: RE: ISDN and NSSA - Solved!
But shouldn't Router A receive the redistributed IGRP routes
over both S0 and the Dialer int. from router B?
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> Ronald Johnson
> Sent: Sunday, March 12, 2000 10:41 PM
> To: ccielab@groupstudy.com
> Subject: ISDN and NSSA - Solved!
>
>
>
> I think I understand what you're saying. Router A is receiving
> redistributed
> IGRP routes from Router B via interface Serial 0. Router A in turn feels
> like it needs to advertise those routes back to Router B via the dialer
> interface. There is evidence that reinforces this theory. When I shutdown
> the Serial 0 interface on Router A, the problem dissappears. The
> Demand-circuit command operates as it should by suppressing the
> hello's, yet
> the router is actually sending an UPDATE back to router A over
> the ISDN link
> and not a mere "hello" as the "show dialer" command suggests:
>
> 3-R3-2516-1#sh dialer
>
> BRI0 - dialer type = ISDN
>
> Dial String Successes Failures Last called Last status
> 0 incoming call(s) have been screened.
> 0 incoming call(s) rejected for callback.
>
> BRI0:1 - dialer type = ISDN
> Idle timer (90 secs), Fast idle timer (20 secs)
> Wait for carrier (30 secs), Re-enable (15 secs)
> Dialer state is data link layer up
> Dial reason: ip (s=192.168.3.13, d=224.0.0.5) << makes you think it's a
> regular hello
> Interface bound to profile Dialer0
> Time until disconnect 71 secs
> Current call connected 00:00:26
> Connected to 8358662 (5-R5-2516-2)
>
> After enabling OSPF debug commands the truth became apparent. The link was
> indeed kicked up due to a routing loop.
> Router A was trying to advertise routes it had learned from Router B (over
> the frame relay link) back to Router B
> through the ISDN connection:
>
> 1w5d: OSPF: rcv. v:2 t:4 l:64 rid:192.168.5.1
> aid:0.0.0.0 chk:0 aut:2 keyid:1 seq:0x1FB22 from Serial0
> 1w5d: OSPF: received update from 192.168.5.1, Serial0 << received from
> Serial 0
> 1w5d: OSPF: Rcv Update Type 5, LSID 192.168.3.13, Adv rtr 192.168.5.1, age
> 3600, seq 0x80000015
> 1w5d: Mask /32
> 1w5d: OSPF: Sending update on Dialer0 to 224.0.0.5 << update then
> advertised
> out Dialer 0!
> 1w5d: OSPF: Send Type 5, LSID 192.168.3.13, Adv rtr 192.168.5.1, age 3600,
> seq 0x80000015
> 1w5d: OSPF: Send with youngest Key 0
> 1w5d: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 93 changed to up
> 1w5d: %ISDN-6-LAYER2UP: Layer 2 for Interface BR0, TEI 94 changed to up
> 1w5d: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
> 1w5d: %DIALER-6-BIND: Interface BRI0:1 bound to profile Dialer0
> 1w5d: %ISDN-6-CONNECT: Interface BRI0:1 is now connected to 8358662
> 1w5d: OSPF: Sending delayed ACK on Serial0
> 1w5d: OSPF: Ack Type 5, LSID 192.168.3.13, Adv rtr 192.168.5.1, age 3600,
> seq 0x80000015
> 1w5d: OSPF: Send with youngest Key 1
>
> A problem like this may cost someone the lab exam. This goes to show how
> valuable this
> list is in preparing for the big day (hopefully 2 big days!). Thanks again
> to all for your
> input in figuring out this problem. Lesson learned: if things aren't
> behaving the way they should
> don't jump to conclusions.. dig deeper.
>
> -Ron
>
>
> -----Original Message-----
> From: Ryan B [mailto:rbenigno@home.com]
> Sent: Sunday, March 12, 2000 9:35 PM
> To: Ronald Johnson; ccielab@groupstudy.com
> Subject: Re: ISDN and NSSA
>
>
> This is the same problem we've been talking about in the other posts with
> people having problems with OSPF demand circuits.. You need to put the
> proper route maps on router B's redistribution.
>
> -Ryan
>
> ----- Original Message -----
> From: Ronald Johnson <ronbob@ibm.net>
> To: <ccielab@groupstudy.com>
> Sent: Sunday, March 12, 2000 3:37 PM
> Subject: RE: ISDN and NSSA
>
>
> > I still have a similar problem with Dialer profiles.
> Configuring "ip ospf
> > demand-circuit" on the dialer interfaces makes no difference. OSPF LSA's
> > keep bringing up the link. I did not have this problem when configuring
> only
> > physical BRI interfaces with "demand-circuit". I am not doing any
> > redistribution on the router affected by this problem, however,
> the router
> > is receiving redistributed routes via another interface (Serial0). Right
> now
> > I have a dialer list denying everything but ICMP ping packets.
> If I change
> > the dialer list to "ip permit" the multicast hellos keep the
> isdn link up.
> > My feeling is that this problem is somewhat restricted to dialer
> > interfaces.. I have seen all of the relevant posts about physical isdn
> > interfaces, and I don't have problems with non-dialer profile configs.
> >
> > Configs Below:
> >
> > Router A :
> >
> > interface BRI0
> > no ip address
> > no ip directed-broadcast
> > encapsulation ppp
> > dialer pool-member 1
> > isdn switch-type basic-ni
> > isdn spid1 0835866101
> > isdn spid2 0835866301
> > ppp authentication pap chap
> > !
> > interface Dialer0
> > ip address 192.168.3.13 255.255.255.252
> > no ip directed-broadcast
> > encapsulation ppp
> > ip ospf demand-circuit <<
> > dialer remote-name 5-R5-2516-2
> > dialer idle-timeout 90
> > dialer string 8358662
> > dialer pool 1
> > dialer-group 1
> > no cdp enable
> > ppp authentication pap chap
> > ppp multilink
> > !
> > router ospf 200
> > area 0 authentication message-digest
> > area 3 authentication message-digest
> > network 192.168.3.0 0.0.0.255 area 0
> > network 192.168.4.0 0.0.0.255 area 3
> >
> > access-list 101 permit icmp any any
> > dialer-list 1 protocol ip list 101
> >
> >
> > Router B:
> >
> > interface BRI0
> > no ip address
> > no ip directed-broadcast
> > encapsulation ppp
> > dialer pool-member 1
> > isdn switch-type basic-ni
> > isdn spid1 0835866201
> > isdn spid2 0835866401
> > ppp authentication pap chap
> > !
> > interface Dialer0
> > ip address 192.168.3.14 255.255.255.252
> > no ip directed-broadcast
> > encapsulation ppp
> > ip ospf demand-circuit
> > dialer remote-name 3-R3-2516-1
> > dialer idle-timeout 90
> > dialer string 8358661
> > dialer pool 1
> > dialer-group 1
> > ppp authentication pap chap
> > ppp multilink
> > !
> > router ospf 200
> > area 0 authentication message-digest
> > redistribute igrp 50 subnets
> > network 192.168.3.0 0.0.0.255 area 0
> > network 192.168.5.0 0.0.0.255 area 0
> > !
> > router igrp 50
> > redistribute connected metric 10 255 255 120 1400
> > redistribute ospf 200 metric 1544 30 255 20 1400
> > network 192.168.3.0
> > network 192.168.5.0
> >
> > access-list 101 permit icmp any any
> > dialer-list 1 protocol ip list 101
> >
> >
> > I'm including the redistribution portion of the config on router B,
> however,
> > I know that
> > router A also brings up the link when I remove the restrictive
> dialer-list.
> > The ospf interface
> > "demand-circuit" command makes no difference.
> >
> > Any thoughts? I'm taking the lab down in RTP 3/26-3/27 and would like to
> > have this question behind
> > me before then!
> >
> > Thanks.
> >
> > -Ron
> >
> >
> >
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
> > Joshua W. Watkins
> > Sent: Sunday, March 12, 2000 5:15 PM
> > To: Ryan B
> > Cc: David Russell; LASSERRE Grégory; ccielab@groupstudy.com
> > Subject: Re: ISDN and NSSA
> >
> >
> >
> > I just tested ospf demand circuit and it pretty much does what it says
> > it will do. The only time OSPF will cause the circuit to dial is when
> > there is a change in the OSPF network. Hellos are supressed by
> > default.
> >
> > > In my experience, the only time an ISDN links comes up with a
> > properly
> > > configured demand circuit is when there is actually information to
> > send...
> > > A topology change in the OSPF network should bring up the link to
> > update the
> > > routing tables. So, demand-circuit works as advertised.
> > >
> > > -Ryan
> > >
> > > ----- Original Message -----
> > > From: David Russell <drussell@tns-inc.com>
> > > To: LASSERRE Grégory <gregory.lasserre@arche.fr>;
> > <ccielab@groupstudy.com>
> > > Sent: Sunday, March 12, 2000 12:40 PM
> > > Subject: Re: ISDN and NSSA
> > >
> > >
> > > > This seems to be an unsettled issue with various posts indicating
> > that
> > > there
> > > > is multicast traffic over a demand circuit while others say there
> > isn't.
> > > >
> > > > I am running 12.0(2a) code and do not see the problem with either
> > the RIP
> > > > redist in the ASBR or when both routers are in area 0.
> > > >
> > > > Greg's last post retracts his observation of LSA broadcasts. He
> > had a
> > > > mutual redistribution routing loop (ouch!).
> > > >
> > > > Does anyone have a test case that does cause LSAs to be sent over
> > a demand
> > > > circuit?
> > > >
> > > >
> > > > Dave Russell
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: LASSERRE Grégory <gregory.lasserre@arche.fr>
> > > > To: ccielab@groupstudy.com <ccielab@groupstudy.com>
> > > > Cc: 'Earl Aboytes' <earl@linkline.com>
> > > > Date: Sunday, March 12, 2000 1:22 PM
> > > > Subject: RE: ISDN and NSSA
> > > >
> > > >
> > > >
> > > > I also encounter the problem, but in my case Type 5 LSAs are
> > keeping my
> > > > circuit up
> > > > (RIP redistributed in OSPF by my ASBR - normal Area).
> > > >
> > > > If i remove the rip redistribution from my ASBR, the circuit goes
> > down
> > > after
> > > > a while,
> > > > and then the demand circuit works fine.
> > > >
> > > > Here are the log :
> > > >
> > > > OSPF: Generate external LSA 113.78.220.2, mask 255.255.255.255,
> > type 5,
> > > age
> > > > 3600, metric 16777215, seq 0x80000054
> > > > OSPF: Start timer for Nbr 2.2.2.2 after adding 113.78.220.2 type 5
> > caller
> > > > 0x3396AE6
> > > > OSPF: Sending update on Dialer1 to 224.0.0.5
> > > > OSPF: Send Type 5, LSID 113.78.220.2, Adv rtr 10.10.10.10, age
> > 3600, seq
> > > > 0x80000054
> > > > IP: s=113.78.220.10 (local), d=224.0.0.5 (Dialer1), len 84,
> > sending
> > > > broad/multicast
> > > >
> > > > Does anybody knows a workaround to this problem ?
> > > >
> > > > Best regards.
> > > > Greg.
> > > >
> > > > > -----Message d'origine-----
> > > > > De: Earl Aboytes [SMTP:earl@linkline.com]
> > > > > Date: dimanche 12 mars 2000 10:54
> > > > > À: ccielab@groupstudy.com
> > > > > Objet: ISDN and NSSA
> > > > >
> > > > > I thought that I would share something that I recently
> > discovered. I
> > > hope
> > > > > this isn't obvious to the rest of you.
> > > > >
> > > > > If you are injecting a distance vector routing protocol into
> > OSPF and
> > > ISDN
> > > > > is using OSPF as its routing protocol, a multicast with address
> > > 224.0.0.5
> > > > > (all spf routers) will keep your circuit up forever. Even with
> > the ip
> > > ospf
> > > > > demand-circuit command this still occurs. OSPF sees these
> > external
> > > routes
> > > > > and floods them as Type 7 LSA's.
> > > > >
> > > > > My first thoughts were to configure the offending areas as
> > NSSAs. Area
> > > 1
> > > > > is one of the areas but has a virtual link running through it.
> > Is this
> > > a
> > > > > concern? The other area is area 0 which cannot be configured as
> > a NSSA.
> > > > > I was left with no choice but to configure 224.0.0.5 as
> > uninteresting
> > > > > traffic. Am I right?
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > Earl Aboytes
> > > > > Senior Technical Consultant
> > > > > GTE-Managed Solutions
> > > > > 800-483-5325 x8817
> > > > > earl.aboytes@telops.gte.com
> > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:23:05 GMT-3