similar to: [Bridge] Bridge port states

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

Avoid poisoning of the bridge forwarding table by frames that have been dropped by filtering. This prevents spoofed source addresses on hostile side of bridge from causing packet leakage, a small but possible security risk. Signed-off-by: Stephen Hemminger <shemminger@osdl.org> Index: bridge/net/bridge/br_input.c =================================================================== ---

I have two multi-port bridges connected together with a lot of cables. Current setup is as follows: --------eth0------- | | [Bridge A] <-eth1-> [Bridge B] | | --------eth5------- Bridge A is root-bridge, and eth0 is set to lowest path-cost. Consequently on Bridge B interfaces eth1 and eth5 are in blocking state. However, when looking

Hi there, I was asking this question already a few days go, but I'm not sure whether anyone noticed due to the mailserver outtage. So I'm just re-posting it, sorry, but it's an important issue for me, I would be glad to hear some insight on this. The question is regarding throughput performance using linux 2.4.5.1. My setup is very simple : I have two laptops with a wireless card.

This is a revised version of Kishore's patch to set message age appropriately in STP configuration packets. Signed-off-by: Kishore A K <KishoreAK@myw.ltindia.com> Signed-off-by: Stephen Hemminger <shemminger@osdl.org> diff -Nru a/net/bridge/br_stp.c b/net/bridge/br_stp.c --- a/net/bridge/br_stp.c 2004-06-29 14:45:50 -07:00 +++ b/net/bridge/br_stp.c 2004-06-29 14:45:50 -07:00 @@

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

This patch adds basic Virtual Ethernet Port Aggregator (VEPA) capabilities to the Linux kernel Ethernet bridging code. A Virtual Ethernet Port Aggregator (VEPA) is a capability within a physical end station that collaborates with an adjacent, external bridge to provide distributed bridging support between multiple virtual end stations and external networks. The VEPA collaborates by forwarding all

Hi, We have a simple bridge setup but the ping (and other network traffic) does not work reliably. After tracing the code, it looks like a software bug. Since bridge software is been running by thousands of people. I guess I am wrong. Anyway, here is the problem. There are 2 boxes and each one has 2 interfaces, 1 ethernet and 1 wifi. STP is enabled for the bridge to avoid the loop. So the box 1

Hi all, I would like to draw one picture which would show two different types of boxplots using the same axes (kind of on top of each other). However, I would like to plot each boxplot using a different color or different shading inside the box, so they could be better distinquished from each other... Could you help me? Here is an example of the plot I have so far. I was only able to change the

From: xu xin <xu.xin16 at zte.com.cn> This creates six drop reasons as follows, which will help users know the specific reason why bridge drops the packets when forwarding. 1) SKB_DROP_REASON_BRIDGE_FWD_NO_BACKUP_PORT: failed to get a backup port link when the destination port is down. 2) SKB_DROP_REASON_BRIDGE_FWD_SAME_PORT: destination port is the same with originating port when

On Thu, 6 Apr 2023 19:30:34 +0800 (CST) yang.yang29 at zte.com.cn wrote: > From: xu xin <xu.xin16 at zte.com.cn> > > This creates six drop reasons as follows, which will help users know the > specific reason why bridge drops the packets when forwarding. > > 1) SKB_DROP_REASON_BRIDGE_FWD_NO_BACKUP_PORT: failed to get a backup > port link when the destination port is

Hi, please Cc: all replies, I'm not subscribed I seem to have troubles with my Linux bridge (2.6.8-rc2), which is apparently not bridging UDP fragments (NFS) when passing packets through iptables, but I do not see in the iptables stats where the packets are dropped. Policies for INPUT, FORWARD, OUTPUT are all "ACCEPT", and I grepped for all REJECT and DROP rules in iptables -nvL,

This patch adds a 'hairpin' (also called 'reflective relay') mode port configuration to the Linux Ethernet bridge kernel module. A bridge supporting hairpin forwarding mode can send frames back out through the port the frame was received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

This patch adds a 'hairpin' (also called 'reflective relay') mode port configuration to the Linux Ethernet bridge kernel module. A bridge supporting hairpin forwarding mode can send frames back out through the port the frame was received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

This patch adds a 'hairpin' (also called 'reflective relay') mode port configuration to the Linux Ethernet bridge kernel module. A bridge supporting hairpin forwarding mode can send frames back out through the port the frame was received on. Hairpin mode is required to support basic VEPA (Virtual Ethernet Port Aggregator) capabilities. You can find additional information on VEPA

Hi, Does anyone know what version of XEN works fine with CentOS 6? I installed XEN on a CentOS 6 server, as per these instructions: http://www.crc.id.au/xen-on-rhel6-scientific-linux-6-centos-6-howto/ And the server now gives this error on reboot: PANIC: early exception 0e rip 10:0 error 10 cr2 0 These are the packages that was installed: Installed: kernel-xen.x86_64 0:2.6.32.45-1

Thanks, Gabriel. On Mon, 2020-09-07 at 14:38 -0700, Gabriel Becker wrote: > I cannot speak to initial intent, perhaps others can. I can say that > there is at least one place where the difference between R_NilValue > and NULL is very important as of right now. The current design of the > ALTREP framework contract expects ALTREP methods that return a SEXP > to return C NULL when

This hook is protected with the RCU, so simple if (br_should_route_hook) br_should_route_hook(...) is not enough on some architectures. Use the rcu_dereference/rcu_assign_pointer in this case. Signed-off-by: Pavel Emelyanov <xemul@openvz.org> --- diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c index 3cedd4e..b42b192 100644 --- a/net/bridge/br_input.c +++

On Tue, 28 Oct 2003 12:24:16 +0100 Jos? J. Gonz?lez Alonso <jjgonzalez@igalia.com> wrote: > Hi! > > I am very interested in your project. Concretely, I am interested in the > possibility of extending your implementation so that it fulfills the > specifications of 802.1G. I read this specifications and they seem > "simple" extensions of 802.1D standard. >