F5 upgrades
We are upgrading F5 tenants from 17.1 to 17.5. We have Two R-series pairs at each data center ( ex:main and colo) Within the data center, they are in HA active standby and the 4 are in a GSLB group . Each host has one tenant During the upgrade process, I disabled GTM Sync on the F5 that is going to be upgraded. Is it recommended? I plan on having traffic moved to this active box at ex colo from the other data center main, I won't be making any config changes . After the applications move to this side, LTM pools show up on this side and global availability will have the upgraded side up. just want to make sure, if that is disabled, do we need to leave them disabled and sync them after all the 4 F5s are upgraded? during this process, can we make changes with the data center on LTM pools? Thank youUse F5 Distributed Cloud to control Primary and Secondary DNS
Overview Domain Name Service (DNS); it's how humans and machines discover where to connect. DNS on the Internet is the universal directory of addresses to names. If you need to get support for the product Acme, you go to support.acme.com. Looking for the latest headlines in News, try www.aonn.com or www.npr.org. DNS is the underlying feature that nearly every service on the Internet depends on. Having a robust and reliable DNS provider is critical to keeping your organization online and working, and especially so during a DDoS attack. "Nature is a mutable cloud, which is always and never the same." - Ralph Waldo Emerson We might not wax that philosophically around here, but our heads are in the cloud nonetheless! Join the F5 Distributed Cloud user group today and learn more with your peers and other F5 experts. F5 Distributed Cloud DNS (F5 XC DNS) can function as both Primary or Secondary nameservers, and it natively includes DDoS protection. Using F5 XC DNS, it’s possible to provision and configure primary or secondary DNS securely in minutes. Additionally, the service uses a global anycast network and is built to scale automatically to respond to large query volumes. Dynamic security is included and adds automatic failover, DDoS protection, TSIG authentication support, and when used as a secondary DNS—DNSSEC support. F5 Distributed Cloud allows you to manage all of your sites as a single “logical cloud” providing: - A portable platform that spans multiple sites/clouds - A private backbone connects all sites - Connectivity to sites through its nodes (F5 Distributed Cloud Mesh and F5 Distributed Cloud App Stack) - Node flexibility, allowing it to be virtual machines, live on hardware within data centers, sites, or in cloud instances (e.g. EC2) - Nodes provide vK8s (virtual K8s), network and security services - Services managed through F5 Distributed Cloud’s SaaS base console Scenario 1 – F5 Distributed Cloud DNS: Primary Nameserver Consider the following; you're looking to improve the response time of your app with a geo-distributed solution, including DNS and app distribution. With F5 XC DNS configured as the primary nameserver, you’ll automatically get DNS DDoS protection, and will see an improvement in the response the time to resolve DNS just by using Anycast with F5’s global network’s regional point of presence. To configure F5 XC DNS to be the Primary nameserver for your domain, access the F5 XC Console, go to DNS Management, and then Add Zone. Alternately, if you're migrating from another DNS server or DNS service to F5 XC DNS, you can import this zone directly from your DNS server. Scenario 1.2 below illustrates how to import and migrate your existing DNS zones to F5 XC DNS. Here, you’ll write in the domain name (your DNS zone), and then View Configuration for the Primary DNS. On the next screen, you may change any of the default SOA parameters for the zone, and any type of resource record (RR) or record sets which the DNS server will use to respond to queries. For example, you may want to return more than one A record (IP address) for the frontend to your app when it has multiple points of presence. To do this, enter as many IP addresses of record type A as needed to send traffic to all the points of ingress to your app. Additional Resource Record Sets allows the DNS server to return more than a single type of RR. For example, the following configurations, returns two A (IPv4 address) records and one TXT record to the query of type ANY for “al.demo.internal”. Optionally, if your root DNS zone has been configured for DNSSEC, then enabling it for the zone is just a matter of toggling the default setting in the F5 XC Console. Scenario 1.2 - Import an Existing Primary Zone to Distributed Cloud using Zone Transfer (AXFR) F5 XC DNS can use AXFR DNS zone transfer to import an existing DNS zone. Navigate to DNS Management > DNS Zone Management, then click Import DNS Zone. Enter the zone name and the externally accessible IP of the primary DNS server. ➡️ Note: You'll need to configure your DNS server and any firewall policies to allow zone transfers from F5. A current list of public IP's that F5 uses can be found in the following F5 tech doc. Optionally, configure a transaction signature (TSIG) to secure the DNS zone transfer. When you save and exit, F5 XC DNS executes a secondary nameserver zone AXFR and then transitions itself to be the zone's primary DNS server. To finish the process, you'll need to change the NS records for the zone at your domain name registrar. In the registrar, change the name servers to the following F5 XC DNS servers: ns1.f5clouddns.com ns2.f5clouddns.com Scenario 1.3 - Import Existing (BIND format) Primary Zones directly to Distributed Cloud F5 XC DNS can directly import BIND formatted DNS zone files in the Console, for example, db.2-0-192.in-addr.arpa and db.foo.com. Enterprises often use BIND as their on-prem DNS service, importing these files to Distributed Cloud makes it easier to migrate existing DNS records. To import existing BIND db files, navigate to DNS Management > DNS Zone Management, click Import DNS Zone, then "BIND Import". Now click "Import from File" and upload a .zip with one or more BIND db zone files. The import wizard accepts all primary DNS zones and ignores other zones and files. After uploading a .zip file, the next screen reports any warnings and errors At this poing you can "Save and Exit" to import the new DNS zones or cancel to make any changes. For more complex zone configurations, including support for using $INCLUDE and $ORIGIN directives in BIND files, the following open source tool will convert BIND db files to JSON, which can then be copied directly to the F5 XC Console when configuring records for new and existing Primary DNS zones. BIND to XC-DNS Converter Scenario 2 - F5 Distributed Cloud DNS: Primary with Delegated Subdomains An enhanced capability when using Distributed Cloud (F5 XC) as the primary DNS server for your domains or subdomains, is to have F5 XC dynamically manage the DNS records for its own managed services. Note that prior to July 2023, the delegated DNS feature in F5 XC required the exclusive use of subdomains to use dynamically managed DNS records. As of July 2023, organizations are allowed to have both F5 XC managed and self-managed DNS resource records in the same domain or subdomain. When "Allow HTTP Load Balancer Managed Records" is checked, DNS records automatically added by F5 XC appear in a new RR set group called x-ves-io-managed which is read-only. In the following example, I've created an HTTP Load Balanacer with the domain "www.example.f5-cloud-demo.com" and F5 XC automatically created the A resource record (RR) in the group x-ves-io-managed. Scenario 3 – F5 Distributed Cloud DNS: Secondary Nameserver In this scenario, say you already have a primary DNS server in your on-prem datacenter, but due to security needs, you don’t want it to be directly accessible to the Internet. F5 XC DNS can be configured as a secondary DNS server and support both zone transfer (AXFR, IXFR) and receive (NOTIFY) updates from your primary DNS server. All that's needed to complete this change is to change the nameserver records with your DNS registrar by adding the F5 XC nameservers and removing your the real primary. Having F5 XC DNS as public interface includes complimentary security services, such as DDoS protection and vector scaling. This improves both the uptime of your services as well as reducing latency by allowing all F5's nameservers world-wide to handle domain name resolution. If the primary nameserver is configured for DNSSEC and delivers RRSIG and zone DNSKEY records, F5 XC nameservers will also include these records in the lookups delivered to clients. This ensures a consistent level of security for records management end-to-end. To configure F5 XC DNS to be a secondary DNS server, go to Add Zone, then choose Secondary DNS Configuration. Next, View Configuration for it, and add your primary DNS server IP’s. To enhance the security of zone transfers and updates, F5 XC DNS supports TSIG encrypted transfers from the primary DNS server. To support TSIG, ensure your primary DNS server supports encryption, and enable it by entering the pre-shared key (PSK) name and its value. The PSK itself can be blindfold-encrypted using the F5 XC Console to prevent other admins from being able to see it. If encryption for zone transfers is desired, simply enter the remaining details for your TSIG PSK and click Apply. Once you’ve saved a new secondary DNS configuration, the F5 XC DNS pulls the zone details and begins resolving queries on the F5 XC Global Network with its pool of Anycast-reachable DNS servers. To see the status of individual zones and when they were last transferred by navigating to the DNS Management > DNS Zones overview. As applications mature and your audience broadens, ensuring low-latency for DNS requires additional services. Adding F5 XC DNS to complement an existing BIG-IP GTM or other existing primary nameserver deployment, including with DNSSEC records and TSIG-protected zone transfer support, is straight forward. Conclusion You’ve just seen how to configure F5 XC DNS both as a primary DNS as well as a secondary DNS service. Ensure the reachability of your company with a robust, secure, and optimized DNS service by F5. A service that delivers the lowest resolution latency with its global Anycast network of nameservers, and one that automatically includes DDoS protection, DNSSEC, TSIG support for secondary DNS. Watch the following demo video to see how to configure F5 XC DNS for scenarios #1 and #3 above. Additional Resources On-Demand webinar: Boost resilience and performance with F5 Distributed Cloud DNS Information about using F5 Distributed Cloud DNS Technical documentation DNS Demo Guide and step-by-step walkthrough BIND to XC-DNS Converter (open source tool)F5 DNS/GTM External Monitor(EAV) with SNI support and response code check
I have used this monitor for XC Distributed Cloud as the HTTP LB share by default the same tenant IP address and SNI support is needed. You can order dedicated public IP addresses for each HTTP LB and enable "Default Load Balancer" ( https://my.f5.com/manage/s/article/K000152902 ) option but it will cost you extra 😉 The script is a modified version of External https health monitor for SNI-enabled pool as to handle response codes and to set the SNI globally for the entire pool and it's members. If you are uploading from Windows machine see External monitor fails to run as you could hit the bug. This could be needed for F5 DNS/GTM below 16.1 that do not support SNI in HTTPS monitors. The only mandatory variable is "SNI" that should be set in the external monitor config that references this uploaded bash script. The "URI" variable by default is set to "/" and "$2" variable by default is empty or 443, the default expected response code 200. #!/bin/sh # External monitoring script for checking HTTP status code # $1 = IP (::ffff:nnn.nnn.nnn.nnn notation or hostname) # $2 = port (optional; defaults to 443 if not provided) # Default SNI to IP if not explicitly provided node_ip=$(echo "$1" | sed 's/::ffff://') # Remove IPv6 compatibility prefix SNI=${SNI:-"$node_ip"} # Assign sanitized IP to SNI # Default variables MON_NAME=${MON_NAME:-"MyExtMon$$"} pidfile="/var/run/$MON_NAME.$1..$2.pid" # PID file path DEBUG=${DEBUG:-0} # Enable debugging if set to 1 EXPECTED_STATUS=${EXPECTED_STATUS:-200} # Default HTTP status code to 200 URI=${URI:-"/"} # Default URI DEFAULT_PORT=443 # Default port (used if $2 is unset) # Set port to default if $2 is not provided if [ -z "${2}" ]; then PORT=${DEFAULT_PORT} else PORT=${2} fi # Kill old process if pidfile exists if [ -f "$pidfile" ]; then kill -9 -$(cat "$pidfile") > /dev/null 2>&1 fi echo "$$" > "$pidfile" # Perform the HTTP(S) request via single curl (fetch status code only) status_code=$(curl -s -o /dev/null -w '%{http_code}' --connect-timeout 5 --resolve "${SNI}:${PORT}:${node_ip}" "https://${SNI}:${PORT}${URI}") # Cleanup rm -f "$pidfile" > /dev/null 2>&1 # Output server status based on HTTP status code match if [ "$status_code" -eq "$EXPECTED_STATUS" ]; then echo "up" else echo "down" fi # Debugging if [ "$DEBUG" -eq 1 ]; then echo "Debugging on..." echo "SNI=${SNI}" echo "URI=${URI}" echo "IP=${node_ip}" echo "PORT=${PORT}" echo "MON_NAME=${MON_NAME}" echo "STATUS_CODE=${status_code}" echo "EXPECTED_STATUS=${EXPECTED_STATUS}" echo "curl -s -o /dev/null -w '%{http_code}' --connect-timeout 5 --resolve ${SNI}:${PORT}:${node_ip} https://${SNI}:${PORT}${URI}" fiDNS/GTM health monitor big3d timeout because of alias config
Hello Everyone, I was testing some experimental config for DNS/GTM where the health monitor does not monitor the pool members but a specific IP address configured in the "alias" and it does not work as the error says bigd timeouts to report the state. For LTM http/https health monitors the "alias" option works but not for gtm/dns. I think I discovered a bug as this is rare use case to not monitor the pool members themselves. I have changed the ip to 1.1.1.1 just for the picture screenshot 😄 Also in the logs after gtm and big3d is enabled I see the logs below and too bad that F5 DNS does not have monitor debug like LTM to just enable a debug for a monitor and not the entire box. ----- Will not probe x.x.x.x:80 ( in DC /Common/niki-dc because will be done by other GTM (<unknown>:<unknown>) Unable to identify which gtm server represents the local device
F5 DNS combine all zones into one top-level zone
We are migrating our F5 DNS(GTM) towards a new automated setup using AS3, but I noticed we forgot the create a top-level zone in the zone runner configuration. So now all our WideIPs already deployed have their own zone file with the A-records of the pool members. We can create a new top-level zone which should cover all our WideIPs but I am looking for away to transfer all the already existing A-records into this new top-level zone so we delete all the wideip specific zones. Is there an option to re-group all the records into this top-level zone?nsupdate to modify zone in specific views.
we have zone name example.com and we have 2 view (external and internal) so in /var/namedb/ we have zone file db.external.example.com and db.internal.example.com . How can we use nsupdate to modify zone in specific views? because we can't seem to specify view in nsupdate script. and we can't specify "zone internal.example.com" in nsupdate script too
F5 DNS Generic Host
I am trying to create a few generic hosts for a POC, but having issues with them being monitor failed. I created a new server named RANCHER-POC-11 and gave it an ip address of 10.4.65.11, this has a monitor of https assigned to it. I then created a virtual server with the same ip address and port 443 as well as the https monitor. The Server and Virtual Servers are both red triangles. I performed a packet capture and I don't see that the gtm is even attempting to monitor. I put a specific route in the network and pointed to the GW and now if I initiate a connection from the CLI I see logs in our monitoring but only if I do the connection manually. This is the first generic host we have tried to deploy as the rest of the virtual servers/pools are pulled from the LTM's and this service is not behind the LTM. Any suggestions would be appreciated. Thanks, Joe
