Network Services South
Load Balancer Series:
F5 Networks BIG-IP v4.x Load Balancers
Presented by: David Mai
February 13, 2007 © 2003 IBM Corporation
Agenda
• Intro
• Hardware aspects of the Big-IP Load balancer
• Load balancing terminology and concepts specific to the BIG-IP
• Using the GUI and the Command Line Interface
• Taking nodes (real servers) IS/OOS
• Logs
• Node availability (Health monitoring)
• Persistence
• NATs and SNATs
F5 Networks
BIG-IP Load Balancer
BIG-IP® 520 & 540 IP Server Appliance
Big-IP 520 has a single processor (Pentium III 1GHz)
Big-IP 540 has dual processors and more memory
Clients
Internet www.example.com
BIG-IP
Servers
Big-IP v4.5 Concepts and
Terminology
• Node (IP Address of real server:Service)
10.23.4.7:80
• Node Address (IP Address of real server only)
10.23.4.7
• Pools (Groups of nodes)
10.23.4.7:80, 10.23.4.8:80, 10.23.4.9:80
• Virtual Server
9.42.151.228 (www.support.com)
• Monitor = Health check
Internet
Node
10.23.4.7 10.23.4.8 10.23.4.9
Address
10.23.4.7 :80 10.23.4.8:80 10.23.4.9:80
10.23.4.7 :443 10.23.4.8:443 10.23.4.9:443
Nodes
Internet
www.example.com
9.42.151.228
Virtual
Server
10.23.4.7:80 10.23.4.8:80 10.23.4.9:80
Pool
Load Balancing Modes
• Round Robin
– Round robin mode distributes connections
evenly across all available nodes, passing a
new connection to the next node in line.
• Least connections
• Fastest
Persistence (Sticky)
• Simple
– Allows traffic from a specific source address (or group of
addresses) to be directed to the same node. Simple persistence
supports TCP and UDP protocols, and it tracks connections
based on the client IP address. As long as a client doesn’t
change its IP address during the persistence period, it will
always be routed to the same node until the persistence timeout
value is reached.
• Cookie persistence
– This method of persistence uses an HTTP cookie stored on a
client’s computer to allow the client to reconnect to the same
server previously visited at a web site.
Health Monitoring Concepts
• By default when you create a new node address, the default is icmp.
• Nodes, on the other hand, when created do not have a health check
assigned to it.
• The system supplied monitors are default set at interval of 5 and a timeout
of 16. In this scenario, the BIG-IP will check every 5 seconds. After 16
seconds (or three tries), the BIG-IP marks the node or node address down.
The BIG-IP will continue to check to see if a node or node address is
available start sending traffic if it comes back up.
• If you wish to change the intervals and timeout values of the system
supplied monitors, you will need to create a user defined monitor.
Load Balancer Tab Repository
• https://gatorade.raleigh.ibm.com/USF/lbtab/
• Login with your gatorade ID
Available VIPs Group # &
to configure Assigned BIG-IP v4.5 LAB
(http port) listening
port (X) To access the F5 Gui:
9.42.151.228 81 https://9.42.151.226
9.42.151.229 82
9.42.151.230 83
9.42.151.231 84 9.x Network Username: admin
9.42.151.232 85 Password: lab
9.42.151.233 86
Interface 1.1: 9.42.151.226
Interface 1.2: 10.23.4.4
X = your
assigned port
10.23.4.7 :X 10.23.4.8:X 10.23.4.9:X
Taking Nodes and Node Addresses
IS/OOS
Enable Enable Node State Results:
Connections Sessions BIG-IP’s Interaction with the Node
State State
Checked Checked UP Existing Connections – Maintained
New Sessions – Can be Created
New Connections – Can be Created
Checked Unchecked DISABLED Existing Connections – Maintained
New Sessions – Not Created
New Connections – Can be created, but
ONLY for Clients in Existing Sessions
Unchecked Checked FORCED Existing Connections – Maintained
DOWN New Sessions – Not Created
New Connections – Not Created
Unchecked Unchecked FORCED Existing Connections – Maintained
DOWN New Sessions – Not Created
New Connections – Not Created
LAB - Taking Servers IS/OOS
• In this lab you will proceed to remove a server out of rotation in the pool assigned to
your virtual server.
• From the Navigation pane, click the Nodes menu.
• You will a list of all the nodes configured on this box.
• Click on the 10.23.4.7 node assigned to your group (10.23.4.7:X)
• Proceed to take the server out of rotation by unchecking the “Enable Sessions” and
“Enable Connections” options and select Apply.
• Now let’s check to see if it worked. From the Navigation pane, click the Statistics
menu.
• Click on “Pools” in the drop down menu.
• Look for your pool. Proceed to load your assigned VIP on your browser. Refresh
several times. You should see the stats increase for only two of the nodes in your
pool.
• You should also notice that you are being load balanced to only 2 servers instead of
three now.
• Proceed to put the server back in rotation then load your assigned VIP on your
browser. You should now see that you are being load balanced to all three nodes.
NATs and SNATs
• NATs provide a one-to-one mapping between two IP addresses. Generally the “NAT”
address is externally routable and the node address is not. Communication can be
initiated either by the devices that can reach the NAT address or by the node.
• SNATs provide a many-to-one mapping between the IP addresses of a group of
nodes and a “SNAT” address. Like NATs, the SNAT address is generally routable
where the nodes addresses may not be. Unlike NATs, connections cannot be
initiated to a SNAT address. Only the nodes can initiate connections.
NATs on a BIG-IP
Internet
NAT = 9.42.151.228
10.23.4.7 10.23.4.8 10.23.4.9
SNATs on a BIG-IP
Internet
SNAT = 9.42.151.228
10.23.4.7 10.23.4.8 10.23.4.9
High Availability
• Big-IPs are generally deployed in a Active-Standby pair. Failover detection can be
achieved using a Hardware Failover Cable (serial cable) that is attached to both BIG-
IPs. The other alternative is to use a network-based failover which is disabled by
default.
• Big-IPs offer stateful failover that CSSs and Alteons do not provide. All connections
(TCP and UDP and it’s associated applications – FTP, telnet) and simple persistence
are kept in tact as it’s transferred to the second BIG-IP. In essence, file transfers and
clients accessing web servers behind the BIG-IP observe no interruption during a
BIG-IP failover.
• Failover can be achieved by entering the following in the CLI on the active BIG-IP
– Bigpipe failover standby
• To failover via the GUI (on the active BIG-IP),
– Click on System on the Navigation Pane
– Click on the Redundant Properties tab
– Click on Force to Standby
Command Line Interface (CLI)
• The BIG-IP can be accessed via SSH.
• The Command Line is an alternative to using the system supplied GUI.
• Base config files:
– /config/bigip.conf
– /config/bigip_base.conf
• License File:
– /config/bigip.license
• Logs are kept in
– /var/log
Troubleshooting
• Network Map
• Check Logs
• Monitoring
• Command Line
Troubleshooting via the Command Line
• Troubleshooting via the CLI
– To view a summary of Nodes and to see if the BIG-IP is Active or Standby
• Bigtop
– Status of the NICs and whether there are any interface errors
• b interface show
– View current routing table
• Netstat –rn
– Display interface and IP address assignments
• Ifconfig –a
• Tcpdump
– Tcpdump –i [internal or external] –s 1600 host x.x.x.x
– Tcpdump –i internal –s 1600 host 10.23.4.7 and 10.23.4.4
– Tcpdump –i internal –s 1600 –w [dump file name] host
10.23.4.7
Logs
• Logs can be found in Log Files section of the Navigation Pane.
• Three major types of logs:
– System Log: Includes events occuring on the BIG-IP system, this includes boot up and
login messages
– BIG-IP Log: Includes events such as defining or changing a Virtual Server or Pool definition
(config changes)
– Monitor Log: Primarily contains events such as the status of Nodes and Services
• By default the F5 will keep logs for one day before it is archived. A separate file is
created for each day and after seven days, the oldest file is deleted.
• Old logs can be accessed in the /var/log directory (you will have to SSH to the box)
– /var/log/message -- System log files
– /var/log/bigip – BIG-IP log files
– /var/log/bigd -- Monitor log files
To view archived log files you can use the gzcat command:
gzcat “filename” | more
Interpreting TCPDUMP output
External:
[root@REGFLB001:Active] config # tcpdump -i external host 24.211.153.89
tcpdump: listening on external
21:33:30.947974 24.211.153.89.1422 > 129.41.225.182.http: S 3434252633:3434252633(0) win 64240 <mss
1460,nop,wscale 0,nop,nop,sackOK> (DF)
21:33:30.948029 129.41.225.182.http > 24.211.153.89.1422: S 65945337:65945337(0) ack 3434252634 win 4380 <mss
1460,nop,wscale 0,nop,nop,sackOK> (DF)
21:33:30.973965 24.211.153.89.1422 > 129.41.225.182.http: . ack 1 win 64240 (DF)
21:33:30.982051 24.211.153.89.1422 > 129.41.225.182.http: P 1:407(406) ack 1 win 64240 (DF)
21:33:30.983438 129.41.225.182.http > 24.211.153.89.1422: P 1:310(309) ack 407 win 4786 (DF)
21:33:31.054785 24.211.153.89.1422 > 129.41.225.182.http: P 407:744(337) ack 310 win 63931 (DF)
21:33:31.055478 129.41.225.182.http > 24.211.153.89.1422: P 310:840(530) ack 744 win 5123 (DF)
Internal:
[root@REGFLB001:Active] admin # tcpdump -i internal host 24.211.153.89
tcpdump: listening on internal
21:33:30.982125 24.211.153.89.1422 > 10.23.4.74.http: S 630635807:630635807(0) win 4380 <mss
1460,nop,nop,sackOK,nop,wscale 0> (DF)
21:33:30.982358 10.23.4.74.http > 24.211.153.89.1422: S 915956237:915956237(0) ack 630635808 win 5840 <mss
1460,nop,nop,sackOK,nop,wscale 0> (DF)
21:33:30.982380 24.211.153.89.1422 > 10.23.4.74.http: . ack 1 win 4380 (DF)
21:33:30.982397 24.211.153.89.1422 > 10.23.4.74.http: P 1:407(406) ack 1 win 4380 (DF)
21:33:30.982575 10.23.4.74.http > 24.211.153.89.1422: . ack 407 win 6432 (DF)
21:33:30.983374 10.23.4.74.http > 24.211.153.89.1422: P 1:310(309) ack 407 win 6432 (DF)
21:33:31.054857 24.211.153.89.1422 > 10.23.4.74.http: P 407:744(337) ack 310 win 4689 (DF)
21:33:31.055438 10.23.4.74.http > 24.211.153.89.1422: P 310:840(530) ack 744 win 7504 (DF)
Open discussion
