Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Don't auto-set broadcast unless subnet larger than /31 #496

Merged

Conversation

brandt
Copy link
Contributor

@brandt brandt commented Oct 30, 2019

Since #248, adding an address automatically sets the broadcast if the broadcast address was not specified. This is undesirable when adding an IP with a prefixlen of /31 or /32. (Additional details in the issues linked below.)

This PR changes the behavior so that the broadcast is only automatically set if the prefixlen is /30 or larger.

Issue reported in:

See also:

Alternatives to this PR:

A. #472 - Adds AddrAddWithoutCalculatedBroadcast.
B. [email protected]9a85a61 - Breaking change to make auto-setting the broadcast address an opt-in feature.
C. already works - Suppress setting the broadcast when addr's broadcast address is set to 0.0.0.0. (This works today, but I'm not sure the behavior can be relied upon as a public API.)

Since [vishvananda#248](vishvananda#248), adding an address automatically sets the broadcast if the broadcast address was not specified. This is undesirable when adding an IP with a prefixlen of /31 or /32. (Additional details in the issues linked below.)

This changes the behavior so that the broadcast is only automatically set if the prefixlen is /30 or larger.

Issue reported in:

- vishvananda#329
- vishvananda#471

See also:

- [RFC 3021](http://tools.ietf.org/html/rfc3021)

Alternatives to this PR:

A. vishvananda#472 - Adds `AddrAddWithoutCalculatedBroadcast`.
B. [email protected]9a85a61 - Breaking change to make auto-setting the broadcast address an opt-in feature.
C. already works - Suppress setting the broadcast when addr's broadcast address is set to `0.0.0.0`. (This works today, but I'm not sure the behavior can be relied upon as a public API.)
@dannyk81
Copy link

@dannyk81 dannyk81 commented Oct 31, 2019

I think the approach of this PR is the optimal one.

Copy link
Contributor

@jellonek jellonek left a comment

Yeah, also IMO it looks better.

@vishvananda vishvananda merged commit aad0bae into vishvananda:master Nov 13, 2019
1 check passed
@brandt brandt deleted the suppress-auto-broadcast-calculation branch Dec 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants