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