F5 DNS iAPP Error

I would like to reproduce this error. What version are you running (tmsh show sys version)? It would also help if you would post the input values (obscure any IP addresses).

Thanks for the quick response. Here is the output from tmsh:

Product BIG-IP Version 11.6.0 Build 4.0.420 Edition Hotfix HF4 Date Mon Feb 16 02:21:25 PST 2015

As far as the input values, I've tried a lot of different options but here is an example:

Name: Test Template: f5.dns What IP address do you want to use for the virtual server? 192.168.1.250 Do you want to create a new pool or use an existing one? Create a new pool... Which servers are a part of this pool? 172.16.1.100 What fully qualified hostname do you want to send to the DNS server for this health monitor? test.mydomain.com

As you can see, there is nothing special here...just 2 private IPs. I didn't put in my actual DNS name, but it is internally resolvable if that matters. I also tried pre-creating a Node with that IP, as well as a pool with that Node as the only member. Same error.

Your inputs work just fine on my 11.6.0 HF4 machine. Pre-creating the node should not affect anything. Is there anything else that was configured on your BIG-IP prior to running the iapp? I'm stumped.

Found it. You must have an FQDN node configured. FQDN nodes were introduced in 11.6, and there is a known bug in 11.6 that causes this error with some iapps whenever an FQDN node is configured on BIG-IP, regardless of whether that node is associated with the iapp or not. The bug is fixed in upcoming 12.0, and is a candidate for the next 11.6 hotfix.

Fred -

Thank you very much for all of your help. Can I open a case even with a lab edition of the VE? Either way, my employer is looking at moving from v10.x to v11.x on their physical appliances this summer, so I am curious if this bug exists in the firmware for the physical appliances as well.

I'm having the same issue with a different iApp (sharepoint 2013). Is there a workaround till the hotfix comes out?

Is there an engineering hotfix for this? I'm encountering the same problem.

The fix is in test now and will get released in 11.6.0-HF6. I don't have a release date at this time.

Tim/Arie/Jie: I did not want you to have to wait for HF6. I ported the latest f5.dns template back to 11.6. Download f5.dns.v1.0.0 Let me know if you run into any issues.

So was this issue actually fixed in 11.6HF6? I'm running that version on an HA pair, but I'm observing the same issue.

script did not successfully complete: (field not present: "address" while executing "tmsh::get_field_value $node address" (procedure "iapp::destination" line 104) invoked from within "iapp::destination $::pool__addr $::pool__port_secure" invoked from within "iapp::conf create ltm virtual ${app}_vs destination [iapp::destination $::pool__addr $::pool__port_secure] mask $mask $vs_params ip-protocol tcp ..." invoked from within "subst $substa_out" invoked from within "if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] set substa_out [subst $substa_out] } else { ..." ("uplevel" body line 3) invoked from within "uplevel { append ::substa_debug "\n$substa_in" if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] ..." (procedure "iapp::substa" line 9) invoked from within "iapp::substa vs_arr($secure_client,$do_redirect)" (procedure "v11_4_main" line 429) invoked from within "v11_4_main" invoked from within "subst $substa_out" invoked from within "if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] set substa_out [subst $substa_out] } else { ..." ("uplevel" body line 3) invoked from within "uplevel { append ::substa_debug "\n$substa_in" if { [info exists [set substa_in]] } { set substa_out [subst $$substa_in] ..." (procedure "iapp::substa" line 9) invoked from within "iapp::substa main($do_v11_3,$upgrade,$downgrade)" line:937)