Traffic Router Administration¶
- CentOS 7
- 4 CPUs
- 8GB of RAM
- Successful install of Traffic Ops (usually on another machine)
- Successful install of Traffic Monitor (usually on another machine)
- Administrative access to Traffic Ops
Hardware requirements are generally doubled if DNSSEC is enabled
Installing Traffic Router¶
Traffic Ops will only recognize a profile as assignable to a Traffic Router if its name starts with the prefix
ccr-. The reason for this is a legacy limitation related to the old name for Traffic Router (Comcast Cloud Router), and will (hopefully) be rectified in the future as the old Perl parts of Traffic Ops are re-written in Go.
Ensure the FQDN of the Traffic Router is resolvable in DNS. This FQDN must be resolvable by the clients expected to use this CDN.
Install a Traffic Router server package, either from source or using a
traffic_router-version string.rpmpackage generated using the instructions in Building Traffic Control.
Changed in version 3.0: As of version 3.0, Traffic Router depends upon a package called
tomcat. This package should have been created when Traffic Router was built. If installing the
traffic_routerproduces a depenedency error, make sure that the
tomcatpackage is available in an accessible yum(8) repository.
/opt/traffic_router/conf/traffic_monitor.propertiesand specify the correct online Traffic Monitor(s) for your CDN.
URL that should normally point to this file, e.g.
Period to wait (in milliseconds) between reloading this file, e.g.
Start Traffic Router. This is normally done by starting its systemd(1) service.
systemctl start traffic_router, and test DNS lookups against that server to be sure it’s resolving properly. with e.g.
curl. Also, because previously taken CDN Snapshots will be cached, they need to be removed manually to actually be reloaded. This file should be located at
/opt/traffic_router/db/cr-config.json. This should be done before starting or restarting Traffic Router.
[root@trafficrouter /]# systemctl start traffic_router [root@trafficrouter /]# dig @localhost mycdn.ciab.test ; <<>> DiG 9.9.4-RedHat-9.9.4-72.el7 <<>> @localhost mycdn.ciab.test ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27109 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;mycdn.ciab.test. IN A ;; AUTHORITY SECTION: mycdn.ciab.test. 30 IN SOA trafficrouter.infra.ciab.test. twelve_monkeys.mycdn.ciab.test. 2019010918 28800 7200 604800 30 ;; Query time: 28 msec ;; SERVER: ::1#53(::1) ;; WHEN: Wed Jan 09 21:27:57 UTC 2019 ;; MSG SIZE rcvd: 104
Perform a CDN Snapshot.
Ensure that the parent domain (e.g.:
cdn.local) for the CDN’s top level domain (e.g.:
ciab.cdn.local) contains a delegation (Name Server records) for the new Traffic Router, and that the value specified matches the FQDN of the Traffic Router.
Configuring Traffic Router¶
Changed in version 1.5: Many of the configuration files under
/opt/traffic_router/conf are now only needed to override the default configuration values for Traffic Router. Most of the given default values will work well for any CDN. Critical values that must be changed are hostnames and credentials for communicating with other Traffic Control components such as Traffic Ops and Traffic Monitor. Pre-existing installations that store configuration files under
/opt/traffic_router/conf will still be used and honored for Traffic Router 1.5 onward.
Changed in version 3.0: Traffic Router 3.0 has been converted to a formal Tomcat instance, meaning that is now installed separately from the Tomcat servlet engine. The Traffic Router installation package contains all of the Traffic Router-specific software, configuration and startup scripts including some additional configuration files needed for Tomcat. These new configuration files can all be found in the
/opt/traffic_router/conf directory and generally serve to override Tomcat’s default settings.
For the most part, the configuration files and Parameters used by Traffic Router are used to bring it online and start communicating with various Traffic Control components. Once Traffic Router is successfully communicating with Traffic Control, configuration should mostly be performed in Traffic Portal, and will be distributed throughout Traffic Control via CDN Snapshot process. See Snapshot CRConfig for more information. Please see the Parameter documentation for Traffic Router in the Using Traffic Ops guide documented under Traffic Router Profile for Parameters that influence the behavior of Traffic Router via the Snapshot.
|ConfigFile||Parameter Name||Description||Default Value|
|traffic_monitor.properties||traffic_monitor.bootstrap.hosts||Semicolon-delimited Traffic Monitor FQDNs with port numbers as necessary||N/A|
|traffic_monitor.bootstrap.local||Use only the Traffic Monitors specified in local configuration files||
|traffic_monitor.properties||Path to file:traffic_monitor.properties; used internally to monitor the file for changes||
|traffic_monitor.properties.reload.period||The interval in milliseconds for Traffic Router to wait between reloading this configuration file||
|dns.properties||dns.tcp.port||TCP port that Traffic Router will use for incoming DNS requests||
|dns.tcp.backlog||Maximum length of the queue for incoming TCP connection requests||
|dns.udp.port||UDP port that Traffic Router will use for incoming DNS requests||
|dns.max-threads||Maximum number of threads used to process incoming DNS requests||
|dns.zones.dir||Path to automatically generated zone files for reference||
|traffic_ops.properties||traffic_ops.username||Username with which to access the Traffic Ops API
(must have the
|traffic_ops.password||Password for the user specified in
|cache.properties||cache.geolocation.database||Full path to the local copy of a geographic IP mapping database (usually MaxMind’s GeoIP2)||
|cache.geolocation.database.refresh.period||The interval in milliseconds for Traffic Router to wait between polling for changes to the GeoIP2 database||
|cache.czmap.database||Full path to the local copy of the coverage zone file||
|cache.czmap.database.refresh.period||The interval in milliseconds for Traffic Router to wait between polling for a new coverage zone file||
|cache.dczmap.database||Full path to the local copy of the deep coverage zone file||
|cache.dczmap.database.refresh.period||The interval in milliseconds for Traffic Router to wait between polling for a new deep coverage zone file||
|cache.health.json||Full path to the local copy of the health state||
|cache.health.json.refresh.period||The interval in milliseconds which Traffic Router will poll for a new health state file||
|cache.config.json||Full path to the locally cached copy of the CDN Snapshot||
|cache.config.json.refresh.period||The interval in milliseconds which Traffic Router will poll for a new Snapshot||
|startup.properties||various parameters||This configuration is used by systemd(1) to set environment variables
|log4j.properties||various parameters||Configuration of
|server.xml||various parameters||Traffic Router specific configuration for Apache Tomcat. See the Apache Tomcat documentation||N/A|
|web.xml||various parameters||Default settings for all Web Applications running in the Traffic Router instance of Tomcat||N/A|
DNSSEC is a set of extensions to DNS that provides a cryptographic mechanism for resolvers to verify the authenticity of responses served by an authoritative DNS server. Several RFCs (RFC 4033, RFC 4044, RFC 4045) describe the low level details and define the extensions, RFC 7129 provides clarification around authenticated denial of existence of records, and finally RFC 6781 describes operational best practices for administering an authoritative DNSSEC-enabled DNS server. The authenticated denial of existence RFC 7129 describes how an authoritative DNS server responds in NXDOMAIN and NODATA scenarios when DNSSEC is enabled. Traffic Router currently supports DNSSEC with NSEC, however, NSEC3 and more configurable options are planned for the future.
Upon startup or a configuration change, Traffic Router obtains keys from the ‘keystore’ API in Traffic Ops which returns KSKs and ZSKs for each Delivery Service that is a sub-domain of the CDN’s TLD in addition to the keys for the CDN TLD itself. Each key has timing information that allows Traffic Router to determine key validity (expiration, inception, and effective dates) in addition to the appropriate TTL to use for the DNSKEY record(s). All TTLs are configurable Parameters; see the Traffic Router Profile documentation for more information.
Once Traffic Router obtains the key data from the API, it converts each public key into the appropriate record types (DNSKEY, DS) to place in zones and uses the private key to sign zones. DNSKEY records are added to each Delivery Service’s zone (e.g.:
demo1.mycdn.ciab.test) for every valid key that exists, in addition to the CDN TLD’s zone. A DS record is generated from each zone’s KSK and is placed in the CDN TLD’s zone (e.g.:
mycdn.ciab.test); the DS record for the CDN TLD must be placed in its parent zone, which is not managed by Traffic Control.
The DNSKEY to DS record relationship allows resolvers to validate signatures across zone delegation points. With Traffic Control, we control all delegation points below the CDN’s TLD, however, the DS record for the CDN TLD must be placed in the parent zone (e.g.:
ciab.test), which is not managed by Traffic Control. As such, the DS record must be placed in the parent zone prior to enabling DNSSEC, and prior to generating a new CDN KSK. Based on your deployment’s DNS configuration, this might be a manual process or it might be automated. Either way, extreme care and diligence must be taken and knowledge of the management of the upstream zone is imperative for a successful DNSSEC deployment.
To enable DNSSEC for a CDN in Traffic Portal, Go to CDNs from the sidebar and click on the desired CDN, then toggle the ‘DNSSEC Enabled’ field to ‘true’, and click on the green Update button to save the changes.
Rolling Zone Signing Keys¶
Traffic Router currently follows the ZSK pre-publishing operational best practice described in RFC 6781#section-22.214.171.124. Once DNSSEC is enabled for a CDN in Traffic Portal, key rolls are triggered by Traffic Ops via the automated key generation process, and Traffic Router selects the active ZSKs based on the expiration information returned from the ‘keystore’ API of Traffic Ops.
Troubleshooting and Log Files¶
Traffic Router log files can be found under
/opt/tomcat/logs. Initialization and shutdown logs are in
/opt/tomcat/logs/catalinadate.out. Application related logging is in
/opt/traffic_router/var/log/traffic_router.log, while access logs are written to
Event Log File Format¶
All access events to Traffic Router are logged to the file
/opt/traffic_router/var/log/access.log. This file grows up to 200MB and gets rolled into older log files, ten log files total are kept (total of up to 2GB of logged events per Traffic Router instance)
Traffic Router logs access events in a format that largely follows ATS event logging format.
- Except for the first item, each event that is logged is a series of space-separated key/value pairs.
- The first item is always the Unix epoch in seconds with a decimal field precision of up to milliseconds.
- Each key/value pair is in the form of
unquoted_string="optionally quoted string"
- Values that are quoted strings may contain whitespace characters.
- Values that are not quoted should not contains any whitespace characters.
Any value that is a single dash character or a dash character enclosed in quotes represents an empty value
|qtype||Whether the request was for DNS or HTTP||Always “DNS” or “HTTP”|
|chi||The IP address of the requester||Depends on whether this was a DNS or HTTP request, see other sections|
|rhi||The IP address of the request source address||Depends on whether this was a DNS or HTTP request, see other sections|
|ttms||The amount of time in milliseconds it took Traffic Router to process the request||A number greater than or equal to zero|
|rtype||Routing result type||One of ERROR, CZ, DEEP_CZ, GEO, MISS, STATIC_ROUTE, DS_REDIRECT, DS_MISS, INIT, FED|
|rloc||GeoLocation of result||Latitude and longitude in degrees as floating point numbers|
|rdtl||Result details Associated with unusual conditions||One of DS_NOT_FOUND, DS_NO_BYPASS, DS_BYPASS, DS_CZ_ONLY, DS_CZ_BACKUP_CG|
|rerr||Message about an internal Traffic Router error||String|
Items within brackets are detailed under the HTTP and DNS sections
144140678.000 qtype=DNS chi=192.168.10.11 rhi=- ttms=789 [Fields Specific to the DNS request] rtype=CZ rloc="40.252611,58.439389" rdtl=- rerr="-" [Fields Specific to the DNS result] 144140678.000 qtype=HTTP chi=192.168.10.11 rhi=- ttms=789 [Fields Specific to the HTTP request] rtype=GEO rloc="40.252611,58.439389" rdtl=- rerr="-" [Fields Specific to the HTTP result]
These samples contain fields that are always present for every single access event to Traffic Router
- The request was not redirected. This is usually a result of a DNS request to the Traffic Router or an explicit denial for that request
- The client’s IP matched an Anonymous Blocking rule and was blocked
- The result was derived from Coverage Zone data based on the address in the
- The result was derived from Deep Coverage Zone data based on the address in the
- _*HTTP Only*_ No HTTP Delivery Servicesupports either this request’s URL path or headers
- The result is using the Bypass Destination configured for the matched Delivery Service when that Delivery Service is unavailable or does not have the requested resource
- An internal error occurred within Traffic Router, more details may be found in the
- _*DNS Only*_ The result was obtained through federated coverage zone data outside of any Delivery Services
- The result was derived from geolocation service based on the address in the
- The request was redirected based on the National Geo blocking (Geo Limit Redirect URL) configured on the Delivery Service
- Traffic Router was unable to resolve a DNS request or find a cache for the requested resource
- The request was redirected to the Regional Geo-Blocking URL. Regional Geo blocking is enabled on the Delivery Service and is configured through the
regional_geoblock.polling.urlParameter on the Traffic Router Profile
- _*DNS Only*_ The result was obtained through federated coverage zone data outside of any Delivery Service - the request was regionally blocked because there was no rule for the request made
- _*DNS Only*_ No DNS Delivery Servicesupports the hostname portion of the requested URL
- The request was not redirected. This is usually a result of a DNS request to the Traffic Router or an explicit denial for that request
- Used a bypass destination for redirection of the Delivery Service
- Traffic Router did not find a resource supported by coverage zone data and was unable to determine the geographic location of the requesting client
- Traffic Router found a backup cache via fall-back (CRconfig’s
edgeLocation) or via coordinates (CZF) configuration
- The selected Delivery Service only supports resource lookup based on coverage zone data
- No valid bypass destination is configured for the matched Delivery Service and the Delivery Service does not have the requested resource
- Always goes with
rtypesSTATIC_ROUTE and DS_MISS
- Traffic Router could not find a resource via geographic location data based on the requesting client’s location
- This entry is for a standard request
- This goes with the
rtypeRGDENY. The URL is being regionally blocked
- The request was blocked because there was no rule in the Delivery Service for the request
1452197640.936 qtype=HTTP chi=126.96.36.199 rhi=- url="http://foo.mm-test.jenkins.cdnlab.comcast.net/some/asset.m3u8" cqhm=GET cqhv=HTTP/1.1 rtype=GEO rloc="40.252611,58.439389" rdtl=- rerr="-" pssc=302 ttms=0 rurl="http://odol-atsec-sim-114.mm-test.jenkins.cdnlab.comcast.net:8090/some/asset.m3u8" rh="Accept: */*" rh="myheader: asdasdasdasfasg"
|url||Requested URL with query string||A URL String|
|cqhv||Http Protocol Version||e.g.
|rh||One or more of these key value pairs may exist in a logged event and are controlled by the configuration of the matched Delivery Service | Key/value pair of the format
|rurl||The resulting URL of the resource requested by the client|
144140678.000 qtype=DNS chi=192.168.10.11 rhi=- ttms=123 xn=65535 fqdn=www.example.com. type=A class=IN ttl=12345 rcode=NOERROR rtype=CZ rloc="40.252611,58.439389" rdtl=- rerr="-" ans="192.168.1.2 192.168.3.4 0:0:0:0:0:ffff:c0a8:102 0:0:0:0:0:ffff:c0a8:304"
|xn||The ID from the client DNS request header||a whole number between 0 and 65535 (inclusive)|
|rhi||The IP address of the resolver when ENDS0 client subnet extensions are enabled.||An IPv4 or IPv6 string, or dash if request is for resolver only and no client subnet is present|
|fqdn||The qname field from the client DNS request message (i.e. the FQDN the client is requesting be||A series of DNS labels/domains separated by ‘.’ characters and ending with a ‘.’ character|
|type||The qtype field from the client DNS request message (i.e. the typeof resolution that’s requested such as IPv4, IPv6)||Examples are A (IpV4), AAAA (IpV6), NS, SOA, and CNAME, (see qtype)|
|class||The qclass field from the client DNS request message (i.e. the class of resource being requested)||Either IN or ANY (Traffic Router rejects requests with any other value of class)|
|ttl||The ‘time to live’ in seconds for the answer provided by Traffic Router (clients can reliably use this answer for this long without re-querying traffic router)||A whole number between 0 and 4294967295 (inclusive)|
|rcode||The result code for the DNS answer provided by Traffic Router||One of NOERROR (success), NOTIMP (request is not NOTIMP (request is not supported), REFUSED (request is refused to be answered), or NXDOMAIN (the domain/name requested does not exist)|
GeoLimit Failure Redirect Feature¶
This feature is also called NGB.
In the past, if the Geolimit check fails (for example, the client IP is not in the
US Region but the Geolimit is set to ‘CZF + US’), Traffic Router will respond with
503 Service Unavailable, but with this feature, when the check fails, it will respond with
302 Found if the redirect URL is set in the Delivery Service.
- The Geolimit check will fail in the following scenarios:
- When the GeoLimit is set to ‘CZF + only’ and the client IP is not in the the CZ file
- When the GeoLimit is set to any region e.g. ‘CZF + US’ and the client IP is not in such region, and the client IP is not in the CZ file
To enable the NGB feature, the Delivery Service must be configured with the proper redirect URL. The setting for this can be found by clicking on Advanced Options at the bottom of a Delivery Service details page, and is specified by the ‘Geo Limit Redirect URL’ field. An individual Delivery Service details page can be viewed by clicking on the desired Delivery Service under . If no URL is put in this field, the feature is disabled.
The URL has 3 kinds of formats, which have different meanings:
- URL with no domain
- If no domain is in the URL (e.g.
vod/dance.mp4), Traffic Router will try to find a proper cache server within the Delivery Service and return the redirect URL in the format:
http://[cache server name]. :term:`Delivery Service`'s Fully Qualified Domain]/[configured relative path]
- URL with domain that matches with the Delivery Service
- For this URL, Traffic Router will also try to find a proper cache server within the Delivery Service and return a redirect URL in the format:
http://[cache server name]. :term:`Delivery Service`'s Fully Qualified Domain Name]/[configured relative path]
- URL with domain that doesn’t match with the Delivery Service
- Traffic Router will return the configured URL directly to the client.
Deep Caching - Deep Coverage Zone Topology¶
Deep Caching is a feature that enables clients to be routed to the closest possible “deep” Edge-tier cache server s on a per-Delivery Service basis. The term “deep” is used in the networking sense, meaning that the Edge-tier cache server s are located deep in the network where the number of network hops to a client is as minimal. This deep caching topology is desirable because storing content closer to the client gives better bandwidth savings, and sometimes the cost of bandwidth usage in the network outweighs the cost of adding storage. While it may not be feasible to cache an entire copy of the CDN’s contents in every deep location (for the best possible bandwidth savings), storing just a relatively small amount of the CDN’s most requested content can lead to very high bandwidth savings.
What You Need¶
Edge cache deployed in “deep” locations and registered in Traffic Ops
A DCZF mapping these deep cache hostnames to specific network prefixes (see The Deep Coverage Zone File for details)
Deep caching parameters in the Traffic Router Profile (see Traffic Router Profile for details):
How it Works¶
Deep Coverage Zone routing is very similar to that of regular Coverage Zone routing, except that the DCZF is preferred over the regular CZF for Delivery Services with Deep Caching enabled. If the client requests a Deep Caching-enabled Delivery Service and their IP address gets a “hit” in the DCZF, Traffic Router will attempt to route that client to one of the available “deep” cache server s in the client’s corresponding zone. If there are no “deep” cache server s available for a client’s request, Traffic Router will fall back to the regular CZF and continue regular CZF routing from there.
A Steering Delivery Service is a Delivery Service that is used to route a client to another Delivery Service. The Type of a Steering Delivery Service is either STEERING or CLIENT_STEERING. A Steering Delivery Service will have target Delivery Services configured for it with weights assigned to them. Traffic Router uses the weights to make a consistent hash ring which it then uses to make sure that requests are routed to a target based on the configured weights. This consistent hash ring is separate from the consistent hash ring used in cache selection.
Special regular expressions - referred to as ‘filters’ - can also be configured for target Delivery Services to pin traffic to a specific Delivery Service. For example, if the filter
.*/news/.* for a target called
target-ds-1 is created, any requests to Traffic Router with “news” in them will be routed to
target-ds-1. This will happen regardless of the configured weights.
Some other points of interest¶
- Steering is currently only available for HTTP Delivery Services that are a part of the same CDN.
- A new role called STEERING has been added to the Traffic Ops database. Only users with the Steering Role or higher can modify steering assignments for a Delivery Service.
- A new API has been created in Traffic Ops under
/internal. A Steering user can either directly access this API to modify assignments, or use the Traffic Portal UI ( on a Steering Delivery Service’s details page), however a filter can only be created via the API.
- Traffic Router uses the steering API in Traffic Ops to poll for steering assignments, the assignments are then used when routing traffic.
A couple simple use-cases for Steering are:
The Difference Between STEERING and CLIENT_STEERING¶
The only difference between the STEERING and CLIENT_STEERING Delivery Service Types is that CLIENT_STEERING explicitly allows a client to bypass Steering by choosing a destination Delivery Service. A client can accomplish this by providing the
X-TC-Steering-Option HTTP header with a value of the
xml_id of the target Delivery Service to which they desire to be routed. When Traffic Router receives this header it will route to the requested target Delivery Service regardless of weight configuration. This header is ignored by STEERING Delivery Services.
The following needs to be completed for Steering to work correctly:
- Two target Delivery Services are created in Traffic Ops. They must both be HTTP Delivery Services part of the same CDN.
- A Delivery Service with type STEERING or CLIENT_STEERING is created in Traffic Portal.
- Target Delivery Services are assigned to the Steering Delivery Service using Traffic Portal.
- A user with the role of Steering is created.
- The Steering user assigns weights to the target Delivery Services.
- If desired, the Steering user can create filters for the target Delivery Services.
For more information see the Steering how-to guide.
HTTPS for HTTP Delivery Services¶
New in version 1.7: Traffic Router now has the ability to allow HTTPS traffic between itself and clients on a per-HTTP Delivery Service basis.
As of version 3.0 Traffic Router has been integrated with native OpenSSL. This makes establishing HTTPS connections to Traffic Router much less expensive than previous versions. However establishing an HTTPS connection is more computationally demanding than an HTTP connection. Since each client will in turn get redirected to an ATS instance, Traffic Router is most always creating a new HTTPS connection for all HTTPS traffic. It is likely to mean that an existing Traffic Router may have some decrease in performance if you wish to support a lot of HTTPS traffic. As noted for DNSSEC, you may need to plan to scale Traffic Router vertically and/or horizontally to handle the new load.
The HTTPS set up process is:
- Select one of ‘1 - HTTPS’, ‘2 - HTTP AND HTTPS’, or ‘3 - HTTP TO HTTPS’ for the Delivery Service
- Generate private keys for the Delivery Service using a wildcard domain such as
- Obtain and import signed certificate chain
- Perform a CDN Snapshot
- Any secure client will get an SSL handshake error. Non-secure clients will experience the same behavior as prior to 1.7
- Traffic Router will only redirect (send a
302 Foundresponse) to clients communicating with a secure connection, all other clients will receive a
503 Service Unavailableresponse
- HTTP AND HTTPS
- Traffic Router will redirect both secure and non-secure clients
- HTTP TO HTTPS
- Traffic Router will redirect non-secure clients with a
302 Foundresponse and a location that is secure (i.e. an
https://URL instead of an
http://URL), while secure clients will be redirected immediately to an appropriate target or cache server.
If you have HTTPS Delivery Services in your CDN, Traffic Router will not accept any connections until it is able to fetch certificates from Traffic Ops and load them into memory. Traffic Router does not persist certificates to the Java Keystore or anywhere else.
Traffic Router fetches certificates into memory:
- At startup time
- When it receives a new CDN Snapshot
- Once an hour starting whenever the most recent of the last of the above occurred
To adjust the frequency at which Traffic Router fetches certificates add the Parameter
certificates.polling.interval with the ConfigFile “CRConfig.json” and set it to the desired duration in milliseconds.
Taking a CDN Snapshot may be used at times to avoid waiting the entire polling cycle for a new set of certificates.
Certificate Chain Ordering¶
The ordering of certificates within the certificate bundle matters. It must be:
- Primary Certificate (e.g. the one created for
- Intermediate Certificate(s)
- Root Certificate from a CA (optional)
If something is wrong with the certificate chain (e.g. the order of the certificates is backwards or for the wrong domain) the client will get an SSL handshake. Inspection of
/opt/tomcat/logs/catalina.log is likely to yield information to reveal this.
To see the ordering of certificates you may have to manually split up your certificate chain and use openssl(1ssl) on each individual certificate
Suggested Way of Setting up an HTTPS Delivery Service¶
Assuming you have already created a Delivery Service which you plan to modify to use HTTPS, do the following in Traffic Portal:
- Select one of ‘1 - HTTPS’, ‘2 - HTTP AND HTTPS’, or ‘3 - HTTP TO HTTPS’ for the protocol field of a Delivery Service and click the Update button
- Go to
- Click on
- Fill out the form and click on the green Generate Keys button, then confirm that you want to make these changes
- Copy the contents of the Certificate Signing Request field and save it locally
- Go back and select ‘HTTP’ for the protocol field of the Delivery Service and click Save (to avoid preventing other CDN Snapshot updates from being blocked by Traffic Router)
- Follow your standard procedure for obtaining your signed certificate chain from a CA
- After receiving your certificate chain import it into Traffic Ops
- Edit the Delivery Service
- Restore your original choice for the protocol field and click Save
- Paste your key information into the appropriate fields
- Click the green Update Keys button
- Take a new CDN Snapshot
Router Load Testing¶
The Traffic Router load testing tool is located in the Traffic Control repository under test/router. It can be used to simulate a mix of HTTP and HTTPS traffic for a CDN by choosing the number of HTTP Delivery Services and the number HTTPS Delivery Service the test will exercise.
There are 2 parts to the load test:
- A web server that makes the actual requests and takes commands to fetch data from the CDN, start the test, and return current results.
- A web page that’s used to run the test and see the results.
Running the Load Tests¶
- First, clone the Traffic Control repository.
- You will need to make sure you have a CA file on your machine
- The web server is a Go program, set your
GOPATHenvironment variable appropriately (we suggest
- Open a terminal emulator and navigate to the
test/router/serverdirectory inside of the cloned repository
- Execute the server binary by running
go run server.go
- Using your web browser of choice, open the file
- Authenticate against a Traffic Ops host - this should be a nearly instantaneous operation - you can watch the output from
- Enter the Traffic Ops host in the second form and click the button to get a list of CDN’s
- Wait for the web page to show a list of CDN’s under the above form, this may take several seconds
- The List of CDN’s will display the number of HTTP- and HTTPS-capable Delivery Services that may be exercised
- Choose the CDN you want to exercise from the drop-down menu
- Fill out the rest of the form, enter appropriate numbers for each HTTP and HTTPS Delivery Services
- Click Run Test
- As the test runs the web page will occasionally report results including running time, latency, and throughput
The following is an example of the command line parameters set in
/opt/traffic_router/conf/startup.properties that has been tested on a multi-core server running under HTTPS load test requests. This is following the general recommendation to use the G1 garbage collector for JVM applications running on multi-core machines. In addition to using the G1 garbage collector the
InitiatingHeapOccupancyPercent was lowered to run garbage collection more frequently which improved overall throughput for Traffic Router and reduced ‘Stop the World’ garbage collection. Note that any environment variable settings in this file will override those set in
CATALINA_OPTS="\ -server -Xms2g -Xmx8g \ -Dlog4j.configuration=file://$CATALINA_BASE/conf/log4j.properties \ -Djava.library.path=/usr/lib64 \ -XX:+UseG1GC \ -XX:+UnlockExperimentalVMOptions \ -XX:InitiatingHeapOccupancyPercent=30"
Pattern-Based Consistent Hashing Feature¶
New in version 3.1: Traffic Router now has the ability to influence consisting hashing using a regular expression on a per-HTTP Delivery Service basis.
Pattern-Based Consistent Hashing is a feature to modify the request path given to Traffic Router’s consistent hasher for Cache selection (and Delivery Service selection for Steering Delivery Services) using a regular expression. This new regular expression field ‘Consistent Hash Regex’ is applied on a per-Delivery Service basis and is given to Traffic Router via the CDN Snapshot. The purpose of this feature is to increase cache efficiency by directing requests for the same asset, but with varying request paths, to the same Cache.
Pattern-Based Consistent Hashing is only available for HTTP and Steering Delivery Services
How it Works¶
With Pattern-Based Consistent Hashing, a regular expression (Consistent Hash Regex) is applied to the request path to extract matching elements to build a new string to pass to the consistent hasher. i.e.: using the Consistent Hash Regex
/.*?(/.*?/).*?(m3u8) given the request paths
/other/path/asset.m3u8 the resulting path to hash will be
See Oracle’s documentation for the java.util.regex.Pattern implementation in Java.
- When routing requests for an HTTP Delivery Service, Traffic Router compiles a list of eligible caches and uses consistent hashing on the request path to select one. With Pattern-Based Consistent Hashing, the request path is rebuilt prior to consistent hashing for Cache Selection.
- For a Steering Delivery Service, Traffic Router uses consistent hashing on the request path to select a Target Delivery Service. In the case of Pattern-Based Consistent Hashing, the request path is rebuilt using the Consistent Hash Regex assigned to the Steering Delivery Service prior to consistent hashing. Then, the Target Delivery Service inherits the Consistent Hash Regex from the Steering Delivery Service and uses it for Cache selection.
Testing Pattern-Based Consistent Hashing¶
In order to test this feature without affecting the delivery of traffic through a CDN, there are several test tools in place.
- Traffic Router API
- Several Traffic Router endpoints have been added to test regular expression application against a request path, Cache selection, and Delivery Service selection using Pattern-Based Consistent Hashing. For more information see the Traffic Router API documentation.
- Traffic Ops API
- A Traffic Ops endpoint has been added that will proxy request data through to one of the Traffic Router endpoints in order to test regular expression application against a request path. For more information see the Traffic Ops API documentation.
- Traffic Portal Test Tool
- On the Delivery Service (HTTP and Steering) form in Traffic Portal, a “Test Regex” link has been added so that the user can validate a regular expression before saving it to a Delivery Service.