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 from nsb source nile segment a destination nile segment b action allow 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