From: Joshua W. Watkins (josh@xxxxxxxxxxx)
Date: Sun Mar 12 2000 - 19:14:50 GMT-3
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