- play_arrow Flow Capture Services
- play_arrow Dynamically Capturing Packet Flows Using Junos Capture Vision
- play_arrow Detecting Threats and Intercepting Flows Using Junos Flow-Tap and FlowTapLite Services
- Understanding the FlowTap and FlowTapLite Services
- Understanding FlowTap and FlowTapLite Architecture
- Configuring the FlowTap Service on MX Series Routers
- Configuring a FlowTap Interface on MX Series Routers
- Configuring FlowTap and FlowTapLite Security Properties
- FlowTap and FlowTapLite Application Restrictions
- Examples: Configuring the FlowTapLite Application on MX Series and ACX Series Routers
- Configuring FlowTapLite on MX Series Routers and M320 Routers with FPCs
-
- play_arrow Inline Monitoring Services and Inband Network Telemetry
- play_arrow Inline Monitoring Services
- play_arrow Flow-Based Telemetry
- play_arrow Inband Flow Analyzer 2.0
- play_arrow Juniper Resiliency Interface
-
- play_arrow Sampling and Discard Accounting Services
- play_arrow Sampling Data Using Traffic Sampling and Discard Accounting
- play_arrow Sampling Data Using Inline Sampling
- Understand Inline Active Flow Monitoring
- Configuring Inline Active Flow Monitoring Using Routers, Switches or NFX250
- Configuring Inline Active Flow Monitoring on MX80 and MX104 Routers
- Configuring Inline Active Flow Monitoring on PTX Series Routers
- Inline Active Flow Monitoring of MPLS-over-UDP Flows on PTX Series Routers
- Inline Active Flow Monitoring on IRB Interfaces
- Example: Configuring Inline Active Flow Monitoring on MX Series and T4000 Routers
- play_arrow Sampling Data Using Flow Aggregation
- Understanding Flow Aggregation
- Enabling Flow Aggregation
- Configuring Flow Aggregation on MX, M and T Series Routers and NFX250 to Use Version 5 or Version 8 cflowd
- Configuring Flow Aggregation on MX, M, vMX and T Series Routers and NFX250 to Use Version 9 Flow Templates
- Configuring Flow Aggregation on PTX Series Routers to Use Version 9 Flow Templates
- Configuring Inline Active Flow Monitoring to Use IPFIX Flow Templates on MX, vMX and T Series Routers, EX Series Switches, NFX Series Devices, and SRX Series Firewalls
- Configuring Flow Aggregation to Use IPFIX Flow Templates on PTX Series Routers
- Configuring Observation Domain ID and Source ID for Version 9 and IPFIX Flows
- Configuring Template ID and Options Template ID for Version 9 and IPFIX Flows
- Including Fragmentation Identifier and IPv6 Extension Header Elements in IPFIX Templates on MX Series Routers
- Directing Replicated Flows from M and T Series Routers to Multiple Flow Servers
- Logging cflowd Flows on M and T Series Routers Before Export
- Configuring Next-Hop Address Learning on MX Series and PTX Series Routers for Destinations Accessible Over Multiple Paths
-
- play_arrow Real-Time Performance Monitoring and Video Monitoring Services
- play_arrow Monitoring Traffic Using Real-Time Performance Monitoring and Two-Way Active Monitoring Protocol (TWAMP)
- Understanding Using Probes for Real-Time Performance Monitoring on M, T, ACX, MX, and PTX Series Routers, EX and QFX Switches
- Configuring RPM Probes on M, MX and T Series Routers and EX Series Switches
- Understanding Real-Time Performance Monitoring on EX and QFX Switches
- Real-Time Performance Monitoring for SRX Devices
- Configuring RPM Receiver Servers
- Limiting the Number of Concurrent RPM Probes on M, MX, T and PTX Routers and EX Series Switches
- Configuring RPM Timestamping on MX, M, T, and PTX Series Routers and EX Series Switches
- Configuring the Interface for RPM Timestamping for Client/Server on a Switch (EX Series)
- Analyzing Network Efficiency in IPv6 Networks on MX Series Routers Using RPM Probes
- Configuring BGP Neighbor Discovery Through RPM
- Examples: Configuring BGP Neighbor Discovery on SRX Series Firewalls and MX, M, T and PTX Series Routers With RPM
- Trace RPM Operations
- Examples: Configuring Real-Time Performance Monitoring on MX, M, T and PTX Series Routers
- Enabling RPM on MX, M and T Series Routers and SRX Firewalls for the Services SDK
- Understand Two-Way Active Measurement Protocol
- Configure TWAMP on ACX, MX, M, T, and PTX Series Routers, EX Series and QFX10000 Series Switches
- Example: Configuring TWAMP Client and Server on MX Series Routers
- Example: Configuring TWAMP Client and Server for SRX Series Firewalls
- Understanding TWAMP Auto-Restart
- Configuring TWAMP Client and TWAMP Server to Reconnect Automatically After TWAMP Server Unavailability
- play_arrow Managing License Server for Throughput Data Export
- play_arrow Testing the Performance of Network Devices Using RFC 2544-Based Benchmarking
- Understanding RFC 2544-Based Benchmarking Tests on MX Series Routers and SRX Series Firewalls
- Understanding RFC2544-Based Benchmarking Tests for E-LAN and E-Line Services on MX Series Routers
- Supported RFC 2544-Based Benchmarking Statements on MX Series Routers
- Configuring an RFC 2544-Based Benchmarking Test
- Enabling Support for RFC 2544-Based Benchmarking Tests on MX Series Routers
- Example: Configure an RFC 2544-Based Benchmarking Test on an MX104 Router for Layer 3 IPv4 Services
- Example: Configuring an RFC 2544-Based Benchmarking Test on an MX104 Router for UNI Direction of Ethernet Pseudowires
- Example: Configuring an RFC 2544-Based Benchmarking Test on an MX104 Router for NNI Direction of Ethernet Pseudowires
- Example: Configuring RFC2544-Based Benchmarking Tests on an MX104 Router for Layer 2 E-LAN Services in Bridge Domains
- Example: Configuring Benchmarking Tests to Measure SLA Parameters for E-LAN Services on an MX104 Router Using VPLS
- play_arrow Configuring RFC 2544-Based Benchmarking Tests on ACX Series
- RFC 2544-Based Benchmarking Tests for ACX Routers Overview
- Layer 2 and Layer 3 RFC 2544-Based Benchmarking Test Overview
- Configuring RFC 2544-Based Benchmarking Tests
- Configuring Ethernet Loopback for RFC 2544-Based Benchmarking Tests
- RFC 2544-Based Benchmarking Test States
- Example: Configure an RFC 2544-Based Benchmarking Test for Layer 3 IPv4 Services
- Example: Configuring an RFC 2544-Based Benchmarking Test for NNI Direction of Ethernet Pseudowires
- Example: Configuring an RFC 2544-Based Benchmarking Test for UNI Direction of Ethernet Pseudowires
- Configuring a Service Package to be Used in Conjunction with PTP
- play_arrow Tracking Streaming Media Traffic Using Inline Video Monitoring
- Understanding Inline Video Monitoring on MX Series Routers
- Configuring Inline Video Monitoring on MX Series Routers
- Inline Video Monitoring Syslog Messages on MX Series Routers
- Generation of SNMP Traps and Alarms for Inline Video Monitoring on MX Series Routers
- SNMP Traps for Inline Video Monitoring Statistics on MX Series Routers
- Processing SNMP GET Requests for MDI Metrics on MX Series Routers
-
- play_arrow Configuration Statements and Operational Commands
Enabling Passive Flow Monitoring on M Series, MX Series or T Series Routers
You can monitor IPv4 traffic from another router if you have the following components installed in an M Series, MX Series, or T Series router:
Monitoring Services, Adaptive Services, or Multiservices PICs to perform the service processing
SONET/SDH, Fast Ethernet, or Gigabit Ethernet PICs as transit interface
On SONET/SDH interfaces, you enable passive flow monitoring
by including the passive-monitor-mode
statement at the
[edit interfaces so-fpc/pic/port unit logical-unit-number] hierarchy level:
[edit interfaces so-fpc/pic/port unit logical-unit-number] passive-monitor-mode;
On Asynchronous Transfer Mode (ATM), Fast Ethernet, or
Gigabit Ethernet interfaces, you enable passive flow monitoring by
including the passive-monitor-mode
statement at the [edit interfaces interface-name]
hierarchy
level:
[edit interfaces interface-name] passive-monitor-mode;
IPv6 passive monitoring is not supported on Monitoring Services PICs. You must configure port mirroring to forward the packets from the passive monitored ports to other interfaces. Interfaces configured on the following FPCs and PIC support IPv6 passive monitoring on the T640 and T1600 Series routers:
Enhanced Scaling FPC2
Enhanced Scaling FPC3
Enhanced II FPC1
Enhanced II FPC2
Enhanced II FPC3
Enhanced Scaling FPC4
Enhanced Scaling FPC4.1
4-port 10-Gigabit Ethernet LAN/WAN PIC with XFP (supported on both WAN-PHY and LAN-PHY mode for both IPv4 and IPv6 addresses)
Gigabit Ethernet PIC with SFP
10-Gigabit Ethernet PIC with XENPAK (T1600 Series router)
SONET/SDH OC192/STM64 PIC (T1600 Series router)
SONET/SDH OC192/STM64 PICs with XFP (T1600 Series router)
SONET/SDH OC48c/STM16 PIC with SFP (T1600 Series router)
SONET/SDH OC48/STM16 (Multi-Rate)
SONET/SDH OC12/STM4 (Multi–Rate) PIC with SFP
Type 1 SONET/SDH OC3/STM1 (Multi–Rate) PIC with SFP
To configure port mirroring, include the port-mirroring
statement at the [edit forwarding-options]
hierarchy
level.
When you configure an interface in passive monitoring
mode, the Packet Forwarding Engine silently drops packets coming from
that interface and destined to the router itself. Passive monitoring
mode also stops the Routing Engine from transmitting any packet from
that interface. Packets received from the monitored interface can
be forwarded to monitoring interfaces. If you include the passive-monitor-mode
statement in the configuration:
The ATM interface is always up, and the interface does not receive or transmit incoming control packets, such as Operation, Administration, and Maintenance (OAM) and Interim Local Management Interface (ILMI) cells.
The SONET/SDH interface does not send keepalives or alarms and does not participate actively on the network.
Gigabit and Fast Ethernet interfaces can support both per-port passive monitoring and per-VLAN passive monitoring. The destination MAC filter on the receive port of the Ethernet interfaces is disabled.
Ethernet encapsulation options are not allowed.
Ethernet interfaces do not support the
stacked-vlan-tagging
statement for both IPv4 and IPv6 packets in passive monitoring mode.
On monitoring services interfaces, you enable passive
flow monitoring by including the family
statement at the [edit interfaces interface-name unit logical-unit-number]
hierarchy level, specifying
the inet
option:
[edit interfaces interface-name unit logical-unit-number] family inet;
For the monitoring services interface, you can configure multiservice physical interface properties. For more information, see Configuring Flow-Monitoring Interfaces.
For conformity with the cflowd record structure, you
must include the receive-options-packets
and receive-ttl-exceeded
statements at the [edit interfaces interface-name unit logical-unit-number family inet]
hierarchy level:
[edit interfaces interface-name unit logical-unit-number family inet] receive-options-packets; receive-ttl-exceeded;
Passive Flow Monitoring for MPLS Encapsulated Packets
On monitoring services interfaces, you can process MPLS packets
that have not been assigned label values and have no corresponding
entry in the mpls.0
routing table. This allows you to assign
a default route to unlabeled MPLS packets.
To configure a default label value for MPLS packets, include
the default-route
statement at the [edit protocols
mpls interface interface-name label-map]
hierarchy level:
[edit protocols mpls interface interface-name label-map] default-route { (next-hop (address | interface-name | address/interface-name)) | (reject | discard); (pop | (swap <out-label>); class-of-service value; preference preference; type type; }
For more information about static labels, see the MPLS Applications User Guide.
Removing MPLS Labels from Incoming Packets
The Junos OS can forward only IPv4 packets to a Monitoring Services, Adaptive Services, or Multiservices PIC. IPv4 and IPv6 packets with MPLS labels cannot be forwarded to a monitoring PIC. By default, if packets with MPLS labels are forwarded to the monitoring PIC, they are discarded. To monitor IPv4 and IPv6 packets with MPLS labels, you must remove the MPLS labels as the packets arrive on the interface.
You can remove MPLS labels from an incoming packet by including
the pop-all-labels
statement at the [edit interfaces interface-name (atm-options | fastether-options | gigether-options
| sonet-options) mpls]
hierarchy level:
[edit interfaces interface-name (atm-options | fastether-options | gigether-options | sonet-options) mpls] pop-all-labels { required-depth [ numbers ]; }
For MX Series routers with
MPCs, the pop-all-labels
statement pops all labels by default
and the required-depth
statement is ignored.
For other configurations, you can remove up to two MPLS labels
from an incoming packet. By default, the pop-all-labels
statement takes effect for incoming packets with one or two labels.
You can specify the number of MPLS labels that an incoming packet
must have for the pop-all-labels
statement to take effect
by including the required-depth
statement at the [edit
interfaces interface-name (atm-options | fastether-options
| gigether-options | sonet-options) mpls pop-all-labels]
hierarchy
level:
[edit interfaces interface-name (atm-options | fastether-options | gigether-options | sonet-options) mpls pop-all-labels] required-depth [ numbers ];
The required depth can be 1
, 2
, or [ 1 2 ]
. If you include the required-depth 1
statement,
the pop-all-labels
statement takes effect for incoming
packets with one label only. If you include the required-depth
2
statement, the pop-all-labels
statement takes effect
for incoming packets with two labels only. If you include the required-depth [ 1 2 ]
statement, the pop-all-labels
statement takes effect for incoming packets with one or two labels.
A required depth of [ 1 2 ]
is equivalent
to the default behavior of the pop-all-labels
statement.
When you remove MPLS labels from incoming packets, note the following:
The
pop-all-labels
statement has no effect on IP packets with three or more MPLS labels except for MX Series routers with MPCs.When you enable MPLS label removal, you must configure all ports on a PIC with the same label popping mode and required depth.
You use the
pop-all-labels
statement to enable passive monitoring applications, not active monitoring applications.You cannot apply MPLS filters or accounting to the MPLS labels because the labels are removed as soon as the packet arrives on the interface.
On ATM2 interfaces, you must use a label value greater than 4095 because the lower range of MPLS labels is reserved for label-switched interface (LSI) and virtual private LAN service (VPLS) support. For more information, see the Junos OS VPNs Library for Routing Devices.
The following ATM encapsulation types are not supported on interfaces with MPLS label removal:
atm-ccc-cell-relay
atm-ccc-vc-mux
atm-mlppp-llc
atm-tcc-snap
atm-tcc-vc-mux
ether-over-atm-llc
ether-vpls-over-atm-llc
Example: Enabling IPv4 Passive Flow Monitoring
The following example shows a complete configuration for enabling passive flow monitoring on an Ethernet interface.
In this example, the Gigabit Ethernet interface can accept all Ethernet packets. It strips VLAN tags (if there are any) and up to two MPLS labels blindly, and passes IPv4 packets to the monitoring interface. With this configuration, it can monitor IPv4, VLAN+IPv4, VLAN+MPLS+IPv4, and VLAN+MPLS+MPLS+IPv4 labeled packets.
The Fast Ethernet interface can accept only packets with VLAN ID 100. All other packets are dropped. With this configuration, it can monitor VLAN (ID=100)+IPv4, VLAN (ID=100)+MPLS+IPv4, and VLAN (ID=100)+MPLS+MPLS+IPv4 labeled packets.
[edit firewall] family inet { filter input-monitoring-filter { term def { then { count counter; accept; } } } } [edit interfaces] ge-0/0/0 { passive-monitor-mode; gigether-options { mpls { pop-all-labels; } } unit 0 { family inet { filter { input input-monitoring-filter; } } } } fe-0/1/0 { passive-monitor-mode; vlan-tagging; fastether-options { mpls { pop-all-labels required-depth [ 1 2 ]; } } unit 0 { vlan-id 100; family inet { filter { input input-monitoring-filter; } } } } mo-1/0/0 { unit 0 { family inet { receive-options-packets; receive-ttl-exceeded; } } unit 1 { family inet; } } [edit forwarding-options] monitoring mon1 { family inet { output { export-format cflowd-version-5; cflowd 192.0.2.2 port 2055; interface mo-1/0/0.0 { source-address 192.0.2.1; } } } } [edit routing-instances] monitoring-vrf { instance-type vrf; interface ge-0/0/0.0; interface fe-0/1/0.0; interface mo-1/0/0.1; route-distinguisher 68:1; vrf-import monitoring-vrf-import; vrf-export monitoring-vrf-export; routing-options { static { route 0.0.0.0/0 next-hop mo-1/0/0.1; } } } [edit policy-options] policy-statement monitoring-vrf-import { then { reject; } } policy-statement monitoring-vrf-export { then { reject; } }
Example: Enabling IPv6 Passive Flow Monitoring
The following example shows a complete configuration for enabling IPv6 passive flow monitoring on an Ethernet interface.
In this example, the Gigabit Ethernet interface can accept all Ethernet packets. It strips VLAN tags (if there are any) and up to two MPLS labels blindly, and passes IPv6 packets to the monitoring interface. With this configuration, the Gigabit Ethernet interface can monitor IPv6, VLAN+IPv6, VLAN+MPLS+IPv6, and VLAN+MPLS+MPLS+IPv6 labeled packets.
The vlan-tagged Gigabit Ethernet interface can accept only packets with VLAN ID 100. All other packets are dropped. With this configuration, it can monitor VLAN (ID=100)+IPv6, VLAN (ID=100)+MPLS+IPv6, and VLAN (ID=100)+MPLS+MPLS+IPv6 labeled packets.
[edit interfaces] xe-0/1/0 { passive-monitor-mode; unit 0 { family inet6 { filter { input port-mirror6; } address 2001:db8::1/128; } } } xe-0/1/2 { passive-monitor-mode; vlan-tagging; unit 0 { vlan-id 100; family inet6 { filter { input port-mirror6; } } } } xe-0/1/1 { unit 0 { family inet6 { address 2001:db8::1/128; } } } [edit firewall] family inet6 { filter port-mirror6 { term term2 { then { count count_pm; port-mirror; accept; } } } } [edit forwarding options] port-mirroring { input { rate 1; } family inet6 { output { interface xe-0/1/1.0 { next-hop 2001:db8::3; } no-filter-check; } } }