-
-
Notifications
You must be signed in to change notification settings - Fork 90
Debug Help
This text contains some hints how to debug your multicast routing.
-
Make sure that the TTL of the sender is large enough to reach the receiver. E.g., if the sender and the receiver are separated by a two routers in the middle, the TTL of the data packets transmitted by the sender must be at least 3.
-
Make sure the receiver sends IGMP join (membership report) for the group(s) it want to receive. Use tcpdump on the router closest to the receiver to make sure. Sometimes buggy IGMP snooping switches, or cloud provider networks, filter out multicast in general, in all control traffic (IGMP/PIM) in particular.
-
Before you start the multicast routing daemon
-
Verify the kernel config, the following settings should be activated:
CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_V1=y CONFIG_IP_PIMSM_V2=y
-
Check the list of multicast capable interfaces:
cat /proc/net/dev_mcast
-
Start the multicast routing daemon in debug mode, e.g.
pimd -d all
-
-
After you start the multicast routing daemon
-
Are the multicast VIFs correctly installed in the kernel:
cat /proc/net/ip_mr_vif
-
Is multicast forwarding enabled on those VIFs:
cat /proc/sys/net/ipv4/conf/eth0/mc_forwarding
for each of the enabled interfaces. If it returns zero, the multicast forwarding on that interface is not working.
-
Is the PIM multicast routing daemon exchanging PIM HELLO messages with its neighbors? Look into the debug messages output; if necessary, use tcpdump as well.
-
Are the Bootpstrap messages received by all PIM-SM daemons?
-
If a Bootstrap message is received, is it accepted, or is it rejected because of a wrong iif?
-
After a while, does the Cand-RP set contain the set of RPs?
-
After the first multicast packets are received, is there a
CACHE_MISS
signal from the kernel to the user-level daemon? -
After the
CACHE_MISS
signal, are the MFC (Multicast Forwarding Cache) entries installed in the kernel?cat /proc/net/ip_mr_cache
-