Configuring Port Mirroring
On routers containing an Internet Processor II application-specific integrated circuit (ASIC) or T Series Internet Processor, you can send a copy of an IP version 4 (IPv4) or IP version 6 (IPv6) packet from the router to an external host address or a packet analyzer for analysis. This is known as port mirroring.
Port mirroring is different from traffic sampling. In traffic sampling, a sampling key based on the IPv4 header is sent to the Routing Engine. There, the key can be placed in a file, or cflowd packets based on the key can be sent to a cflowd server. In port mirroring, the entire packet is copied and sent out through a next-hop interface.
You can configure simultaneous use of sampling and port mirroring, and set an independent sampling rate and run-length for port-mirrored packets. However, if a packet is selected for both sampling and port mirroring, only one action can be performed and port mirroring takes precedence. For example, if you configure an interface to sample every packet input to the interface and a filter also selects the packet to be port mirrored to another interface, only the port mirroring would take effect. All other packets not matching the explicit filter port-mirroring criteria continue to be sampled when forwarded to their final destination.
 | Note: Configuration for both port mirroring and traffic sampling are handled by the same daemon, so in order to view a trace log file for port mirroring, you must configure the traceoptions option under traffic sampling. |
To prepare traffic for port mirroring, include the filter statement at the [edit firewall family inet] hierarchy level:
This filter at the [edit firewall family (inet | inet6)] hierarchy level selects traffic to be port-mirrored:
To configure port mirroring on a logical interface, configure the following statements at the [edit forwarding-options port-mirroring] hierarchy level:
| Note: The input statement can also be configured at the [edit forwarding-options port-mirroring] hierarchy level. This is only maintained for backward compatibility. However, the configuration of the output statement is deprecated at the [edit forwarding-options port-mirroring] hierarchy level. |
Specify the port-mirroring destination by including the next-hop statement at the [edit forwarding-options port-mirroring output interface interface-name] hierarchy level:
| Note: For IPv4 port mirroring to reach a next-hop destination, you must manually include a static Address Resolution Protocol (ARP) entry in the router configuration. |
The no-filter-check statement is required when you send port-mirrored traffic to a Tunnel PIC that has a filter applied to it. en
The interface used to send the packets to the analyzer is the output interface configured above at the [edit forwarding-options port-mirroring family (inet | inet6) output] hierarchy level. You can use any physical interface type, including generic routing encapsulation (GRE) tunnel interfaces. The next-hop address specifies the destination address; this statement is mandatory for non point-to-point interfaces, such as Ethernet interfaces.
To configure the sampling rate or duration, include the rate or run-length statement at the [edit forwarding-options port-mirroring input] hierarchy level.
You can trace port-mirroring operations the same way you trace sampling operations. For more information, see Tracing Traffic Sampling Operations.
For more information about port mirroring, see the following sections:
Configuring Tunnels
In typical applications, you send the sampled packets to an analyzer or a workstation for analysis, rather than another router. If you must send this traffic over a network, you should use tunnels. For more information about tunnel interfaces, see Tunnel Properties.
If your router is equipped with a Tunnel PIC, you can forward duplicate packets to multiple interfaces by configuring a next-hop group. To configure a next-hop group, include the next-hop-group statement at the [edit forwarding-options] hierarchy level:
The interface statement specifies the interface that sends out sampled information. The next-hop statement specifies the next-hop addresses to which to send the sampled information.
Next-hop groups have the following restrictions:
- Next-hop groups are supported for IPv4 addresses only.
- Next-hop groups are supported on M Series routers only, except the M120 and the M320.
- Next-hop groups support up to 16 next-hop addresses.
- Up to 30 next-hop groups are supported.
- Each next-hop group must have at least two next-hop addresses.
Port Mirroring with Next-Hop Groups
You can configure next-hop groups for MX, TX, and T Series routers using either IP addresses or Layer 2 addresses for the next hops. Use the group-type [ inet | layer-2 ] statement at [edit forwarding-options next-hop-group next-hop-group-name] hierarchy level to establish the next-hop groups. You can reference more than one port mirroring instance in a filter on MX Series routers. Use the port-mirror-instance instance-name statement at the [edit firewall family family-name filter filter-name term term-name] to refer to one of several port mirroring instances. For more information about this configuration, see the JUNOS® MX Series 3D Universal Edge Routers Solutions, Release 12.3.
| Note: On the Trio chipset for MX series routers, port mirroring instances can only be bound to the FPC level and not up to the PIC level. For MX series routers with a DPC card, both levels are supported. |
On MX, TX, and T Series routers only, you can configure port mirroring using next-hop groups, also known as multipacket port mirroring, without the presence of a Tunnel PIC. To configure this functionality, include the next-hop-group statement at the [edit forwarding-options port-mirror family inet output] or [edit forwarding-options port-mirror instance instance-name family inet output] hierarchy level:
or
You define the next-hop group by including the next-hop-group statement at the [edit forwarding-options] hierarchy level. For an example, see Examples: Configuring Port Mirroring.This configuration is supported only with IPv4 addresses.
You can disable this configuration by including a disable or disable-all-instances statement at the [edit forwarding-options port-mirror] hierarchy level or by including a disable statement at the [edit forwarding-options port-mirror instance instance-name] hierarchy level. You can display the settings and network status by issuing the show forwarding-options next-hop-group and show forwarding-options port-mirroring operational commands.
| Note: If you try to bind any derived instance to the FPC, a commit error will occur. |
Configuring Inline Port Mirroring
Inline port mirroring provides you with the ability to specify instances that are not bound to the flexible PIC concentrator (FPC) in the firewall filter’s then port-mirror-instance action. This way, you are not limited to only two port-mirror instances per FPC. Inline port mirroring decouples the port-mirror destination from the input parameters like rate. While the input parameters are programmed in the switch interface board, the next-hop destination of the mirrored packet is available in the packet itself. Inline port mirroring is supported only on Trio-based modular port concentrators (MPCs).
Using inline port mirroring, a port-mirror instance will have an option to inherit input parameters from another instance that specifies it, as shown in the following CLI configuration example:
Multiple levels of inheritance are not allowed. One instance can be referred by multiple instances. An instance can refer to another instance that is defined before it. Forward references are not allowed and an instance cannot refer to itself, doing so will cause an error during configuration parsing.
The user can specify an instance that is not bound to the FPC in the firewall filter. The specified filter should inherit one of the two instances that have been bound to the FPC. If it does not, the packet is not marked for port-mirroring. If it does, then the packet will be sampled using the input parameters specified by the referred instance but the copy will be sent to the its own destination.
Filter-Based Forwarding with Multiple Monitoring Interfaces
If port-mirrored packets are to be distributed to multiple monitoring or collection interfaces based on patterns in packet headers, it is helpful to configure a filter-based forwarding (FBF) filter on the port-mirroring egress interface.
When an FBF filter is installed as an output filter, a packet that is forwarded to the filter has already undergone at least one route lookup. After the packet is classified at the egress interface by the FBF filter, it is redirected to another routing table for additional route lookup. Obviously, the route lookup in the latter routing table (designated by an FBF routing instance) must result in a different next hop from those from the previous tables the packet has passed through, to avoid packet looping inside the Packet Forwarding Engine.
For more information about FBF configuration, see the Junos OS Routing Protocols Configuration Guide. For an example of FBF applied to an output interface, see Examples: Configuring Port Mirroring.
Restrictions
The following restrictions apply to port-mirroring configurations:
- The interface you configure for port mirroring should not participate in any kind of routing activity.
- The destination address you specify should not have a route to the ultimate traffic destination. For example, if the sampled IPv4 packets have a destination address of 10.68.9.10 and the port-mirrored traffic is sent to 10.68.20.15 for analysis, the device associated with the latter address should not know a route to 10.68.9.10. Also, it should not send the sampled packets back to the source address.
- IPv4 and IPv6 traffic is supported. For IPv6 port mirroring, you must configure the next-hop router with an IPv6 neighbor before mirroring the traffic, similar to an ARP request for IPv4 traffic. All the restrictions applied to IPv4 configurations should also apply to IPv6.
- On M120 and M320 routers, multiple next-hop mirroring is not supported.
- On M Series routers other than the M120 and M320 routers, only one family protocol (either IPv4 or IPv6) is supported at a time.
- Port mirroring supports up to 16 next hops, but there is no next-hop group support for inet6.
- Only transit data is supported.
- You can configure multiple port-mirroring interfaces per router.
- On routers containing an Internet Processor II application-specific integrated circuit (ASIC), you must include a firewall filter with both the accept action and the port-mirror action modifier on the inbound interface. Do not include the discard action, or port mirroring will not work.
- If the port-mirroring interface is a non-point-to-point interface, you must include an IP address under the port-mirroring statement to identify the other end of the link. This IP address must be reachable for you to see the sampled traffic. If the port-mirroring interface is an Ethernet interface, the router should have an Address Resolution Protocol (ARP) entry for it. The following sample configuration sets up a static ARP entry.
- You do not need to configure firewall filters on both inbound and outbound interfaces, but at least one is necessary on the inbound interface to provide the copies of the packets to send to an analyzer.
- Inline port mirroring is supported only on Trio-based MPCs.
Configuring Port Mirroring on Services Interfaces
A special situation arises when you configure unit 0 of a services interface (AS or Multiservices PIC) to be the port-mirroring logical interface, as in the following example:
Since any traffic directed to unit 0 on a services interface is targeted for monitoring (cflowd packets are generated for it), the sample port-mirroring configuration indicates that the customer would like to have cflowd records generated for the port-mirrored traffic.
However, generation of cflowd records requires the following additional configuration; if it is missing, the port-mirrored traffic is simply dropped by the services interface without generating any cflowd packets.
| Note: Another way to configure sp-1/0/0 to generate cflowd records is to use only the sampling configuration, but include a firewall filter sample action instead of a port-mirror action. |
Examples: Configuring Port Mirroring
The following example sends port-mirrored traffic to multiple cflowd servers or packet analyzers:
The following example demonstrates configuration of filter-based forwarding at the output interface. In this example, the packet flow follows this path:
- A packet arrives at interface fe-1/2/0.0 with source and destination addresses 10.50.200.1 and 10.50.100.1, respectively.
- The route lookup in routing table inet.0 points to the egress interface so-0/0/3.0.
- The output filter installed at so-0/0/3.0 redirects the packet to routing table fbf.inet.0.
- The packet matches the entry 10.50.100.0/25,
and finally leaves the router from interface so-2/0/0.0.[edit interfaces]so-0/0/3 {unit 0 {family inet {filter {output fbf;}address 10.50.10.2/25;}}}fe-1/2/0 {unit 0 {family inet {address 10.50.50.2/25;}}}so-2/0/0 {unit 0 {family inet {address 10.50.20.2/25;}}}[edit firewall]filter fbf {term 0 {from {source-address {10.50.200.0/25;}}then routing-instance fbf;}term d {then count d;}}[edit routing-instances]fbf {instance-type forwarding;routing-options {static {route 10.50.100.0/25 next-hop so-2/0/0.0;}}}[edit routing-options]interface-routes {rib-group inet fbf-group;}static {route 10.50.100.0/25 next-hop 10.50.10.1;}rib-groups {fbf-group {import-rib [ inet.0 fbf.inet.0 ];}}
The following example shows configuration of port mirroring using next-hops groups or multipacket port mirroring:
The following example shows configuration of port mirroring using next-hops groups or multipacket port mirroring on a T series router:
The following example shows configuration of inline port mirroring using PM1 and PM2 as our port mirror instances.
The packets will be sampled at a rate of 3 and the copy is sent to 50.0.0.3.
