cancel
Showing results forĀ 
Search instead forĀ 
Did you mean:Ā 
cancel
2764
Views
15
Helpful
26
Replies

OSPFv3 - TSA (Totally Stuby Area) missing the default route?

FlorianCokl
Level 1
Level 1

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).

Bildschirmfoto 2022-09-14 um 01.49.47.png

1 Accepted Solution

Accepted Solutions

Harold Ritter
Level 12
Level 12

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.

Capture dā€™eĢcran, le 2022-09-16 aĢ€ 10.37.34.png

 

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
MĆ©xico mĆ³vil: +52 1 55 8312 4915
Cisco MĆ©xico
Paseo de la Reforma 222
Piso 19
CuauhtƩmoc, JuƔrez
Ciudad de MĆ©xico, 06600
MĆ©xico

View solution in original post

26 Replies 26

see below comment 

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.

A0524EFB-D621-463F-88B2-92A333838059.jpeg

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.

please share the config of the OSPFv2 and OSPFv3

Hello MHM

I don't see what difference it would make - the configuration is straight forward - however:

OSPFv3 R1

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

OSPFv2 R1

router ospf 1
router-id 1.1.1.1
area 6 stub
area 62 stub no-summary
passive-interface Loopback0

Here you are

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!

Harold Ritter
Level 12
Level 12

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.

Capture dā€™eĢcran, le 2022-09-16 aĢ€ 10.37.34.png

 

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
MĆ©xico mĆ³vil: +52 1 55 8312 4915
Cisco MĆ©xico
Paseo de la Reforma 222
Piso 19
CuauhtƩmoc, JuƔrez
Ciudad de MĆ©xico, 06600
MĆ©xico

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.

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
MĆ©xico mĆ³vil: +52 1 55 8312 4915
Cisco MĆ©xico
Paseo de la Reforma 222
Piso 19
CuauhtƩmoc, JuƔrez
Ciudad de MĆ©xico, 06600
MĆ©xico

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.

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,

Harold Ritter
Sr Technical Leader
CCIE 4168 (R&S, SP)
harold@cisco.com
MĆ©xico mĆ³vil: +52 1 55 8312 4915
Cisco MĆ©xico
Paseo de la Reforma 222
Piso 19
CuauhtƩmoc, JuƔrez
Ciudad de MĆ©xico, 06600
MĆ©xico

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 

OSPF_Allowed_LSAs_clean_normal.PNG

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
hjgjghkghkgj.pngghfhfghfghfh.png

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)

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.

it is a software-issue - period - as Harold has prooven - and I meanwhile, too.

  • IOL - fail
  • vIOS - pass

I follow you and @Harold Ritter 
but I want to be sure only 
if you can share the output of 


show ospfv3
Review Cisco Networking for a $25 gift card