Technical Note: How to configure Load Balance VIP using health monitor in SLBC environment

[nvisentin_FTNT]

Description

This article explains how to configure Load Balance VIP using health monitor in SLBC environment.

Solution

In SLBC architecture, only TCP and UDP traffic is load balanced to the worker blades.  Other protocols, including ICMP, are sent to the ELBC master blade.  If a load Balance VIP relies on ICMP health check (for instance “ping”, ICMP echo), the following behavior will occur.

Each worker will try to probe the real server using ICMP echo.  The server will reply, since ICMP is directed to the ELBC master, the reply will go to the ELBC master, therefore all the other worker blades will not get the reply.  Hence the probe will fail and the real server will be marked as down.

In the following example, there 2 worker blades, slot3 is the ELBC master:

LB VIP configuration (HTTP):

config firewall vip
    edit "LB-HTTP-VIP"
        set uuid 1e1ea188-96ce-51e7-8b62-c9628d763e65
        set type server-load-balance
        set extip 10.5.16.35
        set extintf "any"
        set server-type tcp
        set monitor "ICMP"
        set color 1
        set ldb-method least-session
        set extport 80
        config realservers
            edit 1
                set ip 10.118.0.100
                set port 80
            next
         end
    next
end

config firewall ldb-monitor
    edit "ICMP"
        set type ping
    next
end

Real servers status – slot3 (ELBC master):

5KD-A-3 (VD1) # diag firewall vip realserver list
alloc=3
------------------------------
vf=2 name=LB-HTTP-VIP/4 type=3 10.5.16.35:(80-80), protocol=6
total=2 alive=1 power=1 ptr=76870143
ip=10.118.0.100-10.118.0.100:80 adm_status=0 holddown_interval=300 max_connections=0 weight=1 option=01
   alive=1 total=1 enable=00000001 alive=00000001 power=1
   src_sz=0
   id=0 status=up ks=0 us=0 events=1 bytes=0 rtt=0

Real server status - slot4:

5KD-A-4 (VD1) # diag firewall vip realserver list
alloc=3
------------------------------
vf=1 name=LB-HTTP-VIP/3 type=3 10.5.16.35:(80-80), protocol=6
total=2 alive=0 power=0 ptr=42719710
ip=10.118.0.100-10.118.0.100:80 adm_status=0 holddown_interval=300 max_connections=0 weight=1 option=01
   alive=0 total=1 enable=00000001 alive=00000000 power=0
   src_sz=0
   id=0 status=down ks=0 us=0 events=0 bytes=0 rtt=0

As a result, HTTP requests directed to slot4 will not work, the debug flow will report the following output:

id=20085 trace_id=14 func=print_pkt_detail line=4903 msg="vd-VD1 received a packet(proto=6, 172.26.128.66:6689->10.5.16.35:80) from VLAN2_VD1. flag [S], seq 2480966248, ack 0, win 64240"
id=20085 trace_id=14 func=init_ip_session_common line=5047 msg="allocate a new session-0457f0bd"
id=20085 trace_id=15 func=print_pkt_detail line=4903 msg="vd-VD1 received a packet(proto=6, 172.26.128.66:6688->10.5.16.35:80) from VLAN2_VD1. flag [S], seq 3896442640, ack 0, win 64240"
id=20085 trace_id=15 func=init_ip_session_common line=5047 msg="allocate a new session-0457f0c4"

The solution is to use UDP or TCP based probes.  Since TCP and UDP segments will create a session in the FortiController Distribution Processor, the reply will be directed to the proper worker blade.  Hence, the health check will work on all worker blade.

Configuration changes:

config firewall ldb-monitor
    edit "HTTP"
        set type tcp
        set port 80
    next
end

config firewall vip
    edit "LB-HTTP-VIP"
        set monitor "HTTP"
end

Real servers status – slot3 (ELBC master):

vf=2 name=LB-HTTP-VIP/4 type=3 10.5.16.35:(80-80), protocol=6
total=2 alive=1 power=1 ptr=76870143
ip=10.118.0.100-10.118.0.100:80 adm_status=0 holddown_interval=300 max_connections=0 weight=1 option=01
   alive=1 total=1 enable=00000001 alive=00000001 power=1
   src_sz=0
   id=0 status=up ks=0 us=0 events=1 bytes=0 rtt=1

Real server status - slot4 :

5KD-A-4 (VD1) # diag firewall vip realserver list
alloc=3
------------------------------
vf=1 name=LB-HTTP-VIP/3 type=3 10.5.16.35:(80-80), protocol=6
total=2 alive=1 power=1 ptr=42719710
ip=10.118.0.100-10.118.0.100:80 adm_status=0 holddown_interval=300 max_connections=0 weight=1 option=01
   alive=1 total=1 enable=00000001 alive=00000001 power=1
   src_sz=0
   id=0 status=up ks=0 us=0 events=1 bytes=0 rtt=0

HTTP requests directed to slot4 will work normally.