In the world of network monitoring, SPAN and RSPAN are useful features that can be implemented on Cisco switches. These two features provide the ability to transparently monitor (by copying) select ingress traffic, while allowing the switch to continue to forward the original traffic as normal. Both SPAN and RSPAN require the selection of one-or-more SPAN Source ports (typically physical interfaces, but entire VLANs can also be selected) as well as one-or-more SPAN Destination ports (where copies of the monitored frames will be transmitted for further inspection).

The main difference between SPAN and RSPAN are the relationships between placement of the SPAN Source ports, and the SPAN Destination port to which your network monitoring device (IDS, IPS, Wireshark Laptop, etc) is connected. When using the SPAN feature (also called Local SPAN) your network monitoring device (likely a laptop or PC running Wireshark or some other packet capture software) would be physically connected to the same chassis on which your SPAN Source ports have been identified. Whereas RSPAN allows you to decouple the SPAN Destination from the SPAN Source ports...placing the RSPAN Destination port (to which your networking monitoring device is connected) on a different switch chassis and having the copied SPAN traffic transmitted between the chassis across VLAN Trunks utilizing an RSPAN VLAN.

When configuring SPAN, one uses the “monitor session” keywords in Cisco IOS. The first time one creates a monitor session (i.e. a SPAN/RSPAN session) you would select one-or-more SPAN Source ports. You must also select if you want to copy only frames received on this port (ingress frames), frames transmitted out of this port (egress frames), or both (the default).

A word of warning; the SPAN/RSPAN features do not allow you to selectively choose which traffic on the Source Ports will be copied to the SPAN/RSPAN Destination port. It is an all-or-nothing feature. Considering that all traffic matching the direction you’ve specified (rx, tx, or both) will be copied and sent to the SPAN/RSPAN Destination port, there is a great likelihood of overwhelming/congesting the SPAN/RSPAN Destination port if more than a single interface are included as SPAN/RSPAN Source Ports.

When configuring the second instance of the monitor session, you would select where you want your copied frames to go (the SPAN Destination). If using the Local SPAN feature, this SPAN destination would be one-or-more physical interfaces on the same chassis that contains the SPAN Source Ports. Notice that in both the graphic above and the one below, everything has been configured on a single chassis (Switch-1);

If using RSPAN, you would need to first configure (on all switches that will carry the copied RSPAN traffic) a special RSPAN VLAN. This must be a VLAN that is not currently used by any other features and contains no access switchports.

The configuration of your RSPAN Source ports is no different than the previous configuration shown for SPAN.

Subsequently, on the switch that contains the physical RSPAN Source Ports, this same RSPAN VLAN would be designated as your SPAN Destination. This ensures that frames received from the RSPAN Source Ports are copied, and placed, into this special VLAN for transmission over any VLAN Trunks you may have to remote switches.

The command, “show monitor session all” will confirm if you have a running SPAN or RSPAN session on your switch as well as identify all SPAN Source and Destination ports.

The final step of an RSPAN configuration is to move to the remote switch (connected to your network monitoring device) and configure a monitor session pointing to the RSPAN VLAN as your SPAN source…

...and one-or-more physical interfaces as your RSPAN Destination.

At this point, I have created the following topology in my lab environment (pay special attention to the ports which are included in the RSPAN session and, just as importantly, which ports are not);

When configuring the SPAN Destination port on Switch-2, if you use the Cisco IOS CLI help function, you’ll notice that there are some additional keywords available;

 

The “Encapsulation” Keyword

The “encapsulation” command is only applicable when using a Local SPAN session (not RSPAN). It dictates the format of frames that will be sent to the Network Monitoring device on the SPAN/RSPAN destination interface. One must consider the nature of traffic being received on the SPAN Source ports to determine if selecting “encapsulation” is desired.

If all of your SPAN Source ports are access switchports (i.e. you do not expect to receive any ISL encapsulated, or 802.1q tagged traffic on these ingress ports) then the “encapsulation” command is unnecessary. However if one-or-more of your SPAN Source interfaces is a VLAN Trunk (ISL or 802.1q) then you need to decide if it’s important to you to retain the ISL headers, and/or 802.1q VLAN tags from your received traffic when copying them and sending them to your SPAN destination.

By default, frames received on SPAN Source ports (whether received with tags or not) are sent as native Ethernet frames to the SPAN Destination port. This means, that if a frame is received with an 802.1q VLAN tag (on a SPAN Source port) indicating that it was received on VLAN-99 (as an example) that tag information will be lost when sending a copy of that frame to the SPAN Destination and you will not see the tag information in your Wireshark packet capture (or whatever device is connected to your SPAN Destination port).

If ingress frames are being received with 802.1q tags, or ISL headers and you want visibility to this information in your packet capture on the SPAN Destination, this is where using the “encapsulation” command (that comes immediately after specifying the SPAN Destination interface) comes in handy. And at this point you have three choices available to you;

Encapsulation dot1q - If your SPAN Source interfaces consist solely of 802.1q VLAN Trunks, or a mixture of 802.1q VLAN Trunks and Access Switchports, use this keyword to retain the 802.1q tags when copying frames sent to your SPAN Destination.

Encapsulation isl - If your SPAN Source interfaces consist solely of ISL VLAN Trunks, or a mixture of ISL VLAN Trunks and Access Switchports, use this keyword to retain the ISL headers when copying frames sent to your SPAN Destination.

Encapsulation replicate - If your SPAN Source interfaces consist of a mixture of 802.1q VLAN Trunks, ISL VLAN Trunks and Access Switchports, use this keyword to retain the ISL headers and 802.1q VLAN tags when copying frames sent to your SPAN Destination. This keyword is recommended in most Cisco documents.

NOTE: When using the “encapsulation dot1q” or “encapsulation isl” keywords in your configuration you may receive a warning message similar to the one below. This is simply a warning. You will see that your configuration does display as typed in the output of “show running-config” and preservation of tags and/or ISL headers does work.

When utilizing the RSPAN feature, use of the “encapsulation” command in reference to egress frames sent your SPAN Destination port wouldn’t make any sense. Why? This is because the RSPAN Destination on the switch (locally connected to the physical RSPAN Source ports) will always point to the RSPAN VLAN (remote-vlan). So any ISL Headers, or 802.1q VLAN tags received on ingress RSPAN Source ports (which are operational VLAN Trunks) are naturally lost as an 802.1q VLAN Tag is applied to all traffic (that references the RSPAN VLAN) prior to transmitting copies of these frames out any egress VLAN trunks. And selecting the “encapsulation” command on a remote RSPAN Destination switch (that connects to your network monitoring device) is pointless because all it would capture is the RSPAN VLAN contained in the 802.1q tag (or ISL Header).

 

The “Ingress” Keyword

By default, a SPAN Destination port (physical interface) is placed into the “monitoring” state which can be seen here;

This means that the only thing this port is used for is to transmit copies of frames received from the SPAN/RSPAN feature to the network monitoring device. This port is not allowed to receive (ingress) any frames sent from the network monitoring device.

As an example note below that the Network Monitoring device (a router in this example) has NOT had its MAC address learned by Switch-2, and is not able to ping any other devices in the same VLAN/IP Subnet;

When reading the Cisco documentation pertaining to the use of the “ingress” keyword one sees the following:

“If ingress traffic forwarding is enabled for a network security device, the destination port forwards traffic at Layer 2.”

And…

“Enter ingress with keywords to enable forwarding of incoming traffic on the destination port and to specify the encapsulation type.”

(Quotes provided courtesy of the Cisco Catalyst 3750-X and 3560-X Switch Software Configuration Guide, Release 12.2(55)SE).

Under what circumstances might one want to enable “ingress” traffic forwarding from the SPAN and/or RSPAN Destination port? Two use-cases come to mind;

1. Some Network Security devices (such as IPS devices) upon detection of a TCP-based network attack, can send TCP Reset messages to the attacker in an attempt to thwart the attack. If that IPS device is connected to a SPAN Destination port, one would want to enable the “ingress” keyword to allow the connected switch to receive, and forward, these TCP Resets to the attacking device.
2. If the device connected to the SPAN Destination port is a laptop or PC (running Wireshark or other packet-capture application) one might want to simultaneously be able to browse the Internet, retrieve emails, etc from that laptop or PC. This would be another situation in which the “ingress” keyword would be helpful on the connected switch. However, in this situation there is a caveat which must be observed, which is detailed below.

One must recognize that while implementation of the “ingress” keyword does modify ingress behavior of the SPAN Destination port...it does NOT change the egress behavior of that port. In other words;

In a Local SPAN session, the only traffic that is allowed to be transmitted OUT of a SPAN Destination port, is traffic captured on SPAN Source ports. This behavior does not change if the “ingress” keyword is used on the SPAN Destination port.

In an RSPAN session, the only traffic that is allowed to be transmitted OUT of an RSPAN Destination port, is traffic that has been received from the RSPAN VLAN (configured as the RSPAN Source in the remote switch). This behavior does not change if the “ingress” keyword is used on the RSPAN Destination port.

Notice the following examples of both below.

Example-1 Topology (SPAN with destination “ingress”):

Notice that in this topology (with “ingress” enable on port 0/4) the Monitoring Device (a router) is able to ping Host-A...but not Host-C.

       When pinging from the Monitoring Device to Host-A:

1. Switch-2 receives unicast ARP Reply on port 0/3.
2. Host-C receives the ARP Request, populates its own ARP cache with the information from the source, and generates a unicast ARP reply back to the MAC address of the M.D.
   
   
3. The ARP request is received by Switch-2 on the SPAN Destination port 0/4.
   Because “ingress” has been enabled on this interface, frame forwarding is allowed and this ARP Request (a Broadcast) is flooded to all ports in VLAN-1 (the VLAN defined after the “ingress” keyword as part of the SPAN Destination command).
   
   
4. The Monitoring Device (M.D.) transmits a broadcast ARP request for Host-C
   
   
5. When the M.D. creates its successive ICMP Echo Requests (pings) the same process occurs that previously occurred with the ARP process. Only the copies of the ICMP Echo Responses (from Host-A) are transmitted back to the M.D. due to the SPAN process.
   
   When pinging from the Monitoring Device to Host-C:
   
   
6. Switch-2 receives unicast ARP Reply on port 0/2.
   
   a. The destination MAC of the ARP Reply (M.D.s MAC) is not found in the mac address-table of Switch-2 (remember, mac learning is disabled on SPAN Destination ports).
   
   b.With an unknown unicast mac address, the ARP Reply is flooded by Switch-2 out all other ports (VLAN Trunks and Access ports) assigned to VLAN-1. This does NOT include the SPAN Destination port as it is in the “monitoring” state and not considered as a Trunk or an Access Port.
   
   c. Because the ARP Reply was received on Port 0/2 of Switch-2 (which is the SPAN Source port) a copy of that frame is created, and that copy is transmitted out port 0/4 (the SPAN Destination port). This allows the M.D. to receive a response to its initial ARP for Host-A.
   
   
7. Host-A receives the ARP Request, populates its own ARP cache with the information from the source, and generates a unicast ARP reply back to the MAC address of the M.D.
   
   
8. The ARP request is received by Switch-2 on the SPAN Destination port 0/4.
   Because “ingress” has been enabled on this interface, frame forwarding is allowed and this ARP Request (a Broadcast) is flooded to all ports in VLAN-1 (the VLAN defined after the “ingress” keyword as part of the SPAN Destination command).
   
   
9. The Monitoring Device (M.D.) transmits a broadcast ARP request for Host-A
   
   
1. The destination MAC of the ARP Reply (M.D.s MAC) is not found in the mac address-table of Switch-2 (remember, mac learning is disabled on SPAN Destination ports).
   
   
2. With an unknown unicast mac address, the ARP Reply is flooded by Switch-2 out all other ports (VLAN Trunks and Access ports) assigned to VLAN-1. This does NOT include the SPAN Destination port as it is in the “monitoring” state and not considered as a Trunk or an Access Port.
   
   
3. Because port 0/3 is NOT defined as a SPAN Source port, no copies of the ARP Reply are created or sent to the SPAN Destination port.
   
   
4. This concludes the ARP process...and the M.D. never receives an ARP Reply.
   
   
10. Without an ARP reply from Host-C, the M.D. cannot create its ICMP Echo Request packets and the pings timeout.

Example-2 Topology (RSPAN with destination “ingress”):

       When pinging from the Monitoring Device to Host-A:

1. The Monitoring Device (M.D.) transmits a broadcast ARP request for Host-A
   
   
2. The ARP request is received by Switch-2 on the SPAN Destination port 0/4.
   Because “ingress” has been enabled on this interface, frame forwarding is allowed and this ARP Request (a Broadcast) is flooded to all ports in VLAN-1 (the VLAN defined after the “ingress” keyword as part of the SPAN Destination command).
   
   3. As this ARP Request is flooded across the VLAN Trunk (Fast0/10) Switch-1 receives it and learns the source MAC of the M.D. and populates its mac address-table.
   
   4. Host-A receives the ARP Request, populates its own ARP cache with the information from the source, and generates a unicast ARP reply back to the MAC address of the M.D.
   
   5. Switch-1 receives the unicast ARP Reply on port 0/1.
   
   a. The destination MAC of the ARP Reply (M.D.s MAC) is found in the mac address-table of Switch-1 and forwarded across the VLAN Trunk (port 0/10) to Switch-2 on the native VLAN (VLAN-1).
   
   b. Because the ARP Reply was received on Port 0/1 of Switch-1 (which is the RSPAN Source port) a copy of that frame is created, and that copy is placed into the RSPAN VLAN (VLAN_200) and transmitted out port 0/10 (a VLAN Trunk).
   
   6. Switch-2 receives two copies of the ARP Reply...the original frame which is received on the Native VLAN (VLAN-1) of the trunk, and the RSPAN copy which was also received on the trunk with an 802.1q tag of VLAN_200 (the RSPAN VLAN).
   
   7. When Switch-2 receives the ARP Reply on VLAN-1, it finds no corresponding destination MAC in its mac address-table (remember, mac learning is disabled on SPAN Destination ports).
   
   a. With an unknown unicast mac address, the ARP Reply is flooded by Switch-2 out all other ports (VLAN Trunks and Access ports) assigned to VLAN-1. This does NOT include the SPAN Destination port as it is in the “monitoring” state and not considered as a Trunk or an Access Port.
   
   8. When Switch-2 receives the copy of the ARP Reply on the RSPAN VLAN, that copy is transmitted out port 0/4 (the RSPAN Destination port). This allows the M.D. to receive a response to its initial ARP for Host-A.
   
   9. When the M.D. creates its successive ICMP Echo Requests (pings) the same process occurs that previously occurred with the ARP process. Only the copies of the ICMP Echo Responses (from Host-A) that are placed onto the RSPAN VLAN (by Switch-1) are transmitted back to the M.D. due to the RSPAN process.

       When pinging from the Monitoring Device to Host-B or Host-C:

1. The Monitoring Device (M.D.) transmits a broadcast ARP request for Host-B or Host-C
   
   
2. The ARP request is received by Switch-2 on the SPAN Destination port 0/4.
   Because “ingress” has been enabled on this interface, frame forwarding is allowed and this ARP Request (a Broadcast) is flooded to all ports in VLAN-1 (the VLAN defined after the “ingress” keyword as part of the SPAN Destination command).
   
   
3. Hosts-B and C receive the ARP Request, populate their own ARP caches with the information from the source, and generate a unicast ARP reply back to the MAC address of the M.D.
   
   
4. When Switch-1 receives the ARP Reply from Host-B, it forwards this ARP Reply across the Native VLAN (VLAN_1) to Switch-2 (because it learned the source MAC of the M.D. from the previous ARP Request).
   
   
5. Switch-2 receives unicast ARP Reply from Host-C on port 0/3.
   
   
6. In both cases, the destination MAC of the ARP Reply (M.D.s MAC) is not found in the mac address-table of Switch-2 (remember, mac learning is disabled on SPAN Destination ports).
   
   a. With an unknown unicast mac address, the ARP Reply is flooded by Switch-2 out all other ports (VLAN Trunks and Access ports) assigned to VLAN-1. This does NOT include the SPAN Destination port as it is in the “monitoring” state and not considered as a Trunk or an Access Port.
   
   b. Because neither ARP Reply was received on an RSPAN Source port port no copies of the ARP Reply are created or sent to the SPAN Destination port.
   
   c. This concludes the ARP process...and the M.D. never receives an ARP Reply from Host-B or Host-C.
   
   d. Without an ARP reply from Host-B or Host-C, the M.D. cannot create its ICMP Echo Request packets and the pings to these hosts timeout.

In summary, the intent of the “ingress” keyword on SPAN/RSPAN Destination ports is not to enable bidirectional communication between the Network Monitoring device and all other remote hosts. Rather, it is meant to allow the Network Monitoring device to transmit a unicast flow of traffic to any remote destination...but replies from that destination are only conditionally accepted (if received on SPAN/RSPAN Source Ports).

There are many other caveats and restrictions regarding the SPAN/RSPAN features that are beyond the scope of this document and it is recommended that one read the Cisco documentation to obtain that information.