fib_frontend: Add network specific broadcasts, when it takes a sense

fib_frontend: Add network specific broadcasts, when it takes a sense

[Brandon Philips]

Hello-

A number of us are working on an OSS overlay network system called
flannel. It is used in a variety of Linux container systems and one of
the backends is VXLAN.

The issue we have: when creating the VXLAN interface and assigning it
an address we see a broadcast route being added by the Kernel. For
example if we have 10.4.0.0/16 a broadcast route to 10.4.0.0 is
created. This route is unwanted because we assign 10.4.0.0 to one of
our VXLAN interfaces.

However, the Kernel interface bring-up comment reads: Add network
specific broadcasts, when it takes a sense. The code is here:
https://github.com/torvalds/linux/blob/master/net/ipv4/fib_frontend.c#L859-L872

Can someone explain why creation of the broadcast route is
non-optional? Would a patch to make it optional be acceptable? Is it
safe for us to simply delete the route? We have a patch that simply
deletes the broadcast route after interface creation but don't know
why the Kernel code "makes sense".

You can read more information about the issue here:
https://github.com/coreos/flannel/pull/569

Thank You,

Brandon

fib_frontend: Add network specific broadcasts, when it takes a sense

[Brandon Philips]

Hello-

A number of us are working on an OSS overlay network system called flannel.
It is used in a variety of Linux container systems and one of the backends
is VXLAN.

The issue we have: when creating the VXLAN interface and assigning it an
address we see a broadcast route being added by the Kernel. For example if
we have 10.4.0.0/16 a broadcast route to 10.4.0.0 is created. This route is
unwanted because we assign 10.4.0.0 to one of our VXLAN interfaces.

However, the Kernel interface bring-up comment reads: Add network specific
broadcasts, when it takes a sense. The code is here:
https://github.com/torvalds/linux/blob/master/net/ipv4/fib_frontend.c#L859-L872

Can someone explain why creation of the broadcast route is non-optional?
Would a patch to make it optional be acceptable? Is it safe for us to
simply delete the route? We have a patch that simply deletes the broadcast
route after interface creation but don't know why the Kernel code "makes
sense".

You can read more information about the issue here:
https://github.com/coreos/flannel/pull/569

Thank You,

Brandon

Re: fib_frontend: Add network specific broadcasts, when it takes a sense

[Jiri Benc]

On Fri, 9 Dec 2016 15:41:52 -0800, Brandon Philips wrote:
> The issue we have: when creating the VXLAN interface and assigning it
> an address we see a broadcast route being added by the Kernel. For
> example if we have 10.4.0.0/16 a broadcast route to 10.4.0.0 is
> created. This route is unwanted because we assign 10.4.0.0 to one of
> our VXLAN interfaces.

Are you saying you're trying to assign the IP address 10.4.0.0/16 as a
unicast address to an interface? Then you'll run into way more problems
than the one you're describing. You can't have host part of the IP
address consisting of all zeros (or all ones). Just don't do it. Choose
a valid IP address instead.

 Jiri

Re: fib_frontend: Add network specific broadcasts, when it takes a sense

[Brandon Philips]

On Mon, Dec 12, 2016 at 9:30 AM, Jiri Benc <jbenc@redhat.com> wrote:
> On Fri, 9 Dec 2016 15:41:52 -0800, Brandon Philips wrote:
>> The issue we have: when creating the VXLAN interface and assigning it
>> an address we see a broadcast route being added by the Kernel. For
>> example if we have 10.4.0.0/16 a broadcast route to 10.4.0.0 is
>> created. This route is unwanted because we assign 10.4.0.0 to one of
>> our VXLAN interfaces.
>
> Are you saying you're trying to assign the IP address 10.4.0.0/16 as a
> unicast address to an interface? Then you'll run into way more problems
> than the one you're describing. You can't have host part of the IP
> address consisting of all zeros (or all ones). Just don't do it. Choose
> a valid IP address instead.

Yes, this is what we are doing; it is because of an upstream, to us,
address assignment so I will figure it out upstream.

Regardless, it is hard to find an RFC that says "simply don't do this
because _____". The closest I could find was RFC 922 after sending
this which says:

"There is probably no reason for such addresses to appear anywhere but
as the source address of an ICMP Information".

I will submit a patch that at least documents this RFC and quote.

Thanks!

Brandon

Re: fib_frontend: Add network specific broadcasts, when it takes a sense

[Jiri Benc]

On Mon, 12 Dec 2016 09:44:54 -0500, Brandon Philips wrote:
> Regardless, it is hard to find an RFC that says "simply don't do this
> because _____". The closest I could find was RFC 922 after sending
> this which says:

https://tools.ietf.org/html/rfc1812#section-5.3.5 is probably what
you're looking for.

 Jiri

Re: fib_frontend: Add network specific broadcasts, when it takes a sense

[David Miller]

From: Jiri Benc <jbenc@redhat.com>
Date: Mon, 12 Dec 2016 15:30:35 +0100

> On Fri, 9 Dec 2016 15:41:52 -0800, Brandon Philips wrote:
>> The issue we have: when creating the VXLAN interface and assigning it
>> an address we see a broadcast route being added by the Kernel. For
>> example if we have 10.4.0.0/16 a broadcast route to 10.4.0.0 is
>> created. This route is unwanted because we assign 10.4.0.0 to one of
>> our VXLAN interfaces.
> 
> Are you saying you're trying to assign the IP address 10.4.0.0/16 as a
> unicast address to an interface? Then you'll run into way more problems
> than the one you're describing. You can't have host part of the IP
> address consisting of all zeros (or all ones). Just don't do it. Choose
> a valid IP address instead.

Agreed.

Re: fib_frontend: Add network specific broadcasts, when it takes a sense

[Hannes Frederic Sowa]

On 12.12.2016 15:44, Brandon Philips wrote:
> On Mon, Dec 12, 2016 at 9:30 AM, Jiri Benc <jbenc@redhat.com> wrote:
>> On Fri, 9 Dec 2016 15:41:52 -0800, Brandon Philips wrote:
>>> The issue we have: when creating the VXLAN interface and assigning it
>>> an address we see a broadcast route being added by the Kernel. For
>>> example if we have 10.4.0.0/16 a broadcast route to 10.4.0.0 is
>>> created. This route is unwanted because we assign 10.4.0.0 to one of
>>> our VXLAN interfaces.
>>
>> Are you saying you're trying to assign the IP address 10.4.0.0/16 as a
>> unicast address to an interface? Then you'll run into way more problems
>> than the one you're describing. You can't have host part of the IP
>> address consisting of all zeros (or all ones). Just don't do it. Choose
>> a valid IP address instead.
> 
> Yes, this is what we are doing; it is because of an upstream, to us,
> address assignment so I will figure it out upstream.
> 
> Regardless, it is hard to find an RFC that says "simply don't do this
> because _____". The closest I could find was RFC 922 after sending
> this which says:
> 
> "There is probably no reason for such addresses to appear anywhere but
> as the source address of an ICMP Information".

Alternatively you can renumber the network to use /32 and add the
unicast routes for your /16 yourself.

Bye,
Hannes