Ticket: CM-12370
Reviewed By: Roopa, Kanna, Scott E
Testing Done:
This patch also fixes a problem where dhcp6 used to create lease file with
a trailing whitespace. dhcp6 operation were also sometimes using the wrong
pid file. I added some code in the debian.postinst script to correctly
rename these files if they exists when we install/update ifupdown2.
(cumulus-qa-infra/cl-tests/tests/smoke/testdhcp.py:Testdhcp_relay)
auto swp1
iface swp1 inet dhcp
link-speed 10000
link-duplex full
link-autoneg off
auto swp1
iface swp1 inet6 dhcp
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-6908, CM-6110, CM-13221
Reviewed By: julien, nikhil
Testing Done: added a new test in ifupdown2-tests which covers all cases
- move all mtu handling to a single function in addons/address.py
- Have an ifupdown2 default of 1500 mtu
- add a policy manager max_mtu check (we want to default cumulus max mtu
to 9216)
- special handling for bond and bridges
- print an info log abt setting mtu on bridge
- this can be enhanced in the future to look
at individual port mtu and rejecting the bridge mtu.
this operation can be expensive right now. Hence
just an info log.
- bond and vxlan dev mtu follow the rules of physical device mtu
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-12798
Reviewed By: Roopa, Nikhil G
Testing Done:
We are seeing some issue when using IP addresses with inner values padded with
zeros. Such as: 2a01:75e0:0000:09b0::1/64
The kernel will process the ip properly but when we query the kernel again (with
iproute2 or netlink) it returns 2a01:75e0:0:09b0::1/64
Since we are doing string comparaison we are seeing failures. We are now
converting all ip address to a standard format using IPNetwork or IPAddress obj
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-12798
Reviewed By: Roopa
Testing Done:
A customer discovered a corner case: the kernel is shrinking/reducing the ip
address fields containing 0s. For example if we configure and address such as
2a01:75e0:0000:09b0::1/64
Then if we query the kernel (using iproute2 or netlink) it will come back as:
2a01:75e0:0:09b0::1/64
Because of this issue we were seeing
root@r4u28:~# ifreload -a
error: bridge.200: cmd 'ip -force -batch - [addr add 10.50.103.193/26 dev bridge.200
addr add 2a01:75e0:0000:09b1::1/64 dev bridge.200
]' failed: returned 1 (RTNETLINK answers: File exists
Command failed -:1
)
Before adding an address to an iface we query it to know if the change is
necessary, since we only do a string comparaison between:
2a01:75e0:0000:09b1::1/64 and 2a01:75e0:0:09b1::1/64
it fails, ifupdown2 thinks that a change is needed. So we try to add the new
address via iproute2. iproute2 will fail because this address in a "shrinked"
format already exists.
This patch hot-fixes this problem by ignoring the error if it's an "exists"
error, we don't want to confuse the user.
A later fix will the real issue by normalizing all ip addr to the IPNetwork
format.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
we should leave the mtu on lo to the default mtu
if user has not requested to change it. lo has
a larger mtu because it does not really depend on a
physical mtu.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-8610
Reviewed By: Roopa, Nikhil G
Testing Done:
It used to be a silent exception, but not anymore because we catch it and log
accordingly (error) and flag the ifaceobj so that ifupdown2 returns 1.
$ cat /etc/network/interfaces
auto tap0
iface tap0
mtu 9000
address 172.17.28.0/31
$ ifreload -a
$ echo "address 2002:17:27:17/120" >> /etc/network/interfaces
$ ifreload -a
$ echo $?
0
$ # applying this patch
$ ifreload -a
error: tap0: cmd 'ip -force -batch - [addr add 172.17.28.0/31 dev tap0
addr add 2002:17:27:17/120 dev tap0
]' failed: returned 1 (RTNETLINK answers: File exists
Command failed -:1
Error: an inet prefix is expected rather than "2002:17:27:17/120".
)
$ echo $?
1
$
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-8610
Reviewed By: Roopa, Nikhil G
Testing Done:
It used to be a silent exception, but not anymore because we catch it and log
accordingly (error) and flag the ifaceobj so that ifupdown2 returns 1.
$ cat /etc/network/interfaces
auto tap0
iface tap0
mtu 9000
address 172.17.28.0/31
$ ifreload -a
$ echo "address 2002:17:27:17/120" >> /etc/network/interfaces
$ ifreload -a
$ echo $?
0
$ # applying this patch
$ ifreload -a
error: tap0: cmd 'ip -force -batch - [addr add 172.17.28.0/31 dev tap0
addr add 2002:17:27:17/120 dev tap0
]' failed: returned 1 (RTNETLINK answers: File exists
Command failed -:1
Error: an inet prefix is expected rather than "2002:17:27:17/120".
)
$ echo $?
1
$
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
we should leave the mtu on lo to the default mtu
if user has not requested to change it. lo has
a larger mtu because it does not really depend on a
physical mtu.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-12201
Reviewed By: Roopa
Testing Done:
The syntax: netmask <number> is ifupdown legacy support
We want to deprecate it so we don't want to officially support it.
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-8101
Reviewed By: CCR-4949
Testing Done: smoke tests + ran ifup -a -s on every interface configuration file from GSS cl-supports collection
This commit is introducing ~20 keywords. The value of the different attributes
will be check against raw values and <keywords>:
'<mac>'
'<text>'
'<ipv4>'
'<ipv6>'
'<auto>': "auto"
'<ipaddr>': ipv4/6 with preflix len
'<number>'
'<interface>'
'<ipv4-vrf-text>': equivalent to: <ipv4> "vrf" <text>
'<number-ipv4-list>': example: "100=172.16.100.1 101=172.16.101.1"
'<interface-list>': example: "swp1 swp2 swp3"
'<ipv4/prefixlen>'
'<ipv6/prefixlen>'
'<ipaddr/prefixlen>'
'<number-range-list>': example: "2000 2200-3000"
'<interface-range-list>': example: "swp1=100 swp2=100" ('validrange' : ['0', '65535'])
'<mac-ipaddr/prefixlen-list>'
'<number-interface-list>': example: "4 swp1 swp2"
'<interface-yes-no-list>': example: "swp1=yes swp2=no"
'<interface-yes-no-0-1-list>'
'<interface-yes-no-auto-list>'
It's possible to combine a keyword with a range from validrange. example:
validrange: 10-50
validvals: <intrface-range-list>
value: swp1=21 swp2=42 ...
Signed-off-by: Julien Fortin <julien@cumulusnetworks.com>
Ticket: CM-8596, CM-5118
Reviewed By: roopa, julien
Testing Done: used same config mentioned in bug
Previously, only first configured gateway is set as default route.
This patch sets all the configured gateways as default routes.
This patch also removes default route on ifup
after removing 'gateway' from the interface
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
Ticket: CM-8561
Reviewed By: kanna, julien
Testing Done: Tested on amd64 switch
ifreload always deletes and adds back a host IP address
if that address is specified without a "/" and without a "netmask" config.
The problem is fixed so that _inet_address_convert_to_cidr() handles a missing
"/" and a missing "netmask" config. The host addresses is no longer added to a
list of addresses we will del/add. The patch was simply to add a case for the
missing "/" and a missing "netmask".
Ticket: CM-10857
Reviewed By: julien, nikhil
Testing Done: Tested moving from a dhcp to static addr method for eth0
before the patch:
- when moving from dhcp to static address method, after releasing the dhcp
address, it takes a few seconds for the dhcp address to go away. When we
query addresses to configure, there is a chance that we may end up
getting the dhcp address for a few seconds. Which is ok until when the
static address to be configured is same as the dhcp address.
In which case we end up not configuring the static address because we
think it is already configured (per the running list).
After this patch:
- when moving from dhcp to static address method, we always re-apply the
address config avoiding the chance of not configuring an address due to a
dhcp address sticking around.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-10857
Reviewed By: julien, nikhil
Testing Done: Tested moving from a static to dhcp addr method for eth0
the check to see if dhclient is running on an interface was failing.
which caused the following problem:
- interface when moved from dhcp to static addr_method was
not killing the existing dhcp process
- and a subsequent move from static to dhcp addr_method quit starting
dhcp because a dhclient process was already running
- but the original dhcp ip was already removed because of the
static address config which leaves eth0 in a weird state
After this patch:
- move from dhcp to static addr_method will release any
existing dhcp leases on an interface
- a subsequent move from static to dhcp will request a new
dhcp lease
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
not bond slaves
Ticket: CM-9449
Reviewed By: julien
Testing Done: Tested resetting mtu on physical interfaces to default
default mtu is already present in address.json policy file. This patch
continues to take a cautious and conservative approach to
reset mtu of only physical interfaces if different from default mtu
and mtu is not given by the user. bond slaves get their mtu from
the bond when bond has a configured mtu. so this patch only
resets mtu on physical interfaces which are not bond slaves.
{noformat}
$cat /var/lib/ifupdown2/policy.d/address.json
{
"address": {
"defaults": { "mtu": "1500" }
}
}
{noformat}
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-10281
Reviewed By: Roopa Prabhu
Testing Done: Tested with the configuration mentioned in the bug id
Due to bug CM-10188, defualt route via gateway is not installed in time.
It needs 2 sec delay, and fix to CM-10188 shall rectify this issue.
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
Ticket: CM-7840
Reviewed By: Roopa Prabhu
Testing Done: yes, by installing ifupdown .deb file onto dell-s3000-02
This patch adds a new argument '--with-defaults' to 'ifquery'
when 'ifquery --with-defaults' is executed, running states of all interface
attributes are compared against respective configured attributes from
/etc/network/interfaces file, if configured. Otherwise, compared against
default attributes from policy file
This patch also: (1) fixes ifquery check failure for bridge-* stp attributes.
(2) removes vrf-default-route and vrf-cgroup attributes from ifupdown2 policy
and just have the vrf-helper attribute
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
Ticket: CM-10178
Review: trivial
Testing: tested with failing testcase in the CM
This patch fixes a check in vrf map initialization code which did
not account for running vrfs correctly. This caused the case where
there were no running vrfs but stale map file to fail.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
addons,ifupdown,sbin: adding ifquery --with-defaults option
Ticket: CM-7840
Reviewed By: Roopa Prabhu
Testing Done: yes, by installing ifupdown .deb file onto dell-s3000-02
This patch adds a new argument '--with-defaults' to 'ifquery'
when 'ifquery --with-defaults' is executed, running states of all interface
attributes are compared against respective configured attributes from
/etc/network/interfaces file, if configured. Otherwise, compared against
default attributes from policy file
Signed-off-by: Nikhil <nikhil@cumulusnetworks.com>
Ticket: CM-10471
Reviewed By:
Testing Done: Tested with failing config in CM-10471
Recent commit "84f33af6e1f53d ("address.py: default value for mtu when
mtu attribute is removed") CM-9449" enabled setting of device mtu to default
mtu if mtu is not given in the interfaces file.
logical devices like bridges and vlan devices rely on mtu
from their lower devices. ie mtu travels from
lower devices to upper devices. For bonds mtu travels from
upper to lower devices. running mtu depends on upper and
lower device mtu. With all this implicit mtu
config by the kernel in play, it becomes almost impossible
to compare running mtu with the default mtu.
This commit disables this resetting of mtu based on default mtu.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: cleanup
Reviewed By:
Testing Done: Tested ifupdown sanity
This gets rid of some ugly previous flag handling which was
passed through modules. This creates a global instance of
flags that all addon modules and helper modules can use.
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Ticket: CM-10027
Reviewed By: julien, nikhil
Testing Done: Tested with an interfaces file with shared dependents
In the process of fixing this saw a few more issues with link kind
handing. Its better to separate kind from interface private flags
like bond slave and bridge port. this patch cleans up all that handling.
Example errors:
error: misconfig..? swp5.2 vrfslave is enslaved to multiple interfaces
['vrf1012', 'br2']
error: misconfig..? swp5.2 bridgeport is enslaved to multiple
interfaces ['vrf1012', 'br2']
Ticket: CM-6896
Reviewed By: CCR-4276
Testing Done:
host: sm-e1031-02
$ # > adding "hwaddress 02:01:02:03:04:08" to eth0 in /etc/network/interfaces
$ ifreload -a
$ ifup -v -a
$ ifdown -a -v
$ ifquery -c -a
$ reboot
$ # > analyze /var/log/syslog for boot error message
$ cat /var/log/syslog | grep ifupdown
I did the same process with "hwaddress ether 02:01:02:03:04:11"
also without the hwaddress statement.
This reverts commit bed653e31b.
Reverting commit because this does not do the right thing and also
prints 'NoneType' errors. We should not be changing anything for
running values. The ether check is only needed for configured values.
Ticket: CM-6795
Reviewed By: CCR-4270
Testing Done:
root@debian:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback
alias foo_bar
root@debian:~# ip link show lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
alias foo_bar
root@debian:~# ifdown -v lo
info: loading builtin modules from /usr/share/ifupdown2/addons
info: module ethtool not loaded (module init failed: no /sbin/ethtool found)
info: module ethtool not loaded (module init failed: no /sbin/ethtool found)
info: looking for user scripts under /etc/network
info: loading scripts under /etc/network/if-pre-up.d ...
info: loading scripts under /etc/network/if-up.d ...
info: loading scripts under /etc/network/if-post-up.d ...
info: loading scripts under /etc/network/if-pre-down.d ...
info: loading scripts under /etc/network/if-down.d ...
info: loading scripts under /etc/network/if-post-down.d ...
info: lo: running ops ...
info: rtnetlink: setting link lo down
info: executing ip -o addr show dev lo
info: Executing echo "" > /sys/class/net/lo/ifalias
info: Executing /etc/network/if-down.d/avahi-autoipd
info: Executing /etc/network/if-down.d/upstart
info: Executing /etc/network/if-down.d/wpasupplicant
info: Executing /etc/network/if-post-down.d/wireless-tools
info: Executing /etc/network/if-post-down.d/avahi-daemon
info: Executing /etc/network/if-post-down.d/wpasupplicant
root@debian:~# ip link show lo
1: lo: <LOOPBACK> mtu 65536 qdisc noqueue state DOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
root@debian:~# ifup -v lo
info: loading builtin modules from /usr/share/ifupdown2/addons
info: module ethtool not loaded (module init failed: no /sbin/ethtool found)
info: module ethtool not loaded (module init failed: no /sbin/ethtool found)
info: looking for user scripts under /etc/network
info: loading scripts under /etc/network/if-pre-up.d ...
info: loading scripts under /etc/network/if-up.d ...
info: loading scripts under /etc/network/if-post-up.d ...
info: loading scripts under /etc/network/if-pre-down.d ...
info: loading scripts under /etc/network/if-down.d ...
info: loading scripts under /etc/network/if-post-down.d ...
info: processing interfaces file /etc/network/interfaces
info: lo: running ops ...
info: Executing /etc/network/if-pre-up.d/wireless-tools
info: Executing /etc/network/if-pre-up.d/wpasupplicant
info: rtnetlink: setting link lo up
info: executing ip -o addr show dev lo
info: executing ip link set dev lo alias foo_bar
info: Executing /etc/network/if-up.d/mountnfs
info: Executing /etc/network/if-up.d/avahi-autoipd
info: Executing /etc/network/if-up.d/openssh-server
info: Executing /etc/network/if-up.d/upstart
info: Executing /etc/network/if-up.d/avahi-daemon
info: Executing /etc/network/if-up.d/wpasupplicant
root@debian:~# ip link show lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
alias foo_bar
Ticket: CM-6795
Reviewed By:
Testing Done: Julien Fortin <julien@cumulusnetworks.com>
When using ifdown the value of the alias field was checked but never used. Instead this string "\'\'" was used.
Ticket: CM-8621
Reviewed By: Roopa Prabhu
Testing Done: Yes, by installing ifupdown2 deb onto cel-e1031-01
This patch makes sure ifupdown2 will not delete the address
configured through quagga when address-purge is set to no
Ticket: CM-8773
Reviewed By: CCR-4079
Testing Done:Yes, with following cofiguration
auto swp1
iface swp1
address 71.12.21.43
address 2001:620:5ca1:160::47
preferred-lifetime 30
Fix for this is, a small update in address.py method '_inet_address_convert_to_cidr'
where there is a check for different addres attributes.
Ticket: CM-7917
Reviewed By: CCR-3845
Testing Done: Tested changing address and ifreloading on multiple iface stanzas
In presence of multiple iface stanzas, current ifupdown2 does not purge
existing addresses.
Because each ifaceobject processing looks at only its stanzas and it is
afraid that it may purge running addresses that does not belong to
itself. Historically multiple iface stanzas are processed individually
than squashing them as a single interface. Squashing iface stanzas into
a single iface stanza has been a problem in the past and also does not
work well with iface stanzas that are supported by ifupdown (I dont have
a specific problem example right now...but)
This patch processes all address attributes when processing the first iface
object (or iface stanza). Unsure if this can be a surprise to existing
users. It should not but cant say sometimes people have weird things in
their pre-up/post-up commands. Hence this is controlled by a ifupdown2.conf
variable addr_config_squash=0 set to off by default. still debating if this
can be on by default.
When addr_config_squash=0 and existing addresses are not purged a
warning is displayed:
"warning: swp1: interface has multiple iface stanzas skip purging
existing addresses"
(cherry picked from commit 7aaa75674547392f2abb8273b18671f0795b3eaf)
Ticket: CM-6106
Reviewed By: CCR-3637
Testing Done: Tested address under a bridge
We had shipped example files with addresses under bridges and slaves
in 2.5.3. With the warning introduced in 2.5.4, we will start emitting
warnings for existing customer files. And I have recently
learnt that users are relying on warnings to detect errors.
With this commit I am changing the warn to an info message
to avoid breaking existing users. We can change it back to a warn in
3.0.
changed:
"warning: interface bridge is enslaved or a vlan aware bridge and cannot
have an IP Address"
to:
"info: bridge: ignoring ip address. Interface is enslaved or a vlan
aware bridge and cannot have an IP Address"
(cherry picked from commit ecb20279e3d3c123537b9e6fddea4590c63a5013)
Ticket: CM-7087
Reviewed By: CCR-3379
Testing Done: unit testing with clag_vxlan_clos_spec/cfg.py
On clag pairing, clagd changes local address of vxlan device to anycast ip.
If user does ifreload now, ifupdown2 will overwrite local address with
individual ip contained in /etc/netwrok/interfaces. vxlan.py caches
anycast_ip configuration so that ifquery -c can skip it from flagging error
and ifreload skip overwriting vxlan device's local ip.
vxrd provisions head-end replication endpoints by adding bridge fdb entries.
If /etc/network/interfaces doesn't have remote-ip attribute, then on ifreload
ifupdown2 will delete all vxrd provisioned entries. ifupdown will check for
presence of vxrd service and skip add/delete bridge fdb entries for
head-end replication
On ifreload vxlan device are put in proto-down even if they are up and running.
Check for operstate and put it in proto-down only if operstate transitions from
down to up.
Ticket: CM-6106
Reviewed By: roopa,scotte
Testing Done: ran ifupdown2 regression suite and hand tested
This patch prevents IP address assignment under vlan aware bridges.
This prevents some confusion because a bridge subinterface is required
for layer 3 termination.
Ticket: CM-5146
Reviewed By: roopa,jtoppins
Testing Done: built new ifupdown package and ran testifupdown2 suite of tests
This patch prevents enslaved interfaces from having IP addresses.
(cherry picked from commit 0c00606fbc76db11557a8e946310e93a2b376aa7)
(cherry picked from commit dc30987acfc6af356b9e055db95d94ae45f0de9f)
Ticket: CM-5355
Reviewed By: roopa
Testing Done: Tested config in ticket
MTU settings are defaulted 1500 when interface is ifdowned.
This has the effect of changing the MTU on the interface and any subinterfaces to
1500. And if these subinterfaces are in a bridge, the bridge will pick the MIN MTU
so the bridge keeps this MTU even after the interface is brought back up. The sub
interface does not change to a higher value then 1500 (kernel VLAN driver only
moves the MTU is the decreasing direction.
