Hello list,
following relayd setup exists in prod:

relay int_health_check {
        listen on 127.0.0.1 port 78
        protocol http_relay
        forward to <hwpool> port 80 mode roundrobin check http "/" code 200
        forward to <fallback> port 80 mode roundrobin check  http "/" code
503
        forward to <m_vm> port 80 mode roundrobin check http "/" code 301
        forward to <fallback> port 9800 mode roundrobin check http "/" code
503
}

table <m_hw_pool> { 192.168.10.31 parent 1, 192.168.10.32 parent 2, \
                        192.168.10.33 parent 3, 192.168.10.34 parent 4, \
                        192.168.10.35 parent 5, 192.168.10.36 parent 6 \
                }

table <m_vm_pool> { 10.2.128.34 parent 9, 10.2.128.35 parent 10, \
                        10.2.128.36 parent 11, 10.2.128.37 parent 12, \
                        10.2.128.38 parent 13, 10.2.128.39 parent 14 \
                }

table <fallback_copy> { 192.168.10.83 parent 7, 192.168.10.84 parent 8 }

The dance above, if unclear, is done to eliminate number of health checks per
relay and copy the
state of machines into each relay using those pools. We have several relays.
Below is one of those.

relay se_m_tls {
        listen on $VIP22 port 443 tls
        listen on $VIP23 port 443 tls
        protocol tls_accel
        forward to <m_vm_pool> port 80 mode roundrobin check http "/" code
200
        forward to <m_hw_pool> port 80 mode roundrobin check tcp
        forward to <fallback_copy> port 80 mode roundrobin check tcp
}

The idea here is obvious, is to fall through until client reaches
<fallback_copy>.

With relay above, status is following:
m_vm_pool is enabled
m_hw_pool is disabled
fallback_copy is enabled

We decided to test fallback_copy and thus I disabled m_vm_pool as well.
Expected result is that all traffic
should end up in fallback_copy and display very simple index.html. Actual
result is that relay continued to operate
as usual, eg. serving PHP generated content.
This test was done from a different location so no prev. states existed in
PF.
Eg. disable first, then surf.

Is this expected behavior ?

I also noted, that if I disable parent table, eg for example <hwpool>, hosts
within the pool never get status UNKNOWN and thus
appear UP in all child tables (<m_hw_pool>).
My understanding is that if table is disabled, relayd will stop checking hosts
within table
and those eventually should switch status to UNKNOWN. As well as the rest on
child tables using this parent table.
As in the test above, disabling child table should override status of hosts
within the table and those should become UNKNOW,
which should prevent usage of this child table.


Any clarification regarding this scenario is appreciated.

P.S.
This is 6.0-stable

Br
//mxb

Reply via email to