Forum Discussion
gdoyle
Cirrostratus
CirrostratusiRule sending traffic to the wrong pool.
I have a fairly basic irule that seems to be sending traffic to the wrong servers and I can't figure out why.
when HTTP_REQUEST {
switch -glob [string tolower [HTTP::path]] {
"/web/*" { pool abc.webserver.com_new }
"/abc/xyz" { HTTP::respond 301 "Location" "https://admin.website.com[HTTP::path]/lmnop" }
"/abc/xyz/" { HTTP::respond 301 "Location" "https://admin.website.com[HTTP::path]lmnop" }
"/" { HTTP::respond 301 "Location" "https://admin.website.com/abc/xyz/lmnop" }
}
}
So this irule is fairly basic. It uses the pool attached to the VIP unless the URI is "/web/*", in which case it sends it to the abc.webserver.com_new.
Prior to me adding the "/web/*" line in there this irule worked without issue. However, the server teams stood up some new IHS servers, which is where they want the "/web/*" traffic going. However, they are seeing some of the "/web/*" traffic on the original pool rather than on the abc.webserver.com_new pool.
I tried to see some logs using tail -f /var/log/ltm while adding log local0 statement, but the irule editor was giving me fits about format being incorrect.
Has anyone seen anything like this where traffic isn't sent to the correct pool when the URI matches? Is there something wrong in my irule statement?
Thanks.
When you load balance to a server in a pool, the BIG-IP establishes direct TCP connections with that pool member (as a proxy would). If you're doing "content switching", where you're sending traffic to different pools based on some request criteria, you may run into a situation where the BIG-IP has an established TCP connection with one pool member and won't immediately sever that connection and start a new one somewhere else. The OneConnect profile (applied in the virtual server and in the associated HTTP profile) allows you to safely switch between pool members.
When you load balance to a server in a pool, the BIG-IP establishes direct TCP connections with that pool member (as a proxy would). If you're doing "content switching", where you're sending traffic to different pools based on some request criteria, you may run into a situation where the BIG-IP has an established TCP connection with one pool member and won't immediately sever that connection and start a new one somewhere else. The OneConnect profile (applied in the virtual server and in the associated HTTP profile) allows you to safely switch between pool members.
gdoyleThis is exactly the answer that was determined yesterday. Thank you!
