2

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

7
  • Are the connections to the core access ports, or are they routed ports, and what distribution switch models do you have? – Ron Maupin Oct 13 '16 at 22:15
  • I'll edit the main post with what I was gonna put here since there is some formatting worth preserving. – Peter Oct 13 '16 at 22:52
  • 1
    But, what is the switch model? – Ron Maupin Oct 13 '16 at 22:53
  • Catalyst 3750s. I can't remember if they're 3750G or 3750X or something, but they're 3750s – Peter Oct 13 '16 at 22:58
  • 1
    It is important. Cisco has released code that expands ERSPAN to some 3K and 4K models. Since you have FE interfaces, I don't think what you have supports this, but I may be wrong. Side note:, unless you have on four or less access switches attached to your distribution switch, you are really too far bandwidth oversubscribed between the distribution and core. The Cisco best practice is that the access to distribution ratio be no greater than 20:1, and the distribution to core be no greater than 4:1. If you want to use any SPAN across that, then you probably need to even shrink the ratio. – Ron Maupin Oct 13 '16 at 23:06
1

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.

2
  • I figured it wouldn't be possible. The question wasn't about a network we didn't control. We do control our 2 distribution switches and the access switches under them, we just can't touch the core layer or above. I was just hoping there was some solution we could implement without getting the higher level people involved. – Peter Oct 14 '16 at 3:55
  • I still think the trunk as an access port could work. – Ron Maupin Oct 14 '16 at 3:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.