ā09-13-2022 05:00 PM - last edited on ā09-19-2022 11:37 PM by Translator
Hello Networkers,
There is a simmilar post regarding ospfv2 - but mine is about ospfv3 configured with
router ospfv3 <proc-id>!
The links are configured with ipv4 and ipv6 addresses. The area 6 stub works - but (in my case) area 62, on R1 gets the
area 62 stub no-summary
configured - as I have learned for decades. It doesn't matter if the
latter
command is configured under the address-family or the "just under the routing process, above the adddres-families" - the results are the same = no default route on "my" R62?!
The LSDB, however, has the route - I just can't see the difference?
R62 is (of course) configured with
area 62 stub
"only", since the
no-summary
is only necessary on the ABR (R1 in my case).
Solved! Go to Solution.
ā09-16-2022 08:40 AM - edited ā09-16-2022 09:06 AM
Hi @FlorianCokl ,
What IOS version are you running in this lab? I just ran a quick test with IOS 15.9(3)M4 and it works like a charm. So it looks like it could be a software issue.
ā09-13-2022 05:24 PM - edited ā09-16-2022 07:55 AM
see below comment
ā09-16-2022 06:04 AM
Hello MHM
Unfortunately you are not wrong - but not right either. I have done the same Lab but with OSPFv2.
However - in both Labs R1 does not have a default-route itself - it doesn't receive one from any other. R1 is an ABR.
In a Stub-Area it is the responsibility of the ABR to advertise a 0.0.0.0/0 since LSA5 is no longer allowed - and if there where any LSA5 in the Domain how would (in my case AREA 6) be able to reach them without having LSA5 and/or a 0.0.0.0/0?!
In a Totally-Stubby-Area it is the responsibility of the ABR to advertise a 0.0.0.0/0, TOO!! Since neither LSA5 nor LSA3 are allowed - how them would (in my case AREA 62) be able to reach any other AREA in the domain?!
To proove it - here is the same Lab but with OSPFv2.
As you can see - R1 is NOT in posession of a 0.0.0.0/0. However R6 and R62 do have the 0.0.0.0/0 in the LSDB and in the routing table.
ā09-16-2022 07:41 AM
please share the config of the OSPFv2 and OSPFv3
ā09-16-2022 08:17 AM
Hello MHM
I don't see what difference it would make - the configuration is straight forward - however:
router ospfv3 1
!
address-family ipv4 unicast
passive-interface Loopback0
router-id 1.1.1.1
area 6 stub
area 62 stub no-summary
exit-address-family
!
address-family ipv6 unicast
passive-interface Loopback0
router-id 1.1.1.1
area 6 stub
area 62 stub no-summary
exit-address-family
router ospf 1
router-id 1.1.1.1
area 6 stub
area 62 stub no-summary
passive-interface Loopback0
Here you are
ā09-16-2022 08:19 AM
Hello MHM
And like I pushed in the very beginning: the default route is in the LSDB - on R6 and R62 - for both IPv4 and IPv6!
ā09-16-2022 08:40 AM - edited ā09-16-2022 09:06 AM
Hi @FlorianCokl ,
What IOS version are you running in this lab? I just ran a quick test with IOS 15.9(3)M4 and it works like a charm. So it looks like it could be a software issue.
ā09-16-2022 11:00 AM
Hello Harold
Well - I am running Version 15.7(3)M2. Yours is obviously a higher version, and....
Your output from the CLI is what I expect to see = it is in the LSDB, there is no hint on why it should not make into the routing-table -and - tata, it is in the routing-table.
Still very strange - how old is OSPF now? Even Version 3? Bad....
One more question: Is yours an IOL, or a vIOS? And if it is an IOL, is it available from Cisco for downloading? vIOS I posess the version you ran the lab with.
Harold - you nailed it. THANK YOU for your effort.
ā09-16-2022 11:21 AM
Hi @FlorianCokl ,
I am actually running vIOS under CML.
The strange thing is that R6 and R62 receive the same LSA (according to the show ospfv3 database you provided) and should both install it in the RIB. Can you confirm both R6 and R62 ospfv3 configuration is the same and the they are running the same vIOS version? Also can you move to vIOS 15.9 and see if it fixes the issue.
Regards,
ā09-16-2022 11:41 AM - last edited on ā09-19-2022 11:42 PM by Translator
Hello Harold
Actually I have replaced the R62 (in my example) with a vIOS Router (IOS 15.9(3)M4) instead of IOL - all others are the same - R1 is still an IOL - and, now it looks like in your example, and as I would expect it = R62 has it in the routing-table now as well.
No - the routers R6 and R62 do not receive the same LSA -> yes, in both is 0.0.0.0, but the sequence number is different + R1 has 2 LSA, 1 for AREA 6, 1 for AREA 62 (as expected) - and these sequence numbers match (as expected) with R6, R62 respectively. So that would be fine. Yet, for some reason R62 (as IOL) wasn't willing to install it in the routing table. The interesting thing: the LSA stays the same, no matter if R1 is configured with
stub
or with
stub no-summery
- but R62 (as IOL) would, with the
latter (stub no-summery)
suddenly not install the LSA in the routing-table.
I really don't get it. Why? What difference does it make for R62 if R1 has no-summery added? From my studies and from looking at OSPF-hellos, I haven't noticed "a new flag for totally"? Yes the stub-bit - fine.
And yes Harold - in the Labs all routers where IOL, all running the same version.
ā09-16-2022 11:56 AM
Hi Florian,
What I meant by the same LSA is that it looks to contain the same information, so technically R62 should install it as well. Strange.
I am glad that the upgrade to 15.9 fixed it.
Regards,
ā09-16-2022 11:42 AM - edited ā09-16-2022 11:47 AM
Just to clear some point here
first the LSA3 default prefix, this prefix is not advertise nor redistribute from static it generate from ABR
OSPFv2
as I mention before the T-Stub area not allow LSA3 and LSA5&7, but it allow LSA3 default (* in table)
you do the OSPFv2 and it work as we want
OSPFv3
I run small lab in GNS3 same as your case one ABR between Stub and T-Stub and Area 0,
the only different is LSA3 is called inter-area prefix
you see the lab is OK and stub have LSA3 + LSA3 default
T-stub have only LSA3 default
can I see show run in R1 in case of OSPFv3?
also show ospfv3
you must see three area and with it type. (also share this)
ā09-16-2022 11:52 AM
Hello MHM
first the LSA3 default prefix, this prefix is not advertise nor redistribute from static it generate from ABR
OSPFv2
as I mention before the T-Stub area not allow LSA3 and LSA5&7, but it allow LSA3 default (* in table)
you do the OSPFv2 and it work as we want.
I never said anything like it - i.e. redistrubution!! It is the responsibility of the ABR to "inject" the 0.0.0.0 in the stub-area 6, and totally-stubby-area 62 - and I have very clearly explained why - I am not repeating it.
the only different is LSA3 is called inter-area prefix
exactly - and some more - and they have different numbers: 0x2003 (three - like in ospfv2 the LSA3) + the new LSA 0x2004 that "advertises" ABRs.
ā09-16-2022 11:55 AM
it is a software-issue - period - as Harold has prooven - and I meanwhile, too.
ā09-16-2022 11:59 AM - last edited on ā09-19-2022 11:45 PM by Translator
I follow you and @Harold Ritter
but I want to be sure only
if you can share the output of
show ospfv3
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide