Migration Topologies
In this document we will explore the following two use cases and see how they can be migrated to Nile;
- Large Campus Deployment - Multiple buildings and floors with enterprise applications
- Small to Medium Deployment - A single warehouse with beep and scan applications or an office floor or suite with enterprise applications
Large Campus Deployment
A large campus typically has multiple buildings connected via fiber to a core. It's usually a three-tier architecture with access, distribution, and core layers. As shown below, the existing distribution layer and access layer will be replaced by the Nile Service Blocks (NSBs). The Nile NSB gateway will connect to the core routers via a Layer 3 link and form an OSPF neighborhship to exchange routes. The existing DHCP, DNS, and RADIUS servers will be connected to the core layer or in the cloud.
The upstream device can be anything that supports OSPF or static routes with ECMP. Following are the types of devices we can connect to
- L3 Switch
- Core Router
- Firewall Appliance
- SD-WAN Appliance
OSPF
Nile service will automatically configure OSPF when Core or Uplink router interface facing Nile NSB gateway has OSPF enabled and configured:
Nile NSB gateway interface facing customer router/firewall default MTU is 9000 (jumbo frame) if uplink router tries to negotiate an adjacency on an interface in which the Nile NSB gateway neighbour has a larger MTU, the adjacency will be denied, Nile service will automatically adjust the MTU to match uplink router and establish OSPF adjacency.
Router Interface OSPF Options:
OSPF Options | Description |
|---|---|
Area ID | Defines the area ID for that interface facing the Nile NSB gateway. |
cost | Explicitly specifies the cost of sending a packet on an OSPF interface. |
Priority | Sets priority to help determine the OSPF-designated router for a network. |
network point-to-point | Configures an interface as point-to-point for broadcast media. |
hello-interval (seconds) | Specifies the length of time between the hello packets that the Cisco IOS software sends on an OSPF interface. |
dead-interval (seconds) | Sets the number of seconds that a device must wait before it declares a neighbor OSPF router down because it has not received a hello packet.
|
MTU | MTU needs to be matched between Nile NSB gateway and uplink router as OSPF packets cannot be larger than the interface MTU. |
Routing with VRF migration requirements
For multi-tenancy deployments that require virtual routing and forwarding (VRF) with LAN SVI to segment routing protocols between tenancies, customers will need to configure policy-based routing (PBR) on the interfaces facing the Nile NSB gateway cluster. This will map Nile segments to VRFs and enable VRF leaking to advertise the Nile NSB routes to the appropriate VRF routing.
Policy-Based Routing (PBR) for traffic from NSB to the enterprise tenant network
PBR uses a route map to specify an attribute other than the destination and then define the path out of the router based on these conditions, to support multi-tenant routing with VRF, the customer will need to change segment default VRF to specific VRF at the router ingress interface, to achieve this, customers will need a policy map to match a specific segment subnet/subnets, then set a new VRF to match tenant VRF, the router will use the tenant routing table to forward the traffic to the destination.
PBR | Description |
|---|---|
Access or prefix List | Access or prefix list (depending on router software) to match segment or segment subnets (Source IP). |
Route map | Route map to match the access or prefix list (match segment or segments) and change the VRF from default or original VRF to destination VRF (Set VRF) |
Policy | Apply a router map as an ingress policy under the interface facing the Nile NSB gateway |
VRF Leaking using static routes with VRF setting
VRF leaking | Description |
|---|---|
Static route with VRF | Create a static route for a specific segment with VRF and next-hop as NSB NSB gateway interface/IP |
Redistribute to BGP | Redistribute to BGP under VPN IPv4 VRF |
IP Prefix list | Match specific Nile segment subnet/subnets |
Route map | Use IP prefix list to create a route map of Nile segment/segments |
VRF | Import IPv4 unicast to VRF using segment/segments Route MAP |
BGP | Redistribute OSPF or Static route (Nile segments routes) to BGP |
Multiple NSB's
If the campus is very large, multiple NSBs can be installed, with each NSB scaling to serve multiple buildings. This design will divide the campus into multiple clusters of buildings, each managed by a different NSB.
Note: When multiple NSB's are used on a campus. unique subnets have to be defined for each segment. For example, if there are 3 NSBs in a campus, the Employee segment will have 3 unique subnets; one for each NSB
Split Core
In large campuses, there can be primary and secondary core. Nile's distribution layer can be split across the two cores to provide active-active redundancy
Small to Medium Deployment
This topology is common in small and medium-sized campus/branch sites where the core and distribution layers are combined. In this case, the Nile Service Block will replace the customer's existing distribution and access layers. The Nile Service Gateway will connect to the customer's core routers or Firewall via a Layer 3 link and form an OSPF neighborhship to exchange routes. The existing DHCP, DNS, and RADIUS servers will be connected to the core layer or on the cloud.
If a router or SD-WAN device is being used as the core the same routing principles outline in the previous section will apply. If a firewall is being used as a router, the VLANs need to be removed and converted to Nile Segments.
Firewall Policies with the Nile Access Service
Introduction
This document provides firewall policy recommendations when the Nile Access Service gateways are Layer 3 connected to the enterprise firewall. In this scenario, the Nile Access Service 1G/10G uplink ports are directly connected to one or a pair of firewalls, with the firewall interface IP addresses acting as the default gateways for the Nile gateways.
Firewall Networking Design
Firewalls are typically connected to the enterprise network in one of two ways:
- VLAN/Subnet Termination:
- Direct: The firewall acts as the core routing switch, with VLANs/subnets mapped directly to firewall zones. This design is common in small-to-medium enterprises due to its simplicity.
- Indirect: All VLANs terminate on a core switch, which then connects to the firewall via a trunk. This offers more flexibility in subnet exposure to the firewall, while other subnets are routed directly on the core switch.
- Layer 3 Termination:
- All VLANs/subnets are terminated on the core/distribution switch, which acts as the routing engine. The firewall is connected at Layer 3 as the default gateway to access the "Untrusted" / Internet and "DMZ" zones.
- This design offers VLAN scalability at the cost of internal segmentation, and the core/distribution switch shields the firewall from Layer 2 anomalies.
Nile Access Service Design
The Nile Access Service is provided through the Nile Service Block (NSB), which connects to the enterprise network through a pair of Layer 3 gateways (L3 Switches). The preferred connectivity is a direct Layer 3 connection to the enterprise firewall(s), which act as the default gateways for the NSB.
The Nile Access Service design can be considered a hybrid, combining subnet scalability and subnet segmentation through the built-in Policy-Based Routing (PBR) that directs all Nile client traffic to the firewall for traffic policing and segmentation. Additionally, the NSB design is inherently broadcast and Spanning Tree Protocol (STP) free.
Firewall Policies with the Nile Access Service
Since the Nile NSB connects to the firewall through two gateways, it consumes two physical interfaces/ports per firewall. For full redundancy with a pair of Active/Standby firewalls, four physical interfaces will likely be used.
Given that the NSB supports Equal-Cost Multi-Path (ECMP) routing, it is recommended to combine both interfaces to the NSB in a single security zone, which could be named "NSB".
With a Layer 3 termination to the firewall, client subnets enter the firewall from the same NSB zone. It is recommended to leverage the firewall's "Objects" construct to name subnets by their Nile segment, making the security policy rules easier to read and monitor in logs.
For example, in a Palo Alto Networks firewall, the use of Nile segment names in the source or destination addresses of a policy rule would make the rule much clearer when segmenting traffic originating from the Nile NSB:
This guidance applies to most firewall vendors, as the use of segment-based naming conventions can significantly improve the readability and manageability of the firewall policies in a Nile Access Service deployment.
