Geo-Location Based Traffic Management with F5 BIG-IP for VMware Products (PoC): F5 BIG-IP GTM Configuration (SKKB1018)

In this article we will focus on the F5 BIG-IP Global Traffic Manager (LTM) configuration. We will take a look at LTM Datacenters, Servers, Listeners , ZoneRunner and DNS delegation, LTM with GTM integration, GTM with GTM integration, Pools, Wide IP’s, Topology records, and Distributed Applications.

Part 1: Geo-Location Based Traffic Management with F5 BIG-IP for vRA (PoC)
Part 2: Infrastructure Setup
Part 3: F5 BIG-IP LTM
Part 4: F5 BIG-IP GTM (this article)
Part 5: Infrastructure Setup (continued)
Part 6: Use Case 1
Part 7: Use Case 2

Lab Environment

The logical design of this lab can be seen HERE.

 

F5 BIG-IP GTM

Datacenters

Data centers are the top level of your physical network setup. You must configure one data center for each physical location in your global network. When you create a data center in the Global Traffic Manager, you define the servers (Global Traffic Manager systems, Local Traffic Manager systems, Link Controller systems, hosts, and routers) that reside at that location.

A data center can contain any type of server. For example, one data center can contain a Global Traffic Manager and a host, while another might contain two Global Traffic Manager systems and eight Local Traffic Manager systems.

For information about configuring data centers, see Managing data centers.

In this case we will define two datacenters: Los Angeles and New York
Go to the f5-gtm-a-01 GMT device and navigate to [DNS > GSLB > Data Centers]
Create tow Data Centers with the following properties:

Name: los-angeles-dc
Location: Los Angeles
Stat: enabled

Name: new-york-dc
Location: New York
Stat: enabled

Leave all other properties to their default values.
You should now have created the data centers:

DO NOT perform this step on the f5-gtm-b-01 GTM device. This configuration will be later automatically synced.

 

Servers

A server is a physical device on which you can configure one or more virtual servers. The servers that you define for the Global Traffic Manager to manage can include both BIG-IP systems and third-party servers, for example, Local Traffic Manager systems and Windows® 2000 Servers.

One server that you must define is the Global Traffic Manager. This places the system on the network map. You can also define Local Traffic Manager systems, and the virtual servers that these servers manage.

For information about configuring servers, see Managing servers.

In this case we will be adding all GTM and LTM devices as servers to the GMT device.

This is roughly represented by the diagram below:

Go on the f5-gtm-a-01 GMT device and navigate to [DNS > GSLB > Servers]
Create four Servers and add the four F5 devices with the following properties:

Name: f5-gtm-a-01
Product: Big-IP System (Single)
Address: 172.16.61.2
Datacenter: los-angeles-dc
Health Monitor: BIG-IP
Virtual Server Discovery: Enabled
Link Discovery: Enabled

Name: f5-ltm-a-01
Product: Big-IP System (Single)
Address: 172.16.61.10
Datacenter: los-angeles-dc
Health Monitor: BIG-IP
Virtual Server Discovery: Enabled
Link Discovery: Enabled

Name: f5-gtm-b-01
Product: Big-IP System (Single)
Address: 172.16.71.2
Datacenter: new-york-dc
Health Monitor: BIG-IP
Virtual Server Discovery: Enabled
Link Discovery: Enabled

Name: f5-ltm-b-01
Product: Big-IP System (Single)
Address: 172.16.71.10
Datacenter: new-york-dc
Health Monitor: BIG-IP
Virtual Server Discovery: Enabled
Link Discovery: Enabled

Leave all other properties to their default values.
You should now have created the servers:

DO NOT perform this step on the f5-gtm-b-01 GTM device. This configuration will be later automatically synced.

Note that at this point the LTM devices might report a red status. This is because we are going to integrate LTM with GTM systems alter in this article. 

Note also that the status of the remote GTM device (f5-gtm-b-01) will be shown as Unknown (not shown on screenshot ) because you have not yet run the gtm_add script which will allow communication between both GMT devices. Again we will be doing this later in this article.

 

 

Listeners

To communicate with the rest of your network, you must configure the Global Traffic Manager so that it can correctly identify the resolution requests for which it is responsible. A listener is an object that monitors the network for DNS queries, and thus is critical for global traffic management. The listener instructs the system to monitor the network traffic destined for a specific IP address.

In most installations, when you define a listener for the Global Traffic Manager, you use the IP address of the Global Traffic Manager; however, there are many different ways you can configure listeners so that the system handles DNS traffic correctly.

For more information on configuring listeners, see Chapter 4, Working with Listeners.

In this PoC we will be creating a DNS Listeners on all GTM devices. The GTM’s will be authorities DNS servers for the f5.vmware.com DNS namespace and will be accepting DNS queries through those listeners.  We will be configuring our authoritative DNS server for vmware.com to delegate f5.vmware.com namespace to all GTM devices. In this way our GMT’s will be solely responsible for managing DNS traffic for our GeoApp: geoapp.f5.vmware.com

This is roughly represented by the diagram below:

Go to the f5-gtm-a-01 GMT device and navigate to [DNS > Delivery > Listeners].
Create Listeners with the following properties:

Name: gtm-listener-01-TCP
Destination: 172.16.61.3
Protocol: TCP
DNS Profile: DNS

Name: gtm-listener-01-UDP
Destination: 172.16.61.3
Protocol: UDP
DNS Profile: DNS

Leave all other properties to their default values.
You should now have created the Listeners:

Go to the f5-gtm-b-01 GMT device and navigate to [DNS > Delivery > Listeners].
Create Listeners with the following properties:

Name: gtm-listener-01-TCP
Destination: 172.16.71.3
Protocol: TCP
DNS Profile: DNS

Name: gtm-listener-01-UDP
Destination: 172.16.71.3
Protocol: UDP
DNS Profile: DNS

Leave all other properties to their default values.
You should now have created the Listeners:

 

ZoneRunner and DNS Delegation

One of the modes in which you can operate the Global Traffic Manager system is the node mode. In node mode, the Global Traffic Manager is responsible not only for load balancing name resolution requests and monitoring the health of your physical and logical network; it is also responsible for maintaining the DNS zone files that map name resolution requests to the appropriate network resource.

In the Global Traffic Manager, you create, manage, and maintain DNS files using the ZoneRunner utility. The ZoneRunner utility is a zone file management utility that can manage both DNS zone files and your BIND configuration.

Additionally, you can transfer zone files to another name server, or import zone files from another name server. A zone file contains resource records and directives that describe the characteristics and hosts of a zone, otherwise known as a domain or sub-domain.

There are five types of zone files. Each type has its own content requirements and role in the DNS.
The types of zones are:

  • 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.
  • 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 as long as 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.

For more information about how to use ZoneRunner, see Using ZineRunner to configure DNS Zones and Managing DNS Files with Zone Runner

In this PoC we will create a Master DNS Zone for the f5.vmware.com sub-domain DNS namespace. This way F5 GMT’s will be responsible for all DNS queries to this namespace and will be owning the zone.

Go on the f5-gtm-a-01 GMT device and navigate to [DNS > Zones > ZoneRunner > Zone List]
Create a Zone with the following properties:

View Name: external
Zone Name: f5.vmware.com
Zone Type: Master
Record Creation Method: Manual
SOA Record (TTL): 500
SOA Record (Master Server): f5-gtm-a-01
NS Record (TTL): 60
NS Record (Master Server): f5-gtm-a-01
A Record (IP Address): 172.16.60.3

Leave all other properties to their default values.
You should now have created the Zone:

DO NOT perform this step on the f5-gtm-b-01 GTM device. This configuration will be later automatically synced.

Now that we’ve configure the F5 GMT to be master server for the f5.vmware.com zone, we will configure a delegation for that zone on our Authoritative server for the vmware.com zone.

In this example this is the lan1dc1.vmware.com (192.186.1.1) server. I’m creating this delegation because later I will configure the both LDNS servers with a Secondary Copy of the vmware.com domain zone and I want them to have the delegation information and be able to forward request directly to the F5 GTM devices.
In this example I’ve went on my authoritative server for the vmware.com DNS zone and created delegation for the f5.vmware.com zone. Also added two NS records the IP’s for which are the GTM Listeners on each GTM device:

To clarify more the f5-gtm-a-01-sip-external-2.vmware.com NS record above is a Self IP on the f5-gtm-a-01 GMT device. IP address is 172.16.61.3

This same address 172.16.61.3 is configured for the DNS Listener on the same GTM Device.

Same is for the other NS record which points to a DNS Listener on the other GMT device.

 

Integrating LTM with GTM Systems

You can add BIG-IP Local Traffic Manager (LTM) systems to a network in which BIG-IP Global Traffic Manager (GTM) systems are already present. This expands your load balancing and traffic management capabilities to include the local area network. For this implementation to be successful, you must authorize communications between the LTM and GTM systems. When the LTM and GTM systems use the same version of the big3d agent, you run the BIG-IP_add utility to authorize communications between the systems.

For more information about LTM and GTM systems integration, see Integrating BIG-IP LTM with BIG-IP GTM Systems.

In this case we are going to connect all LTM devices to the GTM device in the LA Datacenter and to the GTM Device in the NY Datacenter.

This is roughly represented by the diagram below:


Note that the bigip_add command in the link uses syntax which will fail on F5 Virtual Appliances, but will most likely run without a problem on F5 hardware appliances.

Do an SSH session to f5-gtm-a-01 GMT device and run

// Enable communication to the f5-ltm-a-01 device

run gtm bigip_add -a admin@172.16.61.10

// Enable communication to the f5-ltm-b-01 device

run gtm bigip_add -a admin@172.16.71.10

Do an SSH session to f5-gtm-b-01 GMT device and run

// Enable communication to the f5-ltm-a-01 device

run gtm bigip_add -a admin@172.16.61.10

// Enable communication to the f5-ltm-b-01 device

run gtm bigip_add -a admin@172.16.71.10

To verify connectivity go to the f5-gtm-a-01 GTM device navigate to [DNS > GSLB > Servers].
First you should see that status of the LTM devices shown as green.

if you have already configured a virtual server on the LTM device for the use case you are implementing, you should also see it appear.

To check if a virtual server is synchronized from an LTM device select the devices and the go to [Virtual Servers]. You should see a list of the virtual servers which are available on the LTM device appear in the GTM interface.

Note: Virtual Server Discovery should be set to Enabled.

 

 

 

Adding GTM to a GTM synchronization group

You can configure BIG-IP Global Traffic Manager (GTM) systems in collections called GTM synchronization groups. All BIG-IP GTM systems in the same GTM synchronization group have the same rank, exchange heartbeat messages, and share probing responsibility.

Configuration changes to one device in a GTM synchronization group are synchronized incrementally across the devices in the group. That is, only the data that has changed on a GTM device is synchronized to the other devices in the group. Although incremental synchronization is the default behavior, if an incremental synchronization fails, the system automatically performs a full configuration synchronization.

For more information about the whole synchronization group setup, see Overview: Adding a BIG-IP GTM system to a GTM synchronization group

For more information about the requirements needed, see BIG-IP GTM synchronization group requirements

Most of the requirements we have already configured, but if you want to be sure you are still on the right track,  see the links above.

In this case we are going to synchronize both GTM Devices across both Datacenters.

This is roughly represented by the diagram below:

Run the gtm_add script on the BIG-IP GTM system you are adding to your network to acquire the configuration settings from a BIG-IP GTM system that is already installed on your network.

Go to f5-gtm-a-01 GTM device and navigate to  [Device Management > Devices]
Select the f5-gtm-a-01 GTM and then navigate to [Device Connectivity > Config Sync]
Make sure Local Address is set to 172.16.60.2

Go to f5-gtm-b-01 GTM device and navigate to  [Device Management > Devices]
Select the f5-gtm-b-01 GTM and then navigate to [Device Connectivity > Config Sync]
Make sure Local Address is set to 172.16.70.2

Go to f5-gtm-a-01 GTM device and navigate to  [DNS > Settings > GSLB > General]
Select and enable Synchronize and Synchronize DNS Zone files.

Go to f5-gtm-b-01 GTM device and navigate to  [DNS > Settings > GSLB > General]
Select and enable Synchronize and Synchronize DNS Zone files.

Open an SSH to f5-gtm-b-01 GTM device and run:

run gtm gtm_add -a admin@192.168.1.61

 

Go to f5-gtm-a-01 GTM device and navigate to [Device Management > Device Trust > Peer List]
Create a Device Trust with the peer f5-gtm-b-01 GTM device.
Create a Device Trust with the following properties:

Device IP Address: 192.168.1.63
Administrator Username: admin (unless you’ve changed it)
Administrator Password: admin (unless you’ve changed it)

You should now have created the Device Trust:

After few moments the status should show In Sync. You can also verify this by going to [Device Management > Overview]

 

 

Pools

A pool is a collection of virtual servers that can reside on multiple network servers. When you define the virtual servers to which the Global Traffic Manager directs DNS traffic, you combine those virtual servers into pools. You can then configure the Global Traffic Manager to direct traffic to a specific virtual server within a pool, using a specific load balancing method.

For more information about configuring pools and pool members, see Defining pools.

 

 

Wide IP’s (WIP)

One of the most common logical components you create in the Global Traffic Manager is a wide IP. A wide IP maps a fully-qualified domain name to one or more pools of virtual servers that host the domains content.

When an LDNS requests a connection to a specific domain name, the wide IP definition specifies which pools of virtual servers are eligible to answer the request, and which load balancing modes to use in choosing a pool. The Global Traffic Manager then load balances the request across the virtual servers within that pool to resolve the request.

For information about configuring wide IPs, see Managing wide IPs.

Refer to the particular use case you are implementing to identify the Pools necessary and how to create them.

 

 

Topology

As the name implies, Global Traffic Manager handles name resolution requests at an international level. You can use topologies to load balance these requests. A topology is a set of characteristics that identifies the origin of a given name resolution request. In Global Traffic Manager, topologies belong to one of several categories, including:

  • Continent
  • Country               
  • IP Subnet
  • ISP         
  • Region 
  • State

A region is a customized collection of topologies. For example, you can create a topology for Denmark, Iceland, Finland, Norway, and Sweden. These topologies can compose a custom region called Scandinavia.

Through topologies, you can instruct Global Traffic Manager to select a data center or resource based on its physical proximity to the client making the name resolution request. This process helps ensure that name resolution requests are answered and managed in the fastest possible time.

You can also instruct Global Traffic Manager to use topologies to load balance name resolution requests across pools at the wide IP level, and across virtual servers at the pool level.

A topology record is a statement that tells Global Traffic Manager how to handle name resolution requests based on topologies

For more information about topology, see Topologies and Configuring BIG-IP Global Traffic Manager for Topology Load Balancing

In this case we will create two regions

  • Region for the New York External Network identified by IP Subnet.
  • Region for the Los Angeles External Network identified by IP Subnet.

Further we will create two records:

  • A record to tell GTM to forward name resolution requests from the Los Angeles External Network to the GeoApp Pool in the LA Datacenter
  • A record to tell GTM to forward name resolution requests from the New York External Network to the GeoApp Pool in the NY Datacenter

Go to the f5-gtm-a-01 GTM and navigate to [DNS > GSLB > Topology > Regions]
Create Regions with the following properties:

Name: region-los-angeles-extrenal
Member List (Member Type): IP Subnet
Member List (IP Subnet):  172.16.61.0/24

Name: region-new-york-extrenal
Member List (Member Type): IP Subnet
Member List (IP Subnet):  172.16.71.0/24

Leave all other properties to their default values.
You should now have created the regions:

Go to the f5-gtm-a-01 GTM and navigate to [DNS > GSLB > Topology > Records]
Create Records with the following properties:

Request Source: Region is region-los-angeles-extrenal
Destination: Pool is gtm-pool-geoapp-la
Weight: 100

Request Source: Region is region-new-york-extrenal
Destination: Pool is gtm-pool-geoapp-ny
Weight: 100

Leave all other properties to their default values.
You should now have created the regions:

If you have previously successfully configured GTM Synchronization Group these changes will be synchronized to the other GTM members. If you haven’t do an SSH to the f5-gtm-b-01 GTM device and run the following command to synchronize the changes:

run gtm gtm_add -a admin@172.16.61.2

Same configuration changes should appear on f5-gtm-b-01 GTM device.

Depending on the use case you are implementing, more topology Records or Regions might need to be created. 

Refer to the particular use case you are implementing to identify the Records or Regions necessary.

Load Balancing

When the Global Traffic Manager receives a name resolution request, the system employs a load balancing mode to determine the best available virtual server to which to send the request. Once the Global Traffic Manager identifies the virtual server, it constructs a DNS answer and sends that answer back to the requesting clients local DNS server. The DNS answer, or resource record, can be either an A record that contains the IP address of the virtual server, or a CNAME record that contains the canonical name for a DNS zone.

Within the Global Traffic Manager, there are two categories of load balancing modes from which to select: static and dynamic. A static load balancing mode selects a virtual server based on a pre-defined pattern. A dynamic load balancing mode selects a virtual server based on current performance metrics.
The Global Traffic Manager provides a tiered load balancing system. A tiered load balancing system is a load balancing system that occurs at more than one point during the resolution process. The tiers within the Global Traffic Manager are as follows:

Wide IP-level load balancing

A wide IP contains two or more pools. The Global Traffic Manager load balances requests, first to a specific pool, and then to a specific virtual server in the selected pool. If the preferred, alternate, and fallback load balancing methods that are configured for the pool or virtual server fail, then the requests fail, or the system falls back to DNS.

Pool-level load balancing

A pool contains one or more virtual servers. After the Global Traffic Manager uses wide IP-level load balancing to select the best available pool, it uses a pool-level load balancing to select a virtual server within that pool. If the first virtual server within the pool is unavailable, the Global Traffic Manager selects the next best virtual server based on the load balancing mode assigned to that pool.

For each pool that you manage, the Global Traffic Manager supports three types of load balancing methods: preferred, alternate, and fallback. The preferred load balancing method is the load balancing mode that the system attempts to use first. If the preferred method fails to provide a valid resource, the system uses the alternate load balancing method. Should the alternate load balancing method also fail to provide a valid resource, the system uses the fallback method.

For more information about GTM Load balancing, see Load Balancing with the Global Traffic Manager and GTM Load Balancing

Refer to the particular use case you are implementing to identify the Load Balancing configuration necessary and how to configure it.

 

 

Distributed Applications

When you create a distributed application on Global Traffic Manager, the system acquires information about the data centers, servers, and links that make up the application, including the status of each of these components. You have the option of setting the status of the distributed application to be dependent upon the status of one of these types of components. For example, when you configure the distributed application for server dependency, and a specified server becomes unavailable, Global Traffic Manager considers the distributed application to be unavailable as well.

Example 1: Data Center Dependency
If the application uses data center dependency, Global Traffic Manager considers the entire data center to be unavailable to the application, even if other virtual servers for the application remain available at the data center. Other connection requests, independent of the application, can still be sent to the data center.

Example 2: Server Dependency Level
If the application uses server dependency, Global Traffic Manager considers the server hosting the virtual server to be unavailable to the application, even if other virtual servers on that server are online. Other connection requests, independent of the application, can still be sent to the server.

Example 3: Link Dependency Level
If the application uses link dependency, Global Traffic Manager considers all resources for the application that use that link to be unavailable to the application. Other connection requests, independent of the application, can still be sent to these resources through other links.

Example 4: Wide IP Dependency Level
If the application uses wide IP dependency, Global Traffic Manager considers all wide IPs that host that application to be unavailable, even if only one of the wide IPs is unavailable. Other connection requests, independent of the application, can still be sent to the data center.

Note: You do not have to set a dependency for a distributed application. You can accept the default value of None. If you do not set a dependency, then Global Traffic Manager considers the application available as long as there is at least one wide IP to which it can load balance a name resolution request.

Many distributed applications require that users access a single set of resources until they complete their transaction. For example, customers purchasing a product online might need to remain with the same data center until they finish their order. In the context of Global Traffic Manager, this requirement is called persistence. Persistence is the state in which a user of the system remains with the same set of resources until the user closes the connection.

When you enable persistence for a distributed application, and an LDNS makes repetitive requests on behalf of a client, the system reconnects the client to the same resource to which it was connected for previous requests. For persistence to work correctly for a distributed application, you must also specify a dependency level. This is because a connection to the distributed application persists to the dependency object you specify (that is, the specified wide IP, server, data center, or link), and not to a specific pool member.

For more information about Distributed Applications, see The Logical Network

Refer to the particular use case you are implementing to identify the Distributed Applications necessary and how to create them.

 

DISCLAIMER; This is a personal blog. Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. Any views or opinions are not intended to malign any religion, ethnic group, club, organization, company, or individual.
All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
Photos
Unless stated, all photos are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. If used with watermark, no need to credit to the blog owner. For any edit to photos, including cropping, please contact me first.
Recipes
Unless stated, all recipes are the work of the blog owner and are licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License. Please credit all recipes to the blog owner and link back to the original blog post.
Downloadable Files
Any downloadable file, including but not limited to pdfs, docs, jpegs, pngs, is provided at the user’s own risk. The owner will not be liable for any losses, injuries, or damages resulting from a corrupted or damaged file.
Comments
Comments are welcome. However, the blog owner reserves the right to edit or delete any comments submitted to this blog without notice due to
– Comments deemed to be spam or questionable spam
– Comments including profanity
– Comments containing language or concepts that could be deemed offensive
– Comments containing hate speech, credible threats, or direct attacks on an individual or group
The blog owner is not responsible for the content in comments.
This policy is subject to change at anytime.