Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Routing Protocols

  • Maximum reference bandwidth increased to 4 TB for IGP protocols (ACX7100-32C, ACX7100-48L, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008, PTX10016, QFX5130-32CD, QFX5700, and QFX5220)—Starting with Junos OS Evolved Release 22.3R1, we've increased the maximum reference bandwidth for IS-IS and OSPF interior gateway protocol (IGP) protocols from 1 Tbps to 4 Tbps. The default bandwidth is 100 Mbps. You can increase the reference bandwidth to adjust the path metrics, which you use to determine the preferred path in case of multiple equal-cost routes to a destination.

    To configure the reference bandwidth, use the reference-bandwidth reference-bandwidth statement at the [edit protocols isis] hierarchy level or the [edit protocols (ospf | ospf3)] hierarchy level.

    [See reference-bandwidth (Protocols IS-IS) and reference-bandwidth (Protocols OSPF).]

  • Support for BGP flowspec (QFX5130-32CD and QFX5220)—Starting with Junos OS Evolved Release 22.3R1, we support traffic flow specification, a distributed denial of service (DDoS) mitigation solution that provides traffic filtering and rate-limiting capabilities. A BGP speaking device identifies packets that match conditions defined in a flow specification. The device distributes these packets according to the listed actions.

    [See Understanding BGP Flow Routes for Traffic Filtering.]

  • Fast lookup of origin and neighbor ASs (ACX7100-32C, ACX7100-48L, ACX7509, PTX10001-36MR, PTX10004, PTX10008, PTX10016, QFX5130-32CD, QFX5700, and QFX5220)—Starting in Junos OS Evolved Release 22.3R1, you can use the new asregex-optimize configuration statement at the [edit policy-options defaults] hierarchy level to perform a fast lookup of origin and neighbor autonomous systems (ASs). The asregex-optimize configuration statement is not enabled by default.

    [See Improve the Performance of AS Path Lookup in BGP Policy.]

  • Sharding support for conditional route manager (PTX10001-36MR, PTX10003, PTX10004, PTX10008, and QFX5130-32CD)—Starting in Junos OS Evolved Release 22.3R1, we support sharding for conditional route manager to fetch active route information from the main thread for conditions. Using this approach, the condition manager on the shard interacts with the route target (RT) proxy client to get active route information. The condition manager on the main thread interacts with the RT proxy server to send details to shards. The condition manager on shards stores active route information that is TRUE or FALSE for any condition and evaluates policy (having the condition) based on that. No change in the condition manager occurs on the main thread with respect to route lookup, flash mechanism, or dependent route operations such as additions or deletions.

    We have updated the following command outputs:

    • show policy condition

    • show policy condition detail

    • show policy condition <condition-name>

    • show policy condition <condition-name> detail

    • show policy condition rib-sharding <shard-name>

    • show policy condition detail rib-sharding <shard-name>

    • show policy condition <condition-name> rib-sharding <shard-name>

    • show policy condition <condition-name> detail rib-sharding <shard-name>

    [See Routing Policy Match Conditions, rib-sharding, and show policy conditions.]

  • Strip/replace BGP private-AS support (ACX7100-32C, ACX7100-48L, ACX7509, PTX10001-36MR, PTX10004, PTX10008, PTX10016, QFX5130-32CD, QFX5130-48C, QFX5700, and QFX5220)—Starting in Junos OS Evolved Release 22.3R1, we have introduced the strip-as-path policy option. This policy option removes the incoming Autonomous System (AS) path, AS_PATH, as part of the import policy for a BGP session. This policy option also replaces the received AS_PATH with the receiving router's local-AS number for the receiving session. Note that the local-AS number may be different from the number configured under the autonomous-system at the [edit routing-options] hierarchy level.

    If you need to normalize externally injected routes, you can use this policy option for the incoming AS_PATH so that it can be used similarly to routes that originate solely within the fabric. The new strip-as-path policy option has no impact on the BGP export policy.

    You can configure the strip-as-path option from the policy-options then clause:

    set policy-options policy-statement do-strip term a then strip-as-path

    [See Autonomous Systems for BGP Sessions.]

  • Origin validation communities conversion to keywords (PTX10001-36MR, PTX10008, PTX10016, QFX5130-32CD, and QFX5220)—Starting in Junos OS Release Evolved 22.3R1, you can choose to accept or reject the origin validation extended communities received from an external BGP (EBGP) peer. The default behavior of Origin Validation State Extended Community (OVS EC) is changed to rejected if received from an EBGP peer. You can configure OVS EC to accept the community when needed. We also support the configuration of distinguished communities with keywords (valid, invalid, and unknown) at all the three layers of the BGP configuration hierarchy: global, group, and per-neighbor. If you enable the OVS EC at a hierarchy level, it’s enabled for the lower levels as well. However, you can choose to disable it explicitly at a lower layer if required in any instance.

    To accept origin validation communities from an EBGP peer, use origin-validation accept at the [edit protocols bgp ebgp-community-cleanup], edit protocols bgp group <group-name> ebgp-community-cleanup], or [edit protocols bgp group <group-name> neighbor <address> ebgp-community-cleanup] hierarchy level.

    To reject origin validation communities from an EBGP peer, use origin-validation reject at the [edit protocols bgp ebgp-community-cleanup], edit protocols bgp group <group-name> ebgp-community-cleanup], or [edit protocols bgp group <group-name> neighbor <address> ebgp-community-cleanup] hierarchy level.

    [See BGP Origin Validation.]