Creating a GTM Pool error
I am trying to add a GTM pool with the following command create gtm pool a POOL_NAME { members add { DC:/Common/VS_NAME { member-order 0 } } } It is giving me this error: 01070226:3: Pool Member VS_NAME references a nonexistent Virtual Server The virtual server does exist. I have added 40+ other pools with the same command, this is the only one giving me an error. When I try to create the pool via the GUI this server is not available in the "Virtual Server:" dropdown list. What could be the issue?
GTM return LDNS IP to client
Problem this snippet solves: We do a lot of our load balancing based on topology rules, so it's often very useful to know where the DNS request is actually coming from rather than just the client's IP and the DNS servers they have configured. Especially if they're behind an ADSL router doing NAT or some other similar set up. This rule simply returns the IP address of the LDNS that eventually made the query to the GTM device in the response to a lookup for the WideIP using the rule, as well as logging the response and perceived location. Code : rule "DNS_debug" partition "Common" { when DNS_REQUEST { host [IP::client_addr] log local0.err "Debug address : [IP::client_addr] [whereis [IP::client_addr]]" } }
BIG-IP DNS Resource Record Types: Architecture, Design and Configuration
Welcome to my first article on DevCentral! This article starts aseries about BIG-IP DNS (the artist formerly known as GTM). This article and accompanying videos take a look at the support for Domain Name System (DNS) Resource Record (RR) types that were introduced in BIG-IP version 12.0. This enhancement represented a major step forward in the capabilities available on the BIG-IP. I created these videos during the initial introduction of the feature in BIG-IP 12.0 release. Based on the timestamp in the BIG-IP GUI, that would be October of 2015. The information presented here is still relevant for later versions of BIG-IP and will be of benefit to anyone trying to understand the different DNS resource record types available on the BIG-IP. The videos assume you have used BIG-IP DNS before, and you understand the basics of DNS. If you need a refresher on DNS resource records, I present an overview of the new and existing resource records supported by BIG-IP DNS. I then go into the feature itself and the architecture and implementation details for each of the records on BIG-IP DNS. In the last video, I do a configuration walk-through of a NAPTR and SRV wideIP along with the NAPTR and SRV pools. Be sure and see the attachment at the end of the article. It is a zip file that contains a PDF of many of the slides I use in the videos. Executive Summary (9 Minutes) First up is the Executive Summary. This video introduces, at a high level, everything that will be covered in the later videos. It also talks about some things that are not explicitly called out in any of the other content. Technology Overview (8 Minutes) Next is a DNS technology overview for the different resource record types supported by BIG-IP DNS. If you are already familiar with the different DNS RR types (A, AAAA, CNAME, NAPTR, SRV, MX), you can skip this part. If you need a quick refresher on what each record type is and the fields used in them this content is for you! NOTE: This is not a discussion of how the BIG-IP DNS implements these resource records but rather a discussion of the record types themselves in a purely DNS sense. Feature/Architecture Overview If you do not watch any of the other videos in this series, watch these!! I go over the concepts and architecture behind how the different resource records are implemented and configured on BIG-IP DNS with lots of diagrams. The configurations of the different resource record types and all the associated pools can get confusing. These videos will give you a solid foundation to follow the configuration walk-through. I am going to be bold here and say that I guarantee you will learn something you did not know about BIG-IP DNS if you watch the next five videos. As a polling mechanism, hit the “Like” button on the article if I was correct in my prediction. General Information and A/AAAA Records (11:30 Minutes) This video covers general information about the DNS RR implementation along with the A and AAAA record types. For example, the video talks about a new concept in BIG-IP DNS called Non-Terminal and Terminal Pools and what they mean in wideIP configurations. CNAMEs (9 Minutes) This is a long discussion about CNAMEs. Who knew they were so interesting? Well, they are, and it is worth listening to how they are implemented on BIG-IP DNS. NAPTR, SRV and MX Records (5:30 Minutes) NAPTR, SRV and MX records are next. The configuration walk-through later in this article will implement NAPTR and SRV wideIPs. Health Checks (7:30 Minutes) Let’s talk about one of the reasons you have a BIG-IP DNS…health checks! Now that wideIPs can be pool member, the game has changed. Persistence (8 Minutes) Persistence also has some new wrinkles. If you use persistence, you want to watch this. Configuration Walk-through (11:30 Minutes) Finally, we have the configuration walk-through. This is where things get real. In this video, I do a configuration of NAPTR and SRV wideIPs along with the NAPTR and SRV pools. You can see the configuration objects I will create and the order in the diagram below. Conclusion That is all I have for this article. I hope you learned something and most importantly have a better understanding of the different DNS resource record types available on the BIG-IP DNS. I have more articles and videos to come so stay tuned. Be sure and grab the attachment if you want a copy of some of the diagrams used in the videos. Trivia: iQuery uses port 4353 for its communication. Do you know the significance/meaning of that particular port number? Drop a comment at the bottom if you know the answer.Using BIG-IP GTM to Integrate with Amazon Web Services
This is the latest in a series of DNS articles that I've been writing over the past couple of months. This article is taken from a fantastic solution that Joe Cassidy developed. So, thanks to Joe for developing this solution, and thanks for the opportunity to write about it here on DevCentral. As a quick reminder, my first six articles are: Let's Talk DNS on DevCentral DNS The F5 Way: A Paradigm Shift DNS Express and Zone Transfers The BIG-IP GTM: Configuring DNSSEC DNS on the BIG-IP: IPv6 to IPv4 Translation DNS Caching The Scenario Let's say you are an F5 customer who has external GTMs and LTMs in your environment, but you are not leveraging them for your main website (example.com). Your website is a zone sitting on your windows DNS servers in your DMZ that round robin load balance to some backend webservers. You've heard all about the benefits of the cloud (and rightfully so), and you want to move your web content to the Amazon Cloud. Nice choice! As you were making the move to Amazon, you were given instructions by Amazon to just CNAME your domain to two unique Amazon Elastic Load Balanced (ELB) domains. Amazon’s requests were not feasible for a few reasons...one of which is that it breaks the RFC. So, you engage in a series of architecture meetings to figure all this stuff out. Amazon told your Active Directory/DNS team to CNAME www.example.com and example.com to two AWS clusters: us-east.elb.amazonaws.com and us-west.elb.amazonaws.com. You couldn't use Microsoft DNS to perform a basic CNAME of these records because of the BIND limitation of CNAME'ing a single A record to multiple aliases. Additionally, you couldn't point to IPs because Amazon said they will be using dynamic IPs for your platform. So, what to do, right? The Solution The good news is that you can use the functionality and flexibility of your F5 technology to easily solve this problem. Here are a few steps that will guide you through this specific scenario: Redirect requests for http://example.com to http://www.example.com and apply it to your Virtual Server (1.2.3.4:80). You can redirect using HTTP Class profiles (v11.3 and prior) or using a policy with Centralized Policy Matching (v11.4 and newer) or you can always write an iRule to redirect! Make www.example.com a CNAME record to example.lb.example.com; where *.lb.example.com is a sub-delegated zone of example.com that resides on your BIG-IP GTM. Create a global traffic pool “aws_us_east” that contains no members but rather a CNAME to us-east.elb.amazonaws.com. Create another global traffic pool “aws_us_west” that contains no members but rather a CNAME to us-west.elb.amazonaws.com. The following screenshot shows the details of creating the global traffic pools (using v11.5). Notice you have to select the "Advanced" configuration to add the CNAME. Create a global traffic Wide IP example.lb.example.com with two pool members “aws_us_east” and “aws_us_west”. The following screenshot shows the details. Create two global traffic regions: “eastern” and “western”. The screenshot below shows the details of creating the traffic regions. Create global traffic topology records using "Request Source: Region is eastern" and "Destination Pool is aws_us_east". Repeat this for the western region using the aws_us_west pool. The screenshot below shows the details of creating these records. Modify Pool settings under Wide IP www.example.com to use "Topology" as load balancing method. See the screenshot below for details. How it all works... Here's the flow of events that take place as a user types in the web address and ultimately receives the correct IP address. External client types http://example.com into their web browser Internet DNS resolution takes place and maps example.com to your Virtual Server address: IN A 1.2.3.4 An HTTP request is directed to 1.2.3.4:80 Your LTM checks for a profile, the HTTP profile is enabled, the redirect request is applied, and redirect user request with 301 response code is executed External client receives 301 response code and their browser makes a new request to http://www.example.com Internet DNS resolution takes place and maps www.example.com to IN CNAME example.lb.example.com Internet DNS resolution continues mapping example.lb.example.com to your GTM configured Wide IP The Wide IP load balances the request to one of the pools based on the configured logic: Round Robin, Global Availability, Topology or Ratio (we chose "Topology" for our solution) The GTM-configured pool contains a CNAME to either us_east or us_west AWS data centers Internet DNS resolution takes place mapping the request to the ELB hostname (i.e. us-west.elb.amazonaws.com) and gives two A records External client http request is mapped to one of the returned IP addresses And, there you have it. With this solution, you can integrate AWS using your existing LTM and GTM technology! I hope this helps, and I hope you can implement this and other solutions using all the flexibility and power of your F5 technology.Adding LTM to GTM with different version
Hi Experts, I am looking for a KB that shows the prerequisites or consideration prior doing BIGIP ADD in GTM. Are goal is to use GSLB functionality of our GTM. Our GTM is running in 11.6.1 version and we will upgrade our LTM from 11.6.1 to 13.0. May we know if it is possible or there is an issue with this setup.
GTM Source IP Redirect to Specific Pools iRule
I'm trying to redirect clients to specific pools based on the clients IP address through an iRule. I created this iRule in the GTM and it seems to be working fine however, I'd like to set client networks in the rule instead of "starts_with" in an effort to keep this rule as short as we add more and more clients. I've tried "equals "10.80.0.0/16" however that didn't seem to work. Anyone have any ideas on what I could do to achieve my goal? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- when DNS_REQUEST { if { [IP::client_addr] starts_with "10.80." } { pool pool_10_80 } elseif { [IP::client_addr] starts_with "10.96." } { pool pool_10_96 } elseif { [IP::client_addr] contains "172.27." } { pool pool_172_27 } } =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Thanks in advance for any feedback.Edge to Pulse: IP Geolocation Database Migration
UPDATE (August 2023): Previously, we announced the end of support of the Edge legacy database. However, support for the Edge database has been extended indefinitely. All supported versions of F5 BIG-IP can now use both types of IP geolocation databases: Edge and Pulse, provided by Digital Envoy. The Edge database is based off of partner-supplied data gathered from IP traffic. The Pulse database relies on information derived from mobile devices and Wi-Fi connection points, increasing the accuracy for certain aspects, but also significantly increasing file size. Because of this, F5 does not support City level for the Pulse database. Last month, F5’s BIG-IP DNS team released the new, Pulse database from our third-party vendor, Digital Envoy. F5 migrated its IP geolocation database from the Edge database to the Pulse database because Pulse provides a higher number of available subnets. This allows for improved geolocation accuracy for querying IP addresses. Because Pulse captures more granular data of locations than Edge, it is larger than the Edge database. This installation update may take longer than expected after the migration due to the size of the database. As with any infrastructure shift, there are a few important things to know: This migration applies to all supported BIG-IP versions and is transparent to users If using City Database from Digital Envoy, then please follow the KB article before installing the Pulse City RPM (K78974041 - link below) There is no change of database format, downloading, or installation procedures Edge and Pulse databases are available for an additional three months from release date to ease the migration process Both databases are seamlessly available for customer download until the end of 2022 Beginning in January 2023, only the Pulse database will be accessible Edge database will reach End of Life by the end of December 2022
BIGIP DNS health monitor
I suspect I am missing some fundamental understanding for this but what i want to accomplish is to have a wide ip that monitors two web servers and just returns only an ip of a server that is up. I created two server objects of product generic host. I put the ip of one webserver in the big-ip system devices and also created a resource on the page with the same ip. Repeated the process for the other. I created a GSLB pool and added both server objects. I created the wide ip object and added the pool. Resolves as expected with the webserver ips alternating, however none of the health monitors actually work (all are red) when i look at the pool members they have the error against availibility as Offline (Enabled) - Monitor /Common/gateway_icmp from <unknown> : no reply from big3d: timed out I suspect I am creating the server object incorrect or there is another way to do this, could anyone please advise?
Using Client Subnet in DNS Requests
BIG-IP DNS 14.0 now supports edns-client-subnet (ECS) for both responding to client requests (GSLB) or forwarding client requests (screening). The following is a quick start on using this feature. What is EDNS-Client-Subnet (ECS) If you are familiar with X-Forwarded-For headers in HTTP requests,ECS solves a similar problem. The problem is how to forward a DNS request through a proxy and preserve information about the original request (IP Address). Some of this discussion I also cover in a previous article,Implementing Client Subnet in DNS Requests . Traditional DNS Requests When a traditional DNS request is made, a client makes a request to a “local” DNS server (LDNS), and that request is forwarded to the authoritative DNS server for that domain. When a topology (send different responses based on the source address) record is evaluated it will use the source IP of the LDNS server. Usually this is OK for most applications, but it would be ideal to be able to forward more precise information from the LDNS server. ECS DNS Requests Using ECS a LDNS server can inject additional meta-data about the request that includes information about the source IP address of the client. In the following example a “Client Subnet” of 192.0.2.0/24 is forwarded to the DNS server. ECS on BIG-IP DNS F5 BIG-IP DNS can use ECS in two ways. Use ECS when handling topology requests Inject ECS when “screening” a DNS server Using ECS with BIG-IP DNS Topology There are two methods of configuring BIG-IP DNS to use ECS. Either at the wide-ip or globally. To configure ECS on a wide-ip: To configure ECS globally. Under DNS Settings. Injecting ECS records BIG-IP DNS can also proxy requests to other DNS servers (BIG-IP DNS or other vendors). When you modify the DNS profile to insert an ECS record. You will observe that the original /32 address will be forwarded to any DNS servers that are in the pool for that particular Virtual Server. The following is a diagram of the above.DnsClientNrptRule configuration not working when connected to BIG-IP Edge Client
Hello, Our problem is when connecting to a third party VPN, our local DNS is not resolving causing problems with users accessing local resources while on this VPN. Split tunneling is enabled on the connection but we do not have control over changing any of the F5 connection settings since this connection is outside of our organization. We are attempting to fix this using a DnsClientNrptRule but even after adding the rule, it still uses the DNS servers configured on the VPN connection. The rule works as expected when not connected to the VPN. Any insight would be greatly appreciated. Thanks!
