Would it be extremely difficult to do multicast over tinc? How about reliable multicast over tinc? This would be more traffic than multicast dns, but not _necessarily_ a great deal more. It would be for syncing some information among freeipa domain controllers. Would the tinc nodes need to be in all in switch or maybe even hub mode? EthernetOverIP over tinc?
Switch mode acts in this way already. You can already use multicast but all of your ting nodes must be n switch mode. Regarding reliability: it will only be as reliable as your provider. Also factoring in that multicast uses udp packets which do not guarantee sucessful delivery. "Rob Townley" <rob.townley@...> wrote: >Would it be extremely difficult to do multicast over tinc? > >How about reliable multicast over tinc? > >This would be more traffic than multicast dns, but not _necessarily_ >a great deal more. >It would be for syncing some information among freeipa domain >controllers. > >Would the tinc nodes need to be in all in switch or maybe even hub >mode? > >EthernetOverIP over tinc? >_______________________________________________ >tinc-devel mailing list >tinc-devel@... >http://www.tinc-vpn.org/cgi-bin/mailman/listinfo/tinc-devel -- -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On Wed, Oct 6, 2010 at 4:11 PM, Mike Bentzen <mike@...> wrote: > Switch mode acts in this way already. You can already use multicast but all of your ting nodes must be n switch mode. > > Regarding reliability: it will only be as reliable as your provider. Also factoring in that multicast uses udp packets which do not guarantee sucessful delivery. > Thanks Mike, but i thought i read tinc could do a small amount of mutlicast, like mdns, but not large amounts. Does that sound right? Would only be a small amount in router mode? i was surprised to find out there is such a thing as secure reliable multicast -- see http://www.ietf.org/dyn/wg/charter/msec-charter > "Rob Townley" <rob.townley@...> wrote: > >>Would it be extremely difficult to do multicast over tinc? >> >>How about reliable multicast over tinc? >> >>This would be more traffic than multicast dns, but not _necessarily_ >>a great deal more. >>It would be for syncing some information among freeipa domain >>controllers. >> >>Would the tinc nodes need to be in all in switch or maybe even hub >>mode? >> >>EthernetOverIP over tinc?(Continue reading)
Hi Rob, I do not believe tinc is limited this way. Give it a go! ;) Router mode will not multicast. You'll want switch mode only. You might also be interested in this: http://en.wikipedia.org/wiki/Pragmatic_General_Multicast Mike On 07/10/2010, at 2:41 PM, Rob Townley wrote: > On Wed, Oct 6, 2010 at 4:11 PM, Mike Bentzen <mike@...> wrote: >> Switch mode acts in this way already. You can already use multicast but all of your ting nodes must be n switch mode. >> >> Regarding reliability: it will only be as reliable as your provider. Also factoring in that multicast uses udp packets which do not guarantee sucessful delivery. >> > > Thanks Mike, but i thought i read tinc could do a small amount of > mutlicast, like mdns, but not large amounts. Does that sound right? > Would only be a small amount in router mode? > > i was surprised to find out there is such a thing as secure reliable > multicast -- see http://www.ietf.org/dyn/wg/charter/msec-charter > > >> "Rob Townley" <rob.townley@...> wrote: >> >>> Would it be extremely difficult to do multicast over tinc?(Continue reading)
On Thu, Oct 07, 2010 at 03:06:23PM +1000, Mike Bentzen wrote:
> I do not believe tinc is limited this way. Give it a go! ;)
> Router mode will not multicast. You'll want switch mode only.
Tinc also supports multicast in router mode. The limitation is that in all
Modes, tinc treats multicast packets as broadcasts, so it will work but it is
not very efficient if, for example, you have 100 nodes and want to stream HD
video via multicast to only 5 of them.
--
Met vriendelijke groet / with kind regards,
Guus Sliepen <guus@...>
On Thu, Oct 07, 2010 at 03:06:23PM +1000, Mike Bentzen wrote: > I do not believe tinc is limited this way. Give it a go! ;) > Router mode will not multicast. You'll want switch mode only. Tinc also supports multicast in router mode. The limitation is that in all Modes, tinc treats multicast packets as broadcasts, so it will work but it is not very efficient if, for example, you have 100 nodes and want to stream HD video via multicast to only 5 of them. -- -- Met vriendelijke groet / with kind regards, Guus Sliepen <guus@...>
I've been using tinc to do some high bandwidth VPNs between nodes in Amazon's EC2 environment (to work around some limitations there for effectively loadbalancing raw TCP connections while preserving the sources addresses, using Linux IPVS in NAT mode). The raw amount of traffic involved is probably making this a bit of a corner case for tinc. In the overall it has held up remarkably well under this scenario, and I really like the ease of configuration and deployment vs some of the other UDP tunneling options out there. Most of the issues I've run into I've been able to tune or configure my way around effectively. To recap the most important of those for posterity though (or maybe faq/doc info): 1) In tinc-up, users will want to adjust the txqueuelen of the tunnel device as appropriate with ifconfig. The default it 500, which resulted in tons of overruns for me. After trying 2000 for a while and still seeing overruns, I went with a value of 10000, which seems to be working well. 2) A single, central tinc daemon serving several high bandwidth client hosts can easily max out a CPU core on a reasonable machine, even with authentication, encryption, and compression disabled. The way to evade this (assuming most of your traffic flows are in a star rather than mesh shape anyways) is to spawn separate daemons for separate point-to-point VPN daemons for each client host, instead of building one giant VPN with a single daemon at the central host. This allows the CPU load to be spread over multiple CPU cores. There are a few other issues which may warrant some source changes though: 3) When looking at txqueuelen issues, I stumbled on a tun device flag(Continue reading)
On Sat, Oct 23, 2010 at 11:19:30AM -0500, Brandon Black wrote: > I've been using tinc to do some high bandwidth VPNs [...] How high is the bandwidth exactly? > 1) In tinc-up, users will want to adjust the txqueuelen of the tunnel > device as appropriate with ifconfig. The default it 500, which > resulted in tons of overruns for me. After trying 2000 for a while > and still seeing overruns, I went with a value of 10000, which seems > to be working well. Is the traffic very bursty? Normally, any TCP traffic inside the tunnel should adapt its bandwidth to that available, this means it also should not become higher than tinc can handle. So if traffic is very regular, one wouldn't expect many packets being queued in the tun device... > 3) When looking at txqueuelen issues, I stumbled on a tun device flag > IFF_ONE_QUEUE (and the corresponding TUN_ONE_QUEUE) in the Linux tun > source. Some other VPN software out there (openvpn for example) seems > to set this on all tun devices. Whether it helps or hurts in any > given situation on a modern Linux host is unclear to me just from > reading the source. It's possible this might warrant an experimental > config setting for Linux, or at least some more research and testing. Interesting. I have seen that flag but never looked into what it does. It can be made configurable. > 4) tinc.conf needs some settings for tuning SO_SNDBUF and SO_RCVBUF on > the tunnel traffic sockets. I was getting tons of "Lost XXX packets(Continue reading)
RSS Feed1 | |
|---|---|
9 | |
8 | |
2 | |
4 | |
2 | |
3 | |
2 | |
4 | |
13 | |
7 | |
5 | |
2 | |
1 | |
10 | |
2 | |
36 | |
7 | |
15 | |
3 | |
5 | |
7 | |
1 | |
1 | |
11 | |
3 | |
5 | |
1 | |
6 | |
16 | |
14 | |
6 | |
2 | |
5 | |
2 | |
1 | |
1 | |
8 | |
2 | |
8 | |
1 | |
15 | |
14 | |
9 | |
2 | |
1 | |
2 | |
2 | |
1 | |
3 | |
11 | |
3 | |
15 | |
3 | |
3 | |
1 | |
1 | |
3 | |
10 |
