Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Hardware

  • PTX10002-36QDD router (PTX Series)—The PTX10002-36QDD is a fixed-configuration router that features 36 high-density and cost-efficient 800-Gigabit Ethernet (800GbE) ports network ports in a 2-U form factor. With 28.8 terabits per second (Tbps) of throughput, the PTX10002-36QDD is optimally designed for peering, core routing, and infrastructure edge routing roles in cloud provider, service provider, and content provider networks.

    The router supports 2200-W or 3000-W high-voltage HVAC/HVDC and DC power supply units (PSUs) and front-to-back airflow.

    You can channelize the ports on the PTX10002-36QDD and increase the number of interfaces.

    To install the PTX10002-36QDD router and perform initial configuration, routine maintenance, and troubleshooting, see the PTX10002-36QDD Hardware Guide. See Feature Explorer for the complete list of features for any platform.

    Table 1: PTX10002-36QDD Feature Support

    Feature

    Description

    Chassis

    • Support for the following chassis management functionalities:

      • The presence of two ASIC packages enables you to take a Flexible PIC Concentrator (FPC) offline or bring it online to restart the FPC without impacting the power to the FPC.

      • When you connect 3000-watt (W) power supply units (PSUs), the system operates in normal power mode. You can change the operating power mode from normal to power-optimized by using the set chassis mode power-optimized command.

      • The show chassis fpc command displays both PFE and PFE-Instance details.

      • On the router, when you run the request chassis fpc command, you must use pfeinstead of pfe-instance to control the FPC operations. Also, when you run the request chassis fpc command, you must commit the command for both the Packet Forwarding Engines that are present.

      [See Power Mode Management on PTX10002-36QDD, chassis, request chassis fpc, and show chassis fpc.]

    • Support for resiliency features to manage fabric faults, including but not limited to:

      • Auto-heal functionality to recover the faulty link by fixing the errors automatically.

      • All Packet Forwarding Engines disabled when the number of fabric link errors exceeds four in the system.

      You can use the existing CLI commands for the fabric management. The following commands display new or different fields in their outputs:

      • show chassis fabric fpcs displays peer FPC and PFE details because the Packet Forwarding Engines are directly connected to each other.

      • show chassis fabric topology displays only physical link connectivity.

      [See Chassis-Level User Guide, show chassis fabric fpcs, and show chassis fabric topology.]

    • Optics EM policy support. We've extended the Junos Environment Monitoring (EM) policy to include optics temperature sensors for PTX10002-36QDD routers. It includes the following features:

      • The Optics EM policy incorporates periodically polled temperature readings of optical modules in the system to automatically manage the fan speed.

      • Junos OS Evolved automatically triggers optics shutdown for 100GbE, 400GbE, and 800GbE optics when the Fire Shutdown threshold is breached. Auto-recovery is not supported for optics disabled by the EM policy. To re-enable the optics, use the request interface optics-reset command or perform optics online insertion and removal (OIR).

      • EM policy is enabled by default on all 100GbE, 400GbE, and 800GbE optics that are Multi-source Agreements (MSA)-compliant and support diag EEPROM with temperature monitoring. This policy is not applicable for loopback optics and direct attach copper (DAC) cables.

      To disable EM policy or view temperature threshold values, use the following CLI commands:

      • set chassis fpc fpc_slot pic pic_slot port port_no no-temperature-monitoring explicitly disables the EM policy on specific WAN ports.

      • show chassis temperature-thresholds displays the optics temperature threshold values.

      • show chassis environment displays the optics temperature.

      [See chassis-adc-temperature-sensor.]

    • Routing Engine support. The fixed-configuration PTX10002-36QDD router supports an inbuilt Routing Engine represented by the model number RE-JNP10002-36QDD in the CLI.

      The router does not support:

      • A pluggable Routing Engine

      • GRES, as the router does not have a redundant Routing Engine

      • The following operational commands:

        • request chassis routing-engine master acquire

        • request chassis routing-engine master release

      [See show chassis hardware.]

    • Routing Engine resiliency. We've enabled Routing Engine resiliency for the faults related to CPU memory and DIMM. The Routing Engine supports fault-handling actions such as logging errors, raising alarms, sending SNMP traps, and providing indication about an error through the LEDs.

      [See show system errors active.]

    • Support for fabric platform resiliency includes resiliency functionality to manage hardware components such as the FPCs, PSUs, and fans.

      [See show chassis power detail, show chassis fpc, and show chassis fan.]

    • Packet Forwarding Engine resiliency. The software detects, reports, and takes action on Packet Forwarding Engine faults. Actions are taken based on the default configuration or user configuration available for the errors.

      [See show system errors active.]
    Class of service

    • Support for class-of-service (CoS) features, including classifiers (behavior aggregate (BA), fixed, and multifield (MF)), rewrite rules, forwarding classes, loss priorities, transmission scheduling, rate control, and drop profiles.

      [See CoS Features and Limitations on PTX Series Routers.]

    • Support for priority-based flow control (PFC) watchdog, which detects and mitigates PFC pause storms received for PFC-enabled queues.

      We've added the jnxCosWatchdogTxQueueTable table to the SNMP class-of-service (CoS) MIB to show statistics for transmitting PFC queues related to the PFC watchdog. Table entries are indicated by jnxCosWatchdogTxQueueEntry and contain the following objects:

      • jnxCosWatchdogIfIndex—The index of an interface on which PFC and PFC watchdog are enabled.

      • jnxCosWatchdogTxQueueId—The ID of the queue of the PFC-enabled interface.

      • jnxCosWatchdogTxQueueRecoveredCount—The number of times a queue recovered after a PFC pause storm.

      • jnxCosWatchdogTotalPktDrop—The total number of packets dropped due to PFC pause storm mitigation since the device was started.

      • jnxCosWatchdogLastPktDrop—The number of packets dropped due to the last PFC pause storm.

      [See SNMP MIBs and Traps Supported by Junos OS and Junos OS Evolved and PFC Watchdog.]

    • Support for importing existing classifier and rewrite rules to form new rules.

    • Support for priority-based flow control (PFC) at Layer 3 for untagged traffic and explicit congestion notification (ECN).

      [See Understanding PFC Using DSCP at Layer 3 for Untagged Traffic and CoS Explicit Congestion Notification.]

    • Queue-depth monitoring support for virtual output queues. Virtual output queue (VOQ) queue-depth monitoring, or latency monitoring, measures peak queue occupancy of a VOQ. Junos OS Evolved supports VOQ queue-depth monitoring to report peak queue length for a given physical interface for each Packet Forwarding Engine.

      [See VOQ Queue-depth Monitoring.]

    • Support for export of physical interface queue statistics to an outside collector. Use UDP (native) streaming, remote procedure call (gRPC) services, or gRPC network management interface (gNMI) services by using the sensor/junos/system/linecard/interface/queue/. Each physical interface has eight queues. The following counters are exported as part of this sensor for all configured physical interfaces:

      • Transmitted packets and transmitted bytes

      • Red drop packets and bytes

      • Tail drop packets and bytes

      This feature includes zero suppression support. It does not include support for summed-up counters on aggregated Ethernet (ae) interfaces.

      [See sensor (Junos Telemetry Interface) and Guidelines for gRPC and gNMI Sensors (Junos Telemetry Interface).]

    • Hierarchical CoS support. The router supports up to four levels of scheduling on an interface (physical interfaces, logical interface sets, logical interfaces, and queues). The router does not support hierarchical CoS on integrated routing and bridging (IRB) or aggregated Ethernet interfaces. Also, hierarchical CoS schedulers should not include buffer or drop profile configurations.

      To enable hierarchical scheduling, set hierarchical-scheduler at the [edit interfaces interface-name] hierarchy level.

      [See Hierarchical Class of Service in ACX Series Routers.]

    • Support for classification override configured under a forwarding policy.

      [See CoS Features and Limitations on PTX Series Routers and Overriding the Input Classification.]

    Dynamic Host Configuration Protocol

    • DHCPv4 relay agent and DHCPv6 relay agent are supported. The router supports the following DHCP features:

      • DHCP Relay: Layer 3 (L3) interfaces

      • DHCP Relay: Option 82 for Layer 2 VLANs

      • DHCP Relay: Option 82 for L3 interfaces

      • Extended DHCP relay agent

      • Virtual router-aware DHCP (VR-aware DHCP)

      [See Extended DHCP Relay Agent Overview.]

    Hardware

    • Supported transceivers, optical interfaces, and DAC cables. Select your product in the Hardware Compatibility Tool to view supported transceivers, optical interfaces, and DAC cables for your platform or interface module. We update the HCT and provide the first supported release information when the optic becomes available.

      [See Hardware Compatibility Tool .]

    High availability and resiliency

    • BFD support, including:

      • Distributed BFD and BFD-triggered local repair (BFD authentication is not supported.)

      • Independent micro-BFD sessions enabled on a per-member link basis for a LAG bundle

      • Inline BFD

      [See Understanding BFD .]

    • Support for IP-over-IP encapsulation to facilitate IP overlay construction over an IP transport network. An IP network contains edge devices and core devices. To achieve higher scale and reliability among these devices, use an overlay encapsulation to logically isolate the core network from the external network that the edge devices interact with.

      Static configuration or a BGP protocol configuration is used to distribute routes and signal dynamic tunnels. The dynamic-tunnels configuration creates IP-over-IP encapsulation-only tunnels in the Packet Forwarding Engine.

      The router does not support the following features:

      • Dynamic tunnel de-encapsulation operation

      • Next-hop-based statistics for dynamic tunnels

      • IP fragmentation at tunnel start point and path MTU discovery for IPv4/IPv6

      [See Next-Hop-Based Dynamic Tunneling Using IP-Over-IP Encapsulation .]

    • Support for VRRP.

      The following features are not supported for VRRP on Junos OS Evolved:

      • ISSU

      • Proxy ARP

      • MC-LAG

      • Distribution support on aggregated Ethernet interfaces

      • IRB

      • Inline delegation

      [See Understanding VRRP .]

    Interfaces

    • Interface support. The PTX10002-36QDD supports multiple port speeds and various channels under each port. The router supports a maximum port speed of 400 Gbps in low power mode. In standard power mode, it supports a port speed of 800 Gbps, If a port speed is configured (or a port speed is determined by default) without configuring number-of-sub-ports (at the [edit interfaces interface-name] hierarchy level), the port operates in nonchannelized mode.

      [See Port Speed on PTX Routers.]

    • 400G-ZR and 400G-ZR+ support enhancements. We support 400G-ZR and 400G-ZR+ optics enhancements on the PTX10002-36QDD. The enhancements include application selection and configuration of target output power. You can view the advertised applications and switch between the applications.

      [See Features of 400ZR and 400G OpenZR+.]

    • Support for performance monitoring and TCA. We support performance monitoring for the PTX10002-36QDD optical transceiver modules. The current and historical performance monitoring metrics are accumulated into 15-minute and 1-day interval bins. You can view the metrics using the show interfaces transport pm command and manage optical transport links efficiently.

      [See show interfaces transport pm.]

    • Support for timing and synchronization. The PTX10002-36QDD supports Synchronous Ethernet compliant with the following ITU recommendations:

      • G.8262/G.8262.1—Specifies timing characteristics of Synchronous Ethernet equipment clock (EEC).

      • G.8264—Describes the Ethernet Synchronization Message Channel (ESMC).

      [See Synchronous Ethernet Overview.]

    • Support for load balancing under the [edit forwarding-options enhanced-hash-key] hierarchy.

      Load balancing includes:

      • GRE key inclusion for transit IPv4 and IPv6 traffic

      • IP Layer 3 fields

      • IP Layer 4 fields

      • IPv6 flow label inclusion

      • MPLS labels

      • MPLS port data

      • MPLS pseudowire traffic

      • Tunnel endpoint identifier (TEID) inclusion in GPRS tunneling protocol (GTP) packets

      • RSVP-TE load balancing in proportion to LSP bandwidth

      [See enhanced-hash-key.]

    • Support for 128-way equal-cost multipath (ECMP) routing for MPLS transit cases.

      The following features do not support 128-way ECMP:

      • Multicast

      • P2MP

      • MC-LAG

      • Weighted unilist

      • Consistent hashing

      • Link protection (MPLS)

      • Adaptive load balancing

      • Class-based forwarding

    • Support for 256-way ECMP. You can configure a maximum of 256 equal-cost multipath (ECMP) next hops for external BGP (EBGP) peers. This feature increases the number of direct BGP peer connections, which improves latency and optimizes data flow. However, we support 128 ECMP next hops for MPLS routes. Note that we do not support consistent load balancing (consistent hashing) for IPv4 or IPv6 with this feature.

      [See Understanding BGP Multipath.]

    • Support for FTI-based encapsulation and de-encapsulation of IPv4 and IPv6 packets. You can configure IP-IP encapsulation and de-encapsulation on flexible tunnel interfaces (FTIs). The default mode is loopback encap mode.

      Use the bypass-loopback statement at the [edit interfaces fti number unit logical-unit-number tunnel encapsulation ipip] hierarchy level to change the mode to flattened encap mode to achieve line-rate performance.

      [See Tunnel and Encryption Services Interfaces User Guide for Routing Devices.]

    • Support for configuring UDP tunnel encapsulation on FTIs. You can configure encapsulation by using the tunnel encapsulation udp source address destination address statement at the [edit interfaces fti unit unit] hierarchy level.

      Keep in mind the following when configuring this feature:

      • Adding tunnel-termination makes the tunnel a de-encapsulation-only tunnel and encapsulation is disabled.

      • Specifying both the source and destination address is mandatory when you do not configure tunnel-termination.

      • Configuring a variable prefix mask on the source address is not allowed.

      [See encapsulation (interfaces-fti).]

    • GRE tunnel encapsulation using loopback-based interface. You can configure GRE tunnel encapsulation on flexible tunnel interfaces (FTIs) using the loopback interface. Configure encapsulation by using the tunnel encapsulation gre source address destination address statement at the [edit interfaces fti0 unit unit] hierarchy level.

      [See encapsulation (interfaces-fti).]

    • Support for GRE tunnel de-encapsulation using FTIs. Flexible tunnel interfaces (FTIs) support GRE tunnel de-encapsulation. When you enable the tunnel-termination statement at the [edit interfaces fti0 unit unit-number] hierarchy level, tunnels are terminated on the WAN interface before any other actions—such as sampling, port mirroring, or filtering—are applied.

      [See Tunnel and Encryption Services Interfaces User Guide for Routing Devices.]

    • Support for configuring MPLS protocols over FTI tunnels, thereby transporting MPLS packets over IP networks that do not support MPLS. Generic routing encapsulation (GRE) and UDP tunnels support the MPLS protocol for both IPv4 and IPv6 traffic. You can configure encapsulation and de-encapsulation for the GRE and UDP tunnels.

      To allow the MPLS traffic on the UDP tunnels, include the mpls port-number statement at the [edit forwarding-options tunnels udp port-profile profile-name] hierarchy level. To allow the MPLS traffic on the GRE tunnels, include the mpls statement at the [edit interfaces fti0 unit unit family] hierarchy level.

      [See Flexible Tunnel Interfaces Overview.]
    Junos telemetry interface

    • JTI support for Packet Forwarding Engine sensors for usage, network processing unit (NPU) memory, NPU utilization, and pipeline NPU and ASIC. Using the Junos telemetry interface (JTI), you can export statistics using remote procedure call (gRPC) services, gRPC Network Management Interface (gNMI) services, and UDP transport.

      Use these sensors:

      • /junos/system/linecard/packet/usage/

      • /junos/system/linecard/npu/memory/

      • /junos/system/linecard/npu/utilization/

      • /components/component/integrated-circuit/state/

      • /components/component/integrated-circuit/pipeline-counters/

      For pipeline sensors, the four packet and drop counter categories are interface, lookup, queuing, and host interface.

      [See Junos YANG Data Model Explorer.]

    • JTI support for platform sensors. Using the Junos telemetry interface (JTI), you can export platform-specific software and chassis component statistics using remote procedure call (gRPC) services, gRPC Network Management Interface (gNMI) services, and UDP transport.

      Use these sensors:

      • /junos/system/cmerror/

      • /junos/system/linecard/

      • /components/components/

      • /system/alarms/

      • /state/interfaces/

      • /state/chassis/

      [See Junos YANG Data Model Explorer.]

    Layer 2 features
    Layer 3 features

    • Support for the following Layer 3 forwarding features:

      • IPv4

      • IPv6

      • MPLS

      • LAG

      • ECMP

      • MTU checks

      • ICMP

      • OSPF

      • IS-IS

      • ARP

      • NDP

      • BGP

      • BFD

      • LACP

      • LDP

      • RSVP

      • LLDP

      • VRF-lite

      • TTL expiry

      • IP options

      • IP fragmentation

      • DDoS

    MACsec

    • MACsec support in static CAK mode on physical interfaces with dynamic power management. Media Access Control Security (MACsec) is an industry-standard security technology that provides secure communication for traffic on Ethernet links. This device supports MACsec in static connectivity association key (CAK) mode. This device supports MACsec on physical interfaces to enable you to secure your network using any of the following encryption types:

      • GCM-AES-128

      • GCM-AES-256

      • GCM-AES-XPN-128

      • GCM-AES-XPN-256

      This device supports the following MACsec features:

      • Configurable security association key (SAK) rekey period

      • MACsec Key Agreement (MKA) protocol fail-open mode

      • Preshared key (PSK) chains and hitless rollover

      • PSK password encryption using single password

      • Fallback PSK

      • Extended packet numbering (XPN)

      • Jumbo frames

      [See Understanding Media Access Control Security (MACsec).]

    • MACsec dynamic power management support. Use MACsec to secure your network with the knowledge that your device is working to optimize power usage. To save power, the device dynamically powers MACsec blocks on and off based on the MACsec configuration.You might experience minimal traffic loss during the power block transition.

      [See Understanding Media Access Control Security (MACsec).]

    MPLS

    • Support for MPLS FRR. MPLS fast reroute (FRR) provides faster convergence time (less than 50 milliseconds) for RSVP tunnels. The Routing Engine creates backup paths, and the Packet Forwarding Engine installs the backup-path labels and next hops.

      [See Fast Reroute Overview.]

    • Support for MPLS features,including:

      • CLI support for monitoring MPLS label usage

      • Inline MPLS and IPv6 lookup for explicit null

      • 32,000 transit LSPs

      • Explicit null support for MPLS LSPs

      • MPLS label block configuration

      • MPLS over untagged Layer 3 interfaces

      • MPLS OAM: LSP ping

      • JTI: OCST: MPLS operational state streaming (v2.2.0)

      • 2000 ingress LSP support

      • 2000 egress LSP support

      • Entropy label support

      • MPLS: JTI: Junos telemetry interface MPLS self-ping and TE++

      • LDP, including:

        • Configurable label withdraw delay

        • Egress policy

        • Explicit null

        • Graceful restart signaling

        • IGP synchronization

        • Ingress policy

        • IPv6 for LDP transport session

        • Strict targeted hellos

        • Track IGP metric

        • Tunneling (LDP over RSVP)

      • RSVP++

      • RSVP-TE, including:

        • Bypass LSP static configuration

        • Ingress LSP statistics in a file

        • RSVP-TE hitless-MBB with no artificial delays

        • 32,000 transit LSPs

        • Auto bandwidth

        • Class-based forwarding (CBF) with 16 classes

        • CBF with next-hop resolution

        • Convergence and scalability

        • Graceful restart signaling

        • JTI interface statistics and LSP event export

        • LSP next-hop policy

        • LSP self-ping

        • MPLS fast reroute (FRR)

        • MTU signaling

        • Optimize adaptive teardown

        • Node/link protection

        • Refresh reduction

        • Soft preemption

        • Shared Risk Link Group (SRLG)

      • Static LSPs with IPv4 next hop, IPv6 next hop, and IPv6 next hop with next-table support for bypass

      • Traffic engineering, including:

        • TE++: Dynamic ingress LSP splitting

        • Traffic engineering extensions (OSPF-TE and ISIS-TE)

        • Traffic engineering options: bgp, bgp-igp, bgp-igp-both-ribs, and mpls-forwarding

      [See MPLS Applications User Guide .]

    • Support for an increased scale of transit RSVP-TE–signaled MPLS label-switched paths (LSPs) that are enabled with link protection.

    • Enhanced scaling for the following MPLS features:

      • RSVP transit LSPs with link and node protection

      • RSVP ingress and egress LSPs with ultimate-hop popping (UHP) and penultimate-hop popping (PHP)

      • LDP-over-RSVP LSPs

      • Packet Forwarding Engine statistics

      • Fast reroute (FRR) and make before break (MBB)

      • Weighted ECMP

      • Ping and traceroute

      • Clone route

      • Transit statistics

      [See MPLS Applications User Guide .]

    • Support for RSVP-based and LDP-based point-to-multipoint (P2MP) LSPs with graceful restart. In addition, the router supports IP unicast traffic in a label-edge router (LER) role and both IP unicast and multicast traffic in a label-switching router (LSR) role.

      [See Point-to-Multipoint LSPs Overview.]

    • Support for MPLS features P2MP ping and P2MP LSPs traceroute. MPLS ping and traceroute provide the mechanism to detect data-plane failure and isolate faults in the MPLS network. The traceroute or ping is initiated to validate LSP paths on P2MP.

      [See MPLS Applications User Guide .]

    • Optimized fast branch updates. We've refined the method of making fast-branch updates to a multicast replication tree. Now, any membership changes in the tree trigger fast make-before-break (FMBB) re-optimization of the tree and ensure that there is no traffic loss.

      [See Multicast Shortest-Path Tree.]

    Multicast

    • MVPN BIER with MPLS encapsulation. Junos OS Evolved supports the Bit Index Explicit Replication (BIER) architecture to simplify control and forwarding planes by eliminating the need for multicast trees and per-flow states. With BGP-MVPN as an overlay, you can configure BIER-enabled provider tunnels for multicast VPNs.

      [See BIER Overview and bier.]

    • IS-IS as routing underlay for BIER. Junos OS Evolved supports the advertisement of BIER information of one or more BIER subdomains using IS-IS as the IGP underlay. Key BIER information such as BFR IDs and BFR prefixes in each subdomain are flooded through the IS-IS domain to generate the BIER forwarding table.

      [See IS-IS Extension for BIER and bier-sub-domain (Protocols IS-IS).]

    • IPv4 and IPv6 multicast support including MSDP, support for PIM-SM as the first-hop router (FHR) or last-hop router (LHR), and support for anycast, static, or local rendezvous point (RP).

    • Support for multicast-only fast reroute (MoFRR) for both IPv4 and IPv6 traffic flows. MoFRR minimizes multicast packet loss in PIM domains when there are link failures.

      MoFRR is supported for PIM sparse mode (SM) and source-specific multicast (SSM) modes only. Support does not extend to Multipoint LDP-based MoFRR.

      [See Understanding Multicast-Only Fast Reroute.]

    • Support for bidirectional Protocol Independent Multicast (PIM) for multicast traffic.

      [See pim-snooping.]

    Routing policy and firewall filters

    • Support added to hierarchical policers for applying user-selectable bandwidth for premium and non-premium traffic. Use the firewall filter action policer-charge to subtract available bandwidth credits and make bandwidth available to the aggregate policer.

    • Firewall output filtering support using Fast Lookup Filter (FFT) block for line-rate performance of up to 2 billion PPS. The fast-lookup-filter statement from the CLI filter configuration prioritizes output filtering (but not input filtering) on the FFT block. FFT enables support for 128 unique output filters across IPv4, IPv6, or MPLS families.

      [See fast-lookup-filter (PTX).]

    • SNMP MIB support for the jnxFirewallCounterTable object. Junos OS Evolved SNMP extends support for the jnxFirewallCounterTable and its objects:

      • jnxFirewallCounterEntry

      • jnxFWCounterPacketCount

      • jnxFWCounterByteCount

      • jnxFWCounterDisplayFilterName

      • jnxFWCounterDisplayName

      • jnxFWCounterDisplayType

      [See SNMP MIB Explorer.]

    • Firewall filter support. IPv4 and IPv6 firewall filters provide rules that define whether to permit, deny, or forward packets that are transiting an interface on the router from a source address to a destination address.

      [See Firewall Filter Match Conditions and Actions (PTX Series Routers).]

    • Support for filter-based forwarding.

      [See Example: Configuring Filter-Based Forwarding to a Specific Outgoing Interface or Destination IP Address.]

    • Support for SDN-based networks to configure certain router interfaces to pass traffic toward an SDN controller. Use firewall filters to match and redirect packets defined at the [edit services inline-monitoring instance] hierarchy level. Supported match criteria includes IPv4, IPv6, and family any (destination), VLAN ID, and certain traceroute redirect packets.

      [See controller.]

    • Support for firewall filters on discard interfaces. You can apply firewall filters on a discard interface. The action specified by the filter (log or count) is executed before the traffic is discarded. Firewall filters are supported only for IPv4 and IPv6 traffic in the egress direction of the interface.

      [See Configuring Firewall Filters.]

    • Support for firewall features, including:

      • Forwarding IPv4 and IPv6

      • Firewall filter

      • Load balancing

      • MPLS fast reroute

      • Host path

      • Egress peer engineering

      [See Firewall Filter Match Conditions and Actions (PTX Series Routers).]

    • Support for input-chain and output-chain CLI filters. Use multiple levels of CLI filters. The filter chain helps in logically grouping filters with a specific pattern of rules, instead of evaluating all the filter terms in one filter and deciding at the filter's last term. The feature provides you flexibility in modeling the filter as and when it is applicable in the solution. You can configure up to eight filters in both input chains and output chains.

      [See Example: Using Firewall Filter Chains, output-chain, and input-chain.]

    • Support for nested filters, which enable you to reference a common firewall filter by attaching it to multiple firewall policies (a filter being one or more match conditions and corresponding actions). You can bind nested filters to the following interface types:

      • inet—Both input and output directions

      • inet6—Both input and output directions

      • mpls—Input direction only

      You can also bind the filters to routing instances, and in the input direction, in the output direction, or in both directions.

      [See Guidelines for Nesting References to Multiple Firewall Filters and Example: Nesting References to Multiple Firewall Filters.]

    • Support for matching ip-options in IPv4 packet headers. Use the ip-options any match condition to match fields in the IPv4 header and create firewall filter rules to handle the matched packets. Specifying ip-options provides a finer level of control, so for example, you can create a rule to drop any IPv4 packets that do not include at least one IP option in the header. Configure the match condition at the [edit firewall family inet filter name term name from ip-options any] hierarchy level.

      [See Firewall Filter Match Conditions for IPv4 Traffic .]

    • Support for labeling interfaces with specified group IDs from 1 through 255 and matching the interface-group ID on the firewall filter. The filter recognizes which interface the packet comes from and performs actions only specified for a certain interface group.

      [See Understanding BGP Flow Routes for Traffic Filtering .]

    • Firewall filter support for bitwise logical operations for TCP flag match.

      [See Firewall Filter Match Conditions Based on Bit-Field Values .]

    • MPLS filter payload match. IPv4 and IPv6 payload fields match conditions are available for MPLS traffic. Additionally, the following match conditions are available:

      • MPLS header EXP match conditions for MPLS traffic—exp0, exp1, exp0-except, exp1-except. Existing match conditions exp and exp-except will be deprecated.

      • MPLS header Label match conditions for MPLS traffic—label0, label1, label0-except, label1-except. Existing match conditions label and label-except will be deprecated.

      • MPLS header TTL match conditions for MPLS traffic—ttl0, ttl1, ttl0-except, ttl1-except. Existing match conditions ttl and ttl-except will be deprecated.

      • MPLS header Bottom of Stack match conditions for MPLS traffic—bottom-of-stack0 and bottom-of-stack1

      [See Firewall Filter Match Conditions for MPLS Traffic .]

    • Unicast RPF support for both IPv4 and IPv6 traffic flows.

      [See Configuring Unicast RPF Loose Mode.]

    • Enhanced scaling for DoS and protection offers loose mode unicast RPF on IPv4 and IPv6.

      [See Configuring Unicast RPF Loose Mode.]

    • Support for DCU and SCU accounting. Source class usage (SCU) accounting provides a breakdown of output interface traffic statistics that originates from specific prefixes. Destination class usage (DCU) accounting provides a breakdown of input interface traffic statistics that is destined for specific prefixes.

      [See Understanding Source Class Usage and Destination Class Usage Options.]

    • Class-based firewall filters. You can apply firewall filters actions such as drop, reject, sample, and police on packets classified by destination class usage (DCU) and source class usage (SCU) accounting. You can use this feature, for example, as part of a design to provide distributed denial-of-service (DDoS) protection to specific customers.

      [See Configure the Filter Profile.]

    • Support for forwarding class and packet loss priority (PLP) as policer actions. You can use forwarding class (FC), and both FC and PLP together, as policer actions in policer policy configurations. This includes both ingress and egress directions.

    • Support for two-color Layer 3 interface policers (ingress and egress).

      [See Basic Two-Rate Three-Color Policers.]

    • Support for packet-rate policers. You can use a count of packets as the threshold for traffic policers. Per-packet policers can better mitigate low-and-slow types of denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks.

      You can apply packet-level policers in the ingress or egress interface direction. These policers support both two-color and three-color policers. The following families are supported: inet, inet6, mpls, and ethernet-switching .

      Configure per-packet policer rates using the pps-limit (packets per second) and packet-burst-size-limit (packets) configuration statements at the [edit firewall policer policer-name] hierarchy level.

      [See Packets-Per-Second (pps)-Based Policer Overview and pps-limit (Policer).]

    • Shared-bandwidth and percentage policer. Use the shared-bandwidth policer for instances where policers are attached to aggregated Ethernet interface bundles with child legs spanning different Packet Forwarding Engine or Flexible Port Concentrator (FPC) instances. The bandwidth policers program the policer token bucket with weighted bandwidth or burst (depending on the number of child legs per Packet Forwarding Engine).

      The percentage policer feature enables you to configure the bandwidth policer relative to the physical-interface speed where you configure the class-of-service (CoS) shaping rate. After the configuration, the egress policer can then use this base CoS shaping rate instead of the physical-interface speed.

      [See Configure the Filter Profile.]

    • Two-color and three-color traffic policers for input and output traffic. The supported actions are discard, forwarding-class, and loss-priority (high and low). You can attach policers to logical interfaces and the protocol families mpls, inet, and inet6.

      [See Basic Two-Rate Three-Color Policers.]

    • Filter-based GRE encapsulation and de-encapsulation and filter-based MPLS-in-UDP de-encapsulation. We've enabled the following encapsulation and de-encapsulation workflow:

      1. An incoming packet matches a filter term with an encapsulate action. The packet is encapsulated in an IP+GRE header and is forwarded to the endpoint's destination.

        set firewall tunnel-end-point tunnel-name ipv4|ipv6 source-address address
set firewall tunnel-end-point tunnel-name ipv4|ipv6 destination-address address
set firewall tunnel-end-point tunnel-name gre
set firewall family inet|inet6 filter name term name from source-address address
set firewall family inet|inet6 filter name term name then encapsulate tunnel-name
set firewall family inet|inet6 filter name term last then accept
set interfaces interface-name unit number family inet|inet6 filter input
set interfaces interface-name unit number family inet|inet6 address address # This source address differs from the one for the tunnel endpoint.

      2. At the destination, the packet matches a filter term with a de-encapsulate action. The GRE header or MPLS-in-UDP header is stripped from the packet. The inner packet is routed to its destination.

        set firewall family inet|inet6 filter name term name from source-address address
set firewall family inet|inet6 filter name term name from protocol gre
set firewall family inet|inet6 filter name term name then decapsulate gre # Optionally de-encapsulate mpls-in-udp.
set firewall family inet|inet6 filter name term last then accept
set interfaces interface-name unit number family inet|inet6 filter input filter-name
set interfaces interface-name unit number family inet|inet6 address address # This is the destination address.

      [See Components of Filter-Based Tunneling Across IPv4 Networks and tunnel-end-point.]

    • Support for tunnel de-encapsulation using firewall filters for GRE and UDP tunnels.

      [See Configuring a Filter to De-Encapsulate GRE Traffic and decapsulate (Firewall Filter).]

    Routing protocols

    • BGP flow specification. BGP can carry flow-specification network layer reachability information (NLRI) messages on PTX10002-36QDD devices with 14.4 Tbps line cards. Propagating firewall filter information as part of BGP enables you to propagate firewall filters against denial-of-service (DOS) attacks dynamically across autonomous systems.

      The following match conditions are not supported:

      • ICMP codes alone [inet/inet6]

      • Source/destination prefix with offset for inet6

      • Flow label for inet6 fragment [for inet6]

      Junos OS Evolved running on this router doesn't support the traffic marking action.

      To configure flow routes statically, configure the match conditions and actions at the [edit routing-options] hierarchy level.

    • Forwarding IPv6 transit statistics.

      [See BGP User Guide.]
    Network management and monitoring

    • Local port mirroring support. You can use port mirroring to copy packets entering or exiting a port or entering a VLAN and to send the copies to a local interface for local monitoring.

      The following features are included:

      • Interface filter on ingress and egress

      • Forwarding table filter (FTF) on ingress

      • Families inet and inet6

      • Aggregated Ethernet interfaces at both ingress and egress

      Use the following CLI hierarchies to configure port mirroring:

      • [edit interfaces]

      • [edit forwarding-options port-mirroring]

      • [edit firewall filter]

      You can configure family inet and family inet6 in the [edit interfaces] and the [edit forwarding-options port-mirroring] hierarchies for this feature. This feature applies to global port mirroring only.

      [See Understanding Port Mirroring and Analyzers.]

    • Remote port mirroring with ToS or DSCP settings. You can send sampled copies of incoming packets to remotely connected network management software. You send the packets using GRE, which is supported by flexible tunnel interfaces (FTIs). You can set ToS and DSCP values to provide necessary priorities in the network for these packets. You can also apply policing to sampled packets that are leaving the FTI. Configure the settings you need in the [edit forwarding-options port-mirroring instance instance-name output] hierarchy.

      [See instance (Port Mirroring).]

    • Support for additional family any in port mirroring You can configure family any (as well as the earlier family options, inet, and inet6) for local port mirroring and remote port mirroring. You can use the family any configuration option to process the families any, ccc, ethernet-switching, or mpls.

      Note:

      You use the family any configuration option to process all four families.

      Use [edit forwarding-options port-mirroring] for local port mirroring or [edit forwarding-options port-mirroring instance instance-name] for remote port mirroring, with both configurations also requiring a firewall filter.

      The following configuration statements are no longer part of the port mirroring configuration on PTX Series devices:

      • next-hop for family any
      • family vpls
      • no-filter-check
      • hosted-service
      • server-profile

      [See port-mirroring.]

    • Support for EVPN-VXLAN filtering and port mirroring based on VNI match conditions. You can construct a firewall filter to filter EVPN-VXLAN traffic by using the VXLAN network identifier (VNI) values in the match condition on ingress and egress interfaces. This feature supports redirecting traffic to a global port-mirroring instance.

      To filter traffic based on the VNI, use the following commands:

      set firewall filter filter-name term term-name from vxlan vni vni-value
set firewall filter filter-name term term-name from vxlan vni-except vni-value

      vni-value can be a numeric value or range of numeric values.

      [See Firewall Filter Match Conditions and Actions (PTX Series Routers).]

    • Support for the sFlow technology, which is a monitoring technology for high-speed switched or routed networks. The sFlow monitoring technology randomly samples network packets and sends the samples to a monitoring station.

      [See sFlow Monitoring Technology.]

    • sFlow technology support for MPLS interfaces to sample and report MPLS traffic on the routers.

      [See sFlow Technology Overview.]

    • Ingress and egress sFlow functionalities for transit nodes are supported for IPv4-in-IPv4, IPv6-in-IPv4, and regular IPv4/IPv6 traffic. In transit-only devices, the IP-in-IP encapsulated packet can transit through the device without any change or might get de-encapsulated and forwarded or de-encapsulated and encapsulated and forwarded based on the next-hop configuration. Additionally, the packet might traverse through multiple VRF instances while getting forwarded. The router supports ingress and egress sFlow for all those variations.

      [See sFlow Monitoring Technology.]

    • sFlow technology support for exporting extended IPv4 and IPv6 tunnel egress structure. sFlow technology supports the export of the Extended Tunnel Egress Structure fields for traffic entering IPv4 or IPv6 GRE tunnels. These additional attributes provide information about the GRE tunnel into which a packet entering the device will get encapsulated. The GRE tunnel could be IPv4 or IPv6. The feature is supported only when sFlow is enabled in the ingress direction wherein firewall-based GRE happens on IPv4 or IPv6 packets.

      The device supports the feature for the following traffic scenarios when ingress sFlow sampling is enabled:

      • Incoming IPv4 traffic that undergoes IPv4 GRE

      • Incoming IPv6 traffic that undergoes IPv4 GRE

      • Incoming IPv4 traffic that undergoes IPv6 GRE

      • Incoming IPv6 traffic that undergoes IPv6 GRE

      [See sFlow Monitoring Technology.]

    • Sample size support in sFlow. You can configure the sFlow sample size of the raw packet header to be exported as part of the sFlow record to the collector. The configurable range of sample size is from 128 bytes through 512 bytes.

      [See sFlow Monitoring Technology.]

    • Support for passive monitoring, including support for passive monitoring on MPLS-encapsulated packets. You can configure passive monitoring on any interface on the PTX Series routers, and you can use this feature to monitor MPLS-encapsulated packets. After you enable passive monitoring, the router accepts and monitors traffic on the interface and forwards those packets to monitoring tools such as IDS servers and packet analyzers, or to other devices such as other routers or end-node hosts.

      [See Passive Monitoring and passive-monitor-mode.]

    • Support for link fault management (LFM). We support IEEE 802.3ah OAM LFM to monitor point-to-point Ethernet links that are connected either directly or through Ethernet repeaters. The following LFM features are supported:

      • Link discovery with active and passive modes

      • Detect-LOC

      • Remote loopback

      • Loopback tracking

      • Action profile

      • GRES and non-graceful Routing Engine switchover

      [See Introduction to OAM Link Fault Management (LFM).]

    Segment routing

    • Segment routing support. You can configure the following Source Packet Routing in Networking (SPRING) or segment routing features on the router:

      • MPLS (segment routing using IS-IS):

        • Ping and traceroute for single IS-IS node or prefix segment

      • BGP Link State (BGP-LS):

        • Segment routing extensions for IS-IS

        • Segment routing extensions for OSPF

      • BGP:

        • Binding segment identifier (SID) for segment routing–traffic engineering (SR-TE)

        • Binding SID for SR-TE [draft-previdi-idr-segment-routing-te-policy]

        • Programmable routing protocol process APIs for SR-TE policy provisioning

        • Static SR-TE policy with mandatory color specification

        • Static SR-TE policy without color specification

      • IS-IS:

        • Adjacency SID

        • Advertising maximum link bandwidth and administrative color without RSVP-TE configuration

        • Anycast and prefix SIDs

        • Configurable segment routing global block (SRGB)

        • Node and link SIDs

        • Segment Routing Mapping Server (SRMS) and client

        • Topology Independent Loop-Free Alternate (TI-LFA):

          • Link and node protection for IPv4 addressing (not required for IPv6 prefixes)

          • Link and node protection for IPv4 addressing (required for IPv6 prefixes)

          • Protection for SRMS prefixes

      • OSPF:

        • Advertising maximum-link bandwidth and administrative color without RSVP-TE configuration

        • Anycast SID

        • Configurable SRGB

        • Inter-area support

        • Node and link SID

        • Prefix SID

        • Segment Routing Mapping Server (SRMS) and client

        • Static adjacency SID

        • TI-LFA:

          • Link and node protection

          • Protection for SRMS prefixes

          • MPLS ping and traceroute for single OSPF node or prefix segment

          • IGP adjacency SID hold time

          • Path Computation Element Protocol (PCEP) for segment routing LSPs

      • BGP IPv4 labeled-unicast resolution over:

        • BGP IPv4 SR-TE with IPv4 segment routing using IS-IS and OSPF

        • Non-colored IPv4 SR-TE with segment routing using IS-IS and OSPF

        • Static colored IPv4 SR-TE with segment routing using IS-IS and OSPF

      • BGP Layer 3 VPN over:

        • Colored SR-TE tunnels and IPv4 protocol next hops

        • Non-colored SR-TE tunnels and IPv4 protocol next hops

      • BGP-triggered dynamic SR-TE colored tunnels

      • Class-based forwarding and forwarding table policy LSP next-hop selection among non-colored SR-TE LSPs

      • First-hop label support for SID instead of an IP address

      • Path specification using router IP addresses (segment routing segment list path ERO support using IP address as next hop and loose mode)

      • SR-TE color mode:

        • 00—Route resolution fallback to IGP path

        • 01—Route resolution fallback to color only null routes

      • Static LSPs with member-link next hops for aggregated Ethernet bundles (also known as adjacent SID per LAG bundle or aggregated Ethernet member link)

      [See Understanding Source Packet Routing in Networking (SPRING).]

    • Support for scaled-up static and BGP segment routing policies, where each policy contains eight segment routing paths with five labels per path without make-before-break (MBB).

      [See egress-chaining and fib-next-hop-split.]

    • SPRING statistics sensor support for JTI supports export of SPRING statistics to an outside collector by using remote procedure call (gRPC) services. The feature provides the segment-identifier (SID)-level and interface-level traffic counts for SPRING traffic. These statistics reflect the SPRING LSP utilization in the traffic engineering database, which aids in correctly rerouting the RSVP LSPs.

      To enable SPRING statistics, include the following statements on the client device:

      • For egress (per-interface egress), use set protocols isis source-packet-routing sensor-based-stats per-interface-per-member-link egress

      • For egress (per-SID egress), use set protocols isis source-packet-routing sensor-based-stats per-sid egress

      • For ingress (per-SID ingress), use set protocols isis source-packet-routing sensor-based-stats per-sid ingress.

      Use the following sensors to export statistics by means of gRPC services to an outside collector:

      • /junos/services/segment-routing/interface/egress/usage/ for egress (per-interface egress) aggregate SPRING traffic.

      • /junos/services/segment-routing/sid/usage/ for egress (per-SID egress) and ingress (per-SID ingress) aggregate SPRING traffic.

      [See source-packet-routing and Guidelines for gRPC and gNMI Sensors (Junos Telemetry Interface.]

    • BGP and statically configured SR-TE traffic statistics sensor support for JTI.

      [See source-packet-routing, Guidelines for gRPC and gNMI Sensors (Junos Telemetry Interface, and Understanding OpenConfig and gRPC on Junos Telemetry Interface.]

    • Support for segment routing over UDP. Configure the udp-tunneling encapsulation statements at the [edit protocols isis source-packet-routing] hierarchy level to enable SR-MPLS routers and IP-only routers to seamlessly coexist, by encapsulating SR-MPLS label stacks in IP/UDP encapsulation. This feature also supports:

      • Entropy in the UDP source port

      • Underlay and overlay ECMP at the start of the tunnel

      • Policy control to resolve dynamic tunnels

      SR-over-UDP supports tunnels without a loopback stream in the Packet Forwarding Engine, thereby reducing additional bandwidth consumption.

      [See Next-Hop-Based Dynamic Tunnels and source-packet-routing (Protocols IS-IS).]

    • SPRING : JTI : Ingress SR-TE statistics per binding SID and segment list (static, BGP, PCEP paths). Use this feature to provide route statistics for segment routing-traffic engineering (SR-TE) per label-switched path (LSP). Junos OS Evolved uses Junos telemetry interface (JTI) and gRPC services to provide the statistics.

      Supported resource paths (sensors) include:

      • /junos/services/segment-routing/traffic-engineering/tunnel/lsp/ingress/usage/

      • /junos/services/segment-routing/traffic-engineering/tunnel/lsp/transit/usage/

      [See Guidelines for gRPC and gNMI Sensors (Junos Telemetry Interface, source-packet-routing, and show spring-traffic-engineering.]

    • SPRING statistics sensor support for JTI supports export of SPRING statistics to an outside collector by using remote procedure call (gRPC) services and gRPC Network Management Interface (gNMI) services. This feature provides interface-level and segment identifier (SID)-level ingress statistics. The feature also provides egress statistics for each child member at the physical interface level.

      To enable SPRING statistics, include the following statements on the client device:

      • For egress (per-child member at the physical interface level), use the set protocols isis source-packet-routing sensor-based-stats per-interface-per-member-link egress command.

      • For ingress (per-SID ingress and per-interface ingress), use the set protocols isis source-packet-routing sensor-based-stats per-interface-per-member-link ingress command.

      Use the following sensors to export statistics by means of gRPC or gNMI services to an outside collector:

      • /network-instances/network-instance/mpls/signaling-protocols/segment-routing/interfaces/interface/state/in-octets/ for ingress (per-SID ingress and per-interface ingress) SPRING traffic.

      • /network-instances/network-instance/mpls/signaling-protocols/segment-routing/interfaces/interface/state/out-octets/ for egress (per-child member at the physical- interface level) SPRING traffic.

      • /network-instances/network-instance/mpls/signaling-protocols/segment-routing/interfaces/interface/state/out-pkts/ for egress (per-child member at the physical- interface level) SPRING traffic.

      [See Guidelines for gRPC and gNMI Sensors (Junos Telemetry Interface and source-packet-routing.]

    • Support for segment-routing telemetry sensor enhancements. We support segment routing sensor enhancements for SID-level and interface-level traffic counts. These enhancements comply with the current supported sensors in the OpenConfig models openconfig-segment-routing.yang and openconfig-mpls.yang.

    • SR-TE colored policy RIB5 and SR-TE colored telemetry sensor support. We support JTI streaming and ON-CHANGE sensors that deliver operational state statistics for SR-TE colored policy RIB5 and SR-TE colored telemetry sensors. Statistics are delivered to an outside collector using gRPC or gNMI. The feature includes new OpenConfig resource paths for existing and new SR-TE policy (tunnel) and SR-TE per-LSP colored statistics.

      [See Telemetry Sensor Explorer.]

    • Support for SRv6 network programming in IS-IS. Use this feature to configure segment routing in a core IPv6 network without an MPLS dataplane.

      To enable SRv6 network programming in an IPv6 domain, include the srv6 statement at the [edit protocols isis source-packet-routing] hierarchy level.

      To advertise the Segment Routing Header (SRH) locator with a mapped flexible algorithm, include the algorithm statement at the [edit protocols isis source-packet-routing srv6 locator] hierarchy level.

      To configure a TI-LFA backup path for SRv6 in an IS-IS network, include the transit-srh-insert statement at the [edit protocols isis source-packet-routing srv6] hierarchy level.

      [See How to Enable SRv6 Network Programming in IS-IS Networks.]

    • Support for SRv6 network programming and Layer 3 Services over SRv6 in BGP. You can configure BGP-based Layer 3 service over an SRv6 core. You can enable Layer 3 overlay services with BGP as the control plane and SRv6 as the data plane. SRv6 network programming provides flexibility to leverage segment routing without deploying MPLS. Such networks depend only on the IPv6 headers and header extensions for transmitting data.

      To configure IPv4 and IPv6 transport over an SRv6 core, include the end-dt4-sid sid and the end-dt6-sid sid statements at the [edit protocols bgp source-packet-routing srv6 locator name] hierarchy level.

      To configure IPv4 VPN and IPv6 VPN service over an SRv6 core, include the end-dt4-sid sid and the end-dt6-sid sid statements at the [edit routing-instances routing-instance-name protocols bgp source-packet-routing srv6 locator name] hierarchy level.

      [See Understanding SRv6 Network Programming and Layer  3 Services over SRv6 in BGP.]

    • OAM ping support for segment routing with IPv6 (SRv6) network programming. You can perform an Operations, Administration and Management (OAM) ping operation for any SRv6 segment identifier (SID) whose behavior allows upper layer header processing for an applicable OAM payload.

      As segment routing with IPv6 data plane (SRv6) adds only the new type-4 routing extension header, you can use the existing ICMPv6-based ping mechanisms for an SRv6 network to provide OAM support for SRv6. Ping with O-Flag (segment header) is not supported.

      [See ITU-T Y.1731 Ethernet Service OAM Overview and How to Enable SRv6 Network Programming in IS-IS Networks.]

    • Support for SRv6 traceroute. We support the traceroute mechanism for segment routing for IPv6 (SRv6) segment identifiers. You can use traceroute for both UDP and ICMP probes. By default, traceroute uses UDP probes. For ICMP probes, use the traceroute command with the probe-icmp option.

      [See How to Enable SRv6 Network Programming in IS-IS Networks.]

    • SRv6 support for static SR-TE policy. You can configure static segment routing–traffic engineering (SR-TE) tunnels over an SRv6 data plane.

      Use the following configuration commands to enable SRv6 support:

      • For an SR-TE policy: set protocols source-packet-routing srv6

      • For an SR-TE tunnel: set protocols source-packet-routing source-routing-path lsp name srv6

      • For an SR-TE segment list: set protocols source-packet-routing source-routing-path segment-list srv6

      [See Understanding SR-TE Policy for SRv6 Tunnel.]

    Services applications

    • Inline active flow monitoring support.

      [See Understand Inline Active Flow Monitoring.]

    • Juniper Resiliency Interface support.

      [See Juniper Resiliency Interface.]

    • Inline monitoring services support for packet mirroring with metadata.

      [See Inline Monitoring Services Configuration.]

    • Support for additional RPCs for the gNOI certificate management (cert) service. Junos OS Evolved supports the following gRPC Network Operations Interface (gNOI) cert service RPCs:

      • CanGenerateCSR() —Query if the target device can generate a certificate signing request (CSR) with the specified key type, key size, and certificate type.

      • RevokeCertificates()—Revoke certificates on the target device.

      [See gNOI Certificate Management (Cert) Service.]

    • CFM support:

      • Up maintenance association end points (MEPs) in distributed periodic packet management (PPM)

      • Distributed Y.1731 on synthetic loss measurement (SLM), delay measurement (DM), and loss measurement (LM)

      • Down MEPs on bridges, circuit cross-connect (CCC) , and Ethernet VPN (EVPN)

      • Distributed session support for connectivity fault management (CFM) on aggregated Ethernet

      • Enhanced CFM mode

      • IPv4 (inet) support for Data Model (DM) and synthetic loss message (SLM)

      • Action profile for marking a link down, except for EVPN and bridge up MEP

      • LM colorless mode

      • DM and LM on aggregated Ethernet if all active child links are on the same Packet Forwarding Engine

      • Supported CFM protocol data units (PDUs), as follows:

        • Continuity check messages (CCM)

        • LBM

        • LBR

        • Link Trace Message (LTM)

        • Link Trace Reply (LTR)

        • 1DM (one-way delay measurement)

        • Delay measurement message (DMM)

        • Delay measurement reply (DMR)

        • LMM

        • LMR

        • Synthetic loss message (SLM)

        • Synthetic loss reply (SLR)

      • Enterprise and service provider configurations

      • VLAN normalization

      • VLAN transparency for CFM PDUs

      • CoS forwarding class (FC) and CoS packet loss priority (PLP) for CFM

      • CFM session on child physical interface in distributed mode

      • SNMP

      • Chassis ID or Send ID type, length, and value

      • Trunk mode

      • Maintenance association intermediate point (MIP)

      [See Connectivity Fault Management (CFM).]

    • Support for enhanced CFM. The feature extends CFM support to inline mode. Support includes:

      • Up and down maintenance association end points (MEPs) on bridges, circuit cross-connect (CCC), and Ethernet VPN (EVPN) in inline mode

      • ITU-T Y.1731 on synthetic loss measurement (SLM) and delay measurement (DM)

      • Inline session support for connectivity fault management (CFM) on aggregated Ethernet

      • Enhanced CFM mode by default

      • Supported inline performance monitoring (PM) sessions, as follows:

        • PM Tx

        • PM Rx

        • PM responder

      • IPv4 (inet) and IPv6 (inet6) support for continuity check messages (CCM), delay measurement (DM), and synthetic loss message (SLM)

      • DM on aggregated Ethernet with at least one child link on the anchor Packet Forwarding Engine

      • Action profile for marking a link down, except for EVPN and bridge up MEP

      • Supported CFM protocol data units (PDUs) for inline handling, as follows:

        • CCM

        • Delay measurement message (DMM)

        • Delay measurement reply (DMR)

        • Synthetic loss message (SLM)

        • Synthetic loss reply (SLR)

      • Enterprise and service provider configurations

      • VLAN normalization

      • VLAN transparency for CFM PDUs

      • Combination of up MEP, down MEP, or maintenance association intermediate point (MIP) configuration over the same interface

      [See Connectivity Fault Management (CFM).]

    Security services

    Software installation and upgrade

    • Support for secure BIOS and secure boot implementation based on the UEFI 2.4 standard.

      [See Secure Boot.]

    VPNs

    • MPLS-based Layer 3 VPNs support includes:

      • MPLS over Layer 3 VLAN-tagged subinterfaces

      • Per-next-hop label allocation

      • Mapping of the label-switched interface (LSI) logical interface label to the VPN routing and forwarding (VRF) routing table using the vrf-table-label statement

      • ICMP tunneling and MPLS traceroute

      • Disabling time-to-live (TTL) decrementing using no-propagate-ttl

      [See Layer 3 VPNs Feature Guide for Routing Devices.]

    • Carriers-of-carriers and inter-AS VPN supported features include:

      • Carrier-of-carriers VPN service

      • Interprovider Layer 3 VPN Option A

      • Interprovider Layer 3 VPN Option B

      • Interprovider Layer 3 VPN Option C

      However, traffic statistic collection for BGP labeled unicast is not supported for carrier-of-carrier VPNs and interprovider traffic.

      [See Carrier-of-Carrier VPNs.]

    • Layer 2 VPN feature support includes:

      • Transport of Layer 2 frames over MPLS (LDP signaling)

      • Layer 2 VPNs over tunnels (BGP signaling)

      • Simple Ethernet and VLAN-based cross-connect (also known as connections)

      • Local and remote switching

      • Ethernet and VLAN CCC

      • Single-tagged CCC logical interfaces

      • Control word

      • Regular and aggregated Ethernet interfaces

      • Layer 2 protocol pass-through

      • Layer 2 circuit backup interface and backup neighbor

      • Layer 2 circuit statistics and CoS

      • VCCV with type 2 and type 3

      [See Layer 2 VPNs and VPLS User Guide for Routing Devices and TCC Overview.]

  • Supported transceivers, optical interfaces, and DAC cables—Select your product in the Hardware Compatibility Tool to view supported transceivers, optical interfaces, and direct attach copper (DAC) cables for your platform or interface module. We update the HCT and provide the first supported release information when the optic becomes available.