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

Unanswered Question
Apr 24th, 2008

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?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
yuchenglai Thu, 04/24/2008 - 06:54

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

t814687 Sat, 04/26/2008 - 19:41

Use VACL capture for capturing traffic on 6500

works well and does not have session limits.

-serg

yuchenglai Mon, 04/28/2008 - 06:28

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.

t814687 Mon, 04/28/2008 - 06:43

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

yuchenglai Mon, 04/28/2008 - 07:08

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

t814687 Mon, 04/28/2008 - 07:33

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

yuchenglai Wed, 06/04/2008 - 10:42

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?

Ryan Carretta Thu, 06/05/2008 - 00:13

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. ;)

Ryan Carretta Thu, 06/05/2008 - 01:04

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.

yuchenglai Thu, 06/05/2008 - 06:05

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?

t814687 Thu, 06/05/2008 - 06:08

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

Ryan Carretta Thu, 06/05/2008 - 12:38

Serg,

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'.

-Ryan

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.

IDS documentation:

"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?

chintan-shah Fri, 08/08/2008 - 01:41

Hi,

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 ???

Configuration:

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

switchport capture allowed vlan 300,301

Chintan.

chintan-shah Fri, 08/08/2008 - 03:19

Hi,

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.

Chintan.

Actions

This Discussion