Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Routing Protocols

  • BMP local RIB monitoring support for all RIBs with sharding (ACX Series, PTX Series, and QFX Series)—Starting in Junos OS Evolved Release 22.4R1, you can configure a policy to monitor routing information bases also known as routing table (RIBs) of virtual routers and virtual routing and forwarding instances (VRF). You can specify two separate sets of RIBs in the BGP Monitoring Protocol (BMP), one for monitoring and the other for reporting. With this feature BMP can filter traffic based on the routes and routing-instances.

    [See BGP Monitoring Protocol, loc-rib, and rib-list.]

  • Keep bypass tunnels operational during configuration changes (PTX10001-36MR, PTX10003, PTX10004, PTX10008, and PTX10016)—Starting in Junos OS Evolved Release 22.4R1, you can configure the OS to keep bypass tunnels operational until the tunnels no longer carry local repair traffic, even during configuration changes. Bypass tunnels that carry local repair traffic are in the BackupActive state. When you change the bypass-related configuration on software releases containing this feature, the OS keeps any bypass tunnels that are in BackupActive state up. When the bypass tunnels are no longer in BackupActive state, the operating system tears down the bypass tunnels. This feature ensures that all local repair traffic reaches its destination and prevents traffic loss on label-switched paths (LSPs).

    Configure this feature at the [edit protocols rsvp interface all link-protection] hierarchy level. Use theshow rsvp session bypass command to check whether the bypass routes protecting an interface remain operational in BackupActive state after the configuration changes.

    [See link-protection (RSVP) and Link Protection for MPLS LSPs.]

  • OSPF FAPM and inter area support (ACX7100-32C, ACX7100-48L, PTX10001-36MR, PTX10003, PTX10008, and PTX10016)—Starting with Junos OS Evolved Release 22.4R1, the Flexible Algorithm Prefix Metric (FAPM) is defined to allow an optimal end-to-end path for an inter-area prefix. The Area Border Router (ABR) must include the FAPM when advertising the prefix between areas that are reachable in that given Flexible Algorithm (flex algo). When a prefix is unreachable, the ABR must not include that prefix in the flex algo when advertising between areas. The defined FAPM provides inter-area support.

    [See Understanding OSPF Flexible Algorithm for Segment Routing.]

  • TCP-AO and TCP MD5 authentication support prefixes for LDP and BGP (ACX7100-32C, ACX7100-48L, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008, PTX10016, QFX5130-32CD, QFX5220, and QFX5700)—Starting in Junos OS Evolved Release 22.4R1, we have extended TCP Authentication Option (TCP-AO) and TCP MD5 to support IP subnets for BGP and LDP sessions. When you configure TCP authentication with a network address and a prefix length, your chosen TCP authentication method authenticates TCP connections to the entire range of addresses under that subnet. This means you can authenticate TCP connections without needing to know the exact IP addresses of the destination devices.

    When IP subnets overlap, the authentication method uses the longest prefix match (LPM) to determine the exact authentication key for a specific TCP session.

    [See TCP.]

  • TCP-AO and TCP MD5 authentication are VRF aware for LDP and BGP (ACX7100-32C, ACX7100-48L, ACX7509, PTX10001-36MR, PTX10003, PTX10004, PTX10008, PTX10016, QFX5130-32CD, QFX5220, and QFX5700)—Starting in Junos OS Evolved Release 22.4R1, TCP Authentication Option (TCP-AO) and TCP MD5 authentication are VRF aware in BGP and LDP sessions. You can configure TCP-AO and TCP MD5 under non-default routing instances. The TCP authentication method you configure under a routing instance is only applied to the TCP sessions inside that VRF instance. If a TCP connection in a different VRF instance has the same destination IP address, the TCP authentication method does not get applied to that TCP connection if the VRF instance does not have TCP authentication configured for the peer.

    [See TCP.]