From: Ronald Johnson (ronbob@xxxxxxx)
Date: Sun Mar 12 2000 - 20:48:40 GMT-3
Leaving the command on the physical interfaces makes no difference when it's
the dialer profile
that is initiating the call. "Deny any any ospf" does not solve the problem.
I would like to
see the "ip ospf demand-circuit" command work like it did w/ physical
interfaces..
-Ron
-----Original Message-----
From: Jason [mailto:jkb@bctel.ca]
Sent: Sunday, March 12, 2000 6:45 PM
To: Ronald Johnson
Subject: Re: ISDN and NSSA
Why not leave the ip ospf demand circuit on the physical interface ?
I would if a access-list with a deny any any ospf would help ?
Ronald Johnson wrote:
> 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