On Thu, Apr 04, 2019 at 05:29:40PM +0200, Remi Locherer wrote: > On Tue, Apr 02, 2019 at 07:27:07PM +1000, Mitchell Krome wrote: > > On 2/04/2019 3:30 pm, Remi Locherer wrote: > > > Hi Mitchell > > > > > > On Sat, Mar 30, 2019 at 04:10:09PM +1000, Mitchell Krome wrote: > > >> I kept finding I had a lingering /30 route when I turned off one of my > > >> test boxes. I tracked it down to ospfd sending RTM_ADD for a stub > > >> network with the non-masked prefix. The RTM_ADD path applies the mask > > >> inside the kernel, so the route got added as expected, but the > > >> RTM_DELETE enforces an exact match, so it could never remove the route. > > >> > > >> The advertised stub network was as follows: > > >> > > >> Link connected to: Stub Network > > >> Link ID (Network ID): 10.10.20.2 > > >> Link Data (Network Mask): 255.255.255.252 > > >> Metric: 10 > > > > > > Please send the details of your setup so it is easy to reproduce the > > > issue. > > > - OpenBSD version > > > - ospfd.conf > > > - interface configs > > > - routing table > > > > I am running a kernel I compiled myself with source from ~2 weeks ago. > > See the bottom for other info. > > > > > > > >> ospfd sends the interface address rather than network address as the > > >> link ID. The RFC says "set the Link ID of the Type 3 link to the > > >> subnet's IP address" which to me means we probably should also apply the > > >> mask before we add the stub to the LSA to avoid getting into this place > > >> to start with? > > > > > > This only applies to Type 3 LSAs. Below table is from RFC 2328 > > > chapter 12.1.4: > > > > > > LS Type Link State ID > > > _______________________________________________ > > > 1 The originating router's Router ID. > > > 2 The IP interface address of the > > > network's Designated Router. > > > 3 The destination network's IP address. > > > 4 The Router ID of the described AS > > > boundary router. > > > 5 The destination network's IP address. > > > > > >> > > >> The patch below just masks the stub network before it gets added to the > > >> route table, so that we can properly delete it. I can send a patch to > > >> mask it before sending the LSA too if the consensus is that is how it > > >> should be. > > > > > > With your patch you change the case "LSA_TYPE_ROUTER" (LS Type 1) and not > > > LS type 3. > > > > Inside the LSA type 1 there is a type 3 link which is a "stub network". > > That is what I was changing. Under 12.4.1.1 second dotpoint it says for > > a point to point network add a type 3 link. Maybe I got the terminology > > wrong, but this was definitely the thing I intended to change > > > > Link type Description Link ID > > __________________________________________________ > > 1 Point-to-point Neighbor Router ID > > link > > 2 Link to transit Interface address of > > network Designated Router > > 3 Link to stub IP network number > > network > > 4 Virtual link Neighbor Router ID > > > > > > Table 18: Link descriptions in the > > router-LSA. > > > > > > Thank you Mitchell for your analysis and great explanation! > > I think your proposed fix is correct. I never noticed this warning bevor > because I always used a /32 mask on point-to-point interfaces. > > Below again the diff from Mitchell. I tested this and it is OK remi@.
Looks good to me OK claudio@ > > Index: rde_spf.c > =================================================================== > RCS file: /cvs/src/usr.sbin/ospfd/rde_spf.c,v > retrieving revision 1.76 > diff -u -p -r1.76 rde_spf.c > --- rde_spf.c 22 Nov 2015 13:09:10 -0000 1.76 > +++ rde_spf.c 2 Apr 2019 20:13:40 -0000 > @@ -195,7 +195,7 @@ rt_calc(struct vertex *v, struct area *a > if (rtr_link->type != LINK_TYPE_STUB_NET) > continue; > > - addr.s_addr = rtr_link->id; > + addr.s_addr = rtr_link->id & rtr_link->data; > adv_rtr.s_addr = htonl(v->adv_rtr); > > rt_update(addr, mask2prefixlen(rtr_link->data), > -- :wq Claudio
