What is the Nile Service?

What is the Nile service?

Connectivity should be secured and delivered as simply as utilities like electricity. This is our foundational belief, and underpins everything we create at Nile.

Nile provides wired and wireless connectivity as a service. In this document we will introduce the architecture and functions of the Nile Service, concluding with how it is deployed in a modern enterprise network.

A typical network consists of user and devices connecting via wired or wireless at the access layer. Upstream to the access is the core router and/or firewall which connects to the Internet. Nile focuses on providing Network as a Service for all wired and wireless users and devices.

Nile is not an MSP. We provide connectivity infrastructure in the same way Amazon, Google and Microsoft provide cloud compute. You configure the system to deliver services required, and Nile ensures the underlying infrastructure provides the necessary capacity and reliability.

The Nile Service is delivered by combining modern cloud architecture with fully integrated hardware. The Nile Service Block (NSB) includes switching, APs and sensors. Which have all been developed in-house, to achieve our goal of bringing an Apple-like experience to the enterprise. 

There are a number of notable innovations that support the Nile Service;

• 'Outside In' approach to active service monitoring.
• Redundancy By Default
• Layer 3, host based segmentation
• Campus Zero Trust
• Shared Responsibility

Let's explore each of these in more detail. 

The 'Outside-In' Approach

Our goal is to eliminate complexity and provide a simple, scalable, and secure network that doesn’t require manual configuration by humans. To ensure the service is always on, we have taken an outside-in approach using physical and virtual sensors that are deployed across the Nile network (including AP’s and switches).

We call this the "outside-in approach" because of its simplicity and the ability to easily verify the Nile sensor data. These sensors monitor the Nile network itself, as well as the DHCP, RADIUS, Internet, DNS, and applications, to identify any issues that can cause end-to-end service interruption. 

The Nile network is guaranteed to be always-on and backed financially if SLAs are not met.

Nile SLAs

Following are the SLAs Nile commits to:

Availability:The goal of this SLA is to ensure Nile is available for end users/devices. Our WiFi sensors probe the NSB every minute to ensure it is available. If the probes fail, Nile is in violation for that minute.

Coverage:The goal of this SLA is to confirm every sensor reports a five bars (-67dbm signal or better), every minute. If a single sensor does not receive this signal level, Nile is in violation for that minute.

Capacity: The goal of this SLA is to verify that the committed number of Nile APs are functioning across a floor. If the committed number is not met, Nile is in violation for that minute.

Nile commits to SLAs per building, monthly . The SLA is calculated as a percentage of the time Nile meets the SLA threshold. Nile calculates all of the violation minutes reported by all sensors in a building to measure the percentage of time that Nile meets SLA commitments. Unique to the industry, if we fall short on our commitment we provide financial credits back to you.

Our wall pluggable, WiFi physical sensors, and each AP’s 3rd radio sensor monitor the Nile service every minute to measure availability, coverage, and capacity of the network. If an issue with Nile disrupts service, this will be reflected in the Nile tile,directly affecting our committed SLA.

We built redundancy into every aspect of the Nile Service Block (APs and switches), therefore as an admin, you don't have to worry if an AP or a link is down, but rather if service is impacted. Service availability is truly reflected by these metrics that are continuously running.

[JR: I need to understand core/context in greater detail, and where it should fit in this doc?] Core: Core is basically what Nile offers, Secure Wireless and Wired connectivity as a service. Context: Context is the infrastructure that supports the Nile Service, these include the Internet, DHCP, DNS , Radius, device and applications

Redundancy By Default

Our SLA commitments are delivered by building redundancy throughout the Nile Service Block.

Distribution

Nile Distribution switches are always deployed with full redundancy to your upstream route/security, and downstream to Nile Access Switches, and OSPF is used throughout to automatically manage path redundancy. A hardware failure of a Nile Distribution switch is never service interrupting.

Access

Two Nile Access switches are deployed per floor, with Salt & Pepper Wi-Fi deployment. In the event of a hardware failure Wi-Fi coverage is unaffected, and only half your wired ports are offline. Upstream path redundancy is also automatically managed using OSPF.

Host Based Segmentation

Virtual segmentation of physical networks has changed little since 1998 when VLANs were first described by the IEEE 802.1q standard. We have now reached a point where traditional Layer 2 trunk and access port configurations do not meet the security and operational needs of modern enterprise networks.

The Nile Service uses Layer 3 host based segmentation for all wired and wireless access, allowing upstream security appliances like Palo Alto, and services like zScaler, to centrally enforce traffic and security policy.

What are Nile Segments?

Segments are a Nile construct operating at Layer 3 of the ISO model. Rather than defining an SSID to be on VLAN 2 we define the SSID to be a segment. Internally, a Segment maps to a subnet rather than a VLAN. This gives Nile the flexibility to map users and devices to segments rather than configure ports with VLANs. In the Nile world there is no port level config on a switch. When a device plugs in it is assigned a segment and gets an IP from the subnet that was mapped to that segment

Segments are global construct. For example if you have three sites, SFO, BLR and FRA, you can create a segment called Employee and map it to all locations. Once configured, you can define a subnet per geographic location. Segments will follow the user or device regardless of physical location, versus being tied to a physical port.

The diagram below illustrates how this works for two devices in the same Layer 3 segment.

Imagine a world without having to manage complex VLAN port configurations across your switched infrastructure, a world where  typographic mistakes in configuration files or command line are a thing of the past, a world where Campus Zero Trust access is a reality.

Campus Zero Trust

 

Shared Responsibility

Nile Service Architecture

Overview

Nile Cloud Platform

Providing everything you need to order, deploy and manage Nile Services, the intuitive Nile Cloud Platform can be used in the native web ui or via API.

Nile Service Block Hardware

NSB hardware, deployed throughout your sites, serves as the common access layer for both wired and wireless users, along with devices such as surveillance cameras and printers. The physical components of NSB include WiFi 6E APs, Distribution and Access Switches. 

There are no local interfaces to NSB hardware. The Nile Cloud Platform manages all aspects - from ordering and provisioning to operation and monitoring.

NILE DASHBOARD IMAGE

How is a Nile Service deployed?