[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
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: Fri, 23 May 2003 03:31:27 -0000


OpenVPN normally leaves all fragmenting and routing issues up to the kernel.

However OpenVPN 1.4.1 has a new experimental mode that does fragmenting
itself, allowing the MTU of the TUN/TAP device to be much larger than the MTU
of the UDP connection that carries the tunnel data.

To enable this feature, you must build OpenVPN with ./configure

Then you can use the --mtu-disc (Linux only) or --mtu-dynamic options to
explicitly control path MTU discovery and fragmenting options.

For example,

  openvpn --tun-mtu 1500 --mtu-disc yes --mtu-dynamic 500 500 [other options]

would create a tunnel that looks like it has an MTU of 1500 to the OS, but
OpenVPN would actually break the packets up so that the encrypted UDP
datagrams sent between the OpenVPN peers would never be larger than 500 bytes
(not including the IP header).  The "--mtu-disc yes" option tells the OS to
set the "Don't Fragment" bit on the UDP datagrams.  The downside of
--mtu-dynamic is that it will always be measureably less efficient than not
fragmenting in the first place.

The --mtu-dynamic option is still experimental at this point and has two
planned features which have not been implemented yet: (a) give --mtu-dynamic a
lower and upper bound on UDP MTU size and have OpenVPN automatically choose
the largest size (using a cryptographically secure handshake) which will not
fragment, without depending on the OSes implementation of Path MTU discovery,
and (b) given our empirically and securely determined path MTU, generate our
own "Fragmentation needed but DF set" ICMP messages to bounce back over the
TUN device, effectively constraining upstream senders to an MTU which will not
cause fragmentation.

Anyway, I mention this because it might be an interesting experiment to
isolate where the problem is occurring, i.e. if --mtu-dynamic fixes the
problem, then it may point to some kind issue with multicast fragmentation in
the kernel.

I also checked the Linux kernel source, and if you look at icmp_send in icmp.c
you will see:

	 *	No replies to physical multicast/broadcast
	if (skb_in->pkt_type!=PACKET_HOST)

	 *	Now check at the protocol level

It seems that this might create complications for Path MTU discovery on
multicast streams, because no "fragmentation needed but DF set" ICMP message
could be returned in response to a multicast stream that demands fragmentation.


James MacLean <macleajb@xxxxxxxxxxx> said:

> Hi Folks,
> I am seeing a problem which occurs both OpenVPN, GRE and mrouted's 
> builtin tunnels.
> If a large Multicast packet gets sent to the tunnel, it gets fragmented, 
> or atleast broken up :). But when it comes out the other side, it appears 
> to never get reconstructed into it original format.
> For some reason, this makes tunneled connections get a limited max 
> bandwidth of around 270Kbs. Almost like the kernel is getting slowed down 
> by them?
> If I set the MTU at the originating machine down to something smaller 
> like 1100, Linux fragements the packets at the source, they pass through 
> the tunnel un-split, and appear to work fine end to end.
> This is not only OpenVPN but also on GRE tunnels and mrouted builtin 
> tunnels. GRE and mrouted both use ipip.o in the Linux kernel if that 
> matters.
> VIC and Rat appear to not be affected by this because their packets are 
> mostly smaller around 512 bytes I think.
> To see it in action, Get mp4live running (part of mpeg4ip.sourceforge.net) 
> in multicast through a tunnel. I tried both mrouted and pimd. The results 
> will be that the fastest throughput you'll get is around 270Kbs :).
> Maybe this is just particular to Linux? Or it is expected?
> OpenVPN 1.4.1 and RedHat 9.0.
> -- 
> James B. MacLean        macleajb@xxxxxxxxxxx
> Department of Education 
> Nova Scotia, Canada
> B3M 4B2
> -------------------------------------------------------
> This SF.net email is sponsored by: ObjectStore.
> If flattening out C++ or Java code to make your application fit in a
> relational database is painful, don't do it! Check out ObjectStore.
> Now part of Progress Software. http://www.objectstore.net/sourceforge
> _______________________________________________
> Openvpn-users mailing list
> Openvpn-users@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/openvpn-users


Openvpn-users mailing list