All-Ones netmask is not needed for ACLs or flow logging #4440
Conversation
|
@eriknordmark Do you remember what was the use-case of the |
milan-zededa
force-pushed
the
remove-all-ones-netmask
branch
from
ded61d4 to
0cf9169
Compare
|
The description in https://eve-os.readthedocs.io/docs/APP-CONNECTIVITY/ matches my memory and your description above. We did have to add the "disable" knob because some NFV applications didn't work with that setting. Note that we need to communicate to users that the disable knob is no longer needed (and removed). Alternatively we can leave the knob in place and have it be a no-op. (I don't know if anybody notices the errors when a config is referring to a non-existant knob.) |
The DHCP server deployed by EVE for Local Network Instances assigns IP addresses to applications with a /32 netmask (all-ones) and uses the Classless Static Route Option (RFC 3442) to configure static routes for the NI subnet. This setup enforces routing even for east-west (app-to-app) traffic, which would otherwise only be forwarded if the actual NI subnet mask (e.g., /24) were used. This approach was historically implemented to prevent east-west traffic from bypassing ACLs and to ensure that connection tracking (conntrack) entries were created for flow logging purposes. However, it became unnecessary after we enabled the "net.bridge.bridge-nf-call-iptables" option, which ensures that even traffic forwarded by a bridge within EVE passes through iptables filtering and has conntrack entries created. Using a /32 netmask now offers no added value and has some drawbacks. First, applications may use DHCP servers with the Classless Route option disabled, resulting in obtaining all-ones netmask with no reachable destinations due to missing connected routes. Second, enforcing routing adds extra packet processing steps for traffic that could be directly forwarded between applications, increasing overhead and reducing network performance. We previously added an option to disable the all-ones netmask (while still keeping it enabled by default), but this has increased code complexity since it requires two distinct routing configurations to manage (and test). I propose removing the all-ones netmask configuration altogether to simplify the code and reduce packet processing overhead. While some may consider this a breaking change, I believe the change in the netmask should not impact applications as long as IP addresses are preserved and the overall routing/bridging functionality remains consistent across EVE upgrades (the set of reachable destinations does not change). Signed-off-by: Milan Lenco <milan@zededa.com>
milan-zededa
force-pushed
the
remove-all-ones-netmask
branch
from
0cf9169 to
a225170
Compare
Good point, I didn't realize that we will publish error in ZInfoDevice.ConfigItemStatus when undefined config item is being used. I decided to leave the knob in place as suggested and just added comment that it no longer has any effect. |
There was a problem hiding this comment.
Can you put some text in CONFIG-PROPERTIES.md that the knob no longer needs to be set since we now work without the all-ones netmask in all cases but the knob remains to avoid errors if users are setting the knob.
Feel free to do that doc change as a separate PR and merge this one ahead if that makes sense.
|
@milan-zededa I see lots of failures in the Jenkins-run ztests for this, but that seems to be due to an earlier xen image having problems. |
We do not have this knob documented in CONFIG-PROPERTIES.md. Should I still mention it there even though it no longer has any effect? |
Sorry, I forgot that we had intentionally left this out. |
The DHCP server deployed by EVE for Local Network Instances assigns IP addresses to applications with a
/32netmask (all-ones) and uses the Classless Static Route Option (RFC 3442) to configure static routes for the NI subnet. This setup enforces routing even for east-west (app-to-app) traffic, which would otherwise only be forwarded if the actual NI subnet mask (e.g.,/24) was used.This approach was historically implemented to prevent east-west traffic from bypassing ACLs and to ensure that connection tracking (conntrack) entries were created for flow logging purposes. However, it became unnecessary after we enabled the
net.bridge.bridge-nf-call-ip(6)tablesoption, which ensures that even traffic forwarded by a bridge within EVE passes through iptables filtering and has conntrack entries created.Using a
/32netmask now offers no added value and has some drawbacks. First, applications may use DHCP servers with the Classless Route option disabled, resulting in obtaining all-ones netmask with no reachable destinations due to missing connected routes. Second, enforcing routing adds extra packet processing steps for traffic that could be directly forwarded between applications, increasing overhead and reducing network performance.We previously added an option to disable the all-ones netmask (while still keeping it enabled by default), but this has increased code complexity since it requires two distinct routing configurations to manage (and test). I propose removing the all-ones netmask configuration altogether to simplify the code and reduce packet processing overhead. While some may consider this a breaking change, I believe the change in the netmask should not impact applications as long as IP addresses are preserved and the overall routing/bridging functionality remains consistent across EVE upgrades (the set of reachable destinations does not change).
This PR is part of a series of network performance optimizations coming into EVE, see documentation (will be submitted in a separate PR)