The present disclosure relates generally to analysis of occupancy of a buffer in a network device.
In a computer network, data is transmitted from a source to a destination in the form of packets that generally pass through one or more network devices (e.g., switches, routers, firewalls, etc.). During the transmission, certain errors may arise that result in, for example, redundant data being added to the original data, dropped packets, etc. Massively Scalable Data Center and Cloud Computing systems are putting more traffic load on network equipment such that over-provisioned networks are no longer possible. Monitoring of a buffer in a network device is useful to gain knowledge for network administration, analysis, and performance.
Techniques are presented herein to facilitate the monitoring of occupancy of a buffer in a network device. Packets are received at a network device. Information is captured describing occupancy of the buffer caused by packet flow through the buffer in the network device. Analytics packets are generated containing the information. The analytics packets from the network device for retrieval of the information contained therein for analysis, replay of buffer occupancy, etc.
Complete network visibility into buffer occupancy and the ability to replay occupancy via export and post processing is important since network disruptions (e.g., microbursts) can occur at any time. Furthermore, the ability to replay buffer occupancy allows for effective diagnosis of network issues to provide corrective actions. Existing solutions such as port mirroring (i.e., Switched Port Analyzer (SPAN)) do not provide visibility of buffer occupancy. As such, presented herein are techniques for monitoring and replaying buffer occupancy.
Referring now to
Packets 20 arrive at the network device 10 via any of the ports 12(1)-12(N).
Generally, the buffer analytics logic 16 captures information describing occupancy of the buffer 14 caused by packet flow through the buffer in the network device 10, and generates buffer analytics packets 30 containing the information. As will become apparent from the description below in connection with
First, the network device 10 may insert into buffer analytics packets 30 an address for a destination of the buffer analytics packet, e.g., address for any device connected to the network 40, such as collector device 60 having a CPU 62 and memory 64. The network device 10 sends the analytics packet 30 via network 40 to the destination collector device 60, which may be at any location, local or remote from network device 10.
Second, the network device 10 may output the analytics packet 30 to a dedicated port, e.g., port 12(4) of the network device 10 to which a collector device 70 is connected. The dedicated analytics port 12(4) can participate in port channel or fixed port distribution to expand bandwidth to a single or multiple monitor ports. The collector device 70, since it is connected directly to port 12(4), is usually local to the network device 10. The collector device 70 includes a CPU 72 and memory 74.
Third, the analytics packets 30 may be output to the onboard CPU 18 and memory 19 in the network device 10, such that CPU 18 and memory 19 also serve as a collector device. In any of these scenarios, the CPUs 18, 62 and 72 may replay and analyze the occupancy of the buffer 14 based on software instructions stored in its associated memory 19, 64 and 74, respectively. Moreover, the analytics packets are stored in the memory 19, 64 and 74 for the associated CPU 18, 62 and 72, respectively.
The network device 10 can be any network device now known or hereinafter developed, including a switch, router, gateway, a software stack on a host device, virtual network interface cards (VNICs) virtual switches, physical network interface cards (including those that support virtualization).
Memory 19, 64 and 74 may comprise read only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical/tangible memory storage devices. Thus, in general, the memory 19, 64 and 74 may comprise one or more tangible (non-transitory) computer readable storage media (e.g., a memory device) encoded with software comprising computer executable instructions and when the software is executed (by the associated CPU) it is operable to perform the operations described herein.
Reference is now made to
The enqueue analytics packet generator 80 is configured to generate an analytics packet, called an enqueue buffer analytics packet shown at reference numeral 32, that describes/summarizes a packet being enqueued into buffer 14. Similarly, the dequeue analytics packet generator 82 is configured to generate an analytics packet, called a dequeue buffer analytics packet shown at reference numeral 34, that describes/summarizes a packet being dequeued from buffer 14. The packet assembler 88 assembles a packet 20 ready out from the buffer 14 for output from the network device.
The enqueue analytics packet generator 80 captures, for a packet enqueued to buffer 14, information describing one or more of identification of ingress port of arrival of the packet at the network device, Layer 2 source address and destination address, Layer 3 source address and destination address, Layer 4 source address and destination address, class of service, and timestamp of arrival at the ingress port. Similarly, the dequeue analytics packet generator 82 captures, for a packet dequeued from the buffer 14, information describing one or more of identification of egress port for departure of the packet from the network device, Layer 2 source address and destination address, Layer 3 source address and destination address, and timestamp of departure from the egress port.
The enqueue buffer analytics packet 32 generated by the enqueue analytics packet generator 80, dequeue buffer analytics packet 34 generated by the dequeue analytics packet generator 82, and packet 20 output by the packet assembler 88, are all supplied to a corresponding input of the multiplexer 90. The multiplexer 90 selectively outputs, at any given time, either a packet 20, an enqueue buffer analytics packet 32 or a dequeue buffer analytics packet 34. Priority is given to output of a packet 20 in order to maintain proper flow of network traffic through the network device 10. Trigger for output of an analytics packet may be based on time (according to a schedule) or size of a packet enqueued to the buffer or dequeued from the buffer.
Replay of buffer occupancy has several categories, namely the buffer enqueue, buffer dequeue, buffer enqueue drop, and buffer dequeue drop, each having properties to facilitate buffer visibility. The buffer enqueue is defined as any packet that is admitted to the buffer, while buffer dequeue is defined as any packet that is removed from the buffer. Buffer enqueue drop is defined as any packet that is not admitted to the buffer, while buffer dequeue drop is defined as any packet that is admitted to the buffer, but that will be dropped. Recording each of these categories would require enormous bandwidth if a complete packet is captured. However, the entire packet is not necessary for analysis and a replay of the buffer may use specific pieces of information that is of interest to network administrators and application developers.
Therefore, in accordance with examples presented herein, a networking device is configured to filter packets in a network buffer and to generate a “record” for selected packets. Each captured record corresponds to a single buffered packet and is, in essence, a truncation of the packet. The record includes only certain desired information about the packet (i.e. selected information desired by a network administrator).
Examples of record fields can include, but are not limited to: (1) Ethernet packet header information such as media access control (MAC) destination address/source address (DA/SA), Internet Protocol (IP) DA/SA, class of service (CoS), or type of service (TOS); (2) a timestamp of the packet arrival and/or departure to/from the buffer to create replay; (3) a timestamp based on a local or global clock derived from protocols such as Precision Time Protocol (PTP) or Network Time Protocol (NTP); (4) buffer occupancy characteristics such as overall, priority, unicast or multicast queue length; (5) packet properties such as drop, port mirrored, load balanced, bridged or routed, and packet length; or (6) packet error properties such as Cyclic Redundancy Check (CRC), Runt, Giant, and Jabber.
Reference is now made to
The Ethernet header field 110 is field that is used to encapsulate the destination address of the analytics packet, e.g., to direct the analytics packet to a destination, i.e., a local or remote collector device (as indicated in
The common header field 110 contains information captured from the header of a packet that has been enqueued to or dequeued (as the case may be) from the buffer. Thus, the common header field summarizes the header of a packet that is enqueued to and dequeued from the buffer in the network device. For example, the common header field includes information for a common header version (to allow for backward/future compatibility), timescale information representing the timescale of the enqueued or dequeued packet, a timestamp of the packet arrival and/or departure to/from the buffer to allow for replay, a record number to allow a collector to determine how many, if any records, have been lost in between the current analytics packet and the last received analytics packet, and one or more user defined fields such as class of service, type of service, etc.
The record field 120 contains data for an enqueued or dequeued packet that a user configures the buffer analytics logic to capture. Examples of data that may be include in a record field includes:
Format version to indicate a format version of the record field for backward/future compatibility.
L2 Header Fields (MAC SA/DA) or compressed versions (i.e. last 24 bits) and priority
L3 Header (IP SA/DA) or compressed versions (i.e. last 16 bits) and priority and protocol type
L4 Header (TCP/UDP SA/DA)
User defined fields, including one or more of:
Thus, to summarize, the record field 120 for an analytics packet contains information about an enqueued packet or dequeued packet to describe buffer occupancy characteristics such as overall buffer occupancy, buffer occupancy based on packet priority, unicast queue length, multicast queue length; packet properties such as drop, port mirrored, load balanced, bridged or routed, and packet length; and packet error properties such as Cyclic Redundancy Check (CRC), and various error protocols such as Runt, Giant, and Jabber. More specifically, for a packet enqueued to the buffer, information is included in the record field describing one or more of identification of ingress port of arrival of the packet at the network device, Layer 2 source address and destination address, Layer 3 source address and destination address, Layer 4 source address and destination address, class of service, and timestamp of arrival at the ingress port. Similarly, for a packet dequeued from the buffer, information is included in the record field describing one or more of identification of egress port for departure of the packet from the network device, Layer 2 source address and destination address, Layer 3 source address and destination address, and timestamp of departure from the egress port. Other examples of data captured into user defined fields include an indication of a packet being rate limited, shaped, policed as well as any programmable bytes of the packet including payload.
The size of the analytics packet (Ethernet header field, common header field and records) may be the Maximum Transmit Unit (MTU), a switch specific analytics MTU, determined using a time-based method (e.g., analytics packet generated and transmitted at predetermined times), determined based on a selected number of packets, or by other techniques.
Reference is now made to
By generating and exporting analytics packets that summarize properties of packets enqueued to and dequeued from a buffer in a network device, a replay of the buffer may be achieved using specific pieces of information that are of interest to network administrators and application developers. Recording each of these categories would require enormous bandwidth if a complete enqueued or dequeued packet is captured.
In summary, presented herein are techniques that enable a time-based complete replay of the buffer occupancy with resolution determined by a sampling period. These techniques provide visibility of traffic flows received by network devices. The information provided can be used by network administrators to gain insight into their specific network traffic, such as per-packet latency, buffer occupancy, and possible congestion sources. This information can lead to better allocation and provisioning of network resources, reduced congestion, and higher overall throughput. By parsing and aggregating relevant characteristics from each packet according to the techniques presented herein, bandwidth requirements associated with network monitoring are greatly reduced. As such, these techniques assist in reducing the amount of data exported for analysis.
The above description is intended by way of example only.
This application is a continuation of U.S. application Ser. No. 14/707,139, filed May 8, 2015, which in turn is turn is a continuation of U.S. application Ser. No. 13/708,265, filed Dec. 7, 2012, now U.S. Pat. No. 9,077,619, which in turn claims priority to U.S. Provisional Application No. 61/702,320, filed Sep. 18, 2012, entitled “Exporting Real Time Network Traffic Latency and Buffer Occupancy.” The entirety of these applications is incorporated herein by reference.This is an application for reissue of U.S. Pat. No. 9,641,407, and is a divisional of U.S. application Ser. No. 16/400,122, filed May 1, 2019, which is also an application for reissue of U.S. Pat. No. 9,641,407, which is a continuation of U.S. application Ser. No. 14/707,139, filed May 8, 2015, now U.S. Pat. No. 9,509,622, which is a continuation of U.S. application Ser. No. 13/708,265, filed Dec. 7, 2012, now U.S. Pat. No. 9,077,619, which claims the benefit of U.S. Provisional Application No. 61/702,320, filed Sep. 18, 2012.
Number | Name | Date | Kind |
---|---|---|---|
5546389 | Wippenbeck | Aug 1996 | A |
6170022 | Linville | Jan 2001 | B1 |
6192406 | Ma | Feb 2001 | B1 |
6246684 | Chapman et al. | Jun 2001 | B1 |
6333917 | Lyon | Dec 2001 | B1 |
6690646 | Fichou et al. | Feb 2004 | B1 |
6788697 | Aweya | Sep 2004 | B1 |
6853623 | Nederveen et al. | Feb 2005 | B2 |
6892237 | Gai et al. | May 2005 | B1 |
6990202 | Wee et al. | Jan 2006 | B2 |
7106731 | Lin et al. | Sep 2006 | B1 |
7395332 | Gai et al. | Jul 2008 | B2 |
7466703 | Arunachalam | Dec 2008 | B1 |
7474666 | Kloth et al. | Jan 2009 | B2 |
7656818 | Baroudi et al. | Feb 2010 | B1 |
7792130 | Fischer | Sep 2010 | B2 |
7830793 | Gai et al. | Nov 2010 | B2 |
7899048 | Walker et al. | Mar 2011 | B1 |
7961621 | Bergamasco et al. | Jun 2011 | B2 |
7969971 | Gai et al. | Jun 2011 | B2 |
8116307 | Thesayi et al. | Feb 2012 | B1 |
8170025 | Kloth | May 2012 | B2 |
8208389 | Alaria et al. | Jun 2012 | B2 |
8238287 | Gopi | Aug 2012 | B1 |
8274905 | Edwards et al. | Sep 2012 | B2 |
8520522 | Goldman | Aug 2013 | B1 |
8601297 | Abts | Dec 2013 | B1 |
8605588 | Sankaran et al. | Dec 2013 | B2 |
8640036 | Pignataro et al. | Jan 2014 | B2 |
8681806 | Bucknell et al. | Mar 2014 | B2 |
8767551 | Goldfarb et al. | Jul 2014 | B2 |
8817615 | Kutscher | Aug 2014 | B2 |
8964547 | Rygh | Feb 2015 | B1 |
9154452 | Thottan | Oct 2015 | B2 |
9917874 | Luby | Mar 2018 | B2 |
20030007456 | Gupta | Jan 2003 | A1 |
20030081546 | Agrawal | May 2003 | A1 |
20030231596 | Hong | Dec 2003 | A1 |
20040128343 | Mayer | Jul 2004 | A1 |
20050180250 | Suzzoni | Aug 2005 | A1 |
20050182850 | Kohno | Aug 2005 | A1 |
20050240745 | Iyer et al. | Oct 2005 | A1 |
20060062209 | Riley | Mar 2006 | A1 |
20060253900 | Paddon et al. | Nov 2006 | A1 |
20060268847 | Halbraich et al. | Nov 2006 | A1 |
20070201870 | Cohen | Aug 2007 | A1 |
20080049787 | McNaughton | Feb 2008 | A1 |
20080279207 | Jones | Nov 2008 | A1 |
20080285463 | Oran | Nov 2008 | A1 |
20090034416 | Baron et al. | Feb 2009 | A1 |
20090041011 | Sheppard | Feb 2009 | A1 |
20090100040 | Sheppard et al. | Apr 2009 | A1 |
20090171474 | Birze et al. | Jul 2009 | A1 |
20090252040 | Kocaturk | Oct 2009 | A1 |
20100023635 | Labonte | Jan 2010 | A1 |
20100054152 | Foschiano et al. | Mar 2010 | A1 |
20100154033 | Oulai | Jun 2010 | A1 |
20100162399 | Sheleheda | Jun 2010 | A1 |
20100287297 | Lefebvre | Nov 2010 | A1 |
20120093505 | Yeap et al. | Apr 2012 | A1 |
20120120254 | Tan | May 2012 | A1 |
20120215909 | Goldfarb et al. | Aug 2012 | A1 |
20120317276 | Muniraju | Dec 2012 | A1 |
20120327779 | Gell | Dec 2012 | A1 |
20120330804 | Morrill | Dec 2012 | A1 |
20130007223 | Luby | Jan 2013 | A1 |
20130028088 | Do | Jan 2013 | A1 |
20130067034 | Degioanni | Mar 2013 | A1 |
20130155858 | Chen et al. | Jun 2013 | A1 |
20130188482 | Lee | Jul 2013 | A1 |
20130194923 | Basso et al. | Aug 2013 | A1 |
20150244637 | Edsall et al. | Aug 2015 | A1 |
Number | Date | Country |
---|---|---|
2477640 | Aug 2011 | GB |
2008097001 | Aug 2008 | WO |
Entry |
---|
Office Action in counterpart Indian Application No. 201928047007, mailed Dec. 24, 2021, 6 pages. |
English translation of First Office Action and Search Report in counterpart Chinese Application No. 201380048250.6, mailed Nov. 21, 2016, 10 pages. |
English translation of Second Office Action in counterpart Chinese Application No. 201380048250.6, mailed May 2, 2017, 3 pages. |
First Examination Report in counterpart Indian Application No. 444/MUMNP/2015, mailed May 24, 2019, 6 pages. |
Williams, Randy, Arista Networks Inc., “LANZ Streaming Client Configuration”, Dec. 2, 2011, 2 pages. |
Donahue, Gary A., “Arista Warrior”, Chapter 20, ISBN: 978-1-449-31453-8, O'Reilly Media Inc., Oct. 3, 2012, 15 pages. |
Arista Networks Inc., “LANZ—A New Dimension in Network Visibility”, Latency Analyzer (LANZ) Technical Bulletin, Mar. 15, 2011, 5 pages. |
International Search Report and Written Opinion in counterpart International Application No. PCT/US2013/059180, mailed Nov. 28, 2013, 10 pages. |
Cisco Systems, Inc., “Cisco Nexus 3000 Series NX-OS Release Notes, Release 5.0(3)U2(1),” pp. 1-12, Aug. 31, 2011. |
Number | Date | Country | |
---|---|---|---|
61702320 | Sep 2012 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 16400122 | May 2019 | US |
Child | 17329520 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 14707139 | May 2015 | US |
Child | 15285603 | US | |
Parent | 13708265 | Dec 2012 | US |
Child | 14707139 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 15285603 | Oct 2016 | US |
Child | 16400122 | US | |
Parent | 15285603 | Oct 2016 | US |
Child | 17329520 | US |