Reset Search
 

 

Article

Pings to IP addresses configured directly on a VDX usually show response times on the order of 1ms but occasionally show response times on the order of 100ms.

« Go Back

Information

 
TitlePings to IP addresses configured directly on a VDX usually show response times on the order of 1ms but occasionally show response times on the order of 100ms.
Symptoms
Pings to IP addresses configured directly on a VDX usually show response times on the order of 1ms but occasionally show response times on the order of 100ms.

Pings never time out due to no response. ICMP echo requests and replies are never lost. Ping responses are only ever delayed for up to 100ms.

TAC examination of non-public log files in supportsave shows log messages with the code "CBR2-5074" and the content "Number of packets per second processed on BPQ 5 exceeded threshold".

Pings routed through the VDX are not affected. Pings to IP addresses configured on ve interfaces on the VDX are affected.

Capture of all the broadcast, unknown unicast, and multicast packets and frames coming out an interface configured for "switchport trunk allowed vlan all" shows over half the BUM traffic for the whole VCS is ARP requests in a single VLAN where the ve interface IP address is configured with a shorter than /24 netmask such as /21.
Environment
  • VDX6940
  • NOS 7.2.0a1
Cause
BPQs (Blade Port Queues) manage traffic that enters an interface destined for the device CPU. All broadcast frames are received and processed by all hosts on a subnet including VDX ve interfaces. Broadcast ARP requests are queued in the relatively high priority queue BPQ5. ICMP echo request pings are queued in the relatively low priority BPQ3.

The CPU prioritizing handling of BPQ5 ARP over BPQ3 ICMP combined with extremely high rate bursts of ARP requests can lead to delays in ping responses.

Occasionally high overall rates of broadcast ARP requests happen more easily and more often the shorter the netmask. A subnet with /21 netmask has eight times the odds of ARP request bursts as a subnet with /24 netmask.
Resolution
Traffic routed through the VDX is not affected. Only traffic to the VDX CPU is affected. As such one option is to ignore delays in responses to pings to VDX ve interface IP addresses.

If the bursts of ARP requests happen to be repeated periodic 1 per second requests from a large number of hosts for a single target host, that is a sign that the large number of hosts are configured to use that target host as some sort of server or destination. In that situation,
removing that target IP address from all client hosts can reduce the bursts of ARP requests that clog up the VDX's BPQ5. If the number of ARP request target hosts is small, configuring the target IPs on any hosts on the network will provide the ARP requesters with a reply that will stop them from flooding the network with ARP requests.

At the network design stage, subnet masks shorter than /24 should generally be avoided. Configuring multiple separate subnets on a single ve interface should also be avoided. Any topology that increases the number of hosts that that can send broadcast frames into a ve interface will also increase the odds of this phenomenon happening.
Additional notes

Feedback

 

Was this article helpful?


   

Feedback

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

Characters Remaining: 255