Revision tags: v3.18-rc1, v3.17 |
|
#
93fdd47e |
| 04-Oct-2014 |
Herbert Xu <herbert@gondor.apana.org.au> |
bridge: Save frag_max_size between PRE_ROUTING and POST_ROUTING
As we may defragment the packet in IPv4 PRE_ROUTING and refragment it after POST_ROUTING we should save the value of frag_max_size.
T
bridge: Save frag_max_size between PRE_ROUTING and POST_ROUTING
As we may defragment the packet in IPv4 PRE_ROUTING and refragment it after POST_ROUTING we should save the value of frag_max_size.
This is still very wrong as the bridge is supposed to leave the packets intact, meaning that the right thing to do is to use the original frag_list for fragmentation.
Unfortunately we don't currently guarantee that the frag_list is left untouched throughout netfilter so until this changes this is the best we can do.
There is also a spot in FORWARD where it appears that we can forward a packet without going through fragmentation, mark it so that we can fix it later.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
5be5a2df |
| 03-Oct-2014 |
Vlad Yasevich <vyasevich@gmail.com> |
bridge: Add filtering support for default_pvid
Currently when vlan filtering is turned on on the bridge, the bridge will drop all traffic untill the user configures the filter. This isn't very nice
bridge: Add filtering support for default_pvid
Currently when vlan filtering is turned on on the bridge, the bridge will drop all traffic untill the user configures the filter. This isn't very nice for ports that don't care about vlans and just want untagged traffic.
A concept of a default_pvid was recently introduced. This patch adds filtering support for default_pvid. Now, ports that don't care about vlans and don't define there own filter will belong to the VLAN of the default_pvid and continue to receive untagged traffic.
This filtering can be disabled by setting default_pvid to 0.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
3df6bf45 |
| 03-Oct-2014 |
Vlad Yasevich <vyasevich@gmail.com> |
bridge: Simplify pvid checks.
Currently, if the pvid is not set, we return an illegal vlan value even though the pvid value is set to 0. Since pvid of 0 is currently invalid, just return 0 instead.
bridge: Simplify pvid checks.
Currently, if the pvid is not set, we return an illegal vlan value even though the pvid value is set to 0. Since pvid of 0 is currently invalid, just return 0 instead. This makes the current and future checks simpler.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
96a20d9d |
| 03-Oct-2014 |
Vlad Yasevich <vyasevich@gmail.com> |
bridge: Add a default_pvid sysfs attribute
This patch allows the user to set and retrieve default_pvid value. A new value can only be stored when vlan filtering is disabled.
Signed-off-by: Vladisl
bridge: Add a default_pvid sysfs attribute
This patch allows the user to set and retrieve default_pvid value. A new value can only be stored when vlan filtering is disabled.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
775dd692 |
| 30-Sep-2014 |
Florian Fainelli <f.fainelli@gmail.com> |
net: bridge: add a br_set_state helper function
In preparation for being able to propagate port states to e.g: notifiers or other kernel parts, do not manipulate the port state directly, but instead
net: bridge: add a br_set_state helper function
In preparation for being able to propagate port states to e.g: notifiers or other kernel parts, do not manipulate the port state directly, but instead use a helper function which will allow us to do a bit more than just setting the state.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.17-rc7, v3.17-rc6 |
|
#
34666d46 |
| 18-Sep-2014 |
Pablo Neira Ayuso <pablo@netfilter.org> |
netfilter: bridge: move br_netfilter out of the core
Jesper reported that br_netfilter always registers the hooks since this is part of the bridge core. This harms performance for people that don't
netfilter: bridge: move br_netfilter out of the core
Jesper reported that br_netfilter always registers the hooks since this is part of the bridge core. This harms performance for people that don't need this.
This patch modularizes br_netfilter so it can be rmmod'ed, thus, the hooks can be unregistered. I think the bridge netfilter should have been a separated module since the beginning, Patrick agreed on that.
Note that this is breaking compatibility for users that expect that bridge netfilter is going to be available after explicitly 'modprobe bridge' or via automatic load through brctl.
However, the damage can be easily undone by modprobing br_netfilter. The bridge core also spots a message to provide a clue to people that didn't notice that this has been deprecated.
On top of that, the plan is that nftables will not rely on this software layer, but integrate the connection tracking into the bridge layer to enable stateful filtering and NAT, which is was bridge netfilter users seem to require.
This patch still keeps the fake_dst_ops in the bridge core, since this is required by when the bridge port is initialized. So we can safely modprobe/rmmod br_netfilter anytime.
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Acked-by: Florian Westphal <fw@strlen.de>
show more ...
|
Revision tags: v3.17-rc5 |
|
#
20adfa1a |
| 12-Sep-2014 |
Vlad Yasevich <vyasevich@gmail.com> |
bridge: Check if vlan filtering is enabled only once.
The bridge code checks if vlan filtering is enabled on both ingress and egress. When the state flip happens, it is possible for the bridge to
bridge: Check if vlan filtering is enabled only once.
The bridge code checks if vlan filtering is enabled on both ingress and egress. When the state flip happens, it is possible for the bridge to currently be forwarding packets and forwarding behavior becomes non-deterministic. Bridge may drop packets on some interfaces, but not others.
This patch solves this by caching the filtered state of the packet into skb_cb on ingress. The skb_cb is guaranteed to not be over-written between the time packet entres bridge forwarding path and the time it leaves it. On egress, we can then check the cached state to see if we need to apply filtering information.
Signed-off-by: Vladislav Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5 |
|
#
5d5eacb3 |
| 10-Jul-2014 |
Jamal Hadi Salim <jhs@mojatatu.com> |
bridge: fdb dumping takes a filter device
Dumping a bridge fdb dumps every fdb entry held. With this change we are going to filter on selected bridge port.
Signed-off-by: Jamal Hadi Salim <jhs@moja
bridge: fdb dumping takes a filter device
Dumping a bridge fdb dumps every fdb entry held. With this change we are going to filter on selected bridge port.
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1 |
|
#
204177f3 |
| 10-Jun-2014 |
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> |
bridge: Support 802.1ad vlan filtering
This enables us to change the vlan protocol for vlan filtering. We come to be able to filter frames on the basis of 802.1ad vlan tags through a bridge.
This a
bridge: Support 802.1ad vlan filtering
This enables us to change the vlan protocol for vlan filtering. We come to be able to filter frames on the basis of 802.1ad vlan tags through a bridge.
This also changes br->group_addr if it has not been set by user. This is needed for an 802.1ad bridge. (See IEEE 802.1Q-2011 8.13.5.)
Furthermore, this sets br->group_fwd_mask_required so that an 802.1ad bridge can forward the Nearest Customer Bridge group addresses except for br->group_addr, which should be passed to higher layer.
To change the vlan protocol, write a protocol in sysfs: # echo 0x88a8 > /sys/class/net/br0/bridge/vlan_protocol
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
f2808d22 |
| 10-Jun-2014 |
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> |
bridge: Prepare for forwarding another bridge group addresses
If a bridge is an 802.1ad bridge, it must forward another bridge group addresses (the Nearest Customer Bridge group addresses). (For det
bridge: Prepare for forwarding another bridge group addresses
If a bridge is an 802.1ad bridge, it must forward another bridge group addresses (the Nearest Customer Bridge group addresses). (For details, see IEEE 802.1Q-2011 8.6.3.)
As user might not want group_fwd_mask to be modified by enabling 802.1ad, introduce a new mask, group_fwd_mask_required, which indicates addresses the bridge wants to forward. This will be set by enabling 802.1ad.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
8580e211 |
| 10-Jun-2014 |
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> |
bridge: Prepare for 802.1ad vlan filtering support
This enables a bridge to have vlan protocol informantion and allows vlan tag manipulation (retrieve, insert and remove tags) according to the vlan
bridge: Prepare for 802.1ad vlan filtering support
This enables a bridge to have vlan protocol informantion and allows vlan tag manipulation (retrieve, insert and remove tags) according to the vlan protocol.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.15 |
|
#
2cd41431 |
| 07-Jun-2014 |
Linus Lüssing <linus.luessing@web.de> |
bridge: memorize and export selected IGMP/MLD querier port
Adding bridge support to the batman-adv multicast optimization requires batman-adv knowing about the existence of bridged-in IGMP/MLD queri
bridge: memorize and export selected IGMP/MLD querier port
Adding bridge support to the batman-adv multicast optimization requires batman-adv knowing about the existence of bridged-in IGMP/MLD queriers to be able to reliably serve any multicast listener behind this same bridge.
Signed-off-by: Linus Lüssing <linus.luessing@web.de> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
07f8ac4a |
| 07-Jun-2014 |
Linus Lüssing <linus.luessing@web.de> |
bridge: add export of multicast database adjacent to net_dev
With this new, exported function br_multicast_list_adjacent(net_dev) a list of IPv4/6 addresses is returned. This list contains all multi
bridge: add export of multicast database adjacent to net_dev
With this new, exported function br_multicast_list_adjacent(net_dev) a list of IPv4/6 addresses is returned. This list contains all multicast addresses sensed by the bridge multicast snooping feature on all bridge ports of the bridge interface of net_dev, excluding addresses from the specified net_device itself.
Adding bridge support to the batman-adv multicast optimization requires batman-adv knowing about the existence of bridged-in multicast listeners to be able to reliably serve them with multicast packets.
Signed-off-by: Linus Lüssing <linus.luessing@web.de> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
dc4eb53a |
| 07-Jun-2014 |
Linus Lüssing <linus.luessing@web.de> |
bridge: adhere to querier election mechanism specified by RFCs
MLDv1 (RFC2710 section 6), MLDv2 (RFC3810 section 7.6.2), IGMPv2 (RFC2236 section 3) and IGMPv3 (RFC3376 section 6.6.2) specify that th
bridge: adhere to querier election mechanism specified by RFCs
MLDv1 (RFC2710 section 6), MLDv2 (RFC3810 section 7.6.2), IGMPv2 (RFC2236 section 3) and IGMPv3 (RFC3376 section 6.6.2) specify that the querier with lowest source address shall become the selected querier.
So far the bridge stopped its querier as soon as it heard another querier regardless of its source address. This results in the "wrong" querier potentially becoming the active querier or a potential, unnecessary querying delay.
With this patch the bridge memorizes the source address of the currently selected querier and ignores queries from queriers with a higher source address than the currently selected one. This slight optimization is supposed to make it more RFC compliant (but is rather uncritical and therefore probably not necessary to be queued for stable kernels).
Signed-off-by: Linus Lüssing <linus.luessing@web.de> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
90010b36 |
| 07-Jun-2014 |
Linus Lüssing <linus.luessing@web.de> |
bridge: rename struct bridge_mcast_query/querier
The current naming of these two structs is very random, in that reversing their naming would not make any semantical difference.
This patch tries to
bridge: rename struct bridge_mcast_query/querier
The current naming of these two structs is very random, in that reversing their naming would not make any semantical difference.
This patch tries to make the naming less confusing by giving them a more specific, distinguishable naming.
This is also useful for the upcoming patches reintroducing the "struct bridge_mcast_querier" but for storing information about the selected querier (no matter if our own or a foreign querier).
Signed-off-by: Linus Lüssing <linus.luessing@web.de> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.15-rc8 |
|
#
e0d7968a |
| 26-May-2014 |
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> |
bridge: Prevent insertion of FDB entry with disallowed vlan
br_handle_local_finish() is allowing us to insert an FDB entry with disallowed vlan. For example, when port 1 and 2 are communicating in v
bridge: Prevent insertion of FDB entry with disallowed vlan
br_handle_local_finish() is allowing us to insert an FDB entry with disallowed vlan. For example, when port 1 and 2 are communicating in vlan 10, and even if vlan 10 is disallowed on port 3, port 3 can interfere with their communication by spoofed src mac address with vlan id 10.
Note: Even if it is judged that a frame should not be learned, it should not be dropped because it is destined for not forwarding layer but higher layer. See IEEE 802.1Q-2011 8.13.10.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Acked-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.15-rc7, v3.15-rc6 |
|
#
b1282726 |
| 20-May-2014 |
Cong Wang <xiyou.wangcong@gmail.com> |
bridge: make br_device_notifier static
Merge net/bridge/br_notify.c into net/bridge/br.c, since it has only br_device_event() and br.c is small.
Cc: Stephen Hemminger <stephen@networkplumber.org> C
bridge: make br_device_notifier static
Merge net/bridge/br_notify.c into net/bridge/br.c, since it has only br_device_event() and br.c is small.
Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: David S. Miller <davem@davemloft.net> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
d4f0e095 |
| 18-May-2014 |
Alexei Starovoitov <ast@plumgrid.com> |
net: bridge: fix build
fix build when BRIDGE_VLAN_FILTERING is not set
Fixes: 2796d0c648c94 ("bridge: Automatically manage port promiscuous mode")
Signed-off-by: Alexei Starovoitov <ast@plumgrid.c
net: bridge: fix build
fix build when BRIDGE_VLAN_FILTERING is not set
Fixes: 2796d0c648c94 ("bridge: Automatically manage port promiscuous mode")
Signed-off-by: Alexei Starovoitov <ast@plumgrid.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
2796d0c6 |
| 16-May-2014 |
Vlad Yasevich <vyasevic@redhat.com> |
bridge: Automatically manage port promiscuous mode.
There exist configurations where the administrator or another management entity has the foreknowledge of all the mac addresses of end systems that
bridge: Automatically manage port promiscuous mode.
There exist configurations where the administrator or another management entity has the foreknowledge of all the mac addresses of end systems that are being bridged together.
In these environments, the administrator can statically configure known addresses in the bridge FDB and disable flooding and learning on ports. This makes it possible to turn off promiscuous mode on the interfaces connected to the bridge.
Here is why disabling flooding and learning allows us to control promiscuity: Consider port X. All traffic coming into this port from outside the bridge (ingress) will be either forwarded through other ports of the bridge (egress) or dropped. Forwarding (egress) is defined by FDB entries and by flooding in the event that no FDB entry exists. In the event that flooding is disabled, only FDB entries define the egress. Once learning is disabled, only static FDB entries provided by a management entity define the egress. If we provide information from these static FDBs to the ingress port X, then we'll be able to accept all traffic that can be successfully forwarded and drop all the other traffic sooner without spending CPU cycles to process it. Another way to define the above is as following equations: ingress = egress + drop expanding egress ingress = static FDB + learned FDB + flooding + drop disabling flooding and learning we a left with ingress = static FDB + drop
By adding addresses from the static FDB entries to the MAC address filter of an ingress port X, we fully define what the bridge can process without dropping and can thus turn off promiscuous mode, thus dropping packets sooner.
There have been suggestions that we may want to allow learning and update the filters with learned addresses as well. This would require mac-level authentication similar to 802.1x to prevent attacks against the hw filters as they are limited resource.
Additionally, if the user places the bridge device in promiscuous mode, all ports are placed in promiscuous mode regardless of the changes to flooding and learning.
Since the above functionality depends on full static configuration, we have also require that vlan filtering be enabled to take advantage of this. The reason is that the bridge has to be able to receive and process VLAN-tagged frames and the there are only 2 ways to accomplish this right now: promiscuous mode or vlan filtering.
Suggested-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
f3a6ddf1 |
| 16-May-2014 |
Vlad Yasevich <vyasevic@redhat.com> |
bridge: Introduce BR_PROMISC flag
Introduce a BR_PROMISC per-port flag that will help us track if the current port is supposed to be in promiscuous mode or not. For now, always start in promiscuous
bridge: Introduce BR_PROMISC flag
Introduce a BR_PROMISC per-port flag that will help us track if the current port is supposed to be in promiscuous mode or not. For now, always start in promiscuous mode.
Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
8db24af7 |
| 16-May-2014 |
Vlad Yasevich <vyasevic@redhat.com> |
bridge: Add functionality to sync static fdb entries to hw
Add code that allows static fdb entires to be synced to the hw list for a specified port. This will be used later to program ports that ca
bridge: Add functionality to sync static fdb entries to hw
Add code that allows static fdb entires to be synced to the hw list for a specified port. This will be used later to program ports that can function in non-promiscuous mode.
Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
#
e028e4b8 |
| 16-May-2014 |
Vlad Yasevich <vyasevic@redhat.com> |
bridge: Keep track of ports capable of automatic discovery.
By default, ports on the bridge are capable of automatic discovery of nodes located behind the port. This is accomplished via flooding of
bridge: Keep track of ports capable of automatic discovery.
By default, ports on the bridge are capable of automatic discovery of nodes located behind the port. This is accomplished via flooding of unknown traffic (BR_FLOOD) and learning the mac addresses from these packets (BR_LEARNING). If the above functionality is disabled by turning off these flags, the port requires static configuration in the form of static FDB entries to function properly.
This patch adds functionality to keep track of all ports capable of automatic discovery. This will later be used to control promiscuity settings.
Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14 |
|
#
a8779ec1 |
| 27-Mar-2014 |
Eric W. Biederman <ebiederm@xmission.com> |
netpoll: Remove gfp parameter from __netpoll_setup
The gfp parameter was added in: commit 47be03a28cc6c80e3aa2b3e8ed6d960ff0c5c0af Author: Amerigo Wang <amwang@redhat.com> Date: Fri Aug 10 01:24:3
netpoll: Remove gfp parameter from __netpoll_setup
The gfp parameter was added in: commit 47be03a28cc6c80e3aa2b3e8ed6d960ff0c5c0af Author: Amerigo Wang <amwang@redhat.com> Date: Fri Aug 10 01:24:37 2012 +0000
netpoll: use GFP_ATOMIC in slave_enable_netpoll() and __netpoll_setup()
slave_enable_netpoll() and __netpoll_setup() may be called with read_lock() held, so should use GFP_ATOMIC to allocate memory. Eric suggested to pass gfp flags to __netpoll_setup().
Cc: Eric Dumazet <eric.dumazet@gmail.com> Cc: "David S. Miller" <davem@davemloft.net> Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Cong Wang <amwang@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
The reason for the gfp parameter was removed in: commit c4cdef9b7183159c23c7302aaf270d64c549f557 Author: dingtianhong <dingtianhong@huawei.com> Date: Tue Jul 23 15:25:27 2013 +0800
bonding: don't call slave_xxx_netpoll under spinlocks
The slave_xxx_netpoll will call synchronize_rcu_bh(), so the function may schedule and sleep, it should't be called under spinlocks.
bond_netpoll_setup() and bond_netpoll_cleanup() are always protected by rtnl lock, it is no need to take the read lock, as the slave list couldn't be changed outside rtnl lock.
Signed-off-by: Ding Tianhong <dingtianhong@huawei.com> Cc: Jay Vosburgh <fubar@us.ibm.com> Cc: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: David S. Miller <davem@davemloft.net>
Nothing else that calls __netpoll_setup or ndo_netpoll_setup requires a gfp paramter, so remove the gfp parameter from both of these functions making the code clearer.
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4 |
|
#
e5a727f6 |
| 23-Feb-2014 |
Joe Perches <joe@perches.com> |
bridge: Use ether_addr_copy and ETH_ALEN
Convert the more obvious uses of memcpy to ether_addr_copy.
There are still uses of memcpy that could be converted but these addresses are __aligned(2).
Co
bridge: Use ether_addr_copy and ETH_ALEN
Convert the more obvious uses of memcpy to ether_addr_copy.
There are still uses of memcpy that could be converted but these addresses are __aligned(2).
Convert a couple uses of 6 in gr_private.h to ETH_ALEN.
Signed-off-by: Joe Perches <joe@perches.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|
Revision tags: v3.14-rc3, v3.14-rc2 |
|
#
424bb9c9 |
| 07-Feb-2014 |
Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> |
bridge: Properly check if local fdb entry can be deleted when deleting vlan
Vlan codes unconditionally delete local fdb entries. We should consider the possibility that other ports have the same add
bridge: Properly check if local fdb entry can be deleted when deleting vlan
Vlan codes unconditionally delete local fdb entries. We should consider the possibility that other ports have the same address and vlan.
Example of problematic case: ip link set eth0 address 12:34:56:78:90:ab ip link set eth1 address aa:bb:cc:dd:ee:ff brctl addif br0 eth0 brctl addif br0 eth1 # br0 will have mac address 12:34:56:78:90:ab bridge vlan add dev eth0 vid 10 bridge vlan add dev eth1 vid 10 bridge vlan add dev br0 vid 10 self We will have fdb entry such that f->dst == eth0, f->vlan_id == 10 and f->addr == 12:34:56:78:90:ab at this time. Next, delete eth0 vlan 10. bridge vlan del dev eth0 vid 10 In this case, we still need the entry for br0, but it will be deleted.
Note that br0 needs the entry even though its mac address is not set manually. To delete the entry with proper condition checking, fdb_delete_local() is suitable to use.
Signed-off-by: Toshiaki Makita <makita.toshiaki@lab.ntt.co.jp> Acked-by: Vlad Yasevich <vyasevic@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net>
show more ...
|