Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Example: Configuring Local 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

Use this configuration example to configure local port mirroring feature. Port mirror is a critical tool for debugging and security related tasks. Mirror traffic can be analyzed offline by a variety of tools to either see protocol interactions or for anomaly detection.

Know more

To better understand Port Mirroring, see Port Mirroring and Analyzers

Learn more

 Learning Portal

Functional Overview

Table 1 provides a quick summary of the protocols and technologies deployed in this example.

Table 1: Local Port Mirroring Functional Overview

Routing and Signaling protocols

OSPF and OSPF3

All routers run OSPF and OSPF3 as the IGP. All 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.

In this example the CE and PE/P devices are part of the same IGP routing domain. As a result, tunnels are not needed between the PE devices to transport CE traffic over the core. In addition, because this is a local mirror use case GRE encapsulation is not needed when sending mirrored traffic to the monitoring station.

Routing Protocols

IPv4 and IPv6

All devices 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

In this example, the R3 device functions as the Device Under Test (DUT) as this is where port mirroring is configured. The device uses firewall filters to match the IP addresses associated with the CE devices to trigger the port mirror action. A combination of ingress and egress filters are employed to mirror both request and response traffic flowing between the CE devices (R1 and R5) .

The firewall filters that evoke packet sampling are applied to one or more of the transit interfaces on the R3 device.

Table 2: Local Port Mirroring Topology Overview
Device Name

Role

 Function
CE Customer Edge (CE) device that sends test traffic to confirm sampling works properly. These devices are designated as CE devices. In most cases a CE device is part of a VPN service. Here, we let the CE share the same OSPF Area 0 as the provider devices to provide main instance IP connectivity.
PE Provider Edge (PE) device that attaches to the CE. Devices at the edge of a provider network. Our PEs run only OSPF. BGP and VPNs are not deployed.
P A Provider (P) core router. We opt to demonstrate port mirroring at a P router. You can configure port mirroring on any of the provider devices as needed.
Analyzer The analyzer device received 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 GUIO version of Wireshark.

Topology Illustrations

Figure 1: Local Port Mirroring

R3 Configuration Steps

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

Note:

For complete configuration on all devices see: Appendix 2: Set Commands on All Devices

This section highlights the main configuration tasks needed to configure the DUT, which is the P device (R3) in this example. Excluding the specifics used for sampling, all devices have a similar baseline configuration that supports main instance IPv6 and IPv4 connectivity.

  1. Configure the IPv4 and IPv6 routing baseline. This includes numbering the loopback and core facing interfaces for both IPv4 and IPv6. You also define the OSPF and OSPFv3 routing protocol to provide reachability between all network interfaces.

    A passive IGP instance is provisioned for the interface attached to the analyzer. This provides reachability for diagnostic purposes without having hello packets generated on the interface. An OSPF adjacency is not expected or needed to the analyzer device

    Note: For the local mirror use case IP connectivity is only needed between the analyzer and the device doing the port mirroring. In this example we run a passive IGP on the interface attached to the analyzer. We also configure a default route on the analyzer to provide IP connectivity between it and the other devices. This provides the ability to test connectivity between the analyzer and all other devices. in the topology.

    This capability is most useful in a remote port mirror case where there is a need for Layer 3 reachability between the sampling device and the analyzer.
  2. Configure the sampling rate. We use a rate of 1 to select and sample all matching packets. The default run-length of 0 is left in place given all matching traffic is already sampled. You must also specify the egress interface and next hop address that the mirrored traffic is sent to. In this example of local port mirror, it should be noted that the interface and next hop addresses specified are directly attached to the DUT. As a result, no tunnels are needed or used when sending the mirrored traffic to the analyzer.
    Note:

    This configuration 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.

  3. Define the firewall filter to match on and then mirror IPv4 packets. Note that the filter's action specifies a port mirror action. This action directs matching traffic to the port mirroring instances you configured previously. Two filters are defined, one each for the source and destination addresses of CE1 and CE2, respectively. The filters include a count function to assist in confirmation of proper operation.

    Don't overlook the final accept-all term that overrides the default deny-all action of a Junos firewall filter!

  4. Define the firewall filter to match and mirror IPv6 packets.

  5. Apply the IPv4 and IPv6 filters to the desired interfaces. In our example, we apply both filters to the et-0/0/0 interface. Note the directionality of the filter application. For each CE traffic flow (IPv4 or IPv6), we apply one filter as ingress and the other as egress. This method of application is compatible with the way the filters are written given the address assignments and directionality of the traffic.

Verification

  1. Confirm OSPF and OSPF3 neighbors and routes to all loopback addresses.

  2. Confirm the port mirroring instance on R3. Verify that the port mirroring state is up for the mirroring interface. Be sure to confirm the up state for both the IPv4 and IPv6 families. While here, it is a good idea to confirm IP connectivity between the DUT and the analyzer. In our setup, a default route is configured on the analyzer to permit ping testing from all points of the network. Technically, the analyzer only has to be reachable by the DUT (R3), as this is an example of local port mirroring.

  3. Clear the firewall counters and interface statistics on R3. Next, generate IPv4 and IPv6 test traffic between the CE devices and display the firewall counters on R3. Verify the filters applied to R3 correctly reflect the test traffic.

  4. Display the firewall counters on R3. Verify if the filters applied to R3 correctly reflect the test traffic you generated.

  5. Display interface statistics for R3's et-0/0/2.0 interface that is attached to the analyzer. The goal is to confirm output traffic counters that correlate to the test traffic generated. With ten pings for both IPv4 and IPv6, and given that we mirror both request and replies, you can expect to see about 40 output 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. To keep the size of the capture smaller, we generated new test traffic with only two ping requests for each IPv4 and IPv6. The capture and decode confirms that port mirroring of IPv4 and IPv6, based on a firewall filter matching, is working as expected. Note that both request and response traffic is shown.

    Also, in the capture, note that only the Layer 3 traffic is mirrored. The Layer 2 encapsulation shown is generated by the DUT (R3) when forwarding the mirrored traffic to the analyzer. You can configure port mirroring for Layer 2 services like Ethernet switching or VXLAN when you need to preserve the original Layer 2 frame.

Appendix: Set Commands on All Devices

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 (CE)

R2 (PE)

R3 (DUT)

R4 (PE)

R5 (CE)