Matt Dennett
F5-201 Study Notes
01 July 2024
F5 F5-201 Study

Last month I started the process to my F5-201 certification by sitting the F5-101 exam. Now I have that exam out of the way, I'm getting ready for the F5-201 exam. Here's a quick dump of my study notes that might be helpful if you're heading down the F5 certification path.

Just like my previous post, my goal here is to recap what I know, what I've brushed up on, and what I expect to see on the F5-201 exam. If you don't have a background in networking and F5 BIG-IP my study notes will fall far short of everything you need to know for the F5-201 exam. I would highly recommend you review the exam blueprints early in your study and again in the lead up to sitting the exam to ensure you haven't missed any topics.

Exam Summary

Time: 90 minutes Pass mark: 245 out of 350 Question: 80 (70 scored, 10 pilot/beta)

Exam cadence: Should aim to answer 1 question a minute, 10 minutes for review.

F5 describes a minimally qualified candidate as being able to:

  • Able to access and manage the BIG-IP through multiple paths (management IP, Self IP)
  • Perform administrative tasks using the GUI
  • Understand the relationship and differentiation between virtual servers, virtual server types, virtual addresses, pools, pool members, nodes, profiles, iRules, and address translation (NAT/SNAT)
  • Be familiar with HTTP, ClientSSL, ServerSSL, TCP, UDP, and persistence profiles
  • Open a support case and utilize online resources such as AskF5, F5 iHealth, and DevCentral
  • Perform software management functions on the platform (for example, capable of performing upgrades and licensing)

Order of processing

When connection reach the F5 BIG-IP the following list determines how they are processed.

  1. Existing connection table
  2. Packet filter rules
  3. Virtual server
  4. SNAT
  5. NAT
  6. Self-IP
  7. Drop

VIP Order of processing

Within the above order of processing the below list describes the order which is used to select which virtual server will handel the traffic. Like most networking concepts the most specific match is used.

  1. Specific IP and Specific port - 10.10.10.10:80
  2. Specific IP and all ports - 10.10.10.10:*
  3. Network IP and Specific port - 10.10.10.0/24:80
  4. Network IP and all ports - 10.10.10.0/24:*
  5. All Networks and specific port - 0.0.0.0/0:80
  6. All networks and all ports - 0.0.0.0/0:*

Status Symbols

  1. Green Circle - Enabled and health monitors are succeeding
  2. Red Diamond - Enabled and off line due to the monitors failing
  3. Yellow Triangle - A configured connection limit is being reached
  4. Black circle - Administratively disabled and monitors are succeeding
  5. Black Diamond - Administratively disabled and monitors are failing.
  6. Black Square - Administratively disabled and no monitors are configured
  7. Blue Square - Status is unknown - No monitor is configured, traffic is able to pass
  • Diamonds = Monitors are failing
  • Circles = Monitors are succeeding

  • Square = No monitors enabled to know the status - Status unknown

  • show ltm virtual
  • list ltm virtual
  • show ltm pool <name> members

Priority Group Activation

Priority Group Activation is when BIG-IP load balances traffic according to the priority number assigned to the pool member. This is disabled by default. When enabled, you can specify pool member priority when you create a new pool or on a pool member’s properties screen. Pool members with the same priority assigned are treated as one group. Priority group activation is enabled by selecting “Less than”, and entering a number from 0 to 65535 in the “Available Member(s) field”. When less than this number of members are available in the current group the BIG-IP will begin to direct traffic to members in a lower priority group. When a sufficient number of members become available in the higher priority group, the system again directs traffic to the higher priority group.

  • The group with the highest number is activated first.
  • When a node is no longer required to meet the requirements of PGA, connections on a node are permitted to gracefully finish while no new connections are sent to the node.

Persistence

When you configure session persistence, the BIG-IP system tracks and stores session data, such as the specific pool member that serviced a client request. The primary reason for tracking and storing session data is to ensure that client requests are directed to the same pool member throughout the life of a session or during subsequent sessions.

show ltm persistence persist-records

The persistence types that you can enable using a persistence profile are:

  • Cookie persistence - Cookie persistence uses the HTTP cookie header to persist connections across a session. Most application servers insert a session ID into responses that is used by developers to access data stored in the server session (shopping carts and so on). Load balancing services use this value to enable persistence.
  • Destination address affinity persistence - Also known as sticky persistence, destination address affinity persistence supports TCP and UDP protocols, and directs session requests to the same server based solely on the destination IP address of a packet.
  • Hash persistence - Using hash persistence is the same as using universal persistence, except that with hash persistence, the resulting persistence key is a hash of the data, rather than the data itself. If you use hash persistence, and Local Traffic Manager cannot find an entry in the persistence table for a connection, and the system has not yet chosen a pool member due to fallback persistence, then the system uses the hash value, rather than the specified load balancing method, to select the pool member. You generally use hash persistence with stateless applications or streaming content (video and audio). You cannot associate hash persistence with a virtual server that is managing Fast L4 traffic
  • Host persistence - Host persistence allows the BIG-IP system to use the HTTP Host header passed in an HTTP request to determine which pool member to choose. Microsoft Remote Desktop Protocol persistence = Microsoft Remote Desktop Protocol (MSRDP) persistence tracks sessions between clients and servers running the Microsoft Remote Desktop Protocol (RDP) service.
  • SIP persistence - SIP persistence is an application-specific type of persistence used for servers that receive Session Initiation Protocol (SIP) messages sent through UDP, SCTP, or TCP.
  • Source address affinity persistence - Also known as simple persistence, source address affinity persistence supports TCP and UDP protocols, and directs session requests to the same server based solely on the source IP address of a packet. You generally use this type of persistence technique with stateless applications or streaming content (video and audio) as a means to more evenly distribute load.
  • SSL persistence - Because SSL sessions need to be established and are very much tied to a session between client and server, failing to persist SSL-secured sessions results in renegotiation of the session. Renegotiation can result in a noticeable addition time to load. To avoid unnecessary renegotiation, the BIG-IP system uses the SSL session ID to ensure that a session is properly routed to the application instance to which the session first connected. Even when the client’s IP address changes, the BIG-IP system still recognizes the connection as being persistent based on the session ID.
  • Universal persistence - Universal persistence uses any piece of data (network, application protocol, payload) to persist a session. This technique requires the BIG-IP system to be able to inspect and ultimately extract any piece of data from a request or response. This technique is the basis for application-specific persistence solutions addressing popular applications like SIP, WTS, and more recently, VMware View. With universal persistence, you can write an expression that defines the data that the BIG-IP system will persist on in a packet. The expression, written using the same expression syntax that you use in iRules, defines some sequence of bytes to use as a session ID.

Connection Source IPs

THe BIG-IP system will used different source IPs for different traffic flows. Some of the notable ones to consider are:

  • SNAT Auto Map - Sourced from the FLOATING self IP
  • Monitors - Sourced from the local Self IP

Virtual Server Types

The BIG-IP system supports the following types of Virtual Servers

  • Standard - A Standard virtual server directs client traffic to a load balancing 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.
  • Forwarding (Layer 2) - The Forwarding (Layer 2) virtual server does not have pool members to load balance, and forwards packets based on routing decisions. The virtual server shares the same IP address as a node in an associated VLAN. The Forwarding (Layer 2) virtual server processes connections on a packet-by-packet basis with the following TCP behavior:
    • The initial SYN request is sent from the client to the BIG-IP LTM virtual server.
    • The BIG-IP LTM passes the SYN request to the node in the associated VLAN based on the routing decision.
    • The source MAC address is preserved, and the destination MAC changes based on routing.
  • Forwarding (IP) - A Forwarding (IP) 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.
  • Performance (Layer 4) - A Performance (Layer 4) virtual server is associated with a FastL4 profile. A Performance (Layer 4) virtual server increases the speed at which the virtual server processes packets
  • Performance (HTTP) - A Performance (HTTP) virtual server 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
  • Stateless - A stateless virtual server accepts traffic that matches the virtual server address and load balances the packet to the pool members without attempting to match the packet to a pre-existing connection in the connection table. 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.
  • Reject- A Reject virtual server rejects any traffic destined for the virtual server IP address.
  • DHCP - 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.
  • Internal - An Internal virtual server enables usage of Internet Content Adaptation Protocol (ICAP) servers to modify HTTP requests and responses by creating and applying an ICAP profile and adding Request Adapt or Response Adapt profiles to the virtual server.
  • Message Routing - A Message Routing virtual server routes messages between connections for various application protocols and functions in accordance with the respective protocol session profile and router profile.

Port Lock Down

The port lock down feature allows you to secure the BIG-IP system from unwanted connection attempts by controlling the level of access to each self IP address defined on the system. The system refuses traffic and connections made to a service or protocol port that is not on the list.

To configure port lock down in the GUI navigate to Network -> Self IP’s -> IP address

The option when configuring port lock down on a Self IP are:

  • Allow Default
  • Allow None
  • Allow Custom
  • Allow Default
  • Custom

The defined default list of services is:

  • igmp:any
  • ospf:any
  • pim:any
  • tcp:domain(53)
  • tcp:f5-iquery(4353)
  • tcp:https(443)
  • tcp:snmp(161)
  • tcp:ssh(22)
  • udp:520
  • udp:cap
  • udp:domain(53)
  • udp:f5-iquery(4353)
  • udp:snmp(161)

Packet filters - This needs to be reviewed

Packet filters enforce an access policy on incoming traffic and only apply to incoming traffic. They are enforced before Virtual Server selection.

Navigate to Network -> Packet Filters in the GUI to configure packet filters

  • Here you enable or disable packet filtering for the BIGIP
  • Change the default (implicit) action between deny or allow.
  • Configure exemptions to the policy - Mac Address, Vlans, Ips

Packet Filter Rules can build rules in the tcpdump syntax or in the config utility just like the UI of a normal FW.

Getting support form F5

  • All requests need to be submitted with a SN that is under a current support contract
  • Qkview generated and uploaded to iHealth
    • This can be generated by navigating to System -> Support and select QKView.

F5 Use the following severity ratings:

  • Sev 1 - 1 hour response - The device is down, will not pass traffic preventing critical activities
  • Sev 2 - 1 hour response - Software or hardware are preventing or significantly impairing business activates
  • Sev 3 - 4 Business hours - Software or hardware are creating a degraded service of functionality
  • Sev 4 - 24 hour response - Non critical trouble shooting, questions, how to’s

Initial Configuration

Methods to Connect

  1. Console cable
  2. Default ip address 192.168.1.245 (Hex for F5) Viprion is on 192.168.1.246
  3. LCD panel

Steps for configuration

  1. Change root password
  2. CLI - use the config command to set a management interface IP
  3. ..
  4. ..
  5. Licensing
  6. Resource allocation
  7. Device certificate
  8. Platform configuration (Passwords, hostname, SSH)
  9. VLANs and Self IPs ( Default is an External, Internal and HA VLAN)
  10. Configure DNS and NTP
  11. Configure HA options

Licensing

Two ways to licenses a F5 manual and automatic

  • Automatic needs the management interface to have access to the internet. The “Dossier” is sent to the F5 license server.

  • Manual - Copy the “Dossier” to your laptop and upload that to the F5 licensing server. A license will be returned that you can copy and paste onto the F5.

    get_dossier -b <LICENSE-KEY>

The URL to activate a license is - https://activate.f5.com/license/index.jsp

Backup and Restore

There are two methods of backing up the BIG-IP configuration.

UCS - User Configuration Set
  • A UCS can only be exported from and imported on the SAME hardware platform.
  • UCS files are stored in /var/local/ucs
  • A UCS file contains:
    • Configuration files
    • Product licensing
    • User accounts/passwords
    • SSL certificates and keys
  • When restoring the UCS file you can use tmsh load sys ucs <filePath/Name>.ucs no-license
    • The no-license flag will restore the ucs but not install the included license files. This is required for backups in a lab with 45day trials
  • UCS should be created on the active and standby unit.
  • Caution must be taken with a UCS that contains the SSL key
  • If restoring on a new system, a UCS archive that includes SSL private keys with encrypted passphrases cannot be decrypted by the new system. This is an intentional security measure.

GUI : System > Archives

  • tmsh save sys config
  • tmsh save /sys UCS </path/to/ucs>
  • tmsh save /sys UCS <path/to/ucs> passphrase <password>
  • tmsh save /sys ucs <path/to/ucs> no-private-key
SCF - Single Configuration File
  • A single configuration file (SCF) is a flat text file that contains a series of commands, and the attributes and values of those commands, that reflect the configuration of the BIG-IP system. Specifically, the SCF contains the local traffic management and TMOS configuration of the BIG-IP system.
  • Use a SCF file if you are going between hardware platforms, reproducing a problem in a lab.

  • There is a default SCF file that can be loaded to default the system

  • tmsh save /sys config file bigip1
  • tmsh load /sys config file bigip1

Vlan FailSafe

When you configure VLAN failsafe, the BIG-IP system monitors network traffic on the VLAN. If the BIG-IP system detects a loss of network traffic on the VLAN, the VLAN failsafe timer begins and the BIG-IP system attempts to generate traffic to nodes or the default router accessible through the VLAN in the manner described below:

  • Timer Half Expired
    • Initiates an Address Resolution Protocol (ARP) request for the IP address of the oldest entry in the BIG-IP ARP table
    • Initiates an ICMPv6 neighbor discovery probe (only if entries exist in the BIG-IP IPv6 neighbor cache)
  • Timer Three quatres expired
    • Initiates an ARP request for all IP addresses in the BIG-IP ARP table
    • Initiates an ICMPv6 neighbor discovery probe (only if entries exist in the BIG-IP IPv6 neighbor cache)
    • Initiates a multicast ping to 224.0.0.1

The default timer value is 90 seconds, and the minimum value is 10 seconds.

One of the following actions can be configured to be actinoid when the failsafe timer is expires:

  • Reboot - Specifies that the system restarts. Restart is the default action.
  • Restart All - Specifies that the system restarts all system services.
  • Failover - Specifies that the active unit fails over to its peer.
  • Failover Restart TM - Specifies that the active unit fails over to its peer and restart its TMM process.

Upgrades

Device -> Software Management - Image List

  • The devices are shipped with 3 partitions. The first and second partition contain the same image and the third is empty.
  • IMPORTANT - Configurations changes are not written to the additional partitions, booting to another partition will result in a blank device, no management or anything.
  • The process of installing an OS version to a partition will copy the current configuration at the time of the install. Don’t install and sit on that for weeks before upgrading.
Upgrade Process
  1. Reactivate the license of both units
  2. Disable VLAN FailSafe
  3. Set “Redundancy State Preference” to “none” on both units
  4. Create a UCS backup on each unit and copy it to a network location
  5. Copy the image and MD5 to both units
  6. Install and reboot into the new software on the standby Unit
  7. Confirm configuration is imported correctly
  8. Confirm that persistence and connections have replicated to the standby unit
  9. Fail over to Unit 2
  10. Install the new software on the Unit 1
Install Hotfix process

Device -> Software Management - Hotfix List

The process is the same as install a software version update.

Failover Commands

GUI - Device Management > Traffic Groups

  • Check the current FO status of the unit - It is also shown on the CLI prompt
    • tmsh show /cm traffic-group
    • tmsh show /sys failover
  • Force the device into standby mode
    • tmsh run /sys failover standby
  • To force a specific traffic group into standby mode on the device
    • tmsh run /sys failover standby traffic-group <traffic group name>
  • To force the device into standby mode and specify a device to take the active role
    • tmsh run /sys failover standby device <device name>

End-user diagnostics (EUD)

EUD is disruptive and can take a long time…..

The EUD software consists of a set of tests which report on various components in the hardware unit. The EUD is pre-installed on each BIG-IP system. Some parts of the hardware can only be checked if the system is offline and require the use of EUD. For compression hardware testing you must restart into the EUD partition to run the EUD tests.

If you want to evaluate potential hardware issues without booting the BIG-IP system into the EUD software, you can use the platform_check and platform_diag utilities.

Platform diagnostics are introduced in BIG-IP 11.4.0 and run a series of hardware diagnostics to quickly identify hardware failures on an F5 BIG-IP platform.

The platform diagnostic tests are only a subset of the tests available to the EUD software. However, the benefit is that you can perform the tests without actually booting the system into the EUD software.

Interfaces

F5 uses the term ‘Trunks’ when referring to a Port Channels/LAG

The BIG-IP system automatically assigns a unique MAC address to a trunk. However, by default, the MAC address that the system uses as the source and destination address for frames that the system transmits and receives (respectively), is the MAC address of the lowest-numbered interface of the trunk.

SNAT - Secure NAT

SNAT Auto Map will use the floating SelfIP not the chassis IP.

Administrator roles

There are many different admin roles that are defined in the system.

System > Users

  • No Access - Prevents users from accessing the system.
  • Guest - Grants users limited, view-only access to a specific set of objects.
  • Operator - Grants users permission to enable or disable existing nodes and pool members.
  • Application Editor - Grants users permission to modify existing nodes, pools, pool members, and monitors.
  • Manager - Grants users permission to create, modify, and delete virtual servers, pools, pool members, nodes, custom profiles, custom monitors, and iRules.
  • Certificate Manager - Grants users permission to add and remove certificates on the system.
  • iRule Manager - Grants users permission to create and modify iRules on the system. This user cannot manage the usage of the rules, just the rules themselves. For example, iRule managers can modify an iRule assigned to a virtual server, but they cannot assign that iRule to another virtual server.
  • User Manager - Grants users complete access to non-administrator accounts in the same partition.
  • Resource Administrator - Grants users complete access to all objects on the system, except user account objects. These users can perform configuration synchronization on a redundant system.
  • Auditor - Grants users complete read access to all objects on the system. These users cannot modify any configuration settings.
  • Administrator - Grants users complete access to all objects on the system. These users can perform configuration synchronization on a redundant system, and can perform the tasks required for licensing and adding new users.
  • Application Security Administrator - Grants users permission to view and configure all parts of the Application Security Manager, on all partitions. Application Security Editor - Grants users permission to view and configure most parts of the Application Security Manager, but only on the user’s partition. You can assign this role only when the system includes the Application Security Manager component.
  • Acceleration Policy Editor - Grants users permission to view and configure all parts of the Acceleration Manager, on all partitions. With respect to acceleration management policies, this role is equivalent to the Administrator role.
  • Firewall Manager - Grants users complete access to all firewall rules and supporting objects, including rules in all contexts, address lists, port lists, and schedules; security logging profiles and supporting objects, including log publishers and destinations; IP intelligence and DoS profiles; association rights for all of the above security profiles to virtual servers; and DoS Device Configuration (the L2-L4 DoS protection configuration).
  • Fraud Protection Manager - Grants users permission to configure the BIG-IP Fraud Protection Service (FPS) module. This role has full access to the Fraud Protection profile, and has complete read access to all objects on the system.
  • Other - Grants users permission based on a variable used by a remote authentication server, such as RADIUS or TACACS+. If the remote authentication server sends the variable as part of authenticating a user, the BIG-IP system uses the value of the variable as the user’s role.

When creating remote Auth groups they can be numbered form 1-1000. Processed in a top down 1 -> 1000 order. It is recommended that the first rule added is added as #1000