similar to: [Bridge] [PATCH][RFC] bridge-utils: add basic VEPA support

This patch adds a 'hairpin' (also called 'reflective relay') mode port configuration to the Linux Ethernet bridge utilities. 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 utilities. 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 utilities. 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, I noticed that brctl (or more accurately, libbridge) is using the wrong path when doing various lookups in sysfs: e.g. /sys/class/net/brXXX/stp_state when it should use /sys/class/net/brXXX/bridge/stp_state. This doesn't cause any problems on most systems as it falls back to the ioctl when the sysfs attempt fails; however the ioctl method is apparently deprecated. I believe the

Under newer kernels the bridge configuration parameters are located under /sys/class/net/$bridgename/bridge/$param, while the current bridge-utils code is trying to access them under /sys/class/net/$bridgename/$param. This patch fixes this issue in the bridge-utils code and so allows setting of bridge configuration parameters using sysfs under newer kernel versions. Signed-off-by: Anna Fischer

Under newer kernels the bridge configuration parameters are located under /sys/class/net/$bridgename/bridge/$param, while the current bridge-utils code is trying to access them under /sys/class/net/$bridgename/$param. This patch fixes this issue in the bridge-utils code and so allows setting of bridge configuration parameters using sysfs under newer kernel versions. Signed-off-by: Anna Fischer

Under newer kernels the bridge configuration parameters are located under /sys/class/net/$bridgename/bridge/$param, while the current bridge-utils code is trying to access them under /sys/class/net/$bridgename/$param. This patch fixes this issue in the bridge-utils code and so allows setting of bridge configuration parameters using sysfs under newer kernel versions. Signed-off-by: Anna Fischer

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, I think I detected some bugs in libbridge 1.2. Probably none detected them so far because of the fallback to ioctl() whenever anything fails. On my system (user 32 bits, kernel 64 bits) the fallback doesn't work. It would be nice BTW to have a compile time option that leaves the ioctl fallback out... Here's what I've found (first patch is a compilation patch I posted last

I have been playing around with the STP settings of brctl and saw something strange. I was setting the hello time, so I executed the following: # brctl sethello br0 30 Then I had a look at the value that was set: # cat /sys/class/net/br0/bridge/hello_time 2999 Much bigger than expected. I started looking at the source. In the libbridge/libbridge_devif.c file of brctl, we have the following

Linux 3.8 has a header, include/uapi/linux/if_bridge.h that uses a struct in6_addr but doesn't define it. The trivial seeming fix of including the header that does define it causes more problems. The problem was discussed on mailing lists in January 2013. The final suggestion I found was here: http://www.redhat.com/archives/libvir-list/2013-January/msg01253.html This is intended to

Hi, I use the libbridge and an other lib (libnl) in a same project. I include the headers files of the two lib (libnl first and libbridgge after) and I've a conflict with the inclusion of linux/if.h (in libnl headers) and net/if.h (in libbridge.h), I've this error : /usr/include/net/if.h:45: error: parse error before numeric constant /usr/include/net/if.h:111: error: redefinition of

Hello, I''ve applied ``bridge-utils-0.9.5-ipmode-1.diff'''' to be able to use my shaper as bridge and don''t lose the netfilter capabilities, the patch applies with no error messages, which makes me supose everything is working fine. But when i try to recompile the bridge-utils utilities i get the message transcript below:

The current diagnostic is terrible. This one tells the user how to diagnose and fix the problem. --- src/launch-libvirt.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/src/launch-libvirt.c b/src/launch-libvirt.c index 1c0bfac..d4c4c47 100644 --- a/src/launch-libvirt.c +++ b/src/launch-libvirt.c @@ -181,6 +181,7 @@ static int is_blk (const

I've noticed for a while that # brctl showstp output is showing 0 for port_no and port_id It seems that somewhere in 2.6 sysfs land the following items got printed in hexadecimal, and brctl code was parsing for decimal only doug:/sys/class/net/eth0/brport# cat port_id 0x8001 doug:/sys/class/net/eth0/brport# cat port_no 0x1 The following patch to bridge-utils (git and 1.2 release) lets

Good day Folks! Working on a bridging firewall/gateway and attempting to solve the age-old mystery of whether I can get NAT to work across a gateway that has 2 NICs and requires a bridge... Upside is, I have the gateway working, bridging works (as does OpenVPN using that bridge). But NAT does not in Fedora Core 4... >From dmesg: Linux version 2.6.11-1.1369_FC4 So I went to the website and

Hi! Jens Seidel reported a bug to Debian about a wrong message on brctl, you can see it at http://bugs.debian.org/383938, it is kind of the continuation of the ENODEV bug #348617 that was already patched by Stephen on the git. I have applied the same solution that Stephen applied for the first one, follows the patch against git plus a minor exclamation mark modification I did so that all ENODEV

We've been carrying this exact patch in RHEL 7 for several years. It reverts the change made in 2014 where we switched to using the virbr0 bridge for libguestfs networking instead of SLIRP. We thought SLIRP was going to become unsupported in qemu, but recently there have been more encouraging signs since it looks like SLIRP will be spun off as a separate project, running as a modular process