Catch specific SSL errors/failures???

If you do, could you post back with what you find for future reference?

 

 

Thanks, Aaron

Ok, results are in...

 

 

With the 'get ifile' command on each request:

 

 

show CatchSSLErrors

 

 

--------------------------------------------

 

Ltm::Rule Event: CatchSSLErrors:HTTP_REQUEST

 

--------------------------------------------

 

Priority 10

 

Executions

 

Total 200

 

Failures 0

 

Aborts 0

 

CPU Cycles on Executing

 

Average 664.4K

 

Maximum 1.6M

 

Minimum 0

 

 

-----------------------------------------

 

Ltm::Rule Event: CatchSSLErrors:RULE_INIT

 

-----------------------------------------

 

Priority 500

 

Executions

 

Total 1

 

Failures 0

 

Aborts 0

 

CPU Cycles on Executing

 

Average 0

 

Maximum 0

 

Minimum 0

 

 

 

With the 'get ifile' commands in the RULE_INIT block:

 

 

show CatchSSLErrors

 

 

--------------------------------------------

 

Ltm::Rule Event: CatchSSLErrors:HTTP_REQUEST

 

--------------------------------------------

 

Priority 10

 

Executions

 

Total 200

 

Failures 0

 

Aborts 0

 

CPU Cycles on Executing

 

Average 639.6K

 

Maximum 1.0M

 

Minimum 0

 

 

-----------------------------------------

 

Ltm::Rule Event: CatchSSLErrors:RULE_INIT

 

-----------------------------------------

 

Priority 500

 

Executions

 

Total 1

 

Failures 0

 

Aborts 0

 

CPU Cycles on Executing

 

Average 0

 

Maximum 0

 

Minimum 0

 

 

 

This was with a request size of 200 attempts...

 

 

So there's definitely a difference between the 2..

 

Is it likely to make a big difference? As I'm not that familiar with what's good and what's bad when it comes to iRules and timings...

 

 

Cheers

 

Gav

Thanks for testing. 200 requests should be enough to get an idea of the average CPU cycles each version uses. To compare, the ifile get in RULE_INIT version is ~4% more efficient:

 

 

664 - 639 / 639= 3.9%

 

 

Not as much as I expected, but still good enough in my mind to justify doing the ifile get once in RULE_INIT. I guess it's a sign that doing the ifile get is pretty efficient.

 

 

Aaron

Indeed...

 

 

Probably also worth noting that this was run against a v11 Virtual install...

 

I also upped the thread count to get 2k hits, and it showed a very similar percentage difference... So appears to scale linearly...

 

 

I'll run the same tests against a physical device when I get a chance to see if that gives a bigger margin...

 

 

Cheers

 

Gavin

FYI, I've also added a slightly modified version of this rule to Codeshare...

 

Just removed the Logo lines which are specific to our implementation...

 

 

The link is: http://devcentral.f5.com/wiki/iRules.Catch-SSL-Errors-and-return-a-friendly-page.ashx

 

 

Cheers again.

 

 

Gav

That looks great. Thanks for adding it to the codeshare.

 

 

One small suggestion, I don't think you need the event disable or return commands as you have everything wrapped in if/elseif/else's.

 

 

Aaron

Aaron

 

 

I added them in as I was getting 'multiple redirect/respond invocation' errors logged from other rules that I've got set-up...

 

 

So just did it to ensure that no other processing would take place...

 

 

Am happy to make a change if there's a better way though...

 

 

Gav

Aaron

 

 

I added them in as I was getting 'multiple redirect/respond invocation' errors logged from other rules that I've got set-up...

 

 

So just did it to ensure that no other processing would take place...

 

 

Am happy to make a change if there's a better way though...

 

 

Gav

How about trying TCP::close after HTTP::respond without event disable or return? Do you still see the multiple redirects runtime error?

 

 

HTTP::respond...

 

TCP::close

 

 

Aaron

Yeh, I was seeing these errors frequently:

 

Jan 18 14:11:37 tmm info tmm[9144]: Rule /Common/Catch_SSL_Errors : Catch_SSL_Errors HTTP Request:

 

Jan 18 14:11:37 tmm info tmm[9144]: Rule /Common/Catch_SSL_Errors : SSL Connection initiated... Verifying client certificate.

 

Jan 18 14:11:37 tmm info tmm[9144]: Rule /Common/Catch_SSL_Errors : SSL::cert returned the following output... ''

 

Jan 18 14:11:37 tmm info tmm[9144]: Rule /Common/Catch_SSL_Errors : No Client cert presented. Returning error page...

 

Jan 18 14:11:37 tmm err tmm[9144]: 01220001:3: TCL error: /Common/ProxyPass - Operation not supported. Multiple redirect/respond invocations not allowed (line 1) invoked from within "HTTP::redirect "$proto://[HTTP::host]$rurl" "

 

Jan 18 14:11:37 tmm info tmm[9144]: Rule /Common/Catch_SSL_Errors : Catch_SSL_Errors HTTP Request:

 

Jan 18 14:11:37 tmm info tmm[9144]: Rule /Common/Catch_SSL_Errors : Returning Logo...

 

Jan 18 14:11:37 tmm info tmm[9144]: Rule /Common/Catch_SSL_Errors : SSL Connection initiated... Verifying client certificate.

 

Jan 18 14:11:37 tmm info tmm[9144]: Rule /Common/Catch_SSL_Errors : SSL::cert returned the following output... ''

 

Jan 18 14:11:37 tmm info tmm[9144]: Rule /Common/Catch_SSL_Errors : No Client cert presented. Returning error page...

 

Jan 18 14:11:37 tmm err tmm[9144]: 01220001:3: TCL error: /Common/Catch_SSL_Errors - Operation not supported. Multiple redirect/respond invocations not allowed (line 77) invoked from within "HTTP::respond 403 content [subst $error_page] "Content-Type" "text/html" "Connection" "Close""

 

 

 

Though as part of the error page, the Browser needs to request the logo after the html is returned... But from the above logging it was before the browser was even trying to get the logo...

 

 

Will give TCP::Close a try... Benefits over return + disable event?

 

 

Cheers

 

Gav