- play_arrow Overview
- play_arrow Operation, Administration, and Management Features
- play_arrow Ethernet OAM and Connectivity Fault Management for Routers
- Introduction to OAM Connectivity Fault Management (CFM)
- Configure Connectivity Fault Management (CFM)
- CFM Action Profile
- Ethernet Local Management Interface
- CFM Support for CCC Encapsulated Packets
- Configure Unified ISSU for 802.1ag CFM
- CFM Monitoring between CE and PE Devices
- Configure Continuity Check Messages
- Example: Configure Ethernet CFM on Physical Interfaces
- Example: Configure Ethernet CFM on Bridge Connections
- Example: Configure Ethernet CFM over VPLS
- play_arrow Link Fault Management for Routers
- play_arrow Ethernet OAM Link Fault Management for Switches
- play_arrow Ethernet OAM Connectivity Fault Management for Switches
- play_arrow Ethernet Frame Delay
- Ethernet Frame Delay Measurements on Switches
- Configure MEP Interfaces on Switches to Support Ethernet Frame Delay Measurements (CLI Procedure)
- Configure One-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
- Configure an Iterator Profile on a Switch (CLI Procedure)
- Trigger an Ethernet Frame Delay Measurement Session on a Switch
- Configure Two-Way Ethernet Frame Delay Measurements on Switches (CLI Procedure)
- play_arrow Ethernet Service OAM (ITU-TY.1731) for Routers
- ITU-T Y.1731 Ethernet Service OAM Overview
- Configure Ethernet Frame Delay Measurement Sessions
- Configuring MEP Interfaces to Support Ethernet Frame Delay Measurements
- Configure Ethernet Frame Loss Measurement
- Configure an Iterator Profile
- Configure Ethernet Synthetic Loss Measurements
- Ethernet Alarm Indication
- Inline Transmission Mode
-
- play_arrow Network Monitoring by using SNMP
- SNMP Architecture and SNMP MIBs Overview
- Understand SNMP Implementation in Junos OS
- Configure SNMP in Junos OS
- Configure Options on Managed Devices for Better SNMP Response Time
- Enterprise Specific Utility MIB to Enhance SNMP Coverage
- Optimize the Network Management System Configuration for the Best Results
- Interfaces to Accept SNMP Requests
- Configure SNMP for Routing Instances
- Configure SNMP Remote Operations
- SNMP Traps
- SNMP Traps Supported by Junos OS
- Trace SNMP Activity
- Access Privileges for an SNMP Group
- Configure Local Engine ID on SNMPv3
- Configure SNMPv3
- Configure SNMPv3 Authentication Type and Encryption Type
- SNMPv3 Traps
- SNMPv3 Informs
- SNMP Communities
- MIB Views
- SNMP MIBs Supported by Junos OS and Junos OS Evolved
- Junos OS SNMP FAQs
- play_arrow Remote Network Monitoring (RMON) with SNMP Alarms and Events
- play_arrow Accounting Options
- play_arrow Monitoring Options
- play_arrow Interface Alarms
- play_arrow IP Monitoring
- play_arrow sFlow Monitoring Technology
- play_arrow Adaptive Sampling for Routers and Switches
- play_arrow Packet Flow Accelerator Diagnostics Software
-
- play_arrow Monitoring Common Security Features
- play_arrow Performance Management
- play_arrow System Log Messages
- play_arrow Network Management and Troubleshooting
- Compressing Troubleshooting Logs from /var/logs to Send to Juniper Networks Technical Support
- Monitoring and Troubleshooting
- Troubleshooting System Performance with Resource Monitoring Methodology
- Configuring Data Path Debugging and Trace Options
- Using MPLS to Diagnose LSPs, VPNs, and Layer 2 Circuits
- Using Packet Capture to Analyze Network Traffic
- On-Box Packet Sniffer Overview
- Troubleshooting Security Devices
- play_arrow Configuration Statements and Operational Commands
Configuring Port Mirroring for Multiple Destinations
Understanding Layer 2 Port Mirroring to Multiple Destinations Using Next-Hop Groups
On an MX Series router and on an EX Series switch, you can mirror traffic to multiple destinations by configuring next-hop groups in Layer 2 port-mirroring firewall filters applied to tunnel interfaces. The mirroring of packets to multiple destinations is also known as multipacket port mirroring,
Junos OS Release 9.5 introduced support for Layer 2 port mirroring using next-hop groups on MX Series routers, but required installation of a Tunnel PIC. Beginning in Junos OS Release 9.6, Layer 2 port mirroring using next-hop groups on MX Series routers does not require Tunnel PICs.
On MX Series routers and on EX Series switches, you can define a firewall filter for mirroring packets to a next-hop group. The next-hop group can contain Layer 2 members, Layer 3 members, and subgroups that are either unit list (mirroring packets to each interface) or load-balanced (mirroring packets to one of several interfaces). The MX Series router and the EX Series switch supports up to 30 next-hop groups. Each next-hop group supports up to 16 next-hop addresses. Each next-hop group must specify at least two addresses.
To enable port mirroring to the members of a next-hop group,
you specify the next-hop group as the filter action of a firewall
filter, and then you apply the firewall filter to logical tunnel interfaces
(lt-
) or virtual tunnel interfaces (vt-
) on
the MX Series router or on the EX Series switch.
The use of subgroups for load-balancing mirrored traffic is not supported.
Defining a Next-Hop Group on MX Series Routers for Port Mirroring
Starting with release 14.2, 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 takes effect. All other packets not matching the explicit filter port-mirroring criteria continue to be sampled when forwarded to their final destination.
Next-hop groups allow you to include port mirroring on multiple interfaces.
On MX Series routers, you can mirror tunnel interface input
traffic to multiple destinations. To this form of multipacket port
mirroring, you specify two or more destinations in a next-hop group,
define a firewall filter that references the next-hop group as the
filter action, and then apply the filter to a logical tunnel interface lt-
) or virtual tunnel interfaces (vt-
on the MX
Series router.
To define a next-hop group for a Layer 2 port-mirroring firewall filter action:
Example: Configuring Multiple Port Mirroring with Next-Hop Groups on M, MX and T Series Routers
When you need to analyze traffic containing more
than one packet type, or you wish to perform multiple types of analysis
on a single type of traffic, you can implement multiple port mirroring
and next-hop groups. You can make up to 16 copies of traffic per group
and send the traffic to next-hop group members. A maximum of 30 groups
can be configured on a router at any given time. The port-mirrored
traffic can be sent to any interface, except aggregated SONET/SDH,
aggregated Ethernet, loopback (lo0), or administrative (fxp0) interfaces. To send port-mirrored traffic to multiple flow servers
or packet analyzers, you can use the next-hop-group
statement
at the [edit forwarding-options]
hierarchy level.

Figure 1 shows an example of how to configure multiple port mirroring with next-hop groups. All traffic enters the monitoring router at interface ge-1/0/0. A firewall filter counts and port-mirrors all incoming packets to a Tunnel Services PIC. A second filter is applied to the tunnel interface and splits the traffic into three categories: HTTP traffic, FTP traffic, and all other traffic. The three types of traffic are assigned to three separate next-hop groups. Each next-hop group contains a unique pair of exit interfaces that lead to different groups of packet analyzers and flow servers.
Instances enabled to mirror packets to different destinations from the same PFE, also use different sampling parameters for each instance. When we configure Layer2 Port-mirroring with both global port-mirroring and instance based port-mirroring, PIC level instances will override FPC level and the FPC level will override the Global instance.
[edit] interfaces { ge-1/0/0 { # This is the input interface where packets enter the router. unit 0 { family inet { filter { input mirror_pkts; # Here is where you apply the first filter. } address 10.11.1.1/24; } } } ge-1/1/0 { # This is an exit interface for HTTP packets. unit 0 { family inet { address 10.12.1.1/24; } } } ge-1/2/0 { # This is an exit interface for HTTP packets. unit 0 { family inet { address 10.13.1.1/24; } } } so-0/3/0 { # This is an exit interface for FTP packets. unit 0 { family inet { address 10.1.1.1/30; } } } so-4/3/0 { # This is an exit interface for FTP packets. unit 0 { family inet { address 10.2.2.1/30; } } } so-7/0/0 { # This is an exit interface for all remaining packets. unit 0 { family inet { address 10.5.5.1/30; } } } so-7/0/1 { # This is an exit interface for all remaining packets. unit 0 { family inet { address 10.6.6.1/30; } } } vt-3/3/0 { # The tunnel interface is where you send the port-mirrored traffic. unit 0 { family inet; } unit 1 { family inet { filter { input collect_pkts; # This is where you apply the second firewall filter. } } } } } forwarding-options { port-mirroring { # This is required when you configure next-hop groups. family inet { input { rate 1; # This port-mirrors all packets (one copy for every packet received). } output { # Sends traffic to a tunnel interface to enable multiport mirroring. interface vt-3/3/0.1; no-filter-check; } } } next-hop-group ftp-traffic { # Point-to-point interfaces require you to specify the interface so-4/3/0.0; # interface name. interface so-0/3/0.0; } next-hop-group http-traffic { # Configure a next hop for all multipoint interfaces. interface ge-1/1/0.0 { next-hop 10.12.1.2; } interface ge-1/2/0.0 { next-hop 10.13.1.2; } } next-hop-group default-collect { interface so-7/0/0.0; interface so-7/0/1.0; } } firewall { family inet { filter mirror_pkts { # Apply this filter to the input interface. term catch_all { then { count input_mirror_pkts; port-mirror; # This action sends traffic to be copied and port-mirrored. } } } filter collect_pkts { # Apply this filter to the tunnel interface. term ftp-term { # This term sends FTP traffic to an FTP next-hop group. from { protocol ftp; } then next-hop-group ftp-traffic; } term http-term { # This term sends HTTP traffic to an HTTP next-hop group. from { protocol http; } then next-hop-group http-traffic; } term default { # This sends all remaining traffic to a final next-hop group. then next-hop-group default-collectors; } } } }
Example: Layer 2 Port Mirroring to Multiple Destinations
On MX Series routers, you can mirror traffic to multiple destinations by configuring next-hop groups in Layer 2 port-mirroring firewall filters applied to tunnel interfaces.
Configure the chassis to support tunnel services at PIC 0 on FPC 2. This configuration includes two logical tunnel interfaces on FPC 2, PIC 0, port 10.
content_copy zoom_out_map[edit] chassis { fpc 2 { pic 0 { tunnel-services { bandwidth 1g; } } } }
Configure the physical and logical interfaces for three bridge domains and one Layer 2 VPN CCC:
Bridge domain bd will span logical interfaces ge-2/0/1.0 and ge-2/0/1.1.
Bridge domain bd_next_hop_group will span logical interfaces ge-2/2/9.0 and ge-2/0/2.0.
Bridge domain bd_port_mirror will use the logical tunnel interface lt-2/0/10.2.
Layer 2 VPN CCC if_switch will connect logical interfaces ge-2/0/1.2 and lt-2/0/10.1.
content_copy zoom_out_map[edit] interfaces { ge-2/0/1 { flexible-vlan-tagging; encapsulation flexible-ethernet-services; unit 0 { # An interface on bridge domain ’bd’. encapsulation vlan-bridge; vlan-id 200; family bridge { filter { input pm_bridge; } } } unit 1 { # An interface on bridge domain ’bd’. encapsulation vlan-bridge; vlan-id 201; family bridge { filter { input pm_bridge; } } } unit 2 { encapsulation vlan-ccc; vlan-id 1000; } } ge-2/0/2 { # For ’bd_next_hop_group’ encapsulation ethernet-bridge; unit 0 { family bridge; } } lt-2/0/10 { unit 1 { encapsulation ethernet-ccc; peer-unit 2; } unit 2 { encapsulation ethernet-bridge; peer-unit 1; family bridge { filter { output redirect_to_nhg; } } } } ge-2/2/9 { encapsulation ethernet-bridge; unit 0 { # For ’bd_next_hop_group’ family bridge; } } }
Configure the three bridge domains and the Layer 2 VPN switching CCC:
Bridge domain bd spans logical interfaces ge-2/0/1.0 and ge-2/0/1.1.
Bridge domain bd_next_hop_group spans logical interfaces ge-2/2/9.0 and ge-2/0/2.0.
Bridge domain bd_port_mirror uses the logical tunnel interface lt-2/0/10.2.
Layer 2 VPN CCC if_switch connects interfaces ge-2/0/1.2 and lt-2/0/10.1.
content_copy zoom_out_map[edit] bridge-domains { bd { interface ge-2/0/1.0; interface ge-2/0/1.1; } bd_next_hop_group { interface ge-2/2/9.0; interface ge-2/0/2.0; } bd_port_mirror { interface lt-2/0/10.2; } } protocols { mpls { interface all; } connections { interface-switch if_switch { interface ge-2/0/1.2; interface lt-2/0/10.1; } } }
For detailed information about configuring the CCC connection for Layer 2 switching cross-connects, see the MPLS Applications User Guide.
Configure forwarding options:
Configure global port-mirroring properties to mirror family vpls traffic to an interface on the bridge domain bd_port_mirror.
Configure the next-hop group nhg_mirror_to_bd to forward Layer 2 traffic to the bridge domain bd_next_hop_group.
Both of these forwarding options will be referenced by the port-mirroring firewall filter:
content_copy zoom_out_map[edit] forwarding-options { port-mirroring { # Global port mirroring properties. input { rate 1; } family vpls { output { interface lt-2/0/10.2; # Interface on ’bd_port_mirror’ bridge domain. no-filter-check; } } } next-hop-group nhg_mirror_to_bd { # Configure a next-hop group. group-type layer-2; # Specify ’layer-2’ for Layer 2; default ’inet’ is for Layer 3. interface ge-2/0/2.0; # Interface on ’bd_next_hop_group’ bridge domain. interface ge-2/2/9.0; # Interface on ’bd_next_hop_group’ bridge domain. } }
Configure two Layer 2 port-mirroring firewall filters for family bridge traffic:
filter_pm_bridge—Sends all family bridge traffic to the global port mirroring destination.
filter_redirect_to_nhg—Sends all family bridge traffic to the final next-hop group nhg_mirror_to_bd.
Layer 2 port-mirroring firewall filters for family bridge traffic applies to traffic on a physical interface configured with encapsulation ethernet-bridge.
content_copy zoom_out_map[edit] firewall { family bridge { filter filter_pm_bridge { term term_port_mirror { then port-mirror; } } filter filter_redirect_to_nhg { term term_nhg { then next-hop-group nhg_mirror_to_bd; } } } }
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.