[Xorp-users] Fwd: Fwd: Problem in IPv6 SSM Multicast

Pavlin Radoslavov pavlin at icir.org
Thu Dec 6 12:00:42 PST 2007


> Finally, IPv6 PIM SSM is working. :) Here are the details:

Good!
What was the source of the problem?

> What's odd though is that I don't see any video displayed in the vlc
> receiver application. I'm quite sure PIM-SSM is already working as I can see
> these packets on the interface of the receiver connected to the upstream
> router:
> 
> 17:19:39.634155 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x9a8d7789:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.646131 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x89a0d7d2:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.659118 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x960ae0a2:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.670100 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xaa68e0b2:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.683136 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x856c81f0:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.695087 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xd64fbf0f:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.708045 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0x99f7d97b:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.720029 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xdc3a139d:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:39.732111 IP6 (flowlabel 0x97cd0, hlim 10, next-header: Fragment (44),
> length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
> (0xa3688a13:0|1232) 65336 > 1234: UDP, length 1316
> 17:19:47.410658 IP6 (hlim 1, next-header: Options (0), length: 52)
> fe80::219:5bff:fe2f:1468 > ff02::16: HBH (rtalert: 0x0000) (padn)ICMP6,
> multicast listener report v2, length 44, 1 group record(s) [gaddr ff3e::1234
> block {[|icmp6]
> 
> Is there something wrong with the packets arriving at the receiver's side?

It looks like the IPv6 UDP packets that reach the receiver are
fragmented. Also, I could be wrong here, but it appears that only
the first fragment of each packet reaches the receiver, and the
second segment is missing. The way I interpretate the above log
messages is that the size of each original UDP packet is 1316, but
each of the above fragments contains only 1240 bytes.

FYI, the IPv6 fragmentation should happen at the sender so you need
to run tcpdump on the sender's segment to see whether it really
sends all fragments. You should be looking for the smaller fragments
with size of 76 or so.

Once you solve the above problem, you should also try to eliminate
the reason for the fragmentation. E.g., if the sender's application
allows you to control the transmitted packet size then you should
eventually reduce it to avoid the fragmentation penalty.
However, I'd strongly recommend that first you fix the problem with
the missing fragments. Otherwise, if you mask it by reducing the
packet size it will come and bite you at later stage :)

Regards,
Pavlin



More information about the Xorp-users mailing list