{"id":1274,"date":"2018-09-06T13:46:12","date_gmt":"2018-09-06T06:46:12","guid":{"rendered":"https:\/\/lagonet.vn\/?p=1274"},"modified":"2018-09-06T13:46:12","modified_gmt":"2018-09-06T06:46:12","slug":"show-interface-in-depth","status":"publish","type":"post","link":"https:\/\/kb.lagonet.vn\/?p=1274","title":{"rendered":"Show interface in depth"},"content":{"rendered":"

In my opinion, a good network engineer must know the \u201cshow interface<\/strong>\u201d in depth; indeed, this command is useful to\u00a0obtain various interface information like drop, duplex mismatch, error, tx\/rx load, \u2026<\/strong><\/p>\n

Usually, the\u00a0IOS<\/strong>\u00a0switch\/router have\u00a0similar \u201cshow interface\u201d output<\/strong>; the differences are dictated by devices, interface and IOS.<\/p>\n

Below a show interface of a\u00a0TenGigabitEthernet interface. The show is issued on a Cisco WS-C6509-E in VSS Mode with IOS version 15.<\/span><\/p>\n

Ciscozine-IOS#sh int te1\/5\/4\nTenGigabitEthernet1\/5\/4 is up, line protocol is up (connected)\n  Hardware is C6k 10000Mb 802.3, address is 0000.0000.fd90 (bia 0008.ef4a.fd90)\n  MTU 1500 bytes, BW 10000 Kbit\/sec, DLY 100 usec,\n     reliability 255\/255, txload 1\/255, rxload 1\/255\n  Encapsulation ARPA, loopback not set\n  Keepalive set (10 sec)\n  Full-duplex, 10Gb\/s, media type is 10Gbase-SR\n  input flow-control is on, output flow-control is off\n  Clock mode is auto\n  ARP type: ARPA, ARP Timeout 04:00:00\n  Last input never, output never, output hang never\n  Last clearing of \"show interface\" counters never\n  Input queue: 0\/75\/0\/0 (size\/max\/drops\/flushes); Total output drops: 0\n  Queueing strategy: fifo\n  Output queue: 0\/40 (size\/max)\n  5 minute input rate 7000 bits\/sec, 8 packets\/sec\n  5 minute output rate 10000 bits\/sec, 11 packets\/sec\n  L2 Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes\n  L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast\n  L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes\n     4495527 packets input, 488522378 bytes, 0 no buffer\n     Received 4460539 broadcasts (1153347 multicasts)\n     0 runts, 0 giants, 0 throttles\n     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored\n     0 watchdog, 0 multicast, 0 pause input\n     0 input packets with dribble condition detected\n     6925984 packets output, 825456963 bytes, 0 underruns\n     0 output errors, 0 collisions, 1 interface resets\n     0 babbles, 0 late collision, 0 deferred\n     0 lost carrier, 0 no carrier, 0 PAUSE output\n     0 output buffer failures, 0 output buffers swapped out\nCiscozine-IOS#<\/pre>\n
TenGigabitEthernet1\/5\/4 is up, line protocol is up (connected)
\n<\/em>Identify if the interface is\u00a0phisically<\/strong>\u00a0up and if the\u00a0protocol<\/strong>\u00a0is up.<\/p>\n
Hardware is C6k 10000Mb 802.3, address is 0000.0000.fd90 (bia 0008.ef4a.fd90)
\n<\/em>Identify the hardware interface and the interface mac-address; the\u00a0BIA<\/strong>\u00a0aka Burned-In (MAC) Address cannot be changed, while the \u201caddress<\/strong>\u201c\u00a0can be changed<\/strong>\u00a0with the command \u201cmac-address 0000.0000.fd90\u201d under the interface configuration mode.
\nRemember:\u00a0When the interface mac address is changed, the arp or mac address table associated to the interface will be \u201clinked\u201d with the custom mac address!<\/p>\n
MTU 1500 bytes, BW 10000 Kbit\/sec, DLY 100 usec<\/em>
\nMTU<\/em>: define the Maximum Transmission Unit. More info\u00a0http:\/\/en.wikipedia.org\/wiki\/Maximum_Transmission_Unit<\/a>
\nBW<\/em>:\u00a0The bandwidth command is\u00a0only<\/strong>\u00a0there to\u00a0communicate<\/strong>\u00a0the\u00a0speed<\/strong>\u00a0of the interface to higher level protocols. Most of the time, a routing protocol needs to know the speed of the interface so it can choose the best route.\u00a0In the case of routing protocols, IGRP, EIGRP, and OSPF all use the bandwidth statement.
\nDLY<\/em>:\u00a0Propagation delay is the delay it takes for information to transmit from one point and be received by another down a line or through the air.\u00a0Delay<\/strong>\u00a0is another number\u00a0used<\/strong>\u00a0by a\u00a0routing protocol<\/strong>\u00a0to decide on the\u00a0\u201cbest\u201d route for traffic. It was intended to be the \u201cdelay\u201d for packets over that path, so a routing protocol could choose the lowest delay path to send packets.<\/p>\n
reliability 255\/255, txload 1\/255, rxload 1\/255<\/em>
\nreliability of the interface as a fraction of 255 (255\/255 is 100 percent reliability), calculated as an exponential average over 5 minutes.
\ntxload\/rxload=Load on the interface as a fraction of 255 (255\/255 is completely saturated), calculated as an exponential average over 5 minutes.<\/p>\n
Encapsulation ARPA, loopback not set<\/em>
\nDefine the interface encapsulation; nowadays, you will see only the\u00a0ARPA. In the past, there were also SAP and SNAP encapsulation.
\nLoopbacks<\/strong>\u00a0are an important part of troubleshooting; they are\u00a0used to isolate the fault<\/strong>\u00a0on and end-to-end circuit (especially when the circuit is down). More info\u00a0http:\/\/www.cisco.com\/\u2026\/tech_note09186a00800c93c4.shtml<\/a><\/p>\n
Keepalive set (10 sec)
\n<\/em>Keepalives<\/strong>\u00a0are used on the routers interfaces\u00a0as hello mechanism<\/strong>\u00a0to check the end to end connectivity to the other end.Routers interface used this mechanism to check the interface status.If you have no keepalive command its means that inerface status check mechansim in disabled and router will not transmit any keepalive packet on the link.<\/p>\n
Full-duplex, 10Gb\/s, media type is 10Gbase-SR<\/em>
\nDefine the physical speed of the interface and if it works in half or duplex mode. The last part of the line defines the type of the media.<\/p>\n
input flow-control is on, output flow-control is off<\/em>
\nFlow-control<\/strong>\u00a0is a mechanics allowing the receiving party of a connection\u00a0to control the rate<\/strong>\u00a0of the sending party. You may see many different implementations of flow-control technologies at different levels of OSI model (e.g. XON\/XOFF for RS232, TCP sliding window, B2B credits for Fibre Channel, FECN\/BECN for Frame-Relay, ICMP source-quench message, etc). More info\u00a0http:\/\/blog.ine.com\/2008\/07\/08\/802-3x-flow-control<\/a><\/p>\n
Clock mode is auto
\n<\/em>This command is supported on the 1Gb\/10Gb transceivers only.
\nIf the clock mode of the near end of a link does not match the clock mode of the far end, the line protocol does not come up.\u00a0The active and passive clock status is determined during the auto negotiation process before the transmission link is established.<\/p>\n
ARP type: ARPA, ARP Timeout 04:00:00
\n<\/em>ARP type defines the encapsulation type of the interface; tipically, for ethernet interface is ARPA. The\u00a0default ARP timeout is 4hours<\/strong>\u00a0but can be customized using the command \u201carp timeout [timeout]\u201d<\/p>\n
Last input never, output never, output hang never
\n<\/em>Last input, output are the number of hours, minutes, and seconds since the last packet was successfully received or transmitted by the interface.
\nNote: This\u00a0counter<\/strong>\u00a0is\u00a0updated<\/strong>\u00a0only<\/strong>\u00a0when\u00a0packets<\/strong>\u00a0are\u00a0process<\/strong>\u00a0switched<\/strong>, not when packets are fast switched.<\/p>\n
Last clearing of \u201cshow interface\u201d counters never
\n<\/em>It\u00a0\u00a0is the last time the clear counters command was issued since the last time the switch was rebooted. The clear counters command is used to reset interface statistics.<\/p>\n
Input queue: 0\/75\/0\/0 (size\/max\/drops\/flushes); Total output drops: 0<\/em>
\nInput queue is the number of packets in the input queue.
\nSize\/max\/drops = the current number of frames in the queue \/ the max number of frames the queue can hold before it must start dropping frames \/ the actual number of frames dropped because the max queue size was exceeded. Flushes is used to count Selective Packet Discard.\u00a0SPD<\/strong>\u00a0is a mechanism that\u00a0quickly drops low priority packets when the CPU is overloaded<\/strong>\u00a0in order to save some processing capacity for high priority packets. The flushes counter in the show interface command output increments as part of selective packet discard (SPD), which implements a selective packet drop policy on the IP process queue of the router. Therefore, it applies to only process switched traffic.
\nThe purpose of SPD is to ensure that important control packets, such as routing updates and keepalives, are not dropped when the IP input queue is full. When the size of the IP input queue is between the minimum and maximum thresholds, normal IP packets are dropped based on a certain drop probability. These random drops are called SPD flushes.
\nTotal\u00a0output drops<\/strong>\u00a0is the number of packets\u00a0dropped<\/strong>\u00a0because the\u00a0output queue is full<\/strong>. A common cause of this might be traffic from a high bandwidth link being switched to a lower bandwidth link or traffic from multiple inbound links being switched to a single outbound link. For example, if a large amount of bursty traffic comes in on a gigabit interface and is switched out to a 100Mbps interface, this might cause output drops to increment on the 100Mbps interface. This is because the output queue on that interface is overwhelmed by the excess traffic due to the speed mismatch between the inbound and outbound bandwidths.<\/p>\n
Queueing strategy: fifo
\n<\/em>First-in, first-out (FIFO<\/strong>) queuing is the\u00a0default<\/strong>\u00a0queuing<\/strong>\u00a0strategy<\/strong>\u00a0that applies to all interfaces with more than 2 Mbps, or, in other words, E1 size or greater interfaces. With the FIFO Queuing strategy, packets are forwarded through the interface in the order that they are received. Other methods can be:\u00a0WFQ,\u00a0CBWFQ, \u2026<\/p>\n
Output queue: 0\/40 (size\/max)<\/em>
\nThe number of packets in the output queue. Size\/max means the current number of frames in the queue\/the max number of frames the queue can hold before it is full and must start dropping frames.<\/p>\n
5 minute input rate 7000 bits\/sec, 8 packets\/sec<\/em>
\n5 minute output rate 10000 bits\/sec, 11 packets\/sec<\/em>
\nThe\u00a0average<\/strong>\u00a0input<\/strong>\u00a0and\u00a0output<\/strong>\u00a0rate<\/strong>\u00a0seen by the interface in the last five minutes. In order to get a more accurate reading by specifying a shorter period of time (to better detect traffic bursts for example), issue the \u201cload-interval <seconds>\u201d interface command.<\/p>\n
4495527 packets input, 488522378 bytes, 0 no buffer
\n<\/em>Packets input: Total number of error-free packets received by the system.
\nBytes: Total number of bytes, including data and MAC encapsulation, in the error-free packets received by the system.
\nNo buffers: Number of received packets discarded because there was no buffer space in the main system. Compare with ignored count. Broadcast storms on Ethernet networks and bursts of noise on serial lines are often responsible for no input buffer events.<\/p>\n
Received 4460539 broadcasts (1153347 multicasts)
\n<\/em>Total number of broadcast or multicast packets received by the interface.
\n<\/em><\/p>\n
0 runts, 0 giants, 0 throttles
\n<\/em>Runts: Number of packets that are\u00a0discarded<\/strong>\u00a0because they are\u00a0smaller<\/strong>\u00a0than the\u00a0minimum<\/strong>\u00a0packet<\/strong>\u00a0size of the medium. For instance, any Ethernet packet that is less than 64 bytes is considered a runt.
\nGiants: Number of packets that are\u00a0discarded<\/strong>\u00a0because they\u00a0exceed<\/strong>\u00a0the\u00a0maximum<\/strong>packet<\/strong>\u00a0size<\/strong>\u00a0of the medium. For example, any Ethernet packet that is greater than 1518 bytes is considered a giant.
\nThrottles: the\u00a0number<\/strong>\u00a0of times the\u00a0receiver<\/strong>\u00a0on the port is\u00a0disabled<\/strong>, possibly because of buffer or processor overload. If an asterisk (*) appears after the throttles counter value, it means that the interface is throttled at the time the command is run.<\/p>\n
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
\n<\/em>Input error: Includes runts, giants, no buffer, CRC, frame, overrun, and ignored counts. Other input-related errors can also cause the input errors count to be increased, and some datagrams may have more than one error; therefore, this sum may not balance with the sum of enumerated input error counts.
\nCRC: Cyclic redundancy checksum generated by the originating LAN station or far-end device does not match the checksum calculated from the data received. On a LAN, this usually indicates noise or transmission problems on the LAN interface or the LAN bus itself. A\u00a0high number<\/strong>\u00a0of\u00a0CRCs<\/strong>\u00a0is\u00a0usually<\/strong>\u00a0the\u00a0result<\/strong>\u00a0of\u00a0collisions<\/strong>\u00a0or a station transmitting bad data.
\nFrame: Number of\u00a0packets received incorrectly<\/strong>\u00a0having a CRC error and a noninteger number of octets. On a LAN, this is usually the result of collisions or a malfunctioning Ethernet device.
\nOverrun: Number of times the\u00a0receiver hardware<\/strong>\u00a0was\u00a0unable to hand received data<\/strong>\u00a0to a hardware buffer because the input rate exceeded the receiver\u2019s ability to handle the data.
\nIgnored: Number of received packets ignored by the interface because the interface hardware ran low on internal buffers. These buffers are different than the system buffers mentioned previously in the buffer description.\u00a0Broadcast storms<\/strong>\u00a0and bursts of noise can\u00a0cause<\/strong>\u00a0the\u00a0ignored<\/strong>\u00a0count to be increased.<\/p>\n
0 watchdog, 0 multicast, 0 pause input<\/em>
\nWatchdog: Number of times watchdog receive timer expired. It happens when receiving a packet with length greater than 2048.
\nPause input: Counter incrementing means that the port is receving pause frame. Pause frame is a packet that tells the far-end device to stop transmitting packets until the sender is able to handle all the traffic\u00a0and clear it\u2019s buffers. It could be caused by a oversubscription of bandwidth, or a burst traffic pattern.<\/p>\n
0 input packets with dribble condition detected<\/em>
\nDribble bit error indicates that a frame is slightly too long. This frame error counter is incremented just for informational purposes; the router accepts the frame.<\/p>\n
6925984 packets output, 825456963 bytes, 0 underruns<\/em>
\nPackets output: Total number of messages transmitted by the system.
\nBytes: Total number of bytes, including data and MAC encapsulation, transmitted by the system.
\nUnderruns: Number of times that the transmitter has been running faster than the router can handle. This may never be reported on some interfaces.<\/p>\n
0 output errors, 0 collisions, 1 interface resets<\/em>
\nOutput errors: Sum of all errors that prevented the final transmission of datagrams out of the interface being examined. Note that this may not balance with the sum of the enumerated output errors, as some datagrams may have more than one error, and others may have errors that do not fall into any of the specifically tabulated categories.
\nCollisions: Number of messages transmitted because of an\u00a0Ethernet collision<\/strong>. A packet that collides is counted only once in output packets.
\nInterface resets:\u00a0Number<\/strong>\u00a0of times an interface has been\u00a0completely<\/strong>\u00a0reset<\/strong>. This can happen if packets queued for transmission were not sent within several seconds. On a serial line, this can be caused by a malfunctioning modem that is not supplying the transmit clock signal, or by a cable problem. If the system notices that the carrier detect line of a serial interface is up, but the line protocol is down, it periodically resets the interface in an effort to restart it. Interface resets can also occur when an interface is looped back or shut down.<\/p>\n
0 babbles, 0 late collision, 0 deferred
\n<\/em>Babbles:\u00a0Babble errors occur due to the transmission of frames in excess of 1518 bytes in size.
\nLate collision: Number of late collisions. Late collision happens when a\u00a0collision<\/strong>\u00a0occurs<\/strong>after<\/strong>\u00a0transmitting<\/strong>\u00a0the\u00a0preamble<\/strong>. The most common cause of late collisions is that your Ethernet cable segments are too long for the speed at which you are transmitting.
\nDeferred: Deferred indicates that the chip had to defer while ready to transmit a frame because the carrier was asserted.<\/p>\n
0 lost carrier, 0 no carrier, 0 PAUSE output<\/em>
\nLost carrier:\u00a0Number of times the carrier was lost during transmission.
\nNo carrier:\u00a0Number of times the carrier was not present during the transmission.
\nPAUSE output: Pause outputs occur when the receiving port is getting overloaded and the so the device sends a pause request to the device connected to the port.<\/p>\n
0 output buffer failures, 0 output buffers swapped out
\n<\/em>Output buffer failures:\u00a0Number of failed buffers and number of buffers swapped out.
\nOutput buffers swapped out:\u00a0If the outbound interface transmit queue is full, then the packet is copied from a\u00a0hardware buffer to DRAM, then copied back to the transmit queue when there is room.<\/p>\n
L2 Switched: ucast: 0 pkt, 0 bytes \u2013 mcast: 0 pkt, 0 bytes<\/em>
\nL3 in Switched: ucast: 0 pkt, 0 bytes \u2013 mcast: 0 pkt, 0 bytes mcast<\/em>
\nL3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
\n<\/em>The output indicates how many packets have been L2 switched on the interface as well as how many packets have been L3 switched in and out of the interface.<\/p>\n
Remember:<\/strong>\u00a0There is a difference between the counter of show interface command output for a physical interface and a VLAN interface. The input packet counters increment in the output of show interface for a VLAN interface when that packet is Layer 3 (L3) processed by the CPU. Traffic that is Layer 2 (L2) switched never makes it to the CPU and is not counted in the show interface counters for the VLAN interface. It would be counted on the show interface output for the appropriate physical interface.<\/p>\n
In NX-OS (Nexus device) the \u201cshow interface\u201d output is\u00a0slightly different than the IOS output, but it is\u00a0it is easy to understand. Below an example:<\/p>\n
Ciscozine-NX-OS# sh interface ethernet 1\/1\nEthernet1\/1 is up\n Dedicated Interface\n  Hardware: 1000\/10000 Ethernet, address: 000d.ecdd.2fc8 (bia 000d.ecdd.2fc8)\n  Description: TERADATA - F4238\n  MTU 1500 bytes, BW 10000000 Kbit, DLY 10 usec\n  reliability 255\/255, txload 1\/255, rxload 1\/255\n  Encapsulation ARPA\n  Port mode is access\n  full-duplex, 10 Gb\/s, media type is 10G\n  Beacon is turned off\n  Input flow-control is off, output flow-control is off\n  Rate mode is dedicated\n  Switchport monitor is off\n  EtherType is 0x8100\n  Last link flapped 5week(s) 6day(s)\n  Last clearing of \"show interface\" counters never\n  30 seconds input rate 51128 bits\/sec, 2 packets\/sec\n  30 seconds output rate 109088 bits\/sec, 15 packets\/sec\n  Load-Interval #2: 5 minute (300 seconds)\n    input rate 78.13 Kbps, 9 pps; output rate 113.67 Kbps, 11 pps\n  RX\n    22236230840 unicast packets  4414705 multicast packets  997021 broadcast packets\n    22241642569 input packets  27905275144675 bytes\n    881597017 jumbo packets  0 storm suppression packets\n    0 runts  0 giants  3 CRC  0 no buffer\n    3 input error  0 short frame  0 overrun   0 underrun  0 ignored\n    0 watchdog  0 bad etype drop  0 bad proto drop  0 if down drop\n    0 input with dribble  0 input discard\n    0 Rx pause\n  TX\n    12574452594 unicast packets  112812737 multicast packets  66330588 broadcast packets\n    12753595920 output packets  5123002661192 bytes\n    1001411772 jumbo packets\n    1 output errors  0 collision  0 deferred  0 late collision\n    0 lost carrier  0 no carrier  0 babble 0 output discard\n    0 Tx pause\n  9 interface resets\n\nCiscozine-NX-OS#<\/pre>\n
References:<\/strong><\/p>\n