For some reason es-sys-mac (IFLA_BOND_AD_ACTOR_SYSTEM) is not part
of the netlink dump if requested by non-root user. This commit adds
a log info and will ignore es-sys-mac in that case.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
Three issues:
- when `hwaddress` is removed from an SVI (on top of a bridge), the svi
mac is not resetted back to the bridge mac: fixed
- when `hwaddress` is used on an svi, stale fdb enties were added with the
bridge mac: fixed
- on ifdown we were leaving a leftover fdb entry on the deleted svi: fixed
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
When a policy dhcp-wait is false the dhcp client is run directly in
background.
But, in most cases, the client won't have the time to find an address
before a check occur.
This is making the client being killed nearly every time.
The obvious solution here is to not check ips differences when no-wait
is asked by the policy.
It is only valid for balance-rr and balance-xor.
One Example is:
auto bond0
iface bond0 inet
bond-slaves ens21 ens22
bond-mode balance-rr
bond-arp-interval 100
bond-arp-ip-target 8.8.8.8
address 10.10.10.1/24
Signed-off-by: Sven Auhagen <sven.auhagen@voleatech.de>
Upon ipv6_dad_handling_enabled module global parameter set to true, the
address addon will handle ipv6 dad tentatives by either
* set nodad when adding an ipv6 address
* waiting for dad to finish or warn of a timeout
This handling should be quick close to the ifupdown process.
AttributeGeneric cannot be used unless having it's length defined.
This change allow address flags such as optimistic, nodad or others
to be set with the add_attribute packet method.
AttributeGeneric cannot be used unless having it's length defined.
This change allow address flags such as optimistic, nodad or others
to be set with the add_attribute packet method.
On older ubuntu version bridge_binding is not supported, we can't rely
on `ip link help` to detect this. We have manually check if the first
netlink request is rejected then retry with iproute2.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
According to interfaces(5) [1]:
When sourcing files or directories, if a path doesn't have a leading slash, it's considered relative to the directory containing the file in which the keyword is placed. In the example above, if the file is located at /etc/network/interfaces, paths to the included files are understood to be under /etc/network.
Adapt the implementation to adhere to the documented behaviour.
[1] https://manpages.debian.org/buster/ifupdown/interfaces.5.en.html
