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

Re: [Openvpn-users] Seemingly inexplicable phenomena with several bridges in a full mesh


  • Subject: Re: [Openvpn-users] Seemingly inexplicable phenomena with several bridges in a full mesh
  • From: KORN Andras <korn-openvpn@xxxxxxxxxxxxxxxxxxxxxx>
  • Date: Sat, 10 Jul 2004 01:49:43 +0200

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?

Andras

-- 
                 Andras Korn <korn at chardonnay.math.bme.hu>
                 <http://chardonnay.math.bme.hu/~korn/>	QOTD:
     Cats are smarter than dogs. You can't get eight cats to pull a sled.

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