Additional Features
We've extended support for the following features to these platforms.
-
BGP autodiscovery underlay in EVPN-VXLAN (ACX7100-32C, ACX7100-48L, PTX10001-36MR, PTX10004, PTX10008, PTX10016, QFX5130-32CD, QFX5700, and QFX5220)
-
Enhanced OISM for IPv4 multicast traffic in EVPN-VXLAN fabrics (ACX7100-32C, ACX7100-48L, ACX7024, ACX7024X, ACX7332, ACX7348, and ACX7509). Support includes:
-
Enhanced optimized intersubnet multicast (OISM) mode—the asymmetric bridge domains model, also called the bridge domains not everywhere (BDNE) model.
With enhanced OISM on these devices, you must configure the
vxlan-extended
host profile at the[edit system packet-forwarding-options system-profile]
hierarchy level.Note:The Packet Forwarding Engine reboots when you change the system profile.
-
MAC-VRF EVPN instances with
vlan-based
orvlan-aware
service types only.On these devices, in the EVPN instance (EVI) you must configure the
conserve-mcast-routes-in-pfe
option at the[edit routing-instances name multicast-snooping-options oism]
hierarchy level. -
IPv4 multicast traffic with IGMPv2, IGMPv3, and IGMP snooping.
-
Server leaf or border leaf OISM device roles.
Note:ACX Series OISM leaf devices can only have multihoming peers that are also ACX Series devices.
-
External multicast source and receiver communication using classic Layer 3 (L3) interfaces only.
[See Overview of Enhanced OISM and How Enhanced OISM Works.]
-
-
Fast reroute and egress link protection support for EVPN E-Tree (ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, ACX7024, and ACX7024X)
[See Fast Reroute for Egress Link Protection with EVPN-VXLAN Multihoming and Convergence in a Multihomed EVPN-MPLS Network.]
-
FlowTapLite support (ACX7100, ACX7332, ACX7348, ACX7509, ACX7024, and ACX7024X)—In Junos OS Evolved FlowTapLite support, there are several differences from the Junos OS support.
-
Optimized intersubnet multicast (OISM) for IPv4 multicast traffic in EVPN-VXLAN fabrics (ACX7332, ACX7348, and ACX7509). Support on these devices includes:
-
Regular OISM mode—the original symmetric bridge domains model, also called the bridge domains everywhere (BDE) model
-
MAC-VRF EVPN instances with
vlan-based
orvlan-aware
service types onlyNote:On these devices, in the EVPN instance (EVI) you must configure the
conserve-mcast-routes-in-pfe
option at the[edit routing-instances name multicast-snooping-options oism]
hierarchy level. -
IPv4 multicast traffic with IGMPv2, IGMPv3, and IGMP snooping
-
Server leaf or border leaf OISM device roles
Note:ACX Series OISM leaf devices can only have multihoming peers that are also ACX Series devices.
-
External multicast source and receiver communication using classic Layer 3 (L3) interfaces only
-
-
SMET Support in EVPN-MPLS (ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, ACX7024, and ACX7024X)
[See Overview of Selective Multicast Forwarding, Configuring the number of SMET Nexthops and multicast-replication.]
-
QSFP-100G coherent ZR optics performance monitoring (ACX7024, ACX7348, and PTX10001-36MR; and the PTX10004, PTX10008, and PTX10016 with the PTX10K-LC1201-36CD and PTX10K-LC1202-36MR line cards installed). Monitor the performance of QSFP-100G coherent ZR optics and receive threshold-crossing alert (TCA) information to efficiently manage the optical transport link. Accumulate performance metrics into 15-minute and 1-day interval bins. Use the
show interfaces transport pm
command to view current and historical performance data.[See optics-options, and show interfaces transport pm.]
-
QSFP-100G-LR coherent ZR optics support (ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7332, and ACX7348). Manage optical transport links efficiently with QSFP-100G-LR coherent ZR optics.
[See optics-options.]
-
QSFP-100G-ER4L coherent ZR optics support (ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7332, and ACX7348). Manage optical transport links efficiently with QSFP-100G-LR coherent ZR optics.
[See optics-options.]
-
Static route tracking using the results of RPM and TWAMP tests (ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, ACX7024, ACX7024X, PTX10001-36MR, PTX10002-36QDD, PTX10003, PTX10004, PTX10008, and PTX10016). We've extended support for static route tracking to Junos OS Evolved and included Two-Way Active Measurement Protocol (TWAMP) test support as well. You use RPM or TWAMP probes to detect link status and to change the preferred-route state on the basis of the probe results. Tracked static routes can be IPv4 or IPv6, and each IPv4 and IPv6 tracked static route supports up to 16 next hops. You can also configure the metric, route preference, and tag values for each IPv4 or IPv6 destination prefix. However, you configure this feature differently on Junos OS Evolved devices; you configure the
sla-tracking
statement at the[edit routing-options]
hierarchy level. For Junos OS, you would configure therpm-tracking
statement at the same hierarchy level.[See Understanding Using Probes for Real-Time Performance Monitoring on M, T, ACX, MX, and PTX Series Routers, EX and QFX Switches, Understand Two-Way Active Measurement Protocol, sla-tracking, and show route sla-tracking.]
-
Support for dynamic list next hop (ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, ACX7024, and ACX7024X)
-
Support for EVPN-MPLS egress link protection (ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, ACX7024, and ACX7024X)
-
Support for hard interface shutdown when a device detects EVPN core isolation conditions (ACX7024, ACX7100-32C, and ACX7100-48L)
[See Layer 2 Interface Status Tracking and Shutdown Actions for EVPN Core Isolation Conditions, network-isolation, and network-isolation-profile.]
-
[See Configuring Q-in-Q Tunneling and Q-in-Q Tunneling and VLAN Translation.]
-
Support for SRv6 LSPs in PCEP (ACX7348 and PTX10002-36QDD). The Path Computation Element Protocol (PCEP) supports all types of SRv6 LSPs, such as PCE-initiated, locally created, and delegated SRv6 LSPs.
[See SRv6 LSP in PCEP.]
-
Support for VPLS multihoming and the mapping of VPLS traffic to specific LSPs (ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, and ACX7509)
[See Configuring VPLS Multihoming and Mapping VPLS Traffic to Specific LSPs.]
-
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.
-
Support for policer and count actions (ACX7332)
-
QSFP-100G coherent ZR optics performance monitoring (ACX7100-32C and ACX7100-48L). Monitor the performance of QSFP-100G coherent ZR optics and receive threshold-crossing alert (TCA) information to efficiently manage the optical transport link. Accumulate performance metrics into 15-minute and 1-day interval bins. Use the show interfaces transport pm command to view current and historical performance data.
[See optics-options and show interfaces transport pm.]
-
Support for L2 VPN and L2 Circuit (ACX7100-32C, ACX7100-48L, ACX7024, ACX7024X, ACX7332, ACX7348, and ACX7509,)
[See Understanding Layer 2 VPNs and Layer 2 Circuit Overview.]
-
Exclude hops in the RSVP LSP path (ACX7332, ACX7509, PTX10002-36QDD, PTX10008)—You can configure a list of hops to be excluded in the label-switched path (LSP) so that RSVP LSPs avoid those hops and links in the traffic engineering (TE) domain. When an RSVP LSP is signaled in the network, the path message carries the excluded list of hops. When the downstream routers perform loose hop expansion, such as inter-domain LSP or abstract node expansion, the transit routers use the same excluded list of hops that the ingress router uses for path computation. This mechanism enables intermediate routers to avoid the routers included in the excluded hop list. The routers try alternative paths to help with the convergence of LSPs when a complete end-to-end path computation is not possible.
Additionally, ingress routers receive PathErr messages and when computing another path, the routers use a PathErr message sender's address to avoid the link or node that generates an error. Transit routers also need this error avoidance information during retry attempts. RFC4814 defines the exclude hop information and is accepted in RSVP signaling.
To configure LSPs to exclude a list of hops, include the exclude statement at the
[edit protocols mpls path path-name next-hop]
hierarchy level. The ingress routers exclude the hops in CSPF computation and are also included in RSVP LSP signaling.