Displaying 20 results from an estimated 200 matches similar to: "[Bridge] [BUG/PATCH/RFC] bridge: locally generated broadcast traffic may block sender"
2013 Apr 30
6
[Bridge] [PATCHv4 net-next 0/2] Add two new flags to bridge.
The following series adds 2 new flags to bridge. One flag allows
the user to control whether mac learning is performed on the interface
or not. By default mac learning is on.
The other flag allows the user to control whether unicast traffic
is flooded (send without an fdb) to a given unicast port. Default is
on.
Changes since v4:
- Implemented Stephen's suggestions.
Changes since v2:
-
2007 Apr 18
0
[Bridge] [PATCH] (4/4) bridge forwarding table RCU
Convert the bridge forwarding database over to using RCU.
This avoids a read_lock and atomic_inc/dec in the fast path
of output.
Signed-off-by: Stephen Hemminger <shemminger@osdl.org>
diff -Nru a/include/linux/list.h b/include/linux/list.h
--- a/include/linux/list.h 2004-07-28 15:30:04 -07:00
+++ b/include/linux/list.h 2004-07-28 15:30:04 -07:00
@@ -678,6 +678,24 @@
pos &&
2013 Aug 26
0
[PATCH] bridge: separate querier and query timer into IGMP/IPv4 and MLD/IPv6 ones
Currently we would still potentially suffer multicast packet loss if there
is just either an IGMP or an MLD querier: For the former case, we would
possibly drop IPv6 multicast packets, for the latter IPv4 ones. This is
because we are currently assuming that if either an IGMP or MLD querier
is present that the other one is present, too.
This patch makes the behaviour and fix added in
"bridge:
2013 May 22
1
[Bridge] [PATCH] bridge: Set vlan_features to allow offloads on vlans.
When vlan device is configured on top of the brige, it does
not support any offload capabilities because the bridge
device does not initiliaze vlan_fatures. Set vlan_fatures to
be equivalent to hw_fatures.
Signed-off-by: Vlad Yasevich <vyasevic at redhat.com>
---
net/bridge/br_device.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bridge/br_device.c
2023 May 15
5
[Bridge] [PATCH net-next 1/2] bridge: Add a limit on FDB entries
A malicious actor behind one bridge port may spam the kernel with packets
with a random source MAC address, each of which will create an FDB entry,
each of which is a dynamic allocation in the kernel.
There are roughly 2^48 different MAC addresses, further limited by the
rhashtable they are stored in to 2^31. Each entry is of the type struct
net_bridge_fdb_entry, which is currently 128 bytes big.
2013 Jan 09
16
[Bridge] [PATCH net-next V5 00/14] Add basic VLAN support to bridges
This series of patches provides an ability to add VLANs to the bridge
ports. This is similar to what can be found in most switches. The bridge
port may have any number of VLANs added to it including vlan 0 priority tagged
traffic. When vlans are added to the port, only traffic tagged with particular
vlan will forwarded over this port. Additionally, vlan ids are added to FDB
entries and become
2023 Jun 19
4
[Bridge] [PATCH net-next v2 0/3, iproute2-next 0/1] bridge: Add a limit on learned FDB entries
Introduce a limit on the amount of learned FDB entries on a bridge,
configured by netlink with a build time default on bridge creation in
the kernel config.
For backwards compatibility the kernel config default is disabling the
limit (0).
Without any limit a malicious actor may OOM a kernel by spamming packets
with changing MAC addresses on their bridge port, so allow the bridge
creator to limit
2013 Feb 13
14
[Bridge] [PATCH v10 net-next 00/12] VLAN filtering/VLAN aware bridge
Changes since v9:
* series re-ordering so make functionality more distinct. Basic vlan
filtering is patches 1-4. Support for PVID/untagged vlans is patches
5 and 6. VLAN support for FDB/MDB is patches 7-11. Patch 12 is
still additional egress policy.
* Slight simplification to code that extracts the VID from skb. Since we
now depend on the vlan module, at the time of input skb_tci is
2023 Jun 19
1
[Bridge] [PATCH net-next v2 3/3] net: bridge: Add a configurable default FDB learning limit
This adds a Kconfig option to configure a default FDB learning limit
system wide, so a distributor building a special purpose kernel can
limit all created bridges by default.
The limit is only a soft default setting and overridable per bridge
using netlink.
Signed-off-by: Johannes Nixdorf <jnixdorf-oss at avm.de>
---
Changes since v1:
- Added a default limit in Kconfig. (deemed
2007 Apr 18
4
[Bridge] MTU Question
I have a bridge that has gigabit interfaces. The machine in question has the
fun job of being a Bridge, Firewall and SMB server. Both of the Gigabit
interfaces are connected to workstations directly via Xover cable (well
MDI-X to be exact). My question is, if I enable jumbo frames on the gigabit
interfaces will that make any difference in overall transfer rate of the
bridge? I was thinking it
2023 May 15
3
[Bridge] [PATCH net-next 1/2] bridge: Add a limit on FDB entries
On 15/05/2023 11:50, Johannes Nixdorf wrote:
> A malicious actor behind one bridge port may spam the kernel with packets
> with a random source MAC address, each of which will create an FDB entry,
> each of which is a dynamic allocation in the kernel.
>
> There are roughly 2^48 different MAC addresses, further limited by the
> rhashtable they are stored in to 2^31. Each entry is
2012 Feb 15
2
[PATCH v2 0/2] Part 2: handle addr_assign_type for random addresses
The second part of my patch series to fix the handling of
addr_assign_type for random MAC addresses. This contains the
trival changes from random_ether_addr() to new
eth_hw_addr_random() and code to reset the state to
NET_ADDR_PERM as soon as the MAC get changed via
.ndo_set_mac_address where eth_mac_addr wasn't used.
Danny Kukawka (2):
net: replace random_ether_addr() with
2012 Feb 15
2
[PATCH v2 0/2] Part 2: handle addr_assign_type for random addresses
The second part of my patch series to fix the handling of
addr_assign_type for random MAC addresses. This contains the
trival changes from random_ether_addr() to new
eth_hw_addr_random() and code to reset the state to
NET_ADDR_PERM as soon as the MAC get changed via
.ndo_set_mac_address where eth_mac_addr wasn't used.
Danny Kukawka (2):
net: replace random_ether_addr() with
2012 Feb 15
2
[PATCH v2 0/2] Part 2: handle addr_assign_type for random addresses
The second part of my patch series to fix the handling of
addr_assign_type for random MAC addresses. This contains the
trival changes from random_ether_addr() to new
eth_hw_addr_random() and code to reset the state to
NET_ADDR_PERM as soon as the MAC get changed via
.ndo_set_mac_address where eth_mac_addr wasn't used.
Danny Kukawka (2):
net: replace random_ether_addr() with
2007 Apr 18
5
[Bridge] RFC: [PATCH] bridge vlan integration
Hi,
The attached patches enables the bridge to filter and forward packets
according to their IEEE 802.1q headers. The goals behind this change
include :
- Enable running STP on 802.1q tagged networks. STP packets
must be untagged. It isn't obvious how else to enable STP
with the current bridge and vlan code.
- Add native support for an untagged vlan. Currently an untagged
vlan can
2012 Feb 15
4
[RESEND][PATCH v2 0/2] Part 2: handle addr_assign_type for random addresses
The second part of my patch series to fix the handling of
addr_assign_type for random MAC addresses. This contains the
trival changes from random_ether_addr() to new
eth_hw_addr_random() and code to reset the state to
NET_ADDR_PERM as soon as the MAC get changed via
.ndo_set_mac_address where eth_mac_addr wasn't used.
Resend due to send with too long recipients list. Sorry!
Thanks to Joe
2012 Feb 15
4
[RESEND][PATCH v2 0/2] Part 2: handle addr_assign_type for random addresses
The second part of my patch series to fix the handling of
addr_assign_type for random MAC addresses. This contains the
trival changes from random_ether_addr() to new
eth_hw_addr_random() and code to reset the state to
NET_ADDR_PERM as soon as the MAC get changed via
.ndo_set_mac_address where eth_mac_addr wasn't used.
Resend due to send with too long recipients list. Sorry!
Thanks to Joe
2012 Feb 15
4
[RESEND][PATCH v2 0/2] Part 2: handle addr_assign_type for random addresses
The second part of my patch series to fix the handling of
addr_assign_type for random MAC addresses. This contains the
trival changes from random_ether_addr() to new
eth_hw_addr_random() and code to reset the state to
NET_ADDR_PERM as soon as the MAC get changed via
.ndo_set_mac_address where eth_mac_addr wasn't used.
Resend due to send with too long recipients list. Sorry!
Thanks to Joe
2023 May 09
5
[Bridge] [RFC PATCH net-next 0/5] Add layer 2 miss indication and filtering
tl;dr
=====
This patchset adds a single bit to the skb to indicate that a packet
encountered a layer 2 miss in the bridge and extends flower to match on
this metadata. This is required for non-DF (Designated Forwarder)
filtering in EVPN multi-homing which prevents decapsulated BUM packets
from being forwarded multiple times to the same multi-homed host.
Background
==========
In a typical EVPN
2023 May 18
5
[Bridge] [PATCH net-next 0/5] Add layer 2 miss indication and filtering
tl;dr
=====
This patchset adds a single bit to the skb to indicate that a packet
encountered a layer 2 miss in the bridge and extends flower to match on
this metadata. This is required for non-DF (Designated Forwarder)
filtering in EVPN multi-homing which prevents decapsulated BUM packets
from being forwarded multiple times to the same multi-homed host.
Background
==========
In a typical EVPN