the mcast group set code was not using the right api
to get mcast groups.
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
'bridge flood macs are deleted everytime ifreload is triggered even without any changes to e/n/i config'
this was happening because ifupdown2 was checking the live fdb entries and calculating the delta between
the new and old config. Now we are simply checking the old and new ifupdown2 (/e/n/i) config to avoid
messing with macs added by the control plane
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
fdb entries can be added by FRR, so we won't be checking the running
state if there's no record of a user configuration in /e/n/i
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
Currently mixing SVDs and TVDs on the same system is not supported,
regardless of whether they are in the same vlan-aware bridge or
across different ones. NVUE will configure all VNIs as SVDs by
default so this would hopefully only arise if a user edits
/etc/network/interfaces and manages their configuration with ifupdown2.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
The pre-mature setting of mcast fdbs led to inconsistent state in
mcast grp registration resulting in a deadlock seen in #2638104
more kernel changes towards #2638104 are in progress
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
vxlan-mcastgrp-map config enhancements:
- support for multi-line vxlan multicast group config.
- support for vni range config.
- support for mcast grp range config.
- support for mcast network config.
Example:
vxlan-mcastgrp-map 10001=239.5.2.1
vxlan-mcastgrp-map 10002=239.5.2.2
vxlan-mcastgrp-map 10003=239.5.2.3
vxlan-mcastgrp-map 10005-10008=239.10.39.121
vxlan-mcastgrp-map 10010-10020=239.10.39.152-239.10.39.162
vxlan-mcastgrp-map 10005-10002=239.10.0.0/24
Reviewed-by: Julien Fortin <jfortin@nvidia.com>, Roopa Prabhu <roopa@nvidia.com>, Scott Laffer <slaffer@nvidia.com>
Signed-off-by: Scott Laffer <slaffer@nvidia.com>, Quentin Zilberberg <qzil@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
- create single vxlan device with vnifilter flag
- install vni filter with vnis from bridge-vxlan-vni-map
- vni filter can only be applied when the vxlan interface
is in down state
- toggling of vni filter is unsupported (maybe in the future)
- vni filter on a single vxlan or collect metadata/external
device is a new kernel feature yet to be upstreamed
- move vlan/vni id math helpers to utils.py
Reviewed-by: Julien Fortin <jfortin@nvidia.com>
Signed-off-by: Roopa Prabhu <roopa@nvidia.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
updating an existing singe-vxlan-device is not supported yet, we should warn
the user accordingly.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
When clagd anycast ip configuration changes on an existing setup, we have two issues:
- populate_dependency_info is run twice (in the ifreload case), first on the new
ifaceobjs, then on the old ifaceobjs. Thus hitting vxlan.get_dependent_ifacenames twice
where vxlan._clagd_vxlan_anycast_ip is set (the first time properly, then reset to it's
old value).
The fix: add a "old_ifaceobjs" flag to avoid resetting vxlan._clagd_vxlan_anycast_ip
- when clagd anycast ip changes, clagd also updates the vxlan's ip but there's a chance
that the ifupdown2 cache won't get the netlink notification in time before UP ops are
running on the vxlans, running on a stale cache is no bueno.
The fix: add additional checks to see if we should trust the cache of not.
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
This allows syntax checking to pass for fields like vxlan-ttl/vxlan-tos
which can be a number in a range OR a string value representing a special
meaning (0-255 or "auto", for instance). Without this, you can only pass
a --syntax-check for such fields if your value is one of those literally
specified because, for instance, "64" is not "auto", "0", or "255":
invalid value "64": valid attribute values: ['0', '255']
info: exit status 1
Note that _applying_ such configuration still works, because netlink's
acceptance criteria are independent of ifupdown2's.
fix vxlan-tos inherit = 1 (was set to 0)
and other fixes to make sure we don't unnecessarily set
those attributes on vxlan creation
Signed-off-by: Julien Fortin <jfortin@nvidia.com>
this patch adds support for the vxlan-mcastgrp attribute on single
vxlan device. Prior to this commit the vxlan-mcastgrp was only
applied to regular vxlans.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
When creating a single-vxlan device we were sending local tunnel ip address with ip
network prefix. This patch avoid the following error:
error: cmd '/bin/ip link add dev vxlan0 type vxlan external local 27.0.0.9/32 dstport 4789' failed: returned 1 (Error: any valid address is expected rather than "27.0.0.9/32".
)
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
As mentioned in a previous commit:
python3 ipaddress behave differently from python2-ipaddr, this is
a serious problem for us since it breaks most of the ip addresses
code.
>>> import ipaddress
>>> ipaddress.ip_network("10.10.10.242/10", False)
IPv4Network('10.0.0.0/10')
This is a problem for us, so we need to use a custom IPNetwork object.
Our custom IPNetwork object uses ipaddress.IPAddress under the hood
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
IPNetwork doesn't exists anymore and is replaced by ip_network. IPv?Network (4 and 6)
objects take an optional argument "strict" that defaults to True. If strict is set
and the ip address has the host bit set it will raise an exception. This is bad
for ifupdown2, so we need to replace all calls to IPNetwork and IPv?Network with
function who will set strict to False. That way we can limit the number of changes
for this patch.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
