Forum Discussion

Kees_Smit's avatar
Kees_Smit
Icon for Nimbostratus rankNimbostratus
Sep 14, 2018

GTM Device groups

Hello,

 

I have 2 F5 DNS clusters in two datacenters acting as external DNS server. Each cluster should be able to operate fully standalone to server requests for a specific domain. How I see it I should create a device group for both units in DC_US and a another device group for both units in DC_EU. Each device group wil only synchronize configuration data within the local cluster.

 

Besides this, is there an option to synchronize data between both DNS groups (like GSLB pools per DC) within impacting the 'local'cluster?

 

Thanks :-)

 

  • There are many ways to do this - GTM does not often use LTM failover for the listener ( though it can ). Ideally, you want your GTMs to all be in sync so if this were me then i would have 4 GTMs, all in a single sync group.

     

    • jwilkes's avatar
      jwilkes
      Icon for Nimbostratus rankNimbostratus

      How do you setup GTMs to do LTM failover for listener?

  • The HA configuration "local" has no relation with GTM Sync Group. You can have an HA configuration,... active/standby, active/active.

     

    GTM is always standalone (and implicitly active). If you have more than one GTM, they will work together. For example, splitting work (like monitor), and sharing data (DNS zone files, WIPs, DNS pools).

     

    When you have LTM and GTM together, LTM will still work independently from the GTM, but you can configure the GTM to take advantage of "local" HA clustering.

     

    The GTM listener is a LTM virtual server for all intents and purposes. If you use the floating IP, only the active unit will respond to queries. If you configure the GTM devices with Listeners using the non-floating self IP, both can process DNS requests. Keep in mind the last scenario means that the DNS clients will have both IPs configured for DNS Servers.

     

    More simply put, the HA "local" clustering, and the GTM Sync group clustering are completely separate.

     

    Based on your overview, I would think you would want two HA clusters with one listener each. And all 4 GTM devices, in a sync group, sharing all DNS information (Bind, WIPs, GTM Pools,,.. and so on.). Also, depending on how you monitor the resources, use prober pools to keep the heavy lifting localized.

     

    Hope it helps!

     

    Good luck!

     

  • GTM Troubleshooting steps for GTM sync

     

     

    1. Have you checked if GTM sync group is working between both the GTMs you are expecting to see each other

     

    tmsh show /gtm iquery all

    tail -f  /var/log/gtm | grep -i -e -n iquery

     

    run iqdump from bash mode on both the GTMs and see If the iQuery channel is not established, iqdump returns with an SSL error similar to the following example:

     

    iqdump 10.178.3.120

     

     

    In the case of the BIG-IP DNS device not properly setup, you may want to re-run the gtm_add utility on the affected BIG-IP DNS device again

     

     

    1. BIG-IP DNS synchronization group members must be running the same software version

     

    1. Synchronization must be enabled and each device must have the same synchronization group name. You can define the synchronization parameters by navigating to:

     

    BIG-IP DNS 11.5.0 and later:

     

    DNS > Settings > GSLB > General

     

     

    1. NTP must be configured on each device

    You can configure NTP by navigating to System > Configuration > Device > NTP

     

    tmsh list /sys ntp servers

     

     

    Check the logs

     

    tail -f  /var/log/gtm | grep -i -e -n ntp

    tail -f  /var/log/ltm | grep -i -e -n ntp

     

    1. Port Lockdown must be set properly for the relevant self IP addresses

    You can configure port lockdown by navigating to Network > Self IPs.

     

    tmsh list /net self allow-service

     

    1. Check if these port are able to communicate between both the GTMs on the specific self IP

     

    Allowed Protocol              Service Service Definition

    TCP        4353       iQuery

    TCP        22                           SSH

    TCP        53                           DNS

    UDP       53                           DNS

    UDP       1026       Network Failover

     

    from bash check netstat and see if they can see each other IP there

     

    netstat -na | grep 4353

     

    tail -f  /var/log/gtm | grep -i -e -n 4353

     

    1. try tcpdump on port 4353

     

    tcpdump -nni 0.0:nnn -s0 tcp port 4353 -w "/var/tmp/$(/bin/hostname)_$(date +%Y-%m-%d-%H-%M-%S)_iquery.pcap"

     

     

     

     

    1. BIG-IP DNS synchronization group members use TCP port 4353 to communicate. You must verify that port 4353 is allowed between BIG-IP DNS systems.

     

     

    1. Compatible big3d versions must be installed on synchronization group members , run following from bash mode

     

    big3d -v /shared/bin/big3d -v

     

    tail -f  /var/log/gtm | grep -i -e -n big3d

     

    1. A valid device certificate must be installed on all members

     

    The default device certificate, /config/httpd/conf/ssl.crt/server.crt, must be installed on each sync group member. You can verify the certificate validity by navigating to System > Device Certificates.

     

    Check the status of the device certificate by entering the following command:

    openssl x509 -noout -text -in /config/httpd/conf/ssl.crt/server.crt

     

     

    1. Check for the system logs a successful iQuery connection to the /var/log/gtm file.

     

    tail -f  /var/log/gtm | grep -i -e -n iquery

     

     

    Check If the iQuery protocol is blocked by router or firewall ACL ;

     

     

    1. Check the GTM specific daemons

     

    tmsh show sys service tmm mcpd big3d gtmd

     

    tail -f  /var/log/gtm | grep -i -e -n mcpd

    tail -f  /var/log/gtm | grep -i -e -n big3d

    tail -f  /var/log/gtm | grep -i -e -n gtmd