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 Sub-interfaces

SPAN traffic for VLAN sub-interfaces must be configured in a slightly different way as the behavior of SPAN on sub-interfaces 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 sub-interface. The SPAN must be on the hardware interface which hosts the VLAN sub-interface. For example, with a VLAN 30 sub-interface 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 sub-interface, 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 sub-interface. To see outbound packets, the SPAN must only mirror tx packets on the VLAN sub-interface, not the hardware interface:

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