When we first land on BIG IP Device Console, we need to start from the CLI config In the CLI we can type the command “config” which will take us through a wizard to configure the management interface of the BIG IP Device.
It is not mandatory to access the device via console, by default BIG IP will have 192.168.1.245/24 configured on its management interface, so we can connect to the BIG IP either direct cable or via switch and access the GUI.
Default CLI Credentials Username: root Password: default
Default GUI Credentials Username: admin Password: admin
Resource Provisioning
Dedicated: LTM with Dedicated provisioning means LTM will block its required resources and not allow sharing with other modules, even if LTM is not using the resources.
Nominal: It means that the module gets the least amount of resources required. Then, after all, modules are enabled, the module gets additional resources from the portion of remaining resources.
Minimum: Specifies that when the module is enabled, it gets the least amount of resources required. No additional resources are ever allocated to the module.
MGMT Module
Small: Used for LAB, testing environments, or very small deployments
With small no memory allocation for MGMT Module
Medium: Can be used for deployments with up to 2000 configured objects
To identify the number of objects configured on BIG IP use the command “tmsh list one-line | wc -l ”
Large: Used for deployments with more the 2000 objects
Interfaces & IP Addresses
Network --> Interface --> interface list
To Configure Interfaces with IP Addresses
Step 1: We need to create VLAN and associate this VLAN with the physical interface.
Step 2: Create Self IP and Associate it with the VLAN.
VLAN is connected to the physical interface as well as the self IP
Self-Ip will have Port Lockdown : This is where we configure what type of traffic is allowed on this interface, traffic that is destined to this IP (not passing through the appliance), for example, if you want to allow SSH to this interface, or SNMP.
In case a single Physical Interface serves more than one VLAN then we need to create the VLANs while selecting Tagged Option and specify the VLAN Number.
As VLAN has to be mapped to the physical interface & if that interface was a trunk then it will be tagged.
Now we can map this single physical tagged interface with multiple VLANs.
Link Aggregation - Trunk
On BIG IP Device we can aggregate two links to provide Link Level Redundancy or Increase BW.
When Connecting BIG IP to Two Switches to provide Interface Redundancy, the switches need to support multi-chasses Link Aggregation (MLAG), or something similar for example vPC on Cisco Nexus Switches, or VSS on Catalyst.
Link Aggregation Control Protocol - LACP
LACP is The Control Protocol Used Between BIG IP And The Switch To Exchange Control Messages, This Will Allow Both Devices To Discover Errors On The Link/Interface.
Interface With Errors Will Be Removed From The Group And LACP Will Continue To Monitor The Interface, Once Back Health It Will Re Join The Interface To The Group.
LACP Mode
Active (default): With this Mode,a the BIG IP will send LACP Packets over the Links asking the Other Connected Device to Form Similar Group Of Interfaces (Links Aggregation).
Passive: With LACP Passive Mode, BIG IP Will Not Send LACP Packets, But If the Other Device Asks BIG IP To Form Links Aggregation, BIG IP Will Accept and Form The Aggregation LACP Timeout.
Short: On Each Member Link, BIG IP Will Send LACP Control Packet To the Remote Peer Once Every Second • If the Remote Peer Is Not Responding To LACP Packets After 3 Seconds We Remove The Member From The Group.
Long (Default): On Each Member Link, BIG IP Will Send LACP Control Packet To the Remote Peer Once Every 30 Seconds.
Link Aggregation - Configuration
Network >> Trunks >> Trunk List
The media speed and duplex mode of each link must be the same on both peer systems. For Example, all links should be 1G or all should be 10G.
Link Select Policy :
Auto (the default setting): BIG-IP will use the lowest-numbered interface of the trunk as a reference link.
Then the BIG IP will aggregate only links that have the same media properties and are connected to the same peer as the reference link.
Maximum Bandwidth: BIG-IP will aggregate the subset of member links that provide the maximum amount of bandwidth to the trunk.
Frame Distribution Policy: This setting specifies the basis for the hash that the system uses as the frame distribution algorithm.
Possible values for this setting are:
Source/Destination MAC address
This Means BIG IP should base the hash on both MAC addresses of the source and the destination.
Destination MAC address
This Means BIG IP should base the hash on the MAC address of the destination. •
Source/Destination IP address
This value specifies that the system bases the hash on the combined IP addresses of the source and the destination.
Pools: Disable vs Force Offline
Disable node or pool member continues to process persistent and active connections. It can accept new connections only if the connections belong to an existing persistence session.
Force Offline, a node or pool member allows existing connections to time out, but no new connections are allowed.
Monitors
Monitors are used to determining the status of the server (node / Pool Member), if the server doesnʼt respond to monitor, it will be taken offline and traffic will not be sent.
Red Oval: node is down
Blue Square: no monitor associated with the node
Black Square: node is disabled
Black Oval: node Forced Offline
Node is Red Oval >> Pool Member is Red Oval in all pools
Node is Black Square >> Pool Member is Gray circle
Node is Black Oval >> Pool Member is Gray Oval
Yellow Triangle: The object is not currently available but might become available later with no user intervention.
Example: An object that has reached its configured connection limit might show a yellow status and then switch back to GREEN when a number of connections fall back to the configured limit.
Methods of Monitoring
Simple Monitoring
Determine if the node is up or down
ICMP, and TCP_ECHO Work on node level only, and can NOT be applied to pool member
Gateway ICMP works on Node and Pool Levels
Active Monitoring
Extended Content Verification ‒ ECV
Monitors for Content Check means we send a request to the server and we evaluate the response to determine if the member is healthy or not.
ECV is the most used for pools.
With the default config, the HTTP monitor sends get request, and any response we receive means the server is ok.
Send String
If the response doesn't match make the pool member down.
We can send any HTTP request to the pool member and validate the response, which means we can match specific text in the response, and if that response is not matching the monitor fails and the server is marked down.
Receive String
If the response match makes the pool member down.
in HTTP we know that the 400 response code is not a good string to see in the server response, so we can specify a query to the server and in the receive string filed we match the 400 response code.
Extended Application Verification ‒ EAV
Monitor for Service Check, Path Check, and Application Check
Passive Monitoring
This kind of monitoring checks the health of a pool member based on a specified number of connection attempts or data request attempts that occur within a specified time period.
The passive monitor can NOT check for a specific response.
Load Balancing Methods
Static Load Balancing
1) Round Robin --> Even Distribution ‒ Stateless
2) Pool Ratio Based --> Based on specified ratio as per the capacity of servers say 1:2:4
To Configure Ratio Based Load Balancing Click On Local Traffic > Pools > Members Tab To Assign Ration For Member, Click On The Member And Change The Ratio Value.
3) Node-Based Ratio --> Ratio can be set on the Node level
A node can be part of multiple pools say Pool 1 at port 80 & Pool 2 at port 443.
Let's assume there are two servers Server 1 & Server 2 in a ratio of 1:2
So F5 while redistributing won't care if the request is coming for port 80 or 443 but the only thing it cares about is the ratio is 1:2.
When the ratio is configured on the node level, the load balancing method of Ratio (Node) should be selected.
Dynamic Load Balancing
1) Least Connections (Member / Node) --> When receiving a check client connection check the current number of active connections on pool members & send the request to the member with the least number of active client connections.
Good For Dissimilar Servers Where We Donʼt Know The Explicit Max Number Of Connections Each Server Can Handle.
2) Least Sessions (Only Pool Member) --> Requires L4 / L7 Profile --> It looks at the number of active sessions not the number of connections
3) Dynamic Ratio (Only Pool Member) --> It looks at performance metrics on the servers & Requires performance monitor, for example, SNMP DCA (data collection agent).
Ratios are assigned and updated based on the feedback from the performance data collected from servers. It takes into consideration CPU, Memory, and Disk Performance.
4) Observed --> Uses Dynamic Ratio Algorithm similar to Dynamic Ratio With One Difference That Dynamic Ratio Uses Monitor While In Observed, Instead Of Using Active Monitor This Algorithm Record The Number Of L4 Connections Every Second.
So Every Second There Is A Snapshot Of the Number Of Connections Per Node Or Member And Based On That Ratio Will Be Assigned To The Member, Lower Connections Mean a Higher Ratio.
5) Predictive --> Like Observed But It Monitors The Server Overtime And Observe The Trend, Of Server Performance Is Improving Then The Server Receives More Connections But If The Server Performance Is Declining It Receives Fewer Connections.
6) Fastest --> Select The Node Or Member With The Least Number Of Outstanding L7 Requests. Hence it Requires L7 and TCP Profiles.
7) Least Sessions --> It Considers the Number Of Sessions In the Persistence Table. It Requires a Persistence Profile, It Has To Be Active Persistence So Cookies Are Not Accepted Because It Is Passive.
Priority Group
This is how we configure the active-passive setup. We assign priority to the group & the group with the higher priority will win.
Also, we have to define "Priority group Activation" i.e. say less than 2.
Now say we have two new servers and we only want to use them in case old one incase one of the new servers runs into some issue.
So we will keep new servers in the priority group say 6 and the old one in group 3.
Now with Priority group Activation, the old server won't process any traffic unless one of the new servers have an issue because in that case, the number of server in high priority group will be less than two.
Note: Priority Group works on all load-balancing algorithms.
Profiles
Type of Profiles
Services
• HTTP
• FTP
• SIP
• SMTP
Protocols
• TCP
• UDP
• Fastl4
• Fast
HTTP
• Persistence Profiles
• Cookies
• RDP
• IP (Source and / Or Destination
Authentication Profiles
• RADIUS
• LDAP
• TACACS+
SSL Profiles
• Client
• Server
FastL4
FastL4 is limited in functionality to the socket-level socket-level decision (for example, src_ip: port dst_ip: port). Thus, you can use FastL4 only when socket-levelload-balancing information for each connection is required for the virtual server.
It means that you can't be trying to process anything above Layer 4. So no iRules, no header insertions, no cookie persistence, etc.
Note: limited iRules functionality is available with the FastL4 profile.
Types of VIP
Standard
A Standard virtual server directs client traffic to a general-purpose pool and is the most basic type of virtual server. It is a general-purpose virtual server that does everything not expressly provided by the other types of virtual servers.
A Forwarding (IP)
This virtual server forwards packets directly to the destination IP address specified in the client request. A Forwarding (IP) virtual server has no pool members to load balance.
The Forwarding (Layer 2)
This type of virtual server uses the Fast L4 profile. The Forwarding (Layer 2) virtual server does not have pool members to load balance and forward packets based on routing decisions. The virtual server shares the same IP address as a node in an associated. VLAN.
Performance (Layer 4)
A Performance (Layer 4) virtual server has a FastL4 profile associated with it. A Performance (Layer 4) virtual server increases the speed at which the virtual server processes packets.
A Performance (HTTP) virtual server: It has a Fast HTTP profile associated with it. The Performance (HTTP) virtual server and related profile increase the speed at which the virtual server processes HTTP requests.
Fast HTTP is an appropriate profile to use under ideal traffic conditions.
Fast HTTP combines some of the most commonly used features from the TCP, HTTP, and OneConnect profiles into a single profile that is optimized for network performance.
The Fast HTTP profile is designed to reduce network latency and system CPU usage.
Reject virtual server
It rejects any traffic destined for the virtual server IP address.
Stateless virtual server
It provides improved User Datagram Protocol (UDP) performance over a standard virtual server in specific scenarios, but with limited feature support. This article discusses some uses as well as the limitations of the stateless virtual server. Any new connection entry is immediately removed from the connection table. This behavior addresses the requirements for one-way UDP traffic that needs to be processed at very high throughput levels.
DHCP Virtual Server
A DHCP virtual server relays Dynamic Host Configuration Protocol (DHCP) client requests for an IP address to one or more DHCP servers and provides DHCP server responses with an available IP address for the client.
Persistence Profiles (stickiness)
In load balancing environment multiple requests from the same user can be served by different nodes behind the load balancer, while this is good in terms of load distribution, such behavior may break the functionality of some applications where the server/node user should be served by the same server/node for a period of time (for example e-commerce).
With BIG-IP LTM we can configure the persistence profile so that LTM will send a user to the same node for a configurable period of time Persistence can be configured based on.
Cookies Hash --> Web Server Generates The Cookie and BIG IP will create the HASH value of the cookie to map it to a specific node
Insert Cookie --> The BIG IP will insert a cookie in the server response to the client to identify the node so subsequent client requests go to the same node
A cookie will be named BIGip --> This is the default method for Cookie Persistence.
Passive Cookie --> This Assume that the server itself will insert the appropriate cookie to identify itself and specify the time out, big ip will just use the information within the cookie
Cookie Rewrite --> Server will insert cookie • BIG IP will intercept and rewrite the cookie.
Source / Destination IP
• Hash
• RDP
• SIP
• SSL
• Universal
• iRules
After creating a persistence profile, it needs to be associated with the Virtual Server.
Once the persistence profile is applied to a virtual server, we can see persistence records under statistics > Local Traffic then select statistics.
SSL Profile
Being a full proxy device, BIG IP supports SSL implementation on both Sides, Client, and Server.
Traffic can be encrypted between users and the Virtual Server (Client Side) and can also be encrypted between LTM and Server (Server Side).
If encryption is done end to end between the user and server where the load balancer is just doing basic load balancing functions, the load balancer loses lots of its capabilities if forwarding encrypted traffic.
NAT / Proxy Architecture
By default, there is only Destination NAT. If BIG IP is not the default gateway of back-end servers (or one-arm mode) then servers will try to reach their default Gateway to reach the source address.
To resolve this problem we can configure the BIG IP to change the source IP address of the packet with SNAT or Auto Map as it leaves the BIG IP toward the pool member.
SNAT – Secure NAT
BIG IP has two modes of CLI
1) First Linux Shell (Advanced Shell)
2) TMSH (TMOS)
tmos # show /ltm pool
# list /ltm pool
# ltm
tmos.ltm #
BIG IP IDLE Session Timeout
With BIG IP each client connecting to the app will have a connection in the connection table, such information will be stored in memory and consume memory space, to avoid resource exhaustion BIG IP has a default connection idle time of 300 seconds by default, once the connection is idle for 300 seconds it will be removed from the connection table.
tmos # show /sys connection
To Change Connection IDLE Time we need to create a custom TCP Profile
Connection IDLE vs Persistence Record
Connection Timeout is not related to persistence timeout i.e. if we configure the connection timeout to be 120 seconds and persistence timeout to 180 seconds (default value), what will happen after 120 seconds? The connection will be removed from
connection table while the persistence record will remain in the persistence table.
Once the user clicks refresh on the page or sends any request to the VS before the 180 seconds, the user will be served by the same pool member.
Routing
BIG IP has Two Routing Tables
Linux Routing Table, used for management traffic.
TMM routing table used for application traffic routing and delivery.
If you compare the Linux command netstat ‒r output and the ”show /net route” output you. Will notice that the management subnet is only routed in the Linux routing table.
TMM Routes are Preferred over management Routes.
Response for Traffic hitting the management interface will always use the management routing table.
Static Routes
Outbound traffic Traffic initiated from the BIG IP (SNMP, SMTP, DNS, NTP, etc.) will be subject to the routing table If the destination has a TMM Route, it will be used, if no TMM route, and there is a route in the management table, it will be used.
TMM Routes has lower (better) Metric than management routes, this also applies to the default route so if you have a management default gateway and default route on the outside interface the BIG IP will always prefer the TMM route (outside interface).
TCPDUMP
Command used to capture the first 100 packets on internal VLAN with source or destination ip address of 1.2.3.4 and port 80 (-i for specifying interface)
tcpdump –i internal host 10.20.30.40 and port 80 –c 100
The below command will do the same as above but using the interface number rather than the name
tcpdump –i 1.1 host 10.20.30.40 and port 80 –c 100
The below command will capture all packets hitting the internal interface
tcpdump –i internal
Saving output to file with same command line display format (-n disable name resolution)
tcpdump –i internal –n host 172.16.20.1 and port 80 > mycapture
Save to compressed file
tcpdump –i internal –n host 172.16.20.1 and port 80 -w mycapture
tcpdump can be used from GUI config utility System >> support >> New Support Snapshot >> from the drop-down menu select tcpdump
Specifying Source Host or Destination
tcpdump –i internal dst host 1.2.3.4 and port 80 –c 100
tcpdump –i internal src host 1.2.3.4 and port 80 –c 100
Specifying Source Port or Destination
tcpdump –i internal dst host 1.2.3.4 and src port 80 –c 100
tcpdump –i internal src host 1.2.3.4 and dst port 80 –c 100
Specify ARP as protocol
tcpdump –i internal arp –c 100
ICMP capture
tcpdump –i internal icmp and dst host 1.2.3.4
Use ʻtcpdump -s0ʼ to capture the full data packet.
The number following the ʻsʼ indicates the number of bits to capture in each packet.
0 indicates all (by default tcpdump captures only the first 96 bytes)
tcpdump –s0 –i internal
Write the capture to pcap file (0.0 wildcard means all interfaces)
tcpdump -nni 0.0:n -s0 -w/var/tmp/capture.pcap
Wildcard IP Forwarding VS
“ Forwarding IP ” type of VS will make BIG IP Act like a router
Config Archive
Config Archive is the way we back up and restore LTM Configurations, the backup file will include all files required to restore the device to its current state (config file, license file, users, certificates, etc…).
• To create a backup file, click on System > Archive
• Then click Create to create a backup archive file
• You can select to encrypt the backup file with a passphrase or not
• You can select to include the private keys stored on this device
You can use the tmsh command to create a backup file, the default location for backup files is /var/local/ucsa
Let's create a backup file to a different location, we are also specifying a no-license option to exclude the license file.
save /sys ucs /var/tmp/MyUCS.ucs no-license
To restore configuration archive file, use the command
tmsh load /sys ucs /var/tmp/MyUCS.ucs no-license
Consideration for Restoring Configuration Data
If Restoring on Replaced Device (RMA Processed) the follow the following procedure.
• License the new device
• Copy the archive file to the new device manually
• Use the command “load /sys ucs no-license
If you intend to restore the UCS file from the older software version to thenewer software version, make sure there is an upgrade path from the older to the newer, if there is no upgrade both between both then you can not restore.
Platform Migration
In case we have HA pair
1) Device to be replaced is standby or offline?
2) License the new device and configure it as standby to get sync of config from the primary.
If we have a standalone LTM Device then
If we have a new LTM appliance to replace an old/obsolete LTM appliance then we need to use the platform-migrate option when restoring.
tmsh load sys ucs platform-migrate
Single Configuration File SCF
It is a simple text file that contains all configuration of BIG IP Devices
High Availability
Two BIG IP Devices can be configured with HA to provide active-standby failover, standby device will be a copy of the active device but the user not handle user traffic as long as the active device is available.
Stateful Failover
By Default, Connections are not Synchronized.
This means if I have a connection toward a web server behind the BIG IP and for some reason, the primary device fails and the standby becomes Primary we will lose the connection to the web server and we need to re-establish the connection.
To avoid such a scenario we need to sync the connection table from the primary to the standby, to do so we need to enable connection mirroring, and this is done on per Virtual Server Basis
Click on Local Traffic >> Virtual Servers >>Configuration Section >> Select Advanced >> Enable the Connection Mirroring
Also, Persistence Records are not Synchronized By Default Means BIG IP may not send a user to the same server after a failover.
To sync the persistence table from the primary to the standby
Local Traffic >> Profiles >> Persistence >> Configuration >> Enable the Mirror Persistence
Logging
Who can See Log Files/log messages?
To define which user role can see log messages
System >> Logs >> Configuration >> Options (Allow/Deny)
By default, only Administrator, Resource Administrator, and Auditor can see
Level of messages to be logged for each LTM subsystem
System >> Logs >> Configuration >> Options
To View Log messages from GUI
System >> Logs
There are different Tabs for each component
Local Traffic will show all logs related to LTM, for example, the node is down, pool member is disabled, health monitor failed, and so on
The audit tab will show us administrative actions, for example, Route added or deleted by admin, user disabled by admin
By Default Audit Logging is enabled for both MCP (Config Utility) and TMSH, which means BIG IP will log all config changes by config utility and tmsh commands.
By default Log Files Stored in /var/log
A separate log file for different BIG IP Components
/var/log/audit file will have the log messages for Administrative actions
/var/log/ltm will have log messages related to LTM
TMSH Commands to show Logs
show /sys log ltm
show /sys log range
show /sys log ltm range now-2d
show /sys log ltm range 2021-10-18
show /sys log ltm range 2021-10-08--2021-10-18
Linux Commands
“less /var/log/ltm”
To see logs as they are written on the log file (Real Time)
“tail -f /var/log/ltm”
Remote Logging
Syslog server
System >> Logs >> Configuration >> Remote Logging
This is the legacy Syslog Server config, that will send all logs to the configured Remote IP.
It is not recommended and rarely used because all types of logs will go to the same IP (LTM, AFM, ASM, APM, and others).
High-Speed Logging - HSL
With HSL we can configure logging in a very granular way where we can specify LTM logs to go to certain log servers while ASM Logs and AFM logs go to another log destination.
USERS
By default, we have two types of users.
Admin: By default, the admin can access GUI however we can enable CLI access for the admin account.
User --> Admin --> terminal access --> advance shell
Root: The root account can only access CLI and canʼt access GUI.
User: Terminal Access
Specify if the user allowed to access the “tmsh” CLI or not.
We can NOT give users access to “advanced Shell” unless the role is “Administrator”
User Role Defines
• The types of resources that the user can manage
• User roles define the types of resources, or objects, that a user can manage. For example, a user with the role of Operator can enable or disable nodes and pool members only. while a user with the Guest role cannot manage any BIG-IP system resources.
• The tasks that a user can perform
• User with the role of Operator can enable or disable nodes and pool members, but cannot create, modify, or delete them. while a user with the Manager role can perform all tasks related to objects within a partition, except for tasks related to user accounts.
Resource Administrator
• Can Manage Objects in all partitions
• Canʼt create or manage user accounts
User Manager
• Can Create a user in any partition and assign roles for that user on any partition.
• Can Modify a user in any partition and change the existing roles for that user on any partitions.
• View all user accounts.
• Modify the password on any user account.
• Enable or disable terminal access for any user account.
• Change his or her own password.
Manager
• Can create, modify, and delete virtual servers, pools, pool members, nodes, custom profiles, custom monitors, and iRules.
• Can view all objects on the system and change their own passwords
Administrator
• Can access to all objects on the system. These users can change their own passwords and cannot have any other user role on the system. Users with the Administrator role have access to all partitions on the system, and this partition access cannot be changed. This is the only role that can have Linux Advanced Shell
Administrative Partitions
Administrative Partitions are logical containers where we can place objects within partitions, for example, you can specify Nodes, Pool, VS related to Web_app2 in a separate partition (separate folder).
Then you Can Assign A User To Administer This Partition.
A common partition can not be deleted.
Users with the administrator role can create objects in the common partition.
All users created on BIG IP will have read access to the common partition, except those who have the role “no access”.
A role can be given to a user under a specific administrative partition.
Admin Functions
System >> Configuration >> Device >> General >> Reboot
System >> Configuration >> Device >> NTP
If the BIG IP Device requires a proxy for internet traffic initiated from the appliance itself.
System >> Configuration >> Device >> Proxy
System >> Configuration >> Device >> DNS
System >> Configuration >> Device >> Hosts
Banner is for SSH Access
System >> Configuration >> Device >> SSHD
Specifying the Banner Text is not enough to show the banner, you need to enable the check box “Show the Security Banner On The Login Screen” for the banner to be shown.
IDLE Timeout This IDLE timeout is for SSH Access, it is also applicable only for Linux Shell Mode not for TMSH Mode.
To configure the TMSH IDLE Timeout we need the command
modify /cli global-settings idle-timeout
To Configure IDLE Timeout for Console Access
modify /sys global-settings console-inactivity-timeout
We can also Enable or Disable SSH Access to the appliance.
To configure the IDLE Timeout & banner for GUI Click On
System >> Preferences
SMTP
System >> Configuration >> Device >> SMTP Here we can create SMTP Configuration with the SMTP Server details for sending reports.
This is NOT the SMTP server for sending Alerts this is only used for sending reports.
Change the MGMT IP and Passwords
On System >> Platform
To Limit the Source IP Addresses that can SSH to the appliance "SSH IP allow".
limiting access to the management IP of BIG IP
System >> Platform >> Security Tab
We are required to create Rules like an access list, specify what source IP Addresses are allowed, and what Protocols like SSH and HTTPS.
QKView & iHealth
QKView is a utility that generates diagnosis data on the BIG IP, it generates multiple files in XML format and then combines them in a tar file.
• This file is to be sent to F5 support for system health checks or troubleshooting service requests.
• If you have an iHealth account, you can upload the qkview file to “ihealth.f5.com”.
To Generate a QKView file, click on system > support > New Support Snapshot
• Once file is ready, click download & upload it on the iHealth Portal.