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 physical connectivity 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 t he 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 logical setup and routing nsb routing 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 nile support for ospf and ecmp the nile service block (nsb) requires an upstream router or firewall for connectivity to the nile cloud the nsb gateway, an access or distribution switch, serves as the connection point between the nsb and the upstream network device nsb gateways operate in an active active configuration and act as the default gateway for all nile elements (access switches, access points, and sensors) traffic is routed to the upstream router or firewall using either ospf or static routes, with ospf being the preferred method when ospf is used, no configuration is necessary on the nsb gateways the upstream firewall or router's configuration is sufficient for the nsb gateways to automatically learn routing parameters from hello messages if ospf is not configured, the nsb gateway automatically employs static routes with equal cost multi path (ecmp) for traffic forwarding 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 (firewall a) router ospf 1 router id 10 10 10 1 default information originate network 10 10 10 0 0 0 0 3 area 0 network 10 10 10 4 0 0 0 3 area 0 (firewall b) router ospf 1 router id 10 10 10 9 default information originate network 10 10 10 8 0 0 0 3 area 0 network 10 10 10 12 0 0 0 3 area 0 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 (firewall a) set protocols static route 10 50 100 0/22 next hop 10 10 10 2 set protocols static route 10 50 100 0/22 next hop 10 10 10 6 set protocols static route 0 0 0 0/0 next hop 10 10 10 2 distance 1 set protocols static route 0 0 0 0/0 next hop 10 10 10 6 distance 1 (firewall b) set protocols static route 10 50 100 0/22 next hop 10 10 10 10 set protocols static route 10 50 100 0/22 next hop 10 10 10 14 set protocols static route 0 0 0 0/0 next hop 10 10 10 10 distance 1 set protocols static route 0 0 0 0/0 next hop 10 10 10 14 distance 1 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 be the default gateway for all client subnets and these default gateways must be accessible from the upstream routers or firewalls service bringup to activate the entire network of access switches, access points, and sensors, the nsb gateway requires the following parameters two uplink ip addresses while one is optional, using two is recommended for redundancy a subnet for ap and switches this subnet is used to allocate ip addresses to nile elements such as switches and access points a subnet for nile sensors nile sensors are treated as client devices and require a separate subnet for network monitoring dns server (optional) ntp server (optional) these settings are transmitted to the nsb gateway via bluetooth firewall /acl configuration 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 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