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

[Hansi]

Hello Pavlin,

Apparently, the receiver had two interfaces. One interface connected to the
test network I'm currently using and the other one to the production
network. I suspect the MLDv2 Join messages are sent to the wrong interface
(in this case, the production network) though I explicitly set the
link-local address of the xorp router machine as the client's default
gateway.

Yes, you are right. I ran tcpdump on the sender side and it appears the
streaming server is sending out fragmented packets.

Streaming Server to Router 1:

09:51:22.692158 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 100) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xec6a52cc:1232|92)
09:51:22.700132 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xf753c59f:0|1232) 61541 > 1234: UDP, length 1316
09:51:22.700146 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 100) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xf753c59f:1232|92)
09:51:22.708230 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xe37aa8b2:0|1232) 61541 > 1234: UDP, length 1316
09:51:22.708243 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 100) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xe37aa8b2:1232|92)
09:51:22.716214 IP6 (flowlabel 0x394e1, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0xc1fd9920:0|1232) 61541 > 1234: UDP, length 1316

Apparently, a second fragment of length 100 is sent out after the first one.
Oddly though.. once the fragmented packets reached Router 2, the second
fragment is no longer received... probably dropped. I'm suspecting that
Router 2 is unable to associate the second fragment to the first.

Router 1 <------> Router 2

05:57:43.861774 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x40a52867:0|1232) 61542 > 1234: UDP, length 1316
05:57:43.871960 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x33f49657:0|1232) 61542 > 1234: UDP, length 1316
05:57:43.882756 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x2d938af5:0|1232) 61542 > 1234: UDP, length 1316
05:57:43.893746 IP6 (flowlabel 0xb063f, hlim 14, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x62f4a589:0|1232) 61542 > 1234: UDP, length 1316


Router <------> (sk0)receiver

17:51:56.196244 IP6 (flowlabel 0xb063f, hlim 13, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x48714108:0|1232) 61542 > 1234: UDP, length 1316
17:51:56.205162 IP6 (flowlabel 0xb063f, hlim 13, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x5449397c:0|1232) 61542 > 1234: UDP, length 1316
17:51:56.214114 IP6 (flowlabel 0xb063f, hlim 13, next-header: Fragment (44),
length: 1240) 2001:ec2:4002:fa11:200:24ff:fec4:3235 > ff3e::1234: frag
(0x3e81a7bf:0|1232) 61542 > 1234: UDP, length 1316

I'm currently investigating this issue right now. Got to read more on IPv6
fragmentation. hehe...

Thanks,
Hansi

On Dec 7, 2007 4:00 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:

> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071210/76d4f593/attachment-0001.html