Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Services Applications

  • Inline active flow monitoring IP Flow Information Export (IPFIX) and version 9 template support for CoS policy-map name reporting in the ingress direction (PTX10002-36QDD)—We support a new Juniper-specific enterprise Information Element ID, 32765, in the data record templates ip4-template and ipv6-template. This IE ID is four bytes long and contains the first four characters of the policy-map name. Ensure the first four letters of your policy-map are unique.

    Configure this IE ID with the include-policy-map-name statement at the [edit services flow-monitoring (version-ipfix|version9) template-name data-record-fields] hierarchy level. Configure policy maps at the [edit class-of-service policy-map] hierarchy level.

    [See data-record-fields, Understand Inline Active Flow Monitoring, and Assigning Rewrite Rules on a Per-Customer Basis Using Policy Maps.]

  • Inline active flow monitoring multiple BGP next-hop support (PTX10001-36MR, PTX10002-36QDD, PTX10003, PTX10004, PTX10008, and PTX10016)—We have added support for reporting an accurate BGP next-hop address for the load-balanced traffic over multiple BGP peers in the ingress direction. Previously, we reported only the first address in a list of BGP next hops. To contain the accurate BGP next-hop address, we use the IPv4 BGP Nexthop Address (IE 18) field in the IPv4 and MPLS-IPv4 templates and the IPv6 BGP Nexthop Address (IE 63) field in the IPv6 and MPLS-IPv6 templates, for both the IPFIX and the version 9 formats.

    To configure this feature, include the nexthop-learning enable statement at the [edit services flow-monitoring (version-ipfix | version9) template] hierarchy level. When you enable this feature, the fragmentIdentification (IE 54) field reports a value of 0.

    [See Understand Inline Active Flow Monitoring and nexthop-learning.]

  • RFC 8402 SR support for TWAMP probes (PTX10002-36QDD, PTX10004, PTX10008, and PTX10016)—We have added support in Two-Way Active Measurement Protocol (TWAMP) for segment routing (SR) as defined in RFC 8402, which broadly specifies the SR architecture. We support two types of SR for TWAMP probes:

    • SR-MPLS: Uses a list of labels, each representing a segment end node.

    • SRv6: Uses a type 4 IPv6 routing header introduced in RFC 8754, with each segment end node represented as an IPv6 address or IPv6 segment identifier (SID).

    You can specify the list of SR-MPLS or SRv6 segments for a TWAMP probe to reach the reflector. In addition, you can specify the same information for the return path from the reflector to the client. This return path information is embedded in the probe itself by using the extensions proposed in Simple TWAMP (STAMP) Extensions for Segment Routing Networks, draft-ietf-ippm-stamp-srpm, namely the return path TLV and its return segment list sub-TLVs, as appropriate depending on the segment routing type. The TWAMP probes are timestamped in either the Routing Engine or the Packet Forwarding Engine.

    To configure this feature, include the source-routing statement at the [edit services monitoring twamp client control-connection name test-session session-name hierarchy level.

    [See Understand Two-Way Active Measurement Protocol and source-routing.]