OSPF NSSA

[Konrad Kręciwilk]

W dniu 22.01.2023 o 20:59, Konrad Kręciwilk via Bird-users pisze:
> 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.

additional info,
Mikrotik not always elect /32 stub as forwarding-address. I dont know 
why for one solution /32 is forwarding-address but for another not. The 
choice is not obvious
but since v7.X is possible to set forwarding-address using filters (set 
ospf-ext-fwd):

rul:

if (protocol connected && dst in OSPF-ANNOUNCE) { set ospf-ext-type 
type1; set ospf-ext-fwd 10.81.254.3; accept }


and then it works predictably :)



-- 
Pozdrawiam,
Konrad Kręciwilk
Inżynier sieci
GSM +48 883 131 165
tel.: +48 71 735 15 31
e-mail:konrad.kreciwilk at korbank.pl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20230216/904db022/attachment.htm>