<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">W dniu 22.01.2023 o 20:59, Konrad
Kręciwilk via Bird-users pisze:<br>
</div>
<blockquote type="cite"
cite="mid:3029c4d18074ff529916d9ee26001487@korbank.pl">W dniu
2023-01-21 18:23, Ondrej Zajicek napisał(a):
<br>
<blockquote type="cite">On Sat, Jan 21, 2023 at 04:18:47PM +0100,
Konrad Kręciwilk wrote:
<br>
<blockquote type="cite">As you can see show ospf state from R1
has extrenal 10.7.100.0/24 via
<br>
212.127.92.29 (which is local link via vlan4001) which is
interrupted (L2).
<br>
Its look like R3 does not update database (via) when neighbor
is lost
<br>
(vlan4001)
<br>
<br>
area 0.0.0.0
<br>
<br>
router 212.127.92.1
<br>
distance 2
<br>
router 212.127.92.2 metric 2
<br>
stubnet 212.127.92.0/30 metric 2
<br>
xnetwork 212.127.92.28/30 metric 110
<br>
xnetwork 212.127.92.128/30 metric 10
<br>
external 10.7.100.0/24 metric 20 via 212.127.92.29
<br>
</blockquote>
<br>
I think i understand the issue. LSSA-LSA must contain forwarding
address.
<br>
The route exported to OSPF on R3 was a direct route, so it does
not have
<br>
one. BIRD has to choose one from interfaces that are part of
OSPF domain,
<br>
i.e. "vlan4001" (212.127.92.29) and "vlan4011" (212.127.92.129).
<br>
<br>
It chose the first one, and announced NSSA-LSA with that IP
address. When
<br>
link R1-R3 broke, there is no need to choose a different one,
as
<br>
212.127.92.29 is still valid IP for R3.
<br>
<br>
Now R1 sees Ext-LSA with forwarding address 212.127.92.29
(translated by
<br>
R2 from NSSA-LSA), and it considers 212.127.92.29 reachable (due
to
<br>
local network 212.127.92.28/30 on vlan4011). That is kind of
blind spot
<br>
for OSPF - when a stub network is announced, all addresses on
that
<br>
network are considered reachable, even if the network is really
splitted.
<br>
<br>
If the iface vlan4001 on R3 is disabled, R3 has to announce
NSSA-LSA with
<br>
a different forwarding address, so it will work eventually. But
that is
<br>
not a real issue - if the iface is up, its IP address is valid
to be used
<br>
as forwarding address.
<br>
<br>
I see two ways how to fix it:
<br>
<br>
1) Configuration fix - you should have some loopback/stub IP
(with /32
<br>
mask) on R3 in OSPF domain. In that case BIRD would prefer such
address
<br>
as forwarding address for originated NSSA-LSAs.
<br>
</blockquote>
<br>
I added interface with /32 as a stub, now /32 becomes a forwarding
address for originated NSSA-LSAs. Its works good now
<br>
Thank you !
<br>
<br>
<br>
<br>
<br>
<blockquote type="cite">
<br>
2) I think that OSPF routers should annouce all their local
addresses as
<br>
/32 (in addition to real prefixes), that would mitigate the
blind spot.
<br>
Or at least ones that are used as forwarding addresses in LSAs.
If R3
<br>
announced 212.127.92.129/32 stub, then R2 would translate it to
backbone
<br>
and R1 would use path to 212.127.92.129/32 via R2, even if it
has direct
<br>
212.127.92.28/30.
<br>
<br>
Just curious, how is this situation solved by Quagga and
Mikrotik, if
<br>
you bring it to the similar situation, what is output of 'show
ospf
<br>
state' on R1/R2?
<br>
</blockquote>
<br>
Sorry it was my mistake. Quagga/Frr/Mikrotik they behave the same
way.
<br>
</blockquote>
<p><span class="HwtZe" lang="en"><span class="jCAhz ChMk0b"><span
class="ryNqvb">additional info, <br>
Mikrotik not always elect /32 stub as forwarding-address. I
dont know why for one solution /32 is </span></span></span><span
class="HwtZe" lang="en"><span class="jCAhz ChMk0b"><span
class="ryNqvb">forwarding-address but for another not. </span></span></span><span
class="HwtZe" lang="en"><span class="jCAhz ChMk0b"><span
class="ryNqvb">The choice is not obvious<br>
but since v7.X is possible to set </span></span></span><span
class="HwtZe" lang="en"><span class="jCAhz ChMk0b"><span
class="ryNqvb">forwarding-address using filters (</span></span></span><span
class="HwtZe" lang="en"><span class="jCAhz ChMk0b"><span
class="ryNqvb"><span class="HwtZe" lang="en"><span
class="jCAhz ChMk0b"><span class="ryNqvb">set
ospf-ext-fwd)</span></span></span>:</span></span></span></p>
<p><span class="HwtZe" lang="en"><span class="jCAhz ChMk0b"><span
class="ryNqvb">rul:</span></span></span></p>
<p><span class="HwtZe" lang="en"><span class="jCAhz ChMk0b"><span
class="ryNqvb">if (protocol connected && dst in
OSPF-ANNOUNCE) { set ospf-ext-type type1; set ospf-ext-fwd
10.81.254.3; accept }<br>
</span></span></span><span class="HwtZe" lang="en"><span
class="jCAhz ChMk0b"><span class="ryNqvb"></span></span></span><span
class="HwtZe" lang="en"><span class="jCAhz ChMk0b"><span
class="ryNqvb"></span></span></span></p>
<p><br>
</p>
<p><span class="HwtZe" lang="en"><span class="jCAhz ChMk0b"><span
class="ryNqvb">and then it works predictably :)<br>
</span></span></span></p>
<p><br>
</p>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Pozdrawiam,
Konrad Kręciwilk
Inżynier sieci
GSM +48 883 131 165
tel.: +48 71 735 15 31
e-mail: <a class="moz-txt-link-abbreviated" href="mailto:konrad.kreciwilk@korbank.pl">konrad.kreciwilk@korbank.pl</a></pre>
</body>
</html>