iQuery/ Big-IP DNS server certificate trust problem
Unable to establish iQuery between bigip devices. Connectivity is in place but failing with: SSL error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed I take this to be a certificate chain failure. The device certificates have been added to both DNS > GSLB > Servers > Trusted Server Certificates and System > Cert Mgmt > Device Cert Mgmt > Device Trust Certs. Yet, still no joy, running openssl confirms trust issues. Device certs are issued by a 2 tier PKI (intermediary and root). Big IP is 13 HF 2. Any suggestions? Is it common place to be using internal certs here?
f5 enterprise manager fails to connect to LTMS
Hello, I have a handful of ltms that cant communicate with EM. There is about half that can talk to the the EM and half that cant. The LTMS are 11.4.1 and EM is 3.1.0. The EM talks to the LTMs fine with iquery communication in the dump logs being ok. On of one of the LTMs in question it was discovered by an engineer who is still working on the case that I have already open, he found these errors on one of the LTM's a couple of days ago: 67 May 21 14:44:18 aprcorpextltm1 err eventd[8174]: 012d0012:3: Notification attempt to consumer id D6E738E8- 1974-626A-2E52-EF1569494AD FAILED with error Failed to connect to host 10.58.1.124, port 443: Operation already in progress. 108 May 21 16:31:33 aprcorpextltm1 err eventd[8174]: 012d0012:3: Notification attempt to consumer id 7451CF6C- 1974-F300-1696-9E58A25A09A FAILED with error Failed to connect to host 10.58.1.124, port 443: Operation already in progress. Anyone run into this before ? Thanks
iQuery Network Latency Guidelines
Are there any guidelines on network latency maximums to be followed to have iQuery between GTMs and LTMs be successful? Any F5 "best practices" around directing the iQuery communications over internal links between the systems or over the Internet (via IPSec VPN Tunnels) if spread across different data centers? Or are there restrictions on which interfaces iQuery can be established between the GTMs/LTMs?Seeking easiest way to get iQuery grid working, with new GTM being added
Hi, all - we have a BIG-IP DNS controller we're trying to add to our iquery grid - but it has a newer TMOS (and thus newer big3d) version than our existing GTMs and LTMs. Existing GTMs: 11.5.2 final New GTM: 11.5.4 Existing LTMs: 11.5.2 final (match the existing GTMs) For logistical reasons, I'd like to avoid upgrading TMOS on all the existing equipment at this point. The articles say to make sure you're GTMs are all at the same TMOS version - but I see in the answers that people are successful as long as all the GTMs have the same big3d version (and the LTMs have that big3d version or newer). Is that true, based on your experience, that GTMs can in fact be at slightly different versions, as long as the big3d installs match? If so - and looking for the quickest/easiest path here - is it possible to install a back-leveled 11.5.2 version of big3d on the new GTM? big3d_install script won't do it, because it detects the newer 11.5.4 version of big3d on the new GTM. Is there a manual procedure that will permit back-leveling of big3d? If not - I assume it would work to upgrade just big3d on the existing GTMs and all the LTMs, to match the new GTM? Barring that, is it necessary to back-level the TMOS version on the new GTM to 11.5.2, just to get that older version of big3d? That will involve a trip to the unmanned data center, to build it from scratch again, since the existing 11.5.4 config won't copy into the older 11.5.2 boot image. Of course, eventually, we'll update all this equipment - but as a holding position, would like to get this new GTM in with as little perturbation as possible. thx
iQuery not Returning VIP data from LTM
I have a GTM (12.0.0) and an LTM (12.0.0) setup and have gone through the steps to set up communication between them using bigip_add. When I run a iqdump on the GTM, I see "server" data and "getconfig_element" data being returned but not "vip" data. I run tcpdump on the LTM and I see iquery communications coming in and going out of the LTM. Based on this, I assume the trust is set up correctly. The LTM has a "Green" status and I can go directly to it and reach my web server. Problem is, the GTM shows the LTM object as "Red" and will not return the IP address. We verified the LTM object defined in the GMT has the correct IP address and port number. Has anyone seen this before? Thankschoosing self-IPs for iQuery communication
I'm looking for advise on choosing self-ips for iQuery communication between BigIP-DNS (GTM) and LTM. We considered using the LTM virtual server self-IPs, but that net is most likely to experience external (ddos) attacks. We could configure a small network just for iQuery, but that seems like overkill. I'm curious to hear any thoughts/best practices regarding how self-IPs were chosen for bigip_add to exchange iquery SSL certificates with a remote BIG-IP system and ongoing iQuery communication.
GTM Multiple iQuery Connections to same LTM
Hi, I've noticed that GTMs typically have multiple iQuery connections going to the same LTM. Does this serve some kind of purpose? Are there different status updates from each IP in this case, or would the information just be getting duplicated across each connection? ThanksiQuery fails between GTM & LTM
POST EDITED Hi all Last night I attempted to enable iQuery between our GTMs and LTMs, however, it failed. To walk through the steps here's what I did: Ensured the Self-IPs to which I would be establishing the iQuery to on the LTMs was set to Port Lockdown "Allow Default" Tested that iQuery, SSH and HTTPs weres not blocked via any firewalls: nc –v –s GTM IP <-> LTM IP 4353/22/443. All returned a success. Great! Attempted to run the bigip_add command from the GTM -> LTMs in DC1 by targeting the LTM Self-IPs: bigip_add4. Attempted to run the big3d_install command from the GTM -> LTMs in DC2 by targeting the LTM Self-IPs. From the GTMs to one set of LTMs (in data centre 1) I received the following output: Retrieving remote and installing local BIG-IP's SSL certs ... Enter root password for -a if prompted ssh: mkdir -p /config/big3d; if [ -e /config/httpd/conf/ssl.crt/server.crt ]; then cat /config/httpd/conf: Name or service not known ERROR: Can't read remote cert via /usr/bin/ssh. Enter root password for admin@x.x.x.x if prompted ssh_exchange_identification: Connection closed by remote host ERROR: Can't read remote cert via /usr/bin/ssh. ==> Done <== On the other link, that is, the GTMs to the LTMs in data centre 2 I received a different problem: Unable to retrieve version and platform information via iqsh for x.x.x.x Attempting via ssh ... Password: (Entered password 3 times) Permission denied (publickey,keyboard-interactive,hostbased). Unable to retrieve tmsh and/or big3d versions from x.x.x.x Regarding the first issue I found an article that seems to describe our first problem: “SOL13823:The bigip_add script fails to connect to BIG-IP systems running in Appliance mode” http://support.f5.com/kb/en-us/solutions/public/13000/800/sol13823.html However, our LTMs are not in appliance mode, but our GTMs are!? And in addition, we actually already have an iQuery between another pair of LTMs and these very same GTMs. Regarding the second issue, as per the steps above the big3d versions were different so I attempted to run the big3d_install command. I'm wondering if the admin user I am putting in doesn't have the correct permissions. Currently the admin user does not have tmsh rights. Could this be the issue? The versions we're running are: GTMs: 11.2.1, LTM (DC1): 11.4.1, LTM (DC2): 10.1.0 Any advice? Thank you
