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:[email protected]
