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 thealgorithm (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
hierarchy level.area-id
authentication]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
hierarchy level.area-id
authentication] - Support for OSPFv2 weighted ECMP (PTX10001-36MR,
PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Junos
OS Evolved Release 24.2R1, you can enable weighted ECMP for directly connected routers. In
Junos OS Evolved releases earlier than Release 24.2R1, the Junos OS Evolved ECMP algorithm
does not take the underlying bandwidth into consideration. The algorithm assumes that the
links are of equal capacity, and the traffic is forwarded and distributed equally based on
this assumption.
To enable weighted ECMP traffic distribution on directly connected OSPFv2 neighbors, configure the
weighted one-hop
statement at the[edit protocols ospf spf-options multipath]
hierarchy level.[See Understanding Weighted ECMP Traffic Distribution on One-Hop OSPF Neighbors.]
-
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).]
-
Enable RFC 7606-based error handling in BGP (PTX10008) —Starting in Junos OS Evolved Release 24.2R1, we support RFC 7606, Revised Error Handling for BGP UPDATE Messages that revises the BGP error handling by default. If the errors can be tolerated, BGP recommends that you use the attributes
discard
andtreat-as-withdraw
instead of a session reset. However, if the errors are too severe, BGP triggers a session reset. The session reset minimizes the impact of a malformed update message on routing by retaining the established sessions and valid routes.The
bgp-error-tolerance
statement at[edit protocols bgp]
hierarchy level is enabled by default. You can still configure suboptions such asmalformed-route-limit
,malformed-update-log-interval
, andno-malformed-route-limit
under this configuration statement. Note that If you delete thebgp-error-tolerance
statement, the feature will still remain enabled, but the suboptions are reset to their default values. -
Support for BGP VPN to global RIB import (PTX10001-36MR)—Starting in Junos OS Evolved Release 24.2R1, we support leaking of BGP VPN routes to global routing information bases (RIBs) to provide service providers the flexibility to allow Internet access to VPN customers. To configure this feature, include the
vpn-global-import policy
statement at the[edit routing-options inet.0]
hierarchy level.To use the automatic router discovery feature with the router ID without allocating an IP-address, include the
route-distinguisher-id-use-router-id
statement at the[edit routing-options]
hierarchy level.[See route-distinguisher-id-use-router-id, and vpn-global-import.]
-
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.]
-
-
Support IPv6 address for seamless BFD over static segment routing MPLS LSPs (PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 24.2R1, PTX Series devices support the IPv6 address family for seamless Bidirectional Forwarding Detection (S-BFD) over static segment routing MPLS LSPs. The mode of operation for sBFD support for IPv6 in centralized and distributed mode is as follows:
-
IPv6 support for sBFD over static segment routing MPLS LSP for responder and initiator in distributed mode.
-
IPv6 support for sBFD over static segment routing MPLS LSP for initiator in centralized mode.
You can configure the sBFD IPv6 responder session only by including the
local-ipv6-address
statement at the[edit protocols bfd sbfd local-discriminator disc]
hierarchy level as follows:user@host# set protocols bfd sbfd local-discriminator disc local-ipv6-address ipv6-address
The configured IPv6 address is used as the source IPv6 address in the reply packet.
-