Cisco IOS routers don’t typically support SPAN, although the Cisco CRS router does, which is a special case. This makes sense because if you have a routed port, and you plug in a monitoring workstation there, there will be no traffic on the port itself, since it’s no longer connected to the network.
There are a couple of things that you can do to capture packets that traverse a router port. Typically, a router’s port will be connected to a switch, so you can configure that switch port as a source for a SPAN session on the switch itself. Another option is to use Netflow which provides detailed flow based statistics rather then replicating traffic to a port for monitoring. You can get more meaningful information in this way.
I have a question that is really bothering me, most of the switches can have maximum 2 source SPAN or RSPAN sessions but 64 RSPAN destination sessions. Why is the limit for source sessions so low and so high for RSPAN destination sessions? What is the benefit of it…
Many Cisco switch platforms are indeed limited to two source sessions. Note here that when we say “source session” we are referring to either SPAN or RSPAN sessions. Now there may be an issue with the way Cisco states these things in their documentation. They state that:
“You can run both a local SPAN and an RSPAN source session in the same switch or switch stack. The switch or switch stack supports a total of 64 source and RSPAN destination sessions.”
“You can have multiple destination ports in a SPAN session, but no more than 64 destination ports per switch stack.”
“On each switch stack, you can configure a maximum of 2 source sessions and 64 RSPAN destination sessions. A source session is either a local SPAN session or an RSPAN source session.”
Now the differences may be due to platforms and IOS versions, however, the logic behind the limitation of SPAN sessions compared to RSPAN destination sessions is sound. If you have a SPAN source session, and you create many destination sessions, you are requiring the same switch to use CPU power to manage and produce these sessions. However, with RSPAN, you create each destination session on a remote switch, which means the local switch CPU is not being drained, but the required resources are being distributed among many devices. This way you have the choice of having multiple destinations in various parts of your network, each with a packet sniffer to monitor traffic.
When examining Cisco documentation for IOS, all of the information seems to indicate that you can’t mix and match physical interfaces and VLANs in the same source session. However, I know that this is possible in Nexus platforms as I have configured such a setup. Is the example that you are sharing from an IOS or a Nexus device?
Hay Laz,
I’m using IOS 15… flavour.
instead of using a single VLAN as a source we can you use range of VLANs or more than one VLANS as source. and thats correct we can NOT mix and match physical interfaces & VLANs.
But we are not restricted to use a single VLAN which is my concern as per the 3rd Bullet point indicated.
Yes indeed I understand. It is possible to specify multiple VLANs. It may be that the particular restrictions Rene is mentioning having to do with a specific IOS or platform. I will let him know to take a look.
Thank You for Your answer, but actually it complicates the situation a bit.
So on a single switch You can configure max 2 sessions with source interface/s or vlan/s (source sessions)
monitor session 1-2 source vlan/interface
On a single switch You can configure up to 64 session with source remote vlan (destination sessions)
Monitor session 1-62 source remote vlan
I honestly see only one reason for such a limitations – You have one single dedicated switch on which You gather
all the RSPAN sessions and then forward them to physical ports on this switch. I don’t can think of anything else.
And I think that You are trying to say the same, am I right?
I just changed this. It’s been 5 years since I wrote this post so it’s possible that the switch I tried this on didn’t support it, I messed up, or a combination of the two
These restrictions also depend on your platform. On the older switches, you could use create 1-2 SPAN sessions. On my 3850, I can create 66. It’s best to check the platform’s specific SPAN restrictions. For example:
Could you please confirm that the command below enables ingress traffic from SPAN destination port and received traffic from the device connected to destination port should be VLAN tagged, if it is untagged then frame will be considered in native vlan and native vlan is 10 ?
Packets are sent on the destination port with the same encapsulation (untagged or IEEE 802.1Q) that they had on the source port if we include encapsulation replicate keyword to the SPAN destination command. But you say this is not enough, and we should also configure destination port as trunk and we should specify encapsulation ( switchport mode trunk and switchport encapsulation dot1q ). Could you please clarify ?
According to Cisco’s command reference , this command will accept incoming packets with IEEE 802.1Q encapsulation with the specified VLAN (VLAN 10) as the default VLAN. Now this is a poor choice in words, because the default VLAN is actually VLAN 1 and it cannot be changed. So here in this context, it is speaking about the native VLAN, so you are correct.
Actually, after doing a little more digging, I find that SPAN is highly platform dependant, and what actually happens depends on the platform. For example, let’s say you issue the following command:
This will result in the monitored frames to be sent out of the GE0/1 interface as untagged regardless of how they have been received. If you issue this command:
then the monitored frames will be sent out of GE0/1 with the tag of the VLAN they were in, regardless of whether or not the frames were originally received as tagged (on a trunk) or untagged (on an access port).
then the monitored frames will be sent out of GE0/1 in the form they were received on the switch. That is, with a tag if they were received on a trunk and without if they were received on an access port.
Now if you are using a 6500 Catalyst series device, then this can also be achieved simply by configuring the monitoring port as a trunk port. The resulting behaviour is similar to using the encapuslation dot1q command described above. This is the situation I was describing in my previous post.
Unfortunately, features such as SPAN do have differences across platforms, and this does introduce some confusion, so it’s a good idea to reference Cisco documentation specific to the devices you are configuring to be sure of the methodology of implementation.
The destination port is the port on which the wireshark computer must be connected. The destination is the port where all the packets/frames of the sources will be duplicated and sent out. When you configure a destination port, it loses all of its connectivity capabilities and simply “spews out” the copied frames to be captured.
When you configure the network in this way, it is always best to be physically located at the destination port and manage the wireshark computer locally. However, it is possible to configure the destination port to be able to normally forward traffic and allow the wireshark computer to communicate. In order to do this you must issue the learning keyword at the end of the command like so:
Hi Guys, forgive me if you have been asked this before…
If I perform a SPAN on a layer two interface - will I be able to examine the layer 3 packets encapsulated in the frames or will I be limited to layer 2 information ony?
If you capture frames on a device, you will be able to see the frames as well as all of their content. Remember that the payload of a frame is an IP packet, including its header, and the payload of an IP packet is the TCP segment or UDP datagram, including their headers. And the contents of a segment or datagram are the upper layer protocols used such as HTTP, SMTP, or any other.
Even so, whenever using SPAN, regardless of whether the port is layer 2 or layer 3, it is always the full packet with all the information that is captured. If you look at any wireshark capture, you will never see only from Layer 3 and up, but you will always see the various layers, starting with the “Frame” layer which essentially shows the number of bytes on the wire itself (physical), then the Ethernet layer, and then whatever other layers you happen to capture above that.
