cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2338
Views
0
Helpful
12
Replies

Query on routing process

sateeshk10
Level 1
Level 1

Hi,

 

I am running  two OSPF routing process on the same router,  one process towards core and receiving default route (110) from core and  i am running another process in totally stub area which in turn  generating default route (108) towards down network.

 

Question is , when checked in router , default route installed in RIB receiving from core why is not  the stub area generated default route ? because stub area generate default route AD (108) s lower than core ospf AD(110)

 

ospf 10 (towards core) - default configuration

 

ospf20 (towards down stream)

distance 108

area 2.2.2.2  stub no-summary

default-information originate always

 

 

output - not sure, will be helpful.

 

router# show ip ospf database 0.0.0.0
OSPF Router with ID (x.x.x.67) (Process ID 10 VRF default)

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 x.x.x.101 1125 0x8000b248 0x6046 0
0.0.0.0 x.x.x.x.102 954 0x80022295 0x6382 0

OSPF Router with ID (x.x.x.77) (Process ID 20 VRF default)

Summary Network Link States (Area 1.1.1.1)

Link ID ADV Router Age Seq# Checksum
0.0.0.0 x.x.x.77 444 0x8001f1dd 0x322f
0.0.0.0 x.x.x.78 1458 0x8001f1dd 0x2639

Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 x.x.x.77 1796 0x8001d1a3 0x60ce 0
0.0.0.0 x.x.x.78 947 0x8001c950 0x1375 0

 

 

 

 

 

2 Accepted Solutions

Accepted Solutions

Hello @sateeshk10 ,

usually in these type of scenario with two OSPF processes running the core facing process will use the lowest AD.

So your choices are conceptually wrong as you would not want to have a default route on the edge OSPF process to be preferred over the one coming from the core process.

However, in OSPF process 20 you have only a totally stub area and this means that the B pair is generating a default route in OSPF 20 to be sent downstream and not receiving one.

 

As a result of this there is no competition on the B pair the only available default route that can be installed in the IP routing table is the one coming from core whatever AD is associated with it.

In other words the default route is generated in OSPF 20 for the purpose to be advertised downstream to devices in the totally stub area as an LSA type 3,  but it  is not used locally on the B pair.

 

Hope to help

Giuseppe

 

View solution in original post

Hello @sateeshk10 ,

the LSA type 3 0.0.0.0/0 is locally generated with the only purpose to be advertised into totally stub area in OSPF process 20.

Again, there is no comparison between the two default routes

the LSA type 5 is received and used to install a default route in the local IP routing table  of B pair devices.

 

The LSA type 3 is generated and sent out in totally stub area, but is not consided as a possible default route for themselves.

 

The two routers never try to compare the two, because they know the LSA type 3 is locally generated just to inject a default route in that totally stub area regardless of the existence of an indipendent default route in the IP routing table provided in any way ( static, BGP or another OSPF process like in this case).

The LSA type 3 0.0.0.0/0 is necessary to provide to internal routers in the totally stub area a way to reach subnets that are in other areas as no other LSA type 3 is allowed to enter a totally stub area.

 

I hope now it is more clear for you.

 

Hope to help

Giuseppe

 

 

View solution in original post

12 Replies 12

balaji.bandi
Hall of Fame
Hall of Fame

We may required more information, how many device connected here. and full configuration with show ip route information related to OSPF outout.

 

other suggest is look at the concept and understand the default route populated :

 

https://abhishektechdecoder.wordpress.com/2017/03/21/default-route-0-0-0-00-lsa-types-in-different-ospf-areas/

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

Cristian Matei
VIP Alumni
VIP Alumni

Hi,

 

    AD is a RIB attribute not a IGP attribute, so it has nothing to do with AD. When you generate a default route in OSPF:

         - the always keyword is required only if that router does not have a default route in the RIB, which you have, so the "always" keyword should be removed

         - when OSPF generates a default route to be advertised to its neighbors, you will see it in the OSPF database of the router generating it, but not in the RIB of the generating router. Think about it, if it would show up in the RIB, what would be the next-hop value? Based on which criteria should the router choose a next-hop  and which next-hop?

 

Regards,

Cristian Matei.

    

Hi,

 

Thanks for immediate responses and sorry, may be my question was wrong, here is diagram...

 

Now B pair has two default routes 1)  from A pair with 111 AD and other one is within ospf 20 (generated by default-originate towards server) the question is why highest AD 111  route getting  installed  in RIB instead of ospf 20 default-route which has 109 AD? 

 

Thumbrule, if i am not wrong, if you are running two routing processes, lowest AD route will be preferred  right?

 

 

show ip rou from B pair

0.0.0.0/0, ubest/mbest: 2/0
*via x.x.x.17, Po300, [111/1], 43w4d, ospf-10, type-2
*via x.x.x..45, Po301, [111/1], 42w3d, ospf-10, type-2

Capture.PNGThanks

Hi,

 

If someone responds to my query is highly appreciated.

 

Thanks

 

 

Hello @sateeshk10 ,

usually in these type of scenario with two OSPF processes running the core facing process will use the lowest AD.

So your choices are conceptually wrong as you would not want to have a default route on the edge OSPF process to be preferred over the one coming from the core process.

However, in OSPF process 20 you have only a totally stub area and this means that the B pair is generating a default route in OSPF 20 to be sent downstream and not receiving one.

 

As a result of this there is no competition on the B pair the only available default route that can be installed in the IP routing table is the one coming from core whatever AD is associated with it.

In other words the default route is generated in OSPF 20 for the purpose to be advertised downstream to devices in the totally stub area as an LSA type 3,  but it  is not used locally on the B pair.

 

Hope to help

Giuseppe

 

Thanks  Giuseppe and appreciate!

 

I forgot to mention one more point , when i re-distribute OSPF20 into OSPF10(towards core) , denying  default and redistributing other routes - That might helped to ignore OSPF20 default route installation in RIB ?

 

Here is the my OSPF database on B pair

 


Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 1.1.1.1 1110 0x8000c6c0 0x33e6 0 (Default route from core)
0.0.0.0  1.1.1.2  919 0x8002370d 0x3524 0

 

Router Link States (Area 0.0.0.0)
Summary Network Link States (Area 0.0.0.0)
0.0.0.0 2.2.2.1 702 0x80020654 0x05d0 (Generated in B pair)
0.0.0.0 2.2.2.2 1806 0x80020654 0xf8da

 

In other words the default route is generated in OSPF 20 for the purpose to be advertised downstream to devices in the totally stub area as an LSA type 3,  but it  is not used locally on the B pair - I got this partially,  could you please elaborate this further(but it  is not used locally on the B pair) .

 

Thanks

Kumar

 

Hello @sateeshk10 ,

 

>> I forgot to mention one more point , when i re-distribute OSPF20 into OSPF10(towards core) , denying  default and redistributing other routes - That might helped to ignore OSPF20 default route installation in RIB ?

 

No, in Cisco OSPF implementation it is not possible to redistribute a default route in an OSPF process as far as I know.

 

To help discriminate between the two processes in show commands you can use

 

show ip ospf 10 database external

 

show ip ospf 20 database summary

 

>> In other words the default route is generated in OSPF 20 for the purpose to be advertised downstream to devices in the totally stub area as an LSA type 3,  but it  is not used locally on the B pair

 

The device generating a default route into a routing protocol does it for advertising to other devices in the same routing domain and not for using it in the local IP routing table. This is what happen on the B pair of devices that advertise an LSA type 3 0.0.0.0/0 into totally stub area in OSPF process 20, but this entry does not compete with the received LSA type 5 in OSPF process 10. So the last one is installed in the IP routing table.

And to be noted this is exactly what you would like the devices to do in your network scenario.

 

Hope to help

Giuseppe

 

Sorry to bother you again and again..

 

his is what happen on the B pair of devices that advertise an LSA type 3 0.0.0.0/0 into totally stub area in OSPF process 20, but this entry does not compete with the received LSA type 5 in OSPF process 10 - Means, LSA5 is more preferred than LSA3 ?  on what basis? (i agree that i am missing some basic ) :)

 

Some more info collected from B pair

OSPF10 - ASBR(Normal Area)

OSPF20 - ABR and ASBR(Totally stubby area)

 

Thanks and really appreciated your responses.

 

Kumar

Hello @sateeshk10 ,

the LSA type 3 0.0.0.0/0 is locally generated with the only purpose to be advertised into totally stub area in OSPF process 20.

Again, there is no comparison between the two default routes

the LSA type 5 is received and used to install a default route in the local IP routing table  of B pair devices.

 

The LSA type 3 is generated and sent out in totally stub area, but is not consided as a possible default route for themselves.

 

The two routers never try to compare the two, because they know the LSA type 3 is locally generated just to inject a default route in that totally stub area regardless of the existence of an indipendent default route in the IP routing table provided in any way ( static, BGP or another OSPF process like in this case).

The LSA type 3 0.0.0.0/0 is necessary to provide to internal routers in the totally stub area a way to reach subnets that are in other areas as no other LSA type 3 is allowed to enter a totally stub area.

 

I hope now it is more clear for you.

 

Hope to help

Giuseppe

 

 

Hi Giuseppe,

 

I have tried to simulate the same in LAB, it preferring default originated by stub network, not preferring core network default route(attached configuration files) ..

 

B1 router vlan 100 - ruining ospf with down steam (server ruining OSPF process)

B2 router vlan 200 - ruining ospf with down steam (server ruining OSPF process)

 

R19# show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "ospf 1", distance 109, metric 4, candidate default path, type inter area
Redistributing via ospf 2
Last update from 90.90.90.3 on Vlan100, 00:10:48 ago
Routing Descriptor Blocks:
* 90.90.90.3, from 2.2.2.30, 00:10:48 ago, via Vlan100
Route metric is 4, traffic share count is 1
R19#

 

if i shut the vlan 100 then its preferring core generate default route

 

R19# show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "ospf 2", distance 111, metric 1, candidate default path
Tag 1, type extern 2, forward metric 10
Last update from 1.1.1.130 on Ethernet0/0, 00:00:01 ago
Routing Descriptor Blocks:
* 1.1.1.134, from 2.2.2.20, 00:00:01 ago, via Ethernet0/2
Route metric is 1, traffic share count is 1
Route tag 1
1.1.1.130, from 2.2.2.19, 00:00:01 ago, via Ethernet0/0
Route metric is 1, traffic share count is 1
Route tag 1

 

 

 

 

Hello @sateeshk10 ,

the B pair act as two routers at OSPF level this is why you see this. The first ABR to generate a default route will cause the other one to install it for its lower AD 109.

As I have written in a previous post you should increase the AD on the edge process so that OSPF core default route is preferred.

 

router ospf 1

distance ospf 115 115 115

 

the distance ospf command allows to tweak the AD for O , O IA and external routes. doing this on the edge process (OSPF 1 in my understanding) should lead to the desired behaviour.

 

Hope to help

Giuseppe

 

Hi Giuseppe,

 

I do agree with you but the same scenario is working production so, that leads me to start this thread :)

Off course, if we change AD on OSPF 1 process, sure will work but how it is working in production is question for me, i have configured my lab  similar to production ..

 

I am attaching A pair config also for reference..!

 

 

 

Thanks

Sateesh K

 

 

 

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco