If the output of the subprocess is empty, then an empty <bytes> object
is returned (b''), and not decoded into an empty <string> object.
This may result in errors such as:
info[109734]: executing /bin/ip -6 addr show eth0
networking[109734]: error: eth0: cannot use a string pattern on a
bytes-like object
error[109734]: eth0: cannot use a string pattern on a bytes-like object
- 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>
check if the bond mac address is correctly inherited from it's
first slave. There's a case where that might not be happening:
$ ip link show swp1 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show swp2 | grep ether
link/ether 08:00:27:04:d8:02 brd ff:ff:ff:ff:ff:ff
$ ip link add dev bond0 type bond
$ ip link set dev swp1 master bond0
$ ip link set dev swp2 master bond0
$ ip link show bond0 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link add dev bond1 type bond
$ ip link set dev swp1 master bond1
$ ip link show swp1 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show swp2 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show bond0 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$ ip link show bond1 | grep ether
link/ether 08:00:27:04:d8:01 brd ff:ff:ff:ff:ff:ff
$
ifupdown2 will automatically correct and fix this unexpected behavior
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
error: link_set_bridge_info_data_dry_run() takes exactly 3 arguments (4 given)
error: link_set_brport_with_info_slave_data_dry_run() got an unexpected keyword argument 'kind'
seems like when updating a method, it's associated dry-run method wasn't
updated accordingly. Maybe there is a way to programmatically check that
I will look into it.
warning: bridge: skipping port X invalid ether addr
warning: interface not recognized - please check interface configuration
Won't show on dry-run anymore
Log info for commands executed with utils.exec_command() weren't prefixed with
DRY-RUN.
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>
closes#58
In linux its possible to assign a vlan-aware bridge an ip address
For some use cases is it useful to restrict users from configuring
ips on bridges VA. This patch will let admins and distributions
decide if it is necessary to warn the user in such case.
The patch introduces a new 'address' policy:
vlan_aware_bridge_address_support: yes|no|on|off|0|1 (default to yes)
[16:46:09] root:~ # cat /var/lib/ifupdown2/policy.d/address.json
{
"address": {
"module_globals": {
"enable_l3_iface_forwarding_checks": "yes"
},
"defaults": {
"mtu": "1500",
"ip-forward": "on",
"ip6-forward": "on"
}
}
}
[16:46:16] root:~ # ifquery -a
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp
auto bridge
iface bridge
bridge-ports swp1
bridge-vlan-aware yes
address 10.10.10.10/32
[16:46:20] root:~ # ifup -a --syntax-check
[16:46:22] root:~ # echo $?
0
[16:46:33] root:~ # nano /var/lib/ifupdown2/policy.d/address.json
[16:46:47] root:~ # cat /var/lib/ifupdown2/policy.d/address.json
{
"address": {
"module_globals": {
"enable_l3_iface_forwarding_checks": "yes",
"vlan_aware_bridge_address_support": "no"
},
"defaults": {
"mtu": "1500",
"ip-forward": "on",
"ip6-forward": "on"
}
}
}
[16:46:48] root:~ # ifup -a --syntax-check
warning: bridge: ignoring ip address. Assigning an IP address is not allowed on bridge vlan aware interfaces
[16:46:51] root:~ # echo $?
1
[16:46:52] root:~ #
Reviewed-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
In linux its possible to assign an ip address to a vlan-aware bridge
For some use cases is it useful to restrict users from configuring ips on
bridges VA. This patch will let admins and distributions decide if it is
necessary to warn the user in such case.
The patch introduces a new configuration variable in:
/etc/network/ifudpown2/ifupdown2.conf
vlan_aware_bridge_address_support: yes|no|on|off|0|1 (default to yes)
[8:30:41] root:~ # cat /etc/network/ifupdown2/ifupdown2.conf | grep "vlan_aware_bridge_address_support"
[8:30:43] root:~ # ifquery bridge
auto bridge
iface bridge
bridge-ports swp1
bridge-vlan-aware yes
address 10.10.10.10
[8:30:46] root:~ # ifup bridge --syntax-check
[8:30:52] root:~ # echo $?
0
[8:30:54] root:~ # echo "vlan_aware_bridge_address_support=no" >> /etc/network/ifupdown2/ifupdown2.conf
[8:31:11] root:~ # ifup bridge --syntax-check
warning: bridge: ignoring ip address. Assigning an IP address is not allowed on bridge vlan aware interfaces
[8:31:14] root:~ # echo $?
1
[8:31:17] root:~ #
[8:31:20] root:~ # ifup -a
[8:31:22] root:~ # echo $?
0
[8:31:25] root:~ # ifquery bridge -c
auto bridge
iface bridge [fail]
bridge-vlan-aware yes [pass]
bridge-ports swp1 [pass]
address 10.10.10.10 [fail]
[8:31:29] root:~ # ifdown bridge && ifup bridge -v |& grep "bridge vlan aware interfaces"
info: bridge: ignoring ip address. Assigning an IP address is not allowed on bridge vlan aware interfaces
[8:31:57] root:~ #
Reviewed-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
This is a major update coming all at once from master-next branch
master-next branch was started with --orphan option which is basically a new
branch without history.
The major changes are:
- repackaging
- cleanup the directory tree
- rewritte setup.py to allow install from deb file or pypi (pip install)
- add a Makefile to make things (like building a deb) easier
- review all debian files
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
ifupdown2 code was one level deeper because ifupdown2 initially
had ifupdown2 and ifupdown2-addons as two separate packages.
Since they were combined into one package, it makes sense to
move all combined code under the top level directory
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
