cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
18022
Views
0
Helpful
20
Replies

Local SPAN session limit on 6509-E w/ WS-SUP720-3B

yuchenglai
Level 1
Level 1

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

Session 1

---------

Type : Service Module Session

Modules allowed : 1-9

Modules active : 1-2

BPDUs allowed : Yes

Session 2

---------

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?

20 Replies 20

How unfortunate. I saw the same thing in the 6500 configuration guide.

t814687
Level 1
Level 1

Use VACL capture for capturing traffic on 6500

works well and does not have session limits.

-serg

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.

-serg

Serg,

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

int gi1/1

int gi1/2

int 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

permit any

!

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-access-map)# exit

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

Router(config-if)# end

refer to this config guide.:

http://www.cisco.com/en/US/docs/switches/metro/me6500/software/12.2_18_ZU/configuration/guide/vacl.html

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?

Interesting thread.

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

64x RSPAN

23x ERSPAN

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.

Yu-Cheng:

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

-serg

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco