Cisco – Is it possible to replicate RSPAN features without trunk ports

ciscomirrorswitchvlan

Basically, we have 2 distribution-layer switches on separate sides of our campus, but they're both connected to the same core-layer switch. We don't have any kind of access to the core-layer switch, and it would take a long time to get the people above us to approve any changes we might propose.

The connections between our switches and the core switch are access ports, which means the normal Cisco configuration for setting up RSPAN is not available since it requires trunking VLANs over the connection, something we're not able to do without access to the core switch. Our switches have an SVI set up for the VLAN that carries the traffic to the core switch, and we have a default route setup to point to the core switch.

Our goal is to setup only one sniffer on either switch instead of having to do separate sniffers for each switch. Is that possible with our setup? I thought about setting the default route on one of the switches to the SVI of the other switch, but after more thought, it doesn't seem like that would send the traffic to the switch with the sniffer on it and might even interrupt service.

They are indeed access ports. We have SVIs set up on the distro switches (172.16.x.1/29 where x is the VLAN). I don't really know how the core switch is setup, so I don't know if we're just doing layer 2 or layer 3. Here is an example from one of our switches:

interface FastEthernet0/1
switchport mode access
switchport access vlan 20

interface vlan 20
ip address 172.16.20.1 255.255.255.240

ip route 0.0.0.0 0.0.0.0 172.16.20.2

Best Answer

It doesn't matter what layer-3 routing you put on your switch, SPAN and RSPAN only work at layer-2, not on layer-3 interfaces, e.g. your SVIs.

The obvious solution is to change the access ports to trunk ports, and only allow the single VLAN which you currently have as the access VLAN on the trunk ports, and make that VLAN the native (non-tagged) VLAN. You should disable DTP by using the switchport nonegotiate command on your trunks so that DTP negotiation is disabled. This is like having an access port on a trunk. You say you can't do that because you don't control the core switch, and that really makes your question off-topic here because questions about networks which you do not control are explicitly off-topic here. I don't really see the need to change the core switch to use a trunk as I have described, unless this is really layer-3, not layer-2.

I think the real problem will be trying to send a lot of SPAN traffic over a single 100 Mb interface toward the core switch will cause real problems with the rest of the network.

One option available on some switch models is ERSPAN, which was only available on a very few device models (65xx, ASR1xxx, Nexus), but Cisco recently released newer code versions for some 3xxx and 4xxx switch models. Without a specific model, I can't say for sure if your particular switches support this new code.

ERSPAN will encapsulate SPAN into a GRE tunnel so that the SPAN traffic may be routed via layer-3, which is not possible with SPAN or RSPAN.

Chapter: Configuring ERSPAN

ERSPAN Overview

The Cisco ERSPAN feature allows you to monitor traffic on one or more ports or more VLANs, and send the monitored traffic to one or more destination ports. ERSPAN sends traffic to a network analyzer such as a Switch Probe device or other Remote Monitoring (RMON) probe. ERSPAN supports source ports, source VLANs, and destination ports on different routers, which provides remote monitoring of multiple routers across a network (see the figure below).

On a Cisco ASR 1000 Series Router, ERSPAN supports encapsulated packets of up to 9180 bytes. The default ERSPAN maximum transmission unit (MTU) size is 1500 bytes. If the ERSPAN payload length, which comprises the encapsulated IPv4 header, generic routing encapsulation (GRE) header, ERSPAN header, and the original packet, exceeds the ERSPAN MTU size, the replicated packet is truncated to the default ERSPAN MTU size.

ERSPAN consists of an ERSPAN source session, routable ERSPAN GRE encapsulated traffic, and an ERSPAN destination session.

You can configure an ERSPAN source session, an ERSPAN destination session, or both on a Cisco ASR 1000 Series Router. A device that has only an ERSPAN source session configured is called an ERSPAN source device, and a device that has only an ERSPAN destination session configured is called an ERSPAN termination device. A Cisco ASR 1000 Series Router can act as both an ERSPAN source device and an ERSPAN termination device. You can terminate an ERSPAN session with a destination session on the same Cisco ASR 1000 Series Router.

An ERSPAN source session is defined by the following parameters:

  • A session ID
  • List of source ports or source VLANs to be monitored by the session
  • The destination and origin IP addresses, which are used as the destination and source IP addresses of the GRE envelope for the
    captured traffic, respectively
  • ERSPAN flow ID
  • Optional attributes, such as, IP type of service (TOS) and IP Time to Live (TTL), related to the GRE envelope

An ERSPAN destination session is defined by the following:

  • Session ID
  • Destination ports
  • Source IP address, which is the same as the destination IP address of the corresponding source session
  • ERSPAN flow ID, which is used to match the destination session with the source session

ERSPAN source sessions do not copy ERSPAN GRE-encapsulated traffic from source ports. Each ERSPAN source session can have either ports or VLANs as sources, but not both.

The ERSPAN source sessions copy traffic from the source ports or source VLANs and forwards the traffic using routable GRE-encapsulated packets to the ERSPAN destination session. The ERSPAN destination session switches the traffic to the destination ports.

Figure 1. ERSPAN Configuration

enter image description here

Monitored Traffic

For a source port or a source VLAN, the ERSPAN can monitor the ingress, egress, or both ingress and egress traffic. By default, ERSPAN monitors all traffic, including multicast and Bridge Protocol Data Unit (BPDU) frames.

Related Topic