- 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
Mapping Between Field Values for Version 9 Flow Templates and Logs Exported From an MX-Series Router or NFX250
The following table describes different field IDs or values for flow monitoring logs generated for NAT events in version 9 flow record formats and the events that correspond to the field values:
Field ID | Name | Size (Bytes) | Description |
---|---|---|---|
8 | ipv4 src address | 4 | IPv4 source address |
225 | natInsideGlobalAddress | 4 | It reports a modified value caused by a NAT middlebox (forwarding class and loss priority) represents function after the packet passed the Observation Point. |
12 | ipv4 destination address | 4 | IPv4 destination address |
226 | natOutsideGlobalAddress | 4 | It reports a modified value caused by a NAT middlebox function after the packet passed the Observation Point. |
7 | transport source-port | 2 | TCP/UDP source port |
227 | postNAPTSourceTransportPort | 2 | It reports a modified value caused by a Network Address Port Translation (NAPT) middlebox function after the packet passed the Observation Point. |
11 | transport destination-port | 2 | TCP/UDP destination port |
228 | postNAPTDestinationTransportPort | 2 | It reports a modified value caused by a Network Address Port Translation (NAPT) middlebox function after the packet passed the Observation Point. |
234 | ingressVRFID | 4 | Unique identifier of the VRF name where the packets of this flow are being received. This identifier is unique per Metering Process. |
235 | egressVRFID | 4 | Unique identifier of the VRF name where the packets of this flow are being sent. This identifier is unique per Metering Process. |
4 | Ip protocol | 1 | IP protocol byte |
229 | natOriginatingAddressRealm | 1 | Indicates whether the session was created because traffic originated in the private or public address realm. postNATSourceIPv4Address, postNATDestinationIPv4Address, postNAPTSourceTransportPort, and postNAPTDestinationTransportPort are qualified with the address realm in perspective. The allowed values are: Private: 1 Public: 2 |
230 | natEvent | 1 | Indicates a NAT event. The allowed values are: 1 - Create event. 2 - Delete event. 3 - Pool exhausted. A Create event is generated when a NAT translation is created, whether dynamically or statically. A Delete event is generated when a NAT translation is deleted. |
1 | inBytes | N | Incoming counter with length N x 8 bits for the number of bytes associated with an IP Flow. By default N is 4 |
2 | inPkts | N | Incoming counter with length N x 8 bits for the number of packets associated with an IP Flow. By default N is 4 |
323 | observationTimeMilliseconds | 8 | Specifies the absolute time in milliseconds of an observation that represents a time value in units of milliseconds based on coordinated universal time (UTC). The choice of an epoch, for example, 00:00 UTC, January 1, 1970, is left to corresponding encoding specifications for this type. Leap seconds are excluded. Note that transformation of values might be required between different encodings if different epoch values are used. |
27 | sourceIPv6Address | 16 | IPv6 source address |
284 | natPoolName | 64 | NAT resource pool name |
361 | portRangeStart | 2 | The port number identifying the start of a range of ports. A value of zero indicates that the range start is not specified, ie the range is defined in some other way. |
362 | portRangeEnd | 2 | The port number identifying the end of a range of ports. A value of zero indicates that the range end is not specified, and the range is defined in some other way. |
363 | portRangeStepSize | 2 | The step size in a port range. The default step size is 1, which indicates contiguous ports. A value of zero indicates that the step size is not specified, and the range is defined in some other way. |
364 | portRangeNumPorts | 2 | The number of ports in a port range. A value of zero indicates that the number of ports is not specified, and the range is defined in some other way. |
Consider a sample scenario of a NAT address creation event. Based on the fields in the preceding table, for translations that are not available (such as natOutsideGlobalAddress) is set to 0. Ingress and Egress VRF of the flow can be made available. Also, natEvent is equal to 1 (create). The inBytes field is assumed to be 0 or number of bytes of the incoming packet and the inPkts field is either 0 or 1 because it is the first packet into the system when translation happens. The observationTimeMilliseconds field denotes the time when this address translation creation is recorded.
For a NAT address deletion event, for translations that are not available (such as natOutsideGlobalAddress) is set to 0. Ingress and Egress VRF of the flow can be made available. Also, natEvent is equal to 2 (create). The inBytes field denotes the number of bytes for this flow in both the forward or upward, the value of the inPkts field denotes the number of packets for this flow in both the upward and backward directions. observationTimeMilliseconds is the time when this deletion of translation is recorded.
When the NAT pool is exhausted and no further addresses are remaining for allocation, for translations that are not available (such as natOutsideGlobalAddress) is set to 0. Ingress and Egress VRF of the flow can be made available. Also, the natEvent field is set to 3 (Pool exhausted). All resource failures are combined as a single event. The inBytes field is assumed to be 0 or number of bytes of the incoming packet and the inPkts field is either 0 or 1 because it is the first packet into the system when translation happens. The value of the observationTimeMilliseconds field is the time when this failed translation is recorded.