addons: tunnel: Add support for GRETAP tunnels. (#34)
This commit adds support to configure and check gretap tunnels. An example
configuration could look like this:
iface tap0 inet tunnel
mode gretap
local 10.132.255.3
endpoint 10.132.255.1
ttl 64
mtu 1400
tunnel-physdev eth0
#
address 10.10.0.1/2
ifup will happily configure the interface (which it does even without this
patch) and ifquery now can successfully validate the configure interface:
cr03.in.ffho.net:~# ifquery -c tap0
iface tap0 inet tunnel [[ OK ]]
tunnel-physdev eth0 [[ OK ]]
endpoint 10.132.255.1 [[ OK ]]
local 10.132.255.3 [[ OK ]]
mode gretap [[ OK ]]
ttl 64 [[ OK ]]
mtu 1400 [[ OK ]]
address 10.10.0.1/24 [[ OK ]]
Signed-off-by: Maximilian Wilhelm <max@sdn.clinic>
addons: batman_adv: Add support for more B.A.T.M.A.N. adv. attributes. (#35)
* addons: batman_adv: Rework B.A.T.M.A.N. adv. attribute handling.
This commit reworks the internal handling of B.A.T.M.A.N. adv. attributes
within the plugin. The new approach on setting and checking attributes is
more generic and allows adding more B.A.T.M.A.N. adv. which should be set
as attributes of an B.A.T.M.A.N. adv. interface in a simple way.
This commit does not introduce any changes visibile to the user.
Signed-off-by: Maximilian Wilhelm <max@sdn.clinic>
* addons: batman_adv: Add support for more B.A.T.M.A.N. adv. attributes.
This commit adds supports for setting the following optional attributes:
* gw-mode (one of { off, client, server })
* multicast-mode (can be 'enabled' or 'disabled')
* distributed-arp-table (cat be 'enabled' or 'disabled')
addons: address: Fix handling of 'pointopoint' attr. (#23)
Due to a simple logic bug the 'pointopoint' attribute was ignored when
specifying and address as <ip/mask> and only considered when IP and mask
where given seperately. This commit fixes this behaviour.
When configured in ptp mode »ip addr« will show the IP address without a
netmask which will make »ifquery -c« mark the IP as failed. The check has
been fixed, too.
Signed-off-by: Maximilian Wilhelm <max@rfc2324.org>
Julien Fortin [Thu, 23 Feb 2017 09:42:34 +0000 (16:42 +0700)]
sbin: start-networking: adjust allow-hotplug behavior to ifupdown
Ticket: Bug#855598: src:ifupdown2: allow-hotplug behaves differently, not UPing interfaces
Reviewed By: Roopa
Testing Done: mark an interface (ethX) as hotplug then reboot
This commit adds support for configuring GRE/IPIP/SIT tunnel interfaces as know
from previous versions of ifupdown. Currently only configuration checks for GRE
and SIT tunnels are implemented.
A tunnel interface configuration could look like this:
auto gre42
iface gre42 inet tunnel
mode gre
local 198.51.100.1
endpoint 203.0.113.2
#
# optional tunnel attributes
ttl 64
mtu 1400
tunnel-physdev eth0
#
address 192.0.2.42/31
address 2001:db8:d0c:23::42/64
auto he-ipv6
iface he-ipv6 inet tunnel
mode sit
endpoint 203.0.113.6
local 198.51.100.66
#
# optional tunnel attributes
ttl 255
mtu 1466
tunnel-physdev vrf_external
#
address 2001:db8:666::2/64
Signed-off-by: Maximilian Wilhelm <max@rfc2324.org>
batman_adv: Ignore non-existing batman interface when setting up batman iface.
Previously a single non existing batman member interface could prevent the
configuration of the batman interface. This patch makes sure only existing
member interfaces will be considered when setting up the interface.
Signed-off-by: Maximilian Wilhelm <max@rfc2324.org>
Addons: vxlan: Fix check of »vxlan-svcnodeip« config option.
The »vxlan-svcnodeip« corresponds with the multicast »group« parameter
of the VXLAN interface and should be checked against this value instead
of the »remote« parameter for unicast ptp tunnels.
Signed-off-by: Maximilian Wilhelm <max@rfc2324.org>
Add addon module for B.A.T.M.A.N. advanced interface configuration. (#12)
* Add addon module for B.A.T.M.A.N. advanced interface configuration.
This commit adds support for configuring B.A.T.M.A.N. advanced interfaces
with ifupdown2. B.A.T.M.A.N. advanced is a protocol to build Layer2 based
mesh networks with. It's supported in the Linux kernel and thus available
in many Linux environments.
where »bat0« would be the local connection to the mesh network.
The interfaces »eth1« and »eth2.23« would be used by the B.A.T.M.A.N. adv.
protocol to communicate to other member of the mesh network.
Any interfaces matching the »ifaces-ignore-regex« will be gently ignored
by ifquery and ifreload as there might be some tunnels or interfaces
added to the mesh network by other means which should not be removed by
any subsequent ifreload run.
The »hop-penalty» parameter set the penalty of this node within the mesh
network.
Signed-off-by: Maximilian Wilhelm <max@rfc2324.org>
* addons: batman_adv: replacing rtnetlink by netlink api call and iproute2 instantiation fix
These changes are due to modifications we introduced in debian-prep2.
We no longer use the rtnetlink_api but a new one "netlink" build on top of python-nlmanager.
* Reflect upstream change where flags are stored.
Signed-off-by: Maximilian Wilhelm <max@rfc2324.org>
Julien Fortin [Thu, 1 Mar 2018 05:46:53 +0000 (16:46 +1100)]
iproute2: addr_add: change default broadcast to '+' so iproute2 generate broadcast addrs
today ifupdown2 doesn't generate the broadcast address for an intf while ifupdown1(debian)
does, simply changing the default broadcast value to '+' solve the issue.
$ ip addr show bond1
13: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether f4:52:14:33:ea:01 brd ff:ff:ff:ff:ff:ff
inet 88.213.145.1/24 scope global bond1
valid_lft forever preferred_lft forever
inet6 fe80::f652:14ff:fe33:ea01/64 scope link
valid_lft forever preferred_lft forever
******************************************
With ifupdown1 (debian) with the same configuration
Gaudenz Steinlin [Wed, 25 Oct 2017 00:00:27 +0000 (02:00 +0200)]
Pass environment variables to addon scripts (#32)
Pass the same environment variables to addon scripts from /etc/network/
as are passed to user defined commands in interfaces stanzas. This is
needed for compatibility with ifupdown.
For hotplug devices check if the link is present, not up (#28)
Checking operstate would require firmware to be loaded and link
negotiation to of taken place. Some firmwares take a few seconds to
upload and online the device, and some link negotiations take a second
or two.
Immediately checking operstate is not feasible here. Checking if the
link is present is a more suitable non-delaying approach.
Julien Fortin [Thu, 23 Feb 2017 09:42:34 +0000 (16:42 +0700)]
sbin: start-networking: adjust allow-hotplug behavior to ifupdown
Ticket: Bug#855598: src:ifupdown2: allow-hotplug behaves differently, not UPing interfaces
Reviewed By: Roopa
Testing Done: mark an interface (ethX) as hotplug then reboot
Roopa Prabhu [Mon, 6 Feb 2017 00:27:02 +0000 (16:27 -0800)]
addons: bridge: support for bridge-learning attribute
Ticket: CM-14683
Reviewed By: julien, mallik, anita, vivek, balki, wkok
Testing Done: tested with bridge-learning on off
- support for bridge-learning attribute on bridge ports.
(currently uses sysfs, must move to netlink soon)
- Additional feature for vxlan bridge ports: sync learning
flag to vxlan bridge ports. No ifquery check for this auto
sync feature.
example config for vxlan ports:
auto vxlan1000
iface vxlan1000
vxlan-id 1000
bridge-learning off
bridge-access 100
Ticket: CM-8424
Reviewed By: Roopa, Julien
Testing Done: using the config mentioned in bug
updelay
Specifies the time, in milliseconds, to wait before enabling a
slave after a link recovery has been detected. This option is
only valid for the miimon link monitor.
downdelay
Specifies the time, in milliseconds, to wait before disabling
a slave after a link failure has been detected. This option
is only valid for the miimon link monitor.
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'
...
Roopa Prabhu [Thu, 26 Jan 2017 22:34:32 +0000 (14:34 -0800)]
addons: vxlan: ifquery: fix remote-ip handling
Ticket: CM-14628
Reviewed By: julien, nikhil, vivek, mallik
Testing Done: Tested with vxlan config and remote ips added externally
Recent handling of vxlan-purge-routes as part of CM-13815 did not fix
handling of remote ips during ifquery --check and ifquery --running.
This patch fixes ifquery -c and ifquery running for external
vxlan controller cases.
Without this, ifquery --check always returns exit code of 1 for
external vxlan controller configs
Nikhil [Thu, 5 Jan 2017 22:41:42 +0000 (14:41 -0800)]
addons: mstpctl: ifquery -c --with-default, ignore mstpctl default attributes when stp is off
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
Nikhil [Wed, 18 Jan 2017 01:55:35 +0000 (17:55 -0800)]
addons: address: replay all gateway commands at every ifreload
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
Julien Fortin [Fri, 13 Jan 2017 03:51:28 +0000 (06:51 +0300)]
addons: address: log error when ip route gateway command fails
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
$
$ 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
$
$ 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
$
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 ?)
Julien Fortin [Fri, 6 Jan 2017 14:58:49 +0000 (17:58 +0300)]
addons: bond: add support for attribute aliases (bond-ports)
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]
Roopa Prabhu [Wed, 4 Jan 2017 22:52:09 +0000 (14:52 -0800)]
ifupdown: add missing supporting code for 'link-down [yes|no]'
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.
Roopa Prabhu [Thu, 5 Jan 2017 18:52:31 +0000 (10:52 -0800)]
addons: link: add new 'link-down [yes|no]' link attribute to keep link down
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.
Roopa Prabhu [Wed, 4 Jan 2017 22:52:09 +0000 (14:52 -0800)]
ifupdown: add new 'down [yes|no]' link attribute to keep link down
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.
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
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
Roopa Prabhu [Thu, 22 Dec 2016 07:02:12 +0000 (23:02 -0800)]
addons: bridge: identify a bridge with bridge-ports or bridge-vlan-aware keywords
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.
Julien Fortin [Mon, 12 Dec 2016 06:34:43 +0000 (07:34 +0100)]
bondutils: caching min_links value
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.
Julien Fortin [Mon, 12 Dec 2016 06:34:43 +0000 (07:34 +0100)]
bondutils: caching min_links value
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.
Roopa Prabhu [Thu, 8 Dec 2016 00:41:36 +0000 (16:41 -0800)]
addons: address: fix _cache_update to use the right set cache api
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
Julien Fortin [Fri, 2 Dec 2016 06:15:09 +0000 (07:15 +0100)]
addons: dhcp: release dhclient4/6 if it's still running but inet/inet6 is not configured
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)
Julien Fortin [Thu, 1 Dec 2016 05:34:02 +0000 (06:34 +0100)]
addons: dhcp: check if iface has link-local address before starting dhclient6
Ticket: CM-13248
Reviewed By: Roopa, Kanna, Nikhil G
Testing Done: See bug
Today before starting dhclient6, we are sleeping 2 seconds we need to make sure
the configured interface is up and has a link-local address.
In some cases 2 seconds is not enough. This patch will install a retry loop
with a 10 sec timeout.
We are querying ip -6 addr show to make sure the interface is properly confi-
-gured but in the future the plan is to move this call to netlink.
Roopa Prabhu [Wed, 30 Nov 2016 21:06:36 +0000 (13:06 -0800)]
addons: vrf: bring up master on first slave ifup if WITH_DEPENDS is set
Ticket: CM-12988
Reviewed By: julien, nikhil
Testing Done: Tested ifdown and ifup of vrf device with --with-depends
This patch fixes transient errors like below on vrf slaves when
vrf device is being brought up with --with-depends:
"error: swp1: vrf vrf1 not around, skipping vrf config
error: br100: vrf vrf1 not around, skipping vrf config
error: br101: vrf vrf1 not around, skipping vrf config"
In this patch, the vrf device is brought up on bringing
up of the first vrf slave. This is also done in the normal
ifreload -a case.
history on --with-depends for vrf: On vrf device down,
a bunch of slave state gets cleaned up.
and today, ifup of vrf device alone does not fix all that state
especially when there are vrr (macvlan) interfaces involved.
One has to use --with-depends. This is now also part of documentation
https://tickets.cumulusnetworks.com/browse/UD-851
Roopa Prabhu [Mon, 28 Nov 2016 21:24:31 +0000 (13:24 -0800)]
addons: address: propagate physical mtu to upper vlan devices
Ticket: CM-13221
Reviewed By: julien, nikhil
Testing Done: tested mtu propagation for vlan devices
This is a followup to commit 29de36f36053 ("addons: address: various fixes for mtu handling").
This fixes a pending issue with mtu readjustments on vlan
interfaces on top of physical interfaces.
eg: with the below config:
$ifquery -a
auto swp1.100
iface swp1.100
auto swp1
iface swp1
mtu 9000
/* at boot-up swp1 and swp1.100 mtu is set to 9000 */
$ifdown swp1 /* resets swp1 mtu to 1500. swp1.100 mtu is reset to 1500
implicitly by the kernel */
$ifup swp1 /* swp1 mtu is set to 1500. But swp1.100 mtu stays at 1500
*/
This problem is unique to physical interfaces and vlan devices on
physical interfaces. This is because, when logical interface is ifdown,
kernel deletes all its sub-interfaces. And on the way up (ifup),
ifupdown2 re-creates all these sub-interfaces for you....that
sequence re-adjusts the mtu. For physical
interfaces, since the sub-interfaces are not deleted,
ifupdown2 does not do anything...and mtu of the subinterface is left to
what it was. And this ends up being what was there initially when the
lower interface went down. And ifdown of the lower physical interface,
resets the physical mtu to default which is 1500. The sub-interface mtu
returns to 1500 while the lower physical interface remains down.
(another detail here: kernel vlan driver re-adjusts mtu of the vlan
sub-interface on its own when the lower device mtu becomes lower. But
does not re-adjust its mtu when the lower device mtu increases. This is
expected and correct behavior). We will have to work around it in
ifupdown2 to suit our needs.
two solutions:
a) when physical interface is brought up, ifupdown2 can go and
pro-actively adjust the upper sub-interface mtu
OR
b) when physical interface is brought down, do not reset the mtu on the
device to default
(b) is the easiest and costs less if we dont expect the mtu of a
physical device to go to default on ifdown.
(a) is doable too, but is additional cost to go over all upper
interfaces.
This patch fixes this problem with solution (a). But, makes sure
this does not add additional cost to the default ifreload -a path.
projects / mirror_ifupdown2.git / log