[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Google
 
Web openvpn.net

OpenVPN's bridge algorithm, was: Re: [Openvpn-users] Seemingly inexplicable phenomena with several bridges in a full mesh


  • Subject: OpenVPN's bridge algorithm, was: Re: [Openvpn-users] Seemingly inexplicable phenomena with several bridges in a full mesh
  • From: James Yonan <jim@xxxxxxxxx>
  • Date: Fri, 9 Jul 2004 23:04:00 -0500

> On Sat, Jul 10, 2004 at 12:57:51AM +0200, KORN Andras wrote:
> 
> > I then moved the config of hello to fast-a; the only difference (other 
than
> > link speed) is that I had to remove eth0 from the bridge. This setup 
mostly
> > works; the only weird thing is that packets from fast-c to fast-s go over
> > fast-a, which has the lowest bridge priority.
> > 
> [...]
> 
> > It has been in topology_change_detected mode for more than an hour now.
> 
> OK, I believe I found a problem I can put my finger on.
> 
> As a reminder, the topology is the following:
> 
> fast-c tap2 -> fast-s tap0
> fast-a tap1 -> fast-s tap0
> fast-c tap3 -> fast-a tap0
> 
> This means that fast-s only runs an openvpn server but no client, and
> because that server is openvpn 2.0, it uses a single tap interface.
> 
> It would appear that ieee802.1d topology change notifications are not
> reaching the root bridge for some unknown reason.
> 
> On fast-s, tap0, I see this (sorry about the long lines):
> 
> 01:32:17.349162 fast-s-tap0 > 01:80:c2:00:00:00, 802.3, length 60: LLC, dsap 
STP (0x42), ssap STP (0x42), cmd 0x03, 802.1d tcn
> 01:32:19.257230 fast-a-tap1 > 01:80:c2:00:00:00, 802.3, length 60: LLC, dsap 
STP (0x42), ssap STP (0x42), cmd 0x03, 802.1d config 
8000.00:ff:00:00:04:00.8002 root 0064.00:ff:00:00:14:01 pathcost 255 age 0 
max 20 hello 2 fdelay 15 
> 
> 01:80:c2:00:00:00 is an 'IEEE 802.1D MAC Bridge Filtered MAC Group Address'.
> Other bridges are not supposed to relay it.
> 
> Looking at the traffic on fast-a, I see this on tap1:
> 
> 01:34:21.233787 fast-a-tap1 > 1:80:c2:0:0:0 0026 60: 802.1d config 
8000.00:ff:00:00:04:00.8002 root 0064.00:ff:00:00:14:01 pathcost 255 age 0 
max 20 hello 2 fdelay 15
> (but no TCN)
> 
> On fast-a tap0, I see this:
> 
> 01:34:32.669988 fast-a-tap0 > 01:80:c2:00:00:00, 802.3, length 60: LLC, dsap 
STP (0x42), ssap STP (0x42), cmd 0x03, 802.1d tcn
> 01:34:33.230936 fast-c-tap3 > 01:80:c2:00:00:00, 802.3, length 60: LLC, dsap 
STP (0x42), ssap STP (0x42), cmd 0x03, 802.1d config 
0064.00:ff:00:00:14:01.8003 root 0064.00:ff:00:00:14:01 pathcost 0 age 0 max 
20 hello 2 fdelay 15 
> 
> Now let's take a look at fast-c's view of things (fast-c is the root
> bridge).
> 
> tap2:
> 
> 01:37:25.202035 fast-c-tap2 > 1:80:c2:0:0:0 0026 60: 802.1d config 
0064.00:ff:00:00:14:01.8002 root 0064.00:ff:00:00:14:01 pathcost 0 age 0 max 
20 hello 2 fdelay 15 
> 
> tap3:
> 
> 01:37:43.199898 fast-c-tap3 > 1:80:c2:0:0:0 0026 60: 802.1d config 
0064.00:ff:00:00:14:01.8003 root 0064.00:ff:00:00:14:01 pathcost 0 age 0 max 
20 hello 2 fdelay 15 
> 
> So, the situation is the following:
> 
> - fast-s generates TCNs that no one else can see.
> - fast-a generates TCNs that no one else can see.
> - fast-c is the root bridge and has no idea there was a topology change.
> 
> I'm not sure where to go from here. It would be possible that the TCNs are
> actually propagated, but the kernel swallows them before pcap gets its
> chance; this does not seem to be the case however, because then the kernel
> would presumably act on the TCN, which it does not.
> 
> I'm assuming that the bridge-like thing inside openvpn (that does
> client-to-client, for example) tries to be well-behaved and does not forward
> locally generated packets addressed to 01:80:c2:00:00:00 to its peers, so
> the TCNs never reach the root bridge. This would explain why my packets take
> the long route instead of the short one, but doesn't readily explain why my
> other box would lose its eth0 arp entries.
> 
> Any ideas?

I would guess it might be because the internal OpenVPN bridge function is not 
entirely IEEE 802.1D compliant.

One problem here is that the IEEE 802.1D docs are not freely available, at 
least according to the IEEE web site.

Right now OpenVPN's bridge algorithm is extremely minimalist, with the goal of 
accomplishing useful bridging with the least number of lines of code.  So the 
algorithm is basically this:

* Observe MAC source addresses and learn which client they came from.  Any MAC 
address except for 00:00:00:00:00:00 or FF:FF:FF:FF:FF:FF is considered an 
individual address.

* Broadcast frames with a FF:FF:FF:FF:FF:FF destination address to all 
clients.
 
* Route non-broadcast frames to clients based on a lookup of the destination 
address with the current list of learned addresses.  If the destination 
address lookup fails, i.e. the address was never learned, drop the frame.

Now one problem I see based on second-hand accounts of IEEE 802.1D is that  
MAC Group Addresses might need special handling in OpenVPN.  Specifically, 
the address range 01:80:c2:00:00:00 through 01:80:c2:00:00:0F apparently 
should not be forwarded, or associated with a specific client through 
learning.  This is easy enough to implement.  Frames in that address range 
can be dropped.

What about the Standard MAC Group Addresses: 01-80-C2-00-00-10 to 
01-80-C2-FF-FF-FF.  Do they need to be handled specially?

Am I correct to assume that a MAC Group Address would always be a destination 
address and never a source address?

James

____________________________________________
Openvpn-users mailing list
Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/openvpn-users