Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Routing Protocols

  • Support for OSPFv2 HMAC-SHA-2 keychain authentication (ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 24.2R1, you can enable OSPFv2 keychain module with HMAC-SHA2 (OSPFv2 HMAC-SHA2) authentication to authenticate packets reaching or originating from an OSPF interface. HMAC SHA2 algorithms include HMAC-SHA2-256, HMAC-SHA2-384, and HMAC-SHA2-512 as defined in RFC 5709, OSPFv2 HMAC-SHA Cryptographic Authentication. We support these algorithms along with HMAC-SHA2-224. This feature ensures smooth transition from one key to another for OSPFv2 with enhanced security. We also support HMAC-SHA1 and HMAC-SHA2 authentication for virtual and sham links.

    To enable OSPFv2 HMAC-SHA2 authentication, configure the keychain keychain-name configuration statement at the [edit protocols ospf area area-id interface interface-name authentication] hierarchy level and the algorithm (hmac-sha2-224 | hmac-sha2-256 | hmac-sha2-384 | hmac-sha2-512) option at the [edit security authentication-key-chains key-chain key-chain-name] hierarchy level.

    To enable keychains authentication support for OSPFv2 virtual links, configure the keychain keychain-name configuration statement at the [edit protocols ospf area area-id virtual-link neighbor-id router-id transit-area area-idauthentication] hierarchy level.

    To enable keychains authentication support for OSPFv2 sham links, configure the keychain keychain-name configuration statement at the [edit protocols ospf area area-id virtual-link neighbor-id router-id transit-area area-idauthentication] hierarchy level.

    [See Understanding OSPFv2 Authentication .]

  • Support for dying-gasp PDU (ACX7024 and ACX7024X)—Starting in Junos Evolved OS 24.2R1, you can enable the dying-gasp functionality.

    Dying gasp is a Operation, Administration, and Maintenance (OAM) link fault management (LFM) protocol data unit (PDU) sent by the local peer to remote peer equipment in the event of a power failure. ACX Series devices support remote fault detection (RFD), which is one of the features of OAM LFM. RFD discovers power failures and sends dying-gasp PDUs to the remote peer. Sending dying-gasp PDU allows the OS to gracefully shut down the link and helps in isolating the fault.

    The dying-gasp functionality is disabled by default. To enable it, use the set system dgasp-int CLI command.

    [See Enabling Dying Gasp Functionality.]

  • Support for SR TI-LFA paths for IS-IS and OSPF (ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, and ACX7509)—Starting in Junos OS Evolved Release 24.2R1, you can configure a point of local repair (PLR) to create a topology-independent loop-free alternate (TI-LFA) backup path for prefix segment identifiers (prefix SIDs) derived from LDP mapping server advertisements. In a network configured with segment routing, IGP uses the LDP mapping server advertisements to derive prefix SIDs. Currently, we don't support LDP mapping server advertisements for IPv6.

    [See Understanding Topology-Independent Loop-Free Alternate with Segment Routing for IS-IS.]

  • Support for SRLG link constraint in FAD and delay normalization (ACX Series and PTX Series)—Starting in Junos OS Evolved Release 24.2R1, we support Flexible Algorithm Definition (FAD) defined constraints related to admin-groups and shared risk link group (SRLG) as defined in RFC 9350, IGP Flexible Algorithm. We also support delay normalization on the listed platforms. During Flexible Algorithm (flex algo) computation, when the measured latency values are not equal and the difference is insignificant, IS-IS advertises this slightly higher latency value as a metric. IS-IS uses this normalized latency delay value instead of the measured delay value.

    To configure flex-algo application-specific SRLG values, include the application-specific statement at the [edit protocols isis interface interface-name level level] hierarchy level.

    To exclude the SRLG constraint from an FAD, use the exclude-srlg statement at the [edit routing-options flex-algorithm name definition] hierarchy level.

    [See delay-measurementlevel, and definition.]

  • HMAC authentication with hash functions for IS-IS (ACX7024, ACX7100-32C, ACX7100-48L, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016 )—Starting in Junos OS Evolved Release 24.2R1, we extend support to IS-IS keychain with the following hash functions:

    • HMAC-SHA2-224

    • HMAC-SHA2-256

    • HMAC-SHA2-384

    • HMAC-SHA2-512

    Currently, IS-IS supports inline authentication using simple password, keyed MD5, and HMAC-SHA1 algorithms with a common keychain. Note that it’s important to have the system time synchronized on all nodes when a keychain is active on an IS-IS session.

    [See Understanding Hitless Authentication Key Rollover for IS-IS.]

  • BGP link bandwidth community (ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008, PTX10016, and PTX12008 )—Starting in Junos OS Evolved Release 24.2R1, BGP can communicate link speeds to remote peers, enabling better optimization of traffic distribution for load balancing. A BGP group can send the link-bandwidth non-transitive extended community over an EBGP session for originated or received and readvertised link-bandwidth extended communities.

    To configure the non-transitive link bandwidth extended community, include the bandwidth-non-transitive:value in the export policy at the [edit policy-options community name members community-ids] hierarchy level.

    To enable the device to automatically detect and attach the link-bandwidth community on a route at import, include the auto-sense statement at the [edit protocols bgp group link-bandwidth] hierarchy level. This feature facilitates the integration of devices with different transmission speeds within the network, enabling efficient traffic distribution based on link speed.

    [See auto-sense, and group (Protocols BGP).]

  • Support for configuring multiple independent IGP instances of OSPFv2 (ACX7024, ACX7024X, ACX7100-32C, ACX7100-48L, ACX7332, ACX7348, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 24.2R1, you can configure and run multiple independent IGP instances of OSPFv2 simultaneously on a router as defined in RFC 6549, OSPFv2 Multi-Instance Extensions.

    With this feature:

    • You can use multiple IGP instances of OSPFv2 to redistribute routes among independent OSPFv2 domains on a single router.

    • You can construct flexible OSPFv2 hierarchies across independent IGP domains.

    • You can achieve a more scalabale OSPFv2 deployment.

    To enable multiple IGP instances of OSPFv2 routing on the routing device, configure ospf-instance igp-instance-name at the [edit protocols ospf] hierarchy level.

    Note:

    Junos OS Evolved does not support configuring the same logical interface with multiple IGP instances of OSPFv2.

    [See Multiple Independent IGP Instances of OSPFv2 Overview.]