bigip.conf won't load due to invalid requested attribute
I inherited a production configuration. The top of bigip.conf is: datastor { low water mark 80 high water mark 90 } deduplication {} shell write partition Common v10 b verify load returns: The requested attribute (deduplication {) is invalid for 'datastor'. A similar but different bigip.conf, with the same beginning lines does not return this error. Is this a false positive? Is there a recommended way to troubleshoot?
ProxyPass v10/v11 modifications - how to share?
I've just started using the ProxyPass v10/v11 iRule to move a number of Apache mod_proxy reverse proxies to our F5 HA pair. The first site moved was a simple HTTP clientside to HTTP serverside with no payload rewriting and it worked perfectly as documented. Then I started to see things that could be improved and a few things that didn't work and could be fixed. Localised Options The static::ProxyPassDebug and static::RewriteResponsePayload are inconvenient when the iRule is used by multiple virtual servers, so I've localised these for each virtual server in a new Data Group "ProxyPassOptionsVIRTUAL". Protocol Rewriting We offload SSL to some of our proxies so I found the request header and referer rewriting wasn't rewriting the protocol, resulting in the browser getting connection errors at least, I think, unless the virtual server accepts both HTTP and HTTPS in which case the iRule appears to trap the unchanged protocol in the new request and rewrites and redirects it back to itself. I have fixed this by inferring the serverside protocol for each pool from the ProxyPassSSLProfile information if it exists. There are a couple of assumptions/requirements supporting this method: 1. If any pool, default or alternative, requires SSL it must have a server profile entry in this data group. 2. The clientside protocol is detected via the CLIENTSSL_HANDSHAKE event. Response Payload Protocol Rewriting Payload rewriting doesn't rewrite the protocol. I have fixed this also following from previous item. Response Payload Rewriting Generally I think payload rewriting is incomplete if it only rewrites matching the current request URL components. That is, currently for a request rewrite e.g. "http://www.company.com/some/path" to "", the response payload will reverse only this URL. If the payload includes other absolute URLs e.g. "", this will be missed. So the iRule needs to be modified to rewrite just the "protocol://host_serverside" part for all URLs starting with that string, but it also needs to rewrite any path components that start with any path component in "ProxyPassVIRTUAL" that match the serverside host. For example, given the following "ProxyPathVIRTUAL": "www.company.com/some/path" := "backend.internal/other/path" "www.company.com/some/other/path" := "backend.internal/yet/another/path" Given a request "http://www.company.com/some/path", all of the following rewrites need to occur if found in the response payload: "http://backend.internal/other/path" -> "http://www.company.com/some/path" "http://backend.internal/yet/another/path" -> "http://www.company.com/some/other/path" "http://backend.internal/unchanged/path" -> "http://www.company.com/unchanged/path" "/other/path" -> "/some/path" "/yet/another/path" -> "/some/other/path" URL rewriting and Case (In)Sensitivity The original iRule assumes case sensitivity, which may be valid but is impractical. Unfortunately, we have a backend application running on Windows and the developers were arbitrary about case, hence an inbound request in lowercase will go through ok but response headers and payloads may contain the URL in uppercase. Apache mod_proxy appears, from our experience, to handle this somehow, I assume by checking each response URL against all paths listed for proxying. Our Apache reverse proxy lists each path as lower and upper case and we have not had a problem. This is the same problem as "Response Payload Rewriting Generally" applied to header rewriting. Current thinking is to add an option "ProxyPassURLDownCasing" to invoke down casing of all URL path elements before checking and rewriting. The option needs to be settable per pool, so the option value would probably be a list of pools. Code Sharing I haven't implemented the latter two items yet but I'm happy to provide the modified iRule code once I have if someone can tell me how I can upload it. I don't have any dev points to upload it directly and I tried posting the first three mods to this iRules forum but exceeded the word count and was rejected. Thanks.
Having to upgrade from v10 to v11 manually?
Hello everybody, I need to replace an old BIG-IP 1500 platform with a stronger and newer one, and now I’m facing a weird situation: The old one cannot be run with v11, the new one not with v10. Sticking to the askf5 best practice articles, I couldn’t find anything for such a situation. In DevCentral I found the /usr/libexec/bigpipe daol command and gave it a try: Well, I had to delete nearly all of the HA-configuration and a lot of other stuff because of error messages. After that, it proceeded some steps further but then ran into a segmentation fault. :-( So, is there any other way I could do a migration automatically? Converting it manually would be a life’s work… Thank you very much for your contributions!