Multicast storm with Cisco router and 0900.xxxx.xxxx MAC address.

[djluff]

We have the configuration below:

HSRP_Router_Pair<->Switch<->Stonebeat_Cluster

The stonebeat cluster uses a multicast MAC for it's virtual interface. When one of the routers sends a packet to the stonebeat cluster (ie. to the multicast MAC), the other router picks up the packet and transmits it again. Then the first router picks this up and transmits it again, etc until the TTL times out.

Result: multicast storm.

Why are the routers listening for (and routing) packets addressed to this multicast MAC? And how do we stop it?

More info:

- In the repeated packets, the TTL field is counting down. So the packets are going through the routers, not being duplicated by the switch. Also, the source MAC alternates between the two routers.

- The stonebeat cluster uses a unicast IP (10.201.10.7) with a multicast MAC (0900.0ac9.0a07). This is a normal stonebeat configuration.

- The routers are cards in Cat 5500's. (though same effect seems to occur with seperate 3600 routers)

- The routers each have a static arp entry mapping 10.201.10.7 -> 0900.0ac9.0a07. (Required for stonebeat).

- All the duplicated packets reach the stonebeat cluster.

- I have a 'snoop' capture of the traffic if anyone wants to have a look.

Thanks in advance for the help.

Darryl Luff

dluff@iitscdm.com.au

[r-simpson]

Your static arp entry is causing this behavior. Find out from Stonesoft if there is a workaround so you can maintain your redundancy. Otherwise, you might have to isolate that cluster to its own interface.

[djluff]

The static ARP is needed because the ciscos dont accept ARP updates linking unicast IP's to multicast MAC's. The only alternativese are to:

- Use hubs instead of switches so there's no need for the multicast MAC, or

- Us static multicast groups/CAM entries/IGMP to limit the traffic to the ports the cluster is on.

The first option is a bit unacceptable these days, and the second is a workaround. But I still can't see why the routers are responding to this traffic thats not addressed to them, at the MAC or IP level?

[r-simpson]

It almost sounds like the router is proxy-arping for that static map entry. Maybe an IOS bug? Does anyone know if this is correct behavior? I guess your second option is the lesser of the two evils.

[frisky]

Not sure if you make any progress, but I was running into a similar issue 2 days back and found something interesting :

1) The switch's CAM do not have that multicast address and will broadcast to EVERY port on that broadcast domain. Which is how the 2nd router got the packet. Note that the copy that the 2nd router gets is in addition to the copy that is forwarded to the stonebeat fullcluster.

2) Why does the router accept the packet is interesting too. I don't have a good answer,

but this could be a resolved caveat as when I tried with another router with a 12.1(11) IOS

it did not accept the packet.

3) If the 2nd router accept the packet, and forward it to the stonebeat cluster MAC address,

that switch will take that packet and broadcast it again, a copy to the stonebeat fullcluster,

and another copy to the 1st router, plus whatever is in the broadcast domain.

4) So every new packet from another segment heading for the stonebeat cluster will be bounced between the 2 routers until TTL expires. And everything time it happens, a copy will be send to the stonebeat fullcluster, probably flooding the connection out from the stonebeat fullcluster.

5) The result is a multicast storm, and if you have any other device that is accepting and retransmiting the packet, the effect will be exponential

6) I guess you can either reconfigure your stonebeat cluster to use IGMP or use

the 'set cam permanent 0900.0ac9.0a07 {mod/port} ' command on the Cat 5500