You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Rename all physical ethernet interfaces to something consistent, say enMAC so enAABBCCDDEE01 for example. We track everything based on MAC so that will be easier than dealing with the usual variety of naming schemes.
Every interface, bond or vlan defined above should be internally implemented as a bridge in which we then place either the physical interface, a bond that we created internally or a vlan that we created internally.
The bridge itself is what the user names, the intermediate bond and vlan interfaces are named by us and their naming doesn't really matter (other that we should use a consistent prefix so we can easily ignore those).
Anything that's not defined in the configuration should be set to link DOWN and generally be ignored.
All bridges should have VLAN filtering enabled and be configured to allow all VLAN tags into the bridge
If a VLAN id is directly set on an interface or bond, it means that the resulting bridge should have that VLAN id set as its physical/access VLAN rather than the default (0)
VLAN interfaces are used when multiple bridges are needed and so one can't just use the vlan field on the parent. The example above show one such case where the management bridge (bond) uses the VLAN 100 as its access VLAN, but there's also VLAN 1234 that we want to split out of that bridge and into its own bridge (in this case to give it to OVN).
DHCPv4, DHCPv6 and SLAAC are implemented through special address and route destinations, they can be used for addressing only (no routes) but cannot be used for route-only.
Default is for all dynamic addressing (DHCPv4, DHCPv6, SLAAC) to be completely disabled on any managed interface
The roles don't directly come into play with networkd generated configuration but they will be used for bootstrapping as a way to select specific interfaces/addresses across multiple machines by asking for whatever interface has a given role to be used rather than having to provide the interface name or address
The text was updated successfully, but these errors were encountered:
For anyone wondering, yes, there are a lot of similarities with netplan :)
We can't quite use netplan directly as we're trying to keep our dependencies very minimal and so having to pull python3 and a bunch of python packages would be a bit problematic (though we still need to untangle that with the OVN packages too).
This also only implements a small subset of what netplan can do and then does a few things that are very specific to our environment, like the fact that we generate bridges for everything and always enable VLAN filtering (which netplan still doesn't support).
We also will be shipping OpenVswitch as part of Incus OS, but we intend to keep things purposefully separate with networkd being used for all the host level networking and then OpenVswitch being used exclusively for OVN. This avoids a potential OVN related issue being able to take down the entire system by corrupting the OVS database.
We need to extend the
internal/systemd
package with functions related to networkd:GenerateNetworkConfiguration
=> Clears any existing configuration in /run, turns our network definition struct into networkd configuration filesApplyNetworkConfiguration
=> Implement aRestartUnit
insystemctl.go
and then call that forsystemd-networkd
My current thinking for the network config is something like this (as YAML):
For a much simpler example:
Behind the scenes we should:
enMAC
soenAABBCCDDEE01
for example. We track everything based on MAC so that will be easier than dealing with the usual variety of naming schemes.The text was updated successfully, but these errors were encountered: