Integrating Routers with the Nile Access Service
When deploying the Nile Access Service, the integration between the Nile Service Block (NSB) and the customer's upstream routers or firewalls is a critical step. This article provides guidance on how to configure the router integration to ensure a successful Nile Access Service deployment.
All Nile access and distribution switches provide several high-speed uplink ports to connect to the customer's upstream routers or firewalls. Nile recommends connecting, via the high-speed uplink ports, each of the NSB Gateways to the customer's upstream routers or firewalls.
The uplink speeds supported by the Nile Service Blocks range from 1Gbps to 100Gbps, with the choice of Ethernet or fiber optic ports depending on the required throughput and the customer's existing infrastructure.
Since the Nile Access Service operates at Layer 3, there is no Layer 2 VLAN trunking between the NSB and the customer's upstream routers. All traffic is routed between the Nile Service Block and the customer's upstream devices.
In the next section, we can see examples of OSPF and ECMP being used to route traffic across the transit networks that connect the NSB to the customer's firewall and routing infrastructure. The diagram below shows the topology used in the examples.
- OSPF (Open Shortest Path First): This is a simple and reliable way to manage the traffic flow between the NSB and the customer's routers or firewalls. The customer should configure OSPF on the upstream devices using the transit network subnets connecting to the Nile elements.
Example OSPF Configuration
- ECMP (Equal-Cost Multi-Path): If the customer's routers or firewalls do not support OSPF, ECMP routing can be used. In this case, the upstream devices must be configured with equal-cost routes to the client subnets behind the Nile Service Block.
Example ECMP Configuration
Regardless of the routing protocol used, the key is to ensure that the routes to the client subnets behind the Nile Service Block are reachable from the customer's upstream devices. Nile will use the first usable IP address in each client subnet as the default gateway, and these default gateways must be accessible from the upstream routers or firewalls.
To allow all Nile Service Block elements to communicate with the necessary cloud services, any firewalls or router ACLs in the traffic path should be configured with the following rules:
- Permit outbound HTTPS (TCP/443) to the following URLs and IPs:
- u1.nilesecure.com
- ne-u1.nile-global.cloud(resolves to 52.13.104.212, 100.20.40.199, 52.12.186.175)
- https://s3.us-west-2.amazonaws.com/nile-prod-us-west-2 (required for device upgrades only)
- Permit outbound DNS (UDP/53) to the following IP addresses:
- Nile will use these as default DNS servers for NSB elements (not clients):
- 8.8.8.8
- 8.8.4.4
- If you would prefer the NSB uses your own DNS servers, those will override our defaults. Your server must be configured to accept DNS requests from Nile Service Block elements.
- Permit outbound NTP (UDP/123) to the following URLs:
- Nile will use these as default NTP servers for NSB elements (not clients):
- time.google.com
- pool.ntp.org
- If you would prefer the NSB uses your own NTP servers, those will override our defaults. Your server must be configured to accept NTP requests from Nile Service Block elements.
- Permit RADIUS authentication (UDP/1812 and UDP/1813) from the Nile management subnet IP address to the customer's RADIUS server(s)
- Permit DHCP (UDP/67 and UDP/68) for subnets used in the Nile Service Block to the customer's DHCP servers.
By following these specific firewall configuration guidelines, you can ensure that the Nile Service Block elements can communicate with the required cloud services and authentication servers.