[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 MacLean <macleajb@xxxxxxxxxxx>
  • Date: Sun, 1 Jun 2003 11:37:03 -0300 (ADT)

On Sun, 1 Jun 2003, James Yonan wrote:

> I've never used mrouted, though I understand that it uses IP over IP tunnels,
> and so is likely using IP fragmentation as well.  If you look at the source
> snippet below, you will see that if the linux kernel encounters a multicast
> packet larger than the MTU that the destination can support, it drops it into
> a black hole.  The IP over IP code appears to take the path MTU of the
> destination referenced by the top-level encapsulation and subtract the IP over
> IP header size to derive the MTU of the inner encapsulation.  I would guess
> that someone trying to send a packet to the endpoint of an IP over IP tunnel
> will cause the kernel to see this lesser MTU and fragment according to the
> fragmentability of the particular IP protocol that's being tunneled.  In the
> cast of multicast, it could end up routing a large packet to /dev/null, since
> multicast doesn't fragment.

Excellent. _That_ explains it all. It explains why all kernel tunnels
suffer from this. Yes, mrouted uses IP over IP, GRE tunnels should be
similar and they would all be falling into the hole you found in the
kernel.

I expect unless you have some end-to-end smarts on the tunnel, you can not 
break up packets, send them down the tunnel and reconstruct them at the 
other end. That is magic only being seen in OpenVPN :).

I expect there must be some RFC that states that these MultiCast packets
should be droped and not fragmented at tunnels? I ask because if you send
a 1500 byte MultiCast packet from an application on a box that has an MTU
of 1400, it _does_ fragment it out the interface and appears to allow the
application to function. So it would appear to me that the tunnels
_should_ allow the same capabilities? Or could at least have been setup to 
act as other interfaces?

> Can you configure mrouted to use openvpn tunnels directly, rather than routing
> an IP over IP tunnel through the openvpn tunnel?

That's what the setup at work between the two macines is. I will be trying
the same for my home connection, but it will take some time to change the
setup,
 
> I suspect (as I believe you do) that the IP over IP tunnel might be killing
> the large multicast packets before they ever reach the local endpoint of the
> openvpn tunnel.

Yes. It was the explaination I was looking for all along :-). Many thanks 
for opening my eyes :).

> > Sure, the UDP packets of the tunnel can negotiate MTU... But still the 
> > underlying MultiCast is not being helped out.
> 
> How large are the multicast packets?  Do you have any control over their size?

The packets are usually maxing around 1470. I can set them smaller using 
mp4live's rtpPayloadSize setting, but I was looking to understand the 
problem as it exists and see if it should be fixed at the source first. 
Actually the smaller the size mp4live sends, the poorer the picture 
looks... But that might be me just starting to see things :(.

> Well here's the linux source (2.4.19).  You not only cannot fragment
> multicasts, but you cannot report your inability to do so via the ICMP mechanism.
> 
> if (skb->len+encap > rt->u.dst.pmtu && (ntohs(iph->frag_off) & IP_DF)) {
> 	/* Do not fragment multicasts. Alas, IPv4 does not
> 	   allow to send ICMP, so that packets will disappear
> 	   to blackhole.
> 	 */
> 
> 	IP_INC_STATS_BH(IpFragFails);
> 	ip_rt_put(rt);
> 	return;
> }

Is this code saying that if the DF bit is already set, you can not 
fragment it again, or that if the DF is set, it wants to request to be 
fragmented, but this code disallows it?

Sorry the questions are simple, but I'm still trying to understand why
multicast packets _can_ be fragmented when they are push from an
application out its eth0, but not when they are shoved down a tunnel.

I guess I am just missing the connecting piece. Probably that the above 
code deals with packets traversing a system (in one interface out the 
other) and my example of the application getting fragmented is because it 
is just going out an interface, so the logic is in a different part of the 
network code?

thanks again for explaining what is going on,
JES
-- 
James B. MacLean        macleajb@xxxxxxxxxxx
Department of Education 
Nova Scotia, Canada
B3M 4B2