This reverts commit 65beb82662576c047a281389bd663589dcba09db.
it's causing testifupdown2.py:TestMakoJson to fail... Basically this commit
uncomment codes which parse mc value from brctl output. So `ifquery -r` output
is different (this new attribute show up under the bridge). TestMakoJson at
some point does:
$ ifquery -a -r -t json > running_json
Then later
$ ifup -i running_json...
This ifup fails on:
...
warning: br0: unsupported attribute 'bridge-mclmt'
...
This reverts commit a3d36dd86d6888a0b61b506a534c24ea4867a18f.
Ticket CM-14516 has been filed to track this
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
Ticket: CM-13779
Reviewed By: roopa, satish, julien
Testing Done: testing the config given in the CM
mstpctl showportdetail <bridge> command won't output anything when
bridge-stp is off, therefore ignore mstpctl default attributes during
ifquery -c --with-defaults
This patch also consistently updates bridge and bridge port cache
at the same time.
Earlier bridge and bridge port cache were not consistent
because of the early return condition
attrs = MSTPAttrsCache.get(bridgename)
if attrs:
return attrs
If either of bridge port cache and bridge cache is updated, function used to
return inconsistent cache values
Signed-off-by: Nikhil Gajendrakumar <nikhil@cumulusnetworks.com>
Ticket: CM-14472
Reviewed By: Roopa, Julien
Testing Done: used the config mentioned in CM
Fix introduced by "addons: address: add both v4 and v6 gateways
instead of just one" changed the way gateway commands were configured.
ifupdown2 does not replay default gateway commands on ifreload
This patch ensures all the gateway commands at every ifreload are replayed
Signed-off-by: Nikhil Gajendrakumar <nikhil@cumulusnetworks.com>
Ticket: CM-8401
Reviewed By: Roopa, Julien
Testing Done: tested on all bridge mstpctl attributes.
This patch resets th following bridge attributes to defauls when
users remove settings from interface config file.
mstpctl-treeprio
mstpctl-ageing
mstpctl-fdelay
mstpctl-maxhops
mstpctl-maxage
mstpctl-txholdcount
mstpctl-forcevers
mstpctl-hello
Added an api in policy manager to get policy default value of any
module attribute.
Added a cache for bridge attributes to save some runtime
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
Ticket: CM-14386
Reviewed By: Roopa, Purna, NIkhil G
Testing Done:
We have incorrect Address Range and Default g/w configuration. Kernel will give
error in such condition and ignore the route. but ifupdown2 is masking this
error and making user in blind spot.
$ ifdown -a -X eth0
$ ifreload -a
error: h2t_c-1: cmd 'ip route add table DataVrf1080 default via 3.0.0.1 dev h2t_c-1' failed: returned 2 (RTNETLINK answers: Network is unreachable
)
$ echo $?
1
$ ifquery -a
auto h2t_c-1
iface h2t_c-1
address 6.0.0.1/26
address 2001:fee1::1/64
bond-slaves swp1 swp2
bond-mode 802.3ad
bond-miimon 100
bond-min-links 1
bond-xmit-hash-policy layer3+4
bond-lacp-rate 1
mtu 9152
alias Local Node/s hostd-1-1 and Ports swp1 swp2 <==> Remote Node/s torc-1-1 torc-1-2 and Ports swp7 swp7
gateway 3.0.0.1
gateway 2001:fee1::1
vrf DataVrf1080
auto DataVrf1080
iface DataVrf1080
vrf-table 1080
$
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-14209
Reviewed By: Julien
Testing Done:
vids was a list and pvid is not a list, hence the check was failing
$ cat /etc/network/interfaces
auto vxlan1000
iface vxlan1000
vxlan-id 1000
vxlan-local-tunnelip 172.16.20.103
vxlan-remoteip 172.16.20.106
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-ports swp1 vxlan1000
bridge-vids 100 200
$
$ ifdown -a -X eth0
$ ifreload -a -s
warning: vxlan1000: `bridge-access` attribute is mandatory when vxlan device (vxlan1000) is part of vlan aware bridge (bridge)
$ ifreload -a
warning: bridge: `bridge-access` attribute is mandatory when vxlan device (vxlan1000) is part of vlan aware bridge (bridge)
error: bridge: errors applying port settings
$ ifreload -a
error: vxlan1000: `bridge-access` attribute is mandatory when vxlan device (vxlan1000) is part of vlan aware bridge (bridge)
warning: bridge: `bridge-access` attribute is mandatory when vxlan device (vxlan1000) is part of vlan aware bridge (bridge)
error: bridge: errors applying port settings
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
This reverts commit 4e2db079564a5055a03d2e7e97807b7956c6e110.
reverting because of some reported false errors.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-14209
Reviewed By: Roopa
Testing Done:
$ cat /etc/network/interfaces
auto vxlan1000
iface vxlan1000
vxlan-id 1000
vxlan-local-tunnelip 172.16.20.103
vxlan-remoteip 172.16.20.106
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-ports swp1 vxlan1000
bridge-vids 100 200
$
$ ifdown -a -X eth0
$ ifreload -a -s
warning: vxlan1000: `bridge-access` attribute is mandatory when vxlan device (vxlan1000) is part of vlan aware bridge (bridge)
$ ifreload -a
warning: bridge: `bridge-access` attribute is mandatory when vxlan device (vxlan1000) is part of vlan aware bridge (bridge)
error: bridge: errors applying port settings
$ ifreload -a
error: vxlan1000: `bridge-access` attribute is mandatory when vxlan device (vxlan1000) is part of vlan aware bridge (bridge)
warning: bridge: `bridge-access` attribute is mandatory when vxlan device (vxlan1000) is part of vlan aware bridge (bridge)
error: bridge: errors applying port settings
$
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-13815
Reviewed By:
Testing Done: Tested remote purging
vxlan purging remotes is a feature where we clean up
existing fdb remote entries in favor of the ones specified in the
interfaces file. Obviously in precense of an external controller
like bgp or vxrd this is not a good thing because these remotes
maybe installed by these external controller daemons.
This patch makes the purgining behaviour explicit by a new attribute.
We will ship with a default policy file which sets vxlan-purge-remotes to no.
This also cleans up a bug introduced by fix to CM-13767 where we were
trying to delete default remote entry pointing to the local ip.
more details below.
problem:
for static configuration, ifupdown2 has some code to "purge" existing
default remote fdb entries and install
new ones corresponding to the ones specified in the interfaces file
(with vxlan-remoteip).
For non-static configuration (ie in presence of an external controller),
it skips this "purge"...because these entries
maybe added by an external controller. To detect that there is no
external controller running..., today it
checks if the vxrd process is running or not. We need to extend this
check to now include bgp (for evpn)...and it gets trickier with bgp
since just checking the quagga pid is not good.
Solution:
I would like to make this purging explicit with an attribute. This patch
adds a 'vxlan-purge-remotes yes|no' attribute. vxlan remote address purging
will take into affect when:
vxlan-remoteip attribute is present in the interfaces file
or
vxlan-purge-remotes is set to 'yes'
We will ship a ifupdown2 default policy file to disable purging by
default (vxlan-purge-remotes no).
For existing customer deployed static configs, since the interfaces file
will already have remote entries, this change
will behave as existing code (ie purge = yes).
For existing vxrd deployments, as long as already deployed interfaces
files have no vxlan-remoteip entries,
this patch does not change any behavior (can people confirm that
existing vxrd deployments have no vxlan-remoteip entries in their
interfaces ?)
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Daniel: Having both bridge-vids and bridge-trunk at the
net add interface NAME <TAB>
level creates confusion… need to remove bridge-vids
This commit adds bridge-trunk as an alias for bridge-vids
Ticket: CM-14041
Reviewed By: Roopa, Nikhil G
Testing Done:
$ ifquery -a
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-ports swp1 swp9
bridge-trunk 2-100
bridge-pvid 101
bridge-stp on
$ ifrelaod -a
$ ifquery -a -c
auto bridge
iface bridge [pass]
bridge-vlan-aware yes [pass]
bridge-ports swp1 swp9 [pass]
bridge-stp yes [pass]
bridge-pvid 101
bridge-trunk 2-100 []
$ ifquery -a -r
auto bridge
iface bridge
bridge-vlan-aware yes
bridge-ports swp9 swp1
bridge-stp yes
bridge-pvid 101
bridge-vids 2-101
$ net show bridge vlan
port vlan ids
swp1 2-100
101 PVID Egress Untagged
swp9 2-100
101 PVID Egress Untagged
bridge None
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
This features will allow attributes to have aliases. Our use case today is
between bond-slaves and bridge-ports, which be a little confusing.
It follows the kernel api and existing linux tools. Bonding driver calls them
slaves and to the bridge driver they are ports.
With NCLU we we would like to be more consistent. We will now also support
"bond-ports"a
Ticket: CM-12763
Reviewed By: Roopa
Testing Done:
$ ifquery -a -c
auto bond0
iface bond0 [pass]
bond-slaves swp1 [pass]
auto bond1
iface bond1 [pass]
bond-ports swp2 [pass]
root@cel-redxp-06:~# ifquery -a -r
auto bond0
iface bond0
bond-lacp-bypass-allow 0
bond-slaves swp1
bond-mode 802.3ad
bond-use-carrier 1
bond-lacp-rate 1
bond-min-links 1
bond-miimon 100
bond-xmit-hash-policy layer3+4
auto bond1
iface bond1
bond-lacp-bypass-allow 0
bond-slaves swp2
bond-mode 802.3ad
bond-use-carrier 1
bond-lacp-rate 1
bond-min-links 1
bond-miimon 100
bond-xmit-hash-policy layer3+4
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-13434
Reviewed by: julien, nikhil, daniel
Testing Done: ifreload and multiple down [yes|no] sequences under
physical and logical interfaces (ifupdown2-tests test case is pending)
This also moves the fix done for CM-4125 (inet manual handling for
logical devices) into a single place under ifupdownmain.
attribute 'link-down [yes|no]' will not work in all cases when 'inet manual'
is used. This is only to preserve the semantics of 'inet manual'.
Best use of 'link-down [yes|no]' is to use it without 'inet manual'..
they are conflicting features anyways.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-13434
Reviewed by: julien, nikhil, daniel
Testing Done: ifreload and multiple down [yes|no] sequences under
physical and logical interfaces (ifupdown2-tests test case is
pending)
This also moves the fix done for CM-4125 (inet manual handling for
logical devices) into a single place under ifupdownmain.
attribute 'link-down [yes|no]' will not work in all cases when 'inet
manual' is used. This is only to preserve the semantics of 'inet manual'.
Best use of 'link-down [yes|no]' is to use it without 'inet manual'..
they are conflicting features anyways.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
This reverts commit a21c63b65ca297ca6f23c919bbb74e58f9e04a07.
Moving this to link-down in link.py addon module..due to conflict
with usercmds.py
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
This reverts commit 02e00f54bbf9d0ca647c1ed2c39f7af28b6653b7.
reverting this commit to move it to link.py addon module.
down conflicts with usercmds.py 'down'
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-13434
Reviewed by: julien, nikhil, daniel
Testing Done: ifreload and multiple down [yes|no] sequences under
physical and logical interfaces (ifupdown2-tests test case is pending)
This also moves the fix done for CM-4125 (inet manual handling for
logical devices) into a single place under ifupdownmain.
attribute 'down [yes|no]' will not work in all cases when 'inet manual'
is used. This is only to preserve the semantics of 'inet manual'.
Best use of 'down [yes|no]' is to use it without 'inet manual'..
they are conflicting features anyways.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-14146
Reviewed By: Roopa, Daniel W, Nikhil G
Testing Done:
bridge-portmcfl attribute needs to validate an <interface-yes-no-0-1-list>
to support the yes/no syntax.
This is an incremental commit for CM-8866
$ ifquery -a
auto br0
iface br0
bridge-ports swp1 swp2 swp3 swp4
bridge-portmcfl swp1=yes swp2=no swp3=1 swp4=0
auto br1
iface br1
bridge-vlan-aware yes
bridge-ports swp5 swp6 swp7 swp8
auto swp5
iface swp5
bridge-portmcfl yes
auto swp6
iface swp6
bridge-portmcfl no
auto swp7
iface swp7
bridge-portmcfl 1
auto swp8
iface swp8
bridge-portmcfl 0
$
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-13044
Reviewed By: Roopa, Nikhil G, Daniel W,
Testing Done:
For some reason we can't simply write into a file when we want to purge the
ifalias, we have to exec a command. I wasn't able to make it work in any
other way.
add an alias to an interface, ifreload, ip link show interface
modify it, ifreload, ip link show interface
remove it, ifreload, ip link show interface
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-13044
Reviewed By: Roopa, Nikhil G, Daniel W,
Testing Done:
For some reason we can't simply write into a file when we want to purge the
ifalias, we have to exec a command. I wasn't able to make it work in any
other way.
add an alias to an interface, ifreload, ip link show interface
modify it, ifreload, ip link show interface
remove it, ifreload, ip link show interface
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-14158
Reviewed By: julien, nikhilg
Testing Done: Tested with a bridge config without bridge-ports line.
NCLU wants the ability to create a bridge without ports (to add them
later). Today we cannot specify an attribute without values. We get the
below error:
info: processing interfaces file /etc/network/interfaces
error: /etc/network/interfaces: line10: iface bridge: invalid syntax
'bridge-ports'
The error comes from a generic parser check...we will
need to add exceptions to the generic check if we allow attributes
without values.
This patch simply identifies a bridge by both the bridge-vlan-aware and
bridge-ports keyword. For vlan aware bridge it will simply work.
For old bridge driver nclu will have to specify 'bridge-vlan-aware no'
to achieve the same. nclu does not support old bridge
model today, so defering the old bridge driver discussion for later.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-8401
Reviewed By: Roopa, Julien
Testing Done: tested on all bridge mstpctl attributes.
This patch resets th following bridge attributes to defauls when
users remove settings from interface config file.
mstpctl-treeprio
mstpctl-ageing
mstpctl-fdelay
mstpctl-maxhops
mstpctl-maxage
mstpctl-txholdcount
mstpctl-forcevers
mstpctl-hello
Added an api in policy manager to get policy default value of any
module attribute.
Added a cache for bridge attributes to save some runtime
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
Ticket: CM-13996
Reviewed By: Roopa, Nikhil G
Testing Done:
With the following configuration:
auto bond0
iface bond0
bond-min-links 1
bond-mode 802.3ad
bond-slaves eth0 eth1 eth2
bond-xmit-hash-policy layer3+4
auto vlan0
iface vlan0
vlan-raw-device bond0
address 10.132.253.4/31
address 2a03:2260:2342:fe09::1/126
On non cumulus distribution bond-min-links doesn't default to 1
For some reasons the min_links value wasn't cache with the other
bond values, if you issue an ifreload on a running/existing configuration
since the min_links value is not cache ifreload will down the bond, set
min_links to 1, then bond up. When taking the bond down the kernel will
also flush the ipv6 address but not the ipv4 address...
The issue was reported by an ifupdown2 contributor on github. He find out
that when running ifreload the ipv6 were flushed.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-13967
Reviewed By: julien, nikhil
Testing Done: tested failing config in the bug
This patch fixes a cache_update problem caught during mtu updates.
Cache updates were failing silently, leaving stale cache values.
For the below config, ifupdown2 was falsely reporting an mtu error,
because the cache had a stale mtu default value
$ifquery peerlink-3 peerlink-3.4094
auto peerlink-3
iface peerlink-3
bond-slaves swp32s0 swp32s1
bond-mode 802.3ad
mtu 9202
auto peerlink-3.4094
iface peerlink-3.4094
address 27.0.0.11/32
mtu 9202
$ifreload -a
warning: peerlink-3.4094: vlan dev mtu 9202 is greater than lower realdev peerlink-3 mtu 1500
Before patch:
sequence of events:
- build cache with current system running mtu
- link set mtu 9202 on peerlink-3
- update cache for peerlink-3 to 9202 <---- cache update fails
- when processing peerlink-3.4094, query cache for lowerdev peerlink-3
mtu: this returns 1500 <--- stale cache value
- print warning
After patch:
sequence of events:
- build cache with current system running mtu
- link set mtu 9202 on peerlink-3
- update cache for peerlink-3 to 9202 <---- cache updates to 9202
- when processing peerlink-3.4094, query cache for lowerdev peerlink-3
mtu: this returns 9202
- success and proceed
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-13817
Reviewed By: Roopa, Kanna, Nikhil G
Testing Done:
1) use inet and inet6 dhcp in interfaces file
2) do a ifup -v
3) make sure dhclient v4 and v6 is running
4) now remove inet6 dhcp section
5) ifreload -a -v (should kill dhclient6)
6) replace inet by inet6
7) ifreload -a -v (should kill dhclient4 and exec dhclient6)
etc.. I played with all possible combinations
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-13737
Reviewed By: Roopa, Nikhil G
Testing Done:
Incremental commit for CM-13737
Create a policy file such as:
$ cat /var/lib/ifupdown2/policy.d/defaults_policy.json
{
"README": "This file is automatically generated. Do not edit this file.",
"ethtool": {
"defaults": {
"link-autoneg": "off",
"link-duplex": "full",
"link-speed": "1000"
},
"iface_defaults": {}
}
}
then do ifdown lo && ifup lo
without this patch or af8734d18a9e173a89db982285e801eb31deab5d
you would reproduce the fail
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
It was initially set in a place where only interfaces with
dependencies were processed. This patch moves it to the right
place.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
auto br0
iface br0
bridge-ports swp1 swp2
bridge-ports swp3 swp4
running ifquery in this configuration gaves us 2 identical warnings:
warning: br0: ignoring duplicate bridge-ports lines: ['swp3 swp4']
warning: br0: ignoring duplicate bridge-ports lines: ['swp3 swp4']
when running ifreload -a we still see 2 warnings, this will need to be looked
at later.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
