Case Study: Multiple STAs Fail or Take a Long Time to Obtain IP Addresses

Symptom

Multiple STAs fail or take a long time to obtain IP addresses. According to the log buffer of the AC, there are a large number of records indicating that STAs fail to obtain IP addresses due to failures in responding to DHCP Offer messages.

Relevant Alarms and Logs

Related log:

Cause Analysis

In scenarios where the tunnel forwarding mode is used or DHCP packets of STAs pass through the AC, broadcast packets are lost on the AC. As a result, the STAs fail or take a long time to obtain IP addresses.

Procedure

1. Run the display cap cpu-usage verbose command in the diagnostic view of the AC to check detailed information about the CPU usage of the forwarding subsystem.

   The default threshold for the CPU usage of the AC forwarding subsystem is 20% for processing broadcast packets and unknown multicast packets. Check whether the sum of BCCycle (for broadcast packets) and UMCCycle (for unknown multicast packets) exceeds 20%. If so, the number of broadcast and multicast packets received by the AC exceeds the processing capability of the AC.

2. Run the display cap ssw error statistics command multiple times in the diagnostic view of the AC to check the value of the SSW_BC_ADD_SCHQUEUE field in the error packet statistics of the SSW module.

   If the value of this field increases rapidly, broadcast and multicast packets fail to enter the queue on the AC and some of the packets are discarded.

3. Take measures such as ACLs to enable the AC to discard unnecessary broadcast and multicast packets, excluding common broadcast and multicast packets such as DHCP, ARP, ND, DHCPv6, and ICMPv6 packets.
   1. Configure ACL rules on the AC.

      acl number 3006  
       description deny mDns between ACs
       rule 5 deny udp source-port eq 5353 destination-port eq 5353 
       rule 15 deny udp destination-port eq 5355 
       rule 20 deny udp destination-port eq 1900 
       rule 25 deny udp destination-port eq 10318 
       rule 30 deny udp destination-port eq 889
      acl ipv6 number 3006  
       rule 5 deny udp source-port eq 5353 destination-port eq 5353 
       rule 6 permit icmpv6 icmp6-type echo 
       rule 7 permit icmpv6 icmp6-type echo-reply 
       rule 8 permit icmpv6 icmp6-type neighbor-solicitation 
       rule 9 permit icmpv6 icmp6-type neighbor-advertisement 
       rule 10 permit icmpv6 icmp6-type router-solicitation 
       rule 11 permit icmpv6 icmp6-type router-advertisement 
       rule 15 permit udp source-port eq 546 destination-port eq 547 
       rule 20 permit udp source-port eq 547 destination-port eq 546 
       rule 25 deny ipv6 destination FF02::/16

   2. Suppress unnecessary broadcast and multicast traffic of STAs.

      traffic-profile name xxx
        traffic-filter inbound ipv4 acl 3006
        traffic-filter inbound ipv6 acl 3006

   3. Suppress unnecessary broadcast and multicast traffic on the AC's physical interface received from the network side.

      traffic classifier deny-mcbc
       if-match acl 3006
       if-match ipv6 acl 3006
      traffic behavior deny-mcbc
       permit
      traffic policy deny-mcbc
       classifier deny-mcbc behavior deny-mcbc
      interface xxx  //AC's physical interface
       traffic-policy deny-mcbc inbound
       traffic-policy deny-mcbc outbound

Suggestion and Summary

Configuring ACLs to suppress broadcast and multicast packets in this case is a remedy for the issue that has occurred. It is recommended that you properly plan VLANs in the network planning phase to prevent a large broadcast domain and also configure port isolation and user isolation to optimize broadcast and multicast traffic.