ON THIS PAGE
Deploy the Cluster on AWS
This topic describes how to configure and deploy the Routing Director cluster on the provisioned infrastructure. It includes setting cluster parameters, generating configuration files, establishing secure access between nodes, and initiating the deployment. After completing this section, you can verify the deployment and access the Routing Director Web GUI.
After you have created the node VMs and prepared them as explained in Launch the EC2 VMs, configure the cluster parameters on the VMs and deploy the Routing Director cluster.
Deploy the cluster
Perform the following steps to configure and deploy the Routing Director cluster using Deployment Shell CLI.
Go 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 the 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. In this example, we are installing a four-node cluster. You can also install a three-node and single-node cluster.
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] root@eop# set deployment cluster ntp ntp-servers [ pool.ntp.org time.aws.com ] [edit] 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] 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:
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. Kubernetes nodes with index 1 is the current installer node. The IP addresses are AWS assigned.
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.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.
Configure the PCE server VIP address to view your network topology updates in real-time.
root@eop# set deployment cluster applications pathfinder pce-server pce-server-vip PCE-vIP [edit]
Where:
pce-server-vipis the IP address that you obtained when you resolved the PCE server load balancer DNS name. This IP address is used by the PCE server to establish Path Computational Element Protocol (PCEP) sessions between Routing Director and the devices.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 rb-crpd-nlb-vIP [edit] root@eop# set deployment cluster applications routingbot routingbot-ipfix-vip rb-ipfix-nlb-vIP [edit]
Where:
rb-crpd-nlb-vIP is the IP address that you obtained when you resolved the routing observability CRPD service and used by the external network devices as BMP station IP address to establish the BMP session.
rb-ipfix-nlb-vIP is the IP address that you obtained when you resolved the routing observability IPFIX term and used to enable to viewing of predictor events.
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]
Note: The last two commands are hidden. Typing?will not display these options and pressing tab will not auto-complete these commands.(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 feature on your production deployment, contact your Juniper Partner or Juniper Sales Representative.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) 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) Configure the following settings for SMTP-based user management.
root@eop# set deployment cluster mail-server smtp-relayhost smtp.relayhost.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 routingdirector.net [edit] root@eop# set deployment cluster mail-server smtp-sender-email no-reply@routingdirector.net [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:
smtp-allowed-sender-domainsare the e-mail domains from which Routing Director sends e-mails to users.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.mail-server smtp-enabledenables or disables SMTP.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 Paragon 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) 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 cluster configuration parameters that are required to deploy a cluster.
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
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 over an hour 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 Thursday 14 May 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@primary1>
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.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 all the nodes and the Web admin user e-mail address.
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 : UI : https:// Web Admin User : admin-user@juniper.net ======================================================================================= ova: 20260503_0048_ova build: eop-2.9.10975.ge4a31d62bf *************************************************************** WELCOME TO Routing Director SHELL! You will now be able to execute Routing Director CLI commands! *************************************************************** root@primary1>Note: The Active Assurance TAGW and Web GUI hostnames may not be displayed but are internally configured.
You can now verify the cluster deployment and log in to the Web GUI. Go to Log in to the Web GUI.
Log in to the Web GUI
After the cluster has been deployed, you can verify the deployment (optionally), and log in to the Web GUI using the information you entered during the deployment.
(Optional) Verify the deployment.
Verify cluster details.
root@primary1> show deployment cluster details Storage and Controller Node IPs: node1-IP, node2-IP, node3-IP, node4-IP
Verify cluster node details.
root@primary1> show deployment cluster nodes NAME STATUS ROLES AGE VERSION primary1 Ready control-plane,etcd,master 5d20h v1.35.1+rke2r1 primary2 Ready control-plane,etcd,master 5d20h v1.35.1+rke2r1 primary3 Ready control-plane,etcd,master 5d20h v1.35.1+rke2r1 worker4 Ready worker 5d20h v1.35.1+rke2r1
Log in to the Web GUI.
Enter the common ingress hostname address in the https://generic-ingress-hostname format in a Web browser to access the Routing Director login page.
Enter the Web admin user e-mail and password that you configured previously to log in to Routing Director. The Web admin user e-mail is also displayed on your console after the cluster deployment is complete.
You are logged in to the Routing Director GUI and are directed to the New Account page from where you can create a new Organization. For more information, see User Activation and Login.
For a list of cluster-related tasks that you can perform using Deployment Shell post installation of the Routing Director deployment cluster, see Post Installation Tasks.