It may just be the version of IOS my customer is using, but today I came across a bug when trying to capture traffic on a Cisco Catalyst 3750 switch. The most frustrating part is that I’d seen this before, and didn’t record how I got around it last time!
This switch had two uplinks (trunks) – Fa1/0/20-21, one of them (Fa1/0/20) in a spanning-tree blocked state. A PC in Fa1/0/5 was sending continuous pings to another PC, and I wanted to observe (on a Wireshark capturing PC in fa1/0/6) the BPDUs sent and received on the trunks, as well as the ping traffic being transmitted ans received on the trunks. Shouldn’t be too hard – and the following SHOULD work.
Sw(config)#monitor session 1 source interface fa1/0/20 - 21 both Sw(config)#monitor session 1 destination interface fa1/0/6
Without boring you with the details – it simply DOESN’T WORK. I tried changing the trunks to access ports (I was only using the default VLAN) and tried adding encapsulation replicate on the monitor session 1 destination interface fa1/0/6 command – and this gave me some success, but only in one direction (tx) – it seems the both keyword on the monitor session 1 source command has no meaning although the multicasts and broadcasts received on the trunks were being monitored to the destination port.
I could see the pings being transmitted on the active trunk, I could see the BPDUs beging transmitted on both trunks, and I could see the multicast BPDUs being received. I could NOT see the incoming ICMP pings.
IDEA – Let’s add the PC’s port to the mix so we see the ICMP pings being transmitted.
This was a good idea, but only worked if I made port 5 a trunk port, so my config now looked like:
Sw(config)#spanning-tree portfast default Sw(config)#monitor session 1 source interface fa1/0/20 - 21 both Sw(config)#monitor session 1 destination interface fa1/0/6 encapsulation replicate Sw(config)#interface range fa1/0/5 , fa1/0/20 - 21 Sw(config-if-range)#switchport trunk encapsulation dot1q Sw(config-if-range)#switchport mode trunk
I had the spanning-tree portfast default in the config because I was trying to test IEEE 802.1D-2004 (ie the standards based version of rapid-spanning tree and Multiple Spanning Trees) and to make Cisco switches realise that they have Edge Ports (as described in the standard) you have to use this command.
Now my capture was working well apart from the fact I was now also seeing the BPDUs being transmitted on port fa1/0/5 as well as the trunk ports. A filter in Wireshark fixed that.
But alas all was not well when I came to test the rapid-fail over. In spite of the fact that I had enabled portfast default, my rapid fail-over took 30 seconds – it turned out that this was because my port fa1/0/5 was now a trunk port and Cisco doesn’t do portfast on trunks! So port fa1/0/5 was doing the old 1998 30 seconds listening + 30 seconds learning!
Luckily on the 3750 you can over-ride this with the following command applied to fa1/0/5
Sw(config-if)#spanning-tree portfast trunk
Finally, I was able to get a couple of Wireshark captures of IEEE 8021.D-2004 in action. At least the Cisco version (which does have some strange things going on – but that is another topic for another day)