Ticket: CM-6358
Reviewed By: roopa
Testing Done: Yes
ifupdown2 creates overrides vxrd's config when either (or both) the vxrd-src-ip and vxrd-svcnode-ip appear under the loopback interface's configuration.
Example
address 12.0.0.4/32
vxrd-src-ip 12.0.0.4
vxrd-svcnode-ip 99.99.99.9
Ticket: CM-3715
Reviewed By: CCR-3065
Testing Done: unit testing
Changes to proto down vxlan devices to avoid packet loops or duplicates before
clagd checks consistency and installs egress acl rules. When vxlan device is
brought up, check for presence of peer link and proto-down the device if peer
link exists.
- get_dependent_ifacenames is used to eliminate order dependency in specifying
peer link and vxlan configuration in /etc/network/interfaces.
- A separate script clagVxlanProtoDown is used to protodown vxlan devices if
peer link is configured separately (ifup peerlink) and vxlan devices are
already functional in the system.
Ticket: CM-5254
Reviewed By: roopa
Testing Done: tested master and 2.5_br images with testifupdown2 suite and hand tested
This patch creates a json defaults file upon bootup
(which can be overridden by customer configs in /etc)
which the ethtool module in ifupdown2 will consult
when "link-x" configs are removed in order to restore
them to the initial settings used by the switch.
(cherry picked from commit 8388664f5a5a85f2a813cafbf40ac92d7b86f4bf)
Conflicts:
packages/cl-utilities/usrlib/update-ports
(cherry picked from commit 21c9c10ab2fccaf60be9accb337e82541d497cc4)
ifdown behaviour.
Ticket: CM-5819
Reviewed By: CCR-2846
Testing Done: tested ifreload evo test case
ifreload_down_changed is 0 by default which will make
sure ifreload will not execute down on changed interfaces
but only on deleted interfaces making it non-disruptive.
some notes from CCR:
ifreload was designed to be an optimization for 'service networking
restart' or 'ifdown -a + ifup -a'.
essentially it is a combination of 'ifdown + ifup' with some smarts in
which interfaces it will execute ifdown on.
By default it does the below:
ifdown all interfaces that were deleted from the interfaces file
ifdown all interfaces that were changed from the last time they were
ifup'ed
ifup -a (execute ifup on all interfaces marked auto)
Did not realize people will use ifreload as much as they do today. Also,
they may execute it on a production box when changes are made. ifdown on a production box can be
disruptive because if the ifdown which is part of the ifreload.
To have a non-disruptive option to ifreload, 2.5 added a new option -c
that only executed 'ifup' on all interfaces. Thus reloading all auto +
any other interfaces that were once brought up on the box (essentially
all interfaces present in the saved state file). This by default did not
do anything to the interfaces that got deleted from the file. But had an
ifupdown2.conf toggle to do so.
Looking at the evo use case, they do want to use a single command that
modifies, adds, deletes with
minimum disruption. we can achieve maybe what they want with multiple
commands (But there is also a case of a bug in the build evo is running
which makes it not so easy ).
This patch fixes the bug and also tries to change the default ifreload
behaviour controllable via a variable in ifupdown2.conf.
when ifreload_down_changed=0 in ifupdown2.conf, ifreload will only
ifdown interfaces that were deleted
from the file but not the ones that changed. subsequent ifup as part of
ifreload on the interfaces
that changed will apply the delta. And ifreload_down_changed default
value is '0'.
WIth the patch, ifreload by default will do the below (going back to the
previous default is just a toggle in the ifupdown.conf file):
ifdown all interfaces that were deleted from the interfaces file
ifup -a (execute ifup on all interfaces marked auto)
It sounds like a big change of behaviour for a hotfix release, but
essentially the patch just moves a few things around. And the change in
behaviour is so subtle that it is not very visible.
It just makes it non-disruptive.
(cherry picked from commit 2f7977834d4912a69159d27e54ba201f58a321d8)
Ticket: CM-4802
Reviewed By:
Testing Done: yes
1. clag_enable needs to be set before slaves are added to the bond. Otherwise
bonding driver will bring the slaves up independent of clagd.
2. also added post_down clagd addon to cleanup the clag-id on ifdown.
Ticket: CM-3346
Reviewed By:
Testing Done: Tested ifupdown2 sanity
- moved 'admin up' delays that we introduced recently to be
configurable via two ifupdown2.conf attributes
# Let link master (bridges, bonds) own the link state of slaves
link_master_slave=1
# Delay admin state change till the end
delay_admin_state_change=0
- reduced some redundant traversal of dependency trees
- fixed a few bugs in query check
addons file
Ticket: CM-4423
Reviewed By:
Testing Done: tested ifupdown2 in the presence and absence of clagd
This is a hack to get around an ifupdown2 limitation.
The real fix should come as part of CM-3782
(cherry picked from commit 6fb63d6cdcb660063cf5d07ff28f49c34a306371)
addons file
Ticket: CM-4423
Reviewed By:
Testing Done: tested ifupdown2 in the presence and absence of clagd
This is a hack to get around an ifupdown2 limitation.
The real fix should come as part of CM-3782
Ticket: CM-3525
Reviewed By: CCR-2035
Testing Done: ifup/ifdown, service networking restart, reboot
Need for this change noticed in review.
(cherry picked from commit 231e2cf74b0f55b65f76d315d04f3a9c8279f51b)
Ticket: CM-3454
Reviewed By:
Testing Done: basic testing with vrrpd
There is no check support yet and an open issue
with checking existing ifplugd processes
ifupdown logging from /etc/init.d/networking.
Ticket: CM-3891
Reviewed By:
Testing Done: Tested changing default networking parameters
- This provides a way to log to syslog
- if syslog is not enabled, msgs are output to stdout (in case of boot
these should be captured by bootlog in > 2.5)
Note that these values only affect logging from the
/etc/init.d/networking script and has nothing to do with ifupdown2
logging when ifupdown2 is used outside of /etc/init.d/networking
Ticket:
Reviewed By:
Testing Done: Tested with old and new bridge driver
Examples:
old bridge driver:
%for v in range(100, 104):
auto br${v}
iface br${v}
bridge-ports uplink1.${v} peerlink.${v} downlink.${v} glob
swp2-4.${v}
bridge-stp on
svi-router-ip 11.${v/256}.${v%256}.240/24
svi-router-mac 00:00:5e:00:01:00
svi-router-virtual-ip 11.${v/256}.${v%256}.241/24
svi-router-virtual-mac 00:11:22:33:44:00
%endfor
new bridge driver:
%for v in range(100, 101):
auto br0.${v}
iface br0.${v}
svi-router-ip 11.${v/256}.${v%256}.240/24
svi-router-mac 00:00:5e:00:01:00
svi-router-virtual-ip 11.${v/256}.${v%256}.241/24
svi-router-virtual-mac 00:11:22:33:44:00
%endfor
Pending issues:
- optimization (its slow with 2000 svi's today)
- ifquery check and running support
- names of attributes and macvlan interfaces may change after review
warnings on ifupdown)
Ticket: CM-1438
Reviewed By:
Testing Done: Tested ifupdown2 sanity
Some of the above mentioned configurable items can be specified in
ifupdown2.conf
attributes' for backward compatibility
Ticket: CM-1438
Reviewed By:
Testing Done: Tested ifupdown sanity and new functionality
support for:
- -i <interface file>
- template lookup path and move all template handling to a separate
module template.py
- new ifupdown2 config file /etc/network/ifupdown2/ifupdown2.conf
- bridge_waitport and bridge_maxwait
- moved addons.conf to /var/lib/ifupdownaddons/
