OSPF Default Orginate via Default Route learned from OSPF

[tcp_analysis_flags_eq_1]

Hi Everyone,

Correct me if wrong but its not possible to advertise a default route via the default-information originate command if the default route currently in the routing table is learned via OSPF(eg. another router using the default-information originate with a default route learned from a different protocol)

[Giuseppe Larosa]

Hello @tcp_analysis_flags_eq_1 ,

anyway the local router is able to flood the received default route LSA to other OSPF neighbors unless they are in stub or NSSA areas so this is not a real limitation, but I see it more as a consistency check.

For the downstream devices what is important is to receive the default route if they are in area 0 in a standard area they should.

An ASBR is needed to generate a default route LSA with a local default route installed by other means either a static or other dynamic routing protocol.

Hope to help

Giuseppe

[tcp_analysis_flags_eq_1]

---

@Giuseppe Larosa wrote:

Hello @tcp_analysis_flags_eq_1 ,

anyway the local router is able to flood the received default route LSA to other OSPF neighbors unless they are in stub or NSSA areas so this is not a real limitation, but I see it more as a consistency check.

For the downstream devices what is important is to receive the default route if they are in area 0 in a standard area they should.

An ASBR is needed to generate a default route LSA with a local default route installed by other means either a static or other dynamic routing protocol.

Hope to help

Giuseppe

---

Hi Giuseppe,
Agreed with the setup you said, what if the scenario looks like this?

[Giuseppe Larosa · Accepted solution]

Hello @tcp_analysis_flags_eq_1 ,

if R2 stops to receive the eBGP default route it will simply purge its own LSA 0.0.0.0/0, R2 will not generate its own default route if it learns it via OSPF itself from R1 via R3.

This network diagram and scenario is exactly what I was meaning with consistency check.

The act of purging the OSPF LSA will make R3 to remove the LSA from database and to use only the default route to R1.

In OSPF each LSA has an owner: only the owner that is the advertising router has the right to refresh the LSA every 30 minutes or to remove it. To remove an LSA the owner sends again the LSA with a LS age of max-age = 3600 seconds and this is flooded to all routers in OSPF domain/area depending on LSA type.

see

https://blog.ine.com/igp-route-poisoning-techniques-part-1-ripv2ospf-route-poisoning-techniques

Hope to help

Giuseppe

[tcp_analysis_flags_eq_1]

---

@Giuseppe Larosa wrote:

Hello @tcp_analysis_flags_eq_1 ,

if R2 stops to receive the eBGP default route it will simply purge its own LSA 0.0.0.0/0, R2 will not generate its own default route if it learns it via OSPF itself from R1 via R3.

This network diagram and scenario is exactly what I was meaning with consistency check.

The act of purging the OSPF LSA will make R3 to remove the LSA from database and to use only the default route to R1.

In OSPF each LSA has an owner: only the owner that is the advertising router has the right to refresh the LSA every 30 minutes or to remove it. To remove an LSA the owner sends again the LSA with a LS age of max-age = 3600 seconds and this is flooded to all routers in OSPF domain/area depending on LSA type.

see

https://blog.ine.com/igp-route-poisoning-techniques-part-1-ripv2ospf-route-poisoning-techniques

Hope to help

Giuseppe

---

Hi Giuseppe,

Thanks for validating it, the reason I asked it is that we have a scenario wherein R3 installs an OSPF E2 route that is learned from R2 even though R2 does not have an external default route, it only have a OSPF learned route from R1 via R3 . Its a 3rd party vendor anyways and just wants to validate that there is something wrong on how it operates as I have tried it on a lab as well and R3 should remove the E2 route from its RIB