Refresh "older" APM Policy?
Hey all, Was curious to hear anyone's opinions on at what point during the lifecycle of an APM policy (for instance, i have one that has roots in v11.5) should I consider building a fresh one? Similarly, is there any guidance on converting a policy to Modern templates? Thanks, Josh
Is it possible to use the following Irule syntac with TCL in a policy ?
Hello, I've setup some code in an Irule . This concerns a code that will take the URI, within this uri, search for first directory in the path and put it tolower before sending it to the server. set uri [HTTP::uri] set block [lindex [split $uri /] 1] if { $block ne [string tolower $block]} { set block2 [string tolower $block] HTTP::uri [string map [list $block $block2] $uri] #log local0. "Rewrited part of the URI : $block2" #log local0. "URI Send to Back-end application : https://[HTTP::host][HTTP::uri]" } Is it possible to put this code in a TCL within a policy rule ? I need to replace the first directory of the URI (ie: "/APPLICATION/dir1/DIR2/index.html") to lowercase /application/dir1/DIR2/index.html ( the rest of the URI must stay intact, only /Application/ part must be set to lowercase. Thanks in advance. Regards FrédéricLTM Policy – Matching Strategies
Introduction LTM Policy is a highly performant-feature of the Big IP which allows administrators to inspect many aspects of the system and runtime traffic, and to take custom actions in response. As the name suggests, this is accomplished by creating policies, and unlike iRules, does not require programming. Every policy is a collection of rules, and is associated with a matching strategy. Every rule in a policy is like an if-then statement: it has a set of conditions and a set of actions, either of which may be empty, but not both. Conditions are the defined comparisons of runtime values against policy values. Actions are the commands which will get executed when the conditions match. As an example, one could define a policy with a condition that inspects the HTTP Referer: header, and if its hostname contains the string google.com, then take 2 actions: write a message to the system logs, and forward the connection to a certain pool. LTM Policy provides three matching strategies, described below. Matching strategies come into play when a policy contains more than one rule, because different rules can match at the same time, and different behavior may be desired depending on the situation. First Match With a first-match strategy in effect, as soon as any of the rules match, execute the associated actions and then stop all processing. This can be efficient, because once there is a match, no further effort is expended evaluating the conditions of the other rules. In the case that multiple rules match at the same time, then the ordinal property of each rule is consulted. The ordinal value is used for ordering rules, and lower value wins. All Match The all-match strategy is perhaps the most straightforward. It directs the policy engine to keep evaluating rules as traffic flows, executing the associated actions as conditions are matched. Best Match The best-match strategy is interesting and needs a little more background to describe its capability and customizability. The big idea behind best-match is to find the most specific match. When multiple rules match, the most specific match is deemed to be the one with either the most number of conditions that matched, the longest matches, or the matches which are deemed to be more significant. In the case where multiple rules match, and the rules contain the same number of conditions, then the ultimate tiebreaker is to consult the Strategy List. The Strategy List is the official system ordering or conditions, defining which are to be considered more significant than other conditions. It can be viewed in the GUI by visiting Local Traffic >> Policies >> Strategy List >> best-match , or via tmsh command line at ltm policy-strategy . The conditions at the top of the top of the table are considered more significant than those below, so the winning rule with be the one with the most significant conditions. The Strategy List is customizable to individual customer needs. It is probably not all that common, but should the default hierarchy of conditions not match expectations for the situation, the table can be customized by moving conditions up and down relative to each other. Be aware that that changes to the order affect all policies employing a best-match strategy, so consider trade-offs for customizing the order for one policy versus potential side effects on other policies that use a best-match strategy.Secure Cookie when the VIP is requested by IP (not URL)
Hello. I have a VIP config where the pool member is the one handling the cookie to the client. The pool member has a limitation when the client access the VIP via IP (not URL), the cookie is served not secured. I created this iRule which one of the side effects is an increased in the CPU utilization. when HTTP_RESPONSE { set cookies [HTTP::cookie names] foreach aCookie $cookies { HTTP::cookie secure $aCookie enable } } Is this the most efficient way? Is there a way to use a policy vs an irule? Thank you J
Will auto policy builder handle wildcards parameters like PAR1, PAR2, PAR3 -> PAR?
Hello, I am currently building up a policy in manual mode. Due to the size of this application, it requires a fair bit of work to add all parameters to the policy. A lot of these parameters are in the following form; PAR1 PAR2 iPAR1 iPAR2 PAR3 PAR4 ... PAR11 ... Does the automatic policy builder correctly build wildcard parameters with the numbers as a wildcard? Thanks. RegardsKeeping the original protocol in a policy
Hello, I am configuring a policy which will redirect to another URL keeping the original protocol (http or https) and URI. The URI is OK tcl:https://newURL.com[HTTP::uri] How I can do the protocol? If this is not possible, I guess I can have two rules/actions: one for http, one for https. Please comment Thank you JulioHTTP Policy
Hello, I am attempting to write an HTTP Policy that validate several aspects (HOST HEADER & URI) of a request before forwarding on to the default pool. When I had single values the policy was working great, now that I've add multiple values I no longer get the desired outcome. When I the apply URI check it begins to RESET all traffic. The check of /status and the HOST HEADER work without issue. Thanks! ltm policy /QA/API_SERVICES { controls { forwarding } requires { http } rules { ALLOWED_SERVICES { actions { 0 { log write message "DENIED ACCESS TO WEB SERVICE" } 1 { forward reset } } conditions { 0 { http-uri path not contains values { /favorites/ /users/ } //ONLY PERMIT IF URI CONTAINS ONE OF THESE VALUES } } ordinal 3 } DROP_STATUS_PAGES { actions { 0 { log write message "DENIED ACCESS TO STATUS PAGE" } 1 { forward reset } } conditions { 0 { http-uri path ends-with values { /status } //BLOCK ACCESS TO STATUS PAGES } } ordinal 2 } HOST_HEADER { actions { 0 { log write message "INCORRECT HOST HEADER" } 1 { forward reset } } conditions { 0 { http-host host not values { service1.domain1.ca service2.domain1.ca } //DOES THE HOST HEADER CONTAIN EITHER OF THESE VALUES } } ordinal 1 } } strategy /Common/first-match }Push Policy through REST or "tmsh -c" to 50 LBs
Hi! I am trying to push a (default) policy to all my 50 Lbs (running 12.1.4) where part of the rule is a location redirect value: tcl:https://[getfield [HTTP::host] ":" 1][HTTP::uri] I am having issues send the ":" Any suggestions? Thank you in advanced J
