SD-WAN

View Only

last person joined: 9 days ago

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

Back to Library

Video: Services in 128T

Recommend

05-23-2018 00:23

Justin

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

Definition of a service in 128T
How the 128T platform matches services to inbound traffic
How you can affect routing of traffic using service-routes
Ways you can secure your service
How you make services available to your network users — by setting the scope and access policies

While a lot of what we'll discuss today is conceptual, we’ll use the PCLI and GUI interfaces to illustrate some examples. If you don’t have any hands-on experience with the 128T, I recommend you start by running through your own installation so you can follow along. To learn how to install your own 128T, check out the Video: 128T Installation. Also, for a refresher, you can watch the Video: 128T PCLI Introduction and the Video: 128T GUI Introduction.

Services
Services, along with tenants, represent the foundational building blocks of the 128T Data Model. By Data Model, we mean the various configurable elements that you use to represent, or “model,” the behavior of the 128Ts in your network. In 128T-speak, a service represents the destination of network traffic — the places your network's users are trying to access:

Things such as websites, mail servers, or databases; they can be specific machines defined by a /32 prefix, or entire subnets up to and including 0.0.0.0, which represents all addresses.

In practice, you’ll find that you define a separate service configuration for each variety traffic that you want to give unique treatment.

Services are so-called Global Data, in that you define a service once for all of the routers in your network, and all routers share that exact same definition including any associated policies for access control, encryption, traffic distribution, and so on. Global data is shared within an Authority — the collection of 128T devices under a single administrative control.

Services aren’t just one of the building blocks of the model, they’re an essential component. In order to get your 128T to forward traffic that it receives, that traffic MUST MATCH a configured service. Said another way — every running 128T router has at least one service, or else it wouldn’t route anything. But you’ll usually find many more than one service.

To clarify, when we say the inbound traffic must match a service, we mean the destination address of the inbound packet must match the address associated with a service. Let's see how it works.

Configuring Services

Here we see the skeleton of a service that’s been configured on our lab system. It models a specific web server that I use to test Community development, located at 172.17.128.22. You can also see that we’ve defined two port ranges: TCP port 80 and TCP port 443, which are the well-known ports for HTTP and HTTPS, respectively. Taken together, the 128T in our lab will associate any inbound traffic that arrives with a destination address of 172.17.128.22, that uses TCP as its transport, and is directed at either port 80 or 443, and consider it to be a match with the service named “webserver.”

Note that in this example, all of those elements need to match exactly for it to be considered a match. We could have used a different netmask instead of that /32, and the 128T would’ve matched a range of network addresses on ports 80 or 443. Also, we could have omitted one or both of the port range definition statements. When no port range restrictions are specified, all ports will match.

But as written, this will match HTTP and HTTPS requests for our lab machine. Notably, it will NOT match any SSH, NFS, or other applications on that same machine. This is one of the ways a 128T can provide unique routing treatment for applications, giving priority to one over another, even when the destination is the same remote address.

Service Routes
Once your router has associated traffic to a service by matching the destination information within an inbound packet, the 128T will forward it according to its routing table. Just like any other router you’re familiar with, the 128T routing table is comprised of static routes that have been configured, and dynamic routes that it has learned from a routing protocol. Service configuration is combined with entries in the routing table to create FIB entries. That means in order for a FIB entry to appear for your service, you need both a service AND a route to get there.

show fib

On our lab system, we can see that there’s no FIB entry for my webserver service yet, just some ControlMessageServices that the system pre-populated to handle BGP traffic. That means we need to somehow install a route for that 172.17.128.22 address to let our 128T router know how to deliver the session.

There are several ways we can go about this:

We can configure a good old fashioned static route, to coerce the system to use a specific egress interface.
We can peer with a BGP neighbor that advertises reachability to my web server.
Or, unique to the 128T is a new notion, called a “service route.” These are associated with the services you’ve configured, to instruct your 128T on how to handle traffic that matches its service.

We should point out that all of the various routes we just mentioned (static routes, dynamic routes, and service-routes) are said to be Local Data. What that means is that they’re specific to a single router. Contrast this to Global Data — things like services and tenants — which are defined once and common among all routers in your network. Local Data is set up and managed on a router-by-router basis. This means that each router can define its own service-routes to handle traffic uniquely. Let’s take a look at a service-route, and we’ll go through some of the highlights.

Here we've created a service route named toWebserver, since it’s going to be a route to our lab webserver. We’ve also reference the service’s name, and configured a next hop. This next hop here instructs the 128T to send sessions out of the interface named “eno1” on the routing node named “labsystem1."

Once we put that configuration in, and commit it, a quick “show fib” will confirm that we now have forwarding rules in place for our webserver’s traffic! You can see two entries there: one for TCP port 80, and another for TCP port 443. That “next hops” column shows the internal representation of my “eno1” interface. We should also like take this opportunity to point out the Tenant column, where it says “global.” If you haven’t watched Video: Tenancy in 128T, you may want to do that now. That “global” tenant really means that the webserver service is only available to traffic sources that ARE NOT PART of a tenant.

Scope

Do you see that “scope” field, set to “public”? That’s responsible for that FIB entry associated with the Global tenant. The scope field has two values, public and private, and serves to control whether or not this service is accessible to tenantless sources, a.k.a. members of the Global tenant. This is handy when you have a service that is exposed on the public internet, such as a webserver like we have here, or another application that you’re publishing to the world at large. For most services, as a rule of thumb, you’ll probably want to set the scope to “private” — so that it’s not available on public networks.

But if your network is segmented using Tenants then how do you give your tenants access to this service? It’s done using access policies, right here in the service configuration.

NOTE: PT thinks tenant segmentation is "really cool."

We’ve added an access-policy for a Tenant in my network called “communityTeam”. We've also set the scope to Private, to show you how that affects the FIB entries in a moment. That access-policy is written in what we call a “QSN”, or “Qualified Service Name.” We’ll cover QSNs in a future 128TV episode in much more detail, but for now it’s sufficient to mention that this is how we allow access to the webserver to anything that’s classified as belonging to the communityTeam tenant.

t doesn’t matter where in our Authority the session is sourced from, as soon as any of those routers have classified it as a member of the communityTeam tenant then this service will be ready and waiting. This is the power of GLOBAL DATA — define tenants and services once, and they’re propagated throughout all routers.

Now let’s take a look at the revamped FIB output:

There you have it! The entries for the webserver affiliated with the Global tenant are gone because the scope was set to Private, and now the only entries that are there are associated with the communityTeam tenant due to the access policy we added. Just because we showed it to you this way doesn’t mean it’s either/or — you can combine access-policy statements with a public scope to allow BOTH Global tenant access and specific team access. Furthermore, you can also have an access-policy with its permission set to “deny” instead of "allow."

Security Policy

The security field is where you reference a configured security policy, to indicate how (or whether) this traffic should be encrypted. Security policies also let us configure which cipher to use and whether to use "adaptive encryption" or not. Each 128T system comes with a security policy called "internal" as part of its factory default configuration. Feel free to add your own, but this reference to a security policy indicates our desire to have traffic sent to this service encrypted.

Security policies are Global Data too — and it’s a good thing they are! Because the routers encrypting and decrypting the traffic had better be using the same keys, or else it’d make for a big unintelligible mess.

When security policies are applied at a service, as they are here, this represents the MOST SPECIFIC place where you can configure them on the 128T platform. That means they’ll trump any security policies configured on the peer level, or the tenant level, for traffic that matches this service. This might be handy if you want to really segment traffic apart, even within a tenant.

Conclusion
We hope you found this overview of services to be informative. There’s a lot to cover with services, so stay tuned for future videos where we dig deeper into the policies that govern how services and service routes can be used to have dramatic impacts on the way sessions flow around your network.

#services #ServiceRoutes #ServicePolicies #Tenants

#video
#eLearning

https://player.vimeo.com/video/258336500

Statistics

0 Favorited

1 Views

0 Files

0 Shares

0 Downloads

SD-WAN

Video: Services in 128T

Related Entries and Links