Mirroring
Mirroring copies IPv4 and IPv6 packets seen on a specified source, such as an interface (port) or subinterface (VLAN), or matching an ACL entry, and sends the packets to a specific destination, such as a locally attached traffic analyzer or a tunnel toward a remote destination.
By default, the mirrored packets include IPv4/IPv6 headers, as well as Ethernet headers. Traffic from multiple sources can be mirrored to a single destination, although traffic from a specific source cannot be mirrored to multiple destinations.
Mirror sources
The source for mirrored traffic can be an interface or subinterface or an ACL filter.
-
Interfaces / subinterfaces
A mirror source can be an interface, including all subinterfaces within that interface. The source can be a single interface (for example,
interface ethernet-1/1) or a LAG (for example,interface lag1). Either a LAG member or LAG port can be mirrored. When a LAG port is configured as a mirror source, mirroring is enabled on all ports making up the LAG.The source can be a specific VLAN; that is, a subinterface within an interface where VLAN tagging is enabled (for example,
interface ethernet-1/1.1orlag1.1).You can configure mirroring for traffic in a specific direction (ingress only, egress only) or bidirectional traffic (both ingress and egress).
It is possible for the mirror source operational state to be down because of resource exhaustion. If the mirror source is not mirroring packets, check the operational state of the mirror sources .
-
ACL filters
A mirror source can be an IPv4 or IPv6 ACL filter, applied under one or more interfaces or subinterfaces. Traffic matching entries in the ingress ACL filter (regardless of whether the action is accept or drop), can be mirrored to the destination.
The following table lists hardware platform support for each mirror source.
| Source | 7220 IXR-D2/D3 | 7220 IXR-D2L/D3L | 7220 IXR-D4/D5 | 7250 IXR-6e/10e | 7250 IXR-X3b | 7730 SXR |
|---|---|---|---|---|---|---|
| Interface (ingress) | Yes | Yes | Yes | Yes | Yes (LAG not supported) | Yes |
| Interface (egress) | Yes | Yes | Yes | Yes | Yes (LAG not supported) | Yes |
| Subinterface (ingress) | Yes | Yes | Yes | Yes | Yes (LAG not supported) | Yes |
| Subinterface (egress) | Yes | Yes | No | Yes | Yes (LAG not supported) | Yes |
| ACL filter (ingress) | Yes | Yes | Yes | Yes | Yes | No |
| ACL filter (egress) | No | No | No | No | No | No |
-
LAG not supported means that, the packets cannot be mirrored if the source is a LAG.
-
On 7250 IXR systems, the subinterface used as mirror source cannot be of type, bridged.
-
On 7250 IXR systems, the LAG member port cannot be mirrored.
Mirror destinations
Traffic from the mirror source can be copied to a local destination (local mirroring) or encapsulated into a tunnel to a remote destination (remote mirroring).
Local mirroring
Local mirroring
In a local mirroring configuration, both the mirror source and mirror destination reside on the same SR Linux node, as shown in the following figure.
In this configuration, the local destination is a Switched Port Analyzer (SPAN).
For local mirroring, the following hardware types are supported:
-
7220 IXR-D2/D2L/D3/D3L
-
7220 IXR-D4/D5
-
7250 IXR-6e/10e
-
7250 IXR-X3b
-
7730 SXR
Remote mirroring
In a remote mirroring configuration, the mirror source and mirror destination are on different nodes. The mirror source resides on the SR Linux node, and the mirrored packets are encapsulated into a tunnel toward the mirror destination.
The following figure shows a remote mirroring configuration. In this configuration, the remote destination is an Encapsulated Remote Switched Port Analyzer (ERSPAN).
Tunnel endpoints are defined within a specific network-instance, where the local tunnel endpoint IP address can be either a loopback subinterface address or any subinterface address within that network-instance.
Mirroring with service labels
The 7730 SXR platforms support MPLS-in-GRE to tunnel the mirrored Layer 2 packets. The Layer 2 packet is first encapsulated with the MPLS service label, followed by a GRE header. This allows most MPLS capable router at the remote end to remove the encapsulation and forward the mirrored packet to an analyzer. It is also possible to specify the analyzer as the destination. In this case, the analyzer receives a packet similar to ERSPAN, but with an additional service label.
Mirroring to underlay (ERSPAN+GRE)
In a mirroring-to-underlay (ERSPAN+GRE) configuration, the mirrored packets, including IPv4/IPv6 header as well as Ethernet header, are tunneled using Transparent Ethernet Bridging (GRE protocol type 0x6558) or L3oGRE (protocol type 0x88be for 7250 IXR-6e/10e and 7250 IXR-X3b platforms only) toward the remote destination.
The following figure shows a mirroring-to-underlay configuration.
For remote mirroring, the following hardware types are supported.
| Destination | 7220 IXR-D2/D3 | 7220 IXR-D2L/D3L | 7220 IXR-D4/D5 | 7250 IXR-6e/10e | 7250 IXR-X3b |
|---|---|---|---|---|---|
| Underlay destination (GRE+ERSPAN) - IPv4 (ingress and egress | Yes | Yes | Yes | Yes | Yes |
| Underlay destination (GRE+ERSPAN) - IPv6 (ingress-direction mirroring) | Yes | Yes | Yes | Yes | Yes |
| Underlay destination (GRE+ERSPAN) - IPv6 (egress-direction mirroring) | No | No | Yes | Yes | Yes |
Consider the following when you configure remote mirroring:
-
The system does not place any restrictions on the configuration of the tunnel-end-point destination or source IP address.
-
For an ERSPAN to be functional:
-
the source IP address configured under tunnel-end-point address must be a local interface IP address. This is typically a loopback address on the system
-
there must be a route entry in the routing table destined for the tunnel-end-point destination IP address.
-
Configuring mirroring
To configure mirroring, you configure a mirroring-instance, which specifies the source and destination for the mirrored traffic. Multiple mirror sources can have a single destination, although traffic from a specific source cannot be mirrored to multiple destinations. Only one mirror destination can be configured per mirroring-instance. A mirror destination cannot be reused in multiple mirroring instances.
Within a mirroring-instance, if an interface is configured as mirror source, a subinterface within that interface cannot be added as another mirror source. If a LAG is defined as mirror destination, only the first 8 members of the LAG carry mirrored traffic. Note that on 7220 IXR-D4 and D5 platforms, a mirror destination port cannot be a LAG.
Mirrored traffic is considered Best Effort (BE) Forwarding Class.
Configuring mirroring sources
To configure mirroring, you specify the source and destination for mirrored traffic within a mirroring-instance. The source in a mirroring-instance can be traffic on a specified interface, subinterface, or LAG, or can be packets matching an ACL entry.
interface source
The following example shows a mirroring-instance configuration with an interface as the source for mirrored traffic:
--{ * candidate shared default }--[ ]--
# info system mirroring
system {
mirroring {
mirroring-instance 1 {
admin-state enable
mirror-source {
interface ethernet-1/5 {
direction ingress-egress
}
}
}
}
}
ACL source
The following example configures an ACL with an entry that matches TCP packets and applies the ACL to a subinterface. A mirroring-instance is configured that uses packets matching the ACL as the source for mirrored traffic.
--{ * candidate shared default }--[ ]--
# info acl acl-filter ip_tcp type ipv4
acl {
acl-filter ip_tcp type ipv4 {
entry 1000 {
description Match_TCP_Protocol
match {
ipv4 {
protocol tcp
}
}
action {
accept {
}
}
}
}
}
--{ +* candidate shared default }--[ ]--
# info acl interface ethernet-1/1.1
acl {
interface ethernet-1/1.1 {
interface-ref {
interface ethernet-1/1
subinterface 1
}
input {
acl-filter ip_tcp type ipv4 {
}
}
}
}--{ * candidate shared default }--[ ]--
# info system mirroring
system {
mirroring {
mirroring-instance 1 {
admin-state enable
mirror-source {
acl {
acl-filter ip_tcp type ipv4 {
entry 1000 {
}
}
}
}
}
}
}
Configuring mirroring destinations
In a mirroring-instance, you specify the destination for the mirrored traffic.
The mirroring destination can be a local destination residing on the same SR Linux node as the mirroring source. See Configuring a local mirroring destination for an example of a local mirroring destination configuration.
The mirroring destination can be a remote destination where the mirrored traffic is sent via a tunnel. See Configuring a remote mirroring destination using underlay for an example of a remote mirroring destination configuration.
The tunneled traffic can be encapsulated with GRE protocol type 0x6558 or 0x88BE (7250 IXR-6e/10e and 7250 IXR-X3b platforms only).
The 7730 SXR platforms support MPLS-in-GRE to tunnel the mirrored Layer 2 packets. See Configuring a remote mirroring destination in 7730 SXR platforms
Configuring a local mirroring destination
The following example configures a subinterface to be a local mirror destination
--{ * candidate shared default }--[ ]--
# info from running interface ethernet-1/4 subinterface 1
interface ethernet-1/4 {
subinterface 1 {
type local-mirror-dest
admin-state enable
vlan {
encap {
single-tagged {
vlan-id 1127
}
}
}
local-mirror-destination {
admin-state enable
}
}
}Configuring a remote mirroring destination using underlay
The following example configures a mirroring-instance that specifies the mirrored traffic be encapsulated into a tunnel within a network-instance. The mirrored traffic is encapsulated into a tunnel using L2oGRE to the remote destination.
For IXR-6e/10e and IXR-X1b/X3b, the remote encapsulation is L3oGRE. For all other platforms, the encapsulation is L2oGRE.
--{ + candidate shared default }--[ ]--
# info system mirroring
system {
mirroring {
mirroring-instance test {
admin-state enable
mirror-source {
interface ethernet-1/1 {
direction ingress-egress
}
}
mirror-destination {
remote {
encap l2ogre
network-instance IPVRF-1
tunnel-end-points {
source-address 192.168.1.53
destination-address 192.168.1.153
}
}
}
}
}
}Configuring a remote mirroring destination in 7730 SXR platforms
The following example configuring a remote mirroring destination in 7730 SXR platforms.
--{ + candidate shared default }--[ ]--
# info system mirroring
system {
mirroring {
mirroring-instance one {
mirror-source {
subinterface lag7.1 {
direction ingress-only
}
}
mirror-destination {
remote {
encap mpls-gre
network-instance green_default
tunnel-end-points {
source-address 1.1.1.1
destination-address 32.1.1.5
admin-state enable
service-label 145
}
}
}
}
}
}Displaying mirroring information
Use the info from state command to display mirroring configuration information.
--{ * candidate shared default }--[ ]--
# info from state system mirroring mirroring-instance 2
system {
mirroring {
mirroring-instance 2 {
admin-state enable
oper-state down
oper-down-reason local-mirror-subif-down
mirror-source {
interface lag1 {
direction ingress-egress
}
}
mirror-destination {
local lag25.1
}
}
}
}
Displaying mirroring statistics
On 7220 IXR-D2/D3 and 7730 SXR platforms, you can display the statistics per mirror destination interface using the info from state interface * statistics command. Filter out-mirrored-packets and the out-mirror-octets fields. See Mirroring statistics on 7220 IXR-D2/D3 and 7730 SXR platforms for an example of displaying 7220 IXR-D2/D3 and 7730 SXR mirroring statistics.
On 7220 IXR-D4/D5, 7250 IXR-6e/10e, and 7250 IXR-X3b platforms, mirror destination statistics are not supported per-interface; it is only possible to display per-mirror-destination statistics. The statistics show the number of packets sent to the mirror destination. See Mirroring statistics on 7250 IXR-6e/10e platforms for an example of displaying 7250 IXR-6e/10e mirroring statistics.
On 7220 IXR-D4/D5 platforms, the statistics only include the number of packets mirrored in either the ingress or the egress direction. On 7250 IXR-6e/10e and 7250 IXR-X3b platforms, the statistics include the number of packets in the ingress direction and the number of octets mirrored in either the ingress or the egress direction.
See Mirroring statistics on 7220 IXR-D5 platform for an example of displaying 7220 IXR-D5 mirroring statistics.The octet count for ERSPAN includes the GRE header (not just the actual mirror packet). The interfaces that egress the mirrored packet must adjust the MTU size to accommodate that additional GRE header. If the MTU size is smaller than the GRE packet, the mirrored packet is dropped.
There are no packet drop statistics for mirror destinations. The statistics represent all packets that have been successfully mirrored and sent to the mirror destination. It is possible for mirrored packets to be dropped because of over-congestion of multiple mirror sources to the same mirror destination. Mirrored packet drops can also occur because a mirror destination interface can be used for regular data traffic forwarding.
Mirroring statistics on 7220 IXR-D2/D3 and 7730 SXR platforms
--{ running }--[ ]--
# info from state interface ethernet-1/48 statistics | filter fields out-mirror-octets out-mirror-packets
interface ethernet-1/48 {
statistics {
out-mirror-octets 0
out-mirror-packets 0
}
Mirroring statistics on 7250 IXR-6e/10e platforms
--{ running }--[ ]--
# info from state system mirroring mirroring-instance ixia_one mirror-destination statistics
system {
mirroring {
mirroring-instance ixia_one {
mirror-destination {
statistics {
ingress-mirrored-packets 7417657
ingress-mirrored-octets 10384702600
egress-mirrored-octets 0
}
}
}
}
}
Mirroring statistics on 7220 IXR-D5 platform
--{ running }--[ ]--
# info from state system mirroring mirroring-instance * mirror-destination statistics
system {
mirroring {
mirroring-instance eight {
mirror-destination {
statistics {
ingress-mirrored-packets 22135
egress-mirrored-packets 22132
}
}
}
mirroring-instance five {
mirror-destination {
statistics {
ingress-mirrored-packets 6353567
egress-mirrored-packets 0
}
}
}
}
}