This appendix describes the Traffic Server configuration files that you can edit. For a list of all the configuration files used by Traffic Server, including files that you must not edit, refer to the Traffic Server Installation Guide.
The bypass.config
file contains static bypass rules that Traffic Server uses in transparent proxy caching mode. Static bypass rules instruct Traffic Server to bypass certain incoming client requests so they are served by the origin server. The bypass.config
file also accepts Dynamic Deny Bypass Rules.
You can configure three types of static bypass rules:
IMPORTANT: After you modify the bypass.config
file, you must restart Traffic Server.
Bypass rules follow the format below:
bypass src ipaddress | dst ipaddress | src ipaddress AND dst ipaddress
The following table describes the variables.
Option |
Description |
---|---|
|
Specifies the source (client) IP address in incoming requests Traffic Server must bypass. The variable 123.45.67.8 - In CIDR (Classless Inter-Domain Routing) format, such as 1.1.1.0/24 - A range separated by a dash, such as 1.1.1.1-2.2.2.2 - Any combination of the above separated by commas, such as 1.1.1.0/24, 25.25.25.25, 123.1.23.1-123.1.23.123 |
|
Specifies the destination (origin server) IP address in incoming requests Traffic Server must bypass. The variable - A simple IP address, such as |
|
Specifies the source and destination IP address pair Traffic Server must bypass. The variable |
In addition to static bypass rules, the bypass.config
file also accepts dynamic deny bypass rules that prevent Traffic Server from bypassing certain incoming client requests dynamically (a deny bypass rule can prevent Traffic Server from bypassing itself). Dynamic deny bypass rules can be source, destination, or source/destination and have the following format:
deny_dyn_bypass src ipaddress | dst ipaddress | src ipaddresss AND ipaddress
For a description of the options, refer to the table above. For the dynamic deny bypass rules to work, you must set the variable proxy.config.arm.bypass_dynamic_enabled
to 1
in the records.config
file.
IMPORTANT: Static bypass rules overwrite dynamic deny bypass rules. If a static bypass rule and a dynamic bypass rule contain the same IP address, then the dynamic deny bypass rule will be ignored.
The following example shows source, destination, and source/destination bypass rules:
bypass src 1.1.1.0/24, 25.25.25.25, 128.252.11.11-128.252.11.255
bypass dst 24.24.24.0/24
bypass src 25.25.25.25 AND dst 24.24.24.0
The following example shows source, destination, and source/destination dynamic deny bypass rules:
deny_dyn_bypass src 128.252.11.11-128.252.11.255
deny_dyn_bypass dst 111.111.11.1
deny_dyn_bypass src 111.11.11.1 AND dst 111.11.1.1
The cache.config
file defines how Traffic Server caches web objects. You can add caching rules to specify the following:
IMPORTANT: After you modify the cache.config
file, navigate to the Traffic Server bin
directory; then run the traffic_line -x
command to apply changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.
Each line in the cache.config
file contains a caching rule. Traffic Server recognizes three space-delimited tags:
primary_destination=value secondary_specifier=value action=value
You can use more than one secondary specifier in a rule. However, you cannot repeat a secondary specifier.
The following table lists the possible primary destinations with allowed values.
Primary Destination |
Allowed Value |
---|---|
|
A requested domain name. Traffic Server matches the domain name of the destination from the URL in the request. |
|
A requested hostname. Traffic Server matches the hostname of the destination from the URL in the request. |
|
A requested IP address. Traffic Server matches the IP address of the destination in the request. |
|
A regular expression to be found in a URL. |
The secondary specifiers are optional in the cache.config
file. The following table lists possible secondary specifiers with allowed values.
Secondary Specifier |
Allowed Value |
---|---|
|
A requested URL port. |
|
A request URL protocol: http or https. |
|
A prefix in the path part of a URL. |
|
A file suffix in the URL. |
|
A request URL method: |
|
A time range, such as |
|
A client IP address. |
The following table lists possible actions and their allowed values.
Action |
Value |
---|---|
|
One of the following values:
|
|
The amount of time you want to keep the object(s) in the cache. The following time formats are allowed:
|
|
The amount of time object(s) are to be considered fresh. Use the same time formats as |
|
The amount of time object(s) are to be kept in the cache, regardless of |
The following example configures Traffic Server to revalidate gif
and jpeg
objects in the domain mydomain.com
every 6 hours, and all other objects in mydomain.com
every hour. The rules are applied in the order listed.
dest_domain=mydomain.com suffix=gif revalidate=6h
dest_domain=mydomain.com suffix=jpeg revalidate=6h
dest_domain=mydomain.com revalidate=1h
The congestion.config
file enables you to configure Traffic Server to stop forwarding HTTP requests to origin servers when they become congested, and then send the client a message to retry the congested origin server later. After you modify the congestion.control
file, navigate to the Traffic Server bin
directory; then run the traffic_line -x
command to apply changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster. Traffic Server uses the congestion.config
file only if you enable the Congestion Control option.
You can create rules in the congestion.config
file to specify:
Each line in congestion.config
must follow the format below. Traffic Server applies the rules in the order listed, starting at the top of the file.
Traffic Server recognizes three space-delimited tags:
primary_destination=value secondary_specifier=value action=value
The following table lists possible primary destinations with allowed values.
Primary Destination |
Allowed Value |
---|---|
|
A requested domain name. |
|
A requested hostname. |
|
A requested IP address. |
|
A regular expression to be found in a URL. |
The secondary specifiers are optional in the congestion.config
file. The following table lists possible secondary specifiers with allowed values. You can use more than one secondary specifier in a rule; however, you cannot repeat a secondary specifier.
Secondary Specifier |
Allowed Value |
---|---|
|
A requested URL port or range of ports. |
|
A prefix in the path part of a URL. |
The following table lists the possible tags and their allowed values.
Tag |
Allowed Value |
---|---|
|
The maximum number of connection failures allowed within the fail window described below before Traffic Server marks the origin server as congested. The default value is 5. |
|
The time period during which the maximum number of connection failures can occur before Traffic Server marks the origin server as congested. The default value is 120 seconds. |
|
The number of seconds that Traffic Server waits before contacting a congested origin server again. The default value is 10 seconds |
|
The number of seconds that the client is advised to wait before retrying the congested origin server. The default value is 300 seconds. |
|
The upper limit for a random number that is added to the wait interval. The default value is 30 seconds. |
|
The connection timeout to the live (uncongested) origin server. The default value is 60 seconds. |
|
The maximum number of retries allowed to the live (uncongested) origin server. The default value is 2. |
|
The connection timeout to the congested origin server. The default value is 15 seconds. |
|
The maximum number of retries allowed to the congested origin server. The default value is 1. |
|
The maximum number of connections allowed from Traffic Server to the origin server. The default value is -1. |
|
The error page sent to the client when a server is congested. You must enclose the value in quotes; the default value is |
|
Specifies if Traffic Server applies the rule on a per-host ( |
Examples
The following congestion.config
rule configures Traffic Server to stop forwarding requests to the server www.host.com
on port 80 (HTTP traffic) if the server is congested, according to the timeouts specified. Traffic Server uses the default tag values because no tag has been specified.
dest_host=www.host.com port=80
You can use one or more tags in a rule, but each tag must have one value only. If you specify no tags in the rule, then Traffic Server uses default values.
You can override any of the default tag values by adding configuration variables at the end of records.config
as follows:
CONFIG proxy.config.http.congestion_control.default.tag INT|STRING value
where tag
is one of the tags described in the table under congestion.config and value
is the value you want to use.
For example: CONFIG
proxy.config.http.congestion_control.default.congestion_scheme STRING per_host
IMPORTANT: Rules in the congestion.config
file override the following variables in the records.config
file:
proxy.config.http.connect_attempts_max_retries
proxy.config.http.connect_attempts_max_retries_dead_server
proxy.config.http.connect_attempts_rr_retries
proxy.config.http.connect_attempts_timeout
proxy.config.http.down_server.cache_time
proxy.config.http.down_server.abort_threshold
The filter.config
file enables you to deny or allow particular requests and strip header information from client requests. After you modify filter.config
, you must restart Traffic Server.
Each line in filter.config
contains a filtering rule. Traffic Server applies the rules in the order listed, starting at the top of the file.
Traffic Server recognizes three space-delimited tags:
primary_destination=value secondary_specifier=value action=value
The following table lists possible primary destinations with their allowed values.
Primary Destination |
Allowed Value |
---|---|
|
A requested domain name. Traffic Server matches the domain name of the destination from the URL in the request. |
|
A requested hostname. Traffic Server matches the hostname of the destination from the URL in the request. |
|
A requested IP address. Traffic Server matches the IP address of the destination in the request. |
|
A regular expression to be found in a URL. |
The secondary specifiers are optional in the filter.config
file. The following table lists the possible secondary specifiers and their allowed values. You can use more than one secondary specifier in a rule; however, you cannot repeat a secondary specifier.
The following table lists possible actions with allowed values.
Secondary Specifier |
Allowed Value |
---|---|
|
A requested URL port. |
|
A request URL protocol: |
|
A prefix in the path part of a URL. |
|
A file suffix in the URL. |
|
A request URL method. You can specify one of the following: Note: If the |
|
A time range, such as 08:00-14:00. |
|
A client IP address. |
The following example configures Traffic Server to keep the client IP address header for URL requests that contain the regular expression giraffes
and whose path prefix is /habitat
:
url_regex=giraffes prefix=/habitat keep_hdr=client_ip
The following example configures Traffic Server to strip all cookies from client requests destined for the origin server www.server1.com:
dest_host=www.server1.com strip_hdr=cookie
puts
to the origin server www.server2.com
: dest_host=www.server2.com method=put action=deny
The following example configures Traffic Server to allow only the host associated with the IP address 11.11.1.1 to deliver content directly into the cache (PUSH
). A deny rule is also included to prevent unauthorized users from pushing content into the cache.
dest_domain=. src_ip=11.11.1.1 method=PUSH action=allow
dest_domain=. method=PUSH action=deny
Traffic Server applies the rules in the order listed in the filter.config
file. For example, the sample filter.config
file below configures Traffic Server to do the following:
ldap.com
to access internal.com
internal.com
) to access server1.com
naughty.com
ldap.com
) with the attribute ou="Accounting Department" in their LDAP profile to access 401kfidelity.com
dest_host=internal.com action=ldap server=ldap.com dn="o=ldap.com"
dest_host=server1.com action=allow
dest_host=naughty.com action=deny
dest_host=401k.fidelity.com action=ldap server=ldap.com:389 dn="o=ldap.com" attr=ou attr_val="Accounting Department"
dest_ip=0.0.0.0-255.255.255.255 action=lda
The hosting.config
file enables you to assign cache partitions to specific origin servers and/or domains so that you can manage cache space efficiently and restrict disk usage. For step-by-step instructions on partitioning the cache according to origin servers and/or domains, refer to Partitioning the Cache According to Origin Server or Domain.
Before you can assign cache partitions to specific origin servers and/or domains, you must first partition your cache according to size and protocol in the partition.config
file. For step-by-step instructions about partitioning your cache, refer to Partitioning the Cache. For a description of the partition.config
file, refer to partition.config.
After you modify hosting.config,
navigate to the Traffic Server bin
directory and run the traffic_line -x
command to apply your changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.
IMPORTANT: The partition configuration must be the same on all nodes in a cluster.
Each line in the hosting.config
file must have one of the following formats:
hostname= hostname partition= partition_numbers
domain= domain_name partition= partition_numbers
where hostname
is the fully-qualified hostname of the origin server whose content you want to store on a particular partition (for example, www.myhost.com
); domain_name
is the domain whose content you want to store on a particular partition(for example, mydomain.com
); and partition_numbers
is a comma-separated list of the partitions on which you want to store the content that belongs to the origin server or domain listed. The partition numbers must be valid numbers listed in the partition.config
file.
Note: To allocate more than one partition to an origin server or domain, you must enter the partitions in a comma-separated list on one line, as shown in the example below. The hosting.config
file cannot contain multiple entries for the same origin server or domain.
When configuring the hosting.config
file, you must assign a generic partition to use for content that does not belong to any of the origin servers or domains listed. If all partitions for a particular origin server become corrupt, Traffic Server will also use the generic partition to store content for that origin server.
The generic partition must have the following format:
hostname=* partition=partition_numbers
where partition_numbers
is a comma-separated list of generic partitions.
The following example configures Traffic Server to store content from the domain mydomain.com
in partition 1 and content from www.myhost.com
in partition 2. Traffic Server stores content from all other origin servers in partitions 3 and 4.
domain=mydomain.com partition=1
hostname=www.myhost.com partition=2
hostname=* partition=3,
The icp.config
file defines ICP peers (parent and sibling caches).
IMPORTANT: After you modify the icp.config
file, navigate to the Traffic Server bin
directory and run the traffic_line -x
command to apply the changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.
Each line in the icp.config
file contains the name and configuration information for a single ICP peer in the following format:
host : host_IP : peer_type : proxy_port : icp_port : MC_on : MC_IP : MC_TTL :
Each field is described in the following table.
Field |
Description |
---|---|
|
The hostname of the ICP peer.
|
|
The IP address of the ICP peer. |
|
Use the following options:
|
|
The port number of the TCP port used by the ICP peer for proxy communication. |
|
The port number of the UDP port used by the ICP peer for ICP communication. |
The following example configuration is for three nodes: the local host, one parent, and one sibling.
localhost:0.0.0.0:3:8080:3130:0:0.0.0.0:1
host1:123.12.1.23:1:8080:3131:0:0.0.0.0:1
host2:123.12.1.24:2:8080:3131:0:0.0.0.0:1
The ip_allow.config
file controls client access to the Traffic Server proxy cache. You can specify ranges of IP addresses that are allowed to use the Traffic Server as a web proxy cache.
After you modify the ip_allow.config
file, navigate to the Traffic Server bin
directory and run the traffic_line -x
command to apply changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.
Each line in the ip_allow.config
file must have the following format:
src_ip=ipaddress action=ip_allow | ip_deny
where ipaddress
is the IP address or range of IP addresses of the clients allowed to access the Traffic Server proxy cache, the action ip_allow
enables the specified clients to access the Traffic Server proxy cache, and ip_deny
denies the specified clients to access the Traffic Server proxy cache.
By default, the ip_allow.config
file contains the following line, which allows all clients to access the Traffic Server proxy cache. To restrict access, comment out or delete this line before adding rules:
src_ip=0.0.0.0-255.255.255.255 action=ip_allow
The following example enables all clients to access the Traffic Server proxy cache:
src_ip=0.0.0.0-255.255.255.255 action=ip_allow
The following example allows all clients on a specific subnet to access the Traffic Server proxy cache:
src_ip=123.12.3.000-123.12.3.123 action=ip_allow
The following example denies all clients on a specific subnet to access the Traffic Server proxy cache:
src_ip=123.45.6.0-123.45.6.123 action=ip_deny
The logs.config
file establishes and formats traditional custom transaction log files.
Although Traffic Server supports traditional custom logging, you should use the more versatile XML-based custom logging (refer to Using the Custom Format and logs_xml.config). If you opt to use traditional custom logging instead of the more versatile XML-based custom logging, then you must enable the traditional custom logging option manually (refer to Support for Traditional Custom Logging).
IMPORTANT: After you modify logs.config
, navigate to the Traffic Server bin
directory and run the traffic_line -x
command to apply changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.
Each line in the logs.config
file establishes and formats a custom transaction log file. Lines consist of the following fields, separated by colons (:).
Field |
Allowed Inputs |
---|---|
|
All lines must begin with the word |
|
Specifies if the custom log file is activated. You can specify one of the following options:
|
|
You must use a unique integer for each custom log file you create. |
|
The name for the format you define. |
|
Identifies the Field symbols are indicated by %< |
|
The name of the custom log file you create. |
|
The format of the file: |
|
The header text. Enter |
The following example shows a custom log format for a file named minimalist
. It records the client host IP address (chi
), the client request universal resource identifier (cqu
), and the proxy response status code (pssc
).
format:enabled:1:minimal:%<chi> / %<cqu> / %<pssc>:minimalist:ASCII:none
The output file for the above example format is:
123.12.3.123 / GET http://earth/ocean/index.html HTTP/1.0 / 200
The following example shows a custom log format for a file named test
. It records the User-Agent
value of the client request header (cqh
) and the Retry-After
value of the proxy response header (psh
).
format:enabled:1:test:%<{User-Agent}cqh> %<{Retry-After}psh>:test:ASCII:none
Traffic Server supports WELF, the WebTrends Enhanced Log format, so you can analyze Traffic Server log files with WebTrends reporting tools. A predefined custom format for WELF is provided in the logs.config
file. To create a WELF format log file, comment out the following section at the end of the file and replace <FORMAT_ID>
with a unique integer.
#format:enabled:<FORMAT_ID>:welf:id=firewall time="%<cqtd> %<cqtt>" fw=%<phn> pri=6 proto=%<cqus> duration=%<ttmsf> sent=%<psql> rcvd=%<cqhl> src=%<chi> dst=%<shi> dstname=%<shn> user=%<caun> op=%<cqhm> arg="%<cqup>" result=%<pssc> ref="%<{Referer}cqh>" agent="%<{user-agent}cqh>" cache=%<crc>:welf:ASCII:none
#
To record HTTP transactions for different origin servers in separate log files, you must list each origin server hostname in the log_hosts.config
file. In addition, you must enable the HTTP Host Log Splitting option. You should use the same log_hosts.config
file on every Traffic Server node in your cluster. After you modify the log_hosts.config
file, navigate to the Traffic Server bin
directory and run the traffic_line -x
command to apply the changes. When you apply the changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.
Each line in the log_hosts.config
file has the following format:
hostname
where hostname
is the hostname of the origin server.
Tip: You can specify keywords in the log_hosts.config
file to record all transactions from origin servers with the specified keyword in their names in a separate log file. See the example below.
The following example configures Traffic Server to create separate log files containing all HTTP transactions for the origin servers webserver1
, webserver2
, and webserver3
.
webserver1
webserver2
webserver3
The following example records all HTTP transactions from origin servers that contain sports
in their names. For example: sports.yahoo.com
and www.foxsports.com
in a log file called squid-sport.log
(the Squid format is enabled).
sports
The logs_xml.config
file defines the custom log file formats, filters, and processing options. The format of this file is modeled after XML, the Extensible Markup Language.
The logs_xml.config
file contains the specifications below:
LogFormat
specifies the fields to be gathered from each protocol event access. LogFilter
specifies the filters that are used to include or exclude certain entries being logged based on the value of a field within that entry. LogObject
specifies an object that contains a particular format, a local filename, filters, and collation servers.The logs_xml.config
file ignores extra white space, blank lines, and all comments.
The following table lists LogFormat
specifications.
Field |
Allowed Inputs |
---|---|
|
Required. Valid format names include any name except |
|
Required. A valid format specification is a printf-style string describing each log entry when formatted for ASCII output. Use The specified field can be one of the following types:
Note: You cannot create a format specification that contains both aggregate operators and regular fields. |
|
Use this tag when the format contains aggregate operators. The value " The valid set of aggregate operators are: |
The following table lists the LogFilter
specifications.
Field |
Allowed Inputs |
---|---|
|
Required. All filters must be uniquely named. |
|
Required. This field contains the following elements:
Note: There are no negative comparison operators. If you want to specify a negative condition, then use the |
|
This instructs Traffic Server to either accept or reject records that satisfy the filter condition. |
The following table lists the LogObject
specifications.
Field |
Allowed Inputs |
---|---|
|
Required. Valid format names include the predefined logging formats: |
|
Required. The filename to which the given log file is written on the local file system or on a remote collation server. No local log file will be created if you fail to specify this tag. All filenames are relative to the default logging directory. If the name does not contain an extension (for example, |
|
Valid logging modes include
If you are using a collation server, then the log is written to a pipe on the collation server. A local pipe is created even before a transaction is processed, so you can see the pipe right after Traffic Server starts. Pipes on a collation server, however, are created when Traffic Server starts. |
|
A comma-separated list of names of any previously-defined log filters. If more than one filter is specified, then all filters must accept a record for the record to be logged. |
|
A comma-separated list of the protocols this object should log. Valid protocol names for this release are |
|
A comma-separated list of valid hostnames.This tag indicates that only entries from the named servers will be included in the file. |
|
A comma-separated list of collation servers to which all log entries (for this object) are forwarded. Collation servers can be specified by name or IP address. Specify the collation port with a colon after the name; for example, |
|
The header text you want the log files to contain. The header text appears at the beginning of the log file, just before the first record. |
|
Enables or disables log file rolling for the
|
|
The seconds between log file rolling for the |
|
Specifies an hour (from 0 to 23) at which rolling is guaranteed to align. Rolling might start before then, but a rolled file will be produced only at that time. The impact of this setting is only noticeable if the rolling interval is larger than one hour. |
|
The size at which log files are rolled. |
Examples
The following is an example of a LogFormat
specification that collects information using three common fields:
<LogFormat> <Name = "minimal"/> <Format = "%<chi> : %<cqu> : %<pssc>"/> </LogFormat>
The following is an example of a LogFormat
specification that uses aggregate operators:
<LogFormat> <Name = "summary"/> <Format = "%<LAST(cqts)> : %<COUNT(*)> : %<SUM(psql)>"/> <Interval = "10"/> </LogFormat>
The following is an example of a LogFilter
that will cause only REFRESH_HIT
entries to be logged:
<LogFilter> <Name = "only_refresh_hits"/> <Action = "ACCEPT"/> <Condition = "%<pssc> MATCH REFRESH_HIT"/>
</LogFilter>
Note: When specifying the field in the filter condition, you can omit the %<>
. This means that the filter below is equivalent to the example directly above:
<LogFilter> <Name = "only_refresh_hits"/> <Action = "ACCEPT"/> <Condition = "pssc MATCH REFRESH_HIT"/> </LogFilter>
The following is an example of a LogObject
specification that creates a local log file for the minimal format defined earlier. The log filename will be minimal.log
because this is an ASCII log file (the default).
<LogObject> <Format = "minimal"/> <Filename = "minimal"/> </LogObject>
The following is an example of a LogObject
specification that includes only HTTP requests served by hosts in the domain company.com
or by the specific server server.somewhere.com
. Log entries are sent to port 4000 of the collation host logs.company.com
and to port 5000 of the collation host 209.131.52.129.
<LogObject>
<Format = "minimal"/>
<Filename = "minimal"/>
<ServerHosts = "company.com,server.somewhere.com"/>
<Protocols = "http"/>
<CollationHosts = "logs.company.com:4000,209.131.52.129:5000"/>
</LogObject>
Traffic Server supports WELF (WebTrends Enhanced Log Format) so you can analyze Traffic Server log files with WebTrends reporting tools. A predefined <LogFormat>
that is compatible with WELF is provided at the end of the
file (shown below). To create a WELF format log file, create a logs.config
that uses this predefined format.<LogObject>
<LogFormat>
<Name = "welf"/>
<Format = "id=firewall time=\"%<cqtd> %<cqtt>\" fw=%<phn> pri=6
proto=%<cqus> duration=%<ttmsf> sent=%<psql> rcvd=%<cqhl>
src=%<chi> dst=%<shi> dstname=%<shn> user=%<caun> op=%<cqhm>
arg=\"%<cqup>\" result=%<pssc> ref=\"%<{Referer}cqh>\"
agent=\"%<{user-agent}cqh>\" cache=%<crc>"/>
</LogFormat>
The parent.config
file identifies the parent proxies used in an cache hierarchy. Use this file to perform the following configuration:
Traffic Server uses the parent.config
file only when the parent caching option is enabled (refer to Configuring Traffic Server to Use a Parent Cache).
IMPORTANT: After you modify the parent.config
file, navigate to the Traffic Server bin
directory and run the traffic_line -x
command to apply your changes. When you apply the changes to one node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.
Each line in the parent.config
file must contain a parent caching rule. Traffic Server recognizes three space-delimited tags:
primary_destination=value secondary_specifier=value action=value
The following table lists the possible primary destinations and their allowed values.
Primary Destination |
Allowed Value |
---|---|
|
A requested domain name. |
|
A requested hostname. |
|
A requested IP address or range of IP addresses separated by a dash (-). |
|
A regular expression to be found in a URL |
The secondary specifiers are optional in the parent.config
file. The following table lists the possible secondary specifiers and their allowed values.
Secondary Specifiers |
Allowed Value |
---|---|
|
A requested URL port. |
|
A request URL protocol: |
|
A prefix in the path part of a URL. |
|
A file suffix in the URL. |
|
A request URL method. It can be one of the following: |
|
A time range, such as 08:00-14:00, during which the parent cache is used to serve requests. |
|
A client IP address. |
The following tables lists the possible actions and their allowed values.
Action |
Allowed Value |
---|---|
|
An ordered list of parent servers. If the request cannot be handled by the last parent server in the list, then it will be routed to the origin server. You can specify either a hostname or an IP address, but; you must specify the port number. |
|
One of the following values:
|
|
One of the following values:
|
The following rule configures a parent cache hierarchy consisting of Traffic Server (which is the child) and two parents, p1.x.com
and p2.x.com
. Traffic Server forwards the requests it cannot serve to the parent servers p1.x.com
and p2.x.com
in a round-robin fashion because:
round_robin=true.
dest_domain=. method=get parent=”p1.x.com:8080; p2.y.com:8080” round_robin=true
The following rule configures Traffic Server to route all requests containing the regular expression politics
and the path /viewpoint
directly to the origin server (bypassing any parent hierarchies):
url_regex=politics prefix=/viewpoint go_direct=true
Every line in the parent.config
file must contain either a parent=
or go_direct=
directive.
The partition.config
file enables you to manage your cache space more efficiently and restrict disk usage by creating cache partitions of different sizes for specific protocols. You can further configure these partitions to store data from certain origin servers and/or domains in the
hosting.config file.
IMPORTANT: The partition configuration must be the same on all nodes in a cluster. You must stop Traffic Server before you change the cache partition size and protocol assignment. For step-by-step instructions about partitioning the cache, refer to Partitioning the Cache.
For each partition you want to create, enter a line with the following format:
partition=partition_number scheme=protocol_type size=partition_size
where partition_number
is a number between 1 and 255 (the maximum number of partitions is 255) and
protocol_type
is http
. Traffic Server supports http
for HTTP partition types; partition_size
is the amount of cache space allocated to the partition. This value can be either a percentage of the total cache space or an absolute value. The absolute value must be a multiple of 128 MB, where 128 MB is the smallest value. If you specify a percentage, then the size is rounded down to the closest multiple of 128 MB.
Each partition is striped across several disks to achieve parallel I/O. For example: if there are four disks, then a 1-GB partition will have 256 MB on each disk (assuming each disk has enough free space available). If you do not allocate all the disk space in the cache, then the extra disk space is not used. You can use the extra space later to create new partitions without deleting and clearing the existing partitions.
The following example partitions the cache evenly between HTTP and HTTPS requests:
partition=1 scheme=http size=50%
partition=2 scheme=https size=50%
The records.config
file is a list of configurable variables used by the Traffic Server software. Many of the variables in the records.config
file are set automatically when you set configuration options in Traffic Line or Traffic Shell. After you modify the records.config
file, navigate to the Traffic Server bin
directory and run the command traffic_line -x
to apply the changes. When you apply changes to one node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.
Each variable has the following format:
CONFIG variable_name DATATYPE variable_value
where DATATYPE
is INT
(integer), STRING
(string), or FLOAT
(floating point).
In the following example, the variable proxy.config.proxy_name
is a STRING
datatype with the value my_server
. This means that the name of the Traffic Server proxy is my_server
.
CONFIG proxy.config.proxy_name STRING my_server
In the following example, the variable proxy.config.arm.enabled
is a yes/no flag. A value of 0
(zero) disables the option; a value of 1
enables the option.
CONFIG proxy.config.arm.enabled INT 0
In the following example, the variable sets the cluster startup timeout to 10 seconds.
CONFIG proxy.config.cluster.startup_timeout INT 10
The following table describes the configuration variables listed in the records.config
file.
Configuration Variable |
Default Value |
Description |
---|---|---|
System Variables | ||
|
|
The name of the Traffic Server node. |
|
|
The location of the Traffic Server |
|
|
The name of the executable that runs the |
|
|
The command-line options for starting Traffic Server. |
|
|
The name of the executable that runs the |
|
|
The name of the executable that runs the command-line interface (Traffic Line). |
|
|
The name of the executable that runs the |
|
|
The script executed before the |
|
|
The directory that contains Traffic Server configuration files. |
|
|
The directory used for Traffic Server temporary files. |
|
|
The email address to which Traffic Server sends alarm messages. During a custom Traffic Server installation, you can specify the email address; otherwise, Traffic Server uses the Traffic Server user account name as the default value for this variable. |
|
|
The facility used to record system log files. Refer to Understanding Traffic Server Log Files. |
|
|
The signal sent to 0 = no signal is sent. |
|
|
The minimum amount of free swap space allowed before Traffic Server stops the This configuration variable applies if swap is enabled in Linux 2.2 only. |
|
|
The minimum amount of free memory allowed before Traffic Server stops the This configuration variable applies if swap is disabled in Linux 2.2 only. |
|
|
The name and location of the file that contains warnings, status messages, and error messages produced by the Traffic Server processes. If no path is specified, then Traffic Server creates the file in its logging directory. |
|
|
The directory in which Traffic Server stores configuration snapshots on the local system. Unless you specify an absolute path, this directory is located in the Traffic Server |
|
0 |
When enabled (1 ), runs a separate thread for accept processing. If disabled (0 ), then only 1 thread can be created. |
|
1096908 |
The new default thread stack size, for all threads. The original default is set at 1 MB. |
Local Manager | ||
|
|
The semaphore ID for the local manager. |
|
|
Sets the clustering mode:
|
|
|
The reliable service port. The reliable service port is used to send configuration information between the nodes in a cluster. All nodes in a cluster must use the same reliable service port. |
|
|
The autoconfiguration port. |
|
|
The port used for retrieving and setting statistics and configuration variables. |
|
|
The maximum number of copies of rolled configuration files to keep. |
|
|
Option used to specify who to run the The nonprivileged user account designated to Traffic Server. |
Process Manager | ||
|
|
The port used for internal communication between the |
Alarm Configuration | ||
|
|
Name of the script file that can execute certain actions when an alarm is signaled. The default file is a sample script named |
|
|
The full path to the script file that sends email to alert someone about Traffic Server problems. |
Authentication Basic Realm | ||
|
|
The authentication realm name. If the default of |
HTTP Engine |
||
|
|
The port that Traffic Server uses when acting as a web proxy server for web traffic. |
|
|
The server port options. You can specify one of the following:
|
|
|
The ports other than the port specified by the variable |
|
|
The range of ports used for tunneling. Traffic Server allows tunnels only to the specified ports. For example: to retrieve an object using HTTPS via Traffic Server, a tunnel must be established to an origin server via Traffic Server. |
|
|
You can specify one of the following:
|
|
|
You can specify one of the following:
|
|
|
Enables ( For example: if a client makes a request to |
|
|
When enabled ( |
|
|
When enabled ( |
|
|
Enables ( |
|
|
Specifies whether Traffic Sever can generate a chunked response: 0 = Never1 = Always2 = Generate a chunked response if the server has returned HTTP 1.1 before3 = Generate a chunked response if the client request is HTTP 1.1 and the origin server has returned HTTP 1.1 before |
|
|
Configures Traffic Server to use HTTP Version 1.1 when communicating with origin servers. You can specify one of the following values:
Note: If HTTP 1.1 is used, then Traffic Server can use keep-alive connections with pipelining to origin servers. If HTTP 0.9 is used, then Traffic Server does not use keep-alive connections to origin servers. If HTTP 1.0 is used, then Traffic Server can use keep-alive connections without pipelining to origin servers. |
|
|
Enables ( |
|
|
Enables ( |
Parent Proxy Configuration |
||
|
|
Enables ( Refer to Hierarchical Caching. |
|
|
The amount of time allowed between connection retries to a parent cache that is unavailable. |
|
|
The number of times the connection to the parent cache can fail before Traffic Server considers the parent unavailable. |
|
|
The total number of connection attempts allowed to a parent cache before Traffic Server bypasses the parent or fails the request (depending on the |
|
|
The total number of connection attempts allowed per parent, if multiple parents are used. |
|
|
The timeout value (in seconds) for parent cache connection attempts. |
|
|
Configures Traffic Server to send proxy authentication headers on to the parent cache. |
HTTP Connection Timeouts (secs) |
||
|
|
Specifies how long Traffic Server keeps connections to clients open for a subsequent request after a transaction ends. |
|
|
Specifies how long Traffic Server keeps connections to origin servers open for a subsequent transfer of data after a transaction ends. |
|
|
Specifies how long Traffic Server keeps connections to clients open if a transaction stalls. |
|
|
Specifies how long Traffic Server keeps connections to origin servers open if the transaction stalls. |
|
|
The maximum amount of time Traffic Server can remain connected to a client. If the transfer to the client is not complete before this timeout expires, then Traffic Server closes the connection. The default value of |
|
|
The maximum amount of time Traffic Server waits for fulfillment of a connection request to an origin server. If Traffic Server does not complete the transfer to the origin server before this timeout expires, then Traffic Server terminates the connection request. The default value of |
|
|
The timeout interval in seconds before Traffic Server closes a connection that has no activity. |
|
|
Specifies how long Traffic Server continues a background fill before giving up and dropping the origin server connection. |
|
|
The proportion of total document size already transferred when a client aborts at which the proxy continues fetching the document from the origin server to get it into the cache (a background fill). |
Origin Server Connect Attempts |
||
|
|
The maximum number of connection retries Traffic Server can make when the origin server is not responding. |
|
|
The maximum number of connection retries Traffic Server can make when the origin server is unavailable. |
|
|
Limits the number of socket connections across all origin servers to the value specified. To disable, set to zero ( |
|
0 | Limits the number of socket connections per origin server to the value specified. To disable, set to zero ( |
|
2 | The maximum number of failed connection attempts allowed before a round-robin entry is marked as 'down' if a server has round-robin DNS entries. |
|
|
The timeout value (in seconds) for an origin server connection. |
|
|
The timeout value (in seconds) for an origin server connection when the client request is a |
|
|
Specifies how long (in seconds) Traffic Server remembers that an origin server was unreachable. |
|
|
The number of seconds before Traffic Server marks an origin server as unavailable after a client abandons a request because the origin server was too slow in sending the response header. |
Congestion Control | ||
|
|
Enables ( Refer to Using Congestion Control. |
Negative Response Caching | ||
|
|
When enabled ( Note:
|
|
|
The how long (in seconds) Traffic Server keeps the negative responses valid in cache. Note: This value only affects negative responses that do have explicit |
Proxy User Variables | ||
|
|
When enabled ( |
|
|
When enabled ( |
|
|
When enabled ( |
|
|
When enabled ( |
|
|
When enabled ( |
|
|
When enabled ( |
|
|
When enabled ( |
|
|
The headers Traffic Server should remove from outgoing requests. |
|
|
When enabled ( |
|
0 |
Enable (
This is useful for minimizing cached alternates of documents (e.g. |
Security | ||
|
|
Enables ( Important: If you enable this option, then you must also specify a filtering rule in the |
Cache Control | ||
|
|
Enables ( |
|
|
When enabled ( |
|
|
When enabled ( |
|
|
When enabled ( |
|
|
Specifies how cookies are cached:
|
|
|
When enabled ( |
|
|
Enables ( |
|
0 |
Enables ( |
|
0 |
Specifies when to revalidate content:
If the request contains the |
|
0 |
Specifies when to add
|
|
|
The type of headers required in a request for the request to be cacheable.
|
|
|
The maximum age allowed for a stale response before it cannot be cached. |
|
|
When enabled ( |
|
0 |
Enables (1 ) or disables (0 ) the ability to read a cached object while another connection is completing a write to cache for the same object. If you want connection collapsing to work, then this option must be enabled. |
|
0 | Enables (1 ) or disables (0 ) whether requests will first search the hashtable to see if another similar request is already being served. |
|
0 | When enabled (1 ) while the write configuration parameter is also enabled, secondary clients will wait this amount of time (in msec) before cache lookup is retried. |
|
0 | The amount of time (msec) secondary clients for the same URL will be served the stale object when revalidation of a cached object is in progress. |
|
0 |
Sets a minimum fuzz time; the default value is Effective fuzz time is a calculation in the range ( |
|
0 |
When enabled (1 ), Traffic Server serves documents from cache with a Content-Type: header that does not match the Accept: header of the request.
Note: This option should only be enabled if you're having problems with caching and one of the following is true: Vary: Accept when doing content negotiation with Accept -OR- 406 (Not Acceptable) response for types that it cannot serve. |
|
0 |
When enabled ( Note: This option should only be enabled if you're having problems with caching and your origin server is guaranteed to set |
|
0 |
When enabled ( Note: This option should only be enabled if you're having problems with caching and your origin server is guaranteed to set |
|
0 |
When enabled ( Note: This option should only be enabled if you're having problems with caching and your origin server is guaranteed to set |
|
1 |
When enabled (1 ), Traffic Server ignores any Cache-Control: max-age headers from the client. |
Heuristic Expiration |
||
|
|
The minimum amount of time a document in the cache is considered to be fresh. |
|
|
The maximum amount of time a document in the cache remains fresh. |
|
|
The aging factor for freshness computations. |
|
|
How often Traffic Server checks for an early refresh, during the period before the document stale time. The interval specified must be in seconds. |
|
|
The probability that a refresh is made on a document during the specified fuzz time. |
Dynamic Content & Content Negotiation |
||
|
|
The header on which Traffic Server varies for text documents. For example: if you specify |
|
|
The header on which Traffic Server varies for images. |
|
|
The header on which Traffic Server varies for anything other than text and images. |
Customizable User Response Pages | ||
|
|
Specifies whether customizable response pages are enabled or disabled and which response pages are used:
|
|
|
Enables ( |
|
|
The customizable response page default directory. |
|
|
Specifies when Traffic Server suppresses generated response pages:
|
DNS | ||
|
|
Enables ( For example: if a client makes a request to an unqualified host ( |
|
|
Enables ( |
|
|
The default domain for split DNS requests. This value is appended automatically to the hostname if it does not include a domain before split DNS determines which DNS server to use. |
|
|
Specifies a list of hostname extensions that are automatically added to the hostname after a failed lookup. For example: if you want Traffic Server to add the hostname extension .org, then specify Note: If the variable |
|
|
Enables ( |
|
|
The DNS servers. |
|
0 |
Indicates whether to utilize SRV records for orgin server lookup. |
|
0 |
The number of seconds for which to utilize a stale NS record while initiating a background fetch for the new data. |
|
33554432 |
The amount of space (in bytes) used to store hostdb . The value of this variable must be increased if you increase the size of the proxy.config.hostdb.size variable. |
HostDB | ||
|
|
The maximum number of entries allowed in the host database. Note: For values above |
|
|
The host database time to live mode. You can specify one of the following:
|
|
|
The foreground timeout (in minutes). |
|
|
When disabled ( |
Logging Config |
||
|
|
Enables and disables event logging:
Refer to Working with Log Files. |
|
|
The maximum amount of time before data in the buffer is flushed to disk. |
|
|
The amount of space allocated to the logging directory (in MB). |
|
|
The amount of space allocated to the logging directory (in MB) if this node is acting as a collation client. |
|
|
The tolerance for the log space limit (in bytes). If the variable |
|
|
The hostname of the machine running Traffic Server. |
|
|
The full path to the logging directory. |
|
|
The log file permissions. The standard UNIX file permissions are used (owner, group, other). Permissable values are:
Permissions are subject to the umask settings for the Traffic Server process. This means that a umask setting of |
|
|
Enables ( |
|
|
Enables ( Note: Although Traffic Server supports traditional custom logging, you should use the more versatile XML-based custom formats. |
|
|
Enables ( |
|
|
The squid log file type:
|
|
|
The squid log filename. |
|
|
The squid log file header text. |
|
|
Enables ( |
|
|
The Netscape common log file type:
|
|
|
The Netscape common log filename. |
|
|
The Netscape common log file header text. |
|
|
Enables ( |
|
|
The Netscape extended log file type:
|
|
|
The Netscape extended log filename. |
|
|
The Netscape extended log file header text. |
|
|
Enables ( |
|
|
The Netscape Extended-2 log file type:
|
|
|
The Netscape Extended-2 log filename. |
|
|
The Netscape Extended-2 log file header text. |
|
|
When enabled ( |
|
|
When enabled ( Refer to HTTP Host Log Splitting. |
|
|
The log collation mode:
For information on sending XML-based custom formats to the collation server, refer to logs_xml.config. Note: Although Traffic Server supports traditional custom logging, you should use the more versatile XML-based custom formats. |
|
|
The hostname of the log collation server. |
|
|
The port used for communication between the collation server and client. |
|
|
The password used to validate logging data and prevent the exchange of unauthorized information when a collation server is being used. |
|
|
When enabled ( |
|
|
The number of seconds between collation server connection retries. |
|
|
Specifies how log files are rolled. You can specify the following values:
|
|
|
The log file rolling interval, in seconds. The minimum value is |
|
|
The file rolling offset hour. The hour of the day that starts the log rolling period. |
|
|
The size that log files must reach before rolling takes place. |
|
|
Enables ( |
|
|
Configures Traffic Server to log only a sample of transactions rather than every transaction. You can specify the following values: 1 = log every transaction2 = log every second transaction3 = log every third transactionand so on... |
|
0 |
The number of milliseconds before a slow connection's debugging stats are dumped. Specify 1 to enable or 0 to disable. |
Reverse Proxy | ||
|
|
Enables ( |
|
|
The URL to which to redirect requests with no host headers (reverse proxy). |
URL Remap Rules | ||
|
|
Enables ( For this type of redirection to work, the variable |
|
|
Sets the PAC port so that PAC requests made to the Traffic Server proxy service port are redirected this port.
This variable can be used together with the For example: if you create a Perl script that listens on port 9000 and writes a PAC file in response to any request, then you can set this variable to |
|
|
Set this variable to |
|
|
Set this variable to |
SSL Termination | ||
|
|
Indicates if an accelerator card is required for operation. Traffic Server supports Cavium accelerator cards. You can specify: You can verify operation by running |
|
|
Enables ( |
|
|
Enables ( |
|
|
Enables ( |
|
|
Enables ( Note: IBM web servers do not support the TLS (Transport Layer Security) protocol. For IBM web servers to work with Traffic Server, you must set this variable to |
|
|
Specifies if the Cavium SSL accelerator card is installed on (and required by) your Traffic Server machine:
|
|
|
The port used for SSL communication. |
|
|
Sets the client certification level:
|
|
|
The filename of the Traffic Server SSL certificate (the server certificate). |
|
|
The file, in a chain of certificates, that is the root certificate recognized by your website. |
|
|
The location of the Traffic Server SSL certificate (the server certificate). |
|
|
The filename of the Traffic Server private key. Change this variable only if the private key is not located in the Traffic Server SSL certificate file. |
|
|
The location of the Traffic Server private key. Change this variable only if the private key is not located in the SSL certificate file. |
|
|
The filename of the certificate authority that client certificates will be verified against. |
|
|
The location of the certificate authority file that client certificates will be verified against. |
|
|
Configures Traffic Server to verify the origin server certificate with the Certificate Authority (CA). |
|
|
The filename of SSL client certificate installed on Traffic Server. |
|
|
The location of the SSL client certificate installed on Traffic Server. |
|
|
The filename of the Traffic Server private key. Change this variable only if the private key is not located in the Traffic Server SSL client certificate file. |
|
|
The location of the Traffic Server private key. Change this variable only if the private key is not located in the SSL client certificate file. |
|
|
The filename of the certificate authority against which the origin server will be verified. |
|
|
Specifies the location of the certificate authority file against which the origin server will be verified. |
ICP Configuration | ||
|
|
Sets ICP mode for hierarchical caching:
Refer to ICP Peering. |
|
|
Specifies the network interface used for ICP traffic. Note: The Traffic Server installation script detects your network interface and sets this variable appropriately. If your system has multiple network interfaces, check that this variable specifies the correct interface. |
|
|
Specifies the UDP port that you want to use for ICP messages. |
|
|
Specifies the timeout used for ICP queries. |
Scheduled Update Configuration | ||
|
|
Enables ( |
|
|
Enables ( |
|
|
Specifies the number of times Traffic Server can retry the scheduled update of a URL in the event of failure. |
|
|
Specifies the delay (in seconds) between each scheduled update retry for a URL in the event of failure. |
|
|
Specifies the maximum simultaneous update requests allowed at any time. This option prevents the scheduled update process from overburdening the host. |
Remap Plugin Processor | ||
|
|
Enables ( |
|
|
Specifies the number of threads that will be used for remap plugin processing. |
Plug-in Configuration | ||
|
|
Specifies the location of Traffic Server plugins. |
Sockets | ||
|
|
Sets the send buffer size for connections from the client to Traffic Server. |
|
0 |
Sets the receive buffer size for connections from the client to Traffic Server. |
|
0 |
Turns different options "on" for the socket handling client connections: Note: This is a flag and you look at the bits set. Therefore, you must set the value to |
|
0 |
Sets the send buffer size for connections from Traffic Server to the origin server. |
|
0 |
Sets the receive buffer size for connections from Traffic Server to the origin server. |
|
0 |
Turns different options "on" for the origin server socket: Note: This is a flag and you look at the bits set. Therefore, you must set the value to |
|
0 |
Same as the command line option --accept_mss that sets the MSS for all incoming requests. |
The remap.config
file contains mapping rules that Traffic Server uses to perform the following actions:
Refer to Reverse Proxy and HTTP Redirects, for information about redirecting HTTP requests and using reverse proxy.
IMPORTANT: After you modify the remap.config
file, navigate to the Traffic Server bin
directory; then run the traffic_line -x
command to apply the changes. When you apply the changes to one node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.
Each line in the remap.config
file must contain a mapping rule. Traffic Server recognizes three space-delimited fields: type
, target
, and replacement
. The following table describes the format of each field.
Field |
Description |
---|---|
|
Enter one of the following:
Note: use the |
|
Enter the origin ("from") URL. You can enter up to four components:
where |
|
Enter the destination ("to") URL. You can enter up to four components:
where |
The following section shows example mapping rules in the remap.config
file.
The following example shows a map rule that does not specify a path prefix in the target or replacement:
map http://www.x.com/ http://server.hoster.com/
This rule results in the following translations:
Client Request |
Translated Request |
---|---|
|
|
|
|
The following example shows a map rule with path prefixes specified in the target:
map http://www.intranet.y.com/marketing http://marketing.y.com/
map http://intranet.y.com/sales http://sales.y.com/
map http://intranet.y.com/engineering http://engineering.y.com/
map http://intranet.y.com/ http://info.y.com/
These rules result in the following translations:
Client Request |
Translated Request |
---|---|
|
|
|
|
|
|
The following example shows that the order of the rules matters:
map http://www.g.com/ http://external.g.com/
map http://www.g.com/stuff http://stuff.g.com
These rules result in the following translation.
Client Request |
Translated Request |
---|---|
|
|
In the above examples, the second rule is never applied because all URLs that match the second rule also match the first rule. The first rule takes precedence because it appears earlier in the remap.config
file.
The following example shows a mapping with a path prefix specified in the target and replacement:
map http://www.h.com/a/b http://server.h.com/customers/x/y
This rule results in the following translation.
Client Request |
Translated Request |
---|---|
|
|
|
|
The following example shows reverse-map rules:
map http://www.x.com/ http://server.hoster.com/x/
reverse_map http://server.hoster.com/x/ http://www.x.com/
These rules result in the following translations.
Client Request |
Translated Request |
---|---|
|
|
Client Request |
Origin server Header |
Translated Header |
---|---|---|
|
|
|
When acting as a reverse proxy for multiple servers, Traffic Server is unable to route to URLs from older browsers that do not send the Host:
header. As a solution, set the variable proxy.config.header.parse.no_host_url_redirect
in the records.config
file to the URL to which Traffic Server will redirect requests without host headers.
The following rule permanently redirects all HTTP requests for www.company.com
to www.company2.com
:
redirect http://www.company.com http://www.company2.com
The following rule temporarily redirects all HTTP requests for www.company1.com
to www.company2.com
:
redirect_temporary http://www.company1.com http://www.company2.com
Regular expressions can be specified in remapping rules, with the limitations below:
host
field can contain regexes; the scheme
, port
, and other fields cannot. For path manipulation via regexes, use the regex_remap
plugin. $0
thru $9
can be used as subtraction placeholders ($0
will be the entire input string).regex_map http://x ([0-9]+).z.com http://real-x$1.z.com
regex_redirect http://old.(.*).z.com http://new.$1.z.com
The splitdns.config
file enables you to specify the DNS server that Traffic Server should use for resolving hosts under specific conditions. For more information, refer to Configuring DNS Server Selection (Split DNS).
To specify a DNS server, you must supply the following information in each active line within the file:
You can also include the following optional information with each DNS server specification:
IMPORTANT: After you modify the splitdns.config
file, navigate to the Traffic Server bin
directory and run the traffic_line -x
command to apply the changes. When you apply changes to a node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.
Each line in the splitdns.config
file uses one of the following formats:
dest_domain=dest_domain | dest_host | url_regex named=dns_server def_domain=def_domain >search_list=search_list
The following table describes each field.
Field |
Allowed Value |
---|---|
|
A valid domain name. This specifies that DNS server selection will be based on the destination domain. You can prefix the domain with an exclamation mark ( |
|
A valid hostname. This specifies that DNS server selection will be based on the destination host. You can prefix the host with an exclamation mark ( |
|
A valid URL regular expression. This specifies that DNS server selection will be based on a regular expression. |
|
This is a required directive. It identifies the DNS server that Traffic Server should use with the given destination specifier. You can specify a port using a colon ( You must specify the domains with IP addresses in CIDR ("dot") notation. |
|
A valid domain name. This optional directive specifies the default domain name to use for resolving hosts. Only one entry is allowed. If you do not provide the default domain, the system determines its value from |
|
A list of domains separated by spaces or semicolons (;). This specifies the domain search order. If you do not provide the search list, the system determines the value from |
Consider the following DNS server selection specifications:
dest_domain=internal.company.com named=255.255.255.255:212 255.255.255.254 def_domain=company.com search_list=company.com company1.com
dest_domain=!internal.company.com named=255.255.255.253
Now consider the following two requests:
http://minstar.internal.company.com
This request matches the first line and therefore selects DNS server
255.255.255.255
on port 212
. All resolver requests use company.com
as the default domain, and company.com
and company1.com
as the set of domains to search first.
http://www.microsoft.com
This request matches the second line. Therefore, Traffic Server selects DNS server 255.255.255.253
. Because no def_domain
or search_list
was supplied, Traffic Server retrieves this information from /etc/resolv.conf
The ssl_multicert.config
file lets you configure Traffic Server to use multiple SSL server certificates with the SSL termination option. If you have a Traffic Server system with more than one IP address assigned to it, then you can assign a different SSL certificate to be served when a client requests a particular IP address.
The format of the ssl_multicert.config
file is:
dest_ip=ipaddress ssl_cert_name=cert_name ssl_key_name=key_name
where ipaddress
is an IP address assigned to Traffic Server , cert_name
is the filename of the Traffic Server SSL server certificate, and key_name
is the filename of the Traffic Server SSL private key. If the private key is located in the certificate file, then you do not need to specify the name of the private key.
The following example configures Traffic Server to use the SSL certificate server.pem
for all requests to the IP address 111.11.11.1 and the SSL certificate server1.pem
for all requests to the IP address 11.1.1.1. Since the private key is included in the certificate files, no private key name is specified.
dest_ip=111.11.11.1 ssl_cert_name=server.pem
dest_ip=11.1.1.1 ssl_cert_name=server1.pem
The following example configures Traffic Server to use the SSL certificate server.pem
and the private key serverKey.pem
for all requests to the IP address 111.11.11.1. Traffic Server uses the SSL certificate server1.pem
and the private key serverKey1.pem
for all requests to the IP address 11.1.1.1.
dest_ip=111.11.11.1 ssl_cert_name=server.pem ssl_key_name=serverKey.pem
dest_ip=11.1.1.1 ssl_cert_name=server1.pem ssl_key_name=serverKey1.pem
The storage.config
file lists all the files, directories, and/or hard disk partitions that make up the Traffic Server cache. After you modify the storage.config
file, you must restart Traffic Server.
The format of the storage.config
file is:
pathname size
where pathname
is the name of a partition, directory or file, and size
is the size of the named partition, directory or file (in bytes). You must specify a size for directories or files; size is optional for raw partitions.
You can use any partition of any size. For best performance:
Specify pathnames according to your operating system requirements. See the following examples. In the storage.config
file, a formatted or raw disk must be at least 128 MB.
The following basic example shows 64 MB of cache storage in the /big_dir directory:
/big_dir 67108864
You can use the .
symbol for the current directory. Here is an example for 64 MB of cache storage in the current directory:
. 67108864
The following example is for the Solaris operating system:
/devices/sbus@1f,0/SUNW,fas@e,880000/sd@2,0:a,raw
/devices/sbus@1f,0/SUNW,fas@e,880000/sd@2,0:b,raw
Note: Size is not required because the partitions are raw.
The following example is for the Linux operating system:
/dev/raw_sdb 9105018880
The update.config
file controls how Traffic Server performs a scheduled update of specific local cache content. The file contains a list of URLs specifying objects that you want to schedule for update.
A scheduled update performs a local HTTP GET
on the objects at the specific time or interval. You can control the following parameters for each specified object:
IMPORTANT: After you modify the update.config
file, navigate to the Traffic Server bin
directory and run the traffic_line -x
command to apply changes. When you apply changes to one node in a cluster, Traffic Server automatically applies the changes to all other nodes in the cluster.
Scheduled update supports the following tag/attribute pairs when performing recursive URL updates:
<a href=" ">
<img src=" ">
<img href=" ">
<body background=" ">
<frame src=" ">
<iframe src=" ">
<fig src=" ">
<overlay src=" ">
<applet code=" ">
<script src=" ">
<embed src=" ">
<bgsound src=" ">
<area href=" ">
<base href=" ">
<meta content=" ">
Scheduled update is designed to operate on URL sets consisting of hundreds of input URLs (expanded to thousands when recursive URLs are included); it is not intended to operate on extremely large URL sets, such as those used by Internet crawlers.
Each line in the update.config
file uses the following format:
URL\request_headers\offset_hour\interval\recursion_depth\
The following table describes each field.
Field |
Allowed Inputs |
---|---|
|
HTTP-based URLs. |
|
Optional. A list of headers (separated by semicolons) passed in each |
|
The base hour used to derive the update periods. The range is 00-23 hours. |
|
The interval (in seconds) at which updates should occur, starting at the offset hour. |
|
The depth to which referenced URLs are recursively updated, starting at the given URL. This field applies only to HTTP. |
The following example illustrates an HTTP scheduled update:
http://www.company.com\User-Agent: noname user agent\13\3600\5\
The example above specifies the URL and request headers, an offset hour of 13 (1 pm), an interval of one hour, and a recursion depth of 5. This would result in updates at 13:00, 14:00, 15:00, and so on. To schedule for an update to occur only once a day, use an interval value of 24 hours x 60 minutes x 60 seconds = 86400.
This section describes how to specify a url_regex
. Entries of type url_regex
within the configuration files use regular expressions to perform a match.
The following table provides examples to show how to create a valid url_regex
.
Value |
Description |
---|---|
|
Matches the character |
|
Match any character |
|
Specifies beginning of line |
|
Specifies end of line |
|
A character class. In this case, the pattern matches either |
|
A character class with a range. This pattern matches |
|
A negated character class. For example, this pattern matches any character except those in the class. |
|
Zero or more |
|
One or more |
|
Zero or one |
|
From two to five |
|
Two or more |
|
Exactly four |
|
The literal string |
|
If |
|
A |
|
The character with octal value |
|
The character with hexadecimal value |
|
Matches an |
|
The regular expression |
|
Either an |
|
Inserts an end node, which causes regular expression matching to stop when reached. The value |
You can specify dest_domain=mydomain.com
to match any host in mydomain.com
. Likewise, you can specify dest_domain=.
to match any request.