-
Notifications
You must be signed in to change notification settings - Fork 13
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Allow to configure custom network adapter labels
EVE already offers adapter labels "uplink" and "freeuplink" to match a specific group of ports to provide external connectivity for a network instance. We should allow users to define and assign their own adapter labels and support the following new network instance use-cases: 1. Switch network instance with multiple ports: user should be able to select a group of ports, all of which will be bridged together under one switch NI. EVE should then automatically run the STP protocol for the bridge to avoid bridge loops and broadcast storms. 2. Local network instance with multiple ports: the routing table on the host (EVE) side will contain routes from all selected ports and will be used to select output port for the given flow. For the default route we should: a) allow the user to pick the "default output interface" b) periodically test port connectivity and failover between default gateways when currently used one has broken connectivity a) and b) could be combined together to allow the user to select a subset of NI ports for the default route and then let EVE to pick one of them based on the probing results. We should also allow to limit a port-forwarding rule to only a subset of ports used by a local network instance. This can be done by defining a new ACEMatch type "adapter" where value is adapter label to match. Currently, EVE supports a variant of the second use-case for hard-coded "uplink" and "freeuplink" labels. It would make sense to unify the behaviour between these existing labels and the user-defined ones. This means that we would make small change to the current implementation: when "uplink" or "freeuplink" is selected for a local network instance, the NI routing table will have IP routes from *all* matching (mgmt) ports and the default route will be selected by connectivity testing. This is different to the present behaviour, where EVE installs only routes of the port selected by connectivity testing into the NI routing table. But lets say that there are 2 mgmt ports: eth0 and eth1, and connectivity testing selected eth0. Then even if app is accessing hosts which are directly inside the eth1 subnet, traffic will be routed via eth0, which can be confusing. Also, user-defined static routes for eth1 are not present in the routing table and therefore inactive when eth0 is selected. The idea is to apply connectivity testing to only default route selection. Signed-off-by: Milan Lenco <milan@zededa.com>
- Loading branch information
1 parent
6fe2bd3
commit d20da30
Showing
4 changed files
with
124 additions
and
7 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters