Port Mirroring on a Cisco 3550 Switch

By Daniel Miessler on December 17th, 2007: Tagged as Networking

Just for reference…

Source port(s): 

Switch# config t
Switch(config)# monitor session 1 source interface fastethernet 0/1
Switch(config)# monitor session 1 source interface fastethernet 0/2
Switch(config)# monitor session 1 source interface fastethernet 0/3
Switch(config)# monitor session 1 source interface fastethernet 0/4
(however many you want to monitor)

Destination port: 

Switch(config)# monitor session 1 destination interface fastethernet 0/24

…then exit and: 

Switch# show monitor session 1

It’ll show you what all ports are being monitored (sources) and what port to sniff on (destination). Fin.:

  • Digg
  • Reddit
  • HackerNews
  • StumbleUpon
  • DZone
  • Google Bookmarks
  • Twitter
  • Facebook
  • del.icio.us
  • FriendFeed
  • Posterous
  • RSS
  • email
  

Comments

  • Saul Lethbridge

    4 Fa ports going out 1 Fa port...any dropped packets!!

  • ghost16825

    Also fyi:


    http://taosecurity.blogspot.com/2007/12/expert-commentary-on-span-and-rspan.html

  • Saul Lethbridge

    I know this is just a reference, but I personally would be very concerned with sending more than a few Fa ports out a single Gi port, considering aggregate traffic. 4 fully saturated Fa ports = 800 Mb.


    The tao article above is also something to consider, very good info.

  • I took the CCNA 1-4 (class, not the actual test.) As much as I love networking, that class let me know that I should not pursue a career in it.

  • I agree, guys. The place I implemented this had very little traffic on each port, and even then I realize it's not ideal.


    The problem is that I need to monitor this network, not just a particular port. At the same client I have a number of taps in place (permanent fixtures that I had them buy) to facilitate ongoing traffic monitoring. I do recognize that this method is superior; it's just that it doesn't let you monitor everything on a low-traffic switch like a span does.


    The problem with the span, of course, is that at any time one or more of the ports being monitored could become NOT low-traffic, at which point the solution falls apart.


    At any rate, the post was for remembering syntax for the monitor command more than anything. Good discussion, though.

blog comments powered by Disqus

Twitter Microblog

twitter_icon      facebook_icon

Sample Original Content


Information Security

Tutorials and Primers

Culture & Society

Technology & Science

Politics

Philosophy & Religion

Miscellaneous

Tools & Projects


Blog Archives