Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Example: Configuring Remote Port Mirroring on PTX Routers

This example shows you how to configure and verify local port mirroring on PTX platforms running Junos Evolved. The PTX platforms include PTX10001-36MR, LC1201 and LC1202 in PTX10004, PTX10008 and PTX10016 chassis

Before You Begin

Hardware and Software requirements

Junos OS Evolved Release 22.2R1.12-EVO or later.

PTX10001-36MR

See Feature Explorer for a complete listing of supported platforms and Junos OS versions.

Estimated reading time

Fifteen minutes.

Estimated configuration time

Thirty minutes

Business impact

Port mirror is a critical tool for debugging and security related tasks. Mirrored traffic can be analyzed offline by a variety of tools to analyze protocol interactions, anomaly detection, or lawful intercept wire tap operations.

Know more

To better understand Port Mirroring, see Port Mirroring and Analyzers

Learn more

Learning Portal

Functional Overview

Remote Port Mirroring Functional Overview provides a quick summary of the protocols and technologies deployed in this example.

Table 1: Remote Port Mirroring Functional Overview

Routing and Signaling protocols

OSPF and OSPF3

All routers run OSPF and OSPF3 as the IGP. All provider routers belong to area 0 (also called the backbone area). The OSPF/OSPF3 routing domains provide internal reachability to all networks and interfaces in the topology. The CE routers use OSPF and OSPF3 to exchange routes with the PEs.

MPLS and RSVP The provider routers signal MPLS LSPs using the RSVP protocol. IPv6 tunneling is enabled to support IPv6 over MPLS. MPLS is used to support a Layer 3 VPN.
MP-BGP Multiprotocol BGP is used between the PE routers to advertise customer VPN routes.
Layer 3 VPN The PE routers use a VRF routing instance to support as Layer 3 VPN serve for the CE routers. The customer traffic is transported over the core inside of RSVP signaled LSPs. For more details on the operational of a MPLS-Based L3 VPN, see Example: Configure a Basic MPLS-Based Layer 3 VPN.

Routed Protocols

IPv4 and IPv6

All routers are configured to support routing of both IPv4 and IPv6.

Analyzer (monitoring station)

Centos and Wireshark

The analyzer runs Centos 7.x with a GUI version of Wireshark.

Topology Overview

This example uses the context of a MPLS-based L3 VPN to demonstrate the remote port mirroring feature on PTX routers. The L3 VPN is configured to support both IPv4 and IPv6 traffic between the customer edge (CE) and provider edge (PE) routers.

Table 2: Remote Port Mirroring Sample Topology Overview
Router Name

Role

Function
CE Customer Edge (CE) router that sends test traffic to confirm port mirroring works properly. These routers are designated as CE routers. The CE routers obtain L3 VPN service from the provider network. The CEs don't share the same OSPF routing domain as the provider routers.
PE Provider Edge (PE) router attached to the CE. The PEs are found at the edge of a provider network. Our PEs support Layer 3 VPNs through the use of routing instances, MP-BGP, RSVP, and an MPLS data plane.

The PE1 router functions as one of the remote port mirroring DUTs.

P A Provider (P) core router. The P router represents a BGP-free provider core router. It supports OSPF, OSPF3, and MPLS transport. It does not run BGP or carry VPN state.

The P router functions as one of the remote port mirroring DUTs.

Analyzer The analyzer device receives the mirror traffic for storage and analysis. The specifics of the analyzer are outside the scope of this document. There are a number of open source and commercial options available. Our analyzer happens to be running Centos 7.x with a Gnome desktop supporting a GUI version of Wireshark.

Topology Illustrations

Figure 1: Remote Port MirroringRemote Port Mirroring

This example demonstrates two ways of mirroring CE traffic sent over the provider network:

  • The first method uses a match-all filter on the PE-CE VRF interface.

  • The second method demonstrates a MPLS label matching filter that is applied on the provider (P) router.

The PE1 router (R2) and the P router (R3) are the routers where remote port mirroring is configured and function as our DUTs. These routers use family any firewall filters to match on select traffic for port mirroring. A combination of ingress and egress filters are employed to mirror both request and response traffic flowing between the CE routers (R1 and R5) .

Remote port mirroring uses a tunnel for GRE encapsulation to send mirrored traffic to a remote analyzer device. Our topology has two analyzers. One is attached to the R2/PE1 router and the other to the R3/P router. This allows us to demonstrate two ways of mirroring CE traffic, one at a PE and the other on a core P router. We use a Centos host with Wireshark for packet capture and analysis.

PTX platforms use the Flexible Tunnel Interface (fti) infrastructure to support variety of tunneling applications. In the case of remote port mirrors, GRE tunnels are configured on fti interfaces to transport mirrored traffic to a remote analyzer device . As part of this example, you'll configure fti based GRE tunnels, a mirroring instance, and the firewall filters that select traffic to be mirrored.

R2/PE1 Configuration Steps

For information about navigating the CLI, see Using the CLI Editor in Configuration Mode

Note:

For complete configuration on all routers see: Appendix 2: Set Commands on All Routers

This section highlights the configuration tasks needed to configure the PE1/R2 router in this example. We provide full configurations for all routers in the appendix. Step 1 summarizes the example's baseline. This baseline consists of IPv4 and IPv6 connectivity, MPLS, and a Layer 3 VPN. Our example places the focus on configuring and verifying remote port mirroring.

Note:

For details on the L3 VPN operation and baseline configuration see Example: Configure a Basic MPLS-Based Layer 3 VPN.

  1. Configure the IP routing and L3 VPN baseline on the PE1 router. This involves the following:

    1. Numbering the interfaces for both IPv4 and IPv6 and including family mpls support on core facing interfaces.

    2. Configuring the OSPF and OSPFv3 routing protocols to provide reachability between all network interfaces.

    3. RSVP and MPLS label switched paths (LSPs) to support L3 VPN traffic.

    4. Configuring VRF and BGP peering with the inet-vpn and inet6-vpn address families for a PE router. Our VRF example uses OSPF and OSPF3 as the PE-CE routing protocol.

    With the baseline covered the remaining steps focus on configuring the R2/PE1 router to port mirror all traffic sent and received on its CE1 facing VRF interface.

  2. You begin with configuration of the GRE tunnel. On a PTX router the tunnel is implemented over an fti interface. The source address for the GRE tunnel does not have to be routable, unless you expect to perform diagnostic ping testing sourced from or destined to the GRE tunnel source. The GRE destination for traffic mirrored by PE1 is the analyzer 1 router. This destination must be reachable for mirror traffic to be sent to the analyzer. We use a passive IGP instance to ensure IGP reachability to the analyzer networks.

    The destination address maps to the Analyzer 1 device attached to the et-0/0/2 interface on the P/R3 router. You must configure the fti logical interface with family ccc to support remote port mirroring on the PTX. This is because the mirror action occurs at Layer 2.

    Note:

    A passive IGP instance is provisioned for the interfaces attached to the analyzer devices. This provides IGP reachability to the analyzer ports for the GRE encapsulated mirrored traffic. The passive setting prevents the generation of hello packets to the analyzers as this would just clutter up the captures.

    In addition, we configured a static route on the analyzer device to allow it to respond to pings as an aid in diagnostic testing. Strictly speaking, only simplex connectivity or routing is needed between the DUTs and the analyzer for remote port mirroring to function.

  3. Configure the sampling instance. We use a rate of 1 to sample all matching packets. The default run-length of 1 is left in place given all matching traffic is already sampled. You must specify the logical interface on the fti router that is used to transport the mirror traffic. You configured unit 1 on the fti0 interface for the GRE tunnel in the previous step, so that same interface and unit is specified as the output interface in the mirror instance.
    Note:

    You can specify a maximum packet length for mirrored traffic at the [edit forwarding-options port-mirroring instance instance-name input] hierarchy with the maximum-packet-length option. By default the packet length is 0, which means the entire packet is mirrored.

  4. Define two family any firewall filters to match on and mirror the CE traffic. Two filters are defined, one for mirroring CE1 to CE2 traffic, and the other for mirroring CE2 to CE1. The filters include a count function to assist in verification. The port mirror action directs matching traffic to the port mirroring instance you configured previously.

    Family any filters support both Layer 2 and Layer 3 matching. For the former, you can match on VLAN ID, interface, MAC address, or MPLS label. For the latter, you can match on standard IPv4 or IPv6 headers fields.

    Given our topology we use a match all term that catches all traffic sent or received by the CEs. This includes IPv4, IPv6, ARP, LLDP, and any routing protocols such as OSPF.

    Both filters end with a match all accept term to override the default deny all action at the end of a Junos filter. In this way traffic that is not matched in the first term is accepted. This term is added as a safeguard in the event that later a specific match condition is added to the first term.

    If desired, you can evoke a policer action in your filter to limit the number of mirrored packets sent over the GRE tunnel. The policer is defined with a bandwidth and burst limit along with a discard action for traffic that exceeds the policer.

    You cannot apply a PM filter with a policer action in the egress direction.
    Note:

    If you wanted to match only ICMP traffic sent between the IPv4 loopback addresses of the CE devices add Layer 3 match criteria to your filter.

  5. Apply the filters to the CE facing interface on R2/PE1. For our example, that means application of the filters to the et-0/0/0 interface on PE1. Note the directionality of the filter application. An ingress and egress filter is needed to mirror both directions of CE traffic flow.

For completeness we show the configuration of R2/PE1 in curly brace format.

R3 Configuration Steps

For information about navigating the CLI, see Using the CLI Editor in Configuration Mode

Note:

For complete configuration on all routers see: Appendix 2: Set Commands on All Routers

This section highlights the main configuration tasks needed to configure the P/R3 router in this example. We start with the MPLS-based L3 VPN baseline. Then, we show the steps needed to configure remote port mirroring on a P router to match on and mirror MPLS traffic.

  1. Configure the IPv4 and IPv6 routing and MPLS baseline on the P/R3 router. This involves a few things:

    1. Numbering the interfaces for both IPv4 and IPv6 and including family mpls support on core facing interfaces.

    2. Configure the OSPF and OSPFv3 routing protocols to provide reachability between all network interfaces.

    3. RSVP and MPLS to support the L3 VPN data plane. As a P router, BGP peering and VRF definitions are not present.

      The P1/R3 router attaches to Analyzer 1 over the et-0/0/2 interface. We disable the RSVP protocol and MPLS support on this interface as the mirrored traffic arrives as IPv4 using GRE encapsulation. LSPs don't extend to the analyzer.

      Note:

      The et-0/0/2 interface configuration used here assumes that the analyzer replies to ARP and ND request sent by the DUT for MAC address resolution. If this is not the case, or if you wish that ARP traffic is not part of your packet captures, you should configure a static ARP entry. Be sure to specify the correct MAC address for the interface on the analyzer device that is attached to the DUT.

    With the baseline covered, the following steps focus on configuring remote port mirroring for MPLS traffic on a P router.

  2. You begin with the definition of the GRE tunnel. On PTX platforms tunnels are implemented on an fti interface. The source address for the GRE tunnel does not have to be routable, unless you expect to perform diagnostic ping testing sourced from or destined to the GRE tunnel source. The GRE destination for mirrored traffic is the Analyzer 2 device attached to PE2/R4. This destination must be reachable for mirror traffic to be sent to the analyzer. We use a passive IGP instance to ensure IGP reachability to the analyzer networks.

    You must configure the fti logical interface with family ccc to support remote port mirroring on the PTX. This is because the mirror action occurs at Layer 2.

    Note:

    A passive IGP instance is provisioned for the interfaces attached to the analyzer devices. This provides IGP reachability to the analyzer ports for the GRE encapsulated mirrored traffic. The passive setting prevents the generation of hello packets to the analyzers as this would just clutter up the packet captures.

    In addition, we configured a static route on the analyzer device so it can respond to pings as an aid in diagnostic testing. Strictly speaking, only simplex connectivity or routing is needed between the DUTs and the analyzer for remote port mirroring to function.

  3. Configure the sampling instance. We use a rate of 1 to select and sample all matching packets. By default the run-length is 1. This is fine given all matching traffic is sampled with a rate of 1. You must specify the logical interface on the fti router that is used to send the mirror traffic. You configured unit 1 for the fti interface in the previous step so that same unit is specified as the output interface for the mirror instance.
  4. Define the firewall filters to mirror traffic sent between the CE routers.

    Family any filters only allow Layer 2 match types. For example, VLAN ID, interface, MAC address, or MPLS label. As a result you are not able to use IPv4 or IPv4 specific match conditions.

    Two filters are defined, one for each direction of traffic flow between the CEs.

    Given our goal of mirroring VPN traffic at a P router, the filters are written to match on the specific labels that identify MPLS traffic flows between the two PE routers.

    For the CE1 to CE2 direction, the filter matches on the RSVP transport label used by PE1 to reach PE2. Because of PHP and egress application, the filter used in the CE2 to CE1 direction matches on the VRF label advertised by PE1 to PE2. Matching traffic evokes the port mirror action to the mirroring instances defined previously. The filters include a count function to assist in confirmation of proper operation.

    We determined the correct labels using these commands:

    1. For traffic sent by CE1 to CE2, the current RSVP transport label is displayed with a show rsvp session ingress detail command. This is the RSVP assigned label used by PE1 to reach PE2 using MPLS. It should be noted that all VPN traffic sent between this PE pair uses the same RSVP transport. The resulting filter is not specific to the CE1 VRF on the PE router.

      In this case the output shows that RSVP label 22 is assigned to the PE1/R2 router to reach the LSP egress at the PE2/R4 router.

    2. For traffic sent by CE2 to CE1 you must match on the VRF label. This is because the P router is the penultimate hop node and on the egress interface it will have popped the RSVP transport label. This leaves on the VRF label as the bottom of the stack. You confirm the VRF label advertised by PE1 to the PE2 with a show route advertising-protocol bgp remote-peer-address detail command. This command shows the routes advertised by the local PE along with the VRF label that is bound to the routing instance.

      The output shows that PE1 signaled VRF label 16 to the PE2 router for the routes associated with the CE1 routing instance.

      Using the information from the previous commands we know which RSVP/VRF labels to match on in the firewall filter.

      The filters end with a match all accept term to override the default deny all at the end of a Junos filter. In this way traffic that is not matched in the first term is accepted. This is critical to avoiding disrupting all other traffic using this interface!

      Note:

      RSVP labels can change due to LSP re-signaling caused by link outages or other configuration changes. We demonstrate how a filter can be used to match on specific labels to help constrain the traffic that is mirrored. You can always apply a match all filter to ensure that MPLS label changes does not affect mirroring. The disadvantage of the match all approach is you will mirror all traffic received on the P router interface to include the core protocols and non-VPN traffic.

  5. Apply the filters to the PE1 facing interface on the P/R3 router. The directionality of the filter application is important. Our filters are designed to operate in the input direction for CE1 to CE2 traffic, and in the egress direction for CE2 to CE1 traffic. Because these are family any filters, they are applied at the unit level independent of either IPv4 or IPv6. Family any filters operate at Layer 2 which is independent of any protocol family.

For completeness we show the configuration of R2/PE1 in curly brace format.

Verification

In this example, there are two DUTs where port mirroring is configured. The verification mechanisms are the same. In both cases you'll confirm that the filter is matching on expected traffic, and that mirrored packets are sent to the associated analyzer.

With our configuration PE mirrored traffic is sent to Analyzer 1 while P router mirrored traffic is sent to Analyzer 2. If desired all mirrored traffic can be sent to the same destination but, this results in the interspersing of traffic if port mirroring occurs in multiple places simultaneously.

These steps can be performed on either or both of the DUT routers as desired. R2/PE1 is the first DUT and the P router/R3 is the second.

  1. Confirm OSPF and OSPF3 neighbors and routes to all loopback addresses. Also, verify the route to the remote analyzer IP address. You must be able to send IPv4 packets to the remote analyzer. Optionally, the analyzer can be configured with static routes so it can reply.

    Note:

    In the above output, the 172.16.1.1/32 route is learned in the ce1 routing instance. Thus, with this command you have confirmed proper OSPF operation in both the core and customer edge! Only the local CE1 loopback is listed because the remote CE loopback is learned as a BGP route.

    The passive IGP instance configured on the interface connected to the analyzers provided the needed IP connectivity. Again, we add static routes to the analyzers to permit return traffic for diagnostic testing.

  2. Confirm fti interface and GRE tunnel status.

    The highlights in the output indicate the tunnel interface and GRE tunnel are operational. The non-0 output packet counter is a good sign that traffic is being mirrored. We don't expect any input packets as this GRE tunnel is used only to send mirrored traffic to a remote analyzer.

  3. Confirm the port mirroring instance. The port mirroring state should be up, and the correct mirroring interface should be listed under the destination. The family any indicates this a Layer 2 port mirror instance that is protocol family agnostic. Mirrored traffic includes the original Layer 2 frame along with its contents.

  4. Clear the firewall counters and interface statistics on the DUT. Then generate a known number of IPv4 and IPv6 test packets between the CE router loopback addresses.

  5. Back on R2/PE1, display firewall counters and interface statistics to confirm they reflect the test traffic. You may see some extra packets counted in the CE1 to CE 2 direction that reflect the OSPF, OSPF3, or ARP exchanges between the CE12 and PE1 routers. Note that in the CE12 to CE1 direction the filter application in the egress direction only catches end-to-end traffic. Therefore the CE2-CE1 counter does reflect the test traffic generated.

    Display interface statistics for the fti0./1 interface used to mirror traffic to the remote analyzer.

    With 8 test packets generated you may be surprised to see a packet count on the egress of the fti0.1 interface of 20. First, recall that both OSPF and OSPF3 hellos packets sent by the CE1 router are being mirrored. Second, consider that both ping request and replies are being mirrored at PE1/R2. That means there are 8 ping request, and 8 replies, for a total of 16 ICMP test packets.

  6. Run tcpdump or the analysis application of your choice on the monitoring station to confirm receipt and processing of the mirrored test traffic. Our setup has two analyzer devices, or precisely, one analyzer host with two interfaces. You can perform this step on both of the analyzer interfaces simultaneously, if desired. Recall that the traffic mirrored to the eth2 interface on Analyzer 2 is mirrored at the P router/R3, and therefore includes MPLS encapsulation. Traffic mirrored from R1/PE1 does not include the MPLS encapsulation.

    We begin with a capture on the eth1 interface that receives mirrored traffic from R2/PE1. After starting the capture we perform a single IPv4 ping between the CE routers.

    Note:

    After the capture, we pasted the text-based tcpdump output into a text application that displays line numbers. This makes it easier to call out key portions of the capture. We also enabled line wrap to improve visibility.

    Areas to note in the capture include:

    1. We evoke tcpdump on the eth1 interface and include flags to prevent name resolution, provide detail, capture up to 400 bytes, and to include Layer 2 headers.

    2. Line 3 is the start of the first Layer 2 frame and IP packet. The Ethernet frame is the encapsulation used by the R3/P1 router to send traffic to the locally attached analyzer device. The destination MAC address is owned by the eth1 interface on Analyzer 1. The 100.0.100.1 IP to MAC address resolution is performed through ARP. The Ethernet frame indicates it carries the IP protocol. At the IP layer we see the packet has the Don’t Fragment bit set and identifies that the payload is GRE.

    3. Line 4 shows the decode of the outer IP packet and its GRE payload. The source and destination IP addresses reflect the GRE tunnel configured ion the fti0.1 interface at R2/PE1. The GRE header identifies that its payload is a Layer 2 frame via the transparent Ethernet bridging (TEB) protocol ID. This confirms that remote port mirroring on PTX platforms with a family any filter results in the mirroring of Layer 2 frames.

    4. Line 5 is the decode for the GRE packet's payload . The source and destination MAC addresses (de:99:7e:32:ff:ff and 01:00:5e:00:00:05, respectively) reflect those used for OSPF hello multicast at the link layer. Line 5 also shows that the payload of the GRE encapsulated Layer 2 frame is IP, and that the payload of the IP packet is OSPF.

      Note:

      The OSPF hello exchange between CE and PE is local in a Layer 3 VPN. We see the OSPF packets sent by the local CE because the port mirror action at ingress captured all traffic. The OSPF hello packets generated by the remote CE are not transported over the core and therefore not seen as egress in the capture.

    5. Line 6 decodes the OSPF hello sent by the CE1 router. The source IP address is assigned to the et-0/0/0.0 interface of CE1. The destination IP address is used for OSPF multicast.

    6. We skip over the OSPF decode and land on line 16. This is the second frame in the capture and reflects an IPv4 ICMP echo request. Once again, the Layer 2 frame reflects the MAC addresses of the P1/R3 and Analyzer 1 devices. We see that the outer frame carries an IP packet with a GRE payload. The source and destination IP address of the outer IP packet reflect the GRE tunnel configured at R2/PE2.

    7. Line 18 begins the decode of GRE payload. We again see the MAC addresses of the CE1 and PE1 routers. At the IP layer we see the packet is sent from the loopback address of the CE1 router. The destination IP is the loopback address of CE2. The payload of the inner IP packet is the ICMP echo request as sent from CE1 to CE2.

    8. Line 20 decodes the ICMP echo reply sent by CE2. This confirms the port mirroring is working in both the CE1 transmits and receive direction.

  7. Next, we generate a single IPv6 ping between CE routers while capturing on the eth2 interface of Analyzer 2. This confirms the port mirror configuration on the R3/P router as well as IPv6 port mirroring support.

    Note:

    After the capture, we pasted the text-based tcpdump output into a text application that displays line numbers. This makes it easier to call out key portions of the capture. We also enabled line wrap to improve visibility.

    Note that both request and response traffic is shown. Given that this port mirror occurs on a P-router, OSPF packets between the CE routers are not mirrored as they are not sent over the provider core. Things to note in this capture include:

    1. At line 3 the outer Ethernet frame is decoded. The source and destination MAC addresses now reflect the R4/PE2 and Analyzer devices, respectively.

    2. At line 4 the inner IP packet is decoded. The frame indicates GRE encapsulation, and the source and destination IPs confirm this traffic is mirrored over the fti0.1 GRE tunnel configured at the R3/P1 router. The GRE encapsulation shows the TEB protocol, indicating that a Layer 2 Ethernet frame is encapsulated.

    3. Line 5 begins the decode of the inner Ethernet frame and its MPLS payload. The source MAC address is assigned to the et-0/0/1 interface on the R2/PE1 router. The destination MAC is associated with the et-0/0/0 interface on the R3/P1 router.

      The inner Ethernet frame identifies a payload of MPLS. This is in keeping with Layer 2 port mirroring performed at a P router with filter terms matching on MPLS labels.

      Note that in the CE1 to CE2 direction, the mirrored traffic shows two MPLS labels. The RSVP transport label is 24 (this can change due to LSP re-signaling), and the inner VRF label set to 23, which is the VRF label associated with the CE1 routing instance at the R2/PE1 router.

      Note:

      At the time of this capture the MPLS transport label used by PE1 to reach PE2 had changed. We updated the filter definition at R3/P1 to reflect the current RSVP transport label value of 24 for the captures in this section.

    4. Line 7 decodes the IPv6 payload of the MPLS frame. This is the IPv6 packet sent by CE1 to the CE2. The IPv6 packet identifies its payload as ICMP6 and shows this is an echo request.

    5. Line 8 begins the decode of the reply traffic from CE2. In the CE2 to CE1 direction only a single label is present in the mirror traffic. This is the VRF label that remains after the R3/PE1 router performs penultimate hop popping (PHP) before sending the traffic to the R2/PE1 router. The traffic mirrored at egress in the P1 to PE2 direction.

      The captures at both analyzer devices confirm that remote port mirroring is working as expected.

  8. We conclude with a GUI decode of the same CE to CE test traffic as captured on the Analyzer 2 device. Note again the presence of MPLS labels reflecting a port mirror operation on a MPLS-based PE router. The capture shows both IPv4 and IPv6 test traffic being mirrored. This capture reflects traffic that is mirrored by the P router. As a result MPLS encapsulation is present.

Appendix: Set Commands on All Routers

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

R1 (CE1)

R2 (PE1) DUT1

R3 (P Router) DUT 2

R4 (PE2)

R5 (CE2)

Caveats and Limitations

This section lists the caveats and limitations for remote port mirroring on PTX platforms.

  1. If the output portion of the port mirroring instance configuration has to be changed, the existing output configuration should be deleted first and the change committed, before the new configuration is added.

  2. A total of 15 mirror instances are supported. There is no commit error if the number of remote port mirror instances exceeds 15.

  3. A given mirrored packet can be sent to only one remote analyzer.

  4. The maximum packet length can be configured as multiple of 128 bytes. The exported packet will be 22 bytes less than the configured value.

  5. Multiple output interfaces are not supported in a given mirroring instance. There is no commit error if multiple output interfaces are configured.

  6. The sampling process is not GRES supported. There will be drops of mirrored traffic in the event of a GRES event or restart of the mirrord process.

  7. Tunnel traffic that terminates on the local router cannot be mirrored in the egress direction.

  8. You cannot use port mirroring with a filter that evokes a policer action in the egress direction.

  9. Statistics related to mirrored packets must be verified through firewall counters or FTI interface statistics.