tmsh equivalent of 'b shell partition' command?

Our company is new to F5 and last April we started a project to use the F5 instead of the plugin. It took me two months to figure out all of this stuff and basically what you have it was I did. Of course since we were new to the F5, I had to learn how to do things on the F5 and learn iRules (I had never seen TCL before). I'm glad to see that what I did was the right way to do it.

 

 

One point though. There is a problem with using the iRule to use the JSESSION cookie for session persistence in the case where you have multiple pools. An fairly easy modification to that iRule is instead of using the full cookie as the persist key is to only use the 1st 26 positions, all the way up to the ":".

 

 

The issue is that the cookie has the jessionid that is unique to this session and then a unique identifier is added to the end for each WebSphere server you end up using. With two pools you have two servers. So as you get switched to another server the cookie value changes.

 

 

We have four pools, so you could get sent to four different servers. Each server tags the end of the JSESSION cookie with their unique id and thus the cookie value gets changed.

 

 

This all assumes that the WebSphere Servers are setup to share the JSESSION cookie. If they are not, then you get into real trouble.

Good points, thanks for the comment.

 

Looks like you could use the logic from the ASPSessionID Persistence iRule to build that solution for JSessionID: http://devcentral.f5.com/wiki/default.aspx/iRules/ASP_SessionID_Persistence.html

I'm a WebSphere admin and I've been experimenting with replacing the WAS plugin with some config on LTM. I also noticed the following issues:

 

 

1) for WebSphere V6, if you only intend to use port 80 on the Virtual you would need an iRule similar to the following to stop the client request being redirected to the Websphere port - 908x , otherwise, a virtual with the corresponding 908x port would need to be created and that doesn't look very nice on the client's browser.

 

 

when HTTP_RESPONSE {

 

if { [HTTP::is_redirect] } {

 

log local0. "Request redirected. Original value: [HTTP::header value Location], updated value: [string map -nocase {9081 80 9082 80} [HTTP::header value Location]]"

 

Do the update, replacing port 9080 with 80

 

HTTP::header replace Location [string map -nocase {9081 80 9082 80} [HTTP::header value Location]]

 

 

}

 

}

 

 

2) For WebSpehre V5, one would need to add additional virtual host alias on the Websphere setup so it accepts traffic on the 908x port with the real IP of the WebSphere server. I also had to add a stream profile to correct any reference to the 908x port on the HTTP response ( the above rule for V6 redirect does not work). I'm not sure whether this is application specific problem or an issue across all Websphere V5 installation.

deb:

 

 

Thanks for pointing me to the ASP iRule and that is basically what I did.

 

 

sh710:

 

 

The redirect issue is not isolated to WebSphere. It is actually an issue anytime the backend server does not listen on port 80.

 

 

With your WebSphere V5 issue it is most likely an issue in any WebSphere or J2EE/Java Server.

 

My guess is your applciations is using dynamically generated HTML using system varaibles. So the HTML has the host name and port that WebSphere is using, but that is not the host name that is used to get to the F5. So, as you did, you need to create a stream profile that replaces what WebSphere puts into the html code with what is needed to get back to F5.

 

 

I know I had this issue where we had a page that was dynamically created that had variables that were passed to a Java applet. Since the host name and port in the web page did not match the host name in the browsers URL, the applet did not work. So, one stream profile later and everything worked.

giltjr,

 

 

Thanks for the comments and the confirmation for the use of stream profile. However, I cannot 100% agree with you on the port redirect - we also tested using the LTM to distribute traffic among two IBM HTTP Server (Apache) where they're listening on ports such as 908x , and the redirect rule was not needed to setup the virtual to listen on 80.

 

 

Simon

I guess I was not clear. Anytime the backend server, of anytime, issues redirects and the pages are dynamically built you will need the redirect rule. If there is no redirects or the pages are static and do not refer to the real port that the backend server is listening on, you do not need the redirect rule.

Couple questions for those who have set this up before. What kind of overhead will something like this add to the LTM? Are there any drawbacks you have found to this kind of setup?

We've explored this option but at the end we decided to use a local IHS on the WAS box. the main reason for that is the ease of administration on the plugin if you have hundreds of websites with different context roots.

There's an easier way to do this. Go ahead and set up the pool directly to the java nodes (IP/port). Depending upon your install this could be a large pool as there are generally several nodes per physical server.

 

We're almost done!

 

Next, go into the Websphere admin console and check the "trusthostheadersport".

 

Finished.

Do what?