Reset Search
 

 

Article

VRRP flaps are observed on a specific VLAN when a policy is being applied on the VLAN

« Go Back

Information

 
TitleVRRP flaps are observed on a specific VLAN when a policy is being applied on the VLAN
Symptoms
After applying specific policy to a VLAN, the VRRP flaps are noticed for that VLAN. 
entry rule1 {
if match all {
    destination-address 224.0.0.18/32 ;
}
then {
    permit  ;
  count vrrp ;
}
}
entry rule2 {
if match all {
    source-address 0.0.0.0/0 ;
}
then {
    deny  ;
    count deny ;
}
}
Environment
  • Summit 
  • Black diamond
  • All EXOS version 
  • Issue seen only with specific configuration and the user rules in the policy. 
Cause
  • The VRRP flaps are observed due to contradictions between user ACL rules and the system ACL rules. 
  • The user rules and few other multicast system ACLs are placed in different hardware slices conflicting with each other by which the action to lift the VRRP hello to CPU gets nullified resulting in hardware flooding of the VRRP hellos. 
  • When the device is in backup state and when the VRRP packets are not processed by the CPU it is considered as missed hellos for 3 seconds transitioning itself to be a master node.
  • When the device transitions to be a master node the system ACL to lift the VRRP advertisement to the CPU would be removed.
  • Thus contradictions with multiple rules in different slices does not exist now and hence the VRRP hellos are processed as expected. Since the other node has higher priority, this switch would transition itself back to being a VRRP backup.
  • In this stage (VRRP Backup), the system ACL to lift the VRRP packets to the CPU gets reinstalled and the above steps repeat causing the VRRP state to flap continuously. 
Resolution
Option 1: Re-arrange the order of user's conflicting rules in policy file such that both the rules gets installed in the same slice.
entry rule1 {
if match all {
    source-address 0.0.0.0/0 ;
    destination-address 224.0.0.18/32 ;
}
then {
    permit  ;
}
}
entry rule2 {
if match all {
    source-address 0.0.0.0/0 ;
}
then {
    deny  ;
    count deny;
}
Option 2: Add “copy-cpu-and-drop” action to user ACL.
  • The drawback of this is solution would result in VRRP packets received on that VLAN being slow-path forwarded. 
entry rule1 {
if match all {
    source-address 0.0.0.0/0 ;
    destination-address 224.0.0.18/32 ;
}
then {
copy-cpu-and-drop;
}
}

 
Additional notes

Feedback

 

Was this article helpful?


   

Feedback

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

Characters Remaining: 255