similar to: [Bridge] STP Explanation

I saw some big mistakes, here's the correct version : -------------------------------------------------------------------- void br_send_config_bpdu(struct net_bridge_port *p, struct bpdu *bpdu) { unsigned char buf[42]; buf[0] = bpdu->bpdu_header.protocol[0]; //0x00 buf[1] = bpdu->bpdu_header.protocol[1]; //0x00 buf[2] = bpdu->bpdu_header.version; //0x02 buf[3] =

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 is the 2.4 version which incorporates the observations from Kishore about 2.6. The existing 2.4 code set the age properly, but did not increment correctly for HZ=1000 and could send a stale (expired) configuration. 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 15:30:32 -07:00 +++

Fixes message_age field update in config BPDUs. Also checks whether the BPDU message age has exceeded bridge max age before transmitting config BPDUs. Signed-off-by: Kishore A K <KishoreAK@myw.ltindia.com> Index: linux-2.6.7/net/bridge/br_stp.c ============================================================= --- linux-2.6.7/net/bridge/br_stp.c.orig 2004-06-17 20:17:27.000000000 +0530 +++

Hello, i have ported the BCP (Bride Control Protocol) patch for pppd 2.4.1 mentioned in http://lists.osdl.org/pipermail/bridge/2004-September/000619.html to pppd 2.4.2. The kernel patch still works without problems with kernel 2.4.30. Perhaps someone else could use this patch ... Here again some documentation i have found about the BCP patch somewere else: When pppd negotiates BCP, it tells

This changes the message_age_timer calculation to use the BPDU's max age as opposed to the local bridge's max age. This is in accordance with section 8.6.2.3.2 Step 2 of the 802.1D-1998 sprecification. With the current implementation, when running with very large bridge diameters, convergance will not always occur even if a root bridge is configured to have a longer max age. Tested

Hi, I tried to send the BDPU at less than 1 second in a STP implementation. When I look at STP info with brctl in tells me that the bpdu are send under the second but in fact it's "only" every second. Is it because we can't send BPDU less than 1 second or something else ? Thanks for your response HENRY Simon ------------------------------------------ Faites un voeu et

I have noticed a change in the linux bridge implementation between 2.1.15 and 2.1.17. Specifically, I do not think BPDU's (generated from another bridge) are passed across the bridge when STP is disabled. I think this relates to the LLC handling of BPDU's directly invoking br_bpdu_rcv. In 2.6.15, the br_handle_frame function would pass a BPDU to the br_handle_frame_finish function

Hi all, I work on a SOC based on Micrel/Kendin KS8695 based on ARM9. ( http://micrel.com/page.do?page=product-info/sys_on_chip.jsp) This component has 2 network interfaces. One is connected to a 5 ports switch. eth0 eth1 => switch port1,2,3,4 I want to make a bridge with these 5 ports but my problem is that the network driver only install 2 interfaces. The KS8695 network switch can be

Hi. I'm not subscribed, so please Cc: me. This trivial patch fixes a typo that irritates me every time I boot.. --- linux-2.5.orig/net/bridge/br_stp.c 2004-07-19 14:43:44.000000000 +0300 +++ linux-2.5/net/bridge/br_stp.c 2004-07-19 14:53:15.000000000 +0300 @@ -299,7 +299,7 @@ int isroot = br_is_root_bridge(br); pr_info("%s: topology change detected, %s\n",

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

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 &&

Andrew and Dennis are spot on. Their conclusions about your server being connected to an access port and not a trunk port would be my conclusion as well. On Sat, Jan 24, 2015 at 9:11 AM, Dennis Jacobfeuerborn < dennisml at conversis.de> wrote: > Hi Boris, > what I'd like to know is the actual VLAN configuration of the switch > port (link-type and tagged and untagged VLANs).

When we create an L2 loop on a bridge in netns, we will see packets storm even if STP is enabled. # unshare -n # ip link add br0 type bridge # ip link add veth0 type veth peer name veth1 # ip link set veth0 master br0 up # ip link set veth1 master br0 up # ip link set br0 type bridge stp_state 1 # ip link set br0 up # sleep 30 # ip -s link show br0 2: br0:

Hello, I've got a very strange problem. Lately I've been setting up my linux servers for network (layer2) redundancy with a bridge interface containing two ethernet interfaces connecting to two switches. So far I didn't have any problems with it, but now a very strange thing happens with a new server I'm installing. The server is an ibm x346 having two onboard BCM5721 cards, the

http://developer.osdl.org/shemminger/patches/2.6.12-rc4-bridge/ Here are some patches for requested features, given basic testing but need more testing before they are publicly ready: bridge-csum - turn on bridge pseudo-device flags so that smart hardware does less work. Helps Xen bridge-flush - add /sys/class/net/brX/bridge/flush write only hook to flush

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.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have a machine running 2.6.18-rc3 with a bridge config that looks like this: cr1:~# brctl show bridge name bridge id STP enabled interfaces vlan100 36b0.0007e90f40c1 yes eth0.100 eth2.100 vlan101 5dc0.0007e90f40c1 yes

Hi, I want to connect two pc`s on a redundant way with each other. On those pc`s a 64 bit ubuntu 11.10 is running with kernel version 3.0.0-16-generic. Setup1: ---------- PC1: PC2: br0 br1 | | -- eth0.1000 ---------------------------------------------------eth0.1000 | | __eth1.1001

OK... but why does it need to be a trunk port? Boris. On Sat, Jan 24, 2015 at 6:53 PM, SilverTip257 <silvertip257 at gmail.com> wrote: > Andrew and Dennis are spot on. > Their conclusions about your server being connected to an access port and > not a trunk port would be my conclusion as well. > > On Sat, Jan 24, 2015 at 9:11 AM, Dennis Jacobfeuerborn < > dennisml at