The 128T Session Smart routing platform has several techniques by which it can associate inbound traffic to named applications. This is sometimes referred to as "Application Identification" (or "appID"), and the feature that allows administrators to define network policies using Fully Qualified Domain Names (FQDNs) instead of IP addresses.
The 128T router has three built-in techniques for affiliating named applications to services, all of which will be described in this document. (A fourth technique, involving service function chaining third party software is not covered here.) The three techniques are:
- Using DNS to resolve FQDNs to IP addresses
- Using the
- Using the
Generally, when configuring a
service on a 128T router, administrators use the
address field to identify the IP address(es)/CIDR block(s) that the 128T should use to match to inbound traffic. However, the
address field will also accept hostnames, such as
www.128technology.com. When a service uses a hostname in the
address field, it is referred to as a DNS-based service.
For every DNS-based service, the 128T will use its local DNS to resolve the hostnames; for every IP address that is returned the 128T will treat that as though it were configured in the
address field, and install FIB entries accordingly. It will also refresh these FIB entries based on the time-to-live (TTL) returned by the DNS server. Here is a sample configuration for reference:
In this configuration, the
address is configured as
community.128technology.com. This will be resolved once the configuration is committed, and the 128T will resolve that hostname and install FIB entries. The 128T will periodically re-resolve those hostnames to ensure that the FIB entries are kept up-to-date.
The names used in the
address field must be DNS-resolvable names. You cannot use wildcards such as
- This is a very easy and intuitive way to associate traffic to services, without having to define a long list of IP addresses. When upstream devices change their IP address, there's no need to reconfigure the 128T to keep it up-to-date, as this is handled by DNS.
- Unlike AppID based on TLS, there is no "chicken and egg issue;" i.e., no prerequisite to have the destination be reachable in order to learn the destination's name.
This technique relies on your 128T getting the same answers from DNS that your clients get. Take for example a massive SaaS provider such as
www.salesforce.com. Their web site resolves to hundreds or thousands of IP addresses distributed across the globe. When the 128T resolves that hostname, it will get a handful of answers; if a client does the same DNS query and gets a different set of answers, then the traffic the client sends will not match the FIB entries that the 128T has created.
Key to success
Use DNS-based services when your destination uses a small set of nonvolatile IP addresses. This technique is perfect for small, hosted services. The effectiveness of using DNS-based services diminishes rapidly when referencing names that resolve to dozens of address or more.
The 128T router can also learn about named destinations by inspecting the traffic that traverses it. This is done by inspecting the X.509 certificate sent by a server during the TLS handshake process. Importantly: this presupposes that the 128T can route packets to that destination for the purposes of retrieving the server's certificate. Thus, when using AppID based on TLS, it is important to ensure that there is a
service-route capable of reaching that server in addition to the one you'll configure for the named application.
Normally this is done by having a "catch-all" service for
0.0.0.0/0 to route traffic out to the internet, but it does not need to be.
Server Hello message sent by a server will include its X.509 certificate, which is decipherable by the client to include information about the server. One such example is here:
This sample certificate was supplied by FM4DD.
About a third of the way through the output you can see that the Common Name (listed as
CN in the
Subject line) is
www.example.com. This is what 128T will parse and subsequently retain as the "application name" for this destination. Assuming this matches a configured
application-name within a
service, a FIB entry is installed with this server's IP address and associated with the
To enable application identification based on TLS, configure the
application-identification element within the
router context as seen here:
For reference, here's a
service that would leverage the X.509 certificate shown above:
Here we can see the
application-name set to
www.example.com, which matches the Common Name from the X.509 certificate in our example. Assuming we had a
service-route capable of reaching
www.example.com to begin with, the TLS handshake would see the server's X.509 certificate returned back to the client through the 128T. The 128T parses the certificate, recognizes
www.example.com as belonging to the service named
example and installs a FIB entry for it with the server's IP address.
example service needs to have its own
service-route in order for traffic to be forwarded.
With the TLS-based application identification technique, the
application-name can include a wildcard such as
*.example.com, which is not possible with the DNS-based approach. This gives administrators a bit more flexibility in defining which traffic to match to services when parsing the X.509 certificates.
The last, and arguably most powerful built-in technique for performing application identification is to use a module – effectively, a script that is resident on the 128T router's host operating system that will generate a JSON file that contains dynamic, ingestible routes. This is extremely flexible, but requires some programming expertise.
It is also possible to simply place a static JSON document on the 128T's filesystem (i.e., one that is not generated by a local script) as a means of feeding an application identification module into the 128T).
Configuring application identification based on modules first requires that a router have the feature enabled:
Scripts are placed on the router's filesystem at
/etc/128technology/application-modules/. These scripts produce a JSON output stored at
/var/run/128technology/application-modules/, which in turn is processed by the 128T router and installed as FIB entries.
Beginning with the 5.2 release,
systemd may be used to manage the execution of application identification modules. JSON output produced by the module is passed directly to the highway REST API instead of being written to disk.
Using this approach, modules are registered by creating a file at
/etc/128technology/application-modules/services/<module-name>. This file lists the systemd units of the module and specifies if and how 128T should interact with them.
reload-service: When the highway process starts, reload the systemd unit. This is a signal to POST the JSON to highway again as module data is not saved through process restarts.
stop-on-shutdown: Stop the systemd unit when 128T is shutting down.
Modules must be registered in order for 128T to accept the POST of JSON module data.
In the following example, a systemd timer unit is used to periodically invoke the main service/script, which does the work of gathering module data. Both are stopped on shutdown, but only the timer unit needs to fire again on restart of 128T.
For more information about using timers with the systemd service, refer to ArchLinux systemd/Timers.
Beginning with the 5.2 release, module registration and detailed module status (including a full list of ip-prefix/ports/protocol) can be accessed via a REST API or from the CLI. Please refer to the API documentation available from the GUI, and the
show application modules status and
show application modules registration for full details.
Each module produces a list of service names that are used to reference it in the configuration through the
application-name list. For example, an application identification module named
zoom will retrieve and process all of the IP addresses used for the
ZOOM videoconferencing service. The corresponding service looks like this:
application-name is configured as it is with the
tls variant of
application-identification. In this case, however, it will read the contents of a JSON file to produce the FIB entries. Below is an excerpt from the
zoom module's output:
In the case of this module, the script that generates the JSON is
/etc/128technology/application-modules/zoom.py, the output is stored as
/var/run/128technology/application-modules/zoom.json. A copy of the
zoom.py script is available on our user community, Interchange.
services tag of
ZOOM is what associates these IP prefixes to the service we've shown above. Each of these IP prefixes (which could have also included port ranges, but don't in this example) will create a FIB entry for the
ZOOM service, and be given access and policy determinations based on the configuration we've set in our 128T.
The 128T product ships with an Office365 module, and other modules can be found on Interchange, our user community, as well as on Github. For more information on writing your own application identification module, refer to our developer documentation or our sample code.