Technical Tip: How to configure Load Balance VIP using health monitor in SLBC environment
Description
This article describes how to configure Load Balance VIP using a health monitor in the SLBC environment.
Scope
FortiGate.
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; 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 are 2 worker blades, slot3 is the ELBC master:
LB VIP configuration (HTTP):
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; 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 are 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
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) # diagnose 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
------------------------------
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) # diagnose 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
------------------------------
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"
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 blades.
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
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
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) # diagnose 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
------------------------------
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.
Note: Starting FortiOS v7.4.4, this feature is not supported anymore on FortiGate models with 2GB RAM or less, since Proxy-related features are not supported on FortiGate 2GB RAM models to enhance performance and optimize memory usage. See this document: Proxy-related features not supported on FortiGate 2 GB RAM models NEW for more info.
