Reset Search
 

 

Article

Local multicast (224.0.0.x) packet loss

« Go Back

Information

 
TitleLocal multicast (224.0.0.x) packet loss
Symptoms
  • HSRP flapping or dual master
  • VRRP flapping or dual Master
  • OSPF neighbor loss (temporary)
  • EIGRP neighbor loss (temporary)
Environment
  • EXOS All
  • Local group multicast 224.0.0.0/24
  • VRRP/HSRP/EIGRP/OSPF or any other protocol using 224.0.0.x multicast IP
  • L2 vlan
Cause
Exos switches periodically clear the Hardware multicast entries for the 224.0.0.0/24 range to keep track of the router ports.
When the entry is deleted the next packet will be inspected by the CPU after which the hardware entry will be programmed again.
There are situations where this can cause a short traffic disruption (ie during the programming of the multiple asics).

When this happen some hello packets can be dropped causing a short neighbor loss. For example on VRRP this could cause the backup to not see the master and assume master role, it will resume in backup again after it receives the hello from the master again, during the loss timeframe there is a dual VRRP master on the network.

This happens only for protocols using the control multicast packet range, 224.0.0.0/24.
Resolution
The first bullet option is the preferred method and should work for almost all implementations.
  • Changing the way multicast router ports are learned. Instead of learning router ports from any IP routing protocol the router port is detected only from multicast routers running PIM, DVMRP or CBT. Because the router port is learned in a different way there is no need to delete the HW entry which results in lossless l2 multicast forwarding for 224.0.0.0/24 group.
enable igmp snooping forward-mcrouter-only [VR <VR>]
  •  If there is an IP address on the vlan where the protocol control packets are forwarded in CR xos0053644 would apply and using an EXOS version that includes this fix would be the solution together with configuring below setting configure forwarding ipmc local-network-range fast-path3) If there are no routing protocols or VRRP configured on the ports where the protocol control packets are coming in we can configure IPMC to not periodically copy to the cpu:
configure ipmc to-cpu off port <PORT-LIST>
  • Disable igmp snooping for the customer vlans. Be aware of the fact that if you have more vlans configured on the same ports igmp snooping needs to be disabled on all these vlans or you must configure igmp snooping filters to per-vlan.
disable igmp snooping <VLAN>
configure igmp snooping filters per-vlan
  • Last option is a redirect ACL. We need to use an ACL action that has a higher priority than permit to overrule any system ACL. Be aware that older switches like X450 do only support redirect-port to only 1 port and not to multiple ports. Newer hardware like X460 can redirect to a port-list.
For example for EIGRP (224.0.0.10):
entry one {
 if {
  source-address 10.1.1.1/32;
  destination-address 224.0.0.10/32;
 }
 then {
  redirect-port 47;
 }
}

On switches where redirect-vlan is possible as action (All current EXOS versions) this is a better action as it will flood to all ports in the vlan. The ACL would look like:
entry one {
 if {
  source-address 10.1.1.1/32;
  destination-address 224.0.0.10/32;
 }
 then {
  redirect-vlan;
 }
}
Additional notes
Although the first option is the preferred method, experiences in the field showed that the command to turn of IPMC to-cpu  (option 2) is more effective.

Feedback

 

Was this article helpful?


   

Feedback

Please tell us how we can make this article more useful.

Characters Remaining: 255