Christian, On a quick read of your note, I'm not totally sure I can pick out the main goal of your setup. I'm wondering if taking one step back and looking at it from there would help.
Please mail me, privately if you would, and give me an idea of the setup *around* this host. Tell me what problem you're fixing, and let's see if VTun is even required here or whether there's another tool that may fit. I've set up some truly bizarre configurations, bridging tapXs the smallest bit of said craziness, and I'm interested in knowing what you're up to, here. - bish Christian Brandes wrote: > Hi! > > I am looking for a possibility to connect two network bridges to each other > such as br0 and br1. > > Since one network interface can only be enslaved to one single network > bridge, I thought about connecting two virtual network interfaces e.g. if0 > and if1 to each other such as ethernet packets sent out to if0 come back on > if1 and vice versa. Is there a possibility to achieve this? > > What about connecting two tap interfaces such as outputs from /dev/tap0 are > written to /dev/tap1 and vice versa? > How can I do this in the simplest way? > > I did not find any documentation on this. So I thought about asking you, > since vtun uses tap devices, so you surely know about that. > > My Idea is like this: > > normal state: failure of eth0: implementation idea: > --ethernetsegment-- --ethernetsegment-- --ethernetsegment-- > | | | | | > eth0 eth1 eth1 eth0 eth1 > | | | | | > br0---------br1 br0---------br1 br0--vnet0 br1---vnet1 > | | | | | | > vnet0 vnet1 vnet0 vnet1 tap0 tap1 > | | > /dev/tap0<->/dev/tap1 > > The loop in normal state would be permitted by spanning tree. In case of > failure of one network interface (eth0), all affected interfaces could still > be reached over the connection between br0 and br1. > > What I already tried is: Using vtun over the loopback device (lo). So I > started vtund as server and client on the same system and enslaved tap0 to > br0 and tap1 to br1. > > It works! That's really cool! ;-) > > But this solution has some overhead. The two vtund processes are really busy > with encapsulation and decapsulation work. They reach 100% cpu usage of one > core on my machine each. But the achieve at least 50 MByte/s throughput > (duplex) which results in 100 MByte/s on the loopback device (lo) (also > duplex). That's not bad, but I'd like to strip some overhead and let > /dev/tap0 and /dev/tap1 talk to each other more directly (without > en-de-capsulation). > > Could you help me find a better solution? > > Best regards > Christian > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > Vtun-Users mailing list > Vtun-Users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/vtun-users > ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_sfd2d_oct _______________________________________________ Vtun-Users mailing list Vtun-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/vtun-users
