Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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.

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

  2. To configure the cluster, enter the configuration mode in Deployment Shell.

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

    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-servers is the NTP server to synchronize to.

    web-admin-user and web-admin-password are the e-mail address and password that the first user can use to log in to the Web GUI.

    system-hostname is 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-hostname is 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.

  4. Configure the PCE server VIP address to view your network topology updates in real-time.

    Where:

    pce-server-vip is 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.

  5. Configure the routing observability feature and VIP addresses to establish BGP Monitoring Protocol (BMP) session and IPFIX data collection.

    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.

  6. Enable external load balancer.

    Note: The last two commands are hidden. Typing ? will not display these options and pressing tab will not auto-complete these commands.
  7. (Optional) Enable the AI-ML (artificial intelligence [AI] and machine learning [ML]) use case

    Where:

    install-aiml enables 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.
  8. 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 to small by 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.

    For a single node deployment, you must change the scale mode to single.

  9. (Optional) You can manually change the port number associated with NETCONF access from the default port number 2200.

    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.
  10. (Optional) Configure the following settings for SMTP-based user management.

    Where:

    smtp-allowed-sender-domains are the e-mail domains from which Routing Director sends e-mails to users.

    smtp-relayhost is 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-domains are the e-mail domains from which Routing Director sends e-mails to users.

    smtp-sender-email is the e-mail address that appears as the sender's e-mail address to the e-mail recipient.

    smtp-sender-name is the name that appears as the sender’s name in the e-mails sent to users from Routing Director.

    papi-local-user-management enables or disables local-user management.

    mail-server smtp-enabled enables 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.

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

    Where:

    user-certificate-filename is the user certificate filename.

    user-certificate-key-filename is 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.

  12. (Optional) Configure and enforce security between the PCE server and Path Computation Clients (PCC) using system generated certificates.

    Where:

    pce-server-global-default-tls-mode enables PCEP security. You can set it to auto-detect or strict-enable. It is set to strict-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.

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

    Where:

    kubernetes-pod-cidr and kubernetes-service-cidr IP 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.
  14. Commit the configuration and exit configuration mode.

  15. Generate the configuration files.

    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.

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

  17. Deploy the cluster.

    The cluster deployment begins and takes over an hour to complete.

  18. (Optional) Monitor the progress of the deployment onscreen.

    The progress of the deployment is displayed. Deployment is complete when you see an output similar to this onscreen.

    Alternatively, if you did not choose to monitor the progress of the deployment onscreen using the monitor command, you can view the contents of the log file using the file show /epic/config/log command.

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

    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.

  1. (Optional) Verify the deployment.

    1. Verify cluster details.

    2. Verify cluster node details.

  2. Log in to the Web GUI.

    1. Enter the common ingress hostname address in the https://generic-ingress-hostname format in a Web browser to access the Routing Director login page.

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