Applies To:
Show VersionsBIG-IP GTM
- 11.6.5, 11.6.4, 11.6.3, 11.6.2, 11.6.1, 11.5.10, 11.5.9, 11.5.8, 11.5.7, 11.5.6, 11.5.5, 11.5.4, 11.5.3, 11.5.2, 11.5.1
About listeners
A listener is a specialized virtual server that passively checks for DNS packets on port 53 and the IP address you assign to the listener. When a DNS query is sent to the IP address of the listener, BIG-IP GTM either handles the request locally or forwards the request to the appropriate resource.
How listeners process network traffic
You control how BIG-IP GTM responds to DNS queries on a per-listener basis. The number of listeners you create depends on your network configuration and the destinations to which you want to send specific queries. For example, a single BIG-IP GTM can be the primary authoritative server for one domain, while forwarding other DNSqueries to a different DNS server. BIG-IP GTM always manages and responds to DNS queries for the wide IPs that are configured on the system.
- Managing and responding to requests for two wide IPs configured on the external VLAN:
- www.siterequest.com
- downloads.siterequest.com
- Forwarding DNS traffic destined for a DNS server at IP address 10.2.5.37
In this scenario, BIG-IP GTM requires two listeners:
- A listener with an IP address that is on an external VLAN to manage DNS traffic destined for the wide IPs.
- A listener with the IP address of the local DNS server 10.2.5.37 to which the system can forward incoming traffic destined for that server.
About wildcard listeners
A wildcard listener is a special listener that is assigned an IP address of 0.0.0.0 and the DNS query port (port 53). When you want BIG-IP GTM to respond to DNS queries coming into your network, regardless of the destination IP address of the given request, you use a wildcard listener.
About Prober pools
A Prober pool is an ordered collection of one or more BIG-IP systems. BIG-IP Global Traffic Manager (GTM) can be a member of more than one Prober pool, and a Prober pool can be assigned to an individual server or a data center. When you assign a Prober pool to a data center, by default, the servers in that data center inherit that Prober pool.
The members of a Prober pool perform monitor probes of servers to gather data about the health and performance of the resources on the servers. BIG-IP GTM makes load balancing decisions based on the gathered data. If all of the members of a Prober pool are marked down, or if a server has no Prober pool assigned, BIG-IP GTM reverts to a default intelligent probing algorithm to gather data about the resources on the server.
This figure illustrates how Prober pools work. BIG-IP GTM contains two BIG-IP Local Traffic Manager (LTM) systems that are assigned Prober pools and one BIG-IP LTM system that is not assigned a Prober pool:
- Prober Pool 1 is assigned to a generic host server
- BIG-IP LTM3 is the only member of Prober Pool 1, and performs all HTTPS monitor probes of the server.
- Prober Pool 2 is assigned to generic load balancers
- BIG-IP LTM1 and BIG-IP LTM2 are members of Prober Pool 2. These two systems perform HTTP monitor probes of generic load balancers based on the load balancing method assigned to Prober Pool 2.
- The generic load balancers on the left side of the graphic are not assigned a Prober pool
- BIG-IP GTM can solicit any BIG-IP system to perform FTP monitor probes of these load balancers, including systems that are Prober pool members.
About Prober pool statistics
You can view the number of successful and failed probe requests that the BIG-IP GTM system (on which you are viewing statistics) made to the Prober pools. These statistics reflect only the number of Probe requests and their success or failure. These statistics do not reflect the actual probes that the pool members made to servers on your network.
Prober pool statistics are not aggregated among the BIG-IP GTM systems in a synchronization group. The statistics on one BIG-IP GTM include only the requests made from that BIG-IP GTM system.
In this figure, the Prober pool statistics that display on BIG-IP GTM1 are the probe requests made only by that system.
About Prober pool status
The status of a Prober pool also indicates the status of the members of the pool. If at least one member of a Prober pool has green status (Available), the Prober pool has green status.
The status of a Prober pool member indicates whether the BIG-IP GTM system, on which you are viewing status, can establish an iQuery connection with the member.
About probes
A probe is an action a BIG-IP system takes to acquire data from other network resources. BIG-IP Global Traffic Manager (GTM) uses probes to track the health and availability of network resources.
About GTM probes of an LDNS
BIG-IP Global Traffic Manager (GTM) is responsible for acquiring data from local DNS servers (LDNS) using probes. Unlike probes conducted on internal systems, such as web servers, probes of an LDNS require that BIG-IP GTM verifies data from a resource that exists outside the network. Typically, this data is the path information BIG-IP GTM requires when conducting Quality of Service, Round Trip Time, Completion Rate, and Hops load balancing methods.
The steps in the probe process
- An LDNS sends a DNS name resolution request to BIG-IP GTM for a wide IP.
- The specific BIG-IP GTM in a GTM synchronization group that is chosen to manage probing of a
resource creates an entry with a state of New (unless an entry for the LDNS already
exists).Note: Once a specific BIG-IP GTM system becomes responsible for managing the probing of a resource, that BIG-IP GTM maintains that responsibility until that GTM goes offline, a new BIG-IP GTM is added to the data center, or the configuration of the resource changes.
- The BIG-IP GTM that is responsible for managing the probing of the resource, delegates the
probe to a BIG-IP GTM that is currently responsible for conducting the fewest number of probes.
Note: BIG-IP GTM checks this statistic each time a probe of a specific resource is required; as a result, the BIG-IP GTM that probes the resource can change from one probe instance another.
- The big3d agent on the BIG-IP GTM that is delegated to probe the resource, sends a probe to the LDNS.
- The LDNS responds to the probe.
- BIG-IP GTM updates the LDNS entry, assigning it an Active state.
- The big3d agent then broadcasts the results of the probe to all BIG-IP GTM systems in the GTM synchronization group.
Converting a statistics collection server to a Prober pool automatically
In version 10.2 of BIG-IP Global Traffic Manager (GTM), you could assign a single BIG-IP system to probe a server to gather health and performance data. You did this by specifying the IP address of the BIG-IP system (which you chose to perform probes of the server) in the Statistics Collection Server field of the server. In version 11.0, this feature was replaced by the Prober pool feature.
When you upgrade from version 10.2.x to version 11.x, if a single BIG-IP system was assigned to probe a server, BIG-IP GTM converts the single server to a Prober pool with one member, and then assigns the Prober pool to the server to which the Statistics Collection server was originally assigned. The name of the new Prober pool is based on the IP address of the original Statistics Collection server. If the original Statistics Collection server had an IP address of 10.10.2.3, the name of the automatically created Prober pool is prober_pool_10_10_2_3.
About delegation of LDNS probes
By default, BIG-IP GTM delegates the probe of a resource to a BIG-IP GTM that is in the same data center as the resource, because the close proximity improves probe response time. However, when more than one BIG-IP GTM in a GTM synchronization group resides in the same data center, an algorithm is used to delegate the probes of resources equally among those BIG-IP GTM systems. This ensures that no BIG-IP GTM becomes overloaded with conducting probes, which can cause a decrease in the performance of the other tasks for which the BIG-IP system is responsible. When a data center does not contain a BIG-IP GTM, an algorithm is used to distribute the actual probes of a resource in that data center equally among the BIG-IP GTM systems in the synchronization group.
About LDNS entries on a GTM
An LDNS entry can be in one of three states: New, Pending, or Active. In general, the New and Pending states are temporary. An LDNS entry remains in one of these states only until the LDNS responds to the first probe request from a BIG-IP GTM.
- New
- This LDNS has not contacted BIG-IP GTM before.
- Pending
- This LDNS has contacted BIG-IP GTM before; however, this LDNS has yet to respond to a probe.
- Active
- BIG-IP GTM has an entry for this LDNS.
Protocols and ports used by big3d during communications with local DNS servers
This table describes the protocols and ports the big3d agent uses to communicate with an LDNS when collecting path data for the local DNS servers.
From | To | Protocol | From port | To port | Purpose |
---|---|---|---|---|---|
big3d agent | LDNS | ICMP | n/a | n/a | Probe using ICMP pings |
big3d agent | LDNS | TCP | >1023 | 53 | Probe using TCP (Cisco routers: allow establish) |
LDNS | big3d agent | TCP | 53 | 1023 | Replies using TCP (Cisco routers: allow establish) |
big3d agent | LDNS | UDP | 53 | 33434 | Probe using UDP or the traceroute utility |
LDNS | big3d agent | ICMP | n/a | n/a | Replies to ICMP, UDP pings, or traceroute utility probes |
big3d agent | LDNS | dns_rev, dns_dot | >1023 | 53 | Probe using DNS rev or DNS dot |
big3d agent | LDNS | dns_rev, dns_dot | 53 | >1023 | Replies to DNS rev or DNS dot probes |
About wide IPs
A wide IP maps a fully-qualified domain name (FQDN) to one or more pools of virtual servers that host the content of a domain. When an LDNS issues a DNS name resolution for a wide IP, the configuration of the wide IP indicates which pools of virtual servers are eligible to respond to the request, and which load balancing methods BIG-IP GTM uses to select the pool.
About wildcard characters in wide IP names
BIG-IP Global Traffic Manager (GTM) supports these wildcard characters in wide IP names and aliases:
- Question mark (?)
- Use to replace a single character, except a dot (.).
- Asterisk (*)
- Use to replace multiple consecutive characters with the exception of dots (.)
You can use one or more question marks or asterisks, or both question marks and asterisks in a wide IP name or alias.
- ???.mydomain.net
- www.??.domain.net
- www.my*.net
- www.??*.net
- www.my*.*
- ???.my*.*
- *.*.net
- www.*.??
Using wildcard characters in wide IPs to minimize maintenance tasks
About persistence connections
Most load balancing methods divide DNS name resolution requests among available pools or virtual servers. Each time BIG-IP GTM receives a request, it sends that request to the most appropriate resource based on the configuration of your network.
For example, when a user visits a web site, multiple DNS name resolution requests are generated as the user moves from page to page. Depending on the load balancing method configured, BIG-IP GTM sends each request to a different server, virtual server, or data center. In certain circumstances, you might want to ensure that a user remains with a given set of resources throughout the session. For example, a user attempting to conduct on online banking transaction needs to remain with the same set of resources to ensure that the transaction is completed successfully.
Configuring GTM for persistent connections
About wide IPs and a last resort pool
BIG-IP Global Traffic Manager (GTM) considers any pool associated with a wide IP as a potential resource to which to load balance DNS name resolution requests. A last resort pool is a pool of virtual servers to which BIG-IP GTM sends DNS name resolution requests in the event that all other pools associated with the wide IP are unavailable. When you design your network, ensure that this particular pool is kept in reserve and not used as part of the normal global server load balancing.
Configuring a wide IP with a last resort pool
About data centers
All of the resources on your network are associated with a data center. BIG-IP Global Traffic Manager (GTM) consolidates the paths and metrics data collected from the servers, virtual servers, and links in the data center. GTM uses that data to conduct load balancing and route client requests to the best-performing resource based on different factors.
GTM might send all requests to one data center when another data center is down. Alternatively, GTM might send a request to the data center that has the fastest response time. A third option might be for GTM to send a request to the data center that is located closest to the client's source address.
About servers
A server defines a physical system on the network. Servers contain the virtual servers that are the ultimate destinations of DNS name resolution requests. BIG-IP Global Traffic Manager (GTM) supports three types of server,s as shown in the table.
- BIG-IP systems
- Any member of the BIG-IP system product line.
- Third-party load balancing systems
- A third-party load balancing system is any system, other than a BIG-IP system, that supports and manages virtual servers on the network.
- Third-party host servers
- A third-party host server is a resource to which the BIG-IP system load balances DNS traffic, for example, a web server, file server, or SQL server.
About third-party host servers
A host is a network resource that is not a part of the BIG-IP product family and does not provide load balancing. BIG-IP Global Traffic Manager (GTM) supports these host servers:
- CacheFlow
- NetApp
- Sun Solaris
- Windows 2000 Server (You can monitor the Windows Vista Enterprise Server using the Windows 2000 Server.)
- Windows NT 4.0
About third-party load balancing servers
BIG-IP Global Traffic Manager (GTM) interacts with other load balancing servers to determine availability and assess performance when responding to DNS name resolution requests. BIG-IP GTM supports these load balancing servers:
- Alteon Ace Director
- Cisco CSS
- Cisco LocalDirector v2
- Cisco LocadDirector v3
- Cisco SLB
- Extreme
- Foundry ServerIron
- Radware WSD
- Other generic load balancers
About virtual servers
A virtual server is a specific IP address and port number that points to a resource on the network. In the case of host servers, this IP address and port number likely point to the resource itself. With load balancing systems, virtual servers are often proxies that allow the load balancing server to manage a resource request across a multitude of resources.
Configuring virtual server availability to be dependent on the status of other virtual servers
Configuring virtual server status for clusters
About pools and pool members
A pool is a collection of virtual servers that can reside on multiple servers. A virtual server is a combination of IP address and port number that points to a specific resource on the network. When you add a virtual server to a pool, it becomes a pool member. A pool member is a virtual server that has attributes that pertain to the virtual server only in the context of the pool. A virtual server can be a member of multiple pools and have different attributes in each pool. BIG-IP Global Traffic Manager (GTM) directs traffic to a pool member, based on the attributes of the pool member.
About links
A link is a logical representation of a physical device (router) that connects your network to the Internet. BIG-IP Global Traffic Manager (GTM) tracks the performance of links, which influence the availability of pools, data centers, wide IPs, and distributed applications.
Defining a link
Ensure that at least one data center exists in the configuration.
Gather information about the routers that you want to define as links, including:
- IP addresses
- Data center location
Load balancing outbound traffic through links of differing bandwidths
Ensure that at least one data center exists in the configuration.
Gather the following information about the routers that you want to define as links:
- IP addresses
- Data Center location
Load balancing outbound traffic over the least expensive link first
Ensure that at least one data center exists in the configuration.
Gather the following information about the routers that you want to define as links:
- IP addresses
- Data Center location
About distributed applications
A distributed application is a collection of one or more wide IPs, data centers, and links that serve as a single application to a web site visitor. Configuring a distributed application provides several advantages:
- You can organize logical network components into groups that represent a business environment.
- You can configure a distributed application to be dependent upon the availability of a data center, server, or link. This dependency ensures that a user cannot access a distributed application when a portion of the resources are unavailable.
- You can define persistence for the distributed application, ensuring that a user, who accesses the distributed application uses the same resources during a single session.
If the New York data center goes offline, a wide IP in that data center becomes unavailable. A distributed application associated with that wide IP also becomes unavailable. Consequently, the system does not send resolution requests to any of the distributed application resources, until the entire application becomes available again.
About ZoneRunner
You can use the ZoneRunner utility to create and manage DNS zone files and configure the BIND instance on BIG-IP Global Traffic Manager (GTM). With the ZoneRunner utility, you can:
- Import and transfer DNS zone files
- Manage zone resource records
- Manage views
- Manage a local nameserver and the associated configuration file, named.conf
- Transfer zone files to a nameserver
- Import only primary zone files from a nameserver
About named.conf
named.conf contains the primary operational characteristics of BIND, including DNS views, access control list definitions, and zones. The ZoneRunner utility updates named.conf when you modify the local BIND instance.
Using ZoneRunner to configure named.conf
Creating a hint zone
Create a zone when you want to use ZoneRunner to manage DNS zones and resource records.
Configuring GTM to allow zone file transfers
The command should return a response similar to this:
; <<>> DiG? 9.5.0-P2 <<>> @192.17.1.253 es.net. axfr ; (1 server found) ;; global options: printcmd es.net. 500 IN SOA siterequest.com. hostmaster.siterequest.com. 6 10800 3600 604800 60 es.net. 500 IN NS siterequest.com. a.es.net. 30 IN A 192.17.1.100 b.es.net. 30 IN A 192.18.1.100 es.net. 500 IN SOA siterequest.com. hostmaster.siterequest.com. 6 10800 3600 604800 60 ;; Query time: 6 msec ;; SERVER: 192.17.1.253#53(192.17.1.253) ;; WHEN: Fri Mar 11 17:20:25 2011 ;; XFR size: 5 records (messages 1, bytes 180)About DNS views
A DNS view is a modification of a nameserver configuration based on the community attempting to access it. Using views, you can build multiple nameserver configurations on the same server, and have those configurations apply dynamically when the request originates from a specified source.
If your DNS handles requests from both inside and outside your company, you can create two views: internal and external.
Types of DNS zone files
This table describes the types of DNS zone files.
DNS file type | Description |
---|---|
Primary | Zone files for a primary zone contain, at minimum, the start of authority (SOA) and nameserver (NS) resource records for the zone. Primary zones are authoritative, that is, they respond to DNS queries for the domain or sub-domain. A zone can have only one SOA record, and must have at least one NS record. |
Secondary | Zone files for a secondary zone are copies of the principal zone files. At an interval specified in the SOA record, secondary zones query the primary zone to check for and obtain updated zone data. A secondary zone responds authoritatively for the zone provided that the zone data is valid. |
Stub | Stub zones are similar to secondary zones, except that stub zones contain only the NS records for the zone. Note that stub zones are a specific feature of the BIND implementation of DNS. F5 Networks recommends that you use stub zones only if you have a specific requirement for this functionality. |
Forward | The zone file for a forwarding zone contains only information to forward DNS queries to another nameserver on a per-zone (or per-domain) basis. |
Hint | The zone file for a hint zone specifies an initial set of root nameservers for the zone. Whenever the local nameserver starts, it queries a root nameserver in the hint zone file to obtain the most recent list of root nameservers. Zone file import. |
Types of DNS resource records
This table describes the types of DNS resource records that ZoneRunner supports.
DNS file type | Description |
---|---|
SOA (Start of authority) | The start of authority resource record, SOA, starts every zone file and indicates that a nameserver is the best source of information for a particular zone. The SOA record indicates that a nameserver is authoritative for a zone. There must be exactly one SOA record per zone. Unlike other resource records, you create a SOA record only when you create a new master zone file. |
A (Address) | The Address record, or A record, lists the IP address for a given host name. The name field is the host’s name, and the address is the network interface address. There should be one A record for each IP address of the machine. |
AAAA (IPv6 Address) | The IPv6 Address record, or AAAA record, lists the 128-bit IPv6 address for a given host name. |
CNAME (Canonical Name) | The Canonical Name resource record, CNAME, specifies an alias or nickname for the official, or canonical, host name. This record must be the only one associated with the alias name. It is usually easier to supply one A record for a given address and use CNAME records to define alias host names for that address. |
DNAME (Delegation of Reverse Name) | The Delegation of Reverse Name resource record, DNAME, specifies the reverse lookup of an IPv6 address. These records substitute the suffix of one domain name with another. The DNAME record instructs Global Traffic Manager (GTM) (or any DNS server) to build an alias that substitutes a portion of the requested IP address with the data stored in the DNAME record. |
HINFO (Host Information) | The Host Information resource record, HINFO, contains information on the hardware and operating system relevant to Global Traffic Manager (or other DNS). |
MX (Mail Exchanger) | The Mail Exchange resource record, MX, defines the mail system(s) for a given domain. |
NS (nameserver) | The nameserver resource record, NS, defines the nameservers for a given domain, creating a delegation point and a subzone. The first name field specifies the zone that is served by the nameserver that is specified in the nameservers name field. Every zone needs at least one nameserver. |
PTR (Pointer) | A name pointer resource record, PTR, associates a host name with a given IP address. These records are used for reverse name lookups. |
SRV (Service) | The Service resource record (SRV) is a pointer with which an alias for a given service is redirected to another domain. For example, if the fictional company Site Request has an FTP archive hosted on archive.siterequest.com, the IT department can create an SRV record with which the alias ftp.siterequest.com is redirected to archive.siterequest.com. |
TXT (Text) | The Text resource record, TXT, allows you to supply any string of information, such as the location of a server or any other relevant information that you want available. |
About DNSSEC
Domain Name System Security Extensions (DNSSEC) is an industry-standard protocol that functions as an extension to the Domain Name System (DNS) protocol. BIG-IP Global Traffic Manager (GTM) uses DNSSEC to guarantee the authenticity of DNS responses, including zone transfers, and to return Denial of Existence responses thus protecting your network against DNS protocol and DNS server attacks.
About DNSSEC keys
BIG-IP Global Traffic Manager (GTM) uses two types of DNSSEC keys to return DNSSEC-compliant responses: a zone-signing key to sign all of the records in a DNSSEC resource record set, and a key-signing key to sign only the DNSKEY record (that is the zone-signing key) of a DNSSEC record set.
About enhancing DNSSEC key security
To enhance DNSSEC key security, when automatic key management is configured, BIG-IP Global Traffic Manager (GTM) uses an automatic key rollover process that uses overlapping generations of a key to ensure that BIG-IP GTM can always respond to queries with DNSSEC-compliant responses. BIG-IP GTM dynamically creates new generations of each key based on the values of the Rollover Period and Expiration Period of the key.
The first generation of a key has an ID of 0 (zero). Each time BIG-IP GTM dynamically creates a new generation of a key, the ID increments by one. Over time, each generation of a key overlaps the previous generation of the key ensuring that GTM can respond to a DNSSEC query even if one generation of a key becomes unavailable. When a generation of a key expires, BIG-IP GTM automatically removes that generation of the key from the configuration. The value of the TTL (time-to-live) of a key specifies how long a client resolver can cache the key.
Protocols supported by the BIG-IP system
This table describes the protocols supported by the BIG-IP system.
Protocol | Description |
---|---|
iQuery protocol | The gtmd agent on BIG-IP Global Traffic Manager (GTM) uses iQuery to communicate with the local big3d agent and the big3d agents installed on other BIG-IP systems. |
DNS | BIG-IP supports the Domain Name System (DNS) for distribution of DNS name resolution requests from clients and their local DNS servers to resources on your global network. |
DNSSEC | BIG-IP GTM supports the DNS Security Extensions for secure zone signing and authentication of DNS responses. |
HTTPS | BIG-IP supports Hypertext Transfer Protocol Secure (HTTPS) for secure web browsing. |
SSL | The web server, which hosts the web-based Configuration utility, supports Secure Sockets Layer (SSL) connections as well as user authentication. |
SNMP | BIG-IP supports the Simple Network Management Protocol (SNMP) for monitoring network resources. |
SMTP | BIG-IP supports the Simple Mail Transfer Protocol (SMTP) for email transmission across the Internet. |
SSH | BIG-IP supports Secure Shell (SSH) administrative connections for remote administration from the command line. |
TCP wrappers | BIG-IP supports the use of TCP wrappers to provide an extra layer of security for network connections. |
FTP | BIG-IP supports the File Transfer Protocol (FTP) for secure access to BIG-IP system software downloads from a web server. |