This patch is a follow up to the recently added
'static' fdb option.
It introduces a new option 'dynamic' which adds
dynamic fdb entries with NUD_REACHABLE.
$bridge fdb add 00:01:02:03:04:06 dev eth0 master dynamic
$bridge fdb show
00:01:02:03:04:06 dev eth0
This patch also documents all fdb types. Removes 'temp'
from usage message since it is now replaced by 'static'.
'temp' still works and is synonymous with static.
Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
There is no intuitive option to add static fdb entries today.
'temp' seems to have a side effect of adding
'static' fdb entries. But the name and intent
of 'temp' does not say anything about it being static.
example:
bridge fdb add operates as follows:
$bridge fdb add 00:01:02:03:04:05 dev eth0 master
$bridge fdb add 00:01:02:03:04:06 dev eth0 master temp
$bridge fdb add 00:01:02:03:04:07 dev eth0 master local
$bridge fdb show
00:01:02:03:04:05 dev eth0 permanent
00:01:02:03:04:06 dev eth0 static
00:01:02:03:04:07 dev eth0 permanent
00:01:02:03:04:08 dev eth0 <<== dynamic, ageable learned mac
This patch adds a new bridge fdb type 'static' which
makes sure NUD_NOARP and NUD_REACHABLE is set for static
entries. This effectively is nothing but what 'temp'
does today. But the name 'temp' is misleading.
After the patch:
$bridge fdb add 00:01:02:03:04:06 dev eth0 master static
$bridge fdb show
00:01:02:03:04:06 dev eth0 static
'temp' could ideally be a dynamic mac that can age (ie just
NUD_REACHABLE). But, 'temp' sets 'NUD_NOARP' and 'NUD_REACHABLE'.
Too late to change 'temp' now. But, we are thinking of introduing a
'dynamic' keyword after this patch that only sets NUD_REACHABLE.
Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds fflush in fdb and mdb print functions
Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds support to batch bridge commands.
Follows ip batch code.
Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Acked-by: Christophe Gouault <christophe.gouault@6wind.com>
Before this patch both addmdb and delmdb events were printed the same,
now we'll get a "Deleted" string in front when delmdb is received.
Before:
$ bridge mdb add dev br0 port eth3 grp 239.0.0.1
(monitor) dev br0 port eth3 grp 239.0.0.1 temp
$ bridge mdb del dev br0 port eth3 grp 239.0.0.1
(monitor) dev br0 port eth3 grp 239.0.0.1 temp
^^ No way to differentiate between both events.
After:
$ bridge mdb add dev br0 port eth3 grp 239.0.0.1
(monitor) dev br0 port eth3 grp 239.0.0.1 temp
$ bridge mdb del dev br0 port eth3 grp 239.0.0.1
(monitor) Deleted dev br0 port eth3 grp 239.0.0.1 temp
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
This is similar to command options corresponding to other NTF_* flags
already exposed to the user space (examples self/master).
Also updates bridge man page (The man page patch also includes
a fix to the 'self' entry and documents 'master' for fdb entries)
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Reviewed-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
This patch allows the user to specify the vlan of the mdb group being
added or deleted and adds support for displaying the vlan when
dumping mdb information or monitoring it. It also updates the man page
to reflect the new "vid" argument for mdb.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
This patch adds support for ADDMDB/DELMDB notifications about router ports
which have been added or deleted/expired respectively.
Example output:
$ bridge -s monitor mdb
Deleted router port dev eth3 master br0
router port dev eth3 master br0
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
There have been several instances where response from kernel
has overrun the stack buffer from the caller. Avoid future problems
by passing a size argument.
Also drop the unused peer and group arguments to rtnl_talk.
The kernel now has the capability to offload FDB and FIB entries to hardware.
It is important to let users know if table entries are also offloaded to
hardware. Currently offloaded FDB entries are indicated by the existence of
the flag 'external' on the entry as of the following commit:
commit 28467b7f3f
Author: Scott Feldman <sfeldma@gmail.com>
Date: Thu Dec 4 09:57:15 2014 +0100
bridge/fdb: add flag/indication for FDB entry synced from offload device
When the patch to add support for indicating that FIB entries were also
offloaded as posted to netdev by Scott Feldman it became clear that 'external'
would not be an ideal name for routes. There could definitely be confusion
about what this might mean since many routes are to external networks -- a
collision/confusion that did not happen with FDB.
Scott Feldman asked me to check with others and build concensus around a name.
After speaking with several people about this I am proposing we refer to both
FDB and FIB entries that are currently backed by hardware (based on the work
done in rocker) with the flag 'offload' appended to the end ofthe entry.
Some people liked the string 'external,' others liked 'hardware,' but the point
is to communicate that these routes are available to something that will will
offload the forwarding normally done by the kernel. Since the term 'offload'
is used so frequently it seems appropriate to use the same language in
ip/bridge output.
The term 'offload' also seems to resonate with many of the people who have
responded on Scott's original thread or to those who I reached out to directly
and did respond to my query, so it seems we have reached consensus that it
should be the term used going forward.
v2: rebased against net-next branch
Signed-off-by: Andy Gospodarek <gospo@cumulusnetworks.com>
CC: Jamal Hadi Salim <jhs@mojatatu.com>
CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
CC: Jiri Pirko <jiri@resnulli.us>
CC: John W. Linville <linville@tuxdriver.com>
CC: Roopa Prabhu <roopa@cumulusnetworks.com>
CC: Scott Feldman <sfeldma@gmail.com>
CC: Stephen Hemminger <stephen@networkplumber.org>
This patch replaces exits with returns in several
iproute2 commands. This fixes `ip -batch -force`
to not exit but continue on errors.
$cat c.txt
route del 1.2.3.0/24 dev eth0
route del 1.2.4.0/24 dev eth0
route del 1.2.5.0/24 dev eth0
route add 1.2.3.0/24 dev eth0
$ip -force -batch c.txt
RTNETLINK answers: No such process
Command failed c.txt:2
RTNETLINK answers: No such process
Command failed c.txt:3
Reported-by: Sven-Haegar Koch <haegar@sdinet.de>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
This patch adds support to specify 'master' keyword,
to target a bridge link command explicitly to the software
bridge driver.
Adds self/master keywords to usage and man page
v2:
fix usage to say (self and master) and not (self or master)
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
The existing behaviour forces one to memorize the integer constants for
STP port states.
# bridge link set dev dummy0 state 3
This patch makes it possible to use the lowercased port state name.
# bridge link set dev dummy0 state forwarding
Invalid non-integer inputs now cause exit with status -1.
Signed-off-by: Alex Pilon <alp@alexpilon.ca>
When this attribute is set, it means that the i/o part of the related netdevice
is in another netns.
Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
v2:
Resending now that the dust has cleared in 3.18 on "self" vs. hwmode debate for
brport settings. learning_sync is now set/cleared using "self" qualifier on
brport.
v1:
Add 'learned_sync' flag to turn on/off syncing of learned MAC addresses from
offload device to bridge's FDB. Flag is be set/cleared on offload device port
using "self" qualifier:
$ sudo bridge link set dev swp1 learning_sync on self
$ bridge -d link show dev swp1
2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 2
hairpin off guard off root_block off fastleave off learning off flood off
2: swp1 state UNKNOWN : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0
learning on learning_sync on
Adds new IFLA_BRPORT_LEARNED_SYNCED attribute for IFLA_PROTINFO on the SELF
brport.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Currently self is set internally only if hwmode is set.
This makes it necessary for the hw to have a mode.
There is no hwmode really required to go to hardware. So, introduce
self for anybody who wants to target hardware.
v1 -> v2
- fix a few bugs. Initialize flags to zero: this was required to
keep the current behaviour unchanged.
v2 -> v3
- fix comment
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Reviewed-by: Jiri Pirko <jiri@resnulli.us>
Add NTF_EXT_LEARNED flag to neigh flags to indicate FDB entry learned by
device has been learned externally to bridge FDB. For these entries,
add "external" annotation in bridge fdb show output:
00:02:00:00:03:00 dev swp2 used 2/2 master br0 external
00:02:00:00:03:00 dev swp2 self permanent
In the example above, 00:02:00:00:03:00 is shown twice on dev swp2. The
first entry if from the bridge (master) and is marked as "external" by
the offload device. The second entry is from the brport offload device (self),
and was learned by the device.
Signed-off-by: Scott Feldman <sfeldma@gmail.com>
Signed-off-by: Jiri Pirko <jiri@resnulli.us>
Acked-by: Jamal Hadi Salim <jhs@mojatatu.com>
root@moja-mojo:bridge# ./bridge fdb help
Usage: bridge fdb { add | append | del | replace } ADDR dev DEV {self|master} [ temp ]
[router] [ dst IPADDR] [ vlan VID ]
[ port PORT] [ vni VNI ] [via DEV]
bridge fdb {show} [ br BRDEV ] [ brport DEV ]
Lets start with two bridges each with a port...
root@moja-mojo:bridge# ./bridge link
10: sw1-p1 state DOWN : <BROADCAST,NOARP> mtu 1500 master sw1 state disabled priority 32 cost 100
11: eth1 state DOWN : <BROADCAST,NOARP> mtu 1500 master br0 state disabled priority 32 cost 100
show all...
root@moja-mojo:bridge# ./bridge fdb show
33:33:00:00:00:01 dev ifb0 self permanent
33:33:00:00:00:01 dev ifb1 self permanent
33:33:00:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev eth0 self permanent
33:33:ff:92:c0:60 dev eth0 self permanent
33:33:00:00:00:fb dev eth0 self permanent
01:00:5e:00:00:fb dev eth0 self permanent
01:00:5e:7f:ff:fd dev eth0 self permanent
01:00:5e:00:00:01 dev wlan0 self permanent
33:33:00:00:00:01 dev wlan0 self permanent
33:33:ff:c2:84:3b dev wlan0 self permanent
33:33:00:00:00:fb dev wlan0 self permanent
01:00:5e:00:00:01 dev virbr0 self permanent
01:00:5e:00:00:fb dev virbr0 self permanent
33:33:00:00:00:01 dev br0 self permanent
33:33:00:00:00:01 dev sw1 self permanent
33:33:00:00:00:01 dev dummy0 self permanent
5e:f4:03:44:da:9a dev sw1-p1 vlan 0 master sw1 permanent
33:33:00:00:00:01 dev sw1-p1 self permanent
b6:5e:dd:ce:d7:5e dev eth1 vlan 0 master br0 permanent
33:33:00:00:00:01 dev eth1 self permanent
Lets see a netdev that is *not* attached to a bridge
root@moja-mojo:bridge# ./bridge fdb show brport eth0
33:33:00:00:00:01 self permanent
01:00:5e:00:00:01 self permanent
33:33:ff:92:c0:60 self permanent
33:33:00:00:00:fb self permanent
01:00:5e:00:00:fb self permanent
01:00:5e:7f:ff:fd self permanent
Lets see a netdev that is bridge port
root@moja-mojo:bridge# ./bridge fdb show brport eth1
hadi@jhs-1:/media/MT1/other-gits/iproute-jul04/bridge$ ./bridge fdb show brport eth1
b6:5e:dd:ce:d7:5e vlan 0 master br0 permanent
33:33:00:00:00:01 self permanent
Specify the correct bridge and you get good stuff
root@moja-mojo:bridge# ./bridge fdb show brport eth1 br br0
6:5e:dd:ce:d7:5e vlan 0 master br0 permanent
33:33:00:00:00:01 self permanent
Specify the wrong bridge and you get good nada
root@moja-mojo:bridge# ./bridge fdb show brport eth1 br sw1
dump br0
root@moja-mojo:bridge# ./bridge fdb show br br0
33:33:00:00:00:01 dev br0 self permanent
b6:5e:dd:ce:d7:5e dev eth1 vlan 0 master br0 permanent
33:33:00:00:00:01 dev eth1 self permanent
dump sw1
root@moja-mojo:bridge# ./bridge fdb show br sw1
33:33:00:00:00:01 dev sw1 self permanent
5e:f4:03:44:da:9a dev sw1-p1 vlan 0 master sw1 permanent
33:33:00:00:00:01 dev sw1-p1 self permanent
Lets move a port from one bridge to another for shits-and-giggles
(as the New Brunswickians like to say)
root@moja-mojo:bridge# ip link set sw1-p1 master br0
Now dump again br0
root@moja-mojo:bridge# ./bridge fdb show br br0
33:33:00:00:00:01 dev br0 self permanent
5e:f4:03:44:da:9a dev sw1-p1 vlan 0 master br0 permanent
33:33:00:00:00:01 dev sw1-p1 self permanent
b6:5e:dd:ce:d7:5e dev eth1 vlan 0 master br0 permanent
33:33:00:00:00:01 dev eth1 self permanent
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
This patch adds master dev name from NDA_MASTER netlink attribute
to bridge fdb show output
current iproute2 tries to print 'master' in the output if NTF_MASTER
is present. But, kernel today does not set NTF_MASTER during dump
requests. Which means I have not seen iproute2 bridge cmd print 'master' atall.
This patch overrides the NTF_MASTER flag if NDA_MASTER attribute is present.
Example output:
before this patch:
# bridge fdb show
44:38:39:00:27:ba dev bond2.2003 permanent
44:38:39:00:27:bb dev bond4.2003 permanent
44:38:39:00:27:bc dev bond2.2004 permanent
After this patch:
# bridge fdb show
44:38:39:00:27:ba dev bond2.2003 master br-2003 permanent
44:38:39:00:27:bb dev bond4.2003 master br-2003 permanent
44:38:39:00:27:bc dev bond2.2004 master br-2004 permanent
For comparision with the above, below is the output for NTF_SELF today,
# bridge fdb show
33:33:00:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev eth0 self permanent
33:33:ff:00:01:cc dev eth0 self permanent
If change in output is a concern, 'master' can be put at the end of the fdb
output line or made optional with -d[etails] option.
change from v1 to v2:
use 'bridge' instead of 'master' in fdb show output
change from v2 to v3:
use 'master' instead of 'bridge' in fdb show output
(master could also be a vxlan device)
Signed-off-by: Wilson Kok <wkok@cumulusnetworks.com>
Signed-off-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Michael Tautschnig wrote:
During a rebuild [...]. Please note that we use our research
compiler tool-chain (using tools from the cbmc package), which permits extended
reporting on type inconsistencies at link time.
[...]
gcc bridge.o fdb.o monitor.o link.o mdb.o vlan.o ../lib/libnetlink.a ../lib/libutil.a ../lib/libnetlink.a ../lib/libutil.a -o bridge
file link.c line 18: error: conflicting types for variable "filter_index"
old definition in module fdb file fdb.c line 29
signed int
new definition in module link file link.c line 18
unsigned int
<builtin>: recipe for target 'bridge' failed
make[3]: *** [bridge] Error 64
make[3]: Leaving directory '/srv/jenkins-slave/workspace/sid-goto-cc-iproute2/iproute2-3.14.0/bridge'
Makefile:45: recipe for target 'all' failed
While practical constraints may limit the value of filter_index to remain within
the bounds of a positive signed int, there is certainly no such guarantee here.
Also, a plain majority vote suggests that this really just a wrong declaration
in link.c as several declarations of filter_index as signed int exist.
[...]
My followup on this was:
I think the majority is wrong.
filter_index is assigned exclusively from if_nametoindex or ll_name_to_index
which both return unsigned int.
Changing it to unsigned everywhere seems better.
This has been minimally tested by using the bridge tool
to add vids and showing available vids on different devices.
Reported-by: Michael Tautschnig <mt@debian.org>
Signed-off-by: Andreas Henriksson <andreas@fatal.se>
We need limits.h for LONG_MIN and LONG_MAX, sys/param.h for MIN and
sys/select for struct timeval.
This fixes the following compile errors with musl libc:
f_bpf.c: In function 'bpf_parse_opt':
f_bpf.c:181:12: error: 'LONG_MIN' undeclared (first use in this function)
if (h == LONG_MIN || h == LONG_MAX) {
^
...
tc_util.o: In function `print_tcstats2_attr':
tc_util.c:(.text+0x13fe): undefined reference to `MIN'
tc_util.c:(.text+0x1465): undefined reference to `MIN'
tc_util.c:(.text+0x14ce): undefined reference to `MIN'
tc_util.c:(.text+0x154c): undefined reference to `MIN'
tc_util.c:(.text+0x160a): undefined reference to `MIN'
tc_util.o:tc_util.c:(.text+0x174e): more undefined references to `MIN' follow
...
tc_stab.o: In function `print_size_table':
tc_stab.c:(.text+0x40f): undefined reference to `MIN'
...
fdb.c:247:30: error: 'ULONG_MAX' undeclared (first use in this function)
(vni >> 24) || vni == ULONG_MAX)
^
lnstat.h:28:17: error: field 'last_read' has incomplete type
struct timeval last_read; /* last time of read */
^
Signed-off-by: Natanael Copa <ncopa@alpinelinux.org>
The `bridge monitor file FILENAME' reads dumped netlink messages from
a file. But it forgot to close the file after using it. This patch
fixes it.
Signed-off-by: Petr Písař <ppisar@redhat.com>
Add support for the bridge fdb replace command to replace an
existing entry in the vxlan device driver forwarding data base.
The entry is identified with its unicast mac address and its
corresponding remote destination information is updated.
This is useful for virtual machine migration and replaces the
bridge fdb del and bridge fdb add commands.
It follows the same interface as ip neigh replace commands.
Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
The bridge fdb command line help and the bridge.8
man page are outdated in regards to the vxlan support.
The patch updates both the command line help for the
bridge command and its man page.
Signed-off-by: Thomas Richter <tmricht@linux.vnet.ibm.com>
Use IFLA_AF_SPEC nested attributes to lookup bridge mode and when
doing strcmp() check for equality.
These appear to be typos from the original commit,
commit 64108901b7
Author: Vlad Yasevich <vyasevic@redhat.com>
Date: Fri Mar 15 10:01:28 2013 -0700
bridge: Add support for setting bridge port attributes
Also set flags to BRIDGE_FLAGS_SELF instead of using OR operation.
This allows setting the bridge mode when not being used with a
master device.
To allow setting both master and self devices simultaneously we
will need to add a {self|master} field similar to fdb commands.
For now the command sets are mutually exclusive as noted in the
original commit.
With this patch 'bridge link set' works now,
# ./bridge/bridge link set dev veth1 cost 3
# ./bridge/bridge link show
10: veth1 state UP : <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master bridge0 state forwarding priority 3 cost 3
CC: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
This patch allows setting the "NTF_ROUTER" flag in VXLAN forwarding table
entries to enable L3 switching for router destinations while still allowing
L2 redirection appliances for non-router MAC destinations.
Signed-Off-By: David L Stevens <dlstevens@us.ibm.com>
iproute2 patch to generalize VXLAN forwarding tables
This is the iproute2 support allowing an administrator to specify alternate
ports, vnis and outgoing interfaces for VXLAN device forwarding tables.
Changes since v3: changed NDA_PORT to be 16-bit network byte order to match
changed byte-order/size in the VXLAN driver.
Signed-Off-By: David L Stevens <dlstevens@us.ibm.com>
Add netlink support bridge port attributes such as cost, priority, state
and flags. This also adds support for HW mode such as VEPA or VEB.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
Recent kernel patches added support for VLAN filtering on the bridge.
This functionality allows one to turn a basic bridge into a VLAN bridge,
where VLANs dicatate packet forwarding and header transformation.
To configure the VLANs on the bridge and its ports a new command is
added to the 'bridge' utility.
# bridge vlan add dev eth0 vid 10 pvid untagged brdev
# bridge vlan add
# bridge vlan delete dev eth0 vid 10
# bridge vlan show
This command supports the following flags:
master - peform the operation on the software bridge device. This is
the default behavior.
self - perform the operation on the hardware associated with the port.
This flag is required when the device is the bridge device and
the configuration is desired on the bridge device itself (not
one of the ports).
pvid - Set the PVID (port vlan id) for a given port. Any untagged
frames arriving on the port will be assigned to this vlan.
untagged - Sets the egress policy of for a given vlan. Default port
egress policy is tagged. Set this flag if you wish traffic
associated with this VLAN to exit the port untagged.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
This is the iproute2 support allowing an administrator to specify alternate
ports, vnis and outgoing interfaces for VXLAN device forwarding tables.
Signed-Off-By: David L Stevens <dlstevens@us.ibm.com>
