2950 monitor session

I believe at the end of the destination you need the 'ingress' stated.

monitor session 1 dest int fa0/12 ingress

Check the docs to be sure though, not sure if that is enabled on the switch/version you are running.

Ideally you would install another $20 nic in the machine. That way your sniffer won't have to differentiate between the target traffic and its own traffic. The other reply contains an optional method.

Lance,

The answer is yes, you will need a second NIC. Unfortunately, that's just the way it works: when you configure a port for monitoring with the SPAN feature, that port receives copy of the traffic to/from the source port and nothing else... it is no longer an "operational" port. I believe it is removed from the switch's forwarding table (no MAC address table maintained for the port = no traffic forwarded to the monitor box's MAC address), and, if I recall right, the state of that port while monitoring will show as shutdown or similar.

I hit that roadblock myself some time ago. I was not able to ssh into a Linux box and run tcpdump (as planned) while having SPAN turned on. So I either had to use console access while monitoring (not an option in my scenario) or get around it with the following, highly cumbersome procedure (assumes Unix/Linux box):

- ssh into the monitoring box; - run tcpdump with the nohup command (nohup tcpdump {options + filtering logic} &), making tcpdump write to a binary file; - exit the ssh session; - configure SPAN on the switch; - run whatever test you need to run (so traffic is captured by the tcpdump process); - remove SPAN configuration on switch; - ssh back into monitoring box and kill the tcpdump process; - analyze binary tcpdump capture file.

Honestly, I recommend getting a hub or second NIC, but if you are in a hurry as I was and did not have either at hand, then this may help you.

HTH,

James