therapyer.blogg.se

To apply this ACL to our monitoring session we need only one more line: monitor session 1 filter ip access-group 100 Since we really have no idea what port the traffic will be sourcing from I just included everything greater than 1024 to be sure nothing is missed. This access list will look something like this: access-list 100 permit tcp host 10.1.1.2 gt 1024 host 1.1.1.1 eq 80Īccess-list 100 permit tcp host 1.1.1.1 eq 80 host 10.1.1.2 gt 1024Īs you can see I am covering the bases needed to capture traffic in both directions. Let’s say we are looking to capture HTTP traffic between 10.1.1.2 and 1.1.1.1. To do that first we have to define those packets in an ACL. To troubleshoot a complicated issue on a heavily used network link we will be well severed to limit the packets that get copied to the destination port. Monitor session 2 destination interface Gi1/0/4Īll traffic is copied from the source to the destination interface plain and simple. Or like this: monitor session 2 source interface Gi 1/0/48

Monitor session 1 destination interface Gi2/0/4 Before going further, it is worth mentioning I tested this on a 3750 series switch and results may vary on other units.Ī simple monitoring session would look something like this in the configuration: monitor session 1 source interface vlan 1 Fortunately, there is a way to do this through access control lists on the switch itself. If we mirror a switch port that sees a high volume of traffic simply mirroring all of that traffic to our packet capturing port could be too much for our capture system to consume. Today, I want to focus on the SPAN session from a packet capturing standpoint. A basic span port is very useful in capturing packets or passively monitoring and is a requirement for some web filtering services such as Websense. If you have a bit of familiarity Cisco switches you may have configured a SPAN port or a monitor session in the past.