Switch Port Analyzer (SPAN) Interfaces

A SPAN interface ties two interfaces together such that packets from one interface (the source) are directly copied to another (the destination). This feature is also known as a “mirror port” on some platforms. SPAN ports are commonly used with IDS/IPS, monitoring systems, and traffic logging/statistical systems. The target interface is typically monitored by a traffic analyzer, such as snort, that receives and processes the packets.

A SPAN port mirrors traffic to another interface which is typically a local receiver. To send SPAN packets to a remote destination, see GRE ERSPAN Example Use Case which can carry mirrored packets across GRE.

SPAN Configuration

SPAN instances are configured from config mode using the span <source-interface> command. That command enters config-span mode. Inside config-span mode, the following commands are available:

onto <destination-interface> <layer> <state>:

Specifies a destination for SPAN traffic. May be repeated for multiple destinations. This interface may not be the same as the <source-interface> given to create the span instance.

The available parameters include:

destination-interface:

The interface which will receive copies of packets from the source interface. The destination interface can be any interface available to TNSR except for the <source-interface> given to create the span instance.

layer:

Sets the layer above which packet information is forwarded to the destination. Can be one of the following choices:

hw:

Mirror hardware layer packets.

l2:

Mirror Layer 2 packets.

state:

Can be one of the following choices:

rx:

Enables receive packets

tx:

Enables transmit packets

both:

Enables both transmit and receive packets

disabled:

Disables both transmit and receive

Note

When removing a span instance, the state does not need to be present on the command, and will be ignored.

SPAN Example

This example creates a new span that copies all packets sent and received on GigabitEthernet0/14/0 to memif1/1. The packet copies include hardware level information and above.

tnsr(config)# span GigabitEthernet0/14/0
tnsr(config-span)# onto memif1/1 hw both
tnsr(config-span)# exit

See also

For an example ERSPAN configuration that combines GRE in ERSPAN mode with a span instance, see GRE ERSPAN Example Use Case.

SPAN with VLAN Subinterfaces

SPAN traffic for VLAN subinterfaces must be configured in a slightly different way as the behavior of SPAN on subinterfaces is different from that of hardware interfaces.

TNSR cannot cause inbound packets to be mirrored for a VLAN by configuring SPAN directly on a VLAN subinterface. The SPAN must be on the hardware interface which hosts the VLAN subinterface. For example, with a VLAN 30 subinterface on the TenGigabitEthernet2/0/1 interface, use the following to span inbound packets including those for VLAN 30:

tnsr(config)# interface tap foobar
tnsr(config-tap)# instance 30
tnsr(config-tap)# exit
tnsr(config)# interface tap30
tnsr(config-interface)# enable
tnsr(config-interface)# exit
tnsr(config)# span TenGigabitEthernet2/0/1
tnsr(config-span)# onto tap30 hw rx
tnsr(config-span)# exit
tnsr(config)#

Note

This does not filter the traffic to only the specified VLAN subinterface, but will span all packets received on the interface. The receiving end could then filter based on the VLAN ID in the packet header.

A SPAN on the hardware interface does not capture outbound packets sent through the VLAN subinterface. To see outbound packets, the SPAN must only mirror tx packets on the VLAN subinterface, not the hardware interface:

tnsr(config)# span TenGigabitEthernet2/0/1.30
tnsr(config-span)# onto tap30 hw tx
tnsr(config-span)# exit