Traffic Ops - Using

Deprecated since version 3.0: The Traffic Ops UI is deprecated, and will be removed entirely in the next major release (4.0). A much better way to interact with the CDN is to use Traffic Portal, which is the the only UI that will be receiving updates for the foreseeable future.

The Traffic Ops Menu

The Traffic Ops Landing Page

Fig. 2 The Traffic Ops Landing Page

The following tabs are available in the menu at the top of the Traffic Ops user interface.

ChangeLog

The Changelog table displays the changes that are being made to the Traffic Ops database through the Traffic Ops user interface. This tab will show the number of changes since you last visited this tab in (brackets) since the last time you visited this tab. There are currently no sub menus for this tab.

Help

Help for Traffic Ops and Traffic Control. Hover over this tab to get the following options:

Option Description
About Traffic Ops information, such as version, database information, etc
Release Notes Release notes for the most recent releases of Traffic Ops
Logout Logout from Traffic Ops

Invalidate Content

Invalidating content on the CDN is sometimes necessary when the origin was mis-configured and something is cached in the CDN that needs to be removed. Given the size of a typical Traffic Control CDN and the amount of content that can be cached in it, removing the content from all the caches may take a long time. To speed up content invalidation, Traffic Ops will not try to remove the content from the caches, but it makes the content inaccessible using the regex_revalidate ATS plugin. This forces a revalidation of the content, rather than a new get.

Note

This method forces a HTTP revalidation of the content, and not a new GET - the origin needs to support revalidation according to the HTTP/1.1 specification, and send a 200 OK or 304 Not Modified as applicable.

To invalidate content:

  1. Click Tools > Invalidate Content

  2. Fill out the form fields:

    • Select the :term:`Delivery Service`*
    • Enter the Path Regex - this should be a PCRE compatible regular expression for the path to match for forcing the revalidation. Be careful to only match on the content you need to remove - revalidation is an expensive operation for many origins, and a simple /.* can cause an overload condition of the origin.
    • Enter the Time To Live - this is how long the revalidation rule will be active for. It usually makes sense to make this the same as the Cache-Control header from the origin which sets the object time to live in cache (by max-age or Expires). Entering a longer TTL here will make the caches do unnecessary work.
    • Enter the Start Time - this is the start time when the revalidation rule will be made active. It is pre-populated with the current time, leave as is to schedule ASAP.
  3. Click the Submit button.

Manage DNSSEC Keys

In order to support DNSSEC in Traffic Router, Traffic Ops provides some actions for managing DNSSEC keys for a CDN and associated Delivery Services. DNSSEC Keys consist of a Key Signing Keys (KSK) which are used to sign other DNSKEY records as well as Zone Signing Keys (ZSK) which are used to sign other records. DNSSEC Keys are stored in Traffic Vault and should only be accessible to Traffic Ops. Other applications needing access to this data, such as Traffic Router, must use the Traffic Ops DNSSEC APIs to retrieve this information.

To Manage DNSSEC Keys: 1. Click Tools -> Manage DNSSEC Keys 2. Choose a CDN and click Manage DNSSEC Keys

  • If keys have not yet been generated for a CDN, this screen will be mostly blank with just the CDN and DNSSEC Active? fields being populated.
  • If keys have been generated for the CDN, the Manage DNSSEC Keys screen will show the TTL and Top Level Domain (TLD) KSK Expiration for the CDN as well as DS Record information which will need to be added to the parent zone of the TLD in order for DNSSEC to work.

The Manage DNSSEC Keys screen also allows a user to perform the following actions:

Activate/Deactivate DNSSEC for a CDN

Fairly straight forward, this button set the Parameter with the Name “dnssec.enabled” to have a Value of either “true” or “false” on the Traffic Router Profile for the CDN. The Activate/Deactivate option is only available if DNSSEC keys exist for CDN. In order to active DNSSEC for a CDN a user must first generate keys and then click the Active DNSSEC button.

Generate Keys

Generate Keys will generate DNSSEC keys for the CDN TLD as well as for each Delivery Service in the CDN. It is important to note that this button will create a new KSK for the TLD and, therefore, a new DS Record. Any time a new DS Record is created, it will need to be added to the parent zone of the TLD in order for DNSSEC to work properly. When a user clicks the Generate Keys button, they will be presented with a screen with the following fields:

  • CDN: This is not editable and displays the CDN for which keys will be generated
  • ZSK Expiration (Days): Sets how long (in days) the Zone Signing Key will be valid for the CDN and associated Delivery Services. The default is 30 days.
  • KSK Expiration (Days): Sets how long (in days) the Key Signing Key will be valid for the CDN and associated Delivery Services. The default is 365 days.
  • Effective Date (GMT): The time from which the new keys will be active. Traffic Router will use this value to determine when to start signing with the new keys and stop signing with the old keys.

Once these fields have been correctly entered, a user can click Generate Keys. The user will be presented with a confirmation screen to help them understand the impact of generating the keys. If a user confirms, the keys will be generated and stored in Traffic Vault.

Regenerate KSK

Regenerate KSK will create a new Key Signing Key for the CDN TLD. A new DS Record will also be generated and need to be put into the parent zone in order for DNSSEC to work correctly. The Regenerate KSK button is only available if keys have already been generated for a CDN. The intent of the button is to provide a mechanism for generating a new KSK when a previous one expires or if necessary for other reasons such as a security breach. When a user goes to generate a new KSK they are presented with a screen with the following options:

CDN:This is not editable and displays the CDN for which keys will be generated
KSK Expiration (Days):
 Sets how long (in days) the Key Signing Key will be valid for the CDN and associated Delivery Services. The default is 365 days.
Effective Date (GMT):
 The time from which the new KSK and DS Record will be active. Since generating a new KSK will generate a new DS Record that needs to be added to the parent zone, it is very important to make sure that an effective date is chosen that allows for time to get the DS Record into the parent zone. Failure to get the new DS Record into the parent zone in time could result in DNSSEC errors when Traffic Router tries to sign responses.

Once these fields have been correctly entered, a user can click Generate KSK. The user will be presented with a confirmation screen to help them understand the impact of generating the KSK. If a user confirms, the KSK will be generated and stored in Traffic Vault.

Additionally, Traffic Ops also performs some systematic management of DNSSEC keys. This management is necessary to help keep keys in sync for Delivery Services in a CDN as well as to make sure keys do not expire without human intervention.

Generation of keys for new Delivery Services

If a new Delivery Service is created and added to a CDN that has DNSSEC enabled, Traffic Ops will create DNSSEC keys for the Delivery Service and store them in Traffic Vault.

Regeneration of expiring keys for a Delivery Service

Traffic Ops has a process, controlled by cron(8), to check for expired or expiring keys and re-generate them. The process runs at 5 minute intervals to check and see if keys are expired or close to expiring (withing 10 minutes by default). If keys are expired for a Delivery Service, Traffic Ops will regenerate new keys and store them in Traffic Vault. This process is the same for the CDN TLD ZSK, however Traffic Ops will not re-generate the CDN TLD KSK systematically. The reason is that when a KSK is regenerated for the CDN TLD then a new DS Record will also be created. The new DS Record needs to be added to the parent zone before Traffic Router attempts to sign with the new KSK in order for DNSSEC to work correctly. Therefore, management of the KSK needs to be a manual process.