SD-WAN

 View Only
last person joined: 10 days ago 

Ask questions and share experiences with SD-WAN and Session Smart Router (formerly 128T).
Back to Library

Video: Tenancy in 128T 

05-23-2018 00:23



In this installment of the 128T Data Model Series, we want to talk about the concept of tenancy in the 128T product family. In this lesson, we’ll discuss:

  • What are tenants in the 128T data model?
  • How do you define which hosts belong in a tenant?
  • How can you use tenants to affect routing decisions?
  • How can tenants be organized into hierarchies to give you a lot of flexibility in how you apply access policies in your network?
We’ll also show you how to configure a tenant in your 128T.
 
If you don’t have any hands-on experience with the 128T, it is recommended you first run through your own installation so you can follow along. If you are uncertain on how to perform an install, check out the Video: 128T Installation. You can also check out the Video: 128T PCLI Introduction if you don’t feel comfortable using it yet.

Tenancy
Tenants, along with services, represent the foundational building blocks of the 128T data model. By 128T data model, we mean the various components that you configure to model the behavior of the routers in your network. The 128T router uses the concept of “tenant” to identify collections of devices that all share access to the same network services — basically a group of endpoints that you would like to treat the same.

You can think of tenants in a 128T as similar to tenants in an apartment building. Just as two residents in the same apartment building share common attributes of the building — the mail room, garage, lobby, and so on, devices belonging to the same tenant in a 128T router share the same access to services offered by the network. You can think of a service as the destination you want to route to and the policies you want to apply to packets that route using that service. For example, two members of the “Finance” tenant may both have access to the same services that represent the accounting systems and payroll software. Members of the “Engineering” tenant will have access to the source code repositories and build systems. That leads us to the primary function of tenants in the 128T router: segmentation.
 
Segmentation
We use the term “segmentation” to describe the partitioning of network resources, such that some devices have routes within the network that others don’t. While you may be familiar with some forms of network segmentation — things like VLANs or VRFs — segmentation on the 128T router is done using tenants. In the example of the Finance and Engineering tenants, We mentioned that each would access to services that they need. But importantly, they will not have access to the services that you haven’t explicitly allowed; when you make the source code repository service available to the Engineering tenant, this is only “published” to that segment of your user population. Likewise, devices identified as belonging to the Finance tenant won’t have a route to the source code repository — it’s simply not reachable. This is one of the ways that we enable our customers to have Zero-Trust Security in their networks. That means you don’t allow anyone to have access to any of your services unless you explicitly give them access.  
 
Configuring tenants is extremely easy. All you need to do is give the tenant a name, such as finance.corporate and some rules that allow the 128T router to know which hosts belong to which tenants. How do those rules work?
 
How Tenants are Identified
Well, when the first packets of a new session arrive at a 128T router, one of the first orders of business is to associate that inbound traffic to a network tenant. This is done in one of two ways. First, it can arrive on an interface that is associated with a specific tenant via configuration. The interface in this case means a physical interface, possibly containing a VLAN tag. In this way, an administrator can “map” VLANs into tenants. In other words, when a packet enters your 128T from this particular interface, it doesn’t matter what it’s source IP address is, it will be mapped into the assigned tenant.
 
If you have multiple tenants that can use the same interface, then you can use IP address prefixes to determine which tenant a packet belongs to. You’ll use this technique if you have a mix of tenants comingled on the same LAN, not divided up into VLANs.
 
Configuring Tenants
So let’s look at how you assign a specific tenant to an interface. So that any packet arriving on that interface gets associated with the tenant irrespective of source address.


 
We’ll set the tenant of the network interface named “eno1” to “finance.corporate.” This means any new session that arrives on this interface is part of the finance.corporate tenant, and will get routing treatment as such. Now let’s configure an interface that associates requests to tenants based upon the subnet of the source.


  
This is a separate network interface, named “eno2.” It doesn’t have a tenant assigned. Instead of assigning a tenant, define a neighborhood on this interface, indicating here that the neighborhood is called corporateLAN. Don’t worry if you don’t know what a neighborhood is yet, we’ll cover that in a separate video. For now, just think of it as a label that defines a Layer 3 network.

 

We’ll reference that neighborhood label in the definition of the tenant named engineering.corporate as you see here. This bit of configuration says that any new session setup that lands on an interface assigned to the “corporateLAN” neighborhood — as we just defined on the eno2 interface — and is within the prefix 172.16.1.0/25, is defined as belonging to the engineering.corporate tenant. Then, we amend our configuration for finance.corporate to say it is represented by 172.16.1.128/25 within the corporateLAN neighborhood.

So, based on the source IP address of the first packet, your 128T router will associate it with the engineering.corporate tenant or the finance.corporate tenant, depending on which subnet it falls into. If it doesn’t fall into either of those subnets, it won’t have a tenant associated with it at all. When the system has no rule for assigning it to a tenant, the packet gets associated to what we call the global tenant. The global tenant only has access to services that have been marked as public, so if you don’t have any services marked as public, then these packets gets dropped.
 

Configuring Tenants



As I mentioned earlier, the 128T data model is organized around tenants and services. Here is a bit of service configuration to show how we associate tenants to services. Our configuration has two services defined: payroll and sourcecode. Payroll, as you’d expect, has a policy that allows finance.corporate to access it. Sourcecode has a policy that lets engineering.corporate access it.
 
This is reflected in the 128T router’s FIB:

 

Here you can see that the FIB entry for sourcecode only exists for engineering.corporate, and the FIB entry for payroll only exists for finance.corporate. After packets arrive and are affiliated with a tenant, the FIB is filtered based upon tenant, to only give them access to routes for the services you’ve “published” to them. In this example, if a packet is affiliated with engineering.corporate, the only FIB entry it’ll “see” is the one for 10.0.99.128/32, the sourcecode service. Any other destination address won’t match, and the session stops immediately.
 
Now, we’ll discuss how you can conceptualize your tenant model efficiently using hierarchies. If you use hierarchies, you can simplify the way you assign services to tenants to make your network easier to understand which will make it easier to configure and troubleshoot.
 

Hierarchies

You may have noticed that both of the example tenants we’ve showed you so far had the “.corporate” suffix. The 128T router uses dot separators to indicate a hierarchy. In this case, both engineering.corporate and finance.corporate were “children” of a common parent tenant named “corporate.” This interesting property of tenants lets you associate services with any level within the hierarchy, and all children will inherit access by default.
 
Using the same apartment building metaphor we discussed earlier, two roommates in the same apartment have access to that unit’s services such as the refrigerator and washing machine, but they share services like the mail room and garage with their neighbors in the same building. The parent tenant is the apartment building with the services of mail room and garage while the sub tenant is the apartment with the services of refrigerator and washing machine. Anyone who is a tenant of the apartment building will have access to the mail room and garage, including the members of the apartment, but only the roommates in the apartment will have access to that apartment’s washing machine and refrigerator.
 
Let’s take a look at how this works in the routing world by creating a new service:


 
Here we’ve created a new service and given access to the “corporate” tenant. This will also be inherited by all of the children of the corporate tenant -- in our examples, this has been engineering.corporate and finance.corporate. But it also would be inherited to THEIR children… qa.engineering.corporate, development.engineering.corporate, and so on. This is a good spot for me to point out that you can have an infinite number of tenants and subtenants, there is no limit. We don’t recommend having that many because it can be cumbersome to manage, but it is theoretically possible.
 
Let’s look at the FIB to see the results of this new configuration we’ve added:



Here you see three new entries in the FIB:
  1. one for corporate,
  2. one for finance.corporate,
  3. one for engineering.corporate 
All with the same IP prefix of the email service. So once the 128T classifies a new session source into a tenant and looks in the FIB for that tenant’s routes, any device within the “corporate” family of tenants will have access to the email system.
 

Conclusion

In conclusion, tenants don’t have a lot of configuration associated with the them, but they’re immensely powerful in segmenting your network’s resources, to grant or deny access to services to large collections of devices.
 
We’ve only just scratched the surface on how to model your network with tenants. Check the “Further Resources” links on this page to learn more about tenants and related features.

#Tenants #Segmentation​​​
#video
#eLearning

https://player.vimeo.com/video/247549317
Statistics
0 Favorited
1 Views
0 Files
0 Shares
0 Downloads

Related Entries and Links

No Related Resource entered.