[Xorp-users] Unable to forward multicast packets

[Pavlin Radoslavov]

> I'm trying to route multicast (IPv4) packets using XORP.  I am running XORP
> under Linux (Fedora Core 3, kernel 2.6.12).  I have included the
> "config.boot" file, the xorp_rtrmgr log, and output from the xorpsh "show"
> commands.
> 
>  
> 
> My current configuration is as follows:
> 
>  
> 
> Network_A_Client <-- 64.1.0.0/16 --> Xorp_Router <-- 64.2.0.0/16 -->
> Network_B_Client
> 
>  
> 
> I have a test application that creates multicast UDP packets and sends them
> to a specified group.  In my test case I use 225.1.1.1 (port 22604) for my
> multicast group.  Placing both clients on the same subnet (i.e. no xorp /
> routing), both test instances of the test application see their own packets
> it creates and sends, as well as, the packets created by the second
> instance.
> 
>  
> 
> When trying to use XORP to route / forward the packets to all group members,
> XORP "sees" all group joins and knows which interface that packets are
> coming from, and even indicates that they are going out of the appropriate
> (other) vif ("show pim mfc").  However, the test apps only see the packets
> they created.

Everything in your configuration, CLI output and log output seems
fine. One possible problem that comes to mind is that the original
multicast packets are probably transmitted with the default TTL of
1.
TTL of 1 is sufficient for link-local multicast, but such multicast
packets won't be forwarded across subnets.

Try to increase the TTL of the transmitted data packets and see if
the problem goes away.
If you wrote the test application by yourself, you need to use
something like the following to set the sender's IPv4 TTL:

u_char ip_ttl = your_chosen_ttl;
setsockopt(sock, IPPROTO_IP, IP_MULTICAST_TTL,
           &ip_ttl, sizeof(ip_ttl));

If increasing the TTL doesn't help, check if there are any firewall
rules on the Linux box that filters the multicast packets.

If there are no firewall rules to blame, then please send the output
of "cat /proc/net/ip_mr_cache" while XORP is running and the sender is
transmitting, and we can try to debug the problem from there.


Pavlin