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. 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? -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."