[Xorp-users] Fwd: Fwd: Problem in IPv6 SSM Multicast
Hansi
hantongs at gmail.com
Thu Dec 6 03:19:43 PST 2007
Hello Pavlin,
Finally, IPv6 PIM SSM is working. :) Here are the details:
admin at demo_rtr.infoweapons.com> show mld group
Interface Group Source LastReported Timeout V State
sk0 ff02::2 :: fe80::219:5bff:fe85:cfc7
159 1 E
sk0 ff02::d :: fe80::219:5bff:fe85:cfc7
159 1 E
sk0 ff02::16 :: fe80::219:5bff:fe85:cfc7
159 1 E
sk0 ff02::1:ff00:1 :: fe80::219:5bff:fe85:cfc7
159 1 E
sk0 ff02::1:ff2f:1468 :: fe80::219:5bff:fe2f:1468
166 2 E
sk0 ff02::1:ff85:cfc7 :: fe80::219:5bff:fe85:cfc7
159 1 E
sk0 ff02::2:15ba:6cf7 :: fe80::219:5bff:fe85:cfc7
159 1 E
sk0 ff3e::1234 :: fe80::219:5bff:fe2f:1468
0 2 I
sk0 ff3e::1234 2001:ec2:4002:fa11:200:24ff:fec4:3235
fe80::219:5bff:fe2f:1468 166 2 F
Visible in the Show MLD Group is the multicast address FF3E:1234 and the
source
2001:ec2:4002:fa11:200:24ff:fec4:3235 w/c indicates that xorp successfully
received a MLDv2 Join message from the client receiver application.
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?
Thanks,
Hansi
On Dec 5, 2007 9:40 PM, Hansi <hantongs at gmail.com> wrote:
> Hello Pavlin,
>
> I've consulted w/ the VLC authors and everything appears to be alright w/
> the VLC player according to them. Weird... anyway, I'll review my setup. I
> might have overlooked something though..
>
> Thanks for your assistance.
>
> Hansi
>
> On Dec 5, 2007 2:46 AM, Pavlin Radoslavov <pavlin at icir.org> wrote:
>
> > > > > > show mld group
> > > > >
> > > > >
> > > > > Interface Group Source LastReported Timeout
> > V
> > > > State
> > > > > sk0 ff02::2 ::
> > fe80::219:5bff:fe85:cfc7
> > > > > 243 1 E
> > > > > sk0 ff02::d ::
> > fe80::219:5bff:fe85:cfc7
> > > > > 243 1 E
> > > > > sk0 ff02::16 ::
> > fe80::219:5bff:fe85:cfc7
> > > > > 243 1 E
> > > > > sk0 ff02::1:ff00:1 ::
> > fe80::219:5bff:fe85:cfc7
> > > > > 243 1 E
> > > > > sk0 ff02::1:ff2f:1468 ::
> > fe80::219:5bff:fe2f:1468
> > > > > 248 2 E
> > > > > sk0 ff02::1:ff85:cfc7 ::
> > fe80::219:5bff:fe85:cfc7
> > > > > 243 1 E
> > > > > sk0 ff02::2:15ba:6cf7 ::
> > fe80::219:5bff:fe85:cfc7
> > > > > 243 1 E
> > > >
> > > > It doesn't seem that the client/receiver with IPv6 address
> > > > 2001:ec2:4002:fa11:200:24ff:fec4:3235 has joined group ff3e::1234.
> > >
> > >
> > > The ipv6 address 2001:ec2:4002:fa11:200:24ff
> > > >
> > > > :fec4:3235 is the address of the streaming server. :)
> > > >
> > >
> > > > So your guess in your original email is correct: there is something
> > > > wrong with the receiver so it hasn't joined the multicast group.
> > > > Could you run tcpdump to capture all ICMPv6 (incl. MLD) traffic and
> > > > confirm that XORP is sending the periodic query messages, but the
> > > > receiver itself never sends MLDv2 Join messages.
> > >
> > >
> > > Here are the logs from tcpdump taken on the LAN side of the router
> > (router
> > > ----- receiver)
> > > 20:24:32.872230 IP6 (hlim 1, next-header: Options (0), length: 36)
> > > fe80::219:5bff:fe85:cfc7 > ip6-allnodes: HBH (rtalert: 0x0000)
> > (padn)[icmp6
> > > sum ok] ICMP6, multicast listener query, length 28v2 [max resp
> > delay=10000]
> > > [gaddr :: robustness=2 qqi=125]
> >
> > OK: the router sends the Query
> >
> > > 20:24:32.876596 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ff02::16: HBH (padn)(rtalert: 0x0000)
> > [icmp6 sum
> > > ok] ICMP6, multicast listener report, length 24max resp delay: 0 addr:
> >
> > > ff02::16
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ff02::16
> >
> > > 20:24:32.892588 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ip6-allrouters: HBH (padn)(rtalert: 0x0000)
> >
> > > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> > delay: 0
> > > addr: ip6-allrouters
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ip6-allrouters
> >
> > > 20:24:32.906594 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ff02::d: HBH (padn)(rtalert: 0x0000) [icmp6
> > sum
> > > ok] ICMP6, multicast listener report, length 24max resp delay: 0 addr:
> >
> > > ff02::d
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ff02::d
> >
> > > 20:24:32.906613 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ff02::1:ff00:1: HBH (padn)(rtalert: 0x0000)
> >
> > > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> > delay: 0
> > > addr: ff02::1:ff00:1
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ff02::1:ff00:1
> >
> > > 20:24:32.906634 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ff02::2:15ba:6cf7: HBH (padn)(rtalert:
> > 0x0000)
> > > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> > delay: 0
> > > addr: ff02::2:15ba:6cf7
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ff02::2:15ba:6cf7
> >
> > > 20:24:32.910605 IP6 (hlim 1, next-header: Options (0), length: 32)
> > > fe80::219:5bff:fe85:cfc7 > ff02::1:ff85:cfc7: HBH (padn)(rtalert:
> > 0x0000)
> > > [icmp6 sum ok] ICMP6, multicast listener report, length 24max resp
> > delay: 0
> > > addr: ff02::1:ff85:cfc7
> >
> > OK: MLDv1 Report from the router itself that it is a member of group
> > ff02::1:ff85:cfc7
> >
> > > 20:24:37.389295 IP6 (hlim 1, next-header: Options (0), length: 36)
> > > fe80::219:5bff:fe2f:1468 > ff02::16: HBH (rtalert: 0x0000)
> > (padn)[icmp6 sum
> > > ok] ICMP6, multicast listener report v2, length 28, 1 group record(s)
> > [gaddr
> > > ff02::1:ff2f:1468 is_ex { }]
> >
> > OK: MLDv2 Report from the client that it is a member of group
> > ff02::1:ff2f:1468 for all sources.
> >
> > It appears that the MLDv2 join mechanism between the client and the
> > router is working for group ff02::1:ff2f:1468 (which is the group
> > automatically joined by the kernel on the client's interface).
> >
> > However, I don't seen any join for the multicast group from the
> > client's application.
> >
> > > Back when I was exploring ipv4 ssm, everytime I click either on the
> > play or
> > > stop button of the vlc client, I always see an IGMP join or prune
> > message.
> > > Shouldn't it that it also applies to MLDv2? However, I'm not seeing
> > any
> > > here.
> >
> > I am not familiar with vlc, but what you say is the logically
> > expected behavior.
> > You might want to contact the vlc author(s) about that.
> >
> > > > BTW, what about MLDv1 Join messages? If you configure the client to
> > > > join some (*,G) multicast group does it initiate MLDv1 Join?
> > > >
> > > My current setup is intended for PIM-SSM traffic. Can it also apply to
> > PIM
> > > SM considering the setup consist of only two routers?
> >
> > Yes, you can, but then you must configure one of the routers as the
> > RP. For testing purpose you could just try without any
> > RP. Obviously, multicast routing won't work, but the "show mld
> > group" output will tell us whether MLDv1 Join works for the
> > application (and whether the router will record that).
> >
> > Regards,
> > Pavlin
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ICSI.Berkeley.EDU/pipermail/xorp-users/attachments/20071206/3c2c4be4/attachment-0001.html
More information about the Xorp-users
mailing list