Reset Search
 

 

Article

VRRP mac address is not learned when a dynamic ACL that blocks VRRP packets is removed after upgrading to 15.7 from 15.3.1

« Go Back

Information

 
TitleVRRP mac address is not learned when a dynamic ACL that blocks VRRP packets is removed after upgrading to 15.7 from 15.3.1
Symptoms
A VRRP mac address is not learned when a dynamic ACL that blocks VRRP packets is removed after a switch upgrades from 15.3.1 to 15.7.

The 'iDALL' dynamic ACL that was blocking VRRP packets is removed from VLAN 1753 after upgrading to 15.7 from 15.3.1.


# sh config acl | inc iDALL
create access-list iDALL " ; " "  deny  ; count iDALL_cnt ;" application "Cli"
configure access-list add iDALL last priority 0 zone SYSTEM vlan v1753_10-64-7-128_26_II_SDNBHT3 ingress
# configure access-list delete iDALL vlan v1753_10-64-7-128_26_II_SDNBHT3


Using an ACL that permits and counts VRRP packets, it's confirmed that they are received on VLAN 1753 as the count increases.

# sh access-list counter 
Policy Name       Vlan Name        Port   Direction  
    Counter Name                   Packet Count         Byte Count           
==================================================================
vrrpcount         v1753_10-64-7-128_26_II_SDNBHT3 *      ingress   
    vrrpcount                       102               
           

It's also confirmed that VRRP packets are processed in the CPU by doing tcpdump and seeing VRRP packets in the capture trace.


# !tcpdump -i Broadcom -evXX
Mcast: 01:05->21:33:45.718720 00:00:5e:00:01:01 (oui Unknown) > 01:00:5e:00:00:12 (oui Unknown), ethertype 802.1Q (0x8100), length 64: vlan 1753, p 0, ethertype IPv4, (tos 0xc0, ttl 255, id 55925, offset 0, flags [none], proto VRRP (112), length 40)
    10.64.7.130 > 224.0.0.18: vrrp 10.64.7.130 > 224.0.0.18: VRRPv2, Advertisement, vrid 1, prio 150, authtype none, intvl 1s, length 20, addrs: 10.64.7.129
        0x0000:  0100 5e00 0012 0000 5e00 0101 8100 06d9  ..^.....^.......
        0x0010:  0800 45c0 0028 da75 0000 ff70 ee5b 0a40  ..E..(.u...p.[.@
        0x0020:  0782 e000 0012 2101 9601 0001 373b 0a40  ......!.....7;.@
        0x0030:  0781 0000 0000 0000 0000 0000 0000 0000  ................


However, the VRRP MAC address doesn't get learned on VLAN 1753. The switch doesn't have the VRRP mac address (00:00:5e:00:01:01) in the fdb table.

# sh fdb vlan v1753
Mac                     Vlan       Age  Flags           Port / Virtual Port List
--------------------------------------------------------------------------------
00:04:96:52:9b:1c v1753_10-64-7-128_26_II_SDNBHT3(1753) 0000  dhm        S   1:5

Total: 3620 Static: 2  Perm: 0  Dyn: 3618  Dropped: 0  Locked: 0  Locked with Timeout: 0
FDB Aging time: 300​


From 'dmesg' output, it's confirmed that the VRRP packets are dropped in software by an ACL rule.

/exos/bin # echo debugMask 0x400 > /proc/net/expkt/debugMask
/exos/bin # dmesg -c
<6>### RCV dev: Broadcom vlanIst 0  PIF 1:5  LIF 0:0  type 2  flags 04000206 Len 64  VRID 0 #####
<6>01 00 5e 00 00 12 00 00 5e 00 01 01 81 00 ea c0
<6>08 00 45 c0 00 28 14 d9 00 00 ff 70 30 bc 0a 3c
<6>8a c2 e0 00 00 12 21 01 96 01 00 01 b3 fe 0a 3c
<6>8a c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<6>
<6>expkt_rcv_pkt.(4252) ingress lif:88e6cbc0 vManPort:0 vmanEthertypeAttr:0 vManInstalled:0 vManId:0 vpifAtcktCount:0
<6>chkHwInsertedTag.(3717) HAL_ORIGINAL_PKT_UNTAGGED:0  HAL_ORIGINAL_PKT_TAGGED:512  PKT_TAG:1753  TAGGED_PKT:1
<6>expkt_rcv_pkt.(4520) Regular packet classification. (1) expktGetIngressVpif():88d296a0
<6>expkt_rcv_pkt.(4522) lif ->vManPort:0  ->vManId:0   ->vpifAtcktCount:0
<6>expkt_rcv_pkt.(4529) Found vpif (88d296a0) on 1st try! port:256:1 vpifVid:1753 vlName:v1753_10-64-7-128_26_II_SDNBHT3 vlId:1753  vlType:3 vlInst:1000177  vManMode:0 atcktPtr:00000000
<6>expkt_rcv_pkt.(4749) expkt_rcv_pkt:4749 skb protocol 800
<6>### RCV dev: v1753_F42F1 vlanIst 1000177  PIF 1:5  LIF 256:1  type 2  flags 04000206 Len 64  VRID 2 #####
<6>01 00 5e 00 00 12 00 00 5e 00 01 01 81 00 0a c0
<6>08 00 45 c0 00 28 14 d9 00 00 ff 70 30 bc 0a 3c
<6>8a c2 e0 00 00 12 21 01 96 01 00 01 b3 fe 0a 3c
<6>8a c1 00 00 00 00 00 00 00 00 00 00 00 00 00 00
<6>
<6>expkt_rcv_pkt.(4874) ACL dropping data pkt
<6>expkt_rcv_pkt.(5630) Drop the packet without forward or pass up
Environment
  • EXOS 15.3.3.5-patch1-9 or earlier
Cause
In EXOS 15.7, dynamic ACL rules should get installed with the policy index value of 1 in the xml configuration file. However, when a switch upgrades from EXOS 15.3.1 to 15.7, the policy index is set to the incorrect value of 0 and from this point, dynamic ACL rules are not properly deleted from a switch due to an improper policy index value in the xml configuration file.
 

<aclRuleAppl><aclIfDirection>0</aclIfDirection><ruleName><![CDATA[iDALL]]></ruleName><vlanIfInstance>1000717</vlanIfInstance><applName><![CDATA[Cli]]></applName><application>1</application><polIndex>0</polIndex><priority>0</priority><ruleAction>2</ruleAction><vlan><![CDATA[v1753_10-64-7-128_26_II_SDNBHT3]]></vlan><zone><![CDATA[SYSTEM]]></zone></aclRuleAppl>
 
 
Resolution
Please upgrade to a patch version which contains the fix for CR xos0064490. The fix will be available in the following releases. 

CR xos0064490: Dynamic ACL rule installed in higher virtual slice after upgrading from EXOS 15.2 to higher version.

EXOS 15.6.5-GA-Sep16
EXOS 15.7.4
EXOS 16.1.3-GA-Jul16
EXOS 15.3.5-GA-Aug16
EXOS 21.1.1-GA-Jun16

The workaround is either to reboot a switch after removing and re-adding dynamic ACLs, or to re-create VLANs and re-apply ACL rules back to VLANs when dynamic ACL rules are applied on a VLAN basis.


 
Additional notes
Policy index indicates the priority given to a specific ACL rule. The priority is 0 for user ACL and 1 for dynamic ACL. The priority 0 will have higher precedence than 1.

The policy index (polIndex) was introduced in EXOS 15.3.1.1 via PD4-3282852001. But, it doesn't seem to take effect due to software defects. Further changes were done via a group of software defects (PD4-4570039892, PD4-4573804222 and PD4-4573728051) committed in EXOS 15.3.3.5-patch1-10. An upgrade from EXOS 15.3.3.5-patch1-9 or lower version to any higher version will cause a dynamic ACL configuration to be hit by CR xos0064490.

Feedback

 

Was this article helpful?


   

Feedback

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

Characters Remaining: 255