Deploy the Cluster
This topic describes the procedure to deploy a Routing Director deployment cluster on the VMs.
Perform the following steps to configure and deploy the Routing Director deployment cluster using Deployment Shell CLI.
Go back to the first node VM (Primary1). If you have been logged out, log in again as root with the previously configured password. You are placed in Deployment Shell operational mode.
********************************************************************* WELCOME TO Routing Director SHELL! You will now be able to execute Routing Director CLI commands! ********************************************************************* root@eop>To configure the cluster, enter the configuration mode in Deployment Shell.
root@eop> configure Entering configuration mode [edit]
Configure the following cluster parameters.
root@eop# set deployment cluster nodes kubernetes 1 address node1-IP [edit] root@eop# set deployment cluster nodes kubernetes 2 address node2-IP [edit] root@eop# set deployment cluster nodes kubernetes 3 address node3-IP [edit] root@eop# set deployment cluster nodes kubernetes 4 address node4-IP [edit]
Where:
The IP addresses of
kubernetesnodes with indexes 1 through 4 must match the static IP addresses that are configured on the node VMs. The Kubernetes nodes with indexes 1, 2, and 3 are the primary and worker nodes, the node with index 4 is the worker-only node. The node IP addresses can be on the same subnet or on different subnets. If you are configuring a three node cluster, skip configuring the Kubernetes node with index 4. If you are configuring a single-node deployment, skip configuring the Kubernetes nodes with indexes 2, 3, and 4.Configure the NTP and login parameters.
root@eop# set deployment cluster ntp ntp-servers pool.ntp.org [edit] root@eop# set deployment cluster applications web-ui web-admin-user "user-admin@juniper.net" [edit] root@eop# set deployment cluster applications web-ui web-admin-password Userpasswd [edit]
Where:
ntp-serversis the NTP server to synchronize to.web-admin-userandweb-admin-passwordare the e-mail address and password that the first user can use to log in to the Web GUI.Configure generic ingress and Active Assurance Test Agent gateway (TAGW) parameters.
On KVM, Proxmox VE, or ESXi, configure the VIP addresses:
root@eop# set deployment cluster common-services ingress ingress-vip generic-ingress-vIP [edit] root@eop# set deployment cluster applications active-assurance test-agent-gateway-vip TAGW-vIP [edit]
Where:
ingress-vipis the VIP address for generic common ingress and is used to connect to the Web GUI.test-agent-gateway-vipis the VIP address for the Active Assurance Test Agent gateway (TAGW).The VIP addresses are added to the outbound SSH configuration that is required for a device to establish a connection with Routing Director.
Note:In a multi-subnet cluster installation, the VIP addresses must not be in the same subnet as the cluster nodes.
On AWS, configure the hostnames:
root@eop# set deployment cluster common-services ingress system-hostname generic-ingress-hostname [edit] root@eop# set deployment cluster applications active-assurance test-agent-gateway-hostname TAGW-hostname [edit]
Where:
system-hostnameis the hostname address for generic common ingress and is used to connect to the Web GUI. This hostname is the network load balancer URL that you noted down after creating the load balancer for ingress.test-agent-gateway-hostnameis the hostname address for the Active Assurance Test Agent gateway (TAGW). This hostname is the network load balancer URL that you noted down after creating the load balancer for the TAGW.The hostnames are added to the outbound SSH configuration that is required for a device to establish a connection with Routing Director.
(Optional) Configure hostnames for generic ingress and Active Assurance TAGW.
root@eop# set deployment cluster common-services ingress system-hostname ingress-vip-dns-hostname [edit] root@eop# set deployment cluster applications active-assurance test-agent-gateway-hostname nginx-ingress-controller-hostname [edit]
Where:
system-hostnameis the hostname for the generic ingress virtual IP (VIP) address.test-agent-gateway-hostnameis the hostname for the Active Assurance TAGW VIP address.When you configure hostnames, the hostnames take precedence over VIP addresses and are added to the outbound SSH configuration. The hostnames can resolve to either IPv4 or IPv6 VIP addresses or both.
Note: On AWS, hostnames are already configured in the previous step.Configure the PCE server VIP address.
root@eop# set deployment cluster applications pathfinder pce-server pce-server-vip PCE-vIP [edit]
Where:
pce-server-vipis the VIP address that is used by the PCE server to establish Path Computational Element Protocol (PCEP) sessions between Routing Director and the devices. The VIP address can be on the same subnet as the cluster nodes or on a different subnet. The VIP address can be on different subnets from the other VIP addresses.On AWS,
pce-server-vipis the IP address that you obtained when you resolved the PCE server load balancer DNS name.Note:Configure the PCE server VIP address to view your network topology updates in real-time.
You can also configure the VIP address at any time post cluster deployment. For information on how to configure the PCE server VIP address after cluster deployment, see Configure a PCE Server.
(Optional) Configure the routing observability feature and VIP addresses to establish BGP Monitoring Protocol (BMP) session and IPFIX data collection.
root@eop# set deployment cluster applications routingbot install-routingbot true [edit] root@eop# set deployment cluster applications routingbot routingbot-crpd-vip v4-crpd-address [edit] root@eop# set deployment cluster applications routingbot routingbot-ipfix-vip v4-ipfix-term-address [edit]
Where:
install-routingbotenables the routing observability feature.routingbot-crpd-vipis the VIP address used by external network devices as BMP station IP address to establish the BMP session. On AWS, it is the IP address that you obtained when you resolved the routing observability CRPD service.routingbot-ipfix-vipis the VIP address to view predictor events. On AWS, it is the IP address that you obtained when you resolved the routing observability IPFIX term.Warning: The bare minimum resources required to configure routing observability features are listed in Hardware Requirements. However, to get an estimate of the resources required to configure the routing observability feature on your production deployment, contact your Juniper Partner or Juniper Sales Representative.(Optional) Enable the AI-ML (artificial intelligence [AI] and machine learning [ML]) use case.
root@eop# set deployment cluster applications aiops install-aiml true [edit]
Where:
install-aimlenables AI-ML features. This is disabled, by default.Warning: The bare minimum resources required to configure AI-ML is listed in Hardware Requirements. However, to get an estimate of the resources required to configure the AI-ML use case on your production deployment, contact your Juniper Partner or Juniper Sales Representative.(Optional) Configure IPv6 addresses.
root@eop# set deployment cluster kubernetes address-family cluster-ipv6-enabled true [edit] root@eop# set deployment cluster common-services ingress ingress-vip-ipv6 generic-ingress-IPv6 [edit] root@eop# set deployment cluster applications active-assurance test-agent-gateway-vip-ipv6 TAGW-IPv6 [edit] root@eop# set deployment cluster install prefer-ipv6 true [edit]
Where:
cluster-ipv6-enabledenables usage of IPv6 addresses for the cluster making the cluster dual-stack.ingress-vip-ipv6is the IPv6 VIP address for generic common ingress and is used to connect to the Web GUI.test-agent-gateway-vip-ipv6is the IPv6 VIP address for the Active Assurance TAGW.prefer-ipv6configures preference for IPv6 addresses over IPv4 addresses. When set totrue, and if hostnames are not configured, IPv6 VIP addresses are added to the outbound SSH configuration.The VIP addresses can be on the same subnet as the cluster nodes or on a different subnet. The VIP addresses can also be on different subnets from each other.
Note: Configuring IPv6 addresses is not supported in AWS.(Optional) If you want to use multiple VIP addresses for generic ingress or if you are connecting two separate networks with individual NICs, configure the additional VIP address for NETCONF.
root@eop# set deployment cluster common-services ingress ingress-vip netconf-vIP [edit] root@eop# set deployment cluster applications oc-term oc-term-host address netconf-vIP [edit]
Where:
ingress-vipis used to configure an additional VIP address to be used for NETCONF. When more than oneingress-vipaddresses are defined, you can configure one VIP address to be used to connect to the GUI and the additional VIP address to be used for NETCONF access.oc-term-hostis the VIP address that you want to use for NETCONF.The address configured for NETCONF is added to the outbound SSH configuration used to adopt devices.
If your cluster is connected to two networks with dual NICs, configure the additional VIP address for generic ingress. The generic-ingress-vIP VIP address configured first in step 5 is used to access the GUI and NETCONF, by default. To use the VIP address of your second network for NETCONF access, configure the netconf-vIP VIP address of your second network as explained in this step.
Note: The use of multiple NICs is not supported in AWS.(Optional) If your cluster nodes are in different subnets, configure BGP peering between the ToR router and the cluster nodes using the metalLB agent running in each cluster node. In this example, as illustrated in Figure 2, cluster nodes 1 and 2 are served by ToR1 and cluster nodes 3 and 4 are served by ToR2.
root@eop# set deployment cluster install enable-l3-vip true [edit] root@eop# set deployment cluster common-services metallb metallb-bgp-peer peer-ip ToR1-IP peer-asn ToR1-asn local-asn node-asn local-nodes node1_IP [edit] root@eop# set deployment cluster common-services metallb metallb-bgp-peer peer-ip ToR1-IP peer-asn ToR1-asn local-asn node-asn local-nodes node2_IP [edit] root@eop# set deployment cluster common-services metallb metallb-bgp-peer peer-ip ToR2-IP peer-asn ToR2-asn local-asn node-asn local-nodes [node3_IP node4_IP] [edit] root@eop# set deployment cluster common-services metallb metallb-bgp-peer-ipv6 peer-ip ToR1-IPv6 peer-asn ToR1-asn local-asn node-asn local-nodes [node1_IP node2_IP] [edit] root@eop# set deployment cluster common-services metallb metallb-bgp-peer-ipv6 peer-ip ToR2-IPv6 peer-asn ToR2-asn local-asn node-asn local-nodes [node3_IP node4_IP] [edit]
Where:
enable-l3-vipenables L3 VIP addresses for cluster nodes and VIP addresses in different subnets.metallb-bgp-peerandmetallb-bgp-peer-ipv6are the IP and IPv6 addresses of the ToR routers, respectively.peer-asnis the ToR AS number.local-asnis the AS number of the cluster nodes. The AS number remains the same for all the cluster nodes.local-nodesare the cluster nodes IP addresses configured in step 3.Note: On AWS, BGP peering and ToR integration does not need to be configured.(On AWS) Enable external load balancer.
root@eop# set deployment cluster install install-metallb false [edit] root@eop# set deployment cluster install external-load-balancer true [edit] root@eop# set deployment cluster common-services ingress ingress-load-balancer-type node-port [edit]
?will not display these options and pressing tab will not auto-complete these commands.Note: Using an external load balancer is possible on deployments running on Proxmox VE, KVM, and ESXi hypervisors. However, external load balancer configuration is beyond the scope of this document.Configure the scale size of your cluster. If your cluster is configured with the bare minimum resources required to install a cluster, the scale mode of the cluster is
small. The scale mode is set tosmallby default and you can skip this step.If you want to install a cluster that supports more devices and you have at least 32 vCPUs and 64-GB RAM, you must change the scale mode to
large.root@eop# set deployment cluster install scale-mode large [edit]
For a single node deployment, you must change the scale mode to
single.root@eop# set deployment cluster install scale-mode single [edit]
(Optional) Configure the following settings for SMTP-based user management.
root@eop# set deployment cluster mail-server smtp-relayhost smtp.example.com [edit] root@eop# set deployment cluster mail-server smtp-relayhost-username relayuser [edit] root@eop# set deployment cluster mail-server smtp-relayhost-password relaypassword [edit] root@eop# set deployment cluster mail-server smtp-allowed-sender-domains example.com [edit] root@eop# set deployment cluster mail-server smtp-sender-email no-reply@example.com [edit] root@eop# set deployment cluster mail-server smtp-sender-name Juniper Routing Director [edit] root@eop# set deployment cluster papi papi-local-user-management false [edit] root@eop# set deployment cluster mail-server smtp-enabled true [edit]
Where:
mail-server smtp-enabledenables or disables SMTP. When enabled users receive e-mail invitations to access organizations and notifications for subscribed alerts or events.smtp-relayhostis the name of the SMTP server that relays messages.smtp-relayhost-username(optional) is the username to access the SMTP (relay) server.smtp-relayhost-password(optional) is the password for the SMTP (relay) server.smtp-allowed-sender-domainsare the e-mail domains from which Routing Director sends e-mails to users.smtp-sender-emailis the e-mail address that appears as the sender's e-mail address to the e-mail recipient.smtp-sender-nameis the name that appears as the sender’s name in the e-mails sent to users from Routing Director.papi-local-user-managementenables or disables local-user management. When disabled, users are invited, over e-mail, to set their own passwords to log in to an organization. SMTP must be enabled for users to receive e-mails.Note:SMTP configuration is optional at this point. SMTP settings can be configured after the cluster has been deployed also. For information on how to configure SMTP after cluster deployment, see Configure SMTP Settings in Deployment Shell.
(Optional) Install custom user certificates. Note, before you install user certificates, you must copy the custom certificate file and certificate key file to the Linux root shell of the node from which you are deploying the cluster. Copy the files to the /root/epic/config folder.
root@eop# set deployment cluster common-services ingress user-certificate use-user-certificate true [edit] root@eop# set deployment cluster common-services ingress user-certificate user-certificate-filename "certificate.cert.pem" [edit] root@eop# set deployment cluster common-services ingress user-certificate user-certificate-key-filename "certificate.key.pem" [edit]
Where:
user-certificate-filenameis the user certificate filename.user-certificate-key-filenameis the user certificate key filename.Note:Installing certificates is optional at this point. You can configure Routing Director to use custom user certificates after cluster deployment also. For information on how to install user certificates after cluster deployment, see Install User Certificates.
(Optional) Configure and enforce security between the PCE server and Path Computation Clients (PCC) using system generated certificates.
root@eop# set deployment cluster applications pathfinder pce-server pce-server-global-default-tls-mode strict-enable [edit]
Where:
pce-server-global-default-tls-modeenables PCEP security. You can set it toauto-detectorstrict-enable. It is set tostrict-disable, by default.Note:Enabling PCEP security is optional at this point. You can configure Routing Director to enforce PCEP security after cluster deployment also. Additionally, you can enforce PCEP security using custom certificates. For information on enabling PCEP security using system generated or custom certificates after cluster deployment, see Enable PCEP Security.
(Optional) You can manually change the port number associated with NETCONF access from the default port number 2200.
root@eop# set deployment cluster applications oc-term oc-term-port-external alt-netconf-port [edit]
The alt-netconf-port port number configured for NETCONF is added to the outbound SSH configuration used to adopt devices.
Note: Ensure that you configure an unused and non-reserved port number.(Optional) If your VMs or network devices use the 10.96.0.0/12 or 10.244.0.0/16 ranges, you must specify a different CIDR block for the Kubernetes pods and services.
root@eop# set deployment cluster kubernetes kubernetes-pod-cidr new-pod-IP root@eop# set deployment cluster kubernetes kubernetes-service-cidr new-service-IP
Where:
kubernetes-pod-cidrandkubernetes-service-cidrIP addresses should not be in the defined ranges. For example, 10.97.0.0/16 or 10.255.0.0/16. Note, both these commands are hidden and typing?will not display these options and pressing tab will not auto-complete these commands.Note: You must configure custom CIDR ranges during a fresh installation of Routing Director. We do not support configuring these post-cluster deployment.Commit the configuration and exit configuration mode.
root@eop# commit commit complete [edit] root@eop# exit Exiting configuration mode root@eop>
Generate the configuration files.
root@eop> request deployment config Deployment inventory file saved at /epic/config/inventory Deployment config file saved at /epic/config/config.yml
The inventory file contains the IP addresses of the VMs.
The config.yml file contains minimum Routing Director deployment cluster configuration parameters that are required to deploy a cluster.
The
request deployment configcommand also generates a config.cmgd file in the config directory. The config.cmgd file contains all thesetcommands that you have executed. If the config.yml file is inadvertently edited or corrupted, you can redeploy your cluster using theload set config/config.cmgdcommand in the configuration mode.Generate SSH keys on the cluster nodes.
When prompted, enter the SSH password for the VMs. Enter the same password that you configured to log in to the VMs.
root@eop> request deployment ssh-key Setting up public key authentication for ['node1-IP','node2-IP','node3-IP','node4-IP'] Please enter SSH username for the node(s): root Please enter SSH password for the node(s): checking server reachability and ssh connectivity ... Connectivity ok for node1-IP Connectivity ok for node2-IP Connectivity ok for node3-IP Connectivity ok for node4-IP SSH key pair generated in node1-IP SSH key pair generated in node2-IP SSH key pair generated in node3-IP SSH key pair generated in node4-IP copied from node1-IP to node1-IP copied from node1-IP to node2-IP copied from node1-IP to node3-IP copied from node1-IP to node4-IP copied from node2-IP to node1-IP copied from node2-IP to node2-IP copied from node2-IP to node3-IP copied from node2-IP to node4-IP copied from node3-IP to node1-IP copied from node3-IP to node2-IP copied from node3-IP to node3-IP copied from node3-IP to node4-IP copied from node4-IP to node1-IP copied from node4-IP to node2-IP copied from node4-IP to node3-IP copied from node4-IP to node4-IP
Note:If you have configured different passwords for the VMs, ensure that you enter corresponding passwords when prompted.
Deploy the cluster.
root@eop> request deployment deploy cluster Process running with PID: 231xx03 To track progress, run 'monitor start /epic/config/log' After successful deployment, please exit Deployment-shell and then re-login to the host to finalize the setup
The cluster deployment begins and takes between one and two hours to complete.
(Optional) Monitor the progress of the deployment onscreen.
root@eop> monitor start /epic/config/log
The progress of the deployment is displayed. Deployment is complete when you see an output similar to this onscreen.
<output snipped> PLAY RECAP ********************************************************************* node1-IP : ok=2397 changed=1015 unreachable=0 failed=0 rescued=0 ignored=15 node2-IP : ok=192 changed=96 unreachable=0 failed=0 rescued=0 ignored=0 node3-IP : ok=192 changed=96 unreachable=0 failed=0 rescued=0 ignored=0 node4-IP : ok=186 changed=95 unreachable=0 failed=0 rescued=0 ignored=0 Tuesday 15 August 2026 22:00:57 +0000 (0:00:00.183) 1:01:53.469 ***** =============================================================================== user-registry : Push Docker Images from local registry to paragon registry - 335.76s kubernetes/addons/rook : Wait for Object-Store ------------------------ 213.36s kubernetes/multi-master-rke2 : start rke2 server on 1st master -------- 212.18s jcloud/papi : wait for papi rest api ---------------------------------- 122.19s jcloud/airflow2 : Install Helm Chart ---------------------------------- 117.00s Check if kafka container is up ---------------------------------------- 108.86s Install Helm Chart ---------------------------------------------------- 106.30s kubernetes/addons/postgres-operator : Make sure postgres is fully up and accepting request using regular user -- 73.73s systemd ---------------------------------------------------------------- 62.14s kubernetes/addons/postgres-operator-rb : RB >>> Make sure postgres is fully up and accepting request using regular user -- 52.96s kubernetes/multi-master-rke2 : start rke2 server on other master ------- 51.71s Create Kafka Topics ---------------------------------------------------- 51.48s systemcheck : Get Disk IOPS -------------------------------------------- 49.09s delete existing install config-map - if any ---------------------------- 43.10s paa/timescaledb : Make sure postgres is fully up and accepting request using regular user -- 41.96s kubernetes/multi-master-rke2 : start rke2 server on other master ------- 41.90s Save installer config to configmap ------------------------------------- 41.47s Install Helm Chart ----------------------------------------------------- 35.92s Verify healthbot victoriametrics --------------------------------------- 35.17s kubernetes/addons/vm-operator-rb : Wait for vm storage statefulset and pods -- 31.15s Playbook run took 0 days, 1 hours, 1 minutes, 53 seconds root@eop>
Alternatively, if you did not choose to monitor the progress of the deployment onscreen using the
monitorcommand, you can view the contents of the log file using thefile show /epic/config/logcommand. The last few lines of the log file must look similar to the sample output. We recommend that you check the log file periodically to monitor the progress of the deployment.Upon successful completion of the deployment, the application cluster is created. Log out of the VM and log in again to Deployment Shell.
The console output displays the Deployment Shell welcome message and the IP addresses of the four nodes (called Controller-1 through Controller-4), the Active Assurance TAGW VIP address, the Web admin user e-mail address, and Web GUI IP address. If IPv6 addresses are configured, the welcome message displays the IPv6 VIP addresses as well.
Welcome to Juniper Routing Director Shell This VM is part of a Juniper Routing Director Cluster with IPv6 enabled ======================================================================================= Controller IP : node1-IP, node2-IP, node3-IP, node4-IP PAA Virtual IP : TAGW-vIP, TAGW-vIPv6 UI : https://generic-ingress-vIP, https://[generic-ingress-vIPv6] Web Admin User : admin-user@juniper.net ======================================================================================= ova: 20260815_0206_ova build: eop-2.10.11716.g408e2a3366 *************************************************************** WELCOME TO Routing Director SHELL! You will now be able to execute Routing Director CLI commands! *************************************************************** root@Primary1>The CLI command prompt displays your login username and the node hostname that you configured previously. For example, if you entered Primary1 as the hostname of your primary node, the command prompt is
root@Primary1 >.
You can now verify the cluster deployment and log in to the Web GUI. If you are accessing the Web GUI from an external IP address, outside the Routing Director network, you must use NAT to map the external IP address to the Web GUI IP address.