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.5.0 extends device LCM to the following platforms and provides the following additional features:

• Device Support—You can onboard the devices listed in Table 1 to Routing Director and manage them:

  • Table 1: Supported Devices and Functions

    Device	Supported Functions
    ACX710, ACX5048, and ACX5096	Basic device management functions: Viewing inventory, interface, system logs, and alarms Managing configurations using templates, Taking configuration backup Performing OS upgrades Orchestrating services using custom rules and custom service definitions.
    ACX7020 and ACX2200	Device observability Routing observability Service orchestration, Active assurance Network optimization Viewing topology weather map
    EX2300	Basic device management functions: Viewing inventory, interface, system logs, and alarms Managing configurations using templates, Taking configuration backup Performing OS upgrades Orchestrating services using custom rules and custom service definitions.
    MX104, MX2008, MX2010, and MX2020	MX104 (only basic device management functions). The following functions are supported for MX2008, MX2010, and MX2020 devices: Device observability Routing observability Service orchestration, Active assurance Network optimization Viewing topology weather map
    SRX5400	Basic device management functions: Viewing inventory, interface, system logs, and alarms Managing configurations using templates, Taking configuration backup Performing OS upgrades Orchestrating services using custom rules and custom service definitions.

• Configure aggregated Ethernet interface in a network implementation plan—You can configure aggregated Ethernet interfaces in a network implementation plan so that:

  • LAGs are configured on a device during device onboarding.

  • The aggregated Ethernet interfaces are available as a resource for provisioning services soon after the device is onboarded.

  To use this feature, configure:

  • Maximum Transmission Unit (MTU) and tagging on the interfaces using port profiles in a network implementation plan.

  • MTU, tagging, and LAG members in the network implementation plan.

  [See Configure Port Profiles and Add a Network Implementation Plan].

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. Additionally, Routing Director provides a routing dashboard where you can actively monitor the overall routing health of your network in real time. The timely detection of anomalies enables you to take prompt action and minimize the impact of any issues.

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

• Discover SRLGs—Use Routing Director to discover Shared Risk Link Groups (SRLGs) that you have configured on your network devices. SRLGs help you to identify the links that share the same risk factors and thereby support network redundancy and planning.

  You can view the list of SRLGs on the SRLGs/Facilities tab of the Topology page (Observability > Network > Topology).

  You need to establish a BGP Link State (BGP-LS) session between Routing Director and the device so that the device can advertise SRLG-related information configured in your network. Otherwise, you cannot view the list of SRLGs configured in your network on the SRLGs/Facilities tab.

  [See About the SRLGs Page.]

• Track event history for LSPs—Track changes made to label-switched path (LSP) attributes and events on the Events page of the Tunnels tab (Observability > Network > Topology > Tunnels tab). The graphical representation of bandwidth-related changes for an LSP on the Events page helps you to evaluate the changes in bandwidth over a period of time.

  In addition, you can use the Show Path Changes option to view highlights on the Topology map for any changes to the LSP. With this visibility, you can easily track and analyze routing changes.

  You can track event history only for PCC-initiated LSPs. By default, the retention policy for event history data is 3 days.

  [See About the Tunnels Tab.]

• View alerts and performance graphs of KPIs—Routing Director generates alerts based on the KPI anomalies in your network. Use the KPI tab of the Monitor Instance-Name page (Observability > Health > Custom KPI Collection > Rule Instantiation > Instance-Name) to view a graphical representation of the KPIs and alerts generated for all KPIs associated with a selected device and rule. You can also set triggers and threshold limits for an individual KPI when you define rule parameters.

  [See About the Custom KPI Collection Page.]

• Predict events causing traffic loss using JRI—Routing Director uses the Juniper Resiliency Interface (JRI) to collect routing, kernel, and forwarding exceptions that could potentially lead to traffic loss. These exceptions are displayed as Predictor Events in the Routing and MPLS accordion of the Device-Name page (Observability > Troubleshooting Devices > click Device-Name).

  Additionally, Routing Director offers a list of up to 10 events correlated to a predictor event and lists them in the decreasing order of their relevance to the predictor event.

  [See Predictor Events.]

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 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.

Juniper Routing Director Release 2.5.0 provides the following additional trust and compliance features:

• Monitor device integrity—You can monitor the device integrity using the integrity accordion on the Trust tab (Observability > Health > Health Dashboard > Trust). On this accordion, you can view:

  • Percentage of healthy devices and the total number of unhealthy devices based on integrity of devices.

  • A graphical representation of average health of all devices.

  • KPIs such as Hardware EOL and Software EOL that affect the overall network health.

  You can use this information to perform corrective actions. You can also click View Details to view detailed information about device health and KPIs that affect the integrity of devices.

  [See About the Integrity Health Page.]

• Run a compliance scan by configuring trust settings—Run a compliance scan by configuring trust settings on the Trust tab (Observability > Health > Health Dashboard > Trust) of the Health Dashboard. Select a trust plan, benchmark document, profile, and tailoring document from the Trust Settings page to obtain a desired level of compliance. The results of the scan are displayed on the Compliance accordion.

  [See About the Trust tab.]

• Update trust-related definitions for SIRT, EOL, and PBNs in an air-gapped installation—Update all trust-related KPIs when Routing Director does not have access to the Internet, using the request paragon trust data update hostname command.

  View the updated KPIs on the Trust tab of the Health Dashboard (Observability > Health > Health Dashboard > Trust). You can use this information to detect anomalies and perform corrective actions,.

  [See Update Trust KPIs in an Air-Gapped Installation.]

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.5.0 provides the following additional service orchestration features:

• Configure an IRB interface for EVPN and L3VPN services—You can configure an integrated routing and bridging (IRB) interface to simultaneously support Layer 2 (L2) bridging and Layer 3 (L3) routing on the same interface for EVPN and L3VPN services. To configure an IRB interface, you must:

  • For EVPN services—Enable Layer3 Gateway and select the placement options for the IRB interface on the Add Connection page (Orchestration > Instances > + > E-LAN EVPN CSM > Customer Site Settings > Site Network Access > + > Add Connection).

    Configuring an IRB interface for EVPN services is qualified only for the following scenarios:

    • EVPN with Ethernet interface port mode.

    • EVPN with Ethernet interface VLAN mode.

  • For L3VPN services—Select IRB as the connection type and configure the virtual gateway IP address and MAC address for the IRB interface on the Add Connection page (Orchestration > Instances > + > L3VPN > Customer Site Settings > Site Network Access > + > Add Connection). You can also select the placement options for the IRB interface.

    Configuring an IRB interface for L3VPN services is qualified only for the following scenarios:

    • L3VPN with EVPN having regular untagged interfaces with OSPF as PE-CE protocol.

    • L3VPN with EVPN having regular untagged interfaces with BGP as PE-CE protocol.

    • L3VPN with EVPN having interfaces in VLAN mode with OSPF as PE-CE protocol.

    • L3VPN with EVPN having interfaces in VLAN mode with BGP as PE-CE protocol.

  You can also configure an IRB interface when you add node details to the topology resource pool and devices in the network implementation plan.

  [See Add EVPN or EVPN-VPWS Service Site Details, Add L3VPN Service Site Details, Add a Network Implementation Plan, and Configure Resource Pools for Resource Instances.]

• Provision a multihomed EVPN-VPWS service with preconfigured LAG interfaces—You can configure multihoming on your Ethernet VPN–virtual private wireless service (EVPN-VPWS) service. To configure multihoming you must have pre-provisioned the link aggregation group (LAG) aggregated Ethernet interfaces on the device. You can provision LAG interfaces by logging in to the device and configuring the interfaces manually or through the Routing Director GUI by using network implementation plans. After provisioning the LAG interface on the device, add the interface under the Access Interfaces section (Modify Resource-Instance > Pop/Site > + > Node > + > Access Interfaces > + > Access). Then set the Lag toggle button to True when configuring a topology resource instance for provisioning an EVPN-VPWS service.

  [See Create a Topology Resource Pool and Add a Network Implementation Plan.]

• Provision a multihomed L2 circuit—Routing Director supports configuring multihomed Layer 2 (L2) circuits in the following two modes:

  • Backup mode—In the default backup mode, a single active pseudowire exists between the access node and the remote PE node. The backup pseudowire is not pre-signaled. If the active pseudowire fails, the backup pseudowire becomes active after a connection is established.

  • Hot-standby mode—In this mode, the backup pseudowire is pre-signaled. If the active pseudowire fails, the backup pseudowire becomes active immediately. As the backup pseudowire is pre-signaled, the switchover time to the backup pseudowire is reduced, minimizing traffic disruption.

  To configure multihoming, you must add three devices to the L2 circuit.

  [See Add L2 Circuit VPN Nodes.]

• Configure Q-in-Q tunneling for EVPN and L3VPN services—You can assign a Q-in-Q tag, in addition to a Dot1q tag, to an Ethernet interface for E-LAN EVPN CSM and Layer 3 (L3VPN) services. Assign both an inner customer VLAN ID and an outer service VLAN ID to the same interface when you use a Q-in-Q tag.

  You can assign Q-in-Q as the tag type for interfaces when you add node details to the topology resource pool and devices in the network implementation plan.

  [See Add EVPN or EVPN-VPWS Service Site Details, Add L3VPN Service Site Details, Configure Resource Pools for Resource Instances, and Add a Network Implementation Plan.]

• Assign tags to service instances and network implementation plans—You can assign tags to logically group and categorize service instances and network implementation plans.

  To assign tags to a service instance or network implementation plan, click More > Manage Tags on the Service Instances and Network Implementation Plan pages respectively.

Network Optimization

The network optimization use case in Routing Director enables you to optimize the utilization of network resources, enhance network performance, and ensure reliable and efficient delivery of data across the network. Routing Director optimizes the network by managing the life cycle of label-switched paths (LSPs) through an intent-based approach.

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, each path in a tunnel must be configured and provisioned 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.5.0 provides the following network optimization features:

• Implement tunnel diversity for enhanced network resilience—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). 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.

  Use the Add Diverse Tunnels page (Observability > Network > Topology > Tunnels tab > Provisioning > Diverse Tunnels) to implement tunnel diversity in your network.

  [See Add Diverse Tunnels.]

• Support for ECMP routing—Routing Director supports equal-cost multipath (ECMP) routing to distribute traffic and improve bandwidth utilization on multiple links to the same destination. In the PathFinder Settings section of the Organization Settings page (Settings Menu > System Settings > Organization Settings), select one of the following placement methods for the ECMP Placement Method field:

  • Random—Randomly selects one of the ECMP paths
  • Least filled—Selects the path with the maximum available bandwidth
  • Most filled—Selects the path with the minimum available bandwidth

  Routing Director evaluates link metrics and applies the specified placement method if multiple ECMP paths are available.

  [See Reroute LSPs.]

• Reroute LSPs based on link utilization threshold—Routing Director automatically reroutes a label-switched path (LSP) when the utilization of a link exceeds a specified threshold, ensuring optimal network performance and preventing congestion.

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

  • Link Utilization Threshold—Specify a threshold value for link utilization (in percentage) so that Routing Director can reroute LSPs when the traffic on a link exceeds this value.
  • Threshold Rerouting Interval—Specify the minimum interval (in minutes) after which Routing Director reacts to any threshold violations.

  [See Reroute LSPs.]

• Configure secondary or standby LSPs—Add a secondary or standby label-switched path (LSP) to a primary LSP so that an alternate route is chosen when the primary route fails.

  The tunnel ID, source node, destination node, and IP address of a secondary or standby LSP are identical to that of the primary LSP. However, secondary and standby LSPs have the following differences:

  • A secondary LSP is not signaled until the primary LSP fails.

  • A standby LSP is signaled regardless of the primary LSP status.

  To add a secondary or standby LSP, select a tunnel on the Tunnels tab of the Topology page (Observability > Network > Topology) and click Provisioning > Secondary/Standby Tunnel.

  [See About the Tunnels Tab.]

• Add or remove LSP delegation—Use the Configure LSP Delegation page (Observability > Network > Topology > Tunnel tab > Delegation > Configure Delegation) to delegate the management of Path Computation Client-controlled LSPs (PCC-controlled LSPs) to the Path Computation Element (PCE). After delegation, these LSPs are managed by the PCE and are classified as PCE-delegated LSPs. You can also return the control of these LSPs to the PCC by removing the delegation, and these LSPs are then reclassified as PCC-controlled LSPs.

  [See Add and Remove LSP Delegation.]

• Configure tunnels and tunnel profiles using NETCONF—Use NETCONF in addition to Path Computation Element Protocol (PCEP) to configure tunnels. Routing Director provides the NETCONF option in the Provisioning Method field when you configure a tunnel (Observability > Network > Topology > Tunnels tab > Provisioning drop-down list > Tunnel).

  In addition, NETCONF is supported when you create tunnel profiles using the intent-based network optimization method. Routing Director provides the NETCONF option in the Provisioning Method field when you configure tunnel profiles (Observability > Network > Topology > Tunnels tab > Provisioning drop-down list > Tunnel).

  When NETCONF is the provisioning method, the tunnel is statically provisioned and the associated configuration statements is part of the router configuration file. This tunnel is considered as a device-controlled tunnel.

  [See Add a Tunnel and Add a Tunnel Profile.]

• Set FAD constraints for LSPs and Tunnel Profiles—You can apply Flexible Algorithm Definition (FAD) constraints to your LSP so that LSPs comply with the defined FAD constraints, maintaining optimal network paths. If a compliant path cannot be found, the LSPs remain unprovisioned.

  On the Add Tunnel page (Observability > Network > Topology > Provisioning > Tunnels tab > +), you can select the Flexible Algorithm (flex algo) IDs.

  In addition, you can apply FAD constraints to tunnel profiles so that LSPs that are created using the intent-based network optimization method comply with the defined FAD constraints. On the Add a Tunnel Profile page (Network Optimization > Network > Network Optimization Intent > Tunnel Profiles tab > +), you can select the Flexible Algorithm (flex algo) ID to associate the constraint to the LSP.

  You can assign flex algo IDs only for segment routing (SR) and Segment Routing for IPv6 (SRv6) LSPs.

  [See Add a Tunnel and Add a Tunnel Profile.]

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, new capacity or services, and so on.

Planner generates a topology view of a network, enabling the addition, removal, and reconfiguration of 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.5.0 provides the following planner feature:

• Analyze and simulate offline networks—Use the Planning menu on the Routing Director GUI to import either from Routing Director or using a JSON document. You can then perform an exhaustive failure analysis of all single link, node or SRLG failures, and generate reports to understand the critical failure events that could adversely impact network traffic.

  [See Network Planner Overview and Network Planner Workflow.]

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.5.0 provides the following additional Active Assurance features:

• Add VLAN interfaces on Test Agent Appliances— Add and configure VLAN interfaces from the Interfaces tab of the Test-Agent-Name (Inventory > Active Assurance > Test Agents) page. You can configure VLAN-specific parameters such as the parent interface, VLAN ID, namespace, isolation parameter, and so on. You can add interfaces only on Test Agent Appliances. In addition, you can also set the interface as the management interface or Network Time Protocol (NTP) source for the Test Agent Appliance.

  [See About the Test Agent-Name Page.]

• Delete interfaces on Test Agents—You can delete interfaces associated with Test Agent Appliances and Test Agent Applications from the Interfaces tab of the Test-Agent-Namepage (Inventory > Active Assurance > Test Agents).

  You can mark non-orphaned interfaces associated with Test Agents for deletion by using the Delete option and then commit the changes, and you can directly delete orphaned interfaces on Test Agents by using the Delete option. You can also unmark an interface for deletion by using the Undelete option before committing the configuration. This action restores the interface.

  [See About the Test Agent-Name Page.]

• IPv6 support for management interfaces—In addition to IPv4 addresses, you can configure IPv6 addresses in the management interface of a Test Agent Appliance. You can assign various types of IPv6 addresses, such as static addresses and addresses assigned using DHCP or SLAAC. You can also enable IPv6 support for the NTP client. With this support, a Test Agent Appliance can synchronize time by using an IPv6-based NTP client.

  [See Install Test Agent Appliance.]

Administration

Routing Director Release 2.5.0 provides the following administration features to manage users, sites, and organizations:

• Enable PCEP security—Enforce security between the PCE (Path Computation Element) server and Path Computation Clients (PCC) by configuring a security mode to use certificates. Routing Director supports the following PCEP security modes:

  • auto-detect—Accepts connection regardless of whether PCEP security is enabled.

  • strict-disable—Accepts only non-secured PCEP connections. This is the default mode.

  • strict-enable—Enforces security on all PCEP sessions. If a device does not have security enabled, its connection is rejected.

  To ensure that communication between the PCE server and its clients is encrypted and secure, you must set the security mode to strict-enable or auto-detect using Paragon Shell.

  Note: The communication between the PCE server and its clients is secured using the PCEPS client-server authentication and encryption. We do not support mutual Transport Layer Security (mTLS) authentication.

  Routing Director supports both custom certificates and system-generated certificates. If you are using a system-generated certificate, the server certificate (tls.crt) and private key (tls.key) are automatically generated; otherwise, you must upload a custom certificate.

  [See Enable PCEP Security.]

• Use access control profiles to restrict access to Routing Director resources—With access control profiles, superusers can enforce conditions for granting Routing Director resource access to network administrators. Access controls are implemented by using tags.

  The following operations are access controlled:

  • Device operations: Device update, reset, reboot, deletion, and so on.

  • Service instance operations: Service instance update, force sync, placement update, deprovisioning, and so on.

  • Tagging operations: Tag assignment, update, and deletion.

  A network administrator cannot access a resource if:

  • A resource is not assigned a tag.

  • The user is not assigned an access control profile that include access to that resource.

  [See Access Control Profile Overview.]

• Configure Routing Director to forward SNMP traps to an external system—Routing Director can receive SNMP traps (SNMPV2c and SNMPV3) from Juniper devices and forward them to an external system for fault management.

  To use this feature, you must configure SNMP and SNMP forwarding endpoints in Organization Settings (System Settings > Settings Menu) under SNMP Configuration and SNMP Forwarding Endpoints respectively..

  [See Configure SNMP.]

Juniper Routing Director Installation

Juniper Routing Director Release 2.5.0 provides the following installation-related features:

• Support for Ubuntu 22.04.05 KVM hypervisors—You can deploy the Routing Director cluster on Ubuntu 22.04.05 kernel-based virtual machine (KVM) hypervisors, in addition to Red Hat Enterprise Linux (RHEL) 8.10 KVM hypervisors.

  [See Create the Node VMs.]

• Schedule periodic backup—Schedule a periodic backup of your Routing Director network configuration and telemetry information. You can save the backed-up information on the cluster node or upload the information to a remote storage location. You can also view and delete scheduled backups.

  [See Schedule Backups.]

Beta Features

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

• Routing Director Chatbot— Use Routing Director chatbot (LLM Connector) to facilitate the use of natural language to query network status and obtain troubleshooting information, without using CLI commands.

  LLM Connector can help you:

  • Retrieve device information.

  • Execute Junos OS operational commands.

  • Save data (configuration and logs) to a file.

  • Retrieve a list of all VPNs in your network and their details, metrics, and health information.

  • Fetch information about customers and service instances associated with customers.

  • Get insights based on the telemetry collected from the device.

  • Plot various metrics and state graphs. For example, LLM Connector can plot data related to CPU usage, device temperature, memory usage, packet loss, BGP session status, and so on.

  • Fetch insights based on the telemetry data derived from the metrics collected by the Test Agents.

  To use the LLM Connector tool, you must set up a large language model (LLM). The recommended LLM model for LLM Connector is GPT-4 and GPT-4o.

  [See LLM Connector Overview.]

• Monitor device health and temperature using AI-ML—Routing Director uses artificial intelligence-machine learning (AI-ML) to monitor key performance indicators (KPIs) for device health to detect anomalies. Routing Director monitors the KPIs for the following components:

  • Fans [Revolutions per minute (RPM)]

  • Line cards (CPU utilization, memory utilization, and temperature)

  • Routing Engine (CPU utilization, memory utilization, and temperature)

  • Interfaces (optical temperature, optical Tx power, optical Rx power, input traffic, and output traffic)

  Routing Director also performs root cause analysis (RCA) of device temperature anomalies.

  [See Automatically Monitor Device Health and Detect Anomalies.]

• Detect blackholes using AI-ML—Routing Director uses artificial intelligence–machine learning (AI-ML) to detect blackhole (packet drops) on a device and generates a Blackhole Detected alert to notify about the event. On the Traffic Loss page (Observability > Troubleshoot Devices > click Device-Name > Routing and MPLS accordion > Traffic Loss), you can view:

  • Graphs—Depicts input packet rate, output packet rate, and packet drop.

  • Alerts—Provides details of alerts and traffic flows affected by packet drops.

  [See Detect Blackholes.]

• 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.]

• Support for Test Agent Appliances—Use Routing Director to register and run Test Agent Appliances in your network. A Test Agent Appliance is a full-fledged Test Agent with a built-in operating system, which provides you full control over network configuration and supports advanced functionalities. The Test Agent Appliance is based on the Debian Linux operating system. It is delivered as:

  • Dedicated Test Agent—Download the Test Agent Appliance software image and install the software image on custom x86 hardware.

  • Test Agentvirtual network function—Upload a Test Agent software image to a virtualization platform and run the platform as a virtual machine (VM) on a hypervisor.

  After you install a Test Agent Appliance on a platform, Routing Director discovers the Test Agent Appliance. You can view the discovered Test Agent Appliance on the Test Agents (Inventory > Active Assurance > Test Agents) page.

  [See About the Test Agents Page.]

• Install Test Agent Appliance on custom x86 hardware—You can install a Test Agent Appliance on x86 hardware. For the installation, create a bootable USB flash drive with the Test Agent Appliance software image and use the USB flash drive to boot the hardware. Register the installed Test Agent Appliance with Routing Director to start collecting measurements in your network.

  As an alternative to this deployment method, you can use virtual machine-based deployment to install a Test Agent Appliance. Routing Director supports installation of Test Agent Appliance on Proxmox.

  [See Install Test Agent Appliance.]

• Configure RPM Cisco TWAMP Reflector using GUI—You can configure an RPM Cisco TWAMP Reflector measurement testing from the Measurement Designer page (Observability > Active Assurance > Measurement Designer > Create a Test/Monitor).

  The RPM Cisco TWAMP Reflector task measures network performance by running Two-Way Active measurement protocol (TWAMP) tests on Cisco devices. This test sets up a reflector for TWAMP senders to evaluate metrics like round-trip delay, jitter, and packet loss between TWAMP clients and Cisco devices (reflectors).

  [See Tests and Monitors Overview.]