New Features

Device Life-Cycle Management

Device life-cycle management (LCM) extends over the entire life cycle of a device. As part of device LCM, you install the device onsite, bring the device under management, monitor the device when it is in production, and finally decommission the device.

Juniper Routing Director Release 2.9.0 provides the following additional device LCM features:

• Device Support—Routing Director Release 2.9.0 provides basic support for PTX10002-60MR devices. You can onboard devices, view inventory, view and export device details, and configure the device using configuration templates.

  For a list of all devices supported by Routing Director, see Supported Junos OS Releases, Devices, and Browsers.

• Enhanced network implementation plan page—The network implementation plan name is a clickable link on the Network Implementation Plan page (Inventory > Onboarding Dashboard > Network Implementation Plan). When you click the plan name, the link opens the Plan-Name Details page, enabling you to view key information in the following tabs:

  • Properties—View general properties such as name, service design version, and status message and other key attributes.

  • Order Status—View the status of the most recent service order executed for the plan.

  • Active Assurance—View the count and result of Active Assurance Tests and Monitors used to check the quality of device connections in the plan.

  • Order History—View the history of all service orders generated for the plan.

  • Configurations—View the configurations of devices managed by the plan.

  [See About the Network Implementation Plan Page.]

• Enhanced interface modeling in network implementation plans—Routing Director provides an improved interface modeling framework in a network implementation plan, by separating IFDs (physical interfaces) and IFLs (ogical interfaces). A physical interface can now host more than one logical interface, and the physical and logical interfaces can be configured separately.

  Existing network implementation plans are automatically upgraded and mapped to the new IFD and IFL model based on their configurations.

  [See Add a Network Implementation Plan.]

• Enable artificial-intelligence and machine-learning (AI-ML) use cases on Juniper devices during onboarding—We have added an AIOPs section is added to the Analytics tab of the Add Device Profile page (Inventory > Devices > Device and Interface Profiles > Add > Device Profile) so that you can configure all AI-ML use cases at one place. When you apply a device profile to a device through a network implementation plan during onboarding, the selected AI-ML use case configurations are committed on the device.

  Note:

  Enabling AI-ML use cases requires additional CPU, memory, and storage resources. For detailed information on the required capacity for AI-ML operations, see System Requirements on Hypervisors or System Requirements for AWS.

  [See Add a Device Profile.]

• Vendor-agnostic device management framework— Enhanced gRPC‑based management capabilities now support a vendor‑agnostic device management framework. This enhancement will eventually allow Routing Director to manage a wide range of network devices from different vendors in addition to Cisco and Nokia devices.

  Standardized management interactions improve device interoperability between different devices, increases operational flexibility, and allow management of new device types. You no longer need to specify the MAC address, vendor, device model, and OS for the device when adopting devices to Routing Director.

• Bulk import brownfield Juniper devices to Routing Director—A superuser can import multiple brownfield Juniper devices to Routing Director by:

  • Uploading a .csv file.

  • Creating a batch of devices manually for import.

  You can bulk import devices using the Device Batches page (Inventory > Devices > Device Batches) for the bulk import of devices. After the import, Routing Director connects with the imported device and onboards or adopts it.

  [See About the Batch Imports Page.]

Observability

You can use Routing Director to view your entire network topology in real time and monitor network health. Additionally, you receive notifications about network anomalies and troubleshooting guidance.

With observability, Routing Director monitors and analyzes the network and its components by using key performance indicators (KPIs), device logs, and metrics. Observability includes alerts and alarms that notify you about network issues.

Routing Director also runs connectivity tests using synthetic traffic to identify connection issues between devices in your network. In addition, the real-time routing dashboard allows you to actively monitor the overall routing health of your network. Timely detection of anomalies enables you to take prompt action and minimize the impact of any issues.

Juniper Routing Director Release 2.9.0 provides the following additional observability features:

• Observability Recommendation Engine—Observability Recommendation Engine evaluates device configurations, device inventory attributes (platform/OS/version), and user-defined preferences. Based on the device configurations, this feature automatically generates KPI recommendations tailored to each device. You can manually approve or reject these recommendations or allow Routing Director to approve them automatically.

  In prior releases, custom KPI rules had to be defined and manually instantiated for each brownfield device which was time consuming and prone to errors.

  Note:

  If you are upgrading from an older release to Routing Director Release 2.9.0, then Observability Recommendation Engine is not enabled by default. To enable the Observability Recommendation Engine on devices that are already onboarded, update the device profile.

  To enable ORE, you need to enable the ORE toggle button on the Analytics tab in the Add Device Profile page (Inventory > Devices > Device and Interface Profile > click Add icon > Device Profile > Analytics).

  [See Observability Recommendation Engine Workflow.]

• Selective enablement of AI-ML use cases on devices—You can selectively enable the following artificial intelligence and machine learning (AI-ML) use cases on the device profile user interface (UI):

  • Physical layer fault detection—Detects faults occurring due to cable degradation, damage, or loose connections.

  • Dynamic threshold—Identifies anomalies in device or network performance, allowing you to proactively prevent potential issues.

  • Fabric health detection—Identifies fabric destination errors and packet loss within the switch fabric of MX Series devices.

  • Traffic loss detection—Gives visibility into blackholes and the events causing them. It also offers predictive insights into potential issues that could lead to blackholes.

  The options to enable AI-ML use cases are present on the Analytics tab of the Add Device Profile page (Inventory > Devices > Device and Interface Profile > Add icon > Device Profile).

  Note:

  Enabling AI-ML use cases requires additional CPU, memory, and storage resources. For detailed information on the required resources for AI-ML use cases, see System Requirements.

  [See Add a Device Profile.]

• Dynamic thresholds for BGP, RIB, and FIB KPIs—Routing Director uses AI-ML to generate performance graphs with dynamic thresholds for:

  • BGP advertised routes and received routes

  • Routing information Base (RIB)

  • Forwarding Information Base (FIB)

  You can view these graphs with dynamic thresholds on the Routing and MPLS accordion of the Device-Name page (Observability > Troubleshooting Devices page > Device-Name page > Overview tab), Anomalies are detected and alerts are raised when acceptable deviations occur from the dynamic threshold limits. Static thresholds continue to exist and critical alarms are raised when static thresholds are breached.

  To view dynamic thresholds for BGP, RIB, and FIB KPIs, you must enable Dynamic Threshold on the devices through a device profile.

  [See Add a Device Profile and Routing and MPLS Data and Test Results.]

• Detection of fabric queue drops and fabric destination errors using AI-ML—Routing Director uses AI-ML to detect fabric queue drops and fabric destination errors in Juniper devices and raises a critical alert when the error occurs. You can view the alert on:

  • Hardware accordion—The Fabric field on the Hardware accordion (Observability > Troubleshooting Devices > Device-Name) displays an Unhealthy link. You can view the alert by clicking the Unhealthy link.

  • Events page—The Events page (Observability > Health > Events) lists the alert. You can view the details of the alert on the Alert Details pane.

    To view fabric health, Fabric Health Detection must be enabled on the devices through a device profile.

  [See Add a Device Profile and Hardware Data and Test Results.]

• View predictive alerts for FPC reset—Routing Director uses advanced log analytics and generic correlation to predict potential Flexible PIC Concentrator (FPC) resets. It continuously analyzes log data to identify correlated patterns between packet cyclick redundancy check (CRC) errors and conditions that typically precede an FPC failure.

  Based on this analysis, Routing Director generates predictive alerts that highlight the affected device and FPC at risk. Each alert includes actionable recommendations, enabling operators to take early corrective actions, such as scheduling or initiating an FPC reset, to minimize service impact and prevent unplanned downtime.

  [See Predict FPC Reset.]

• Custom KPI collection for Nokia devices—You can view custom key performance indicators KPIs (Hardware and Interface) for Nokia devices on the Hardware, Interfaces, Routing and MPLS, and Custom KPIs accordions of the Device-Name page (Observability > Troubleshoot Devices > Device-Name). Use this feature to monitor Nokia devices in your network.

  Additionally, you can view the status of gNMI (gRPC Network Management Interface) and NETCONF sessions that are established or terminated between the Nokia device and Routing Director on the Remote Management accordion.

  [See About the Device-Name Page.]

• Stream Active Assurance metrics to an external Kafka system—Use Routing Director to stream Active Assurance metrics to an external Kafka system. In addition to Device and Underlay KPIs, and Syslogs, Routing Director can export Active Assurance metrics in continuous streams, enabling integration with third‑party systems such as security information and event management (SIEM) platforms, artificial intelligence–machine learning (AI/ML) pipelines, and other event‑monitoring systems. You can choose to stream Active Assurance metrics from all running Measurements or limit streaming to specific Measurements by specifying metadata tags in key-value format.

  You can configure Active Assurance metrics streaming on the Export Manager page (Management > Export Manager).

  [See Export Manager Overview.]

Trust and Compliance

Routing Director helps protect the network from threats and vulnerabilities by periodically checking whether a target's configuration, integrity, and performance comply with predefined security benchmarks. The term target refers to a device or a device component. Routing Director distills the outcomes of these checks into a single trust score that you can use to determine how trustworthy a device is.

There are no new features in Release 2.9.0.

Service Orchestration

Service orchestration is the process of designing, configuring, validating, deploying, and monitoring a network service. Routing Director automates the entire life cycle of a network service by providing workflows that execute the tasks required to deliver a service. You can provision various network services by using predefined service designs. The service catalog is an inventory of service designs, which are templates that provide guidelines and parameters for instantiating a service. A service instance defines the elements of a service. A service order includes the instruction to create, modify, or delete a service instance. After you initiate a service order and provision it, Routing Director activates the automated workflow to provision the service in the network. After provisioning, Routing Director automatically monitors network health and measures service quality.

Juniper Routing Director Release 2.9.0 provides the following additional service orchestration features:

• Save a candidate version of a service instance before provisioning—Create a candidate or draft of a service instance to stage and validate configuration changes without affecting the active service. A candidate contains uncommitted updates that you can review, modify, and commit or discard.

  On the Schedule page of the Add or Modify Service-Instance wizard (Orchestration > Instances > Add/Modify Service-Instance > Schedule), click Save to save a candidate of the service instance.

  [See Service Instance Overview and About the Service Instances Page.]

• Define custom descriptions for L2VPN and L3VPN service fields—Add custom descriptions for VPN services, Site Network Access, and BGP (L3VPN only) in their respective description fields. These custom descriptions appear in the device configuration. The VPN service description is applied to the routing instance, while the Site Network Access description is used for the interface unit. For L3VPN, the BGP description is applied to the device’s BGP configuration. If any of these fields are not specified, Routing Director applies default descriptions. Adding custom descriptions ensures consistent and clear labeling across configurations.

  [See Add an L3VPN Service Instance, Add L3VPN Site and Site Network Access Details, Add an EVPN Service Instance and Add EVPN Site and Site Network Access Details.]

• Enable VLAN mapping and C-VLAN preservation for L2 services—Use VLAN mapping to manage customer VLAN (C-VLAN) traffic across EVPN, EVPN-VPWS, and L2 circuit services.

  You must specify a valid service VLAN (S‑VLAN) to transport traffic within the network.

  When you enable Preserve C‑VLAN, the service pushes the configured S-VLAN on ingress traffic while preserving the C-VLAN, and pops the S-VLAN on egress traffic. When you disable Preserve C‑VLAN, a swap operation translates the C-VLAN to the S-VLAN.

  This configuration enables clear separation of customer traffic across the network while supporting C-VLAN preservation or translation, as required.

  Configure VLAN preservation on the General page of the Add E-LAN EVPN CSM, Add E-LINE EVPN VPWS CSM, and Add E-Line L2Circuit NSM services wizards (Orchestration > Service > Instances > +).

  [See Add an EVPN Service Instance, Add an EVPN-VPWS Service Instance, Add an L2 Circuit Service Instance, and L2 Circuit VPN Nodes.]

• Configure an IRB interface for L3VPN services—You can configure an integrated routing and bridging (IRB) interface for Layer 3 VPN (L3VPN) services for the following scenarios:

  • L3VPN with EVPN using regular untagged interfaces with OSPF as PE-CE protocol and insights.

  • L3VPN with EVPN using regular untagged interfaces with BGP as PE-CE protocol and insights.

  • L3VPN with EVPN using interfaces in VLAN mode with OSPF as PE-CE protocol and insights.

  • L3VPN with EVPN using interfaces in VLAN mode with BGP as PE-CE protocol and insights.

  [See Add L3VPN Site and Site Network Access Details.]

Network Optimization

Routing Director's network optimization use case helps you optimize resource utilization, boost network performance, and ensure reliable, efficient data delivery. By using an intent-based approach, Routing Director optimizes the network through active life cycle management of label-switched paths (LSPs).

You can create a path intent using the Routing Director GUI. Path intents are specific LSP configurations that define how traffic is steered through the network. In traditional methods, you configure and provision each path in a tunnel individually with all its attributes. With path intent, you can create sub-profiles of attributes that can be reused for creating paths. This modular approach reduces redundancy and streamlines the process of provisioning multiple tunnels.

When you apply the path intent to the network, Routing Director interprets these intent-based sub-profiles and automates the creation, modification, and deletion of tunnels and LSPs. By autonomously executing the required actions, Routing Director aligns the network state with the specified intent. Routing Director ensures that LSPs are established based on network policies, traffic engineering constraints, and service level agreements (SLAs).

Juniper Routing Director Release 2.9.0 provides the following additional network optimization features:

• Support for container LSPs—View and configure container label-switched paths (LSPs) in your network.

  A container LSP is a logical grouping of sub-LSPs (PCE-initiated) that share the properties defined in the container LSP. Routing Director dynamically adds (splitting) or removes (merging) sub-LSPs based on real-time network conditions, preventing over-reservation or under-utilization of resources.

  Enable the Container LSP Normalization toggle button on the Network Optimization Settings section of the Organization Settings page (Settings Menu > System Settings) and then create container LSPs on the Container LSP tab of the Topology page (Observability > Topology).

  [See About the Container LSP Tab and Add a Container LSP.]

• Enable SID compression in SR-MPLS tunnels to reduce the label stack—Enable Segment ID (SID) compression to reduce the SR-MPLS label stack by compressing multiple SIDs into fewer labels. SID compression allows SR-MPLS path to use fewer SIDs to enable the SR-MPLS path using nodeSID.

  Note: You can enable SID compression only for Segment Routing (SR) tunnels.

  To enable SID compression, use the SID Compression option on the Add Tunnel page (Observability > Network > Topology > Tunnels > Provisioning > Tunnel) and Add Diverse Tunnels page (Observability > Network > Topology > Tunnels > Provisioning > Diverse Tunnels).

  [See Add a Tunnel and Add Diverse Tunnels.]

• View historical data for packet loss—You can monitor historical packet loss data for the links in your network. The historical data is displayed as a graph on the Link tab of the Topology page (Observability > Network > Topology > Link).

  View the packet loss for Juniper Networks and Cisco IOS-XR devices on the Measurement Explorer page (Observability > Active Assurance > Measurement Explorer) after you enable the packet loss collection feature in Routing Director.

  For Routing Director to collect this data, you must enable the Packet Loss toggle button when you create the device profile for the network implementation plan. You must also enable the Packet Loss toggle button in the Organization Settings page (Settings Menu > System Settings > Organization Settings > Network Optimization Settings).

  [See About the Link tab.]

• Reroute LSPs based on packet loss violation—Routing Director automatically reroutes a label-switched path (LSP) when the packet loss in a link exceeds a specified threshold, preventing packet loss over faulty issues in transport layer, and ensuring optimal network performance.

  For automatic rerouting of LSPs, you must configure the following parameters in the Network Optimization Settings section of the Organization Settings page (Settings Menu > System Settings > Organization Settings > Network Optimization Settings).

  • Link Packet Loss Threshold—Specify the threshold value (in percentage) for the link packet loss. If you do not specify a threshold, the LSP is not rerouted. If you specify 0, the links are blocked.

  • Link Packet Loss Violation Count—Specify the count for consecutive link packet loss violations to occur. Count refers to the number of times that a violation must occur for the LSP to be rerouted.

  • Link Packet Loss Violation Interval—Specify the interval (in minutes) for a defined number of link packet loss violations to occur. Interval refers to the time period over which consecutive number of violations (defined in the Link Packet Loss Violation Count) must occur for the LSP to be rerouted.

  [See Reroute LSPs.]

• Filter nodes using topology filter—Create a topology filter to limit the number of nodes (devices) discovered from BGP-LS peering that are not intended for onboarding to the Routing Director. Topology filter allows you to focus on critical nodes by excluding the nodes of lower priority, such as aggregation-layer nodes or route reflectors, or when your topology exceeds the total number of nodes covered by your license.

  To filter nodes, you must create filter rules per node to define inclusion or exclusion criteria on the Topology Filter page (Management > Dynamic Topology > Topology Filter). After you apply the filter rules, you can view the updated topology on the Topology page (Observability > Network > Topology).

  [See Topology Filtering Workflow.]

Planner

Planner is used for offline visualization and detailed architectural planning of any production network. Planner enables you to forecast the impact of changes to your network, such as additional traffic, shifts in traffic flows, and new capacity or services.

Planner generates a topology view of a network, enabling you to add, remove, and reconfigure network elements. Using the network topology view, you can model and visualize dynamic, explicit routing paths, designed to operate within end-user defined constraints. The effects of these changes and other traffic scenarios can be simulated without affecting the production network.

Juniper Routing Director Release 2.9.0 provides the following additional planner features:

• Speed up exhaustive failure simulations using elastic simulation optimization—Use elastic simulation optimization to distribute exhaustive failure simulation jobs (link, node, or SRLG failures) across a selected number of instances.

  An instance is a processing unit allocated by Routing Director to run simulations independently. While running exhaustive failure simulation, the jobs are executed in parallel on the selected number of instances. Elastic simulation optimization reduces overall execution time for exhaustive failure simulations, particularly for large or complex networks.

  You can enable elastic simulation optimization by selecting instances from 2 through 5 in the Number of instances field on the Exhaustive Failure Simulation page (Planning > Networks > Offline Models > Working-Model > Simulation).

  [See Exhaustive Failure Simulation.]

• Analyze network capacity with Capacity Viewer—Routing Director enables you to analyze link utilization and evaluate network performance under varying traffic conditions. This helps you to determine whether capacity upgrades are required without impacting the live network.

  Use the Links tab and Demands tab on the Capacity Viewer page (Planning > Offline Models > Model-Name > Simulation > Capacity Viewer) to make informed decisions about traffic optimization and capacity upgrades.

  The Links tab provides an aggregated view of link utilization across your network, helping identify overutilized or underutilized links. The Demands tab allows you to modify tunnel bandwidth and observe how those changes affect link utilization.

  [See About the Capacity Viewer Page and Capacity Viewer Workflow.]

• Edit offline network models—Use the Edit option on the Working Models page (Planning > Networks > Offline Models > Model-Name > Pencil icon) to make changes or apply multiple updates to an existing network model. While editing, choose one of the following options:

  • Traffic/Demand Generation—To generate and apply traffic or demands using telemetry collected by Routing Director.
  • Import from File—To upload a new JSON file if there are large-scale configuration changes. Routing Director validates the file during upload to ensure that the structure and data are correct. If errors, such as missing fields or incorrect data types, are found, the import fails with clear messages indicating the exact issue and its location.
  • Import Stats from File—To upload the traffic statistics collected by a third-party data collector.

  [See Edit a Network Model.]

• Implement tunnel diversity in offline network models—You can pair label-switched paths (LSPs) so that they do not overlap at any point between their ingress (starting point) and egress (ending point) in an offline network model. Tunnel diversity is crucial for network resilience, as the feature ensures that if one path fails, the other remains operational.

  We support three types of tunnel diversity:

  • Link diversity—Ensures LSPs do not share common links. If one LSP uses a specific link, the other LSP in the pair uses a different link, thus avoiding shared points of failure.

  • Shared Risk Link Group (SRLG) diversity—Ensures LSPs avoid links that share the same risk factors.

  • Site diversity—Ensures LSPs avoid the same nodes and therefore the same sites. This tunnel diversity type includes both link and SRLG diversity features.

    If a node does not belong to a site, it is considered its own site.

  You can create diverse tunnels only for RSVP and SR-TE LSPs.

  Note:

  The Route by Device routing method is not supported for Segment Routing (SR) when configuring tunnel diversity.

  Use the Add Diverse Tunnels page (Planner > Networks > Offline Models > Working Models > Network Model > Open > Tunnels tab > More > Create Diverse Tunnels) to implement tunnel diversity in an offline network model.

  [See Create Diverse Tunnels (Planner).]

• Configure SR protocol for links—You can now configure the SR protocol when creating a link in your network model. When SR is enabled, Routing Director steer traffic along specific paths using Segment Identifiers (SIDs). Use SR to steer traffic along specific paths using Segment Identifiers (SIDs).

  You can specify the SID values (IPv4 addresses) for Node A and Node Z to explicitly define the path over the intended link. If SIDs are not specified, path computation is based on SIDs learned through the routing protocol. This configuration explicitly steers traffic over the intended link and supports accurate path computation.

  Note:

  Even if Segment Identifier (SID) values can be explicitly configured on a link, Planner uses the IPv4 addresses of interfaces or nodes to calculate the tunnel path. The SID values are not directly used during path computation.

  [See Create a Link (Planner).]

Active Assurance

Active Assurance is a programmable test and monitoring solution, which generates synthetic traffic in the underlay network to gain continuous insights on network quality, availability, and performance. Active Assurance uses Test Agents, which are measurement points in your network. Test Agents generate and receive synthetic traffic, and enable you to continuously monitor and validate the infrastructure. You can deploy Test Agents at strategic locations in your network and install them on routers running Junos® OS Evolved, x86 hardware, or on virtual machines (VMs). Routing Director uses RPM to collect metrics data for Juniper Networks® MX Series Universal Routers and Juniper Networks® PTX Series Routers.

Juniper Routing Director Release 2.9.0 provides the following additional Active Assurance features:

• Support for additional plug-ins—Routing Director enables you to evaluate the QoS in your network using the following plug-ins:

  • DSCP Port Mapping—Use this plug-in to verify that traffic sent to specific UDP destination ports is correctly remarked as the traffic passes between two points in your network. The plug-in sends traffic marked with a specific DSCP value to configured UDP port ranges and compares the expected and received DSCP values at the destination. When you run a verification test using this plug-in, port-aware QoS policy misconfigurations and remarking issues tied to specific UDP destination ports are detected.

  • DSCP Remapping—Use this plug-in to verify that traffic is correctly remarked as traffic passes between two points in your network. The plug-in sends traffic marked with specific DSCP values and compares the expected and received DSCP values at the destination. When you run a verification test using this plug-in, DSCP remarking mismatches and QoS policy enforcement issues across the network path are detected.

  • VoIP—Use this plug-in to simulate hub-and-spoke VoIP traffic and verify network readiness for real-time voice communication between Test Agents. The plug-in generates UDP-based voice traffic using a selected voice codec and measures voice quality indicators and network performance metrics. When you run a verification test using this plug-in, issues such as high latency, jitter, and packet loss that degrade voice quality across the network are detected.
  • RFC 6349 TCP Throughput—Use this plug-in to measure the maximum achievable TCP throughput between a server and a client Test Agent following the IETF RFC 6349 framework. The plug-in performs a structured TCP throughput test and evaluates the TCP transfer rate, efficiency, and bottleneck bandwidth across the network path. When you run a verification test using this plug-in, performance issues such as bottlenecks, buffer limitations, and retransmission overhead that limit high-bandwidth data communication are detected.

  [See Supported Plug-ins.]

• Manual installation of Test Agent Appliance on NFX150—Install the Test Agent Appliance manually on an NFX150 device by deploying it as a Virtual Network Function (VNF). The NFX150 supports running a Test Agent Appliance image directly on the virtualized compute layer of the device, without requiring cloud or external virtualization platforms.

  Configure cloud-config metadata files to support automatic registration with Routing Director, download the Test Agent Appliance QCOW2 image, and apply the VNF settings such as CPU, memory, and interface mapping. This deployment method provides a hardware-based environment for running the Test Agent Appliance within the NFX platform.

  [See Install Test Agent Appliance.]

• Restore or permanently delete Test Agents—You can view and manage Test Agents that have been deleted from your network. You can also restore a Test Agent that was erroneously removed or permanently delete Test Agents that are no longer needed, helping you maintain an accurate inventory of active Test Agents.

  Use Trash Bin tab on the Test Agents page (Inventory > Test Agents) to recover or permanently delete Test Agents.

  [See About the Test Agents Page.]

• Schedule Tests at defined intervals—Configure recurrence rules to run Tests automatically at defined intervals. Recurrence rules enable you to schedule Tests by configuring frequency (once, hourly, daily, weekly, monthly, or custom), time zone, start date, and interval between executions. Scheduling a Test eliminates the need to trigger Tests manually and ensures time-based and consistent network monitoring.

  You can schedule a Test from the Measurement Designer page (Observability > Active Assurance > Measurement Designer) and manage scheduled Tests from the Tests page (Observability > Active Assurance > Tests).

  [See About the Tests Page.]

• View intermediate hop details for Pathtrace Streams—Use Routing Director to view details of intermediate hops in the interactive topology view on the Pathtrace page (Observability > Active Assurance > Tests > Test-Name > Topology). Viewing intermediate hop details helps you to quickly identify where latency, packet loss, or routing anomalies occur along a path, enabling faster troubleshooting. You can view hop details such as the host name, IP address, and timestamps of the hop.

  If the hop is associated with a domain, you can view all the streams passing through the domain, identified by domain name, hop number, and IP address from the Matching Streams field.

  [See About the Topology Tab (Path Trace).]

LLM Connector

LLM Connector is an AI-driven capability integrated with Routing Director that enables users to interact with their network through natural language queries. It securely connects to large language models (LLMs) to provide actionable insights, generate configuration recommendations, and assist with troubleshooting. By simplifying access to network intelligence, LLM Connector allows operators to monitor and troubleshoot networks without relying on traditional command-line interface (CLI) commands.

Juniper Routing Director Release 2.9.0 provides the following LLM Connector features:

• LLM Connector enhancements—The following enhancements are made to LLM connector in this release:

  • You can query HPE Juniper Networking documentation using LLM Connector. LLM Connector automatically directs documentation-related queries to the Juniper LLM and returns the results.

    To be able to query HPE Juniper Networking documentation, you must have created an organization in Juniper Routing Assurance and configured documentation mode in LLM Connector.

  • You can execute commands on Juniper devices through LLM Connector. Audit logs are generated for the commands executed and a superuser can view the generated audit logs.

  • LLM Connector can generate interactive dashboards and display them in a separate panel. You can view and save the HTML code used for generating the dashboardslocally and export the dashboard in PDF format.

  • You can use any configured LLM model to generate a response for your query. Additional LLM models from Anthropic and OpenAI-Compatible are supported in this release.

  • LLM Connector responses include supporting details such as tools used, tool outputs, and LLM reasoning. The supporting details are grouped into collapsible sections. Code snippets in the output have syntax highlighted, and expandable and collapsible code blocks.

  • The five-star rating for providing feedback is replaced with Thumbs Up and Thumbs Down icons indicating useful and not useful responses respectively.

  [See LLM Connector Overview.]

• Use MCP server to query Routing Director—A network operator can use any AI agent such as Claude, Copilot, and ChatGPT to query Routing Director through an Model Context Protocol (MCP) server. The MCP server helps network operators to query network data, commit configuration, create dashboards, and access key performance indicators (KPIs) conversationally instead of writing code or learning complex API syntax.

  [See Query Routing Director Using MCP.]

Administration

• Reuse ABAC policies across access control profiles—Routing Director allows the reuse of attribute-based access control (ABAC) policies across access control profiles, improving consistency and simplifying policy management. Superusers can leverage the inventory of default policy templates to create standardized policies, which can then be applied across multiple profiles without duplication.

  The ability to reuse templates and policies eliminates the need to repeatedly define identical policies, thereby reducing configuration errors and providing consistent policy enforcement.

  The Access Control Profile page (Settings Menu > Control Profiles) provides a tabbed interface to manage profiles, policies, and templates (referred to as skeletons on the GUI) separately.

  [See About the Access Control Profiles Page.]

• Enforce password policy—Superusers can define and enforce an organization-wide password policy that comprises:

  • Uppercase letters

  • Lowercase letters

  • Special characters

  • Numeric characters

  • A minimum number of characters

  They can enable or disable password policy enforcement as needed. When enforcement is enabled, all user passwords must comply with the configured policy, ensuring consistent and strengthened account security across the organization.

  Password policy can be defined and enforced from the Organization Settings page (Settings Menu > System Settings).

  [See Manage Organization Settings.]

• Bulk upload sites to Routing Director—A superuser can import multiple sites into Routing Director at the same time by adding them to a .CSV file. After the import, Routing Director provides a summary that includes the number of sites successfully imported, as well as those that were skipped or failed, along with the corresponding reasons.

  Sites can be bulk uploaded from the Sites page (Inventory > Common Resources > Sites).

  [See About the Sites Page.]

Juniper Routing Director Installation

Juniper Routing Director Release 2.9.0 provides the following installation-related feature:

• Install Routing Director on AWS—You can install and deploy the Routing Director cluster on the Amazon Web Services (AWS) cloud, in addition to existing installation support for hypervisor-based environments. In AWS, Routing Director runs as Amazon Elastic Compute Cloud (EC2) instances. This deployment option offers flexibility in hosting and scaling, along with the benefits of AWS features such as on-demand provisioning, scalable compute capacity, and built-in high availability.

  [See Install Routing Director on AWS.]

• Upgraded base OS on the cluster VMs—The default base OS of the Routing Director cluster virtual machines (VMs) is now upgraded to Ubuntu 24.04.4 LTS (Noble Numbat) from Ubuntu 22.04.5 LTS.

  The Routing Director OVA is delivered with all required utilities, operating system components, and software needed to deploy virtual machines. These VMs are provisioned with Ubuntu 24.04.4 as the base OS.

  For existing or upgraded cluster deployments, you must update the base OS to ensure continued security, stability, performance, and Kubernetes cluster compatibility. The upgrade process is considered complete only after the base OS update is applied. Download the OS update file from the software download site.

  [See Update the OS on the Nodes.]

Beta Features

Juniper Routing Director Release 2.9.0 provides Beta support for the following features:

• Roll back service instance and design versions to a previous version—Use the Rollback option to revert the service instance and service design versions associated with a service instance to a previous version on the Service Instances page (Orchestration > Instances > Service Instances). Each modification or provisioning of a service instance creates a new entry in the rollback table and enables you to track changes and select specific versions to roll back to.

  The rollback functionality allows you to revert a service instance to a previous version after provisioning failures or service design version upgrade failures, avoiding the need to rebuild the service from scratch.

  [See About the Service Instances Page.]

• Upload a customized service design—Upload customized service designs to Routing Director by using the service orchestration cMGD CLI.

  Note:

  To create and customize service designs, contact Juniper Networks Professional Services.

  You can view the uploaded service designs on the Service Designs page (Orchestration > Service > Service Catalog) and use them to provision corresponding services in the network.

  [See Upload a Customized Service Design.]

Deprecated Feature

The following GUI page is deprecated in Juniper Routing Director Release 2.9.0.

• Custom KPI Collection—The Custom KPI Collection page (Observability > Health) is no longer available. The following tabs that were previously available on this page have been moved to the KPI Workspace tab of the Smart KPI Assistant page (Observability > Health):

  • Rule Instances

  • Rules List (Renamed to Rules in Release 2.9.0)

  • Rule Helper Files (Renamed to Rule Helpers in Release 2.9.0)