[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
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: Sun, 11 Jul 2004 21:13:31 +0200

On Sun, Jul 11, 2004 at 01:39:07PM -0500, James Yonan wrote:

> > It appears to work. The bridges don't stay in TC mode forever anymore.
> > However, the resulting spanning tree is still weird - I'll have to
> > investigate that further.
> Is there a document somewhere, written in the style of the RFCs, that 
> succinctly sets forth the STP for implementors?

Sure, the IEEE 802.1d standard. I skimmed it a few times already and while I
find its terminology somewhat awkward, it's usable.

I just noticed that in my last post I accidentally gave you a URL for
802.11d instead of 802.1d. :) The correct URL is:

The same usage terms apply, i.e. "The IEEE is providing the Document to you
at no charge. [...] You may retrieve, download and print one (1) copy of
this Document for your personal use. You may retain one (1) additional copy
of this Document as your personal archive copy."

> > I suspect that in the long run it would be beneficial to implement the
> > spanning tree protocol in openvpn as well.
> As much as is possible, I would like to avoid putting too much
> network-stack-type stuff in OpenVPN. Ideally I would like to see the
> bridge mode in OpenVPN seamlessly interoperate with other ethernet bridges
> without having to be an STP-compliant bridge itself.

>From an aesthetic point of view, you are right; however, OpenVPN is already
a bridge, so you must address the issues this brings with it somehow. On
Linux, one way would be to dynamically allocate new tap interfaces as new
clients join the fray, and automatically add them to a bridge - that way,
OpenVPN wouldn't do the bridging at all. However, I'm afraid this might be
less scalable, and a lot less portable. It also doesn't work with tun
interfaces, but OpenVPN doesn't really _bridge_ them, does it?

As I see it, there are two approaches to take:

1. make the OpenVPN bridge implementation as fully 802.1d compliant as
possible, or

2. remove most bridge intelligence and just forward frames back and forth,
being careful to pass frames addressed to 01:anything along all links.

The latter approach would work because it seems to be impossible to create a
bridge loop with OpenVPN alone (the same tap device cannot be a client and a
server at the same time), and I do hope all the other software
implementations people would use are STP capable.

Note that the 802.1d standard appears to contain a reference implementation
of STP in C, or at least the framework for it; the Linux kernel already has
a free implementation that could possibly be shaped into a library for

I'm sorry to say that I'm unable to help for a number of reasons, the most
important being that I'm a lousy C coder. I'm able and willing to test
things though, but it might take time.


                 Andras Korn <korn at chardonnay.math.bme.hu>
                 <http://chardonnay.math.bme.hu/~korn/>	QOTD:
     Would you fly in an airliner designed and built by the lowest bidder?

Openvpn-users mailing list