GS2000 Packet Counters |
Introduction |
This document provides an overview of the GS2000 packet counters and the effect of packets on counters as packets flow through the GS2000 line card. |
Packet Counter Overview |
The GS2000 line card contains packet counters that allow you to observe the amount and types of traffic being processed. The counters keep track of sent and received traffic, in categories that indicate how many packets have reached various outcomes (terminated, dropped, bridged, routed, flooded, fragmented, and so on). Packet counters exist at four internal layers to help you trace packets as they flow within the GS2000:
When a packet is received by an entity within a layer, the packet is either dropped, processed, or passed on to one or more entities within the next layer. Dropped packets cause an error counter within that layer to increment. In some situations, such as bridge ports and interfaces, entities are tightly coupled and dropped packets can increment error counters in two layers. The effects of the packets are not seen in counters at any layers it does not reach. Packets that are successfully processed at a layer increment non-error counters within that layer. Packets sent to the next layer increment non-error counters in that subsequent layer as well. Figure 1 illustrates the logical interface and bridge port layers and shows the relationships between logical interfaces and bridge ports. The figure shows which counters are incremented for the various paths a packet can take within a GS2000.
|
Packets arriving at the GS2000 line card enter the physical interface and can then travel through each of the four layers. Physical interfaces are the connection jacks for cables, and have a one-to-one or one-to-many (in the case of an ATM physical interface) relationship with interfaces. Logical interfaces, (shown as circles in Figure 1), are the lowest layer where counters are used. All packets received and sent are counted by logical interface counters. Error counters for interfaces catch some basic types of errors appropriate to the level of decoding the packet has undergone at this point (for example, a bad FCS) or other errors that are not necessarily associated with a specific higher-level protocol (for example, buffer overflow). If such an error is detected on an interface, the packet being sent or received is discarded, and the appropriate interface error counter is incremented. Otherwise, it is passed to a bridge port (where bridging runs on all interfaces). Packets arriving at a bridge port (dark triangle in Figure 1) are first subject to the effects of bridging. They may be dropped for numerous reasons (destination address filtering, STP port state, and so on), each of which causes a single bridge error or increment a dropped packet counter for that port. If a packet is not dropped, its destination address determines whether it is unicast to another port, flooded out all ports, terminated, and/or delivered to routing. If the packet is bridged out other ports, the bridge attempts to translate and enqueue the packet for sending, if necessary. A failure in this process causes a dropped packet and the error counter increments for the received port. A success means that the packet is sent out other ports and counted by them as well. If a received packet is not dropped or sent out by bridging, it is terminated (such as an STP BPDU) and/or submitted to routing. VLAN interfaces (VIs) receive all packets destined to routing. VIs, which are groups of bridge ports, are paired one-to-one with VLANs. VIs submit packets for routing on behalf of any ports within their VLAN. VI counters keep track of the total number of packets submitted to routing from their VLAN. Outbound packets sent by routing also go through a VI for transmission on a VLAN. VI transmit counters increment once for each packet sent by routing, although multiple packets may be sent on one or more ports (whose counters are incremented as well). Packets sent or received on VIs cannot be dropped by the VI. All errors, overflows, and so on, at the router layer are detected and counted in other layers.Packets reaching the router may be terminated and are counted by routing. The GS2000 IP counters count transmitted, received, and error packets across all VIs and do not display this information on a per-VI basis. |
Counter Relationships |
Some simple relationships exist between interface counters, bridge port counters, and VI counters. For a given packet in Figure 1, the following relationships exist. Refer to the Interface Counters and Bridge Port Counters sections for a complete list of the counters. Example 1 (Unicast packets received + Multicast packets received = Total frames received by the interface) Example 2 (Total frames received by interface ³ Frames submitted to bridging.) Some packets received on an interface may be dropped before being submitted to bridging. Example 3 (Frames submitted to bridging ³ Frames submitted to routing) Only some packets submitted to bridging will be submitted to routing. The rest are either dropped or bridged. Example 4 (Frames submitted to routing £ Unicast packets received + Multicast packets received) The packets submitted to routing by a port's VI may represent only a portion received by that VI since the VI's VLAN may contain other ports. Example 5 Unicast packets transmitted + Multicast packets transmitted £ Translation failures Some packets sent by bridging may be dropped at the interface layer. |
Interface Counters |
Table 1 describes each interface counter (IC) associated with the GS2000. Interface counters IC1A, IC2A, IC3A, and IC4A are identical to IC1, IC2, IC3, and IC4, except the A counters represent VI counters. |
Counter Number |
Name and Definition |
IC1,IC1A* |
Unicast packets received Unicast packets received on an interface. |
IC2,IC2A* |
Multicast packets received Multicast packets received on an interface. |
IC3,IC3A* |
Unicast packets transmitted Unicast packets transmitted on an interface. |
IC4,IC4A* |
Multicast packets transmitted Multicast packets transmitted on an interface. |
IC5 |
Input overflow drops Input queue overflows on an interface (received packet is dropped). Note: Some of these packets may be counted in bridge port counters BC14 and BC15. |
IC6 |
Input error drops Invalid packets/errored packets received on an interface (packet is dropped). Examples of this are packets which are of an invalid length (are shorter than the length given within the packet or are too short to contain the required packet fields). |
IC7 |
Input unknown protocol drops Packets received on an interface which are destined to an unknown protocol (packet is dropped). |
IC8 |
Input congestion control drops Packets received on an interface which were flow controlled (dropped) due to congestion on the packet's receive and transmit interfaces. Note: Some of these packets may be counted in bridge port counter BC22 as well. |
IC9 |
Output overflow drops Outbound packets dropped on an interface due to an output queue overflow. Note: Some of these packets may be counted in bridge port counter BC22 as well. |
IC10 |
Output error drops Outbound packets dropped on an interface because of one of the following:
Note: Some of these packets may be counted in bridge port counters BC23 and BC24 as well. |
Bridge Port Counters |
Table 2 lists and describes the bridge port counters. For most of the dropped packet counters, note that the counter is incremented only if the packet dropped completely-meaning that it is not sent out any ports. For example, assume the case that a packet arrives with an unknown DA and requires flooding and translation to other ports. If the packet can be succesfully sent out at least one of these ports, counters BC9, BC10, BC11, BC12, BC13, BC14, BC15, and BC16 will not be incremented. Counter BC20, however, will be incremented if the packet fails to make it out at least one port. |
Counter Name |
Name and Description |
BC1 |
Port restarts Number of times this bridge port's associated interface has passed a self-test, indicating that the port has restarted. |
BC2 |
Total frames received by interface Number of packets recieved on this bridge port's associated interface (including those eventually discarded due to errors). This is the same as the sum of unicast and multicast packets received on the ports associated interface. |
BC3 |
IP frames fragmented Number of IP packets received on this port's associated interface that were fragmented due to a smaller frame size on the transmit interface's datalink. |
BC4 |
IP frames not fragmented Number of IP packets received on this port's associated interface that bridging attempted to fragmnet but could not because the DONT_FRAGMENT bit was set in the IP header. These packets were discarded. |
BC5 |
Frames submitted to bridging Number of packets received on this bridge port. This includes packets that may eventually be bridged, routed, filtered, or dropped. |
BC6 |
Frames submitted to routing Number of IP packets received on this port's associated interface that were delivered to routing. |
BC7 |
Frames with unknown destination address The number of packets received on this bridge port for which the bridge's forwarding database had no destination address. |
BC8 |
Frames causing learning transactions Number of packets recieved on this bridge port whose source address (SA) is not learned or was known on another port and thus caused a learning transaction. |
BC9 |
Source address filter drops Number of packets completely dropped (not sent out any port) because of their source address. A packet's source address (SA) can be filtered for two reasons:
|
BC10 |
Destination address filter drops Number of packets completely dropped (not sent out any port) because of their destination address. A packet can be filtered for one of two reasons:
|
BC11 |
Protocol filter drops Number of packets completely dropped (not sent out any port) because of a user-configured protocol filter. |
BC12 |
Address rate limiting drops Number of packets completely dropped (not sent out any port) because of a user-configured limit on the number of packets per second that may be sent to the destination address (DA). |
BC13 |
Protocol rate limiting drops Number of packets completely dropped (not sent out any port) because of a user-configured limit on the number of packets per second that may be sent with this protocol type. |
BC14 |
Input buffer overflows Number of packets completely dropped (not sent out any port) due to a lack of input buffers. Note: Some of these packets may be counted in interface counter IC5 as well. |
BC15 |
Input queue overflows Number of packets completely dropped (not sent out any port) due to congestive input loss. Note: Some of these packets may be counted in interface counter IC5 as well. |
BC16 |
Source or destination port blocked drops Number of packets completely dropped (not sent out any port) due to either the source or destination port not being in the forwarding state. |
BC17 |
Terminating queue overflows Number of terminating packets dropped because of an overflow in the termination queue. |
BC18 |
Fragmentation queue overflows Number of packets received with a known unicast destination address (DA) which were dropped because they required fragmentation before being sent out the transmit port, and the fragmentation queue overflowed. |
BC19 |
Translate flood queue overflows Number of packets received that needed to be flooded to multiple ports, some of which required translation, but were not successfully sent out all ports due to an overflow in the translate flood queue. |
BC20 |
Translation failures Number of packets completely dropped (not sent out any port) because the packet could not be translated to a different data link. For example, the length of the packet was less than the minimum required for the received data link. |
BC21 |
Frames sent by bridging Number of packets transmitted on this bridge port. This includes packets that were bridged from other ports as well as locally originated (including routed) packets. It includes packets that may eventually be dropped at the bridge port's associated interface, but not packets that were dropped by the bridge port itself. |
BC22 |
Transmit queue overflows Number of packets that were dropped and not sent on this bridge port due to an overflow in the transmit queue. |
BC23 |
Transmit errors Number of packets that were dropped and not sent on this bridge port due to an error in transmission. Note: Some of these packets may be counted in interface counter IC10. |
BC24 |
Too big to send on port drops |
Number of packets that were dropped and not sent on this bridge port because they were too large. The packet was not fragmented due to one of the following:
Note: Some of these packets may be counted in interface counter IC10 as well. |
Counter Relationships |
Some simple relationships exist between interface counters, bridge port counters, and VI counters. For a given packet in Figure 1, the following relationships exist. Receive Relationships Example 1 Sum of the unicast and multicast packets received on an interface total all of them. Example 2 Some packets received on an interface may be dropped before being submitted to bridging. Example 3 Only some packets submitted to bridging will be submitted to routing. The rest are either dropped or bridged. Example 4 The packets submitted to routing by a port's VI may represent only a portion received by that VI since the VI's VLAN may contain other ports. Transmit Relationships Some packets sent by bridging may be dropped at the interface layer. |
Management Interfaces |
The counters supported on the GS2000 can be viewed through various screens on the CLI. These CLI displays are shown below with the counters (IC* and BC*) labeled. |
CLI Example 1 Monitor>statistics |
Ifc Name | Unicast | Multicast | Packets |
Pkts Rcv | Pkts Rcv | Trans | |
0 VLAN/0 | 2 | 0 | 362 |
1 ATM/2 | 2 | 0 | 2 |
2 ATM/3 | 2 | 0 | 2 |
3 ATM/4 | 2 | 0 | 2 |
4 ATM/5 | 4 | 12 | 6 |
5 ATM/6 | 2 | 0 | 2 |
6 ATM/7 | 3 | 0 | 3 |
7 ATM/8 | (IC1) 3 | (IC2) 0 | (IC3)+(IC4) 3 |
8 ATM/9 | 3 | 0 | 3 |
9 ATM/10 | 3 | 0 | 3 |
10 ATM/11 | 3 | 0 | 3 |
11 ATM/12 | 3 | 0 | 3 |
12 ATM/13 | 3 | 0 | 3 |
13 E100/14 | 3 | 0 | 3 |
14 E100/15 | 3 | 0 | 3 |
15 VLAN/16 | 0 | 0 | 0 |
16 VLAN/17 | 0 | 0 | 0 |
Monitor> |
IC* = Interface Counters |
Example 2 |
Monitor>error |
Input Discards | Input Errors | Input Unk Proto | Input Flow Drop | Output Discards | Output Errors | |
Nt Interface | ||||||
0 VLAN/0 | 0 | 0 | 0 | 0 | 0 | 0 |
1 ATM/2 | 1 | 0 | 0 | 0 | 0 | 0 |
2 ATM/3 | 1 | 0 | 0 | 0 | 0 | 0 |
3 ATM/4 | 1 | 0 | 0 | 0 | 0 | 0 |
4 ATM/5 | 8 | 0 | 0 | 0 | 0 | 0 |
5 ATM/6 | 1 | 0 | 0 | 0 | 0 | 0 |
6 ATM/7 | 2 | 0 | 0 | 0 | 0 | 0 |
7 ATM/8 | 2 | 0 | 0 | 0 | 0 | 0 |
8 ATM/9 | (IC5)2 | (IC6)0 | (IC7)0 | (IC8)0 | (IC9)0 | (IC10)0 |
9 ATM/10 | 2 | 0 | 0 | 0 | 0 | 0 |
10 ATM/11 | 2 | 0 | 0 | 0 | 0 | 0 |
11 ATM/12 | 2 | 0 | 0 | 0 | 0 | 0 |
12 ATM/13 | 2 | 0 | 0 | 0 | 0 | 0 |
13 E100/14 | 0 | 0 | 0 | 0 | 0 | 0 |
14 E100/15 | 0 | 0 | 0 | 0 | 0 | 0 |
15 VLAN/16 |
Monitor>int stat 0 |
Self-Test | Self-Test | Maintenance | |
Ifc Ifc' Name | Passed | Failed | Failed |
0 0 VLAN/0 | 2 | 1 | 0 |
----------------------------------------- | |
Total Receive Frames: | 2 |
Terminated Rcv Mcast Frames: | 0 (IC2) |
Terminated Rcv Ucast Frames: | 2 (IC1) |
----------------------------------------- | |
Total Transmit Frames: | 1737 |
Terminated Xmt Mcast Frames: | 1735 (IC4) |
Terminated Xmt Ucast Frames: | 2 (IC3) |
----------------------------------------- | |
Clock Failure Errors: | 0 |
Receive Start Cell Errors: | 0 |
Receive Cell Parity Errors: | 0 |
----------------------------------------- | |
Transmit Interface Errors: | 0 |
Transmit Cell Parity Errors: | 0 |
DME Abort Cell Errors: | 0 |
----------------------------------------- |
Monitor> |
IC* = Interface Counters |
Input statistics: | |||
failed, frame too long | 0 | failed, FCS error | 0 |
failed, alignment error | 0 | failed, FIFO verrun | 0 |
runts | 0 | packets missed | 0 |
internal hardware errors | 0 |
Output statistics: | |||
deferred transmission | 0 | single collisions | 0 |
multiple collisions | 0 | total collisions | 0 |
excess collisions | 0 | failed, FIFO underrun | 0 |
failed, carrier sense err | 0 | SQE test err | 0 |
late collision | 0 | internal hardware errors | 0 |
MAU Status: | |
connector | RJ45 s |
type | 10BASE-T HALF DUPLEX |
state | OPERATIONAL |
media available state | NOT AVAILABLE |
media avail state exits | 0 |
jabber state | NO JABBER |
jabber state enters | 0 |
false carriers | 0 |
Monitor> |
Example 3 |
BRIDGE>list count port 2 |
Port restarts: | 0 (BC1) |
Total frames received by interface: | 2 (BC2) |
IP frames fragmented: | 0 (BC3) |
IP frames not fragmented: | 0 (BC4) |
Frames submitted to bridging: | 2 (BC5) |
Frames with unknown dest address: | 0 (BC7) |
Frames causing learning transactions: | 0 (BC8) |
Dropped, source address filtering: | 0 (BC9) |
Dropped, dest address filtering: | 0 (BC10) |
Dropped, protocol filtering: | 0 (BC11) |
Dropped, address rate limiting: | 0 (BC12) |
Dropped, protocol rate limiting: | 0 (BC13) |
Dropped, input buffer overflow: | 0 (BC14) |
Dropped, input queue overflow: | 0 (BC15) |
Dropped, source or dest port blocked: | 1 (BC16) |
Dropped, terminating queue overflow: | 0 (BC17) |
Dropped, fragmentation queue overflow: | 0 (BC18) |
Dropped, translate flood queue overflow: | 0 (BC19) |
Dropped, translation failure: | 0 (BC20) |
Frames sent by bridging: | 2 (BC21) |
Dropped, transmit queue overflow: | 0 (BC22) |
Dropped, transmit error: | 0 (BC23) |
Dropped, too big to send on port: | 0 (BC24) |
BRIDGE> |
IC* = Interface Counters |
BC* = Bridge Port Counters |