Forum Discussion
AltostratusAS3 Json for pool creation
Have you seen https://clouddocs.f5.com/products/extensions/f5-appsvcs-extension/latest/userguide/faq.html ?
Does BIG-IP AS3 support multi-tenancy?
- Yes, BIG-IP AS3 creates and uses additional partitions to enable multi-tenancy
- BIG-IP AS3 ONLY writes to the Common partition when you specifically use the Common tenant with the Shared application (/Common/Shared); see the next FAQ entry
- BIG-IP AS3 writes to the Common partition as required for some GSLB configurations
- BIG-IP AS3 does NOT have access to tenants/partitions other than those it creates and /Common
Nimbostratus
Anyway, where were we ... Oh yes, I was working on two problems.
The mod 12 calculation works fine up until the number is larger than 9 digits. After 9 it fails the integer check. -strict has no effect.
For using catch to catch runtime errors works well until I added a "return" command within the catch. The return works but the check for != 0 always fails and I get a syslog message with no text. I tried using "return 0" (syslog message is "0". "return -code 0" also gets a syslog message with no text.
What am I doing wrong?
Another question I have is in regards to the [LB::server addr] variable. If is have a value ie an IP address should it pass an If info exist test. Second, if the LB_FAILED is caused by a real pool failure does [LB::server addr] have a null value or does it not exist?
Regards,
Bret
- Kevin_Stewart
Employee
Do you have any iRule logic applied? Something that may be adding ":443" to the HTTP Host header?
Thomas_Bigler_3Only rule implemented is:
when HTTP_REQUEST { HTTP::redirect https://[getfield [HTTP::host] ":" 1][HTTP::uri] }- Kevin_Stewart
There's more pieces to this puzzle. Presumably you're using this iRule on an HTTP VIP to redirect traffic to an HTTPS VIP. You're saying "Location Header", so also guessing you mean a redirect.
If that's all correct, then the difference is in how the backend server responds - which redirect URL it sends back to the client. It could be that the :443 in the Internet request, however they're getting there, are informing the application that SSL offload is happening, and that's why it sends back the correct URL.
So a few additional thoughts.
-
When the LAN clients get the HTTP redirect URL, do they not go to the HTTP URL and get redirected to HTTPS? Or do they go into a redirect loop and fail?
-
Do you have any idea where the :443 is coming from? Could it be coming from the client, or another iRule on the HTTPS VIP?
-
You may also want to try enabling the Redirect Rewrite option in the HTTP profile. This setting enables the F5 to rewrite any HTTP URL redirects to HTTPS. Start with the All setting, and if that works, try the Matching setting.
-
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
