Cisco N5K-C5010P-BF Troubleshooting Guide - Page 52

Registers and Counters, Identifying drops, Expected/Logical drops

Get Cisco N5K-C5010P-BF - Nexus 5010 Switch PDF manuals and user guides
UPC - 882658212208
View all Cisco N5K-C5010P-BF manuals
Add to My Manuals
Save this manual to your list of manuals

Page 52 highlights

Registers and Counters Chapter 3 Troubleshooting Layer 2 Switching Issues Send document comments to [email protected]. Registers and Counters Identifying drops There are logical and physical causes for the Nexus 5000 to drop a frame. There are also situations when a frame cannot be dropped because of the cut-through nature of the switch architecture. If a drop is necessary, but the frame is being switched in a cut-through path, then the only option is to stomp the Ethernet frame check sequence (FCS). Stomping a frame involves setting the FCS to a known value that does not pass a CRC check. This causes subsequent CRC checks to fail later in the path for this frame. A downstream store-and-forward device, or a host, will be able to drop this frame. Note When a frame is received on a 10 Gb/s interface, it is considered to be in the cut-through path. The following example output shows all discards and drops seen on a given interface, except for queuing drops. The queuing drops may be expected or resulting from errors. (Drops are more common than discards.) Example: switch# show platform fwm info pif ethernet 1/1 ... Eth1/1 pd: tx stats: bytes 19765995 frames 213263 discard 0 drop 0 Eth1/1 pd: rx stats: bytes 388957 frames 4232 discard 0 drop 126 For some commands, you need to know on which chip your port resides. In the following example, the chip is called Gatos. The example shows which Gatos and which Gatos port is associated with ethernet 1/1. switch# show hardware internal gatos port ethernet 1/1 | include instance|mac gatos instance : 7

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
Send document comments to [email protected].
3-10
Cisco Nexus 5000 Series Troubleshooting Guide
OL-25300-01
Chapter 3
Troubleshooting Layer 2 Switching Issues
Registers and Counters
Registers and Counters
Identifying drops
There are logical and physical causes for the Nexus 5000 to drop a frame. There are also situations when
a frame cannot be dropped because of the cut-through nature of the switch architecture. If a drop is
necessary, but the frame is being switched in a cut-through path, then the only option is to stomp the
Ethernet frame check sequence (FCS). Stomping a frame involves setting the FCS to a known value that
does not pass a CRC check. This causes subsequent CRC checks to fail later in the path for this frame.
A downstream store-and-forward device, or a host, will be able to drop this frame.
Note
When a frame is received on a 10 Gb/s interface, it is considered to be in the cut-through path.
The following example output shows all discards and drops seen on a given interface, except for queuing
drops. The queuing drops may be expected or resulting from errors. (Drops are more common than
discards.)
Example:
switch# show platform fwm info pif ethernet 1/1 ...
Eth1/1 pd: tx stats: bytes 19765995 frames 213263 discard 0 drop 0
Eth1/1 pd: rx stats: bytes 388957 frames 4232 discard 0 drop 126
For some commands, you need to know on which chip your port resides.
In the following example, the chip is called Gatos. The example shows which Gatos and which Gatos
port is associated with ethernet 1/1.
switch# show hardware internal gatos port ethernet 1/1 | include
instance|mac
gatos instance
: 7 <- Gatos 7
mac port
: 2 <- Port 2
fw_instance
: 2
Expected/Logical drops
During normal operation, the Nexus 5000 encounters frames that cannot be forwarded based on logical
conclusions.
For example, if you learn a MAC address on a given interface and receive traffic on that interface with
a destination MAC address on the source interface, then you cannot forward the frame. Because it is a
known address and cannot be flooded, you can never send traffic out from where it came. This is a
requirement to avoid looping Layer 2 topologies.
The error counter, shown in the following example, increments when the ingress port is the only port in
the VLAN.
Example (same Gatos instance as in earlier example):
switch# show platform fwm info gatos-errors 7
Printing non zero Gatos error registers:
DROP_SRC_MASK_TO_NULL
9