Debugging Local Multicast on EXOS

Debugging Multicast Issues

Local Multicast address packets are handled differently when compared to data packets. Multicast forwarding/flooding mechanism is based on following three configurations;

1. Ingress vlan is L3 Vlan/L2 Vlan.
2. Snooping enabled/disabled.
3. Local Multicast forwarding configuration slow-path/fast path.

Forwarding behavior for Local multicast packets as well as data packets is as follows.

Configuration	224.0.0.x
IP address not configured(L2 vlan)	Fast-path flood
IP address configured(L3 vlan)	Slow-path flood

Configuration	Multicast stream
IGMP snooping enabled	Fast-path forward
IGMP snooping disabled	Fast-path flood

Debugging Issues with Local Multicast Packets(224.0.0.x) forwarding

L3 Vlan - vlan with IP address assigned.

All packets are flooded via software(slow-path) alone. There will be no cache entry in the hardware/HAL for these streams. Cache entry will be present only in Kernel and software. The following things are to be checked.

1. show mcast cache . In this output, check whether the proper source IP, group IP, egress ports, egress vlan of the stream is present.

If the entry is fine in software, then check whether the corresponding entry is present in Kernel.

2. !cat proc/net/snoop_mr_cache . In this outputs, check whether (S,G) entry is there and corresponding ingress port/egress ports are programmed properly.

In some rare cases, (S,G) information is present but not the ports details. Then this cache is just an unresolved cache and will not be used for packet forwarding.

If the (S,G) entry is not present in both software and kernel, check whether the packets are hitting the CPU using the below command.

3. tcpdump -i netTx src host <required-src-ip-address>

To abort the capture, use (Ctrl+C). In case the packets are not at all hitting the CPU, then check whether the filters are installed in hardware properly.

4. debug hal show platform vlan

check whether appropriate filter is installed in the ingress port. To proceed finding the hardware acl, follow the steps below.

1. Open another telnet session, lets say session
2. Now get into the BCM shell in the session
3. From the session 1, execute the below command.

5. debug hal run pib_acl pibaclwrapruledump <slot_num> <unit_num> <software_rule_id>

6. fp show entry <eid> , whereas <eid> is derived from above step(step 5 command).

If the hardware ACL is not installed in that port, this could be issue with ACL or the configuration part like igmp filter configuration, snooping configuration etc. Check “show configuration mcmgr” output.