OSPF NSSA

[Konrad Kręciwilk]

W dniu 2023-01-21 18:23, Ondrej Zajicek napisał(a):
> On Sat, Jan 21, 2023 at 04:18:47PM +0100, Konrad Kręciwilk wrote:
>> As you can see show ospf state from R1 has extrenal 10.7.100.0/24 via
>> 212.127.92.29 (which is local link via vlan4001) which is interrupted 
>> (L2).
>> Its look like R3 does not update database (via) when neighbor is lost
>> (vlan4001)
>> 
>> area 0.0.0.0
>> 
>> 	router 212.127.92.1
>> 		distance 2
>> 		router 212.127.92.2 metric 2
>> 		stubnet 212.127.92.0/30 metric 2
>> 		xnetwork 212.127.92.28/30 metric 110
>> 		xnetwork 212.127.92.128/30 metric 10
>> 		external 10.7.100.0/24 metric 20 via 212.127.92.29
> 
> I think i understand the issue. LSSA-LSA must contain forwarding 
> address.
> The route exported to OSPF on R3 was a direct route, so it does not 
> have
> one. BIRD has to choose one from interfaces that are part of OSPF 
> domain,
> i.e. "vlan4001" (212.127.92.29) and "vlan4011" (212.127.92.129).
> 
> It chose the first one, and announced NSSA-LSA with that IP address. 
> When
> link  R1-R3 broke, there is no need to choose a different one, as
> 212.127.92.29 is still valid IP for R3.
> 
> Now R1 sees Ext-LSA with forwarding address 212.127.92.29 (translated 
> by
> R2 from NSSA-LSA), and it considers 212.127.92.29 reachable (due to
> local network 212.127.92.28/30 on vlan4011). That is kind of blind spot
> for OSPF - when a stub network is announced, all addresses on that
> network are considered reachable, even if the network is really 
> splitted.
> 
> If the iface vlan4001 on R3 is disabled, R3 has to announce NSSA-LSA 
> with
> a different forwarding address, so it will work eventually. But that is
> not a real issue - if the iface is up, its IP address is valid to be 
> used
> as forwarding address.
> 
> I see two ways how to fix it:
> 
> 1) Configuration fix - you should have some loopback/stub IP (with /32
> mask) on R3 in OSPF domain. In that case BIRD would prefer such address
> as forwarding address for originated NSSA-LSAs.

I added interface with /32 as a stub, now /32 becomes a forwarding 
address for originated NSSA-LSAs. Its works good now
Thank you !




> 
> 2) I think that OSPF routers should annouce all their local addresses 
> as
> /32 (in addition to real prefixes), that would mitigate the blind spot.
> Or at least ones that are used as forwarding addresses in LSAs. If R3
> announced 212.127.92.129/32 stub, then R2 would translate it to 
> backbone
> and R1 would use path to 212.127.92.129/32 via R2, even if it has 
> direct
> 212.127.92.28/30.
> 
> Just curious, how is this situation solved by Quagga and Mikrotik, if
> you bring it to the similar situation, what is output of 'show ospf
> state' on R1/R2?

Sorry it was my mistake. Quagga/Frr/Mikrotik they behave the same way.