OT:

as of 5.3 its is NOT possible to have several "check" statements - last one 
rules over the rest.
Hopefully this can change.

Currently I have to specify two(2) checks in check_web.sh:
1. http-code 200
2. telnet, which returns '1' or '0'

2) is a check if I upgrade machine or not
Eg. port 80 might be up, but his does not means that "we are ready to accept 
any clients yet"

//mxb

On 16 apr 2013, at 19:50, mxb <m...@alumni.chalmers.se> wrote:

> 
> Hello list,
> 
> I currently have active-active CARP of two nodes with relayd and relayd(pf) 
> stops  forwarding packets if I do a "large file download".
> 
> Setup:
> two OpenBSD 5.3 connected to a Cisco stack, with 'balancing ip-stealth' on 
> external and 'balancing arp' on internal.
> Both external and internal are connected to the same stack, except that 
> external has its' own VLAN.
> 
> relayd handles redirects to internal web-farm and all works fine, until the 
> download of rather big file(600MB) is initiated from this farm.
> Then PF just stops to rdr packets in both directions.
> 
> redirect www {
>        listen on $EXT1 port $def_ext_httpport
>        listen on $EXT2 port $def_ext_httpport
> 
>        tag WWW
>        sticky-address
> 
>        forward to <webpool> port $int_httpport mode least-states check script 
> "/etc/check_web.sh"
>        forward to <web_fallback> port $int_httpport mode least-states check 
> http "/" code 200
> } 
> 
> What I can see in tcpdump, then it happens, is that internal machines which 
> just worked normally and handled this download, tries to push packets out, 
> but I don't see anything come out towards the remote host. relayd however 
> reports that all hosts, including this one, are up.
> 
> Of cause my CARP setup has pfsync with 'defer on', so states should not be a 
> problem in this case.
> 
> However, then I bring down one of the nodes into BACKUP on ALL carp, this 
> large http-download works as expected, e.g.. it completes and does not 
> stales. So as long as ONE of two nodes handles all traffic - it's all OK.
> 
> Any ideas?
> 
> //mxb

Reply via email to