From: LASSERRE Grégory (gregory.lasserre@xxxxxxxx)
Date: Sun Mar 12 2000 - 15:17:29 GMT-3
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