Cisco 3560+ipservices — IGMP snooping issue with TTL=1

ciscoigmpmulticastttl

I've got a C3560 with Enhanced (IPSERVICES) image, routing multicast between its VLANs with no external multicast router. It's serving a test environment where developers may generate multicast traffic on arbitrary addresses. Everything is working fine except when someone sends out multicast traffic with TTL=1, in which case the multicast packet suppression fails and the traffic is broadcast to all members of the VLAN.

It looks to me like because the TTL is 1, the multicast routing subsystem doesn't see the packets, so it doesn't create a mroute table entry. If I send out packets with TTL=2 briefly, then switch to TTL=1 packets, they are filtered correctly until the mroute entry expires.

My question: is there some trick to getting the switch to filter the TTL=1 packets, or am I out of luck?

Below are the relevant parts of the config, with a representative VLAN interface. I can provide more info as needed.

#show run
...
ip routing
ip multicast-routing distributed
no ip igmp snooping report-suppression
!
interface Vlan44
 ip address 172.23.44.1 255.255.255.0
 no ip proxy-arp
 ip pim passive
...

#show ip igmp snooping vlan 44
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping                : Enabled
IGMPv3 snooping (minimal)    : Enabled
Report suppression           : Disabled
TCN solicit query            : Disabled
TCN flood query count        : 2
Robustness variable          : 2
Last member query count      : 2
Last member query interval   : 1000

Vlan 44:
--------
IGMP snooping                       : Enabled
IGMPv2 immediate leave              : Disabled
Multicast router learning mode      : pim-dvmrp
CGMP interoperability mode          : IGMP_ONLY
Robustness variable                 : 2
Last member query count             : 2
Last member query interval          : 1000

Best Answer

I encountered this recently on Cisco Cat 4900M switches. The symptom I saw was high latency, some 10 times higher than that of packets with TTL>1. After speaking to Cisco, it turned out it was a bug in the version of IOS we used, and was resolved in a later version.

There's also some background here: http://web.archive.org/web/20100414150244/http://www.29west.com/docs/THPM/ttl-1-and-cisco-cpu-usage.html

Related Topic