Mirroring

Mirroring consists of two main components: a mirror source and a mirror destination. It copies IPv4 and IPv6 packets. Mirror sources such as an interface (port), a subinterface (VLAN), or traffic matching an Access Control List (ACL) entry are specified and copied exactly as they are seen on the wire. These packets are then sent to a specified mirror destination, such as a locally attached traffic analyzer or a remote destination via tunneling.

By default, mirrored packets include both Ethernet headers and IPv4/IPv6 headers. Traffic from multiple sources can be mirrored to a single destination. However, mirroring to multiple destinations is not supported.

Mirror sources

The source for mirrored traffic can be an interface, subinterface, or an ACL filter.

Interfaces and subinterfaces as mirror sources

A mirror source can be an interface, including all subinterfaces within that interface. The mirror source can be the following interfaces:

  • a single interface (for example, interface ethernet-1/1)

  • a LAG (for example, interface lag1)

Either a LAG member or the LAG port can be configured as a mirror source.

When a LAG port is configured as a mirror source, mirroring captures all packets from all interfaces that make up the LAG. In this case, the system prevents these interfaces from being configured as additional mirror sources.

Conversely, if an interface is configured as a mirror source and is also a member of a LAG, the system rejects any attempt to configure the LAG port as another mirror source.

The mirror source can also be a specific VLAN, represented by a subinterface with VLAN tagging enabled (for example, interface ethernet-1/1.1 or interface lag1.1).

You can configure traffic mirroring for a single direction (either ingress or egress) or for both directions.

If system resources are exhausted, mirroring may stop and the mirror source goes operationally down. If mirroring stops working, check the operational state of the mirror sources. The operational state and operational down reason help identify the cause of the issue for a specific mirror source.

Note:

On 7250 IXR Gen 3 platforms, an interface cannot simultaneously support sFlow egress sampling and act as a source for egress mirroring. If both are configured, the system rejects the configuration.

To enable sFlow egress sampling on an interface, you must first remove the interface as an egress mirror source. Conversely, to configure an interface for egress mirroring, you must first remove the sFlow configuration from that interface.

ACL filters as mirror sources

A mirror source can also be an IPv4 or IPv6 ACL filter (not a MAC filter) applied to one or more interfaces or subinterfaces. Traffic matching an ingress ACL filter entry can be mirrored to the destination regardless of whether the ACL action is accept or drop.

Supported platforms

The following table lists hardware platform support for each mirror source.

Table 1. Hardware applicability (source mirroring)

Source

7220 IXR-D2

7220 IXR-D3

7220 IXR-D2L

7220 IXR-D3L

7220 IXR-D4

7220 IXR-D5

7250 IXR-6e

7250 IXR-10e

7250 IXR Gen 2c+

7250 IXR Gen 3

7250 IXR-X1b

7250 IXR-X3b

Interface (ingress) Yes Yes Yes Yes Yes
Interface (egress) Yes Yes Yes Yes Yes
Subinterface (ingress) Yes Yes Yes Yes Yes
Subinterface (egress) Yes Yes No Yes Yes
ACL filter (ingress) Yes Yes Yes Yes Yes
ACL filter (egress) No No No No No
Note: On 7250 IXR systems, the LAG member port cannot be mirrored. Only the entire LAG can be mirrored.

Mirror destinations

Traffic from the mirror source can be copied to a local destination (local mirroring) or tunneled to a remote destination (remote 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).

Figure 1. Local mirroring

For local mirroring, the following hardware types are supported:

  • 7220 IXR-D2

  • 7220 IXR-D3

  • 7220 IXR-D2L

  • 7220 IXR-D3L

  • 7220 IXR-D4

  • 7220 IXR-D5

  • 7250 IXR-6e

  • 7250 IXR-10e

  • 7250 IXR-X1b

  • 7250 IXR-X3b

  • 7250 IXR Gen 2c+

  • 7250 IXR Gen 3

Remote mirroring

In a remote mirroring setup, the mirror source and destination are located on different nodes. As shown in the following figure, the SR Linux node acts as the mirror source, and the mirrored packets are encapsulated into a tunnel toward the mirror destination.

Tunnel endpoints are defined within a specific network instance, where the local tunnel endpoint IP address must either a loopback subinterface address or any subinterface address within that network-instance.

Figure 2. Remote mirroring

The following table summarizes the mirror destination types supported for various platforms. The sections that follow provide more details about each of the remote mirroring tunneling mechanisms.

Table 2. Hardware applicability (destination mirroring - remote)
Destination

7220 IXR-D2

7220 IXR-D3

7220 IXR-D2L

7220 IXR-D3L

7220 IXR-D4

7220 IXR-D5

7250 IXR-6e

7250 IXR-10e

7250 IXR Gen 2c+

7250 IXR Gen 3

7250 IXR-X1b

7250 IXR-X3b

Underlay destination (GRE+ERSPAN ll) - IPv4 (ingress and egress No No No Yes Yes
Underlay destination (GRE+ERSPAN ll) - IPv6 (ingress and egress) No No No Yes Yes
Underlay destination (transparent Ethernet bridging) - IPv4 (ingress and egress) Yes Yes Yes No No
Underlay destination (transparent Ethernet bridging) - IPv6 (ingress-direction mirroring) Yes Yes Yes No No
Underlay destination (transparent Ethernet bridging) - IPv6 (egress-direction mirroring) No No Yes No No
IPv4 GRE pseudowire No No No No No
MPLS pseudowire
Note: MPLS pseudowires are set up without a control word.
No No No No No

Mirroring utilizing an underlay IP infrastructure

For 7220 IXR-D3, 7220 IXR-D4, and 7220 IXR-D5 devices, the mirrored packets including the Ethernet headers are tunneled to the remote mirror destination with a GRE header using transparent Ethernet bridging (GRE protocol type 0x6558).

For 7250 IXR-6e, 7250 IXR-10e, 7250 IXR-X1b, and 7250 IXR-X3b devices, the mirrored packets including the Ethernet headers are tunneled to the remote mirror destination. The mirrored packet is first encapsulated with an ERSPAN header and then an outer IP-GRE header using Ethernet bridging (GRE protocol type 0x88BE).

The following figure shows a mirroring-to-underlay configuration.

Figure 3. Mirroring to underlay

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

Configure mirroring by creating a mirroring instance and speicify source and destination.

The following cosiderations apply to the mirroring configuration:

  • You can map several sources to the same destination.

  • You cannot send traffic from a single source to multiple destinations.

  • The mirror destination can belong to only one mirroring instance configuration and you cannot reuse it in multiple mirroring instances.

  • You cannot use a subinterface of a mirrored interface as an additional source within a mirroring instances.

  • When using a LAG as a mirror destination, only the first eight members of the LAG carry mirrored traffic.

Note: On 7220 IXR-D4 and 7220 IXR-D5 platforms, a mirror destination port cannot be a LAG.

Mirrored traffic is considered Best Effort (BE) Forwarding Class.

Configuring mirroring sources

Follow the guidelines for configuring mirror traffic. See Configuring mirroring.

To configure mirroring, 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 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 with-context 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 with-context 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 with-context 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 with-context system mirroring
    system {
        mirroring {
            mirroring-instance 1 {
                admin-state enable
                mirror-source {
                    interface ethernet-1/5 {
                        direction ingress-egress
                    }
                    acl {
                        acl-filter ip_tcp type ipv4 {
                            entry 1000 {
                            }
                        }
                    }
                }
            }
        }
    }

Configuring mirror destinations

Follow the guidelines for configuring mirror traffic. See Configuring mirroring.

In a mirror instance, you specify the destination for the mirrored traffic.

The mirror destination can be a local destination residing on the same SR Linux node as the mirror source. See Configuring a local mirroring destination for an example of a local mirror destination configuration.

The mirror 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 7250 IXR platforms (7250 IXR-6e, 7250 IXR-10e, 7250 IXR-X1b, and 7250 IXR-X3b) support mirroring of packets including the original L2 header. The mirrored packets are then encapsulated with the GRE header and the ERSPAN II header of type 0x88BE.

Configuring a local mirroring destination

The following example configures a subinterface to be a local mirror destination.

--{ + candidate shared default }--[  ]--
# info with-context 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
            }
        }
    }

The following example configures a mirroring instance and specifies the local mirror destination.

--{ + candidate shared default }--[  ]--
# info with-context system mirroring mirroring-instance local
    system {
        mirroring {
            mirroring-instance local {
                admin-state enable
                mirror-destination {
                    local ethernet-1/4.1
                }
            }
        }
    }

Configuring a remote mirroring destination using underlay

The following example configures a mirroring instance and specifies the mirrored traffic be encapsulated into a tunnel within a network-instance. The mirrored traffic is encapsulated with a GRE header and a ERSPAN header and is tunneled to the remote destination.

Note:

For 7250 IXR-6e, 7250 IXR-10e, 7250 IXR-X1b, and 7250 IXR-X3b, the remote encapsulation is L3oGRE. For all other platforms, the encapsulation is L2oGRE.

--{ + candidate shared default }--[  ]--
# info with-context 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
                        }
                    }
                }
            }
        }
    }

Displaying mirroring information

Use the info from state command to display mirroring configuration information.

Displaying mirroring configuration information in 7250 IXR devices

--{ * candidate shared default }--[  ]--
# info from state with-context 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

Depending on the platforms, mirroring statistics are displayed as follows.

  • On 7220 IXR-D2 and 7220 IXR-D3 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 and 7220 IXR-D3 platforms for an example of displaying 7220 IXR-D2 and 7220 IXR-D3 mirroring statistics.

  • On 7220 IXR-D4, 7220 IXR-D5, 7250 IXR-6e, 7250 IXR-10e, 7250 IXR-X1b. 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, 7250 IXR-10e platforms for an example of displaying 7250 IXR-6e, 7250 IXR-10e mirroring statistics.

  • On 7220 IXR-D4 and 7220 IXR-D5 platforms, the statistics only include the number of packets mirrored in either the ingress or the egress direction. On 7250 IXR-6e, 7250 IXR-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 and 7220 IXR-D3 platforms

--{ running }--[  ]--
# info from state with-context 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, 7250 IXR-10e platforms

--{ running }--[  ]--
# info from state with-context 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 with-context 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
                    }
                }
            }
        }
    }