Troubleshooting ACL and QoS

QoS issues

Traffic failure to match a traffic class

Symptom

When you execute the display qos policy interface command to view the configuration information and running status of the QoS policy on an interface, you find that the current traffic on the interface does not match the traffic classes in the QoS policy.

·     if the Matched field in traffic class 1 is 0 (Packets) 0 (Bytes) in the command output, it means the number of packets that match the traffic class on the interface is 0. In the QoS policy, a default traffic class named default-class exists. All traffic that does not match any other traffic classes in the QoS policy will match the traffic class named default-class.

<Sysname> display qos policy interface gigabitethernet 2/0/1 inbound

Interface: GigabitEthernet2/0/1

  Direction: Inbound

  Policy: 1

   Classifier: default-class

     Matched : 213126 (Packets) 40928738 (Bytes)

     5-minute statistics:

      Forwarded: 20/4208 (pps/bps)

      Dropped  : 0/0 (pps/bps)

     Operator: AND

     Rule(s) :

      If-match any

     Behavior: be

      -none-

   Classifier: 1

     Matched : 0 (Packets) 0 (Bytes)

     5-minute statistics:

      Forwarded: 0/0 (pps/bps)

      Dropped  : 0/0 (pps/bps)

     Operator: AND

     Rule(s) :

      If-match acl 3000

     Behavior: 1

      Marking:

        Remark dscp 3

Common causes

The following are the common causes of this type of issue:

·     The interface that has the QoS policy applied is in down state and is not forwarding traffic.

·     The configuration of a traffic class is incorrect, and it cannot match the forwarded traffic.

·     A higher-priority policy is executed on the traffic matching the ACL in a traffic class of the QoS policy.

Troubleshooting flow

Figure 1 shows the troubleshooting flowchart.

Figure 1 Flowchart for troubleshooting traffic failure to match a traffic class

 

Solution

1.     Identify whether the physical link state of the interface is normal.

Execute the display interface command on the device to check the interface status. For example:

<Sysname> display interface gigabitethernet 2/0/1

GigabitEthernet2/0/1

Interface index: 386

Current state: Administratively DOWN

Line protocol state: DOWN

…

a.     If the Current state field displays Administratively DOWN, execute the undo shutdown command on the interface to bring up the interface.

b.     If the Current state field displays DOWN, check the physical connection of the interface.

c.     If the physical link of the interface is operating normally but the issue persists, proceed to the following steps.

2.     Check the configuration of traffic classes in the QoS policy applied to the device interface.

Execute the display traffic classifier user-defined command on the device to check the configuration of user-defined traffic classes. For more information on the match criteria of the if-match command, see QoS commands in ACL and QoS Command Reference.

If the configuration of a traffic class is incorrect, execute the traffic classifier command to enter the view of the traffic class, and execute the if-match command to modify the match criteria of the traffic class. For example:

[Sysname-classifier-1] if-match dscp ef

[Sysname-classifier-1] display this

 

traffic classifier a operator or

 if-match protocol ipv6

 if-match dscp ef

 

Identify whether the logical relationship among various criteria, which is displayed in the Operator field, is correct. AND means that the criteria in this traffic class are ANDed. In this case, a packet must match all criteria to belong to this class. OR means that the criteria in this traffic class are ORed. In this case, a packet that matches any criterion belongs to this class. If more than one match criterion is in the Rule(s) field and the Operator field displays AND, it means that a packet must match all criteria to belong to this class. In this case, execute the traffic classifier command and set the operator parameter to or.

<Sysname> display traffic classifier user-defined

 

  User-defined classifier information:

 

   Classifier: 1 (ID 101)

     Operator: AND

     Rule(s) :

      If-match dscp ef

 

   Classifier: 2 (ID 102)

     Operator: AND

     Rule(s) :

      If-match dscp af21

 

   Classifier: 3 (ID 103)

     Operator: AND

     Rule(s) :

      If-match dscp af11

If the traffic class in the QoS policy is configured correctly but the issue persists, proceed to the following steps.

3.     When an ACL is referenced for traffic matching in a traffic class, it is possible that the QoS policy configured in MQC method will not take effect because a higher-priority behavior has been executed on the traffic matching the ACL. The priority order for different behaviors is as follows:

¡     In the outbound direction: Packet filtering > Global MQC QoS policy > MQC QoS policy applied to interface.

¡     In the inbound direction: Packet filtering > MQC QoS policy applied to interface > Global MQC QoS policy.

Execute the display current-configuration command to identify whether higher-priority policy behaviors exist in the current running configuration. If no such configurations exist but the issue persists, proceed to the following steps.

4.     If the issue persists, collect the following information and contact Technical Support:

¡     Results of each step.

¡     Configuration data and log messages.

Related alarm and log messages

Alarm messages

N/A

Log messages

·     QOS_POLICY_APPLYIF_CBFAIL

·     QOS_POLICY_APPLYIF_FAIL

Ineffective QPPB policy

Symptom

As shown in Figure 2, in a typical QoS Policy Propagation Through the Border Gateway Protocol (QPPB) environment, Device A and Device B establish a BGP neighbor relationship. Device B sends BGP route 10.10.10.1/24 to Device A. Device A sets the IP precedence or local QoS ID value for BGP route 10.10.10.1/24 through a routing policy and adds it to the routing table of Device A. When Device A receives a packet destined to 10.10.10.1/24, it classifies the packet based on the IP precedence or local QoS ID value in the routing table of Device A and executes the corresponding action.

The QPPB policy does not take effect when Device A forwards packets. The packets are not effectively classified based on the IP precedence or local QoS ID value in the routing table of Device A, and the corresponding action is not executed.

The following section describes the troubleshooting flow in BGP IPv4 unicast address view. The flow is similar for other address family views.

Figure 2 Typical QPPB network

 

Common causes

The following are the common causes of this type of issue:

·     The physical link between routers is not connected.

·     The BGP route has failed to be advertised.

·     The IP precedence or local QoS ID value fails to be issued to the routing table.

·     The QPPB policy has not been applied to the forwarding interface.

·     The configuration of the QPPB policy is incorrect.

Troubleshooting flow

To troubleshoot this type of fault:

·     Identify whether the physical link between routers is operating normally.

·     Identify whether the BGP neighbor relationship has been established normally.

·     Identify whether BGP routes have been learned from the peer.

·     Identify whether the IP precedence or local QoS ID value is properly issued to the routing table.

·     Identify whether the QPPB policy configuration is correct.

·     Identify whether the QPPB policy is applied to the forwarding interface.

Figure 3 shows the troubleshooting flowchart of this type of fault.

Figure 3 Flowchart for troubleshooting ineffective QPPB policy

 

Solution

1.     Check the connectivity of the link between Device A and Device B.

Execute the display interface command on Device A, Device B, and the network devices between them to check the physical link state. View information of the interconnect interface on Device A as an example.

<Sysname> display interface gigabitethernet 2/0/1

GigabitEthernet2/0/1

Interface index: 386

Current state: Administratively DOWN

Line protocol state: DOWN

…

a.     If the Current state field displays Administratively DOWN, execute the undo shutdown command on the interface to bring up the interface.

b.     If the Current state field displays DOWN, check the physical connection of the interface.

c.     If the physical link of the interface is operating normally but the issue persists, proceed to the following steps.

2.     Identify whether the BGP neighbor relationship between Device A and Device B is normal. Device A must be able to learn routes from its BGP peer normally.

a.     Execute the display ip routing-table protocol command on Device A. Identify whether Device A has normally learned BGP route 10.10.10.1/24 from the BGP peer (Device B).

-     If this BGP route appears in the command output, it means BGP routes are learned normally. In this case, proceed to step 3.

-     If this BGP route does not appear in the command output, it means BGP routes are learned abnormally. In this case, proceed to step b.

<Sysname> display ip routing-table protocol bgp

…

Destination/Mask    Proto  Pre  Cost         NextHop         Interface

192.168.80.0/24     bgp    255  10           192.168.80.10   GE2/0/1

10.10.10.1/24       bgp    255  10           2.2.2.2         GE2/0/1

…

b.     Device A and Device B establish a BGP neighbor relationship through their respective Loopback 1 interfaces. By executing the display bgp peer command on Device A, you can identify whether the BGP neighbor relationship between Device A and Device B is normal.

-     If the State field of the peer (Device B) displays Established, it means that the BGP neighbor relationship between Device A and Device B is normal.

-     If not, see the BGP troubleshooting guide to troubleshoot BGP-related issues.

<Sysname> display bgp peer ipv4

 

 BGP local router ID: 1.1.1.1

 Local AS number: 100

 Total number of peers: 1                  Peers in established state: 1

 

 * - Dynamically created peer

 Peer                  AS  MsgRcvd  MsgSent OutQ  PrefRcv Up/Down  State

 

 2.2.2.2               200       13       16    0        0 00:10:34 Established

c.     If the BGP neighbor relationship is normal and Device A can learn the route from the BGP peer normally, proceed to the following steps.

3.     Identify whether the IP precedence or local QoS ID value in the routing table of Device A is correct.

Execute the display ip routing-table ip-address  verbose command on Device A to identify whether the BGP route learned from Device B is configured with the correct IP precedence or local QoS ID value. The command output is as follows:

<Sysname> display ip routing-table 10.10.10.1 verbose

…

 Destination: 10.10.10.1/24

    Protocol: BGP

  Process ID: 0

   SubProtID: 0x1                       Age: 00h00m37s

  FlushedAge: 15h28m49s

        Cost: 0                  Preference: 255

       IpPre: N/A                QosLocalID: 100

         Tag: 0                       State: Active Adv

In the command output, the IpPre field represents the IP precedence value, and the QosLocalID field represents the local QoS ID value. If both of these fields have a value of N/A, it means that the BGP route learned from Device B has not been configured with an IP precedence or local QoS local ID value. Execute the following commands on Device A to add the relevant configuration.

a.     Execute the ip prefix-list command to configure an IPv4 prefix list or an item for the list and permit routes destined to subnet 10.10.10.0/24 and with a mask length of 24.

#

 ip prefix-list 10 index 10 permit 10.10.10.0 24

#

b.     Execute the route-policy command to create a routing policy. In the routing policy, use the if-match ip command to configure the criteria of matching the IPv4 prefix list created above. Then, execute either the apply qos-local-id or apply ip-precedence command to configure the local QoS ID or IP precedence value.

#

route-policy a permit node 10

 if-match ip address prefix-list 10

 apply ip-precedence 1

 apply qos-local-id 100

#

c.     Execute the peer route-policy command in BGP IPv4 unicast address family view to apply the routing policy to the routes from the peer device (Device B).

If the BGP route learned from Device B is configured with the correct IP precedence or local QoS ID value, proceed to the following steps.

4.     Identify whether the QPPB policy configuration is correct.

Execute the display qos policy user-defined command on Device A to view the QPPB policy configuration.

<Sysname> display qos policy user-defined

 

  User-defined QoS policy information:

 

  Policy: aaa (ID 106)

   Classifier: aaa (ID 0)

     Behavior: aaa

      Redirecting:

        Redirect to next-hop 192.168.10.1

a.     Execute the display traffic classifier command to check the traffic class configuration in the QPPB policy. In this example, the Classifier field displays aaa.

<Sysname> display traffic classifier user-defined aaa

 

  User-defined classifier information:

 

   Classifier: aaa (ID 100)

     Operator: AND

     Rule(s) :

      If-match ip-precedence 1

-     If the Rule(s) field displays the If-match ip-precedence rule, make sure the match criteria of the traffic class are consistent with the IP precedence value configured in the previous routing policy.

-     If the If-match ip-precedence match criterion does not exist or if the traffic class configuration is inconsistent with the IP precedence value configured in the routing policy, execute the undo if-match command in traffic class view to delete the original configuration and re-execute the if-match command to configure the match criterion that matches the IP precedence value.

If the configuration of the QPPB policy is correct, proceed to the following steps.

5.     Identify whether the QPPB feature is configured on the packet forwarding interface and a QPPB policy is applied.

On Device A, configure QPPB on the outgoing interface or incoming interface, and apply the QPPB policy to the interface. On this interface, use the display this command to identify whether the configuration is complete. Take the configuration on the incoming interface as an example. The  configuration is displayed as follows:

#

 bgp-policy destination ip-prec-map ip-qos-map

 qos apply policy aaa inbound

#

If any type of the preceding configurations is missing, execute the bgp-policy or qos apply policy command on the interface to add the configuration. If the QPPB policy has already been applied to the packet forwarding interface and the QPPB feature has been configured, proceed to the following steps.

6.     If the issue persists, collect the following information and contact Technical Support:

¡     Results of each step.

¡     Configuration data, log messages, and alarm messages.

Related alarm and log messages

Alarm messages

N/A

Log messages

N/A