In a previous blog post, I discussed how the 128T router’s service-oriented networking approach lets administrators describe the applications their network carries using a purpose-built modeling language. Once the applications are described, the network chooses the most suitable path, based upon the properties and requirements of that application, for each inbound session.
The 128T’s tenancy model takes this a step further, by ensuring the routes for these applications are made available only to the users (and devices) that should have them, in what is known as network segmentation.
Network segmentation is nothing new; network administrators have been using VLANs for well over a decade to restrict network access over arbitrary network topologies. More recently, a whole smorgasbord of tunneling overlays such as VXLAN, GRE, GENEVE, etc. have emerged to address “VLAN bloat” — when networks outgrow the maximum number of allowable VLANs. (And along with them, new superlatives have emerged to imbue a sense of differentiation: microsegmentation, hypersegmentation, and the like.)
The 128T’s tenants give network architects a new tool in their tool belt: a text-based, hierarchical model for organizing their network services. Here’s an example to help illustrate: when a service (application) such as a development lab automation platform is hosted within a tenant named “engineering”, only members of that tenant will have routes to the service. Create a second service to model your source code control platform and assign that to the “dev.engineering” tenant; this limits the scope of the routes to dev.engineering clients. The hierarchy implied by that string “dev.engineering” means that it is a subtenant within the engineering tenant. As a subtenant, a host within dev.engineering will have all routes for services hosted in dev.engineering as well as services hosted within the parent tenant engineering (our automation system), but the converse is not true. A host defined as part of the parent tenant will not have routes to get to the source control repository.
There’s no limit to the number of levels within a tenant hierarchy (e.g., dev.engineering.boston.128technology), so administrators are able to host services within the most suitable location within the tenant model to establish routability. Modeling the scope of your routes using a hierarchy gives very fine-grained control over which hosts (users, devices, and the like) can get to the services that your network is delivering. But it does so without resorting to a cryptic nest of VLANs, overlays, or ACLs.