Routers responding to arbitrary multicast MAC traffic -> multicast storm

[djluff]

I posted this once before in the security forum, because I couldn't find the routing and switching one, but didn't get an answer. The config is:

- Two cisco routers in a HSRP config, connected to a switch.

- Two Sun E220R servers running stonebeat in a HA load-sharing configuration, also connected to the switch. The virtual IP is a unicast IP address, linked to a multicast MAC address (0900.xxxx.xxxx).

- Have to create a static ARP entry on the routers for the unicast IP/multicast MAC combination. This works fine.

- When a packet comes through routerA destined for the stonebeat cluster, routerA correctly forwards it to the cluster multicast MAC.

- routerB receives the packet generated by routerA above, and forwards it to the cluster multicast MAC.

- routerA receives the packet generated by routerB above, and forwards it to the cluster multicast MAC.

etc, etc. So every packet sent from the routers to the

stonbeat cluster is retransmitted (TTL) times by the routers.

Why are the routers receiving and routing traffic addressed to a MAC address of 0900.xxxx.xxxx? They should ignore it as the routers have no reason to be listening on this MAC?

Workaround so far is with CAM filters but why does this happen?

[docwatson]

Change the TTL on the Multicast to 1. This should stop the loop.

Router>(config-if) #ip multicast ttl-threshold ttl-value

reference: page 381, Chapter 11, CCNP Switching Exam Guide by David Hucaby and Tim Boyles. Cisco Press, 2001.

Also, what multicast protocol are you using?

[stmillington]

This happens because Stonebeat has written a Multicast application without understanding Multicast.

If there is anyone that understands the stupid configurations requirements for stonebeat please contact me. We have a lab that is attempting to use the SB product without any great success.

Perhaps someone has contact with the company to motivate *them* to bone up on multicast before producing multicast applications?