Roopa Prabhu [Wed, 2 Mar 2016 06:42:44 +0000 (22:42 -0800)]
ifupdownaddons: fix parsing of vlan attributes
Ticket: CM-8729
Reviewed By: trivial
Testing Done: Tested with a config with vlan-raw-device
'ip -o -d link show' introduced a new attribute between
'vlan and id'. This makes the move to json or netlink
even more necessary.
The fixes were done for the following format:
61: vlan100@swp1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
noqueue state UP mode DEFAULT group default \ link/ether
00:e0:ec:27:4e:b7 brd ff:ff:ff:ff:ff:ff promiscuity 0 \ vlan protocol
802.1Q id 100 <REORDER_HDR> addrgenmode eui64
Roopa Prabhu [Tue, 1 Mar 2016 06:23:24 +0000 (22:23 -0800)]
ifupdownmain: handle more than one upperifaces
Ticket: CM-9595
Reviewed By:
Testing Done: tested with failing vrf config in CM-9595
due to same upperiface getting processed more than once,
there was an unnecessary refcount inc on the lowerdevice.
This patch aborts processing upperiface if already
processed and also adds a new debug function to
dump lower and uppper ifaces of all interfaces in the
file.
Nikhil [Tue, 1 Mar 2016 01:32:23 +0000 (17:32 -0800)]
addons: vrf: Ensures fib rule for local table have higher pref than fib vrf rule
Ticket: CM-9541
Reviewed By: Roopa Prabhu
Testing Done: Yes, by installing ifupdown2 deb onto cel-e1031-01
This patch checks if fib rule for local table have higher pref
than vrf table, if not, it deletes fib rule for local table
with lower pref and adds fib rule for local table with
higher pref than vrf table.
This patch also avoid repeated addition of vrf rules on each ifup
Roopa Prabhu [Mon, 29 Feb 2016 23:31:52 +0000 (15:31 -0800)]
start-networking: introduce state lock file /run/network/ifstatelock in
non-persistant storage
This is a reimport of missing peices of commit f819c3602e56 in 2.5cl ifupdown2.
commit log from 2.5cl:
Introduce a lock file in non-persistent storage
/run/network/ifstatelock to make sure the state
file in persistent storage is cleaned up correctly
ifupdown2 state file was moved to /var/tmp because /var/tmp was
tmpfs and was large enough (100MB) for the state file. But it
appears it has changed (or is not consistent) across all platforms.
We can move it under /run, but /run again size varies on various
platforms and it is too small on some platforms.
This patch:
- continues to keep the ifupdown2 state file under /var/tmp (because
it needs the space)
- ntroduces a second level /run/network/ifstatelock file that stays
on non-persistant storage and is used to delete the state file at
/boot up
Roopa Prabhu [Fri, 26 Feb 2016 14:32:28 +0000 (06:32 -0800)]
vrf: handle slaves when vrf device is brought up
The vrf device may not be up when ifup is executed on the
slaves. This commit makes sure:
- vrf slaves dont try to enslave themselves when vrf device is
not present
- And vrf master enslaves any missing slaves during ifup of vrf master
- Also make vrf device the link master, this will make sure
the vrf device brings the vrf slave links up. This is needed to work
around the ipv6 address flush issue
Roopa Prabhu [Fri, 26 Feb 2016 07:55:27 +0000 (23:55 -0800)]
ifupdownmain: add support for getting and introducing upperiface dependencies
This patch adds a new upperiface module handler get_upper_ifacenames
to get upperifaces from a addon module. This is called during building
dependency graph.
if user changes swp15.100 to another interface and does a ifreload,
before this patch swp15.100 used to be around. This patch makes sure
swp15.100 is deleted in the process
I had to do some cleanup of flags in the process. I might have added
some extra cycles to ifreload. But i dont see an easy way to handle this
case.
Use "remote" attribute in iproute2 command to provision
service node address for service node based replication. Changes also
include allowing only one service node per vxlan device, so its user's
responsiblity to select one service node per vxlan device if there
are multiple nodes to distribute the load.
Currently, when doing ifup of a bridge, the bridge is created
and ports are added to bridge before vlan_filtering is set on
the bridge. This causes extra churn on switchd which has to
configure the hardware one way and then tear it down and
reconfigure it again in the new way. For mlx, it causes even
more problems.
This patch moves the vlan_filtering setting of bridge to before
member ports are being added to the bridge, and it uses the new
iproute2 command for setting the attribute instead of through
sysfs.
The install file resulted in creating /etc/default/networking/ as a
directory and installing the networking.default file in it. Rename
networking.default to networking, and change the install file.
Normally dh_installinit handles all this, but since the package is
ifupdown2, and the file is networking, that doesn't happen.
Also, because we had created a directory with the name of what we want
to install as a file, we need to remove it if it exists. This addition
of a preinst file should not go upstream, and should be removed in a few
weeks when everybody has re-installed enough.
In 3.0, the bridge vlan show command does not print
VLAN ranges unless you use the "-c" option.
This patch modifies the bridge vlan show call in
iproute2.py to use "-c".
Ticket: CM-9078
Reviewed By: CCR-4110
Testing Done: clag bond add/del and clag slave add/del
This change basically does the following -
1. Proto-down swpX pre-clag-bond-enslave
2. Proto-up swpX post-clag-bond-release
Setting/clearing of clag-id will result in similar proto-state changes
and those are handled by clagd.
Note:
I really wanted to keep these changes out of ifupdown2 but the
order of setting is critical i.e. protodown has to happen enslave to
prevent additional flaps/STP TCNs. Theoretically #2 can be done by clagd
but there is no easy way to do #1.
For now disable old LACP bypass options so that ifreload does
not give errors, as the corresponding sysfs nodes do not exist in
the latest 4.1.y kernel.
Dave Olson [Mon, 8 Feb 2016 20:41:41 +0000 (12:41 -0800)]
Remove /etc/init.d/networking after all - causes loops during image builds
Ticket: none
Reviewed By: trivial
Testing Done: installed, Alex tried for image creations.
apparently with some of our packages like mstpd still using init.d for a
while longer, just having the init.d/networking file causes the original
complaints about loops between services.
So I'm purging it completely.
Also clean up the comments a bit in start-networking
Scott Emery [Mon, 8 Feb 2016 20:47:08 +0000 (12:47 -0800)]
ifupdown2: After loading bonding driver, continue to create bond
Ticket: CM-9182
Reviewed By: Trivial
Testing Done: ifup'd bond when bonding module was not yet loaded.
The bond support in ifupdown2 would check to see if the bonding module is
loaded when creating a bond. If it was not it would load the driver and return.
The correct operation is to load the driver and then continue to create the
bond.
Scott Emery [Thu, 4 Feb 2016 00:38:18 +0000 (16:38 -0800)]
ifupdown2: Modify implementation of nowait option
Ticket: None
Reviewed By: CCR-4058
Testing Done: ifup'd interface with both dhcp-wait: "no" and dhcp-wait: "yes"
and not specified at all.
A previous patch implemented the nowait option for DHCP. This patch changes the
name of the option to "dhcp-wait" and makes the default, if nothing is specified
in the policy files, to be "yes", which means dhclient will be called without
the "-nw" option, causing it to wait for up to a minute for a response from the
DHCP server before continuing.
The format of the JSON in the policy file for this option was also changed so
that it conforms to the other ifupdown2 policy options. This format is now:
{
"dhcp": {
"defaults": { "dhcp-wait": "no" }
}
}
Also, the documented argument values are "yes" and "no". Any other values, will
be interpreted as "yes".
A subsequent patch in cl-basefiles will be made to include this fragment in
/var/lib/ifupdown2/policy.d/dhcp.json so that Cumulus Linux will default to
not waiting for DHCP to complete.
Scott Emery [Tue, 2 Feb 2016 00:42:14 +0000 (16:42 -0800)]
ifupdown2: Add nowait attribute for dhcp addon
Ticket: None
Reviewed By: CCR-4058
Testing Done: ifup'd interface with both nowait=0 and nowait=1 and not specified
at all.
The Mellanox platform, as well as some others probably, has two management
interfaces: eth0 and eth1. The customer may plug a cable into either one of
these interfaces, and very rarely both of them. If only one cable is plugged in
and we don't know which one, then /etc/network/interfaces must be configured
by default to automatically bring up both interfaces using DHCP. But when an
interface does not have link, it stalls the boot process for 60 seconds while
dhclient times out.
This patch changes the default dhclient behavior to not wait for DHCP to
complete, by using the "-nw" option when calling dhclient. This means that
dhclient will immediately return and DHCP will complete in the background.
A module attribute has been added for the DHCP addon called "nowait", which
defaults to 1. If this attribute is set to 0, then dhclient will revert to its
previous behavior and delay up to a minute while DHCP completes. This attribute
can be specified in a policy file, e.g. /etc/network/ifupdown2/policy.d/dhcp.json,
with contents such as:
jessie's networking starts as an init.d service. Trying to force ordering
between init.d and systemd services when there are dependencies doesn't work
well (especially since the init.d/networking service is forced very early
because of the remote filesystem requirement in jesie).
Converting networking to a script run as a systemd service allows us to start
networking after switchd. The new script is /sbin/start-networking. I chose
to keep it in /sbin, rather than put it in /usr/cumulus/bin, because it's core
functionaity.
I am not removing /etc/init.d/networking, it just gets ignored unless somebody
types it manually. If somebody does that, systemctl runs through the lsb
hooks. The two lost abilities below are just ignored if passed. I'm
also preventing creating the rc.d symlinks to the init.d/networking
script to reduce future confusion.
We lose some init.d "convenience" functionality because it's not available
through systemd. What we lose are:
reload-currently-up - can still be done with ifreload --currently-up
force-reload - can still be done with ifreload -f -a
We keep start, stop, reload, restart
Roopa Prabhu [Wed, 23 Dec 2015 07:34:17 +0000 (23:34 -0800)]
debian: remove systemd networking .service file
This patch temporarily removes systemd networking service
script. This enables ifupdown2 native init script to run.
systemd networking init script will be re-enabled in the
future after we test and claim that it works.
Add back missing ifupdown/ifupdownconfig.py.
fixes a cherry-pick error.
Fixes 0582f185edf0 ("ifupdown2: address: squash addr config and process
them on the youngest sibling") Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Sam Tannous [Mon, 30 Nov 2015 01:22:06 +0000 (20:22 -0500)]
ifupdown not restoring mstpctl attributes (e.g. bpdufilter, bpduguard) in mstpctl
Ticket: CM-7756
Reviewed By: roopa
Testing Done: built powerpc and tested ifupdown2 as well as new tests
Once mstpctl-portbpdufilter or mstpctl-bpduguard is enabled for
an interface, removing the configuration in /etc/network/interfaces
does not toggle the mstpctl state back to no.
The root cause of this problem is that "ifreload" does not check default settings for MSTP configuration
for bridge ports and use a default when that setting is removed from the configuration.
This patch adds a check in the existing loop on attribute values.
If there is no configured value, we check to see if a default exists.
self._modinfo['attrs'][attrname]['default'] exists.
If it exists and it is different then the currently running value
we reset the attribute to its default. This is what a customer would expect if
they removed a configured value.
(also added test in cl-tests to check this functionality)
Roopa Prabhu [Sun, 22 Nov 2015 06:53:29 +0000 (22:53 -0800)]
ifupdown2: bridge: try to interpret bridge port add rtnetlink return strings from
iproute and print meaningful error
Ticket: CM-6278
Reviewed By: CCR-3851
Testing Done: Tested error cases for bridge with multiple vlans when
net.bridge.bridge-allow-multiple-vlans is zero
new error message with the patch:
$ifquery br-vlan0502
auto br-vlan0502
iface br-vlan0502
bridge-ports swp2.502 swp3.12
bridge-stp on
mstpctl-portadminedge swp2.502=yes
mstpctl-portbpdufilter swp2.502=yes
address 3.50.2.1/24
$ifup br-vlan0502
<snip>
error: br-vlan0502: net.bridge.bridge-allow-multiple-vlans not set, multiple
vlans not allowed
error: br-vlan0502: failed to execute cmd 'ip -force -batch - [link set
dev swp3.12 master br-vlan0502
addr flush dev swp3.12
]'(RTNETLINK answers: Invalid argument
Command failed -:1)
Roopa Prabhu [Tue, 17 Nov 2015 17:48:21 +0000 (09:48 -0800)]
ifupdown2: bridge: fix bridge-pvid under bridge 'notfound' during ifquery --check
Ticket:
Reviewed By:
Testing Done: Tested ifquery --check with bridge-pvid
bridge-pvid and bridge-vids on a bridge does
not correspond directly to a running config
on the bridge. They correspond to default
values for the bridge ports. And they are
already checked against running config of the
bridge port and reported against a bridge port.
So, This patch ignores these attributes under the bridge.
Uses '2' for ignore today. XXX: '2' will be
mapped to a defined value in subsequent patches.
Roopa Prabhu [Tue, 17 Nov 2015 05:00:40 +0000 (21:00 -0800)]
ifupdown2: address: squash addr config and process them on the youngest sibling
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"
This is mostly a cosmetic fix. we were failing with weird/unclear errors
on unable to parse regex expressions correctly.
This patch mainly adds the interface name to the message and plus adds
an info message showing the actual regex being used in searches.
example config:
{noformat}
auto br-roopa
iface br-roopa
bridge-vlan-aware yes
bridge-ports regex '(\\Aswp3\\Z|\\Aswp4\\Z)'
bridge-pvid 20
{noformat}
before the patch:
warning: br-roopa: error getting dependent interfaces (unbalanced
parenthesis)
This introduced an error where if the config has old bridge driver
and configures port attributes on the bridge, the attributes are reset
to defaults after they are configured by the bridge settings.
On bootup and during service network restart these warning messages are thrown out.
root@cel-ken-01:/var/log# service networking restart
[....] Reconfiguring network interfaces...warning: global name 'get_mod_subattr' is not defined
warning: global name 'get_mod_subattr' is not defined
warning: global name 'get_mod_subattr' is not defined
Once mstpctl-portbpdufilter or mstpctl-bpduguard is enabled for
an interface, removing the configuration in /etc/network/interfaces
does not toggle the mstpctl state back to no.
The root cause of this problem is that "ifreload" does not check default settings for MSTP configuration
for bridge ports and use a default when that setting is removed from the configuration.
This patch adds a check in the existing loop on attribute values.
If there is no configured value, we check to see if a default exists.
self._modinfo['attrs'][attrname]['default'] exists.
If it exists and it is different then the currently running value
we reset the attribute to its default. This is what a customer would expect if
they removed a configured value.
Wilson Kok [Tue, 10 Nov 2015 22:16:00 +0000 (14:16 -0800)]
ifupdown: fixed bridge port pvid config on reboot
Ticket: CM-8161
Reviewed By: Roopa
Testing Done:
With vlan-aware bridge, when replacing a port's pvid, the kernel leaves
the port in the original pvid and relies on user space to explicitly
delete the port from that vlan if it is no longer a member of that.
ifupdown does that correctly in ifup and ifreload cases, but missed
removing the port from the default pvid during system reboot. This
patch fixes that by removing the PERFMODE check specifically for pvid
that causes ifupdown to skip checking running config on reboot which
leads to the bug.
Sam Tannous [Tue, 20 Oct 2015 17:49:07 +0000 (13:49 -0400)]
ifupdown2 should allow speed setting even with duplicate iface stanzas
Ticket: CM-6740
Reviewed By: roopa
Testing Done: tested multiple ifreloads with various test cases
In the case of duplicate iface stanzas where one of the stanzas sets
the link attributes, ifupdown2 was confused because the absence
of link attributes forced it to reset them to default values
(when they existed).
This patch tracks link changes and prevents resetting to defaults
only if there are no explicit settings configured. Furthermore,
only the last interface processed (from the duplicates) will take
care of resetting to defaults.
Roopa Prabhu [Fri, 9 Oct 2015 23:32:02 +0000 (16:32 -0700)]
change address on bridge and slave to an info message instead of a warn
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"
Roopa Prabhu [Fri, 9 Oct 2015 22:14:56 +0000 (15:14 -0700)]
Fix the return value for auto interface checks
Ticket: CM-7851
Reviewed By: CCR-3639
Testing Done: Tested a combination of auto and non-auto interfaces.
This fixes a regression introduced in 2.5.4 where ifreload was
picking up non-auto interfaces
This also fixes a minor issue with blacklisting interfaces introduced by
("450c679249b546dbc2cd97d81b49e011fec948bd remove blacklisted interfaces
only if they are upperifaces (ie root of the tree") when an interface
has multiple auto and non-auto stanzas (A rare case, but it was an easy
fix and around the same area).
example, the fix will now blacklist an interface only if all of its stanzas are
blacklisted. In the below example, swp4 is not blacklisted if user
specified auto because one of the iface stanzas is auto.
would fail because while -i was given with stdin, the check for missing filename would produce an error.
It was also decided by consensus that the ifquery command does not need to have a check for
disable_cli_interfacesfile since a query "should" not pose a security check.
(I've also added some test cases for this in cl-tests).
Roopa Prabhu [Fri, 2 Oct 2015 20:18:03 +0000 (13:18 -0700)]
remove blacklisted interfaces only if they are upperifaces (ie root of
the tree)
Ticket: CM-7765
Reviewed By: CCR-3621
Testing Done: tested interface dependencies with auto and non-auto
interfaces
This commit fixes a change in behaviour introduced by "460906d0552d" ("skip adding
filtered or blacklisted interfaces in the dependency graph") that
skipped non-auto (or blacklisted) interfaces.
Turns out we have files out there that do have non-auto
dependents. This patch makes sure blacklisted interfaces who are
dependents of other interfaces are always picked up.
ifupdown2 state file was moved to /var/tmp because /var/tmp was tmpfs
and was large enough (100MB) for the state file. But it appears it has
changed (or is not consistent) across all platforms. We can move it
under /run, but /run again size varies on various platforms and it is
too small on some platforms.
This patch:
- continues to keep the ifupdown2 state file under /var/tmp (because it
needs the space)
- ntroduces a second level /run/network/ifstatelock file that stays on
non-persistant storage and is used to delete the state file at /boot up
Fix mstp settings ordering issues when bridge stp is toggled on and off
(when mstp settings are specified under the port)
Ticket: CM-6626
Reviewed By: CCR-3599
Testing Done: Tested the problem case mentioned in the bug (Plan to
re-work the fix a bit for 2.5.5)
problem:
mstp parameters can be specified under the port or under the bridge
When they are specified under the bridge, there should be no problem
(When you process the bridge, all things on the bridge port are set in
order)
When they are specified under the port:
we check if the bridge is up, if yes, and stp is already configured,
we process mstpctl settings
This check today only checks running stp_state
We should also check the user configured stp state for the bridge
Note that the problem exists only if the bridge and ports are
already up and user executes ifup again and when we need to re-evaluate
the bridge port settings
solution:
When the bridge port is being checked for mstp settings, not only
check running stp state, but also check user specified stp state and
correct bridge stp state before proceeding with mstp configuration
Few things to note with this patch:
- If user changed stp state on bridge to 'on', and did `ifup
<bridge_port>'`,
though the user has not ifup'ed the bridge yet, the bridge stp state
will be applied (very few people will run into this and practically this
should not be a problem atall. But from correctness POV it is
a voilation. ).
- To avoid this, the other solution would have been to let the bridge
port code be as is, but handle this during bringing up the bridge,
but, this can confuse the user, because when processing the
bridge_port, you will still throw warnings even if the port stp config
is later reapplied when the bridge comes up
- note that the patch only handles the case when stp state is not on and
somebody turned it on. For the case where stp state was on and somebody
turned it off, this patch wont throw warnings for the mstpctl config. But
it will not cause any issues because once stp is off things will be ok
everywhere. I want to keep any changes here out of this patch. I will
document this in the bug...and see if i can handle this in 2.5.5
This patch separates the json encoders for iface objects with and
without status (ifaceJsonEncoder and ifaceJsonEncoderWithStatus) so
that they dont interfere with each other.
ifquery --check non-json output displays 'pass' and 'fail' for
each attribute on the same line (see below). This output is not json
friendly. For json, include status in 'config_status' a dictionary
whose keys are similar to the 'config' dictionary but values are status
for the corresponding keys in the 'config' dictionary (see example below)
When vxrd is not enabled in /etc/default/vxrd, the 'service vxrd status'
command returns 0, causing the vxlan-remoteip to be not applied even
though it should have. Fix is to change to checking pidfile of vxrd.
ifupdown2 changes for vxlan anycast_ip, head-end fdb entries, protodown
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.
With recent change to ifupdown2 to create dummy devices (CM-3525), pre-up
sequence has been inadvertently changed to invoke clag before vxlan. This
causes protodown of vxlan device by clag addon to happen before vxlan device
gets added. Revert the pre-up order to have vxlan pre-up before clag's.
This is modification to gospos loopback module. It solves the same
purpose ie using linux dummy device like a loopback device but there were
objections on calling it loopback so i have renamed it to link and i have changed it
into a generic module that can do any 'ip link'. Can be extended for
link args in the future.
below example creates a loopy device
$ifquery loopy
auto loopy
iface loopy
link-type dummy
Sam Tannous [Fri, 21 Aug 2015 03:12:26 +0000 (23:12 -0400)]
ifupdown2 ethtool does not handle link-* settings on enslaved ports
Ticket: CM-7128
Reviewed By: Trivial
Testing Done: unit tested on Ken's machine
The ifupdown2 ethtool addon module fails to set/check
the link-speed on bridge ports.
I removed excessive ifaceLinkKind checking since CM-6619
(03642a9a) added BRIDGE_PORT and BOND_SLAVE. This is ok
since we now check to see if ports have defaults (only swp do)
before showing or changing settings).
Sam Tannous [Fri, 21 Aug 2015 02:59:44 +0000 (22:59 -0400)]
add param in ifupdown2.conf to prevent fupdown2 users from specify interface config file on the CLI
Ticket: CM-7066
Reviewed By: scotte,roopa,olson
Testing Done: Unit testing and regression testing
This patch does two things:
1. It moves the interfaces config file name to the ifupdown2.conf file in /etc/network/ifupdown2.
This should allow administrators to specify a config file location different from the default and allow
subsets of users to use it without giving them access to specifying their own with the -i option in ifup/ifdown.
2. It also adds a new config setting called "disable_cli_interfacesfile" used to prevent users
from specifying their own interfaces file. This defaults to "1" (even if it is not configured).
Note: this new default takes away users ability to specify an interfaces file.
This should close the vulnerability where users could specify their own interfaces file
and add arbitrary user commands.
This leaves the shell=True option in the user commands add-on module since the ifup/ifdown/ifreload/ifquery
commands already require root access to run and the interfaces config file also requires root access to modify.
Currently, ifupdown implicitly configures pvid on a bridge port
in case user doesn't configure it. There is no way to configure
a bridge port to not accept untagged packets. The new option
allows user to do that without changing the current default
behavior.
The "ip batch command to add a bridge port and flush the dev" command with 1k netdevices was taking 1.4G of memory. With 2k netdevices batch, this command was causing a OOM condition. To avoid this, commit the batch after 250 ports. Ideally we have to look at the internal batch implementation to see if there is an underlying issue.
Sam Tannous [Thu, 30 Jul 2015 15:15:17 +0000 (11:15 -0400)]
Document --exclude option a little better for ifupdown2
Ticket: CM-6587
Reviewed By: roopa
Testing Done: checked man paged
If we do an ifdown on all ports and try to exclude a bond or bridge port.
But we also have an iface defined for swp1 or swp4
(even if these are empty).
The lower interfaces will not be excluded. So if we
do an "ifdown -a -X bridge", swp ports in the bridge or bond
will go down effectively bringing a bond or bridge down.
This patch simply adds some documentation to the man pages.
ifupdown2 never follows dependents if the user has given an
interface list (unless explicitly requested with --with-depends
option which is available with some options).
Sam Tannous [Thu, 23 Jul 2015 19:43:45 +0000 (15:43 -0400)]
ifupdown2 patch to properly remove address-virtual mac addresses
Ticket: CM-6702
Reviewed By: roopa
Testing Done: unit and smoke tested with ifupdown2 suite
When address-virtual mac adddress is modified, removed from an SVI, or the SVI is removed,
the permanent mac address is not removed.
This patch addresses all three cases but creating a global statemanager instance
and removing address-virtual FDB entries that were previously configured.
CM-6815 : ip link set syntax for svcnode has been changed. Absence of svcnode
will retain the existing values. svcnode 0.0.0.0 is needed to wipe out service
node addresses in vxlan device. Modified ifupdown2 to use svcnode 0.0.0.0 to
clean up service node address.
CM-6816: "bridge-clan-aware no" is not handled in query-check and hence ifquery
on bridge interface with "bridge-vlan-aware no" fails. Modified bridge's
query-check to take care of this.
CM-6817: With default ageing value (300), if query -c <vxlan device> was
failing. Set ageing to 300 if not specified and compare it with running config.
Dont up a vlan aware bridge during upper iface bringup (optimization)
Ticket: CM-6619
Reviewed By: CCR-3191
Testing Done: Tested upperiface bringup for bridge and vlan devices
'up' on bridge was always done to add the newly created port to the bridge
in cases where the bridge is not part of the interfaces being brought
up. But This will try to re-apply bridge port attributes on all bridge
ports and that can take a while when there are large number of bridge
ports. This patch currently avoids the bridge up for only the vlan
aware bridge case.
and allows users to modify this file. Users can then leave out these
bond attributes in their configs to save typing and space.
It also changes the ifenslave and ifenslaveutil module to bond and
bondutil, respectively to be consistent with other modules
(and also because customers think of "bond" interfaces not
"ifenslave" interfaces.)
For example, the default file installed looks like the following:
{
"README": "This file is user generated and modifiable.",
"bond": {
"defaults": {
"bond-mode": "802.3ad",
"bond-miimon": "100",
"bond-use-carrier": "1",
"bond-lacp-rate": "0",
"bond-min-links": "1",
"bond-xmic-hash-policy": "layer3+4"
}
}
}
Please enter the commit message for your changes. Lines starting