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

Re: [Openvpn-users] Multicast fragmenting not handled by OpenVPN ?


  • Subject: Re: [Openvpn-users] Multicast fragmenting not handled by OpenVPN ?
  • From: "James Yonan" <jim@xxxxxxxxx>
  • Date: Thu, 5 Jun 2003 21:33:31 -0000

James MacLean <macleajb@xxxxxxxxxxx> said:

> Hi Folks,
> 
> On Sun, 1 Jun 2003, James Yonan wrote:
> 
> > James MacLean <macleajb@xxxxxxxxxxx> said:
> > 
> > > On Sat, 31 May 2003, James Yonan wrote:
> > > > James MacLean <macleajb@xxxxxxxxxxx> said:
> > > > > Hi Folks,
> > > > > Wanted to report that openvpn-1.4.1.3 does properly get the multicast 
> > > > > packets through using the suggestion from below. It's the only
tunnel that 
> > > > > does it.
> > > > Great, I'm glad it's working for you.
> > > 
> > > Well... :) It was/is working... At work, between 2 machines both with 
> > > linux 2.4.20 type kernels and using the openvpn tun interfaces for mrouted 
> > > to route over (no mrouted own tunnel involved).
> > > 
> > > But from work to home, which is from a 2.2.x kernel to a 2.4.20 ish 
> > > kernel, it does not appear to be doing its magic. Maybe I should not have 
> > > enabled pthread in openvpn...
> > 
> > I doubt that pthread is an issue here.  It doesn't really do anything unless
> > you are negotiating the tunnel with TLS, though it wouldn't hurt to rule it
> > out by building without pthread.
> 
> Have now tested that when I remove the mrouted tunnel and just use OpenVPN 
> with either mtu-dynamic or tun-extra-mtu then the multicast packets 
> successfully make it to their destination.
> 
> Pavlin Radoslavov (maintaner of PIMd) realized though that the Linux
> kernel is setting the DF bit on _all_ multicast packets it creates. He
> does not believe this to be correct. Not sure if it is backed by any RFCs
> or other decisions?
> 
> Last, openvpn-1.4.1.3 runs slower then its predecessor. Or at least it is
> missing something. Tried pthreads, no pthreads, with dynamic-mtu, without.  
> In all cases, openvpn-1.4.0 carried our traffic to its destinations
> faster. There are different kinds of traffic being sent, but NFS is one
> obvious example where speed was noticeably slower. Also pings used during
> Nagios monitoring would be lost quite often, even when the link was not
> busy. Not sure what this deals with but wanted to pass it along.

I would like to isolate where the slowdown is occurring.

If you build 1.4.1.3 without --enable-mtu-dynamic, how does it compare with
1.4.1 also built without --enable-mtu-dynamic?

You mention 1.4.0 in the above paragraph.  Does 1.4.0 perform differently than
1.4.1 (without --enable-mtu-dynamic on both)?

Now if you compare 1.4.1.3 built with --enable-mtu-dynamic, but without using
the --mtu-dynamic option, what is the result of a comparison with 1.4.1 or
1.4.0 built without --enable-mtu-dynamic? 

All of the above tests should produce results that are roughly equal.  If they
don't, it suggests a possible problem.

The only measurable difference in speed should occur when you are comparing an
--mtu-dynamic tunnel against a tunnel without --mtu-dynamic and where
fragmentation is not occurring. 

Let me know,

James