Cisco – How to know if a Cisco switch is handling traffic well

ciscoiscsimonitoringperformanceswitch

I have just read Jeremy's question about 2960-S and iSCSI traffic handling, which drove me to ask this question: We all have lots of switches deployed in distinct infrastructures, how can you know that the traffic is treated well?

I usually check CPU, RAM and system logs but didn't think about buffers.

I used show buffers failures and here is an example of the data:

show buffers failures 
Caller       Pool          Size      When
0x1279AE0   Middle           445    3d19h
0x1279AE0   Middle           446    3d19h
0x1279AE0   Middle           444    3d19h

How can I know on which interface this occurred?

Are there other performance metrics that should be reviewed?

Best Answer

That depends on the switch model you have and it's not that easy.

Smaller Catalyst switches in general use at least two forms of buffer - there's usually a interface-lavel buffer, on the smaller Catalyst (2k/3k) visible in 'show buffers' under the section named 'Interface buffer pools:':

Interface buffer pools:
Syslog ED Pool buffers, 600 bytes (total 132, permanent 132):
   100 in free list (132 min, 132 max allowed)
   11151 hits, 0 misses
RxQ1 buffers, 2040 bytes (total 128, permanent 128):
   4 in free list (0 min, 128 max allowed)
   244594209 hits, 4559839 fallbacks
RxQ2 buffers, 2040 bytes (total 128, permanent 128):
   1 in free list (0 min, 128 max allowed)
   202559241 hits, 1582494 fallbacks, 0 trims, 0 created
   1582494 failures (0 no memory)
...

...and there's "public" area, where CPU is using the buffers as they're punted towards it and need servicing. The "Rx"-level buffers are part of the shared buffer to service all interfaces (on either old, legacy switches like 2950 or newest 2960S/3560X/etc) or a subset of interfaces, belonging to specific port ASIC (like 2960 or 3560/3750/3560E/3750E).

On the 4500 and 6500 in particular it gets messy, as there is a number of pools that packet can go through - input interface (ASIC) buffer, the pool at linecard level (on the 6500 at DFC), at the switch-fabric level and at the end the buffer at Supervisor level. They don't have to be physically separate memory pools, but are often mapped in different commands to different names to ease the troubleshooting process (at which step of the packet walk-through was the packet dropped for example).

Related Solutions

Cisco IOS – How to Capture Traffic on Cisco IOS Switches

The client switchport or the server switchport can be monitored. A third switchport can be configured as a mirror port. This means that this mirror port will receive copies of all packets on the corresponding original port, while the original traffic won't be affected.

For example, on the Catalyst 3560:

Enter configuration mode:
```
conf t
```
Define the source and set the session number:
```
monitor session 1 source interface fa 0/24
```
Here, the session number can be from 1 to 66, you could also specify a VLAN or an ethernet channel. Also, interface ranges such as fa 0/25 - 26 are possible, and interface list, such as fa 0/24,fa 0/26, if you would like to monitor several clients at the same time. Also by repeating the command you can add ports, or remove using no. Mixing ports and VLANs is not possible in the same session, another restriction is that you cannot use a destination port as a source port.
Define the destination port:
```
monitor session 1 destination interface gi 0/1
```
You can use a normal port, but not a VLAN. Similarly to above, a destination port cannot be a source port: a port used here can either be a source or a destination port, and only of one session. Again, you can specify multiple ports like above.
You may want to exit configiration mode and save the config.
You may have a look at your defined session - here multiple ports, tried like above:
```
#show monitor session 1
Session 1
---------
Type                   : Local Session
Source Ports           :
    Both               : Fa0/24,Fa0/25-26
Destination Ports      : Fa0/48,Gi0/1
    Encapsulation      : Native
          Ingress      : Disabled
```
You can see an encapsulation here - optionally you can set it to replicate for replicating the source interface encapsulation method, such as by adding encapsulation replicate after the source interface. Furthermore, you can specify a direction (tx, rx, both), filter VLANs and more. The Ingress: Disabled line means that the switch will not accept any frames presented to it by your capture device on a destination port. For such finer details and for further restrictions and default settings have a look at the command reference of the IOS version of your switch.

Once you configured source and destination port, you can capture the traffic using your laptop connected to the destination port, for example with Wireshark.

The number of source sessions can be limited, for example the 3560 supports a maximum of 2.

After the capturing, don't forget to remove this session configuration.

Cisco – How to block bit torrent traffic with a Cisco ASA

<joke>Unplug it</joke>

Bittorrent clients can (and do) use random ports. Blocking the common ports will only encourage users to move to different ports. Also, the inter-client traffic has supported encryption for some years now -- originally as a means to limit ISP interference -- making the actual p-t-p traffic unrecognizable.

Looking for "info_hash" in the client-tracker communication, while somewhat effective, is also easily defeated. (tor, ssl, vpn, etc.) It also does nothing to stop tracker-less swarms (DHT), peer-exchange (PEX), UDP tracker protocol...

If you've managed to kill 50%, count yourself lucky. This is a game of whack-a-mole you cannot win.

Best Answer

Related Solutions

Cisco IOS – How to Capture Traffic on Cisco IOS Switches

Cisco – How to block bit torrent traffic with a Cisco ASA

Related Topic