I am getting the following error message when I try create a second local SPAN session on my 6509-E w/ WS-SUP720-3B
% Local Session limit has been exceeded
There are currently two SPAN sessions already running
Type : Service Module Session
Modules allowed : 1-9
Modules active : 1-2
BPDUs allowed : Yes
Type : Local Session
Source VLANs :
Both : 8
Destination Ports : Gi3/8
How do I go about creating local SPAN session sourcing another VLAN w/o getting this error message?
Please see below link for local SPAN limitations.
With the method your suggested, does it mean to monitor a trunk port and then filter for the vlan that we want going to the network tap?
I noticed that I can specify multiple different VLANs as the source and be able to funnel that in to one destination port. That is all well and good, but that destination port connects to a network tap that is capable of only 100mb/s. I am already seeing output drops on the port of the 6509 that connects to the network TAP. The reason I wanted to be able to configure more than 2 local SPAN sessions is so that not all of the monitor VLANs will have to go to one network TAP port.
With VACL capture we define source VLANs we wish to monitor. We do not monitor specific trunk ports.
As example what we do in our network - we have multiple destination capture ports on a single 6513, each is setup as a trunk. We capture a specific set of VLANs to each destination port. This way:
a) we do not oversubscribe the ports (although we have GIGE)
b) capture VLANs for specific security zones we have in our network.
Looks like this is similar to what you want to achieve in your case...
Hope this helps.
Would the following configuration achieve what you described?
monitor session 2 source vlan 9 , 11 - 12
monitor session 2 destination int gi1/1 , gi1/2 , gi1/3
We actually use CATOS and config is little different...
in IOS you have to configure vlan access maps:
Here is an example how to capture traffic for vlans 2, 4-6:
Router# show ip access-lists any_host
Standard IP access list any_host
Router(config)# vlan access-map CAP 10
Router(config-access-map)# match ip address any_host
Router(config-access-map)# action forward capture
Router(config)# vlan filter CAP vlan-list 2, 4-6
Router(config)# interface gigabitEthernet 5/1
Router(config-if)# switchport trunk encapsulation dot1q
Router(config-if)# switchport capture
refer to this config guide.:
Mirroring traffic using VLAN access-maps definitely overcomes the maximum two source sessions SPAN sessions of the traditional SPAN method.
However, I noticed one caveat to using VLAN access-maps and filters, and that is in order to capture bi-directional traffic between VLANs, you must specify both VLANs.
For example, if I needed to capture bi-directional traffic between VLANs 2 and 3, I would have to execute the following:
Router(config)# interface gigabitEthernet 5/1
Router(config-if)# switchport capture allowed vlan 2,3
I was wondering if anyone has noticed this?
In older releases of code, only two span sessions are allowed. In 12.2(33)SXH, the following are the limitations placed on SPAN sessions:
2x local SPAN, RSPAN source, ERSPAN source, ingress, egress, or both
14x egress-only local span
Each local SPAN session may have a maximum of 128 sources and 64 destinations. An RSPAN session may have only one destination RSPAN vlan and an ERSPAN may have only one destination IP address.
As previous posters have mentioned, VACL capture may do the trick for you, depending on what it is you are looking for.
The reason for this is that vacl capture is done here on ingress before the layer-2 rewrite, but the packet is output after the layer-2 rewrite by the PFC. So, if I have vlan1host = 192.168.1.1/24
smac = host, dmac = vlan1svi
sends traffic to
vlan2host = 192.168.2.1/24
smac = vlan2svi, dmac = vlan2
If I do the capture on vlan 1, I will see the packet as it looks when it egresses vlan2, that is with smac = vlan2svi and dmac = vlan2. Similarly, if I were to do it in the opposite direction, the same would be true...I could allow vlan2, and I the packets I would see would look like they were egressing vlan1.
Hope that makes sense. ;)
BTW, what is the difference between [type=local+direction=tx] and [type=local-tx] SPAN from hardware point of view ??? I mean that local SPAN still has limitation of 2 session (even if it is configured as "tx" only), whilst local-tx allows us to configure 14 sessions ???
Without delving into a long discussion on 6k architecture, it has to do with who does the replication of the packet.
Prior to 12.2(33)SXH, for tx span, the replication asic on the supervisor did the packet copying and the copy was sent to the SPAN destination. Post-SXH, the duty of replication was distributed to the line cards.
For rx SPAN, the line cards create a copy of the packet on receipt and direct the copy to the egress SPAN port.
Does local-tx SPAN work if Distributed Egress Replication feature is disabled, which is the default setting for now? (no monitor session egress replication-mode distributed)
Hm...I didn't look close enough at my captures to notice the mac-addresses. I should have saved my captures.
The only thing that immediately jumped out at me was the fact that I was not able to capture bi-directional communications between two hosts residing on VLANs 2 and 3 when I did "switchport capture allowed vlan 2" I was able to capture bi-directional traffic between those two hosts only when I perfored "switchport capture allowed-vlans 2,3".
But lets just talk about VLAN 2 for now.
This behavior seems to suggest that VACL is able to capture traffic going into a VLAN 2 only when the traffic enters the switchports and not when traffic is routed into VLAN 2 itself from VLAN 3. If host A on VLAN 2 pings host B on VLAN 3, I would only see echo requests from host A but not echo response from host B. If I want to see echo responses from host B, I would have to configure my capture port to "switchport captured allowed vlan 2,3"
So assuming that my observations on VACL captures are correct, I can only see one possibility. If host A sends on VLAN 2 sends traffic to host B on VLAN 3, I should be able to capture the true mac-address of host A as the source and the mac-address of VLAN 2 SVI as the destination when I specify only "switchport capture allowed-vlan 2." But if I capture the response packets of host B from VLAN 3 (by adding vlan 3 to the switchport capture statement), I should see host B's true mac-address as the source and the mac-address of VLAN 3 SVI as the destination (when host B responds to host A).
Is this assumption correct?
here is the the explanation on how internally VACL capture works (taken from one of the posts before):
"IF your switch/msfc IS routing between vlans, then you need to be aware of the interaction between VACL Capture and inter vlan routing by the switch/msfc.
If a packet comes in on vlan 1 where a VACL Capure ACL has been placed, but is then routed to vlan 10 where no VACL exists, then that packet will usually be marked as a vlan 10 capture packet. It gets marked as a vlan 10 capture packet even though there is not VACL on vlan 10 and the VACL is only on vlan 1. This weird interaction happens because of MLS (Multi-Layer Switching). It combines as many features of the switch as possible so as to reduce the number of times that a packet traverses the backplane of the switch. In this case the packet is both marked for capture and routed to vlan 10 at the same time.
You need to understand that with VACL Capture the packet is Not actually copied to the VACL Capture port by the supervisor (unlike span where a copy is sent to the span port). Instead the supervisor just adds a single capture bit to the internal switch packet header, and sends the packet down the backplane of the switch. So when the packet goes to the backplane of the switch it has already been routed from vlan 1 to vlan 10, and is a vlan 10 packet with a capture bit. The VACL Capture port is watching out for these packets with the capture bit set. When it sees one it compares the vlan of the packet to the vlans the capture port is trunking. If there is a match then at this point it copies it on to the sensor. It is the end capture port and not the supervisor doing the copying. If there is not a match then it ignores the packet.
So even though you put the VACL on vlan 1, you will still need to monitor vlan 10 to see the packets routed to vlan 10. Even though there is no VACL on vlan 10.
So when you have routing between all of the vlans in the switch you might as well just go ahead and trunk all possible vlans. This way you are also covered if any additional vlans get added.
Another thing to keep in mind is that in Native IOS on the switch a similar thing can happen with ports where the switch has an ip address configured directly on it's port instead of placing them on a user configured vlan. I specifically say "user configured vlan" because internally the switch also has what many term "hidden vlans". When the user puts an ip address on a port instead of making it part of a user configured vlan; internally the switch actually creates it's own "hidden vlan" and puts that port on the hidden vlan. The ip address the user configured on the port then actually gets applied to that "hidden vlan". The "hidden vlan" is a vlan number that switch chooses from the list of vlan numbers that the user is not already using.
And so with routing combined with VACL Capture you can have packets being marked for capture on even these "hidden vlans".
Since you won't know which vlan number will be the "hidden vlan" it is best to go ahead and trunk All vlans. "
I found it very useful
The official name for these are 'internal vlans' (not very exciting I know).
You can actually find out which vlans map to which layer-3 ports. Get on your 6k and issue a 'show vlan internal usage'.
The most interesting part of this post from Marcoa Caballero is the phrase "usually be marked as a vlan 10...". It seems that sometimes the packet can be marked by an ingress VLAN number, rather then the egress VLAN number.
"Using VACL capture or SPAN (promiscuous monitoring) is inconsistent with regard to VLAN tagging, which causes problems with VLAN groups.
-When using Cisco IOS software, a VACL capture port or a SPAN target does not always receive tagged packets even if it is configured for trunking.
-When using the MSFC, fast path switching of learned routes changes the behavior of VACL captures and SPAN."
Can anybody shed some light on this?
I configured VACL for all IP traffic for vlan 300 and vlan 301 and when i ping device connected to vlan 301 i only see in sniffer echo request not echo reply. It means it only capture outgoing traffic not incomming. Any specific config needed ???
ip access-list extended ALL_IP_TRAFIC
permit ip any any
vlan access-map MONITOR 10
match ip address ALL_IP_TRAFIC
action forward capture
vlan filter MONITOR vlan-list 300-301
# configure below two lines under gi1/47 - Port connected to sniffer
switchport capture allowed vlan 300,301
Further to my mail above, i have 6500 box having SVI 300 and 301 configured. it is trunk to other voice box and uplink of 6500 box is connected to my IP core network ( L3 GE interface). Now if I ping from remote pop to IP on voice box ( VLAN 301) i only see outgoign packet (echo request) in sniffer and don't see echo reply.
Sniffer port is configured with trunk and capture all vlan.
How do i get echo reply also in sniffer so that i can also capture the traffic from my voice box to IP core ?
Any help apprcieated.