[Xorp-users] Multicast problem

Pavlin Radoslavov pavlin at ICSI.Berkeley.EDU
Wed Aug 20 20:48:58 PDT 2008


Ben Greear <greearb at candelatech.com> wrote:

> Ok, the MFC was being set up, but it seems xorp continues to
> receive and transmit packets.  I'm thinking I don't really know
> how multicast routing is supposed to work :)

Yes, this is how PIM-SM is suppose to work.
The sender's multicast data packets are encapsulated in PIM Register
messages by the DR (Designated Router) for the sender's subnet,
and then are unicast to the RP. On Linux the encapsulation happens
in user-space (in the XORP PIM-SM process); on BSD the IPv4
encapsulation can happen in kernel (IPv6 BSD doesn't have the kernel
support to do that).
The user-space data encapsulation is probably the reason for the
long latency you were seeing.

However, if the RP sends source-specific (S,G) toward the DR, then
the multicast data packets will be forwarded natively (without the
PIM Register encapsulation overhead).
In XORP you can control when the RP sends the DR by using the
following configuration inside the pimsm4 or pimsm6 block:

        switch-to-spt-threshold {
            /* approx. 1K bytes/s (10Kbps) threshold */
            disable: false
            interval: 100
            bytes: 102400
        }

If you set "bytes" to 0 for example, then the RP should send the
(S,G) Join right after the first PIM Register for that socket is
received by the RP. In your case where performance is critical
you might want to set "bytes" to 0.

> So, I think it's all working proper now.
> 
> The only problem I found that might bother normal xorp users is the
> lack of resetting the msghdr flags.

I don't think this is necessary, because the msghdr.msg_flags are
used only to return flags by recvmsg(2), and are not used by
sendmsg(2). E.g., see:
UNIX Network Programming
W. R. Stevens et al, Volume 1, 3rd Edition, pp 390-391

Regards,
Pavlin

> The socket binding problem probably only affects users like me
> who are using multiple routing tables, and it would *appear* that
> this might be a kernel bug anyway.
> 
> Thanks for listening to me spew :)
> 
> Ben
> 
> -- 
> Ben Greear <greearb at candelatech.com>
> Candela Technologies Inc  http://www.candelatech.com
> 
> _______________________________________________
> Xorp-users mailing list
> Xorp-users at xorp.org
> http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-users



More information about the Xorp-users mailing list