Gtm Student Guide
Related PDF: Ccma Study Guide 2017, Yamaha Fjr 1300 2016 Service Manual, Lippincott Nursing Manual, York Affinity 8 V Series Installation Manual, Organic Chemistry Solutions Manual By Janice Smith, Bennett Ventilator.
F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 5 Overview Welcome to the 302 - F5 Certified Technology Specialist, GTM compiled Study Guide. The purpose of this guide is to help you prepare for the 302 - F5 Certified Technology Specialist, GTM exam. The contents of this document are based on the 302 - F5 Certified Technology Specialist, GTM Blueprint. This study guide provides students with some of the basic foundational knowledge required to pass the exam.
This study guide is a collection of information and therefore not a completely original work. The majority of the information is compiled from F5 sources that are located on the Internet.
All of the information locations are referenced at the top of each topic instead of in an Appendix of this document. This was done to help the reader access the referenced information easier without having to search through a formal appendix. This guide also references the same books as the exam Resource Guide for each topic when applicable for consistency. Those books are a great source of information on DNS and Global Traffic Manger (GTM).
F5 Networks provides the 302 - F5 Certified Technology Specialist, GTM Study Guide as a resource. The Study Guide is a list of reading material that will help any student build a broad base of general knowledge that can assist in not only their exam success but also in becoming a well-rounded systems engineer. The Study Guide will be available to the candidate once they are qualified for the GTM Specialist exam. Taking certified F5 GTM training, such as Configuring BIG-IP GTM v11: Global Traffic Manager, will surely help with the topics of this exam but does not teach directly to the exam content. Hands on administrative experience with the BIG-IP platform licensed with GTM will reinforce many of the topics contained in the 302 - F5 Certified Technology Specialist, GTM exam. The F5 Certified BIG-IP Administrator (F5-CA), which is made up of the 101 - Application Delivery Fundamentals and 201 - TMOS Administration exams, stand as a pre-requisite to this exam.
This guide was prepared by an F5 employee but is not an official F5 document and is not supported by F5 Networks. Reading = Knowledge = Power Printed References These referenced books are and important and should be considered basic reading material for this exam. (Ref:1) Kozierok, Charles M. The TCP/IP Guide.
No Starch Press, Inc. San Francisco, CA. ISBN 1-59327-047-X pp 947 -1080. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 6 (Ref:2) Liu, Cricket and Albitz, Paul. DNS and BIND, Fifth Edition. O’Reilly Media, Inc.
Sebastopol, CA. ISBN 978-0-596-10057-5 (Ref:3) Configuring GTM v11 Global Traffic Manager. March 2013 v11.3.0.
F5 Networks Training Course. (Configuring GTM: Module X) Introduction Global Traffic Manager Introduction The F5 BIG-IP Global Traffic Manager (GTM) system intelligently resolves names into IP addresses providing intelligent wide area application traffic management and high availability of IP applications/services running across multiple data centers. GTM adds intelligence to DNS. Mastering GTM requires an in-depth knowledge of DNS. Much of this study guide will refer to the basic workings and functional pieces of DNS.
Although the Exam Blueprint is not written in a structure that presents topics in an educational order, it does provide all of the necessary building blocks. The Certified GTM training class from F5 will help with many of the scenario based topics on the test. Objective - 1.01 - Identify resource record types and their purpose including DNSSEC record types 1.01 – Identify resource record types and their purpose Resource Records Resource records are the files that contain details about a zone. These resource records, in a hierarchical structure, make up the domain name system (DNS).
Note: Although case is preserved in names and data fields when loaded into the name server, comparisons and lookups in the name server database are not case-sensitive. The following resource records types are the most common although there are others: SOA (Start of authority) The start of authority resource record, SOA, starts every zone file and indicates that a name server is the best source of information for a particular zone. The SOA record indicates that a name server 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. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 7 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 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 GTM (or other DNS). MX (Mail Exchanger) The Mail Exchange resource record, MX, defines the mail system(s) for a given domain. NS (Name Server) The name server resource record, NS, defines the name servers for a given domain, creating a delegation point and a subzone. The first name field specifies the zone that is served by the name server that is specified in the name servers name field. Every zone needs at least one name server.
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 that allows an alias for a given service to be redirected to another domain. For example, if the fictional company Site Request had an FTP archive hosted on archive. Siterequest.com, the IT department can create an SRV record that allows an alias, ftp.siterequest.com to be redirected to archive.siterequest.com. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 8 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.
The following resource record types are associated with DNSSEC: DNSKEY These records contain the public key for the zone. They come in two flavors, a Zone Signing Key (ZSK) and a Key Signing Key (KSK). Generally, the KSK signs only certain records within the zone, while the ZSK signs all of the records. You may have as many of each as required for key-rollover protocols or for your needs. RRSIG – Resource Record Signature These records hold the signatures for a specific record type. For instance, you will see an RRSIG for NS records, one for DNSKEY records, etc. One RRSIG record will be generated per ZSK, typically, and for certain records one for each KSK as well.
Note: there is one signature per-key per-RRSET, not per RR. NSEC – Next Secure This record is used in “negative answers” to prove that a name does not exist. Each name in a zone has an NSEC record added when signed to allow both positive (this name exists) answers and negative answers (this name does not exist) to be cryptographically secure. NSEC3 – Next Secure (version 3) This record is used in “negative answers” to prove that a name does not exist.
It is similar in function to the NSEC record, but has some advantages in certain situations. Zones signed with NSEC are “walkable.” This means the entire contents of a zone can be retrieved simply by following the NSEC chain. Also, every name within a zone must be signed and have NSEC records.
NSEC3 uses cryptographic hashes to prevent zone walking while retaining the ability to prove negative answers. It also allows for an opt-out signing method where only certain names within a zone are signed.
For very large zones this opt-out is useful. DS – Delegation Signer These are records that are submitted to your zone’s parent. They are included only in the parent, and correspond to NS records in that they provide a link between your parent and your zone.
They are part of the DNSSEC chain of trust from your zone’s parent to your zone. Because many parent zones are not yet signed, DLV may be used to provide others with a trusted relationship to your zone when your parent is not signed or not prepared to accept DS record submissions. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 9 DLV – DNSSEC Look-aside Validation These records are in most ways identical to DS records. The only difference is the name on the DLV record. A DS record has your zone’s name (example.com) while a DLV record has an additional name (example.com. Dlv.isc.org.) 1.01 – Identify DNSSEC purpose and GTM implementation About DNSSEC What it is: Domain Name System Security Extensions (DNSSEC) is an industry-standard protocol that functions as an extension to the Domain Name System (DNS) protocol.
GTM uses DNSSEC to guarantee the authenticity of DNS responses and to return Denial of Existence responses thus protecting your network against DNS protocol and DNS server attacks. DNSSEC Keys and Zones How it works: DNSSEC keys and zones GTM responds to DNS requests to a specific zone by returning signed name server responses based on the currently available generations of a key. Before you can configure GTM to handle name server responses that are DNSSEC-compliant, you must create DNSSEC keys and zones.
There are two kinds of DNSSEC keys: zone-signing keys and key-signing keys. GTM uses a zone-signing key to sign all of the records in a DNSSEC record set, and a key-signing key to sign only the DNSKEY record of a DNSSEC record set. F5 Networks recommends that for emergency rollover purposes, when you create a key, you create a duplicate version of the key with a similar name, but do not enable that version. For example, create a key-signing key called ksk1a that is enabled. Then create a duplicate key, but name it ksk1b, and change the state to disabled. When you associate both of these keys with the same zone, you are prepared to easily perform a manual rollover of the key, if necessary.
In order for GTM to use the keys that you create to sign requests, you must assign the keys to a zone. DNSSEC zones are containers that map a domain name to a set of DNSSEC keys that the system uses to sign DNSSEC-compliant name server responses to DNS queries. When you create a DNSSEC zone, you must assign at least one enabled zone-signing and one enabled key-signing key to the zone before the GTM can sign requests to that zone.
F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 10 Additionally, after you create a DNSSEC zone, you must submit the DS record for the zone to the administrators of your parent zone, who sign the DS record with their own key and upload it to their zone. You can find the DS record for your zone in /config/gtm/dsset. Automatic key rollover To enhance key security, the BIG-IP system has an automatic key rollover feature that uses overlapping generations of a key to ensure that the system can always respond to requests with a signature. The system dynamically creates new generations of each key based on the values of the Rollover Period and Expiration Period settings of the key. The first generation of a key has an ID of 0 (zero).
Each time the system dynamically creates a new generation of the key, the ID increments by 1. When a generation of a key expires, the system automatically removes that generation of the key from the configuration. The following diagram illustrates this, and shows how over time each generation of a key overlaps the previous generation of the key. Overlapping generations of a key and TTL value The value that you assign to the TTL (time-to-live) setting for a key specifies how long a client resolver can cache the key. As shown in the figure, the value you assign to the TTL setting of the key must be less than the difference between the values of the Rollover Period and Expiration Period settings of the key; otherwise, a client can make a query and the system can send a valid key that the client cannot recognize. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 11 Important: To ensure that each GTM system is referencing the same time when generating keys, you must synchronize the time setting on each system with the Network Time Protocol (NTP) servers that GTM references. Providing DS records to the parent domain Each time a new generation of a key-signing key is created, you must provide the updated DS record to the administrators of the parent zone.
For example, in Figure 10.1, the value of the Rollover Period of the key is 30 days, and the value of the Expiration Period of the key is 37 days. In the case of a key-signing key, a new generation of the key is created every 30 days, and you have seven days before the old generation of the key expires to provide the new DS record to the administrators of the parent zone. These administrators sign the new DS record with their own key and upload it their zone.
There are numerous ways to provide the new DS record to the administrators of the parent zone, including secure FTP or use of a secure web site for this purpose. Provide the new DS record to the administrators of the parent zone according to your company policy.
DNSSEC resource records Your configuration of BIND is independent of the configuration of DNSSEC on GTM. If you want to use BIND for delegation or other tasks, you must add the DNSSEC resource records to your BIND configuration; otherwise, BIND is not aware of these records. If you do this, you can view the DNSSEC resource records in Zone Runner. Configuring DNSSEC GTM Implementation: You can use GTM to ensure that all responses to DNS-related traffic comply with the DNSSEC security protocol. To configure DNSSEC compliance, you create DNSSEC key-signing and zone-signing keys and a DNSSEC zone.
Then you assign at least one enabled key-signing key and one enabled zone-signing key to the zone. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 12 Traffic flow when GTM is the DNSSEC authoritative name server Deploying the BIG-IP GTM for DNSSEC Objective - 1.02 - Identify the different zone types and their purpose 1.02 - Identify the different types of zones (Master, Slaves, Hint, Root, Stub) ZoneRunner Zone Types and their Description Primary (Master) - Zone files for a primary zone contain, at minimum, the start of authority (SOA) and name server (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.
F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 13 Secondary (Slave) - 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 name server on a per-zone (or per-domain) basis. Hint - The zone file for a hint zone specifies an initial set of root name servers for the zone.
Whenever the local name server starts, it queries a root name server in the hint zone file to obtain the most recent list of root name servers. Root - The DNS root zone is the top-level DNS zone in the hierarchical namespace of the Domain Name System (DNS) of the Internet. Every name resolution either starts with a query to a root server, or, uses information that was once obtained from a root server.
Even if the IP addresses of some root servers change over the years, at least one is needed to retrieve the current list of all name servers. This address file is called named.cache in the BIND name server reference implementation. Objective - 1.03 - Explain the purpose of tools and when to use them 1.03 - Explain the purpose of tools and when to use them, specifically nslookup, dig, named-checkzone, rndc Using NSlookup.exe DNS Tools nslookup - nslookup is a tool for querying the Domain Name System (DNS) to obtain domain name or IP address mapping or for any other specific DNS record.
Dig – dig is a tool for querying the Domain Name System (DNS) to obtain domain name or IP address mapping or for any other specific DNS record. Dig is part of the BIND domain name server software suite and is available on most linux-based systems. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 14 named-checkzone(8) - Linux man page named-checkzone – named-checkzone checks the syntax and integrity of a zone file. It performs the same checks as named does when loading a zone.
This makes named-checkzone useful for checking zone files before configuring them into a name server. Named-checkzone(8) - Linux man page named-compilezone - named-compilezone is similar to named-checkzone, but it always dumps the zone contents to a specified file in a specified format. Additionally, it applies stricter check levels by default, since the dump output will be used as an actual zone file loaded by named. When manually specified otherwise, the check levels must at least be as strict as those specified in the named configuration file. Red Hat Enterprise Linux 3: Reference Guide rndc - BIND includes a utility called rndc which allows command line administration of the named daemon from the localhost or a remote host.
Rndc controls the operation of a name server. It supersedes the ndc utility that was provided in old BIND releases. If rndc is invoked with no command line options or arguments, it prints a short summary of the supported commands and the available options and their arguments. Rndc reads a configuration file to determine how to contact the name server and decide what algorithm and key it should use.
Objective - 1.04 - Explain the dataflow of the DNS query process iterative, recursive, lame delegation, host file, and resolvers 1.04 - Explain the dataflow of the DNS query process Ref: 1, pp. DNS query process The client system is trying to connect to a remote system via a fully qualified host name; an example would a browser connection to www.google.com. The client system will try to resolve the name www.google.com to an IP address. The following steps will explain the resolution process.
The client system checks its cache to see if it has an address for this name. If it does it will connect to that address. If not the system will proceed to step 2. It could have entries in its cache in two ways. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 15. A host file resource record entry. Resource records obtained in answered responses from previous DNS queries 2.
The client checks its local host file for the name. If there is a match; it resolves the name using this information. If there is no match in the file; the system will proceed to step 3. The client makes a recursive query to its defined local DNS server. The local DNS server receives the request and checks its cache. If it has a matching entry it will return the record info to the client. If there is no match in the local DNS server’s cache; the local DNS server will proceed to step 4.
The local DNS server generates an iterative request for the name and sends it to a root name server. The root name server does not resolve the name. It returns the name and address of the name server for the “.com” domain. The local DNS server generates an iterative request and sends it to the name server for “.com”. The name server for “.com” returns the name and address of the name server for the “google.com” domain. The local DNS server generates an iterative request and sends it to the name server for “google.com”.
The name server for “google.com” is authoritative for “www.google.com”. It returns the IP address for that host to the local DNS server. The local DNS server caches this resolution.
(Note: that it will probably also cache some of the other name server resolutions that it received in steps #6, #8 and possible others if there were sub domain requests involved.) 12. The local DNS server returns the name resolution to the client. The client caches the information.
Your browser commences an HTTP request to the www.google.com machine’s IP address. What Is a Lame Delegation or Lame Response? How Do I Fix It?
Lame Delegation or Lame Response When performing recursion, the process of looking up a record from the DNS, a name server must generally query several servers, follow up on referrals, and walk down the chain of authority to find the answer. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 16 For each query, the recursing name server expects the other name server to be authoritative for a given zone. For example, the root servers are expected to be authoritative for the root zone. The root servers give out a referral for.com, pointing to a set of servers; any such server is expected to be authoritative for com. The expected authority can be obtained either from a referral for that zone from a parent zone, or from the authority records returned by another authoritative name server for the zone. If a query is answered in a way that indicates that the responder is not authoritative for the expected zone, the result is called lame. Since the response is almost always in the form of a referral (a delegation response) for either some zone higher up on the tree or for the expected zone itself, the response can be called a lame delegation or lame referral.
1.04 - Explain recursive versus iterative Recursive and Iterative Queries Recursive vs. Iterative With a recursive name query, the DNS client requires that the DNS server respond to the client with either the requested resource record or an error message stating that the record or domain name does not exist. The DNS server cannot just refer the DNS client to a different DNS server. Thus, if a DNS server does not have the requested information when it receives a recursive query, it queries other servers until it gets the information, or until the name query fails. A DNS client generally makes recursive name queries to a DNS server, or by a DNS server that is configured to pass unresolved name queries to another DNS server, in the case of a DNS server configured to use a forwarder. An iterative name query is one in which a DNS client allows the DNS server to return the best answer it can give based on its cache or zone data. If the queried DNS server does not have an exact match for the queried name, the best possible information it can return is a referral (that is, a pointer to a DNS server authoritative for a lower level of the domain namespace).
The DNS client can then query the DNS server for which it obtained a referral. It continues this process until it locates a DNS server that is authoritative for the queried name, or until an error or time-out condition is met. Enabling DNS Recursion in the Named Configuration on a BIG-IP GTM System GTM Configuration When a DNS server sets the recursion available (RA) bit in a DNS response, the DNS server is indicating to the client that it will query other name servers for requested domain names if the DNS server’s zone files do not contain the answer. By default, DNS recursion is disabled on GTM systems.
Under certain circumstances, you may want to enable DNS recursion on the GTM system. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 18 Transport has to do with how the requesting (resolving) server sends the request to a DNS server and if that DNS serve supports the IP protocol that the requesting server understands (IPv4 or IPv6). If DNS server does not support the IP protocol that the requesting is able to process the request will fail or if it is referred to another name server that does not support that IP protocol the request will fail. To fix the issue the requesting server will have to use a DNS server that has a “dual stack” (supports IPv4 and IPv6) to act as a translator and be a “forwarder” (make the request for the requesting server). Objective - 1.06 - Given a DNS hierarchical diagram determine what source IP the GTM will receive the query from 1.06 - Given a DNS hierarchical diagram determine what source IP the GTM will receive the query from Diagram Based Questions This topic is focused on applying the knowledge you know of the DNS query process. Knowing the process described in section 1.04 will give the candidate the ability to answer the questions on this topic.
All F5 exams use diagram-based questions that make the candidate apply what they know to a situation to determine the resulting outcome. An example of a DNS request environment will be presented and you will need to understand how to overlay the steps described in section 1.04 to the diagram to see which system is actually making the DNS request to the GTM system. The following diagram shows an example of a diagram with the overlaid request process. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 20 About Detecting and Protecting Against DoS DDoS and DNS Service Attacks Denial of Service (DoS) DoS and DDoS attacks Denial of service (DoS) and distributed denial of service (DDoS) attacks attempt to render a machine or network resources unavailable to users. Denial of service attacks require the efforts of one or more people to disrupt the services of a host connected to the Internet.
The Advanced Firewall Module allows you to configure packet limits, percentage increase thresholds, and absolute rate limits for a wide variety of packets that attackers leverage as attack vectors, to detect and prevent attacks of this type. DNS flood (DoS) attacks Denial of service (DoS) or flood attacks attempt to overwhelm a system by sending thousands of requests that are either malformed or simply attempt to overwhelm a system using a particular DNS query type or protocol extension. The BIG-IP system allows you to track such attacks.
Malformed DNS packets Malformed DNS packets can be used to consume processing power on the BIG-IP system, ultimately causing slowdowns like a DNS flood. The BIG-IP system drops malformed DNS packets, and allows you to configure how you track such attacks. Protocol exploits Attackers can send DNS requests using unusual DNS query types or opcodes. The BIG-IP system can be configured to allow or deny certain DNS query types, and to deny specific DNS opcodes. When you configure the system to deny such protocol exploits, the system tracks these events as attacks. It’s DNSSEC Not DNSSUX DNSSEC DNSSEC is a suite of extensions that add security to the DNS protocol by enabling responses to be validated.
The premise behind DNSSEC is that responses to DNS queries need to be trustable. DNSSEC applies the principle of signatures via public/private key encryption as a means to achieve that trust.
Essentially DNSSEC is the wrapping of the DNS infrastructure within a trusted, PKI-based superstructure that validates through certificates managed records (zones). Configuring IP Anycast Route Health Injection AnyCast IP Anycast for DNS services on the BIG-IP system to help mitigate distributed denial-of-service attacks (DDoS), reduce DNS latency, improve the scalability of your network, and assist with traffic management. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 21 This configuration adds routes to and removes routes from the routing table based on availability.
Advertising routes to virtual addresses based on the status of attached listeners is known as Route Health Injection (RHI). BIG-IP GTM Datasheet DNSFirewall A DNS firewall shields DNS infrastructure from attacks such as reflection or amplification DDoS attacks and other undesired DNS queries and responses that reduce DNS performance.
In addition, you can mitigate complex DNS security threats by blocking access to malicious IP domains with Response Policy Zones. With GTM, you can install a third-party domain filtering service such as SURBL or Spamhaus and prevent client infection or intercept infected responses to known sources of malware and viruses. F5 DNS firewall services reduce the costs of infection resolution and increase user productivity.
The BIG-IP GTM: Configuring DNSSEC Site Validation Ability to ensure valid information from known systems through the use of digitally signed answers. This function is a piece of the specifications of DNSSEC. BIG-IP GTM Configuration Impacts of Floating vs Non-Floating Self-IP Listener A listener is a specialized virtual server that uses port 53 and to which you assign a specific IP address.
When a DNS name resolution request is sent to the IP address of a listener, GTM either handles the request locally or forwards the request to the appropriate resource. When GTM receives traffic, processes it locally, and sends the appropriate Domain Name System (DNS) response back to the querying server, it is operating in Node mode. In this situation, you create a listener that corresponds to an IP address on the system.
If GTM operates as a standalone unit, this IP address is the self-IP address of the system. If GTM is part of a redundant system configuration for high availability purposes, this IP address is the floating IP address that belongs to both systems. Having GTM deployed in a redundant pair configuration in each data center will allow for hitless code upgrades for the GTM listeners residing in that data center.
As one GTM is taken off line for maintenance the redundant unit in the pair will continue to respond to the floating IP addresses used as listeners. For any GTM systems that are running stand alone, all listeners on the system will be down during maintenance. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 22 Objective - 1.08 - Describe data center, server/virtual server, and object monitoring including explanation of resulting object statuses prober pools, BIG-IP and generic server objects, monitors, etc. 1.08 - Describe data center, server/virtual server, and object monitoring including explanation of resulting object statuses prober pools, BIG-IP and generic server objects, monitors, etc.
BIG-IP Global Traffic Manager: Concepts Data Center Objects All of the resources on your network are associated with a data center. The GTM consolidates the paths and metrics data collected from the servers, virtual servers, and links in the data center, and uses that data to conduct load balancing and route DNS name resolution requests to the best-performing site based on different factors. The GTM might send all requests to one site when another site 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.
Server and Virtual 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.
GTM supports three types of servers:. 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 any server on the network that does not support virtual servers. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 23 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, such as the Local Traffic Manager (LTM), virtual servers are often proxies that allow the load balancing server to manage a resource request across a multitude of resources.
Troubleshooting BIG-IP GTM Monitors Monitors The GTM health monitors verify connectivity to virtual server objects that reside on BIG-IP devices and non-BIG-IP devices. When a GTM monitor marks a virtual server down, and that virtual server is a member of a Wide-IP pool, the GTM no longer includes that virtual server’s address in answers to DNS queries for a Wide-IP.
The GTM system receives the status of virtual servers that reside on non-BIG-IP devices directly from BIG-IP devices using the iQuery protocol. For example, if you have GTM devices and LTM devices in a data center, along with generic host servers, the GTM system will dynamically assign a BIG-IP device to probe the generic host server for status. You can also assign a specific BIG-IP device or group of devices to monitor a server object by using prober pools. 1.08 - Identify the purpose and uses of prober pools BIG-IP Global Traffic Manager: Concepts Prober pools A Prober pool is an ordered collection of one or more BIG-IP systems. 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. 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, GTM reverts to a default intelligent probing algorithm to gather data about the resources on the server. This figure illustrates how Prober pools work. GTM contains two BIG-IP Local Traffic Manager™ (LTM™) systems that are assigned Prober pools and one LTM system that is not assigned a Prober pool. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 24 Example illustration of how Prober pools work BIG-IP systems with prober pools 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 GTM can solicit any BIG-IP system to perform FTP monitor probes of these load balancers, including systems that are Prober pool members. Objective - 1.09 - Define the GTM load balancing methods and when to use them dynamic, static 1.09 - Define the GTM load balancing methods and when to use them dynamic, static About Global Server Load Balancing Global Server Load Balancing GTM provides tiered global server load balancing (GSLB). GTM distributes DNS name resolution requests, first to the best available pool in a Wide-IP, and then to the best available virtual server within that pool. GTM selects the best available resource using either a static or a dynamic load balancing method.
Using a static. F5 STUDY GUIDE 302 – F5 Certified Technology Specialist, GTM 25 load balancing method, GTM selects a resource based on a pre-defined pattern. Using a dynamic load balancing method, GTM selects a resource based on current performance metrics collected by the big3d agents running in each data center. Static load balancing methods This table describes the static load balancing methods available in GTM. Name Description Recommended Use Drop Packet GTM drops the DNS request. Use Drop Packet for the Alternate load balancing method when you want to ensure that GTM does not offer in a response a virtual server that is potentially unavailable. Fallback IP GTM distributes DNS name resolution requests to a virtual server that you specify.
This virtual server is not monitored for availability. Use Fallback IP for the fallback load balancing method when you want GTM to return a disaster recovery site when the preferred and alternate load balancing methods do not return an available virtual server. Global Availability GTM distributes DNS name resolution requests to the first available virtual server in a pool. GTM starts at the top of a manually configured list of virtual servers and sends requests to the first available virtual server in the list.
Only when the virtual server becomes unavailable does GTM send requests to the next virtual server in the list. Over time, the first virtual server in the list receives the most requests and the last virtual server in the list receives the least requests. Use Global Availability when you have specific virtual servers that you want to handle most of the requests. None GTM distributes DNS name resolution requests skipping either the next available pool in a multiple pool configuration or the current load balancing method.
If all pools are unavailable, GTM returns an aggregate of the IP addresses of all the virtual servers in the pool using BIND. Use None for the alternate and fallback methods when you want to limit each pool to a single load balancing method. If the preferred load balancing method fails, GTM offers the next pool in a load balancing response.
F5 Gtm Student Guide
Citrix and GoToMeeting are of Citrix Systems, Inc. And/or one or more of its subsidiaries. Citrix GoToMeeting is a web conferencing software that allows for simple ways to collaborate online with other users. As Duquesne University students, you can connect with Gumberg librarians when you need research assistance or have questions about the research process. All that is required is an applicable Duquesne-affiliated email address ( @duq.edu) and a computer, tablet, or cell phone with ability to download the Citrix GoToMeeting software. Click the following links to download the software on your computer and activate your account:.
F5 Gtm Student Guide Pdf
For the mobile student, you can also download GoToMeeting with a tablet or a cellular device. See the following links for instructions to download and install.