From: Earl Aboytes (earl@xxxxxxxxxxxx)
Date: Mon Mar 13 2000 - 03:44:30 GMT-3
Ron,
Can you post your configs so that we may see exactly how you resolved this issu
e?
Earl
At 10:41 PM 3/12/00 -0500, Ronald Johnson wrote:
>
>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:04 GMT-3