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-pointNeighbor 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 - 1.76
> +++ rde_spf.c 2 Apr 2019 20:13:40 -
> @@ -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