Forum Discussion
ularssx_95224
Nimbostratus
Nimbostratushttp redirect irule issue
Hello all -
I have what I thought should be a simple rule.
when HTTP_REQUEST {
if { [matchclass [HTTP::uri] contains $::siloSIRSI ] } {
pool syndetics2.com-linux
} elseif { [matchclass [HTTP::uri] contains $::clientURI ] } {
pool syndetics.com-linux
} elseif { [matchclass [HTTP::uri] contains $::badclient ] } {
pool Bad_Clients
} else {
pool Syndetics.com
}
}
All I am trying to do is pattern match against the inbound URI. I.E if it matches the first send to pool siloSIRSI, etc etc and the default pool is Syndetics.com - which is the pool the virtual server this rule is attached to is set to go to - I am not even sure if that final else is needed.
When I apply this rule it seems that requests that don't match the above rules go to limbo. Is there a better way to do this.
Thanks in advance if this is extremely obvious
Sean
4 Replies
hoolioCirrostratus
Hi Sean,
The rule looks fine as far as the syntax goes. Can you add logging to the iRule and provide more detail on which requests fail and what log output you see for a failure?when HTTP_REQUEST { log local0. "[IP::client_addr]:[TCP::client_port]: New request to [HTTP::host][HTTP::uri]" if { [matchclass [HTTP::uri] contains $::siloSIRSI ] } { log local0. "[IP::client_addr]:[TCP::client_port]: Using pool syndetics2.com-linux" pool syndetics2.com-linux } elseif { [matchclass [HTTP::uri] contains $::clientURI ] } { log local0. "[IP::client_addr]:[TCP::client_port]: Using pool syndetics.com-linux" pool syndetics.com-linux } elseif { [matchclass [HTTP::uri] contains $::badclient ] } { log local0. "[IP::client_addr]:[TCP::client_port]: Using pool Bad_Clients" pool Bad_Clients } else { log local0. "[IP::client_addr]:[TCP::client_port]: Using pool Syndetics.com" pool Syndetics.com } }
Aaron
ularssx_95224Hi - thanks for the quick response. I was able to quickly enable some logging this morning for a few minutes. Here is some output:
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 136.148.109.151:45015: New request to syndetics.com/index.aspx?isbn=0070167001/sc.jpg&client=lsbuk
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 128.125.28.194:1528: New request to www.syndetics.com/index.aspx?type=xw12&isbn=9783527304387/INDEX.XML&client=uschs
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 140.163.254.157:28696: New request to www.syndetics.com/index.aspx?type=xw12&isbn=0790772663/SC.GIF&client=nypp
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 199.5.204.100:43270: New request to syndetics.com/index.aspx?isbn=0737736259/SC.GIF&client=sirsi&type=rw12
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 140.163.254.157:36683: New request to www.syndetics.com/index.aspx?type=xw12&isbn=0790734206/SC.GIF&client=nypp
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 192.30.202.18:45639: New request to syndetics.com/index.aspx?isbn=9780233002071/SC.GIF&client=sirsi&type=rw12
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 153.2.246.30:44601: New request to syndetics.com/index.aspx?isbn=9780783229522/sc.gif&upc=025192033926&oclc=&client=qubop
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 168.8.111.9:57343: New request to syndetics.com/xw12.pl?isbn=9780439700009/sc.gif&client=surpd
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 66.84.234.234:3899: New request to www.syndetics.com/index.aspx?type=xw12&isbn=0780613805/SC.GIF&client=sclsp
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 204.184.80.26:8477: Using pool syndetics.com-linux
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 158.132.12.80:27686: New request to syndetics.com/index.aspx?isbn=0471969338/SC.GIF&client=hkpua&type=rn12&upc=&oclc=
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 208.119.151.48:55963: New request to syndetics.com/index.aspx?isbn=9781599830582/SC.GIF&client=sirsi&type=rw12
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 208.119.135.19:46964: New request to syndetics.com/index.aspx?isbn=0671040634/SC.GIF&client=sirsi&type=rw12
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 72.1.195.7:38403: New request to www.syndetics.com/index.aspx?type=xw12&isbn=9781885535696/INDEX.XML&client=ottap
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 158.132.12.80:27687: New request to syndetics.com/index.aspx?isbn=1402022433/SC.GIF&client=hkpua&type=rn12&upc=&oclc=
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 206.131.30.1:30292: New request to www.syndetics.com/index.aspx?type=xw12&isbn=024543055396/SC.GIF&client=wclip
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 192.30.202.18:45643: New request to syndetics.com/index.aspx?isbn=9781904950851/SC.GIF&client=sirsi&type=rw12
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 142.227.55.61:1126: New request to syndetics.com/index.aspx?isbn=0440226406/SC.GIF&client=22325&type=rw12
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 210.6.34.79:1856: New request to syndetics.com/index.aspx?isbn=9780195188493/MC.GIF&client=uohkch&type=rw12
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 67.59.92.6:39566: Using pool syndetics.com-linux
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 76.19.61.179:3825: New request to www.syndetics.com/index.aspx?type=xw12&isbn=9780061253096/SC.GIF&client=mevap
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 153.2.246.30:24422: New request to syndetics.com/index.aspx?isbn=9781559409308/sc.gif&upc=&oclc=&client=qubop
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 167.206.79.227:30829: New request to www.syndetics.com/index.aspx?isbn=9781402215230/SC.GIF&client=grenp&showCaptionBelow=t
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 130.111.64.52:59553: Using pool syndetics.com-linux
Mar 10 09:44:28 tmm tmm[994]: Rule SiloRedir_Logging : 209.143.35.128:4485: Using pool syndetics.com-linux
All we are doing currently with this traffic is the following rule:
when HTTP_REQUEST {
if { [matchclass [HTTP::uri] contains $::clientURI ] } {
pool syndetics.com-linux
}
}
Which basically sends all traffic to the virtual server it's attached to unless it's pattern matched against the data group. It seems something isn't quite right when I try to send to different pools- ularssx_95224Not to reply to myself - but what appears to be breaking is traffic that doesn't match any of the data groups - i.e traffic that should be destined to the virtual server the rule is attached to - you get a connection interrupted at that point - but it immediately started would start working if I backed out the new rule. I must be missing something obvious
- hoolioIf a client makes multiple requests over the same TCP connection, subsequent requests will not necessarily be sent to the default pool. It's always better to specify a default (or "else") clause in the iRule if you're selecting a pool. You can do this without hardcoding the name of the default pool:
when CLIENT_ACCEPTED { Save the name of the VIP's default pool set default_pool [LB::server pool] } when HTTP_REQUEST { if {$some_condition==1}{ pool pool_1 } elseif {$some_other_condition==1}{ pool pool_2 } else { Use the VIP's default pool pool $default_pool } }
Aaron
