This post is regarding the section of the CCIE Blueprint – “1.4.a (iii) Embedded packet capture”. I am jumping out of order with this post, but it came in handy recently, so I figured I’d cover it while it was fresh on my mind. Overall, the idea here is that you as the network admin may want to monitor a certain interface on a switch to see what type of traffic is traversing that link.
Here is a scenario: You have a network and an access switch with multiple host devices connected. The end device is not receiving ICMP replies. You are wondering if the replies are making it back to the access switch or not, thinking their may be a problem with the switch itself. What we will do is the the embedded packet capture features of the switch to monitor the uplink port of the access switch to see if that traffic ever even makes it to the access switch, let alone the end device. The uplink in this example is Fa0/1 and you plug a laptop into Fa0/2. This laptop is what you will run Wireshark on to monitor traffic. The problem is, without using embedded packet capture, you may not see traffic destined or originating from other ports. That’s where the SPAN session comes in. SPAN stands for Switch Port Analyzer. Basically what you an do with a SPAN session is send a copy of the traffic on a certain interface to another interface, allowing that traffic then to be analyzed.
The commands to be entered on the switch are:
SW1(config)#monitor session 1 source ?
interface SPAN source interface
remote SPAN source Remote
vlan SPAN source VLAN
SW1(config)#monitor session 1 source interface fa0/1 both
SW1(config)#monitor session 1 destination interface fa0/2
What this is doing is setting Fa0/1 (the uplink of the switch) as the source or what will be monitored and then Fa0/2 is where the copy of the traffic will be sent. With our laptop and Wireshark on Fa0/2, we could then analyze the traffic easily and quickly. From there, it’s a standard Wireshark session where we could search out applicable IP addresses and or mac addresses. In the hypothetical case that we are using in this example, we could then see if the ICMP reply is even reaching our access switch. If NOT, then we would move upstream to see where the problem with the network traffic is.
Here is a more visual example from the Solarwinds team on how to set this up (skip to 15:40 in the video):