Network, IP Addressing, and Firewall Requirements

Network Requirements

The nodes must be able to communicate with each other through SSH. The nodes must be able to sync to an NTP server. SSH is enabled automatically during the VM creation, and you will be asked to enter the NTP server address during the cluster creation. Ensure that there is no firewall blocking NTP or blocking SSH traffic between the nodes in case they are on different servers.

• Cluster in a Single Subnet
• Cluster in Multiple Subnets
• Cluster with Multiple NICs
• Configure IPv4 Addresses
• Configure IPv6 Addresses

Figure 2: Multi-subnet Cluster

In AWS deployments, clusters can be deployed across a single or multiple subnets. Multi-subnet deployments are typically used to support high availability by distributing resources across multiple Availability Zones.

From a configuration perspective, no additional cluster-level setup is required to support multi-subnet deployments, as AWS Load Balancers handle traffic routing and failover. AWS does not require explicit network configuration such as BGP peering or TOR integration.

Figure 3: Dual NICs

On AWS

While AWS instances support multiple network interfaces, the use of dual NIC configurations is not required for typical cluster deployments and has not been qualified.

In most scenarios, network separation (for example, between device management and external GUI access) can be achieved using AWS Load Balancers rather than multiple NICs.

The following section lists the ports that IPv4 addresses and hostnames that must be available for installation.

On VMware ESXi, KVM, and Proxmox

You need to have the following IP addresses available for the installation.

• Interface IP addresses, one for each of the nodes.

  Note that, in a multi-NIC setup, each NIC must also have individual IP addresses.

  Note: Adding worker nodes beyond the documented configuration for increased capacity is not supported in the current deployment architecture.

• Internet gateway IP address

• Virtual IP (VIP) addresses for:

  • Generic ingress IP address shared between NETCONF (SSH connections from devices) and the Web GUI—This is a general-purpose VIP address that is shared between multiple services and used to access Routing Director from outside the cluster.

    Alternatively, when the network used to access the GUI is different from the device‑management network, you can assign one VIP address for Web GUI access and a different VIP address for NETCONF access. When two VIP addresses are configured using the ingress ingress-vip option, both the VIP addresses can be used for Web GUI and NETCONF access. However, only the first VIP address specified during configuration is added to the outbound SSH configuration used to adopt devices.

    To use a different VIP specifically for NETCONF, you must explicitly define that VIP address using the oc-term oc-term-host option. Once defined, this VIP address is included in the outbound SSH configuration used to adopt devices from the corresponding network.

    Although either VIP address can technically be used for GUI and NETCONF access, only the VIP address explicitly defined and configured for NETCONF is added to the outbound SSH configuration.

    If devices are in multiple networks, and you need to adopt devices in more than one network, you can manually edit the outbound SSH command to override the configured IP address for NETCONF access.

  • Active Assurance Test Agent gateway (TAGW)—This VIP address serves HTTP-based traffic to the Active Assurance Test Agent endpoint.

  • PCE server—This VIP address is used to establish Path Computational Element Protocol (PCEP) sessions between Routing Director and the devices. The PCE server VIP configuration is necessary to view dynamic topology updates in your network in real-time. For information on establishing BGP-LS peering and PCEP sessions, see Dynamic Topology Workflow.

    If your cluster is a multi-subnet cluster, you can also configure multiple VIP addresses, one from each subnet, for the devices to establish PCEP sessions on all VIPs.

  • Routing observability cRPD—This VIP is used by external network devices as BGP Monitoring Protocol (BMP) station IP address to establish the BMP session.

  • Routing observability IPFIX—This VIP is used to collect IPFIX data to view predictor events. Predictor events indicate routing, forwarding, and OS exceptions that are identified by Routing Director as a potential indicator of traffic loss.

  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 where the cluster nodes are in different subnets, the VIP addresses must not be on the same subnet as the cluster nodes.

• Hostnames mapped to the VIP addresses—Along with VIP addresses, you can also enable devices to connect to Routing Director using hostnames. However, you must ensure that the hostnames and the VIP addresses are correctly mapped in the DNS and your device is able to connect to the DNS. If you configure Routing Director to use hostnames, the hostnames take precedence over VIP addresses and are added to the outbound SSH configuration used during onboarding devices.

On AWS

You need to have the following IP addresses and hostnames available for the installation.

• Interface IP address for each node in the cluster

• Internet gateway IP address.

• Primary and secondary DNS server IPv4 addresses.

• NTP server information.

• AWS generated hostnames are available as DNS names when you create the network loadbalancers. You need the following hostnames:

  • Generic ingress hostname shared between NETCONF (SSH connections from devices) and the Web GUI—This is a general-purpose hostname that is shared between multiple services and used to access Routing Director from outside the cluster.

  • Active Assurance Test Agent gateway (TAGW)—This hostname serves HTTP-based traffic to the Active Assurance Test Agent endpoint.

  • PCE server—This hostname address is used to establish Path Computational Element Protocol (PCEP) sessions between Routing Director and the devices. You must resolve this hostname (using the nslookup DNS-name command) to determine the corresponding IP address before you deploy the cluster.

    The PCE server hostname configuration is necessary to view dynamic topology updates in your network in real-time. For information on establishing BGP-LS peering and PCEP sessions, see Dynamic Topology Workflow.

  • Routing observability cRPD—This hostname is used by external network devices as BGP Monitoring Protocol (BMP) station IP address to establish the BMP session. You must resolve this hostname (using the nslookup DNS-name command) to determine the corresponding IP address before you deploy the cluster.

  • Routing observability IPFIX—This hostname is used to collect IPFIX data to view predictor events. Predictor events indicate routing, forwarding, and OS exceptions that are identified by Routing Director as a potential indicator of traffic loss. You must resolve this hostname (using the nslookup DNS-name command) to determine the corresponding IP address before you deploy the cluster.

On AWS

IPv6 addresses are not supported for AWS deployments.

Additional IP addresses and hostnames for all deployment platforms

In addition to the listed IP addresses and hostnames, you need to have the following information available with you at the time of installation:

• Primary and secondary DNS server addresses for IPv4 and IPv6 (if supported)

• NTP server information

Firewall Requirements

The following section lists the ports that firewalls must allow for communication within and from outside of the cluster.

You must allow intracluster communication between the nodes. In particular, you must keep the ports listed in Table 1 open for communication.

The following ports must be open for communication from outside the cluster.

On AWS

The following table details the security group that is applied to the AWS load balancer to allow intracluster communication between the nodes.

Allow from everywhere

The following table details the security group that is attached to the EC2 instance and allows traffic flow to and from the VMs.

Web Browser Requirements

The latest versions of Google Chrome, Mozilla Firefox, and Safari.

What's Next

To install Routing Director, go to Install on KVM, Proxmox VE, and VMware ESXi or Install on AWS, depending on your VM deployment platform.