include/utils.h already provides textify(), which is functionally
equivalent to __stringify().
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Allow a port's spanning tree state to be modified on a per-MSTI basis,
and support dumping the current MST states for every port and MSTI.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Allow the user to associate one or more VLANs with a multiple spanning
tree instance (MSTI), when MST is enabled on the bridge.
Signed-off-by: Tobias Waldekranz <tobias@waldekranz.com>
Reviewed-by: Hangbin Liu <liuhangbin@gmail.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
On glibc based systems the definition of 'struct timeval' is pulled in
with inclusion of <stdlib.h> header, but on musl based systems it
doesn't work this way. Missing definition triggers an
incompatible-pointer-types error with gcc 14 (warning on previous
versions of gcc):
../include/json_print.h:80:30: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
80 | _PRINT_FUNC(tv, const struct timeval *)
| ^~~~~~~
../include/json_print.h:50:37: note: in definition of macro '_PRINT_FUNC'
50 | type value); \
| ^~~~
../include/json_print.h:80:30: warning: 'struct timeval' declared inside parameter list will not be visible outside of this definition or declaration
80 | _PRINT_FUNC(tv, const struct timeval *)
| ^~~~~~~
../include/json_print.h:55:45: note: in definition of macro '_PRINT_FUNC'
55 | type value) \
| ^~~~
../include/json_print.h: In function 'print_tv':
../include/json_print.h:58:48: error: passing argument 5 of 'print_color_tv' from incompatible pointer type [-Wincompatible-pointer-types]
58 | value); \
| ^~~~~
| |
| const struct timeval *
Signed-off-by: Gabi Falk <gabifalk@gmx.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Fix the incorrect short opt for compressvlans and color
in usage
Signed-off-by: Date Huang <tjjh89017@hotmail.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Implement MDB flush functionality, allowing user space to flush MDB
entries from the kernel according to provided parameters.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Factor out the repeated code pattern
rta_type = attr->rta_type & NLA_TYPE_MASK
into a helper which is similar to the existing kernel function nla_type().
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
The two implementations are now identical so keep only one instance and
move it to json_print.c where there are already a few other specialized
printing functions.
The string that's formatted in the "end" buffer is only needed when
outputting a range so move the snprintf() call within the condition.
The second argument's purpose is better conveyed by calling it "end" rather
than "id" so rename it.
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Currently, `bridge vni` outputs an empty line after each interface. This is
not consistent with the output style of other iproute2 commands, in
particular `bridge vlan`. Therefore, remove the empty lines.
If there are scripts that parse the normal text output of `bridge vni`,
those scripts might be broken by the removal of the empty lines. This is a
secondary concern because those scripts should consume the JSON output
instead.
Before:
$ bridge vni
dev vni group/remote
vxlan1 4001
5000-5010
vxlan2 100
$
After:
$ ./bridge/bridge vni
dev vni group/remote
vxlan1 4001
5000-5010
vxlan2 100
$
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
print_vnifilter_rtm() is structured similarly to print_vlan_tunnel_info()
except that in the former, the open_vni_port() call is guarded by a "if
(first)" check whereas in the latter, the open_vlan_port() call is guarded
by a "if (!opened)" check.
Reverse the logic in one of the functions to have the same structure in
both. Since the calls being guarded are "open_...()", "close_...()", use
the "opened" logic structure.
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Currently, the call to open_vni_port() within print_vnifilter_rtm() is
written in a way that is safe if there is a RTM_{NEW,DEL,GET}TUNNEL message
without any VXLAN_VNIFILTER_ENTRY attribute. However the close_vni_port()
call is written in a way that assumes there is always at least one
VXLAN_VNIFILTER_ENTRY attribute within every RTM_*TUNNEL message. At this
time, this assumption is correct. However, the code should be consistent in
its assumptions. Choose the safe approach and fix the asymmetry between the
open_vni_port() and close_vni_port() calls by guarding the latter call with
a check.
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
print_vni() is used to output one vni or vni range which, in json output
mode, looks like
{
"vni": 100
}
Currently, the closing bracket is handled within the function but the
opening bracket is handled by open_json_object() before calling the
function. For consistency, move the call to open_json_object() within
print_vni().
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
print_vnifilter_rtm_filter() adds an unnecessary level of indirection so
remove it to simplify the code.
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
To make the code lighter, remove the check on the actual print_range()
output width. In the odd case that an out-of-range, wide vlan id is
printed, printf() will treat the negative field width as positive and the
output will simply be further misaligned.
Suggested-by: Petr Machata <petrm@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Currently, print_vlan_tunnel_info() is first outputting a formatted string
to a temporary buffer in order to use print_string() which can handle json
or normal text mode. Since this specific string is only output in normal
text mode, by calling printf() directly, we can avoid the need to first
output to a temporary string buffer.
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Add the missing 'vni' subcommand to the top level `bridge help`.
For `bridge vni { add | del } ...`, 'dev' is a mandatory argument.
For `bridge vni show`, 'dev' is an optional argument.
Fixes: 45cd32f9f7 ("bridge: vxlan device vnifilter support")
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
When there is a duplicate 'vni' option, report the error using duparg()
instead of the generic invarg().
Before:
$ bridge vni add vni 100 vni 101 dev vxlan2
Error: argument "101" is wrong: duplicate vni
After:
$ ./bridge/bridge vni add vni 100 vni 101 dev vxlan2
Error: duplicate "vni": "101" is the second value.
Fixes: 45cd32f9f7 ("bridge: vxlan device vnifilter support")
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Consider the following command with a duplicated "remote" argument:
$ bridge vni add vni 150 remote 10.0.0.1 remote 10.0.0.2 dev vxlan2
Error: argument "remote" is wrong: duplicate group
The error message is misleading because there is no "group" argument. Both
of the "group" and "remote" options specify a destination address and are
mutually exclusive so change the variable name and error messages
accordingly.
The result is:
$ ./bridge/bridge vni add vni 150 remote 10.0.0.1 remote 10.0.0.2 dev vxlan2
Error: duplicate "destination": "10.0.0.2" is the second value.
Fixes: 45cd32f9f7 ("bridge: vxlan device vnifilter support")
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
is_addrtype_inet_not_multi(&daddr) may read an uninitialized "daddr". Even
if that is fixed, the error message that follows cannot be reached because
the situation would be caught by the previous test (group_present).
Therefore, remove this test on daddr.
Fixes: 45cd32f9f7 ("bridge: vxlan device vnifilter support")
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Reviewed-by: Stephen Hemminger <stephen@networkplumber.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
`bridge vni help` shows "bridge vni { add | del } ..." but currently
`bridge vni del ...` errors out unexpectedly:
# bridge vni del
Command "del" is unknown, try "bridge vni help".
Recognize 'del' as a synonym of the original 'delete' command.
Fixes: 45cd32f9f7 ("bridge: vxlan device vnifilter support")
Reviewed-by: Petr Machata <petrm@nvidia.com>
Tested-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: Benjamin Poirier <bpoirier@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Implement MDB get functionality, allowing user space to query a single
MDB entry from the kernel instead of dumping all the entries. Example
usage:
# bridge mdb add dev br0 port swp1 grp 239.1.1.1 vid 10
# bridge mdb add dev br0 port swp2 grp 239.1.1.1 vid 10
# bridge mdb add dev br0 port swp2 grp 239.1.1.5 vid 10
# bridge mdb get dev br0 grp 239.1.1.1 vid 10
dev br0 port swp1 grp 239.1.1.1 temp vid 10
dev br0 port swp2 grp 239.1.1.1 temp vid 10
# bridge -j -p mdb get dev br0 grp 239.1.1.1 vid 10
[ {
"index": 10,
"dev": "br0",
"port": "swp1",
"grp": "239.1.1.1",
"state": "temp",
"flags": [ ],
"vid": 10
},{
"index": 10,
"dev": "br0",
"port": "swp2",
"grp": "239.1.1.1",
"state": "temp",
"flags": [ ],
"vid": 10
} ]
# bridge mdb get dev br0 grp 239.1.1.1 vid 20
Error: bridge: MDB entry not found.
# bridge mdb get dev br0 grp 239.1.1.2 vid 10
Error: bridge: MDB entry not found.
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Extend "fdb flush" command to match entries with or without (if "no" is
prepended) router flag.
Examples:
$ bridge fdb flush dev vx10 router
This will delete all fdb entries pointing to vx10 with router flag.
$ bridge fdb flush dev vx10 norouter
This will delete all fdb entries pointing to vx10, except the ones with
router flag.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Extend "fdb flush" command to match fdb entries with a specific destination
IP.
Example:
$ bridge fdb flush dev vx10 dst 192.1.1.1
This will flush all fdb entries pointing to vx10 with destination IP
192.1.1.1
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Extend "fdb flush" command to match fdb entries with a specific destination
port.
Example:
$ bridge fdb flush dev vx10 port 1111
This will flush all fdb entries pointing to vx10 with destination port
1111.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Extend "fdb flush" command to match fdb entries with a specific destination
VNI.
Example:
$ bridge fdb flush dev vx10 vni 1000
This will flush all fdb entries pointing to vx10 with destination VNI 1000.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Extend "fdb flush" command to match fdb entries with a specific nexthop ID.
Example:
$ bridge fdb flush dev vx10 nhid 2
This will flush all fdb entries pointing to vx10 with nexthop ID 2.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Extend "fdb flush" command to match fdb entries with a specific source VNI.
Example:
$ bridge fdb flush dev vx10 src_vni 1000
This will flush all fdb entries pointing to vx10 with source VNI 1000.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Currently, the flush command supports the keyword 'brport'. To handle
this argument the variables 'port_ifidx' and 'port' are used.
A following patch will add support for 'port' keyword in flush command,
rename the existing variables to include 'brport' prefix, so then it
will be clear that they are used to parse 'brport' argument.
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Commit 6e1ca489c5 ("bridge: fdb: add new flush command") added support
for "bridge fdb flush" command. This commit did not handle unsupported
keywords, they are just ignored.
Add an error print to notify the user when a keyword which is not supported
is used. The kernel will be extended to support flush with VXLAN device,
so new attributes will be supported (e.g., vni, port). When iproute-2 does
not warn for unsupported keyword, user might think that the flush command
works, although the iproute-2 version is too old and it does not send VXLAN
attributes to the kernel.
Fixes: 6e1ca489c5 ("bridge: fdb: add new flush command")
Signed-off-by: Amit Cohen <amcohen@nvidia.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Building with clang and warnings enabled finds several
places where variable was set but not used.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
With Makefile providing -DCONF_COLOR, we can use its value as the
default color output.
This effectively allow users and packagers to define a default for the
color output feature without using shell aliases, and with minimum code
impact.
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
Extend the bridge and ip utilities to set and show the backup nexthop ID
bridge port attribute. A value of 0 (default) disables the feature, in
which case the attribute is not printed since it is not emitted by the
kernel.
Example:
# bridge -d link show dev swp1 | grep -o "backup_nhid [0-9]*"
# bridge -d -j -p link show dev swp1 | jq '.[]["backup_nhid"]'
null
# bridge link set dev swp1 backup_nhid 10
# bridge -d link show dev swp1 | grep -o "backup_nhid [0-9]*"
backup_nhid 10
# bridge -d -j -p link show dev swp1 | jq '.[]["backup_nhid"]'
10
# bridge link set dev swp1 backup_nhid 0
# bridge -d link show dev swp1 | grep -o "backup_nhid [0-9]*"
# bridge -d -j -p link show dev swp1 | jq '.[]["backup_nhid"]'
null
# ip -d link show dev swp1 | grep -o "backup_nhid [0-9]*"
# ip -d -j -p lin show dev swp1 | jq '.[]["linkinfo"]["info_slave_data"]["backup_nhid"]'
null
# ip link set dev swp1 type bridge_slave backup_nhid 10
# ip -d link show dev swp1 | grep -o "backup_nhid [0-9]*"
backup_nhid 10
# ip -d -j -p lin show dev swp1 | jq '.[]["linkinfo"]["info_slave_data"]["backup_nhid"]'
10
# ip link set dev swp1 type bridge_slave backup_nhid 0
# ip -d link show dev swp1 | grep -o "backup_nhid [0-9]*"
# ip -d -j -p lin show dev swp1 | jq '.[]["linkinfo"]["info_slave_data"]["backup_nhid"]'
null
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Petr Machata <petrm@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
When using 'brige link show' we can either dump all links enslaved to any bridge
(called without arg ) or display a single link (called with dev arg).
However there is no way to dummp all links of a single bridge.
To do so, this adds new optional 'master XXX' arg to 'bridge link show' command.
usage: bridge link show master br0
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
While building iproute2 6.4.0 with musl using Yocto Project, errors such
as the following were encountered:
| mdb.c: In function 'mdb_parse_vni':
| mdb.c:666:47: error: 'ULONG_MAX' undeclared (first use in this function)
| 666 | if ((endptr && *endptr) || vni_num == ULONG_MAX)
| | ^~~~~~~~~
| mdb.c:666:47: note: 'ULONG_MAX' is defined in header '<limits.h>'; did you forget to '#include <limits.h>'?
Include limits.h in bridge/mdb.c to fix this issue. This change is based
on one in Alpine Linux, but the author there had no plans to submit:
https://git.alpinelinux.org/aports/commit/main/iproute2/include.patch?id=bd46efb8a8da54948639cebcfa5b37bd608f1069
Signed-off-by: Trevor Gamblin <tgamblin@baylibre.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Replace multiple whitespaces with tab where appropriate.
While at it, fix tc flower help message and remove some double
whitespaces.
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: David Ahern <dsahern@kernel.org>
After the (d == NULL || vni == NULL) check, vni cannot be NULL anymore.
This remove two useless conditional checks on vni value:
- the first check cannot be true, so remove the whole conditional block
- the second check is always true, so remove the check
Signed-off-by: Andrea Claudi <aclaudi@redhat.com>
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Add support for the per-port neigh_vlan_suppress option. Example:
# bridge link set dev swp1 neigh_vlan_suppress on
# bridge -d -j -p link show dev swp1
[ {
"ifindex": 62,
"ifname": "swp1",
"flags": [ "BROADCAST","NOARP","UP","LOWER_UP" ],
"mtu": 1500,
"master": "br0",
"state": "forwarding",
"priority": 32,
"cost": 100,
"hairpin": false,
"guard": false,
"root_block": false,
"fastleave": false,
"learning": true,
"flood": true,
"mcast_flood": true,
"bcast_flood": true,
"mcast_router": 1,
"mcast_to_unicast": false,
"neigh_suppress": false,
"neigh_vlan_suppress": true,
"vlan_tunnel": false,
"isolated": false,
"locked": false,
"mab": false,
"mcast_n_groups": 0,
"mcast_max_groups": 0
} ]
# bridge -d link show dev swp1
62: swp1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100
hairpin off guard off root_block off fastleave off learning on flood on mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off neigh_suppress off neigh_vlan_suppress on vlan_tunnel off isolated off locked off mab off mcast_n_groups 0 mcast_max_groups 0
# bridge link set dev swp1 neigh_vlan_suppress off
# bridge -d -j -p link show dev swp1
[ {
"ifindex": 62,
"ifname": "swp1",
"flags": [ "BROADCAST","NOARP","UP","LOWER_UP" ],
"mtu": 1500,
"master": "br0",
"state": "forwarding",
"priority": 32,
"cost": 100,
"hairpin": false,
"guard": false,
"root_block": false,
"fastleave": false,
"learning": true,
"flood": true,
"mcast_flood": true,
"bcast_flood": true,
"mcast_router": 1,
"mcast_to_unicast": false,
"neigh_suppress": false,
"neigh_vlan_suppress": false,
"vlan_tunnel": false,
"isolated": false,
"locked": false,
"mab": false,
"mcast_n_groups": 0,
"mcast_max_groups": 0
} ]
# bridge -d link show dev swp1
62: swp1: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100
hairpin off guard off root_block off fastleave off learning on flood on mcast_flood on bcast_flood on mcast_router 1 mcast_to_unicast off neigh_suppress off neigh_vlan_suppress off vlan_tunnel off isolated off locked off mab off mcast_n_groups 0 mcast_max_groups 0
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
Add support for the per-VLAN neigh_suppress option. Example:
# bridge vlan set vid 10 dev swp1 neigh_suppress on
# bridge -d -j -p vlan show dev swp1 vid 10
[ {
"ifname": "swp1",
"vlans": [ {
"vlan": 10,
"state": "forwarding",
"mcast_router": 1,
"neigh_suppress": true
} ]
} ]
# bridge -d vlan show dev swp1 vid 10
port vlan-id
swp1 10
state forwarding mcast_router 1 neigh_suppress on
# bridge vlan set vid 10 dev swp1 neigh_suppress off
# bridge -d -j -p vlan show dev swp1 vid 10
[ {
"ifname": "swp1",
"vlans": [ {
"vlan": 10,
"state": "forwarding",
"mcast_router": 1,
"neigh_suppress": false
} ]
} ]
# bridge -d vlan show dev swp1 vid 10
port vlan-id
swp1 10
state forwarding mcast_router 1 neigh_suppress off
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Signed-off-by: David Ahern <dsahern@kernel.org>
In a similar fashion to VXLAN FDB entries, allow user space to program
and view the outgoing interface of VXLAN MDB entries. Specifically, add
support for the 'MDBE_ATTR_IFINDEX' and 'MDBA_MDB_EATTR_IFINDEX'
attributes in request and response messages, respectively.
The outgoing interface will be forced during the underlay route lookup
and is required when the underlay destination IP is multicast, as the
multicast routing tables are not consulted.
Example:
# bridge mdb add dev vxlan0 port vxlan0 grp 239.1.1.1 permanent dst 198.51.100.1 via dummy10
$ bridge -d -s mdb show
dev vxlan0 port vxlan0 grp 239.1.1.1 permanent filter_mode exclude proto static dst 198.51.100.1 via dummy10 0.00
$ bridge -d -s -j -p mdb show
[ {
"mdb": [ {
"index": 10,
"dev": "vxlan0",
"port": "vxlan0",
"grp": "239.1.1.1",
"state": "permanent",
"filter_mode": "exclude",
"protocol": "static",
"flags": [ ],
"dst": "198.51.100.1",
"via": "dummy10",
"timer": " 0.00"
} ],
"router": {}
} ]
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
In a similar fashion to VXLAN FDB entries, allow user space to program
and view the source VNI of VXLAN MDB entries. Specifically, add support
for the 'MDBE_ATTR_SRC_VNI' and 'MDBA_MDB_EATTR_SRC_VNI' attributes in
request and response messages, respectively.
The source VNI is only relevant when the VXLAN device is in external
mode, where multiple VNIs can be multiplexed over a single VXLAN device.
Example:
# bridge mdb add dev vxlan0 port vxlan0 grp 239.1.1.1 permanent dst 198.51.100.1 src_vni 2222
$ bridge -d -s mdb show
dev vxlan0 port vxlan0 grp 239.1.1.1 permanent filter_mode exclude proto static dst 198.51.100.1 src_vni 2222 0.00
$ bridge -d -s -j -p mdb show
[ {
"mdb": [ {
"index": 16,
"dev": "vxlan0",
"port": "vxlan0",
"grp": "239.1.1.1",
"state": "permanent",
"filter_mode": "exclude",
"protocol": "static",
"flags": [ ],
"dst": "198.51.100.1",
"src_vni": 2222,
"timer": " 0.00"
} ],
"router": {}
} ]
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
In a similar fashion to VXLAN FDB entries, allow user space to program
and view the destination VNI of VXLAN MDB entries. Specifically, add
support for the 'MDBE_ATTR_VNI' and 'MDBA_MDB_EATTR_VNI' attributes in
request and response messages, respectively.
This is useful when ingress replication (IR) is used and the destination
VXLAN tunnel endpoint (VTEP) is not a member of the source broadcast
domain (BD). In this case, the ingress VTEP should transmit the packet
using the VNI of the Supplementary Broadcast Domain (SBD) in which all
the VTEPs are member of [1].
Example:
# bridge mdb add dev vxlan0 port vxlan0 grp 239.1.1.1 permanent dst 198.51.100.1 vni 1111
$ bridge -d -s mdb show
dev vxlan0 port vxlan0 grp 239.1.1.1 permanent filter_mode exclude proto static dst 198.51.100.1 vni 1111 0.00
$ bridge -d -s -j -p mdb show
[ {
"mdb": [ {
"index": 15,
"dev": "vxlan0",
"port": "vxlan0",
"grp": "239.1.1.1",
"state": "permanent",
"filter_mode": "exclude",
"protocol": "static",
"flags": [ ],
"dst": "198.51.100.1",
"vni": 1111,
"timer": " 0.00"
} ],
"router": {}
} ]
[1] https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast#section-3.2.2
Signed-off-by: Ido Schimmel <idosch@nvidia.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
