Tip
This is the documentation for the 24.06 version. Looking for the documentation of the latest version? Have a look here.
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