ospd: NSSA Type-7 LSA Updated Error (Same Prefix, Different Mask)

[Kenzo-Xyy]

Description

The topology consists of an FRRouting device connected upstream to two routers, each establishing a BGP session:
One upstream router advertises the route 10.0.0.0/8.
The other advertises 10.0.0.0/9 and 10.128.0.0/9.
The FRRouting device is connected downstream to another router via OSPF in an NSSA area, and redistributes all three BGP-learned routes into OSPF.
Now, when the BGP neighbor that advertises 10.0.0.0/9 and 10.128.0.0/9 is disconnected, the FRRouting device correctly retains only the 10.0.0.0/8 route in its BGP table. However, the downstream OSPF router ends up with only the 10.0.0.0/9 route — which should have been withdrawn — and does not receive the 10.0.0.0/8 route.

Version

unierm# show version 
FRRouting 8.5.3 (unierm) on Linux(4.15.0-29-generic).
Copyright 1996-2005 Kunihiro Ishiguro, et al.
configured with:
    '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--localstatedir=/var/run/frr' '--sbindir=/usr/lib/frr' '--sysconfdir=/etc/frr' '--with-vtysh-pager=/usr/bin/pager' '--libdir=/usr/lib/x86_64-linux-gnu/frr' '--with-moduledir=/usr/lib/x86_64-linux-gnu/frr/modules' '--disable-dependency-tracking' '--enable-rpki' '--disable-scripting' '--enable-pim6d' '--with-libpam' '--enable-doc' '--enable-doc-html' '--enable-snmp' '--enable-fpm' '--disable-protobuf' '--disable-zeromq' '--enable-ospfapi' '--enable-bgp-vnc' '--enable-multipath=256' '--enable-user=frr' '--enable-group=frr' '--enable-vty-group=frrvty' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' 'build_alias=x86_64-linux-gnu' 'PYTHON=python3'

How to reproduce

only need to disconnect R2 from frr

Expected behavior

R3 should only have 10.0.0.0/8，this is right，I do this using simulate cisco router

Actual behavior

R3 have 10.0.0.0/9，this is wrong，because frr can not get 10.0.0.0/9 or 10.128.0.0/9 any more

Additional context

All Router Configs

config.zip

Checklist

• I have searched the open issues for this bug.
• I have not included sensitive information in this report.

[Kenzo-Xyy]

In fact ,I have tried 10.5.0，but also not work

[drosarius]

It looks like the prefixes 10.0.0.0/8 and 10.0.0.0/9 are getting Link state IDs 10.0.0.0 and 10.127.255.255 respectively (RFC 2328 Apx. E). When R2 is removed the FRR router needs to flush those LSAs (10.0.0.0/9 and 10.128.0.0/9). You can see here in the code

void ospf_nssa_lsa_flush(struct ospf *ospf, struct prefix_ipv4 *p)
{
	struct listnode *node, *nnode;
	struct ospf_lsa *lsa = NULL;
	struct ospf_area *area;

	for (ALL_LIST_ELEMENTS(ospf->areas, node, nnode, area)) {
		if (area->external_routing == OSPF_AREA_NSSA) {
			lsa = ospf_lsa_lookup(ospf, area, OSPF_AS_NSSA_LSA,
					      p->prefix, ospf->router_id);
					
			ospf_ls_retransmit_delete_nbr_area(area, lsa);
			if (!IS_LSA_MAXAGE(lsa)) {
				ospf_refresher_unregister_lsa(ospf, lsa);
				ospf_lsa_flush_area(lsa, area);
			}
		}
	}
}

it is only doing an lsa lookup using the prefix. So when R2 is removed and the FRR router tries to flush those prefixes it will flush the lsa with link state ID 10.0.0.0, which is the link state ID of the 10.0.0.0/8 prefix. There probably needs to be a mask check.

[Kenzo-Xyy]

Thank you for the detailed explanation and for pointing out the issue with the LSA lookup not considering the mask. I understand that this could lead to incorrect LSA flushing when R2 is removed.
Could you please let me know when this fix is expected to be implemented? Also, which version of the software will include this fix?
Looking forward to your update.
Best regards

[Kenzo-Xyy]

Tested and confirmed. Works great now, nice job!