Re: ospfd: Apply netmask to stub prefixes before adding the route to the route table
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
Re: ospfd: Apply netmask to stub prefixes before adding the route to the route table
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@. 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),
Re: ospfd: Apply netmask to stub prefixes before adding the route to the route table
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.
>
> Remi
>
Box 1:
openbsd1# cat /etc/hostname.lo1
inet 10.0.0.1/32
openbsd1# cat /etc/hostname.gre0
up
mpls
tunnel 10.10.10.1 10.10.10.2
tunneldomain 10
inet 10.10.20.1/30
dest 10.10.20.2
openbsd1# cat /etc/ospfd.conf
area 0.0.0.0 {
interface lo1 {
passive
}
interface gre0
}
Box 2:
openbsd2# cat /etc/hostname.lo1
inet 10.0.0.2/32
openbsd2# cat /etc/hostname.gre0
up
mpls
tunnel 10.10.10.2 10.10.10.1
tunneldomain 10
inet 10.10.20.2/30
dest 10.10.20.1
openbsd2# cat /etc/hostname.gre1
up
mpls
tunnel 10.10.10.5 10.10.10.6
tunneldomain 10
inet 10.10.20.5/30
dest 10.10.20.6
openbsd2# cat /etc/ospfd.conf
area 0.0.0.0 {
interface lo1 {
passive
}
interface gre0
interface gre1
}
Box 3:
openbsd3# cat /etc/hostname.lo1
inet 10.0.0.3/32
openbsd3# cat /etc/hostname.gre0
up
mpls
tunnel 10.10.10.6 10.10.10.5
tunneldomain 10
inet 10.10.20.6/30
dest 10.10.20.5
openbsd3# cat /etc/ospfd.conf
area 0.0.0.0 {
interface lo1 {
passive
}
interface gre0
}
1: Box 1 has ospfd disabled. Route table on box 3:
openbsd3# route show
Routing tables
Internet:
DestinationGatewayFlags Refs Use Mtu Prio Iface
10.0.0.2/3210.10.20.5 UG 11 -32 gre0
10.0.0.3 10.0.0.3 UHl0 156 32768 1 lo1
10.10.20.0/30 10.10.20.5 UG 00 -32 gre0
10.10.20.5 10.10.20.6 UHh5 431 - 8 gre0
10.10.20.6 10.10.20.5 UHl0 143 - 1 gre0
10.10.20.6/32 10.10.20.5 UG 00 -32 gre0
localhost localhost UHl0 12 32768 1 lo0
2: Enable ospfd on box 1. Note the /30 is still in the routing table,
but also t
Re: ospfd: Apply netmask to stub prefixes before adding the route to the route table
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 > 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. Remi > > Mitchell > > diff --git usr.sbin/ospfd/rde_spf.c usr.sbin/ospfd/rde_spf.c > index 736f2e575..d842a2c20 100644 > --- usr.sbin/ospfd/rde_spf.c > +++ usr.sbin/ospfd/rde_spf.c > @@ -195,7 +195,7 @@ rt_calc(struct vertex *v, struct area *area, struct > ospfd_conf *conf) > 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), >
ospfd: Apply netmask to stub prefixes before adding the route to the route table
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 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? 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. Mitchell diff --git usr.sbin/ospfd/rde_spf.c usr.sbin/ospfd/rde_spf.c index 736f2e575..d842a2c20 100644 --- usr.sbin/ospfd/rde_spf.c +++ usr.sbin/ospfd/rde_spf.c @@ -195,7 +195,7 @@ rt_calc(struct vertex *v, struct area *area, struct ospfd_conf *conf) 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),
