F5 201 v13.1 Certification Prep V3a - With Slide Notes

F5 201 v13.
1
Certification Prep
PRESENTED BY:
LEIF RASMUSSEN, SR SOLUTIONS ENGINEER – CHANNELS
L.RASMUSSEN@F5.COM
UPDATED: 13 AUG 2020
1
The goal:
If you are just starting your study it will, hopefully,
help you determine strengths and weaknesses
If you are almost ready, then it is an opportunity for

a final review and to ask questions
3 | ©2019 F5
3
Setting Expectations
This course is not designed to have you take the 201 exam after completion
Understand, I have no more idea what is actually in the exam than you do
• The material is based off the blueprint and my experience having taken prior F5 exams and practice exams
We will not cover every topic in depth

• There is simply not enough time.
• We will focus on the topics I think you need to know more deeply
• There are many links to addition information.
This isn’t a course to teach you how to configure a BIG-IP
• If you need basic Local Traffic Management training though, that can be arranged ;)
4 | ©2019 F5
4
F5 Certification Exams
Security 401 Cloud 402 Future
Future Exams
Solutions Solutions Enterprise
Solutions Expert
LTM
Specialist (b) 301b 302 303 304
DNS ASM APM Future
LTM Specialist Specialist Specialist Exams
Specialist (a) 301a
Technology Specialist
TMOS Administration 201 Future Exams Pre-Sales Fundamentals 202

Application Delivery Fundamentals 101
Administrator Sales Professional
5 | ©2019 F5
• All Certs/Exams are good for 2 years

• 201 will qualify you to take 300 level exams
• 202 will not qualify you to take 300 level exams
• You do not have to take 200 or 300 level exams in numerical order
• Any 300-level exam will renew Administrator certification
• However, a 300 exam will not renew any other 300 level certification other
than itself
• 401 needs LTM, ASM and APM
• 402 needs LTM and DNS
© 2017 F5 Networks 5
F5 101 Application Delivery Fundamentals
Exam 101 Blueprint
https://partners.f5.com/learning/certification
6 | ©2019 F5
6
Exam Structure
F5 101 EXAM - APPLICATION DELIVERY FUNDAMENTALS
• TMOS 13.1
• Multiple Choice (there are NO True/False questions!)
• Not Adaptive
• 80 questions in 90 mins
• Non-native English-speaking students have an additional 30 minutes!
• No command line engines (although you will have to know a few TMSH commands)
• View whole exhibit before you close them (attachments)
• Manage Your Time!
• You can flag, review and re-answer questions (within the 90-minute test limit!)
*Secure Sauce (exam tips) at the end of the presentation!
7 | ©2019 F5
How much do F5 exams cost? All F5 exams are currently priced at $180 USD
(not including local taxes and fees) per exam, per attempt.
How long are F5 exams? Most F5 exams are 90-minutes long, by default (not
including any non-native English or other accommodations).
What is the passing score for F5 exams? F5 Exams require a passing score of
245 out of a range between 0 and 350.
How many questions are there? Most F5 exams have 80 questions (70 items
that are scored, and 10 pilot/beta items).
What format are F5 exams? F5 Exams are all computer-based, multiple choice
response exams. Some questions contain exhibits or scenarios that you will
have to view to answer the question.
7
F5 Exams: Multiple Attempt Rules!
- After first failure, you must wait 15 days to re-test
- After second failure, you must wait 30 days to re-test
- After third failure, you must wait 45 days to re-test
- After fourth failure, you must wait 1 calendar year to re-test
- 5th and subsequent failed attempts, you must wait 90 days
8 | ©2019 F5
What is the F5 retake policy?

1st failure: Exam hold for 15-days (you cannot take the exam again for 15-
days);
2nd failure: Exam hold for 30-days;
3rd failure: Exam hold for 45-days;
4th failure: Exam hold for or 365-days;
5th and subsequent failed attempts: 90-days.
The retake count is only reset when the exam is passed.
8
Additional Certification Resources
• Practice Exams through ZooMorphix at www.examstudio.com
You will be able to setup account through Cert Program Enrollment Process
(see next slide for list of exams)
• Online exam study guides found here:

https://clouddocs.f5.com/training/community/f5cert/html/
(NOTE: supporting K-Doc for each objective is listed – very helpful!)
• LinkedIn
F5 Certified Professionals https://www.linkedin.com/groups/85832

LinkedIn – F5 Certified! – 101 https://www.linkedin.com/groups/6711359/profile
LinkedIn – F5 Certified! – 201 https://www.linkedin.com/groups/6709915/profile
9 | ©2019 F5
- Give a shout-out to Eric Mitchell!
9
Available F5 practice exams
10 | ©2019 F5
10
F5 201 v13.1 Certification Prep
BEFORE YOU ASK. YES, THE SLIDES ARE AVAILABLE FOR YOU TO REVIEW
A PDF copy of this slide deck with notes can be found on Partner Central in the Technical Hub under Technical
Certification:
This is a direct link to the PDF
11 | ©2019 F5
11
vLab Environment
• You will need exposure to the F5 TMOS GUI
• Because you are an F5 partner you can download our vLab Environment
https://downloads.f5.com/
• You will need to download necessary vLab content as well as BIG-IP VE
• You can run this in ESXi or anywhere you can run VMWare WS or Fusion.
• Follow instructions in the vLab documentation to build out environment.
This class/presentation content:

https://clouddocs.f5.com/training/community/f5cert/html/class1/class1.html
12 | ©2019 F5
12
K70671013: BIG-IP LTM-DNS operations guide
There currently is no study guide for the 201, but I strongly recommend you review the above article, you will also
see many links from the following manuals:
Manual : BIG-IP Local Traffic Management: Basics
https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-basics-13-0-0.html
Manual : BIG-IP TMOS: Routing Administration
https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-routing-administration-13-1-0.html
13 | ©2019 F5
13
Networking
Objectives 1.01 and 2.03
14 | ©2019 F5
14
1.01
Explain the relationship between interfaces, trunks, VLANs, self-IPs,
routes and their status/statistics
• Explain the dependencies of interfaces/trunks, vlans, self-IPs
• Compare Interface status (Up/Down)
• Illustrate the use of a trunk in a BIG-IP solution
• Demonstrate ability to assign VLAN to interface and/or trunk
• Distinguish between tagged vs untagged VLAN
• Identify, based on traffic, which VLAN/route/egress IP would be used

15 | ©2019 F5
15
Configuring the network
HTTPS://TECHDOCS.F5.COM/KB/EN-US/PRODUCTS/BIG-IP_LTM/MANUALS/PRODUCT/TMOS-ROUTING-ADMINISTRATION-13-1-0.HTML
0. Configuring the out-of-band management interface (eth0) on the control plane
1. Set up Interfaces and Trunks (L1)
2. Assign interfaces and trunks to VLANs (L2)
3. Assign Self IPs to VLANs (L3)
4. Set up Default Gateway
16 | ©2019 F5
The initial network configuration revolves around the control plane and involves
configuration the IP address and default gateway for the out-of-band interface
to all management access via SSH (CLI) or HTTPS (GUI).
Once that is complete you can configuration the data plane network
configuration, starting at L1 and working your way up.
1. Configure interfaces, physical or virtual interfaces and trunks as needed
2. Assigning interfaces/trunks to VLANs to define L2 broadcast domains.
3. And then assign IPs (Self IPs) to the VLANs to define the L3 broadcast
domains
4. Finally, assigning a default gateway(s) to determine the next hop for traffic
16
Interfaces
MANUAL CHAPTER : INTERFACES
• Networking Elements are found on the sidebar

• You should be familiar with the Interfaces, Routes, Self IPs, Trunks and VLANs selections
• You can determine interface status and Enable/Disable (state) interfaces
• Status: UP, DOWN, DISABLED, UNINTIALIZED (VE Only)
− K12697: Initialization of a TMM interface on BIG-IP Virtual Edition
• Interfaces can also be configured and enabled or disable via TMSH, for example:
− tmsh modify net interface 1.3 { disabled }
17 | ©2019 F5
As soon as the cable connection is performed on a physical BIG-IP device, the

system negotiates a link with the peer device and the status of the relevant
Traffic Management Microkernel (TMM) interface changes from down to up.
BIG-IP VE does not behave the same way. After a virtual network adapter has
been associated with a network connection on the host, the system will show
the corresponding TMM interface as UNINITIALIZED until that interface is
assigned to a VLAN.
You can safely ignore this behavior; it is expected. As soon as the interface is
associated with a VLAN, the status of the interface changes to UP.
17
Interface Statistics
• Errors – number of packets containing
errors
• Drops – number of packets drop for

processing or packet errors
• Collisions – should only occur on half-

duplex
(tmos)# show net interface
----------------------------------------------------------------------
Net::Interface
Name Status Bits Bits Pkts Pkts Drops Errs Media
In Out In Out
----------------------------------------------------------------------
1.1 up 111.4M 1.3G 136.1K 178.7K 0 0 10000T-FD
1.2 up 2.2G 170.3M 256.0K 260.3K 0 0 10000T-FD
1.3 disabled 0 5.1K 0 10 0 0 none
mgmt up 254.3M 831.2M 105.4K 139.0K 0 0 100TX-FD
18 | ©2019 F5
Interfaces statistics can be obtained via the GUI or TMSH. The statistics speak
for themselves, but note, Collisions. Collisions (for those of you to young to
remember) only occur on half-duplex links, where the inbound and outbound
traffic on running on the same pair of Cat 5 wires. Since modern device all run
in the full duplex mode collisions likely point to a physical or configuration issue.
18
On the topic of TMSH
HTTPS://CLOUDDOCS.F5.COM/CLI/TMSH-REFERENCE/V13/ WITH LINK TO FULL TMSH REFERENCE GUIDE PDF
When does the configuration get written to disk?
• In the GUI the changes are made to the running configuration and written to disk immediately.
• In TMSH configuration changes are made to the running configuration, but NOT written to disk
− A TMSH command is required to save the configuration to disk, or a change made through the GUI will force a write to disk
(tmos)# save sys config
Saving running configuration...
/config/bigip.conf
/config/bigip_base.conf
/config/bigip_user.conf
Saving Ethernet mapping...done
Show vs List
• show commands allow you to view runtime information, statistics and status
• list commands allow you to view the running configuration and settings
19 | ©2019 F5
Remembering general command structures, like show vs list should help you on
the exam. If, for example, you are asked which command would provide
interface statistics and you are given two commands that start with show and
two commands with list, you can easily eliminate the list commands because
they show configuration and chose from the other two.
19
BIG-IP Trunking
MANUAL CHAPTER: TRUNKS
A trunk is a logical grouping of interfaces on the BIG-IP® system.
• This is logical group of interfaces functioning as a single interface.

• Traffic is distributed across multiple links, in a process known as link aggregation.
• A trunk increases the bandwidth of a link by adding the bandwidth of multiple links together. The purpose of a
trunk is two-fold:
The purpose of a trunk is two-fold:
• To increase bandwidth without upgrading hardware

• To provide link failover if a member link becomes unavailable
The maximum number of interfaces that you can configure in a trunk depends on your specific BIG-IP platform
and software version.
20 | ©2019 F5
Trunks are a L1 construct the combine multiple links into a single logical L1
interface. The traffic hitting a trunk is distributed across the links/interfaces
assigned to the trunk. Trunks have advantages in failover because they are
more strictly monitored, but their main advantages are increasing bandwidth
capacity and provide link failover.
20
BIG-IP Trunks
BIG-IPS ACCEPT BOTH LACP (DEFAULT) AND ETHERCHANNEL LINK AGGREGATION
With BIG-IP trunking you can set up LACP (default) or Etherchannel (Cisco link aggregation)
• IMPORTANT: A BIG-IP trunk is not equivalent to a Cisco trunk with is VLAN tagging
− Cisco terminology uses Port Channel for link aggregation and trunk for 802.1q VLAN tagging
A trunk is created from the Network >> Trunks Once created the trunk shows up as an interface
21 | ©2019 F5
<intentionally left blank>
F5 Agility 2016 21
VLANs
MANUAL CHAPTER : VLANS VLAN GROUPS AND VXLAN
A VLAN is a logical subset of hosts on a local area network (LAN) that operate in the same IP address space. This
allow you to:
• Reduce the size of broadcast domains, thereby enhancing overall network performance.
• Reduce system and network maintenance tasks substantially.
• Enhance security on your network by segmenting hosts that must transmit sensitive data.
You create VLANs and associate physical interfaces with that VLAN.
• Any host that sends traffic to a BIG-IP® system interface is logically a member of the VLAN or VLANs to which
that interface belongs.
22 | ©2019 F5
You should all know the purpose of VLANs. They define L2 broadcast
domains.
F5 Agility 2016 22
Tagged vs Untagged VLANs
MANUAL CHAPTER : VLANS VLAN GROUPS AND VXLAN
If you wish to have more than one VLAN over the same physical
interface or trunk
Place interfaces and trunks into the Untagged or Tagged boxes
Untagged interfaces do not require a Tag be entered
• The BIG-IP will assign a Tag to logically separate internal traffic
Tagged interfaces run 802.1q VLAN tagging
• You need to manually enter the tag
23 | ©2019 F5
When creating VLANs you assign the interface that will support the VLAN traffic
and can program the BIG-IP to mark the VLAN as untagged or tagged (802.1q).
BIG-IP will automatically assign a tag to a “technically” untagged VLAN, starting
at the highest unused VLAN tag (by default 4094).
F5 Agility 2016 23
Distinguish between tagged vs untagged VLAN
This is pretty simple. In the GUI:
24 | ©2019 F5
It’s very simple to determine tagged or untagged VLANs thru the TMUI since
there are tagged and untagged columns. You can also see the VLAN tag
associated with the VLAN and interface(s). As you can see even untagged
interfaces have a tagged. This is a security feature of TMOS and the tag on
Untagged Interfaces is used for internal traffic to prevent any bleed over into
other interfaces.
24
A little more challenging in TMSH
(tmos)# list net vlan (tmos)# show net vlan new_vlan
net vlan ha_vlan { -------------------------------------

Net::Vlan: new_vlan
fwd-mode l3
-------------------------------------
if-index 160 Interface Name new_vlan
interfaces { Mac Address (True) 00:0c:29:5a:0b:23
1.3 { } MTU 1500
} Tag 30
tag 4092 Customer-Tag
}
-----------------------
net vlan new_vlan {
| Net::Vlan-Member: 1.3
fwd-mode l3 -----------------------
if-index 192 | Tagged yes
interfaces { | Tag-Mode none
1.3 {
tagged ----------------------------------------------------------------
} | Net::Interface
} | Name Status Bits Bits Pkts Pkts Drops Errs Media
| In Out In Out
----------------------------------------------------------------
| 1.3 up 867.1K 1.1M 652 3.3K 0 0 10000T-FD
25 | ©2019 F5
In TMSH it may be a little more challenging. By default, the default for any
command does not show up in TMSH or the bigip_base.conf (the configuration
unique to the BIG-IP) or the bigip.conf (the configuration shareable between
BIG-IPs).
25
Self IPs
MANUAL CHAPTER : SELF IP ADDRESSES
A self IP address is associated with a VLAN, to access hosts in that VLAN.
• The netmask of a self IP address represents an address space
Self IP addresses serve two purposes:
• First, when sending a message to a destination server, the BIG-IP system uses the self IP addresses of its
VLANs to determine the specific VLAN in which a destination server resides
− The BIG-IP system sends the message to the interface that you assigned to that VLAN. If more than one interface is assigned to the
VLAN, the BIG-IP system takes additional steps to determine the correct interface, such as checking the Layer2 forwarding table.
• Second, a self IP address can serve as the default route for each destination server in the corresponding VLAN.
− In other words, the BIG-IP can act as a default gateway for the server traffic
− In this case, the self IP address appears as the destination IP address in the packet header when the server sends a response to the BIG-
IP system.
26 | ©2019 F5
26
Types of Self IPs
You should understand the difference between floating and non-floating self IPs.
There are two types of self IP addresses that you can create:
• A static (non-floating) self IP address is an IP address that the BIG-IP system does not share with another
BIG-IP system.
− Any self IP address that you assign to the default traffic group traffic-group-local-only is a static self IP address.
− If the BIG-IP goes down, the static self IPs go down with it.
• A floating self IP address is an IP address that two BIG-IP systems share.

− Any self IP address that you assign to the default traffic group traffic-group-1.
− Or any traffic group that is NOT traffic-group-local-only (all other traffic groups are floating)
− A floating self IP only responds on the Active BIG-IP, if the Active BIG-IP goes down the floating self IP is activated on another BIG-IP in
the Device Service Cluster
27 | ©2019 F5
27
Self IPs
(tmos)# list net self
net self floating-ip {
address 10.1.20.240/24
floating enabled
traffic-group traffic-group-1
unit 1
vlan server_vlan
}
net self ha_ip {
address 192.168.20.245/24
allow-service {
default
}
traffic-group traffic-group-local-only
vlan ha_vlan
}
net self server_ip {
address 10.1.20.245/24
vlan server_vlan
}
net self client_ip {
address 10.1.10.245/24
vlan client_vlan
}
28 | ©2019 F5
Network >> Self IPs >> New Self IP – Allows you to configure a Self IP. Here
you configure:
• A logical name for the Self IP
• The IP address that defines the L3 IP network
• The net mask that defines the L3 broadcast domain
• The VLAN (L2) broadcast domain it resides in
• The Port Lockdown (what ports the IP address will respond to)
• By default the Port Lockdown is Allow None meaning the BIG-IP will only respond to
ICMP requests to the address.
• The Traffic Group the IP address resides in (more on this later), but in
general, non-floating IPs are unique to a BIG-IP device, where as, floating
Self IPs are an HA concept where the IP address can move to another BIG-
IP for failover purposes.
• A Service Policy, which is an Advance Firewall Manager construct not
relevant to the 201 exam.
28
Topic Resources
• https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/tmos-routing-administration-13-1-0.html
• Manual Chapter : Interfaces
• https://clouddocs.f5.com/cli/tmsh-reference/v13/ with link to Full TMSH Reference Guide PDF
• Manual Chapter: Trunks
• Manual Chapter : VLANs VLAN Groups and VXLAN
• Manual Chapter : Self IP Addresses
30 | ©2019 F5
30
2.03
Identify network level performance issues
• Interpret availability status of interfaces
• Identify Speed and Duplex
• Identify when drops are occurring
• Identify when a packet capture is needed within the context of a performance

issue
• Distinguish TCP profiles (optimized profiles)
31 | ©2019 F5
31
2.03 Interpret availability status of interfaces
You can determine interface status and Enable/Disable (state) interfaces
• State: Enabled, Disabled

• Status: UP, DOWN, UNINTIALIZED (BIG-IP VE)
− After a virtual network adapter has been associated with a network connection on the
host, the system will show the corresponding TMM interface as UNINITIALIZED until
that interface is assigned to a VLAN.
− K12697: Initialization of a TMM interface on BIG-IP Virtual Edition
32 | ©2019 F5
State is the administrative disposition of the interface. An administrator can

enable or disable interfaces as necessary. Status is the operation state of the
interface, which is Up, Down or Uninitialized. The Uninitialized state is unique
to BIG-IP Virtual Editions (VEs) and is the status of virtual network adapters on
BIG-IP that have not been assigned to a VLAN. Once assigned a VLAN the
interface will show an Up/Down status.
32
2.03 Identify Speed and Duplex
(tmos)# list net interface
net interface 1.1 {
if-index 48
mac-address 00:0c:29:5a:0b:0f
media-active 10000T-FD
media-fixed 10000T-FD
media-max auto
}
net interface 1.2 {
if-index 64
mac-address 00:0c:29:5a:0b:19
media-active 10000T-FD
media-max auto
}
net interface 1.3 {
if-index 80
media-max auto
}
net interface mgmt {
if-index 32
media-active 100TX-FD
33 | ©2019 F5
Interfaces can be viewed via TMSH or the TMUI.
33
2.03 Identify when drops are occurring
• Errors – number of packets containing
errors
• Drops – number of packets drop for

processing or packet errors
• Collisions – should only occur on half-

duplex
(tmos)# show net interface
----------------------------------------------------------------------
Net::Interface
Name Status Bits Bits Pkts Pkts Drops Errs Media
In Out In Out
----------------------------------------------------------------------
1.1 up 111.4M 1.3G 136.1K 178.7K 0 0 10000T-FD
1.2 up 2.2G 170.3M 256.0K 260.3K 0 0 10000T-FD
1.3 disabled 0 5.1K 0 10 0 0 none
mgmt up 254.3M 831.2M 105.4K 139.0K 0 0 100TX-FD
34 | ©2019 F5
In additional to status, you can get interface statistics via the TMUI or and
TMSH show command. These statistics will show whether or not the interface
is receiving or transmitting traffic, whether any drops or errors have occurred.
The TMUI will show if Collisions have occurred. Collisions are always indicative
of an interface issue since collisions only occur on half-duplex links and modern
network architectures should never be at half duplex. Drops can be indications
of overburden interfaces, in which case creating a trunk (link aggregation) made
be required to resolve the issue.
34
2.03 Distinguish TCP profiles (optimized profiles)
MANUAL CHAPTER : PROTOCOL PROFILES
K10711911: OVERVIEW OF THE TCP PROFILE (13.X)
tcp-lan-optimized and f5-tcp-lan profiles
• pre-configured profiles for LAN-based or interactive traffic
tcp-wan-optimized and f5-tcp-wan profiles
• pre-configured profile types for traffic over a WAN link
tcp-mobile-optimized profile
• pre-configured with default values set to give better performance to service providers' 3G and 4G customers.
mptcp-mobile-optimized profile (Multipath TCP)

• pre-configured profile type for use in reverse proxy and enterprise environments for mobile applications that are
front-ended by a BIG-IP system
35 | ©2019 F5
By default the server-side protocol profile will match the client-side profile, but
because BIG-IP is a full proxy architecture and each virtual server is
independently configured, you can optimize the TCP protocol on each side of
the connection for each virtual server optimizing TCP traffic based on the type
to traffic or network on either side of the proxy. The main TCP profiles you
should be familiar with are the TCP LAN optimized profiles, TCP WAN
optimized profiles and TCP mobile optimized profiles. You should understand,
generally, when these profiles should be implemented.
K10711911: Overview of the TCP profile (13.x)
35
TCP Acceleration Features
Goal: To improve the client experience
TCP Express (or TCP optimization)
• Adaptive congestion windows
• Fast retransmits
• Selective acknowledgements
• Congestion notification
TCP Client-Side Profiles
Goal: Server offload

Content Buffering
• Content spooling
Connection Management
• OneConnect
TCP Server-Side Profiles
36 | ©2019 F5
36
There are a number of connection oriented features which help BIG-IP

accelerate applications. These features either optimize traffic or help offload
valuable server resources.
TCP Express is label under which all BIG-IP TCP optimizations resides.
Because the BIG-IP has a full-proxy architecture we can tune TCP options on
the client-side connections differently from the TCP options on the server-side
connections.
This means while the server-side can be tuned for a LAN, the client-side can be
tuned for a wide area network with TCP options such as, adaptive congestion
windows, fast retransmits and selective acknowledgement and other TCP
options. This makes for more efficient and effective data transmission.
Connection oriented features that help reduce processing time on the back-end
servers are features such as content spooling and OneConnect. Content
spooling allows the server to send data faster than the client can accept it. In
this case the BIG-IP buffers the data and spoon feeds the client. OneConnect
is a connection aggregation and multiplex and feature which allows BIG-IP to
reuse back-end connections and save the servers CPU time by reducing the
number of connections maintained, set up and torn down.
These TCP acceleration features help boost performance and decrease the
amount of bandwidth required for an application.
36
Local Traffic ›› Profiles : Protocol : TCP
37 | ©2019 F5
37
In v11.6 the TCP profile was reorganized are the specific features each option
belong too. Some things to note:
• Proxy Buffer High and Low relate to content spooling and how much memory
PER CONNECTION is used for buffering data from the server
• Idle Timeout tell the virtual server the TCP profile is attached to when to
terminate an idle connection.
• Nagle – which combines a number of small packets into a larger packet for
efficiency.
F5 Agility 2016 37
Preconfigured TCP Profiles
K03553427: USING OPTIMIZED TCP PROFILES
V13.1.x
V11.4.x
38 | ©2019 F5
As you can see, F5 is constantly creating and tuning TCP profiles to make
implementation easier.
38
2.03 Identify when a packet capture is needed within the
context of a performance issue
LEARN F5 - F5 LEARNING SITE FOR F5 ENGINEERS, PARTNERS AND CUSTOMERS
K411: Overview of packet tracing with the tcpdump utility

• K6546: Recommended methods and limitations for
running tcpdump on a BIG-IP system
• K4714: Performing a packet trace and providing the
results to F5 Support
39 | ©2019 F5
You should be very familiar with creating and interpreting TCPDumps. We will
talk about TCPDumps numerous times during the training. You will be
performing and interpreting TCPDumps in the labs. There are excellent articles
on how and when to perform TCPDumps on a BIG-IP. In F5 Learn, which you
all should have access to, the are four free online courses (about 35 minutes
total length) to view on this topic and I strongly recommend you take them if you
are not already familiar with TCPDump.
39
BIG-IP Traffic Flow
Objective 1.02
40 | ©2019 F5
40
1.02
Determine expected traffic behavior based on configuration
• Determine the egress source IP based on configuration
• Consider the packet and/or virtual server processing order (wildcard vips)
• Identify traffic diverted due to status of traffic objects (vs, pool, pool member)
• Identify when connection/rate limits are reached
• Identify traffic diverted due to persistence
41 | ©2019 F5
41
1.02 Determine the egress source IP based on configuration
TRAFFIC FLOW THROUGH THE BIG-IP
TMOS is a full proxy architecture
Routed mode (recommended)

• Real servers are on an internal network behind the BIG-IP
• The BIG-IP is default gateway for the servers
• The virtual servers are on a client accessible network
Source Network Address Translation (SNAT) Mode
• The BIG-IP translates the original source IP, to an IP address owned by the BIG-IP
• Allows a BIG-IP to be inserted into existing networks without changing the existing IP address structure
• Can be used to create One-Armed/Single-Network mode
42 | ©2019 F5
Because TMOS is full proxy architecture traffic must pass through the BIG-IP in
both directions to gain the full benefit of all the application networking features.
Direct Server Return (DSR) is a rarely used exception to this rule. When
configured for DSR the LTM load balances to a server and then the server
responds directly to the client bypassing the BIG-IP. It is unlikely to be on the
201 exam.
Ideally, we would like to real servers to sit behind the BIG-IP and use the BIG-IP
as their default gateway. This is often referred to as routed mode. In this
scenario the applications sit behind the BIG-IP and the BIG-IP is the default
gateway for outbound traffic. Virtual Servers represent the application on the
client-side network and the BIG-IP acts as a firewall protect the applications
from external access.
In the real world though, you often need to insert the BIG-IP into existing
networks without changing the infrastructure. This can be accomplished
through the use of Secure Network Address Translation commonly referred to
as SNAT or One-Armed mode.
In this scenario, the servers have a default gateway that is not the BIG-IP, so
when inbound traffic directed to a server behind the BIG-IP, the BIG-IP
translates the original client IP address to an IP address owned by the BIG-IP.
When the server receives the request, the response is sent back to the BIG-IP
and the BIG-IP then process the request on the outbound connection. We will
walk through both routed and SNAT scenarios in a moment.
42
SNAT is also known as Source Network Address Translation is a secure way of
provide NAT, only the source IP can establish outbound sessions using a then
SNAT. Should a device request to open a connection to a SNAT inbound, that
request will be denied.
42
TMOS – Full proxy Architecture
SYN Client
ACK Data
Remember there are always two
SYN ACK
connections to a transaction.
The BIG-IP connection table Internet Client-Side

Server TCP Profile
contains information about all the Response
sessions currently established on
the BIG-IP system. TMOS – Full Proxy/Connection Mgmt
Client
• Can be displayed via TMSH Data Server-Side
• Shows client-side/server side SYN ACK TCP Profile
connection pairs
SYN
ACK
Server
Response
43 | ©2019 F5
BIG-IP is a full proxy architecture. There are always two connections for every
transaction. When troubleshooting where do you do a TCPdump, client-side,
server-side, both? What TCP profile should be on each side of the proxy?
BIG-IP maintains a connection table tying the client-side session to the

appropriate server-side session and there will be more on that later.
43
Traffic flow through BIG-IP when BIG-IP is the default gateway
ROUTED MODE
Client
The default gateway for the RED
3.3.3.3
and BLUE servers is 1.1.1.254 on
BIG-IP LTM
HTTP response HTTP request
DST: 3.3.3.3 DST: 2.2.2.2:80
SRC: 2.2.2.2:80 SRC: 3.3.3.3
BIG-IP LTM
http_vs 2.2.2.2:80 chooses RED
VLAN Internal VLAN External
IP 1.1.1.254 IP 2.2.2.254
Unique TCP
sessions
HTTP response
DST: 3.3.3.3 HTTP request
SRC: 1.1.1.1:8080 DST: 1.1.1.1:8080
SRC: 3.3.3.3
RED BLUE
44 | ©2019 F5
http_pool 1.1.1.1 :8080 1.1.1.2 :8080
This is an animated slide that is going to show IP and port translation as traffic
passed through the BIG-IP. The last animation brings up the unique TCP
sessions and here is a good time to point out the full proxy architecture (again)
and talk about the fact that to debug this connection you’d have to open two
TCPDUMPs and watch the client IP flow between the two TCP sessions.
44
SNATs and NATs
MANUAL CHAPTER : NATS AND SNATS
You can create NATs on a BIG-IP

• NAT is an address translation object to translate one IP address in a packet header to another IP address.
− Consists of a one-to-one mapping of a public IP address to an internal private class IP address.
Much more common and important are SNATs, understanding how SNATs work is key.
A secure network address translation (SNAT) is a BIG-IP Local Traffic Manager™ feature that translates the
source IP address within a connection to a BIG-IP system IP address that you define. The destination node then
uses that new source address as its destination address when responding to the request.
• Only the source can use the translation to establish connections
• Only supports TCP and UDP by default
This makes SNATs more secure then NATs
45 | ©2019 F5
SNAT is also known as SOURCE network address translation. Unlike a NAT

only the source (ingress) can use the address translation to establish
connections. Like with NATs, each SNAT connection uses a different ephemeral
ports (1024-65535), which means a single SNAT can only support roughly
64512 simultaneous connections. By default BIG-IP SNATs only support TCP
and UDP protocols.
I strongly recommend reading the SNAT portion of Manual Chapter: NATS and
SNATS
45
SNATs – How they are used
When the default gateway of the server node is not the BIG-IP system. This is a very common scenario.
• The server node’s default route cannot be defined to be a route back through the BIG-IP system.
• The client rejects a response because the source of not match the destination of the request.
• The solution is to create a SNAT.
• LTM then translates the client node’s source IP address in the request to the SNAT address of the BIG-IP
• This causes the server node to use that SNAT address as its destination address when sending the response.
• And forces the response to return to the client node through the BIG-IP system rather than through the server
node’s default gateway.
46 | ©2019 F5
SNAT is also known as SOURCE network address translation. I strongly

recommend reading the SNAT portion of Manual Chapter: NATS and SNATS
46
SNATs – How they are used
When clients and servers are on the same network

• You can create a SNAT so that server responses are sent back through the virtual server, rather than directly from the
server node to the client node
− Known as virtual server bounceback
When using the OneConnect feature

• OneConnect allows client requests to re-use idle server-side connections.
• Without a SNAT, the source IP address in the server-side connection remains the address of the client node that
initially established the connection, regardless of which other client nodes re-use the connection.
SNATs for server-initiated (outbound) connections

• When an internal server initiates a connection to an external host, a SNAT can translate the private, source IP
addresses of one or more servers within the outgoing connection to a single, publicly-routable address.
• Since only the servers can used the SNAT establish connections this is a much more secure.
47 | ©2019 F5
Since only the source, the servers in this case, can establish connections this is
a much more secure way for servers to access external resource. An attacker
cannot establish an inbound connection and will receive an immediately reset
(RST).
47
SNAT Automap and Self IP Selection
K7336: THE SNAT AUTOMAP AND SELF IP ADDRESS SELECTION
SNAT Automap uses the Self-IPs already assigned to the BIG-IP VLANs for translation.
• SNATs are almost always assigned at the virtual server level

• Automap can be applied globally, but you essentially change the BIG-IP from default deny, to default allow.
Selects a translation address from the available self IP address in the following order of preference:
• Floating self IP addresses on the egress VLAN

• Floating self IP addresses on different VLANs
• Non-floating self IP addresses on the egress VLAN
• Non-floating self IP addresses on different VLANs
48 | ©2019 F5
48
SNAT Automap simply tells the BIG-IP to use the self IP addressing of the
egress VLAN. The important thing to remember for the exam, is that when
using SNAT automap the floating self IP will be used first, until the ports are
exhausted. Once the ports are exhausted on the floating self IP, then the non
floating self IP will be used. If ports exhausted on both self IP addresses
connections will be dropped.
Also important is the fact, non floating self IPs cannot be used for applications
that require failover, because the IP address is unique to that BIG-IP. SNAT
mirroring mirrors the SNAT IP address and port utilized to the next active device
in the cluster.
© F5 Networks 48
SNAT Pools
RECOMMENDED READING: K7820: OVERVIEW OF SNAT FEATURES
SNAT uses ports to separate client connections
• This is also known as port overload

• More than roughly 64000 concurrent connections will exhaust the ports of a single SNAT’d IP
− Note: BIG-IP Cluster Multiprocessing (CMP) can cause this limit to be exceeded, but always plan using this as the maximum
• Once the ports are exhausted connections will be dropped.

− K8246: How the BIG-IP system handles SNAT port exhaustion
SNAT Pools must be used if the concurrent connections will exceed this limit.
• You will need enough IPs in the pool to handle the maximum number of concurrent connections.
An additional benefit of SNAT pools is that they failover seamlessly if SNAT mirroring is selected
49 | ©2019 F5
The main point to take away from this slide is that connections could be
dropped if you exceed the limitations of the SNAT IP addresses available. You
as an administrator have ways to determine if SNAT exhaustion is taking place
and seeing the maximum number of connections to the pool members and may
have to make recommendations. The number of connection can exclude SNAT
Automap from being used. Other advantages of using SNAT pools are the
ability to provide more seamless failover with SNAT mirroring and potentially
assigning specific SNAT addresses to specific virtual servers making it easier to
determine what traffic on the egress VLAN is coming which virtual server.
49
Traffic flow through BIG-IP when Source NATs are used
Client
3.3.3.3 The default gateway for the RED
and BLUE servers is 1.1.1.254 on
BIG-IP LTM
HTTP response HTTP request
DST: 3.3.3.3 DST: 1.1.1.5:80
SRC: 1.1.1.5:80 SRC: 3.3.3.3
BIG-IP LTM
http_vs 1.1.1.5:80
chooses RED
Default Outside TCP
VLAN onearmed Gateway
IP 1.1.1.100 IP 1.1.1.254 session
SNAT
HTTP response Inside TCP
DST: 1.1.1.100 HTTP request
SRC: 1.1.1.1:8080 DST: 1.1.1.1:8080 session
SRC: 1.1.1.100
RED BLUE
50 | ©2019 F5
http_pool 1.1.1.1 :8080 1.1.1.2 :8080
Let’s see what happens when we used a SNAT in our one-armed configuration.
This is an animation showing a client requests with a SNAT automap applied

globally. Note as the traffic passes through the BIG-IP the source IP address of
the client is changed to the IP address of the BIG-IP on the VLAN “onearmed”,
which is 1.1.1.100, so that when the real server receives a request, it sends the
response back to the BIG-IP because the server thought the BIG-IP made the
request.
50
Traffic flow if BIG-IP is not the gateway and SNAT not used
Who are you? Client Connections load balanced
3.3.3.3 The default gateway for the RED
and BLUE servers is 1.1.1.254 on to the RED server work fine,
BIG-IP LTM but connections load
Outside TCP HTTP request HTTP response balanced to the NEW server
DST: 1.1.1.5 DST: 3.3.3.3 are routed around the BIG-IP.
session SRC: 3.3.3.3 SRC: 1.1.1.2
The asymmetrical routing
BIG-IP LTM
connections will fail, because
http_vs 1.1.1.5:80
chooses BLUE the BIG-IP will not respond to
Default X TCP Session the ACK sent back from the
VLAN onearmed Gateway
IP 1.1.1.100 IP 1.1.1.254 is broken client to the backend server.
Monitors would indicate the
NEW server is up because
Inside TCP HTTP request
DST: 1.1.1.2 they are source from the
session HTTP response
SRC: 3.3.3.3
DST: 3.3.3.3
BIG-IP self IP address on
SRC: 1.1.1.2 that VLAN. On TCPDUMP
you would see traffic heading
for the server, but not coming
RED (GW 1.1.1.100) NEW (GW 1.1.1.254) back.
http_pool 1.1.1.1 :8080 1.1.1.2 :8080
51 | ©2019 F5
Our customer has put the BIG-IP into the network and the RED server is using
the BIG-IP as the default gateway everything is working. The server drops in a
NEW server, but they point the default gateway to 1.1.1.254, their standard
default gateway.
Connections load balanced to the RED server work fine, but connections load
balanced to the NEW server are routed around the BIG-IP. The asymmetrical
routing connections will fail, because the BIG-IP will not respond to the ACK
sent back from the client to the backend server. Monitors would indicate the
NEW server is up because they are source from the BIG-IP self IP address on
that VLAN. Everyone is scratching their head but you. You do a TCPDUMP
and see traffic going to the NEW server with the source IP address of the
original client IP, but nothing comes back. So, there is an intermediate
networking issue or a configuration issue on the NEW server or the BIG-IP. If
the SNAT was supposed to be applied the source IP on the server-side would
belong to the BIG-IP and a SNAT needs to be configure. If the BIG-IP is
supposed to be the BIG-IP, the NEW server needs to be reconfigured to reflect
that.
This is an animation showing the need for SNATs. Point out that the server’s
default gateway is not the BIG-IP and, as the animation continue, note that the
outbound traffic flows through the default gateway rather than the BIG-IP and
51
causes an asymmetrical routing situation. This will break the TCP session. For
example, if this were accessing a web site your browser window would pop up
as if you’re making a connection, but then just hang. Again it is a good time to
talk about using two TCPDUMPs for debugging this behavior. You will watch
the client IP access the virtual server and then be able to follow the client’s IP
address as the request heads for the real server, but you will not see return
traffic. This means that your customer has not reset the server default
gateways to the BIG-IP or you forgot to create a SNAT for that application
traffic.
51
1.02 Consider the packet and/or virtual server processing order
(wildcard vips)
K9038: THE ORDER OF PRECEDENCE FOR LOCAL TRAFFIC OBJECT LISTENERS
Packet Processing Priority

1. Existing connection in connection table
2. AFM/Packet filter rule
3. Virtual server
4. SNAT
5. NAT
6. Self-IP
7. Drop
52 | ©2019 F5
There is a specific order of precedence into how the BIG-IP processes traffic
that is sent to listeners on the BIG-IP. Listeners on a BIG-IP is IP addressing
capable of processing traffic, virtual addresses, SNATs, NATs and Self IPs. We
will go into more detail in the next few slides, but first let’s do a quick walk
though.
1. First, BIG-IP checks its connection table to determine if a flow already

exists, and if finds an existing flow it processes the traffic immediately
a) The connection table contains state information about client-side and server-side
connections and the relationships between them
2. If there is no connection table entry, packet filter rules are checked (or if
Advance Firewall Manager is licensed and provisioned, the firewall rules are
checked), if the request passes the filter/firewall rules, then
3. The most specific virtual server will then be used to process the request, in
no virtual servers match then
4. Check to set if this is an SNAT that matches, if it is an outbound initiated
connection allow it, if this is an inbound initiated connection deny it, if it
doesn’t match a SNAT then
5. Check to see if there is a NAT that matches, finally
6. Check the Self IPs, and if there are still no matches,
7. Drop the packet
52
• Contains state information about client-side and server-side connections and their relationships
• Changes to the virtual server do NOT affect existing connections
• Can be used for troubleshooting
• Can get very detail information on each connection
root@(bigip245)(cfg-sync Standalone)(Active)(/Common)(tmos)# show sys connection protocol tcp
Sys::Connections
10.128.10.1:55146 10.128.10.90:80 any6.any any6.any tcp 1 (tmm: 0) none
10.128.10.1:55450 10.128.10.90:80 10.128.20.245:55450 10.128.20.12:80 tcp 0 (tmm: 0) none
10.128.10.1:55476 10.128.10.90:80 10.128.20.245:55476 10.128.20.12:80 tcp 0 (tmm: 0) none
10.128.10.1:55458 10.128.10.90:80 10.128.20.245:55458 10.128.20.14:80 tcp 0 (tmm: 0) none
10.128.10.1:55126 10.128.10.90:80 any6.any any6.any tcp 2 (tmm: 0) none
10.128.10.1:55440 10.128.10.90:80 10.128.20.245:55440 10.128.20.14:80 tcp 0 (tmm: 0) none
53 | ©2019 F5
I am not sure if there is anything on the exam around connection tables, but it is
part of the processing priority so you should know some basics. The
connection table contains state information about the relationship between
client-side and server-side connections. This state table is maintained in
memory, the more memory, the more simultaneous connections a BIG-IP can
process, less available memory means fewer simultaneous connections.
Because the connection table is checked first, changes to a virtual server will
not impact existing sessions. You can get very detailed information on each
connection that can be used to troubleshoot problems.
53
2. Packet Filter Rules (or Advanced Firewall Manager if licensed, provisioned and configured)
• Disabled by default
54 | ©2019 F5
The BIG-IP can do L2/L3 access control list (ACLs) at the switch level. These
are standard L2-4 ACLs that are applied after the check for an existing
connection.
54
Each virtual server will uniquely

1. Existing connection in connection table A virtual server is an IP address
process client request that match
and service (port) combination its IP address and port
that listens for client requests
10.2.2.100:80 10.2.2.100:443
3. Virtual server
Each virtual server then
10.2.2.225:8080 directs the traffic, usually to
an application pool
The virtual server translates the
destination IP address and port
to the selected pool member
172.20.10.1 172.20.10.2 172.20.10.3 172.20.10.4

172.20.10.1:80 172.20.10.2:80 172.20.10.3:8080
55 | ©2019 F5
172.20.10.2:443 172.20.10.3:443 172.20.10.4:443
A virtual server is an IP address and port combination that clients connect to

when they want to access resources on the other-side of the full proxy, there
resources can be anything from a single server, to a pool of servers, to
networks. Virtual servers not only translate the virtual IP and networks, to a real
IPs and networks, but also can translate a virtual port to the real port used by
the application. A virtual server on a BIG-IP is much like a firewall rule, in that
access is limited to the defined source IPs, destination IP address or networks,
port and selected protocol. Multiple virtual servers can use the same backside
resources.
55
3. Virtual server
• Can be limited to specific source address(es)

• IP address and port combination to connect
− Or Network/Mask to process
• Is usually limited to specific protocols
• Also has an order of precedence (to be discussed)
56 | ©2019 F5
By default all source addresses (0.0.0.0/0) can access a virtual server, but the
source addresses allow to access a virtual server can be limited. The
Destination presented to the client-side of the proxy can be a specific IP
address, a specific network/mask or a wildcard virtual server (0.0.0.0/0) which
captures all traffic not processed by another virtual server. You can define the
port the virtual server will listens on or all ports (* wildcard). Placing a wildcard
in the Service port means port translation is turn off and the original destination
port which the client requested access to will be used on the server-side of the
proxy. If more than one port is required to process traffic for a particular virtual
address (virtual IP, for example port 80 and 443 for a web application, a virtual
server will be required for each port. There are always be a protocol definition
for the virtual server, which means only that protocol will be processed by the
virtual server. The exception is a wildcard for protocol, which means all
protocols will be process, typically this is only done on wildcard or network
virtual servers.
There is also an order to precedence to determine which virtual server process

the traffic which we will discuss in a few minutes.

exists, and if finds it does it processes it immediately
2. If there is no connection table entry, packet filter rules are checks, if the
56
request passes the filter rules,
6. Check the self IPs, and if there are still no matches,
7. Drop the packet
56
3. Virtual server
4. SNAT
5. NAT
6. Self-IP
• By default will only respond to ICMP packets
7. Drop
• BIG-IP is a default deny device and an ISCA certified firewall
57 | ©2019 F5
If no virtual server match is found, SNAT addresses, which were discuss earlier,
will be checked and process according. Then NAT addresses, and finally Self
IP address will be checked for a match.
We will look more closely at self IPs in the System Configuration sections, but
for now, understand by default a self IP address will only respond to ICMP
packets for purposes of checking network connectivity. Finally, if no match is
found the packet is dropped. The BIG-IP is a full proxy ISCA certified firewall
wall and for full firewall functionality you can license and provision the Advanced
Firewall Manager (AFM).

exists, and if finds it does it processes it immediately
2. If there is no connection table entry, packet filter rules are checks, if the
request passes the filter rules,
6. Check the self IPs, and if there are still no matches,
7. Drop the packet
57
Virtual Server Order of Precedence
K14800: ORDER OF PRECEDENCE FOR VIRTUAL SERVER MATCHING (11.3.0 AND LATER)
Order Destination Source Service port

Understand how a virtual server processes a request
1 <host address> <host address> <port>
• Precedence is from most specific to least specific 2 <host address> <host address> *
3 <host address> <network address> <port>
4 <host address> <network address> *
The BIG-IP system uses an algorithm that places virtual 5 <host address> * <port>
server precedence in the following order: 6 <host address> * *
7 <network address> <host address> <port>
• Destination address 8 <network address> <host address> *
− Which virtual address (IP) is most specific 9 <network address> <network address> <port>
10 <network address> <network address> *
• Source address
11 <network address> * <port>
− Is the source address permit to access the virtual address 12 <network address> * *
• Service port 13 * <host address> <port>
14 * <host address> *
− What is the most specific port match
15 * <network address> <port>
16 * <network address> *
17 * * <port>
58 | ©2019 F5
18 * * *
You should absolutely understand in detail how BIG-IP determines which virtual server will
handle a request.
<click> Brings up the grid order
• When traffic reaches the virtual server level of packet process the BIG-IP will first look for the
most specific match of the destination address.
• The BIG-IP will then ensure the source IP address is allow to access the virtual server
• If the source is not allowed the BIG-IP will check for the next closest destination match and re-check to see
if the source is acceptable
• If both destination and source are acceptable with will check to the if the requested inbound
port matches. If not, it continues it’s search for a match.
F5 Agility 2016 58
Virtual Server Match Examples
1. Specific IP address port with IP source of 10.30.1.0/24
Connect to: | Source IP
10.0.33.199:80
2. Specific IP address and specific port with IP source of 0.0.0.0/0
10.0.33.199:80 10.1.33.199:80 | 10.30.1.120
3. Specific IP address and all ports with IP source of 10.30.1.0/24
10.0.33.199:*
4. Specific IP address and all ports with IP source of 0.0.0.0/0 10.0.33.199:80 | 10.30.2.120
10.0.33.199:*
5. Network IP address and specific port with IP source of 0.0.0.0/0
10.0.33.0:443 netmask 255.255.255.0 10.0.33.199:443 | 17.64.223.120
6. Network IP address and all ports with IP source of 0.0.0.0/0
10.0.33.0:* netmask 255.255.255.0 10.0.33.196:443 | 10.30.1.120
7. All networks and specific port with IP source of 10.128.20.0/24
0.0.0.0:80 netmask 0.0.0.0
8. All networks and all ports with IP source of 0.0.0.0/0 74.125.21.106:80 | 10.128.20.100
0.0.0.0:* netmask 0.0.0.0
59 | ©2019 F5
For example, if a NEW connection from 10.1.30.1.20 is being attempted for

10.1.33.199 is being attempted on port 80, then BIG-IP will first attempt to
finding a matching destination. In this case since all the virtual servers are in
the 10.0.33.x ranges, 7 and 8 are the only possible matches, next the source is
checked and only 8 matches both the destination and sources, so the port is not
relevant and virtual server 8 processes the traffic.
8 - Connection to 10.1.33.199:80 from source 10.30.1.120

10.1.x.x does not match 1-6, and the source IP does not match 7
IP matches, source is a wildcard (match), Port matches
IP matches, source matches, port is a wildcard, #3 src IP does not match, #2 src port is 80 no match
5- Connection to 10.0.33.196:443 from source 10.30.1.120
Subnet matches, source is wildcard (default), port is more specific than #6
7- Connection to 74.125.21.106:80 from source 10.128.20.100
Nothing matches, wildcard virtual IP and src IP, but port matches, so no #8
F5 Agility 2016 59
1.02 Identify traffic diverted due to status of traffic objects
(vs, pool, pool member)
BIG-IP OBJECT STATE AND STATUS
How traffic is processed is affected by the state and status of an object.
States are:
• Enabled
• Disabled
Status is based on monitor responses and object hierarchy
• The virtual server status is determined by the status of the pool

• The pool status is determined by the status of pool members
• A pool member is determined by the status of the node
− Node is an IP address
60 | ©2019 F5
Statuses are based on the monitor responses and object hierarchies. It’s
basically, a leg bones connected to do knee bone, situation. The nodes are
affected by the status of the monitors that support them, the pool members are
affected by the status of their monitors or the node status, the pool status is
affected by the status of the members of the pool and the virtual server status is
affected by the pool status.
When a monitor check fails, the member become suspect and no new
connections are sent to it. There is no visible indication of this. The pool
member still maintains its existing connections.
If there’s a successful check before the timeout value is reached, then things
continue normally, and the pool member receives new connections.
If the monitor timeout is exceeded, that is if no successful monitor responses

have been received within the timeout period, then the member is marked
down. At this point the server-side connections between the BIG-IP in the pool
member are reaped, by default the client-side connection is unaware of this and
his connection is left fail after the idle time-out period or client-side actions.
This behavior can be modified by selecting the member and changing the
default behavior. For instance, you can have a reset (RST) sent back to the
client or attempt to re-load balance the connection.
60
12/8/2020
Load Balancing Components (Brief review)

64.128.16.100:80
Virtual Server
• Is the IP Address:Port combination that represents a pool to the outside world
• Is a combination of a virtual IP address and virtual port
− Both the virtual IP address and the virtual port can be translated to match the pool member
• Access is limited to the defined port only
10.20.3.110:8080 10.20.3.120:8080
• Multiple virtual servers can use the same servers or pools
Pool
• A pool is a group of members supporting a particular application
• Each pool has its own characteristics, such as, monitor(s) and load balancing method 10.20.3.110:80 10.20.3.120:80
Member
• A member is the IP Address:Port combination to access an application on the server
• Members are combined to form pools of applications 10.20.3.110:80 (http)
10.20.3.110:443 (https)
• Since a single server may host multiple applications, a single server may be a part of multiple pools
Node
• Is the IP address of the server supporting applications
10.20.3.110
61 | ©2019 F5
Before we continue let’s review the terminology and the hierarchy of the
components that comprise an application on the BIG-IP.
1. The most basic component is the node. This is the IP address of a
server which host one or more applications. Nodes can be
monitored. If monitored, a nodes status impacts the status of the
configuration objects it supports.
2. The configuration objects supported by a node are pool members,
which are simply IP address:port combinations allow access to an
application on a server.
3. Pools are comprised of one or more pool members supporting an
application. Each pool has its own unique configuration, such as,
load balancing method and monitor(s). Monitors at the pool level
should be application specific, such as an HTTP request. Monitors
at the node level should be generic, like ICMP.
4. Finally the virtual server is comprised of a virtual IP address and
virtual port representing the pool to the clients. The BIG-IP can
translate port the IP and port to the selected IP and port of the pool
member.
Configuration object status is hierarchal in nature. The status of the

higher level objects is base on the underlying components. So the
status of the node can determine the status of the pool members it
61
supports, the status of the pool members impact the status of the pool and the
pool status directly impacts the status of the virtual server.
61
12/8/2020
Monitor Status Reporting

Status Status Definition
Available General: Child • Monitor successful
General: Parent • At least one child is Green
Child –Node • Most recent monitor successful
Pool Member • Most recent monitor successful
Pool • At least one pool member is available
Virtual Server • At least one pool is available
Unknown General: Child • No associated monitor (or timeout of first check not reached)
General: Parent • All child objects are unknown (blue)
Node • No associated monitor (or timeout of first check not reached and not
successful)
Pool Member • No associated monitor (or timeout of first check not reached and not
successful)
Pool • All pool members are unknown (blue)
Virtual Server • All pools are unknown (blue)
Offline General: Child • Monitor failed
General: Parent • At least one child red AND no green or yellow children available
Node • Most recent monitor failed (no successful checks within timeout period)
Pool Member • Most recent monitor failed (no successful checks within timeout period)
Pool • One or more members are offline and no members are available
62 | ©2019 F5 Virtual Server • One or more pools offline and no members available
As you can see by the shapes F5 caters to the colorblind as well as those with
normal eyesight. The main thing to take away from this chart is that green does
not mean good. Green means there’s something available to connect too,
below the object. If I have seven members in a pool and six members are
down, the virtual server object is green (available), but things are obviously not
in good condition.
62
Other Statuses and State
• Currently Unavailable
• The virtual server or all its resources have reached a restricting connection limit
that has been set by the administrator
• A pool member have reached a restricting connection limit that has been set by
the administrator
• The object has no further capacity for traffic until the current connections fall
below the connection limit settings.
• Disabled
• The object has administratively marked down and will not process traffic
• The status icon will be a shape that represents the current monitor status of the
object, but will always be colored black.
• A grey status shape would mean the parent object has been disabled.
• If is disable a node, the pool member associated with the node would go grey
63 | ©2019 F5
Currently Unavailable means the configuration object is still processing traffic

but is unable to accept new connections. This status will only be seen if
connection limits have been put in place on the node, pool member or virtual
server levels. There will be more on connection limits in a few slides.
When a configuration item is administratively Disabled, is status shape at time it

was disabled turns black and the status shapes of any supported configuration
items turn gray. For example, if you disable a node, all the pool members the
IP address of the node supports, turn gray and can only be brought back to
Available by Enabling the node. As an administrator you may disable nodes,
pool members or virtual servers for a number of reasons, such as maintenance
windows on servers.
F5 Agility 2016 63
Status and State
(tmos)# show ltm node 10.1.20.14
------------------------------------------
Ltm::Node: 10.1.20.14 (10.1.20.14)
------------------------------------------
Status
Availability : available
State : disabled
Reason : Node address is available, user disabled
Monitor : icmp
Monitor Status : up
Session Status : user-disabled
64 | ©2019 F5
You should be able to interpret status and state information from TMSH or the
TMUI. As you can see here, the Node (IP address) even though the node IP
address is responding to pings (monitor up), it has been administratively
disabled, and the BIG-IP will not long pass traffic to to pool members using the
node IP address 10.1.20.14.
64
Status and State – Network Map
65 | ©2019 F5
The network map is a great place to get and overview of the status of objects.
You can hover over the , the pool members to see the node status. For
example:
hackazon-vs - note there is no node monitor, is in Unchecked the BIG-IP will
always assume the node up, the status of the virtual will only be affected be the
pool status and the pool member will only rely on the monitor status
Purple_vs – here the node status is available, so monitors at the pool member
level are affecting the virtual server status
www_vs/ftp_vs – here the node state/status affects the state/status of multiple
objects, across multiple virtual servers. Assuming the node 10.1.20.11 was
Enabled – Available (Offline) how would the statuses change? Could you
enable the pool member 10.1.20.11:21 in the ftp_pool and affect the statuses.
65
1.02 Identify when connection/rate limits are reached
MANUAL CHAPTER : SETTING CONNECTION LIMITS
Connection limits can be applied to, nodes, members and virtual servers
Connection limits on an object can be affected by other settings

• If a node is part of multiple pools, connections for all pools should be taken into account
• In the node limit is lower than the pool members, then the member will never reach max count
• The same applies to virtual server limits versus pools limits.
Persistence and “Override Connection Limits” can also impact overall connections
Each TMM will process connections for an object

• BIG-IP divides the connection limit by the number of TMM instances and rounds down
• Therefore, you may reach the number of max number connections prior to hitting the actual limit
− For example, 10 connections per member, on CMP system running 4 TMM instances, would allow each instance to handle 2 connections, thus you would only
get 8 connection to a particular member.
− K8457: Connection limits for a CMP system are enforced per TMM instance
Connection Limits can activate priority groups

66 | ©2019 F5
66
Identify traffic diverted due to persistence
MANUAL CHAPTER : SESSION PERSISTENCE PROFILES
Directs a client back to the same server after the initial load balancing decision has been made
• Is required for stateful applications
• May skew load balancing statistics
The persistence profile is assigned at the virtual server level.
Persistence methods should know

• Source Address Affinity (aka Simple) Persistence (Base on source IP and network mask)
• Cookie Persistence (Recommended for HTTP)
Other persistence methods

• SSL Session ID, Session Initiated Protocol (SIP), MSRDP
• Universal Persistence
− iRules can create persistence records based on anything in the client’s request, such as, jsessionid, username, etc.
67 | ©2019 F5
The concept of persistence revolves around the need for stateful applications to
continue to return application request from the same source to the same server
that processed the original load balanced request. Persistence profiles are
assigned at the virtual server and use several different methods to create a
record to return the clients traffic to the server the client was originally load
balanced to. The most common of theses methods, and the ones you should
be more familiar with are Source Address Affinity, Cookie, and Universal.
Source Address Affinity creates a record base on the network and mask
configured, by default 255.255.255.255, of the clients source IP in memory on
the BIG-IP.
There are several cookie methods, the most common being Cookie (Insert)
mode. This profile creates a new cookie with persistence information which is
returned to the requesting browser.
Universal persistence is basically using an iRule to create persistence records
base on whatever criteria the administrator desires that can be found in the
transaction, such as a jsession id for WebSphere transactions. Other
persistence methods are unlikely to show up on the exam.
67
Source Address Affinity Persistence
18.200.150.10
Internet
In standard LTM load balancing,

With persistence, LTM directs
each client request is directed to
subsequent requests from a client
a different pool member
to the same pool member until the
persistence record expires 10.2.2.100:80 10.2.2.100:443
Source Addr Affinity
172.20.10.1 172.20.10.2 172.20.10.3 172.20.10.4

172.20.10.1:80 172.20.10.2:80 172.20.10.3:8080
68 | ©2019 F5 172.20.10.2:443 172.20.10.3:443 172.20.10.4:443
Let’s take a look at an example of the Source Address Affinity persistence

method, which was also known as Simple persistence. In the case we have a
source address affinity persistence profile on the 10.2.2.100:80 virtual server.
1. Without a persistence profile, each new connection the client 18.200.150.10
makes would potentially be load balanced to a different pool member
2. Now let’s add a source address affinity profile with and default mask of
255.255.255.255 (each unique IP gets a persistence record)
3. With the source address affinity profile as BIG-IP makes a load balancing
decision a persistence record is create in memory which tells us,
18.220.150.10 came into shop_vs (vitual server 10.2.2.100:80) destined for
the http_pool and was load balanced to pool member 172.20.10.1:80.
4. With persistence the BIG-IP will direct all subsequent request from
18.200.150.10 to pool member 172.20.10.1:80 until the persistence record
expires.
Something to think about. If this was a single HTTP/HTTPS application what

would happen with the client went over to the HTTPS side of the application,
say to checkout. The answer, if the 10.2.2.100:443 virtual server doesn’t have
a persistence profile or doesn’t honor the persistence record of the
10.2.2.100:80 virtual server, then the client could potentially be load balanced to
a new pool member losing its application state.
68
Cookie Persistence The user selects to make a
purchase and is redirected
MANUAL: SESSION PERSISTENCE PROFILES to the HTTPS virtual server.
HTTPS Sending the cookie along
18.200.150.10
Internet with then request.
HTTP
Configure a persistence profile

using the desired cookie
persistence method and assign
the profile to the virtual servers.
10.2.2.100:80 10.2.2.100:443
The BIG-IP makes a load
balancing decision and
then creates a cookie and Cooky Cooky
returns it to the browser
The BIG-IP reads the
cookie.
The user builds their
shopping cart on
✓Item 1
node 172.20.10.1
✓Item 2
✓Item 3
This client is directed to the
same Web server that contains
172.20.10.1 the shopping cart and can 172.20.10.3
172.20.10.2
172.20.10.1:80 complete their purchase
172.20.10.2:80 172.20.10.3:8080
69 | ©2019 F5 172.20.10.1:443 172.20.10.2:443 172.20.10.3:443
Cookie persistence is always recommended for web application. The BIG-IP

does not have to maintain the records
• Configure the persistence method to use Cookie Persistence and
associate it with both virtual servers
• The user connects the virtual server and the virtual server, the BIG-IP
makes a load balancing decision and the BIG-IP
• Cookie Insert - Creates a cookie with pool member. This is the F5 recommended
method.
• Cookie Passive – Simply reads the pool member in the cookie. The backend
servers are responsible for inserting the selected pool member into an existing
cookie.
• Cookie Rewrite – Inserts the pool member into an existing cookie
• Cookie Hash – use a hash of a cookie value to determine the member
• The user builds their shopping cart on node 172.20.10.1
• The user selects to make a purchase and is redirected to the https virtual
server
• The secure virtual server reads the persistence information from the cookie
because it has the same persistence profile.
• This client is directed to the same Web server that contains the shopping
cart and can complete their purchase
69
Persistence Settings
Match Across Services

• When enabled, specifies that all persistent
connections from a client IP address that go to
the same virtual IP address also go to the same
pool member
Timeout
• Specifies the duration of the persistence
entries
• Resets on a new connection
Override Connection Limit

• Allows new connections to be established if
the connection limit is reached, if there is a
persistence record
70 | ©2019 F5
There are some other persistence settings worth noting.
1. The timeout period defines the duration of time a persistence record will
remain in memory. The timeout period is reset on each new connection
using the persistence record. So, if a user has a persistence record that
has a timeout of 24 hours and the user returns 23 hours later, the timer is
refreshed, and the records remains in memory for another 24 hours.
2. If you cannot use cookies and have to rely on persistence records
maintained on the BIG-IP you may have a requirement to match across
services. When Match Across Services is enabled, virtual servers with the
same Virtual Address will honor a persistence record created by any other
virtual server with that Virtual Address and configured to use the same
persistence profile In our earlier example of source affinity address
persistence, if the 10.2.2.100:80 and 10.2.2.100:443 virtual servers both had
the same persistence profile, then when a client came into 10.2.2.100:80 a
persistence record would be created and when the client moved to HTTPS
at 10.2.2.100:443 the virtual server would find the record already create be
the HTTP virtual server.
3. We talked about Connect Limits earlier, the Override Connect Limit check
box allows the BIG-IP to create a new connection for a client that exceeds
the connection limit, if a valid persistence record is found.
70
Persistence Methods
MANUAL: SESSION PERSISTENCE PROFILES
Configured under Resources in a Virtual Server
Fallback persistence
• If there is not a persistence record from the Default
Persistence Profile
• Check if a persistence record was created by the fallback
and use that recordF
Fallback example:
• If users don’t allow cookies fallback to source persistence.
71 | ©2019 F5
In addition to the default persistence method, you can create a fallback

persistence method in case the default method cannot be used.
For example, if your web site normally uses cookies, but some of your
customers do not allow cookies you could set Fallback persistence profile to
another persistence method. For each new user coming in a record will be
created for both profiles. Users would be able to persist to pool member they
were initially load balanced to using one of the two methods. In this case you
do lose some of the advantages of cookie persistence, for instance, the BIG-IP
will have to consume memory to maintain the source persistence records and
those records will need to be mirrored to the failover
F5 Agility 2016 71
Topic Resources
• Manual Chapter : NATS and SNATs
• K7336: The SNAT Automap and self IP address selection
• K7820: Overview of SNAT features
• K8246: How the BIG-IP system handles SNAT port exhaustion
• K9038: The order of precedence for local traffic object listeners
• K14800: Order of precedence for virtual server matching (11.3.0 and later)
• Manual Chapter : Setting Connection Limits
− K8457: Connection limits for a CMP system are enforced per TMM instance
• Manual: Session Persistence Profiles
72 | ©2019 F5
72
Lab 1 – Accessing the Lab, Networking and BIG-IP Traffic Flow
Accessing the Lab Environment
Networking the BIG-IP
Packet Processing Lab
Packet Filter Lab
Virtual Server Packet Processing
73 | ©2019 F5
73
Accessing the Lab
• Go to https://udf.f5.com and select Non-F5 Users
• Find 201 Certification Training under Happening Now
• Click on the Deployment tab
• Go to the UBU-JUMPBOX instance, select Access and XRDP
• Open a browser window in the Jumpbox and select the Lab Guide
link on the bookmark bar
74 | ©2019 F5
74
Virtual Servers
Objectives 4.01, 1.03, 2.02
78 | ©2019 F5
78
4.01
Apply procedural concepts required to modify and manage virtual
servers
• Apply appropriate protocol specific profile
• Apply appropriate persistence profile
• Apply appropriate HTTPS encryption profile
• Identify iApp configured objects
• Report use of iRules
• Show default pool configuration

79 | ©2019 F5
79
4.01 Apply appropriate protocol specific profile
MANUAL CHAPTER: VIRTUAL SERVERS
All virtual servers must a Protocol profile assign
If looking beyond L4 information is required, then the

appropriate L7 profile needs to be assigned.
• For example, FTP profile for FTP applications

• For example, HTTP profile if the cookie or other
information needs to be view or manipulated.
80 | ©2019 F5
Every virtual server will have a L4 profile assigned, beyond that you may be
required to add a L7 profile if you want to dig deeper into the protocol for the
purposes of using other protocol profiles or iRules to manipulate or log
application traffic. For instance, if I want to use cookie persistence, I would
require the HTTP profile, so that the TMOS would parse out the HTTP header
and data information and make the cookie available to be viewed or inserted.
Because HTTP runs over the stateful transport protocol TCP, a TCP profile
would need to be attached to the virtual server.
80
4.01 Apply appropriate persistence profile
MANUAL CHAPTER : SESSION PERSISTENCE PROFILES (REVIEW)
The persistence profile is assigned at the virtual server level.
Cookie Persistence is the preferred method for HTTP applications.
Simple Persistence (based on source IP and network mask) should be used for most other applications
Universal Persistence uses an iRule to persist on custom application data, ie. jessionid
A fallback persistence method should be used if not all clients can use the primary persistence method.
81 | ©2019 F5
81
4.01 Apply appropriate HTTPS encryption profile
K14783: OVERVIEW OF THE CLIENT SSL PROFILE (11.X - 16.X)
K14806: OVERVIEW OF THE SERVER SSL PROFILE (11.X - 16.X)
SSL Profile requirements
• SSL Client-Side profile, with the appropriate cert & key for SSL
offoad
• SSL Server-Side profile, if the pool members service HTTPS (443)
traffic
An HTTP profile is NOT required.
82 | ©2019 F5
You can have an HTTPS virtual server talk directly to an HTTPS pool without
having SSL profiles evolved. In that scenario, the client and server would
exchange keys and build a encrypted connection directly with each other. Only
L4 information would be available for TMOS to view, log or modify, as the HTTP
header and data would be encrypted as it moved through the full proxy
architecture.
SSL profiles are required when you want to;

• reduce load on the back-end servers, known as SSL offload,
• View, log or manipulate the HTTPS traffic
• Secure against SSL attacks, such as, SSL renegotiation attacks,
• Proxy SSL ciphers,
• The servers can only do TLS 1.1 or 1.2 and you or require TLS 1.3 to the client.
• You want to lower key size to the servers to reduce load, but still secure the traffic.
SSL Client-Side profiles negotiation the key exchange and ciphers between the
BIG-IP and the client
SSL Server-Side profiles do the same between the BIG-IP and the pool
members
An HTTP profile is only required if you wish to view, log or manipulated the
application traffic as HTTP.
82
Because of the full proxy architecture and there are potentially two distinct
encrypted sessions. If client-side and server-sider SSL profiles are used
together, the only time the data is unencrypted is within TMOS.
82
12/8/2020
Processing SSL Traffic on the Client-Side

To configure a virtual server to process HTTPS:
• Import/Create certificate and key
• Create a client SSL profile,
− Attach the certificate and key
• Create a virtual server

− In the SSL Profile (Client) box choose the SSL profile
How client-side processing works Client SSL

Profile
• Client connects to a virtual server that is configured with the client SSL profile
• The client and BIG-IP perform a key exchange and establish an encrypted session
• The virtual server receives the client traffic
− Decrypts traffic
− Performs traffic management functions
− For example, iRules or cookie persistence
• The BIG-IP sends the unencrypted traffic to the chosen pool member
83 | ©2019 F5
Converting a web site from http to https is very easy. First you create or import
your certificate and key and create a client SSL profile using that certificate and
key. Then on the virtual server you use the SSL profile client drop down menu
to select the SSL profile required.
The client accesses the virtual server with the SSL client profile, the key
exchange is performed, the encrypted session established and the client
proceeds to talk to the application through the BIG-IP. The virtual server
receives the traffic, decrypts the traffic and then can read, rewrite or redirect the
traffic as desired. The traffic is then sent unencrypted to the chosen pool
member.
83
Processing SSL Traffic on the Server
Use SSL server profiles for highly secure environments that required L7 (HTTP) processing in TMOS
• Configure a server-side SSL profile
− Certificate could be self signed of lower encryption
• Attach the SSL Server profile to the virtual server
Client SSL
Profile
How server-side processing works
• Client connects to the virtual server using the cert and key in the client SSL profile
Server SSL
• They establish an encrypted session Profile
• The virtual server receives and decrypts the traffic
• Performs traffic management functions
• An encrypted session is established between BIG-IP LTM and the selected pool member.
− Using the certificate and key in the SSL Server profile
• The data is re-encrypted and sent to the pool member

84 | ©2019 F5
If your client wishes a highly secure environment and wants end-to-end

encryption, offloading SSL to the BIG-IP still provides numerous advantages.
For starters, the BIG-IP can still delve into the packets as are moving through
and perform traffic management functions. While you may not save all the
server resources you would with unencrypted traffic, you can still reduce the
workload of the back-end servers by having them use lower encryption level
between the server and the BIG-IP, while having the BIG-IP do higher
encryption levels between itself and the client.
The process is basically the same as with client-side SSL. Configure your SSL
profile and choose that profile from the “SSL profile server” drop down menu on
the virtual server. Everything else proceeds exactly as we discussed earlier
with the exception that the data is a re-encrypted before sending it on chosen
pool member.
84
4.01 Identify iApp configured objects
85 | ©2019 F5
As of version 15.0 iApps are beginning to be phased out and replace with F5
Application Services Templates (FAST) which are base on F5 Applications
Services (AS3), whereas iApps are a conglomeration of TCL, TMSH, APL,
HTML. For the purposes of the current 201 exam, iApps are application
templates design to ease configuration of specific applications on the BIG-IP.
By default, application objects configured via iApps cannot be modified except
through the application template used to create them. This is know as strict
mode. Virtual servers created via iApps are easily identified because they will
have the name of the application template under the Application column and
all objects created by that application will have the application name as a prefix
of the name of the object. For example, on the slide, you can see the virtual
server 10.1.10.120:80 was created by an iapp (in this case using the f5.http
template) with the name created_with_iapp and the virtual server name,
created_with_iapp_vs, was automatically generated using the application name
as a prefix.
85
4.01 Identify iApp configured objects
86 | ©2019 F5
Another advantage of iApps created applications is the administrator has a

single pane of glass to view all the objects created by the template and can
enable or disable configuration objects from this view. If the application is
deleted, all configuration objects created by the application are d
86
4.01 Report use of iRules
87 | ©2019 F5
iRules can be viewed in the Statistics interface all with the number of times they
have been executed, times they failed or were aborted. This can generally give
you an idea if an iRule is actually being used. The best and easiest way to
determine what virtual server is using which iRule(s) is via the network map.
87
4.01 Show default pool configuration
GUI
• Local Traffic >> Virtual Servers >> Virtual Server List >> <select virtual server> under the Resources tab
TMSH
• list ltm virtual
• list ltm virtual pool
Network Map
88 | ©2019 F5
The default pool for a virtual server is found in the Resources tab of the Virtual
Server in the TMUI. It can also be found using TMSH or the Network Map. The
default pool is the pool traffic goes too if not sent to another pool or diverted via
an iRule. For example, I may have a virtual server with the default pool
html_pool and an iRule that diverts request for images, .jpg and .gif to a pool
of image servers. If the mime type matches .jpg or .gif, the default pool will not
see the traffic, the image pool will receive the traffic and respond with the
image. All other traffic not matching those mime types will be processed by the
default pool html_pool.
88
1.03
Identify the reason a virtual server is not working as expected
• Identify the current configured state of the virtual server
• Identify the current availability status of the virtual server
• Identify misconfigured IP address and/or Port
• Identify conflicting/misconfigured profiles
89 | ©2019 F5
When troubleshooting, start with the obvious and then dig deep.
• First, check the status of the virtual, is it configured with the right IP address
and port
• Digging deeper, look at the virtual server configuration via the GUI, tmsh
(with the “list” virtual server command) or directly at the configuration file
/config/bigip.conf
• Is the right protocol profile attach, for example a wildcard virtual with a TCP profile will
drop UDP and ICMP traffic, which may not be desired
• If it’s an HTTPS virtual are the appropriate SSL profiles configured
• If the BIG-IP is not the default gateway for the pool is SNAT configured.
89
1.03 Identify the state and status of a virtual server
# show ltm virtual www_vs

------------------------------------------------------------
Ltm::Virtual Server: www_vs
-----------------------------------------------------------
Status
Availability : available
State : enabled
Reason : The virtual server is available
CMP : enabled
CMP Mode : all-cpus
Destination : 10.1.10.100:80
Traffic ClientSide Ephemeral General

90 | ©2019 F5
Bits In 577.1K 0 -
<cut>
• First, check the status of the virtual, check if it is configured with the right IP
address and port
• Is the virtual server taking traffic
• Is traffic being returned
/config/bigip.conf
• Are iRules being executed and at the appropriate time
We have already seen there are several places to determine the virtual server
state and status, such as the network map. You can also find the status
through the virtual server list or via a tmsh command.
So there are a number ways we might review a virtual server to determine its state and how it is
configured.
• List of virtual servers and be found going to Local Traffic >> Virtual Servers : Virtual Server
List
• Here you can see the status, IP address and Service Port, if it was created by an iAPP the Application
90
type of virtual server.
• Here are the status indicators you may see, defined by shape and color.
• Note: the Disable color (black) will fill what shape the configured item was in at the time it was disabled
• A Gray filled shape indicates a supporting item(s) was disabled.
• This information can also be obtained through tmsh with the “show ltm virtual” command
90
Virtual Server State Status Statistics
91 | ©2019 F5
When identifying virtual server issues, you should first determine if the virtual
server is taking traffic. If your virtual server is not taking traffic, there could be a
routing issue, or the virtual servers IP address and port may be misconfigured.
A virtual server with high CPU may need to be looked at more deeply for
misconfigured iRules, or is SSL traffic is spiking CPU, HTTP compression
being performed CPU.
F5 Agility 2016 91
1.03 Identify misconfigured IP address and/or Port
(tmos)# list ltm virtual ftp_vs

ltm virtual ftp_vs {
destination 10.1.10.100:ftp
ip-protocol tcp
mask 255.255.255.255
pool ftp_pool
profiles {
ftp { }
tcp { }
}
source 0.0.0.0/0
source-address-translation {
pool SNAT249_pool
type snat
}
translate-address enabled
translate-port enabled
vs-index 2
}
92 | ©2019 F5
When checking to ensure IP address and port configuration you should go into
virtual server General Properties or TMSH to view the properties to ensure the
Source Address isn’t blocking your requests and the Destination Address and
Service Port are correct. The virtual server list in the GUI will not show source
port.
92
Virtual Server Response to ICMP
By default a virtual address will respond to ICMP request even

with the virtual server is disabled or offline.
93 | ©2019 F5
A disabled or offline virtual IP address will respond to ICMP packets. This is by

design to allow you to test connectivity to the virtual IP address for
troubleshooting purposes.
93
1.03 Identify conflicting/misconfigured profiles
94 | ©2019 F5
Over the next several slides we will talk about some of the profiles you will want
to have an understanding of and the purpose of profiles in the virtual server
architecture. In general, profiles are used to tell TMOS what traffic to process,
how to view it and allow for the manipulation of that traffic. Profiles are a major
component of virtual servers.
94
Virtual Servers and Profiles
MANUAL : BIG-IP LOCAL TRAFFIC MANAGEMENT: PROFILES REFERENCE
One of the most important configuration components

• Determines what traffic passes
• What traffic can be viewed, manipulated, and validated
• This is done mostly via profiles
Different profile types, different traffic processing

capabilities
• Protocol profiles, such as, TCP and UDP
• SSL profiles, for client-side and server-side certificates
and keys
• Service (L7) profiles, such as, HTTP, FTP, DNS
• And many more…….
95 | ©2019 F5
As we just stated, the virtual server is the most common way to pass traffic
through the BIG-IP, for traffic management, manipulation, steering,
authentication or security, etc. In General Properties you define what IP
address(es) and port(s) the virtual server will listener on and source IP
addresses allowed to access the virtual server (all by default, 0.0.0.0/0). In the
Resources section you will define the pool of servers the virtual server traffic will
flow too. In the case of network virtual servers, which will be discussed later,
you may not define any pool, but let traffic flow as determined by configured
interfaces or routing tables, if configured, on the BIG-IP.
In the Configuration section, you can add profiles tell the virtual server how to
process the packets as the packets flow through the full proxy architecture.
When a profile is attached the TMOS will parse the header and data information
so it can be acted upon by the profile itself or other configuration items, such
as, iRules and policies.
F5 Agility 2016 95
Profile Types
MANUAL : BIG-IP LOCAL TRAFFIC MANAGEMENT: PROFILES REFERENCE (V13.1)
K23843660: BIG-IP LTM-DNS OPERATIONS GUIDE | CHAPTER 5: BIG-IP LTM PROFILES
Profile Type Description

Protocol profiles
Fast L4 Defines the behavior of Layer 4 IP traffic.
Fast HTTP Improves the speed at which a virtual server processes traffic.
TCP Defines the behavior of TCP traffic.
UDP Defines the behavior of UDP traffic.
SSL profiles
Client Defines the behavior of client-side SSL traffic. See also Persistence Profiles.
Server Defines the behavior of server-side SSL traffic. See also Persistence Profiles.
96 | ©2019 F5
The profiles in red are most likely to come up the exam and you should have a
general idea of what they do and how that work. We have already seen how
the TCP profile can be used to define TCP parameters to optimized TCP traffic
on the client and server sides of the proxy. We also discussed how client-side
and server-side SSL profiles can be used to perform SSL offload, make SSL
traffic more secure and allow end-to-end encryption will still giving BIG-IP
administrators the ability to view and manipulation the application flow.
F5 Agility 2016 96
Profile Types Manual : BIG-IP Local Traffic Management: Profiles Reference (v13.1)
Services profiles
HTTP Defines the behavior of HTTP traffic.
FTP Defines the behavior of FTP traffic.
Persistence profiles
Cookie Implements session persistence using HTTP cookies.
Destination Address Affinity Implements session persistence based on the destination IP address specified in the
header of a client request. Also known as sticky persistence.
Hash Implements session persistence in a way similar to universal persistence, except that
the BIG-IP system uses a hash for finding a persistence entry.
Microsoft® Remote Desktop Implements session persistence for Microsoft® Remote Desktop Protocol sessions.
SIP Implements session persistence for connections using Session Initiation Protocol Call-
ID.
Source Address Affinity Implements session persistence based on the source IP address specified in the
header of a client request. Also known as simple persistence.
SSL Implements session persistence for non-terminated SSL sessions, using the session
ID.
Universal Implements session persistence using the BIG-IP system's Universal Inspection
Engine (UIE).
97 | ©2019 F5
We have also talked about persistence profiles. The cookie persistence profile
allows the BIG-IP to create cookies for stateful application (Cookie Insert), this
profile can also rewrite existing work to contain the information or simply use
information in the cookie that was insert by another application. The FTP profile
(https://support.f5.com/csp/article/K13044205) is somewhat unique by allowing
traffic to be received on port 20 (data) in addition to the defined port. Adding
the HTTP profile allows for some inherent HTTP security, by default the number
of HTTP headers is limited to 64 and the number header bytes to 32768, which
eliminate overload as an attack vector. The HTTP profile also enforces RFC
compliancy. And, because TMOS is waiting for all the header information for
parsing PRIOR to making a load balancing decisions, attack vectors like Slow
Loris are thwarted, as the BIG-IP can handle a vast number of simultaneous
connections.
F5 Agility 2016 97
Profile Types Manual : BIG-IP Local Traffic Management: Profiles Reference (v13.1)
Authentication profiles
LDAP Allows the BIG-IP system to authenticate traffic based on authentication data stored on
a remote Lightweight Directory Access Protocol (LDAP) server.
RADIUS Allows the BIG-IP system to authenticate traffic based on authentication data stored on
a remote RADIUS server.
TACACS+ Allows the BIG-IP system to authenticate traffic based on authentication data stored on
a remote TACACS+ server.
SSL Client Certificate LDAP Allows the BIG-IP system to control a client's access to server resources based on data
stored on a remote LDAP server. Client authorization credentials are based on SSL
certificates, as well as defined user groups and roles.
SSL OCSP Allows the BIG-IP system to check on the revocation status of a client certificate using
data stored on a remote Online Certificate Status Protocol (OCSP) server. Client
credentials are based on SSL certificates.
Other profiles
OneConnect Enables client requests to reuse server-side connections. The ability for the BIG-IP
system to reuse server-side connections is known as Connection PoolingTM.
Statistics Provides user-defined statistical counters.
Stream Searches for and replaces strings within a data stream, such as a TCP connection.
98 | ©2019 F5
Other profiles, unlikely to be on the exam.
F5 Agility 2016 98
Working with Profiles
K14488: WORKING WITH PROFILES
Best practice is to not modify default profiles
Always create a custom profile, even if you change nothing
Some profiles conflict with each other

• BIG-IP will notify you of conflicts, most are obvious, for example, UDP/HTTP or FTP/SSL
Some profiles require other profile, for example,

• Using the Stream profile to replace strings in HTTP, would require an HTTP profile
Profiles can have an impact on system resources, for example

• HTTP Compression profiles may impact CPU, if not hardware accelerated
• Web Acceleration profiles will impact memory usage, since content is stored in RAM
Layer 7 profiles (HTTP, FTP, SMTP, etc) dig deeper into transaction and consume memory and CPU
99 | ©2019 F5
Here are a few more things to think about when dealing with profiles. Some
profiles conflict with each other. Most conflicts are obvious. For example, the
UDP profile and HTTP profile will not work together as HTTP is a connection-
oriented protocol. The LTM will let you know when profiles on a virtual server
conflict or if you are missing a profile that you need.
Each virtual server will have at least a protocol profile. The most virtual servers
will have several profiles attached to them.
Each custom profile must have a unique name and custom profiles are stored in
/config/bigip.conf. This is the same file where your pools, virtual servers, iRules
and other configuration items are stored.
Profiles tell the BIG-IP to dig in the packet based on the profile parameters. For
example, HTTP profile tells a virtual server to dig into HTTP header information.
Just because your virtual server is supporting a web application it does not
mean you have to have an HTTP profile on the virtual server. If you do not
need to dive into the HTTP header to look for a cookie, or change header
information, or watch for a particular HTTP response, or perform some other
similar function, you may not want the virtual server to perform the additional
overhead of looking into the HTTP header.
99
Profile Type Prerequisite Incompatible Profiles
Profiles
Protocol profiles
Fast L4 None All
Profile Combinations Fast HTTP
TCP
None
None
All
UDP, Fast L4, Fast L7
UDP None TCP, Fast L4, Fast L7
Services profiles
HTTP TCP FTP
FTP TCP HTTP, CLient SSL or Server SSL
Some profiles conflict with each other SSL profiles
Client SSL TCP FTP
• BIG-IP will notify you of conflicts, most are Server SSL TCP FTP
obvious, for example, UDP/HTTP or Persistence profiles
Cookie HTTP N/A
FTP/SSL
Destination Address Affinity Any None
Hash Fast L4, TCP, UDP N/A
Some profiles require other profile, for MSRDP TCP N/A
SIP TCP or UDP FTP
example, Source Address Affinity Any None
SSL TCP FTP
• Using the Stream profile to replace strings Universal None N/A
in HTTP, would require the HTTP profile Authentication profiles
LDAP TCP N/A
RADIUS TCP N/A
TACACS+ TCP N/A
SSL Client Certificate LDAP TCP N/A
OCSP TCP N/A
Other profiles
OneConnect TCP N/A
100 | ©2019 F5
Statistics TCP N/A
Stream TCP Fast L4, UDP
You should understand that what profiles are required for other profiles to be
applied, and what profiles are incompatible with other profiles. Most of this is
common sense, for example UDP and HTTP are incompatible, because HTTP
runs on top of TCP and normally the BIG-IP itself would not allow you to do it,
but for testing purposes you may need to think this through.
F5 Agility 2016 100

Misconfigured/Missing Profiles
Common mistakes/Things to think about:
• The Protocol profile limits traffic to that protocol

− i.e. Using the TCP profile, you can not ping through a virtual
• If looking into L4, L7, (ie HTTP), the appropriate

protocol profile is needed
• SSL Profile requirements
− HTTPS virtual, HTTPS pool members, where no HTTP profile is
required, does NOT have to have SSL profiles, basically L4
− SSL Offload, virtual HTTP, pool members HTTP will require a SSL
Profile (Client)
− HTTPS virtual, HTTPS pool members, where you need to look into
the HTTP header (ie. Cookie persistence) and/or data require
BOTH an SSL Profile (Client) and an SSL Profile (Server)
101 | ©2019 F5
• First, check the status of the virtual, is it configured with the right IP address
and port
/config/bigip.conf
• Look for what profile maybe needed or may by missing to accomplish what needs to
be done
• Then look at the profiles that are being used for misconfiguration or defaults that are
incompatible with your application.
• Example 1: The application requires 70 HTTP headers for all the information, in
this case the default HTTP profile limit of 64 must be changed
• Example 2: In Response Headers Allowed you have decide to only allow certain
response headers required by the browser and eliminate HTTP headers about the
server to keep attack vector information from being exposed, did you send back
on the headers required by browser.
101
2.02 R
Identify the different virtual server types
• Standard, Forwarding, Stateless, Reject
• Performance (Layer 4) and Performance (HTTP)
102 | ©2019 F5
You are not required to know how to configure each type of these virtual
servers, but you do need a general understand of what each on does and their
use.
102
Virtual Server Types
Virtual server type Description of virtual server type
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) A Forwarding (Layer 2) virtual server typically shares the same IP address as a node in an associated Virtual Local Area
Network (VLAN). You use a Forwarding (Layer 2) virtual server in conjunction with a VLAN group.
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 A Performance (Layer 4) virtual server has a FastL4 profile associated with it. A Performance (Layer 4) virtual
4) server increases the speed at which the virtual server processes packets.
Performance (HTTP) A Performance (HTTP) virtual server has a FastHTTP 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 improves the performance of User Datagram Protocol (UDP) traffic in specific
scenarios.
Reject A Reject virtual server rejects any traffic destined for the virtual server IP address.
DHCP Relay A Dynamic Host Configuration Protocol (DHCP) relay virtual server relays 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. (BIG-IP 11.1.0
and later)
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. (BIG-IP 11.3.0 and later)
Message Routing A Message Routing virtual server uses a Session Initiation Protocol (SIP) application protocol and functions in accordance
103 | ©2019 F5
with a SIP session profile and SIP router profile. (BIG-IP 11.6.0)
The conversation about virtual servers to this point has been primarily around
standard virtual servers. You will need a solid understanding of how standard
virtual servers work and how to configured and troubleshoot them to pass the
201 exam. You will just need a general understanding for the virtual server
types in blue. We will go into more detail around these virtual servers in the
upcoming slides.
103
Standard Virtual Server
MANUAL CHAPTER : ABOUT VIRTUAL SERVERS
A Standard virtual server
• also known as a load balancing virtual server

• directs client traffic to a load balancing pool
• is the most basic (common) type of virtual server.
104 | ©2019 F5
104
Standard Virtual Server with TCP Profile
• Use the TMOS full proxy architecture
• By default translate the destination VS address and port to the pool member address and port
105 | ©2019 F5
Standard virtual servers are by far the most common virtual server type. In a
standard virtual server the BIG-IP establishes client (outside) connection (SYN,
SYN-ACK, ACK), uses the load balancing method to determine the pool
member that will receive the client request, establishes a server (inside)
connection (SYN, SYN-ACK, ACK) to that pool member selected and only then
begins to send information.
F5 Agility 2016 105

Standard Virtual Server with Layer 7 functionality
• Client must send at least one packet before server-side connection is initiated
− The BIG-IP LTM may initiate the server-side connection prior to the first data packet for certain Layer 7 applications, such as FTP
106 | ©2019 F5
A standard virtual server is a L7 profile behaves much like the L4 standard virtual server we just
talked about with the exception of waiting for all the request headers before making a load
balancing decision and establish a server-side connection.
The BIG-IP LTM may initiate the server-side connection prior to the first data packet for certain
Layer 7 applications, such as FTP, in which the user waits for a greeting banner before sending
any data
106
Forwarding (IP) Virtual Server
Forwarding (IP) virtual server
• has no pool members to load balance.

• forwards a packet directly to the configured destination
IP address, based on what's defined on the BIG-IP or
the system's routing table.
• The destination address can be either a node address
or a network address.
• address translation is disabled.
• An example of a Forwarding (IP) virtual server is one
that accepts all traffic on an external VLAN and
forwards it to the virtual server destination IP address.
107 | ©2019 F5
The forwarding virtual server is design to simply forward packets and is usually used to
forwarding or translating networks.
The default protocol is TCP. What would happen if you left this virtual traffic at the default
protocol as you sent traffic to the 10.1.20.0/24 network? (only TCP request would get through,
you could not ping or TFTP)
What might have to be done external of the BIG-IP to get this to work? (You would have to a
route for 10.1.20.0/24 back to the BIG-IP for the virtual server to receive and process traffic)
107
Example: Web administrators required SSH,
Forwarding Virtual Server Webmin, HTTP and HTTPS, ICMP access to
individual backend Apache servers.
Web Admin
3.3.3.3
route ADD 1.1.1.0 MASK 255.255.255.0 2.2.2.254
Request
DST: 1.1.1.8:22 HTTP response
SRC: 3.3.3.3 DST: 3.3.3.3
SRC: 1.1.1.8:22
VLAN DMZ Virtual Servers

Name: forwarding_vs
IP 2.2.2.254 Dest 2.2.2.5:80 Src 0.0.0.0/0
Source Address: 3.3.3.0/24
Dest 2.2.2.5:443 Src 0.0.0.0/0
Destination Address/Mask: 1.1.1.0/24 VLAN Internal
IP 1.1.1.254 Dest 2.2.2.8:21 Src 0.0.0.0/0
Service Port: *
Protocol: *
Request Response
DST: 1.1.1.8:22 DST: 3.3.3.3
SRC: 3.3.3.3 SRC: 1.1.1.8:22
RED BLUE
108 | ©2019 F5
1.1.1.8 1.1.1.9
GW 1.1.1.254 GW 1.1.1.254
Let’s look at an example of why a forwarding virtual server might be useful. In

this scenario, the web servers behind the BIG-IP are using routed mode. Their
default gateway points to an IP address on the BIG-IP. The web administrators
need to get to multiple applications, SSH (22), FTP 21, Webmin (10000) on the
backend server for maintenance and testing. Pools won’t work because they
may need to get to a specific server. You could build multiple forward virtual
servers restricted to specific ports, but maintenance would be troublesome and
the administrators may need an unknown port. Because of these factors, you
decide to build a forwarding virtual server will translate the first 3 octets up the
IP address for the subnet of the backend servers but will not translate the last
octet. This will allow the administrator to pick the server he wishes. You create
a wildcard port, so the port request is not translated. You restrict access to the
virtual server to the source subnet of the administrators. And, you allow all
protocols to pass through the virtual server. (Question: What would happed if
you were to put a TCP protocol profile on the virtual server and then try to ping
it or TFTP to it?)
108
Performance Layer 4
A Performance (Layer 4) virtual
• Is associate a Fast L4 profile.

• Together, the virtual server and profile increase the
speed at which the virtual server processes Layer 4
requests.
109 | ©2019 F5
Notice that your selections are greatly reduced.
109
Performance Layer 4
Performs a packet load balancing, packet-by-packet TCP behavior
Accelerated packet processing with only socket layer decisions are required
On platforms with a PVA ASIC chip, processing is done via the ASIC
Some limitations are:

• No HTTP optimizations
• No TCP optimizations for server offloading
• SNAT/SNAT pools
• Demote PVA acceleration
• Rules limited to L4 events
• No OneConnect
• Limited persistence options:
− Source address
− Destination address
− Universal
No compression
No Virtual Server Authentication
No support for HTTP pipelining

110 | ©2019 F5
110
110
Performance HTTP
A Performance (HTTP) virtual server is a virtual server with which you

associate a Fast HTTP profile. Together, the virtual server and profile
increase the speed at which the virtual server processes HTTP requests.
111 | ©2019 F5
111
Performance HTTP Virtual Server
Recommended when it is not necessary to maintain source IP addresses
Some limitations
• Requires SNAT
• Limited iRule support
• No compression
• No authentication
• No TCP optimization
• No HTTP pipelining
112 | ©2019 F5
112
112
Stateless Virtual Server
A Stateless virtual server
• Prevents the BIG-IP system from putting connections

into the connection table for wildcard and forwarding
destination IP addresses.
• You cannot configure
− SNAT automap
− iRules
− port translation
• You must configure a default load balancing pool.

• Applies to UDP traffic only.
113 | ©2019 F5
113
Reject Virtual Server
A Reject virtual server
• Specifies that the BIG-IP system rejects any traffic

destined for the virtual server IP address.
114 | ©2019 F5
114
Topic Resources
• MANUAL CHAPTER: VIRTUAL SERVERS
• Manual Chapter : Session Persistence Profiles
• K14783: Overview of the Client SSL profile (11.x - 16.x)
• K14806: Overview of the Server SSL profile (11.x - 16.x)
• Manual : BIG-IP Local Traffic Management: Profiles Reference (V13.1)
• K23843660: BIG-IP LTM-DNS operations guide | Chapter 5: BIG-IP LTM profiles
• K14488: Working with profiles
• Manual Chapter : About Virtual Servers
• 13044205: Overview of the FTP profile (12.x - 13.x)
115 | ©2019 F5
115
Pools
Objectives 4.02, 1.04, 2.04
116 | ©2019 F5
116
4.02
Apply procedural concepts required to modify and manage pools
• Determine configured health monitor
• Determine the load balancing method for a pool
• Determine pool member service port configuration
• Determine the active nodes in a priority group configuration
• Apply appropriate health monitor
• Apply load balancing method for a pool
• Apply pool member service port configuration

117 | ©2019 F5
117
4.02 Determine configured health monitor
MANUAL : BIG-IP LOCAL TRAFFIC MANAGER: MONITORS REFERENCE
(tmos)# list ltm pool www_pool
ltm pool www_pool {
members {
10.1.20.11:http {
address 10.1.20.11
session monitor-enabled
state up
}
10.1.20.12:http {
address 10.1.20.12
state up
}
10.1.20.13:http {
address 10.1.20.13
state up
}
}
monitor http
}
118 | ©2019 F5
Health monitors are used to determine the status of a node or pool member.
Knowing the monitor and its configuration is an important troubleshooting tool in
determine the pool member viability and status. You can find the monitors used
by a particular pool via the TMUI and TMSH. Once you know the monitor(s)
being used you can view the monitor configuration by going to Local Traffic >>
Monitor and open the monitor profile being used.
118
4.02 Determine the load balancing method for a pool
MANUAL CHAPTER : ABOUT POOLS
ltm pool www_pool {
load-balancing-mode least-connections-member
members {
10.1.20.11:http {
address 10.1.20.11
priority-group 5
state up
}
10.1.20.12:http {
address 10.1.20.12
priority-group 5
state up
}
10.1.20.13:http {
address 10.1.20.13
state up
}
}
monitor http
119 | ©2019 F5 }
Under the Members section of pools in the TMUI you can determine the load
balancing method you can also find the load balancing method with the list
command in TMSH. We will point this out a couple of times, but only
configuration is used. In other words, if Ratios are configured on pool
members, but you haven’t selected the Ratio load balancing method the ratio
configurations on the members are ignored. The same is true for Priority
Group.
119
4.02 Determine the active nodes in a priority group configuration
120 | ©2019 F5
We will cover Priority Groups in more detail in the next section, but you have a
thorough understanding of how Priority Groups and Priority Group activation
works.
Remember the priority of a pool member pool member is meaningless Priority
Group Activation is disabled (not configured).
120
4.02 Determine pool member service port configuration
ltm pool www_pool {
members {
10.1.20.11:http {
address 10.1.20.11
state up
}
10.1.20.12:http {
address 10.1.20.12
state up
}
10.1.20.13:http {
address 10.1.20.13
state up
}
}
monitor http
}
121 | ©2019 F5
The service port of the application can also be found in the Members section.
Remember the BIG-IP proxy architect translates the port as well as the IP
address. Because of that pool members aren’t required to be in the same
subnet or have matching ports. As long as the BIG-IP can route to the pool
member it can be anywhere.
121
4.02 Apply appropriate health monitor
MODIFY LTM POOL WWW_POOL LOAD-BALANCING-MODE ROUND-ROBIN MEMBERS ADD { 10.1.20.14:80 } MONITOR TCP AND HTTP
(tmos) # modify ltm pool www_pool monitor tcp and http
122 | ©2019 F5
Custom monitors will need to be configured before they can be added to a pool
or pool member (individual pool members can have like and different monitors
as required). Monitors are assigned under the Properties tab of the pool.
Multiple monitors can be assigned to a pool and by default all monitor must be
healthy for a pool member to be considered Available (green), but that can be
modified in the Advanced menu.
122
4.02 Apply pool member service port configuration
MODIFY LTM POOL WWW_POOL LOAD-BALANCING-MODE ROUND-ROBIN MEMBERS ADD { 10.1.20.14:80
(tmos) # modify ltm pool www_pool members add { 10.1.20.14:80 }
• add, delete, modify, none, replace-all-with
123 | ©2019 F5
Pool members can be added, deleted or modified via the TMUI or using TMSH.
Here are can define the IP address:port combination used to access the
application. You can also define/modify ratios, priority group and connection
limits.
123
4.02 Apply load balancing method for a pool
MODIFY LTM POOL WWW_POOL LOAD-BALANCING-MODE ROUND-ROBIN MEMBERS ADD { 10.1.20.14:80
(tmos) # modify ltm pool www_pool load-balancing-mode ratio
124 | ©2019 F5
If the load balancing method was changed to Ratio what would different?
Answer: Nothing, since all members have the same ratio load balancing is still
effectively round robin.
124
Load Balancing methods
K6406: OVERVIEW OF LEAST CONNECTIONS, FASTEST, OBSERVED, AND PREDICTIVE POOL MEMBER LOAD BALANCING
A load balancing method is an algorithm used to determine which pool member to send traffic to
• Load balancing is connection based
Static load balancing methods distribute connections in a fixed manner

• Round Robin (RR)
• Ratio (Weighted Round Robin)
− Distributes in a RR fashion for members/nodes whose ratio has not been met
Dynamic load balancing look at one or more factors, the most common method is:
• Least Connections
− Fewest L4 connections when load balancing decision is being made
− Recommended when servers have similar capabilities
− Very commonly used
125 | ©2019 F5
Load balancing methods are the algorithms or formulas used to distribute load
across the members in a pool. All load balancing is connection oriented. Each
new connection created is load balanced based on the method used. For
example, if there are three members in an HTTP pool and the load balancing
method is Round Robin and 30 connections are required to create the web
page, each member would get 10 connections. The exception to this is
persistence. If a persistence profile is assigned to a virtual server and a
persistence record already exists, the load balancing decision is bypassed, and
the new connection goes to the pool member in the persistence record.
The two primary static load balancing methods are Round Robin and Ration.
Round Robin is the default load balancing method for new pools. The most
common dynamic method Least Connections. Least Connections sends the
next new connection to the pool member with the fewest connections in the
pool, know as, Least Connections (Member) or the member whose node IP
address had with the few total connections across all the pools the node is a
member of.
Let’s look at that a little more deeply on the next couple of slides.
125
Load Balancing a Service (Member)
In this example, the HTTP pool is
Internet configured with the Least
Connections (member) method
18.200.150.10
10.2.2.100:80 BIG-IP LTM directs the

With each new client request to the pool member
request, BIG-IP LTM with the least number of
verifies which pool connections
member within the pool
has the fewest active
Current connection
connections
counts for each pool
member are
displayed in red
172.20.10.1 172.20.10.2 172.20.10.3

http_pool 172.20.10.1:80 45 172.20.10.2:80 42 172.20.10.3:8080 36
126 | ©2019 F5
secure_pool 172.20.10.2:443 12 172.20.10.3:443 22
When selecting a load balancing method, for most methods, you will see either
member or node following the method type. When you select a method where
“member” follows the load balancing method only the statistics of the targeted
pool are take into consideration. When you select a method where node
follows the selected method then the LTM considers all the pools in which the
node has membership.
First, let’s look at an example of load balancing based on member information.
In this example we have nodes that are members of two pools. We have
assigned the http_pool least connections by member. In this case the client
makes a request of the virtual server. When the LTM goes to load balance the
request it is only concerned with the number of connections to each member in
the http_pool. So in this case it selects 172.20.10.3:8080.
126
Load Balancing an IP Address (Node)
Internet In this example, the HTTP
pool is configured with the
18.200.150.10 Least Connections (node)
method
With each new client

10.2.2.100:80 request, BIG-IP LTM verifies
which node has the fewest
BIG-IP LTM directs the active connections
request to the node with the
least number of connections
This takes into account
all services running on
the node
Current connection
counts for each pool a
45 54 58 node is a member of
are displayed in red
172.20.10.1 172.20.10.2 172.20.10.3
http_pool 172.20.10.1:80 45 172.20.10.2:80 42 172.20.10.3:8080 36
127 | ©2019 F5
secure_pool 172.20.10.2:443 12 172.20.10.3:443 22
Now let’s see what would have happen had we selected least connects with the
“node” option.
Now when a client makes a request of the HTTP virtual server, the LTM looks at
the total number of connections across all the pools that the nodes are a
member of. Even though 172.20.10.3 still has fewer connections in the
http_pool, it has more connections across all the pools it is a member of. So in
this case the next connection is sent to 172.20.10.1 which has the fewest
overall connections.
If you are unsure of which option to use, it would be best to go with “node”. If
the node only sevices one pool it is essentially the same as “member” and if it is
the member of multiple pools you are likely to be concern with overall usage.
127
1.04
Identify the reason a pool is not working as expected
• Identify the current configured state of the pool/pool member
• Identify the current availability status of the pool/pool member
• Identify the reason a pool member has been marked down by health monitors
• Identify a pool member not in the active priority group
128 | ©2019 F5
128
1.04 Identify the current configured state/status of the pool/pool member
129 | ©2019 F5
A quick look at the Module Statistics page yields a log of information beyond
statuses.
129
(tmos)# show ltm pool purple_pool members
1.04 Identify the current configured ---------------------------------------------

Ltm::Pool: purple_pool
state/status of the pool/pool member ---------------------------------------------
Status
MANUAL CHAPTER : ABOUT POOLS Availability : offline
State : enabled
Reason : The children pool member(s) are down
Monitor : http_200OK
Minimum Active Members : 0
Current Active Members : 0
Available Members : 0
Total Members : 1
Total Requests : 0
Current Sessions : 0
<cut>
-------------------------------------------
| Ltm::Pool Member: 10.1.20.14:80
-------------------------------------------
| Status
| Availability : offline
| State : disabled-by-parent
| Reason : http_200OK: No successful
responses received before deadline. @2020/07/29 07:44:53.
| Monitor : http_200OK (pool monitor)
| Monitor Status : down
| Session Status : addr-disabled
| Pool Name : purple_pool
| IP Address : 10.1.20.14
130 | ©2019 F5
Here you can see the pool member if Offline because the monitor failed and is
Disabled, because the Node (parent object) is disabled. Because 10.1.20.14 is
the only pool member the pool status is also offline. What was the status of the
pool member with the node was disabled?
130
1.04 Identify the current configured state/status of the pool/pool member
MULTIPLE MONITORS ASSIGNED TO A POOL OR POOL MEMBER
Multiple monitors can be assigned to a pool or a pool

member or a node
• By default all monitors must up for the pool member or
node to be marked Available
• The number of monitors required for the pool member
or node to be up is configurable
131 | ©2019 F5
131
1.04 Identify the reason a pool member has been marked down by
health monitors
There are numerous reason a pool member may

be marked down.
• Misconfigured monitor
• Wrong monitor
• Wrong port
• Bad network path to servers
IMPORTANT: Monitors are sourced from the base

self IP on the outbound VLAN the BIG-IP uses to
send traffic to the pool member being monitored.
132 | ©2019 F5
132
1.04 Identify a pool member not in the active priority group
PRIORITY GROUP ACTIVATION
Priority Group Activation load balancing
• Allows pool members to be used

only if preferred pool members are
unavailable.
• Each pool member is assigned a
priority
• Connections are sent to the highest
priority pool members first.
• A minimum number of available
members are assigned
133 | ©2019 F5
In the graphic note the priority of the pool members. 5 is the highest priority
group. Note the Priority Group Activation number and Available Members. If
there a less than 2 members in the higher priory group, then the next highest
priority group is activated. In this scenario the priority 5 pool members would
take all traffic until one of them failed or had met their connection limit. At that
point 10.1.20.13:80 would be activated and the BIG-IP would load balance
connections to it.
133
1.04 Identify a pool member not in the active priority group
PRIORITY GROUP ACTIVATION
Priority Group Activation is a failure mechanism
• Can dynamically pull in new members into the pool

• Pulls lower priority groups into higher priority groups
• Pulls in all members of a priority group together
Server Pools
Running WWW1 and WWW2
Activation < 4
PG PG PG PG PG PG PG PG PG PG
100 100 100 100 100 90 80 70 25 1
A A A A A A A
web1_pool Servers web2_pool Servers
134 | ©2019 F5
Ot
134
More Priority Group Examples
pool my_pool_1 { pool my_pool_2 { pool my_pool_3 {

lb_mode fastest lb_mode fastest lb_mode fastest
min active members 2 min active members 3 min active members 4
member 10.12.10.7:80 priority 3 member 10.12.10.7:80 priority 3 member 10.12.10.7:80 priority 3
} } }
135 | ©2019 F5
The struck through members are offline.

On the left, in my_pool_1 which members are active? 7,8,4,5,6
In the middle, which pool members are active in my_pool_2? 7,6,1,3,3
On the right, which pools members are active in my_pool_3? 4,5,6,7,8,9
135
2.03 Identify when a packet capture is needed within the context of a
performance issue
K411: OVERVIEW OF PACKET TRACING WITH THE TCPDUMP UTILITY
• Tcpdump command
reference (partial)
&& || ! Alternate notations

136 | ©2019 F5
TCPDump is an invaluable tool in troubleshooting on the BIG-IP. But you

should always be aware of potential dangers in running TCPDumps, especially
poorly formed dumps which could chew up valuable resources, such as, CPU
and disk space. You should have a thorough understanding of how and when
to use TCPDumps. In a few slides we will show you where you can find some
valuable training on LearnF5.com.
F5 Agility 2016 136

performance issue
K411: OVERVIEW OF PACKET TRACING WITH THE TCPDUMP UTILITY
• BIG-IP is a full proxy. Two tcpdumps (one on each side of the proxy) are often needed.
• Can by done be open two SSH sessions, or running the dumps in background (&)
• When a tcpdump is required, always make it as specific a possible
• Limit it to the appropriate interfaces/VLANs and hosts/ports
system# tcpdump –i external –eXs 0 host 10.10.10.10 and port 80
system# tcpdump –i (1.1, f5_trunk1, external, 0.0) –eXs 0 –w /var/tmp/dump.cap &

system# tcpdump –i (1.1, f5_trunk1, internal, 0.0) –eXs 0 –w /var/tmp/dump2.cap &
system# fg
ctl+c
system# fg
ctl+c
137 | ©2019 F5
See more at: https://support.f5.com/kb/en-

us/solutions/public/4000/700/sol4714.html?sr=55000463
F5 Agility 2016 137

performance issue
138 | ©2019 F5
In addition to being able to craft a TCPDump, you should also be able to

interpret the findings.
Overview of TCPDUMP
http://support.f5.com/kb/en-
us/solutions/public/0000/400/sol411.html?sr=40074425
138
Troubleshooting tools - TCPDUMP
LEARN F5 F5 LEARNING SITE FOR F5 ENGINEERS, PARTNERS AND CUSTOMERS
K411: Overview of packet tracing with the tcpdump utility

• K6546: Recommended methods and limitations for
running tcpdump on a BIG-IP system
• K4714: Performing a packet trace and providing the
results to F5 Support
139 | ©2019 F5
139
Troubleshooting Tools
Curl Utility - http://curl.haxx.se/ curl http://www.mysitename.com
• curl is a command line tool for curl http://10.128.20.11
transferring data with URL syntax, [root@bigip249] config # curl -i 10.128.20.11
supporting DICT, FILE, FTP, FTPS, HTTP/1.1 200 OK
Gopher, HTTP, HTTPS, IMAP, IMAPS, Date: Wed, 06 Aug 2014 20:05:13 GMT
LDAP, LDAPS, POP3, POP3S, RTMP, Server: Apache/2.2.22 (Ubuntu)
RTSP, SCP, SFTP, SMTP, SMTPS, X-Powered-By: PHP/5.4.9-4ubuntu2.2
Telnet and TFTP. Vary: Accept-Encoding
Content-Length: 3819
• It is support on BIG-IP and is great for Connection: close
troubleshooting connectivity and Content-Type: text/html
monitors
<html>
<head>
<TITLE>Using virtual server 10.128.20.11 and pool member 10.128.20.11 (Node
#1)</TITLE>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii" />
<script language="javascript">
…………………
</script>
140 | ©2019 F5
You should also be familiar with the basics of the curl command, mainly around
the HTTP protocol, before taking the exam.
140
Topic Resources
• https://example.link.com
141 | ©2019 F5
141
2.04
Identify the reason load balancing is not working as expected
• Identify current availability status
• Identify misconfigurations (incorrect health checks, action on service down,

etc.)
• Consider persistence, priority group activation, rate/connection limits
142 | ©2019 F5
142
2.04 Identify current availability status (look familiar?)
143 | ©2019 F5
143
2.04 Identify misconfigurations incorrect health checks
Is the monitor appropriate
TCP,HTTP monitor on Node object
TCP,ICMP monitor on HTTP object
Are you testing for the right thing
Tools – curl, ping

There are numerous reason a pool member
may be marked down.
Misconfigured monitor
Wrong monitor
Wrong port
Bad network path to servers
144 | ©2019 F5
We talked about a bit earlier. You will be required to determine is a health

check is inappropriately configured or misconfigured or the wrong monitor for
the task. For instance, TCP monitor checking port 80 (HTTP) shows the
application being available on the all pool members, but users are complaining
about content not coming back or getting intermittent 404 errors for the same
content. On further inspection you find will port 80 is responding on a pool
member the application behind port 80 is down or content is missing. In this
case an HTTP monitor asking for specific content and a check of the content
may be a more appropriate monitor.
144
2.04 Action on Service Down
Action on Service Down
• None – RST after idle timeout reached (Default)

• Reject – sent RST to active connections
• Drop – silently remove the connection
• Reselect – move connection to alternate pool member
Slow Ramp Time
• Set less traffic to newly established pool member
145 | ©2019 F5
By default if a pool member goes down the connections between the server and
the BIG-IP are reaped (disconnect and clear from the connection table), while
the connections between the BIG-IP and the client are left up until the idle
timeout expires. For most HTTP applications this is perfectly acceptable. For
some application though the client will try to maintain the session the user won’t
realize they have been disconnected. BIG-IP gives the administrator the option
to modify this behavior. The BIG-IP can attempt to re-loadbalance the
connection, simply drop the client-side connection, or in the case of
client/server applications send a TCP RST back to the client, so the client
knows to attempt to re-establish a connection to the server.
F5 Agility 2016 145

2.04 Consider persistence, priority group activation,
rate/connection limits
REVIEW
Persistence
• Check records
• Object state
• Understand the difference in behavior of
− Pools and Nodes which are Disabled or force Offline
− Persistence Override Connection limits
146 | ©2019 F5
146
12/8/2020
Enabling/Disabling Nodes and Pool Members

STATE DETERMINES ARE PERSISTENCE AND CONNECTIONS ARE HANDLE
Pool Member State Interaction with Pool Member

Enabled Existing Connection – Maintained
All Traffic Allowed New Persistence Records – Can be Created
New Connections – Can be Created
Disabled (Members or Nodes) Existing Connection – Maintained
Only persistent or active connections allowed. New Persistence Records – Not Created
New Connections – Can be Created only for
Client with an Existing Persistence record
Forced Offline (Members or Nodes) Existing Connection – Maintained
Only active connections allowed. New Persistence Records – Not Created
New Connections – Not Created
147 | ©2019 F5
And while we are on the topic of persistence, let’s look at a couple of other
statuses and how persistence affects connectivity to pool members.
If a pool member or node is Enabled and Available all the normal functions take
place, new connections can be sent to the server, existing connections are
maintained and, if persistence is configured, persistence records can be
created to redirect a client back to the server.
If the server administrator needs to take the node or member out of a pool, for
reasons of maintenance, upgrade or whatever, the are several options.
The administrator and simply turn the server off and terminate all connections
immediately, not very nice to the clients, but very efficient. F5 prefers a more
subtle approach.
If the administrator set a node or pool member to Disabled, all existing

connections are maintained, new connections can only be created if a
persistence record indicated a client must get back to that server. Therefore a
administrator and watch the persistence records and connections drain away
and know exactly when it is safe to take server out of the pool.
Forced Offline is a little more aggressive. In this state, existing connections are
maintained, but no new connections will be established, regardless of whether
or not there is a persistence record.
147
When an configuration item is Disabled, is status shape turns black and the
status shapes of any supported configuration items turn gray. For example, if
you disable a node, all the pool members it supports turn gray and can only be
brought back on line by re-enabling the node.
147
Review
Is there something wrong with this
pool?
If all members are up why aren’t all

members taking traffic?
If node1 fails, which members will

take traffic?
If all members are up, but you see

traffic statistics on node3 and node4
what does that tell you?
148 | ©2019 F5
Is there something wrong with the pool? If all the members are available why
are only two members taking traffic? Answer: Priority Groups
If node1 go offline or is disabled, which member will take traffic? Answer: The
next priority group will fulfill the requirement of at two active members, so
node1, node2, node3
If all members are up, but you see traffic statistics on any member not active,
that means the other at some point members failed and priority groups were
activated.
148
Given the configuration what
pool member will take the most
connection?
Given the configuration which

pool members will process
traffic?
149 | ©2019 F5
Given the configuration what pool member will take the most connection?
- Connections will be evenly distributed via Round Robin loadbalancing. Ratio
and Priority Group configurations are meaningless.
Given the configuration which pool members will process traffic?

- All members in the pool because Priority Group Activation is set to less than
3, and Priority Group 10 only has 2 members, the next priority group (5) will
always be activated.
149
You have disabled
10.1.20.11:80, but the pool
member continues to receive
new connections. What does
this tell you?
Given the configuration what

pool member will take the most
connection?
150 | ©2019 F5
You have disabled 10.1.20.11:80, but the pool member continues to receive
new connections. What does this tell you?
- That persistence is probably enabled on the virtual server. If a persistence
record exist, new connections can be created on disabled configuration
objects.
Given the configuration what pool member will take the most connection?
- 10.1.20.12:80 will take all traffic, 10.1.20.11:80 has a higher Ratio but it
disabled and Priority Group Activation has not taken effect.
150
Lab 2 – Virtual Server and Pools Status and Behavior
Virtual Server Status
Pool Member and Virtual Servers
Load Balancing
151 | ©2019 F5
151
System Configuration
Objectives 3.01, 3.02, 3.04 - 3.09, 5.02
152 | ©2019 F5
152
3.01
Identify and report current device status
• Interpret the LCD panel warning messages
• Use the dashboard to gauge the current running status of the system
• Review the Network Map in order to determine the status of objects
• Interpret current systems status via GUI or TMSH
• Interpret high availability and device trust status
153 | ©2019 F5
153
3.01 Interpret the LCD panel warning messages
K15521451: BIG-IP TMOS OPERATIONS GUIDE | CHAPTER 12: LOG FILES AND ALERTS
/etc/alertd/alert.conf – contains the LCD error message
LCD Warning: Critical: 9d Blocking Dos Attack
Local Traffic Log: sweeper_update: aggressive

mode activated. 372313/438016 pages
https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/platform-b5000/2.html?sr=54998935
154 | ©2019 F5
LCD warnings are no different from what see in the log files. For example in the
message above you can see the BIG-IP is currently blocking a Dos attack.
You will see a sweeper_update message in the /var/log/ltm log file indicating the
BIG-IP is currently reaping the oldest idle connections from the connection table
in an attempt to free up memory and keep itself functional.
For more information about the LCD follow this link

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/platform-
b5000/2.html?sr=54998935. All the LCDs on various platforms work pretty
much the same.
154
3.01 Use the dashboard to gauge the current running status of the system
155 | ©2019 F5
The function of the dashboard is pretty obvious. Is memory usage high, is

memory usage and open connections high (this could be usage or attack
information), is CPU utilizations (malformed iRules, SSL TPS not in hardware,
software compression), is a particular vCPU running hot. How many SSL
transaction per second (TPS) are being created and are you exceeding
licensing limits.
155
3.01 Review the Network Map in order to determine the status of objects
REVIEW
156 | ©2019 F5
Why is 10.1.20.11:21 in the ftp_pool sporting a fancy new yellow triangle?

Why is the hackazon-redirect virtual server show a blue square and is that
cause for alarm?
What is the state of 10.1.20.12:80 in the www_pool?
156
3.01 Interpret current systems Sys::System CPU Information
-------------------------------------------------------------------
status via GUI or TMSH System CPU Usage(%) Current Average Max(since 08/04/20 12:04:30)
-------------------------------------------------------------------
Utilization 1 2 40
---------------------------------------------------------------
Sys::Host CPUs
---------------------------------------------------------------
(tmos) # show sys cpu Host: 0
CPU: 0 (clock ticks) Last 5 sec Last 1 min Last 5 min Total
- (avg/sec) (avg/sec) (avg/sec) -
User 1 2 3 70.2K
Niced 0 0 0 2.7K
System 0 0 1 24.2K
Idle 94 93 92 3.2M
Irq 0 0 0 0
Softirq 0 0 0 4.3K
Iowait 0 0 0 1.0K
Stolen 0 0 0 0
Util% (last 5 sec) - - - 2
CPU: 1 (clock ticks) Last 5 sec Last 1 min Last 5 min Total
- (avg/sec) (avg/sec) (avg/sec) -
User 0 1 2 59.0K
Niced 0 0 0 2.4K
System 0 0 1 18.7K
Idle 93 93 92 3.2M
Irq 0 0 0 0
Softirq 0 0 0 1.5K
Iowait 0 0 0 1.3K
Stolen 0 0 0 0
157 | ©2019 F5
Util% (last 5 sec) - - - 0
You should be able to pull and interpret the same information from the TMSH
command line.
157
3.01 Interpret high availability and device trust status
MANUAL : BIG-IP DEVICE SERVICE CLUSTERING: ADMINISTRATION
To create secure communications

between BIG-IPs in a HA configuration
(Device Service Cluster – DSC) they are
place into a Device Trust Group:
• BIG-IP exchanges device certificates

• If a certificate expires the trust is broken
• The device_trust_group must be in
sync for configsync, mirroring and
network failover to be available.
More on HA later…
158 | ©2019 F5
We will talk more about high availability later, but device trust groups are design
group BIG-IPs together and allow them to exchange device certificates to
establish secure communications and share the IP addresses they will listen on
for configuration changes, network polling for device status and exchange
mirroring information.
158
3.03
Identify management connectivity configurations
• Identify the configured management-IP address
• Show remote connectivity to the BIG-IP Management interface
• Explain management IP connectivity issue
• Interpret port lockdown settings to Self-IP
• Identify HTTP/SSH access list to management-IP address
159 | ©2019 F5
159
3.03 Identify the configured management-IP address
K15040: CONFIGURING AND DISPLAYING THE MANAGEMENT IP ADDRESS FOR THE BIG-IP SYSTEM
K7312: OVERVIEW OF THE MANAGEMENT INTERFACE (PORT)
GUI
TMSH
tmos)# list sys management-ip
sys management-ip 10.1.1.4/24 {
description configured-statically
}
“config” utility at the linux prompt

160 | ©2019 F5
There are numerous ways to configure the Out-of-Band (OOB) management

port. Initially the management interface will attempt to obtain an IP address via
DHCP, but the IP address can be configured, via the bash prompt with the
“config” command, via TMSH and via the TMUI interface (which may be a little
hard to get to until you populate the management IP).
160
3.03 Identify SSH access list to management-IP address
K13309: RESTRICTING ACCESS TO THE CONFIGURATION UTILITY BY SOURCE IP ADDRESS (11.X - 16.X)
To add to the allow list:
• modify /sys sshd allow add { <IP address or IP address range> }
To replace the list
• modify /sys sshd replace-all-with {<IP address or IP address range>}
Default is:
(tmos)# list sys sshd allow
sys sshd {
allow { All }
}
Save the change by entering the following command:
• save /sys config
161 | ©2019 F5
For security purposes, in addition to limiting access to the Linux CLI and TMSH
on a per user basis, you can use an allow list to limit SSH access to the
management IP to specific IP addresses or range. This SSH allow list is
configured in the Platform >> Configuration menu of the TMUI or via TMSH.
161
3.03 Identify HTTP access list to management-IP address
K13309: RESTRICTING ACCESS TO THE CONFIGURATION UTILITY BY SOURCE IP ADDRESS (11.X - 16.X)
To add to the allow list:
• modify /sys httpd allow add { <IP address or IP address range> }
To replace the list
• modify /sys httpd replace-all-with {<IP address or IP address range>}
Default is:
(tmos)# list sys httpd
allow
sys httpd {
allow { All }
}
Save the change by entering the following command:
• save /sys config
162 | ©2019 F5
HTTP access to 443 on the management interface can only be limited via
TMSH.
162
3.03 Show remote connectivity to the BIG-IP Management interface
You connect to the Management interface
• GUI over HTTPS (port 443)

• Terminal via SSH (port 22)
By default these ports are open on the OOB Manage IP
You can also connect to the management interfaces via a self IP address
• You must modify the default port lockdown of “None”

• You should never open management interfaces to the internet
163 | ©2019 F5
163
3.03 Interpret port lockdown settings to Self-IP
Port Lockdown determines which ports a self IP address will respond too
• By default Port Lockdown is none, the self IP only responds to ICMP
Port Lockdown settings can be modified to allow other traffic, such as,
port 443 or 22 for management
164 | ©2019 F5
By default Self IP address will only respond the ICMP traffic. But Self IP
address can be configured to respond to any UDF or TCP port, by changing the
Port Lockdown from “Allow None” to another selection and configuring the
required ports. Why would you want to do this? You may not have an OOB
management network and may have to open up HTTPS and SSH on an internal
network to allow management access to the BIG-IP. You may want to do
SNMP polling via a Self IP address. There are numerous reason. But, in
general, you should never expose management ports on a self IP that faces the
internet. A possible except might be to allow temporary access to the BIG-IP
by F5 support or profession services.
164
3.03 Interpret port lockdown settings to Self-IP
You can select “Allow Default” which opens the following:

• ospf:any list net self
• tcp:domain (53) net self client_ip {
• tcp:f5-iquery (4353) address
10.1.10.245/24
• tcp:https (443)
allow-service {
• tcp:snmp (161) tcp:ssh
• tcp:ssh (22) tcp:https
• udp:520 }
• udp:cap (1026 - for network failover)
• udp:domain (53)
• udp:f5-iquery (4353)
• udp:snmp (161)
Or you can select custom ports to open

165 | ©2019 F5
If you select Allow Default, BIG-IP opens up the commonly used ports for the
management, SNMP, DN, high availability (Device Service Clusters). But you
can also customize the exact protocols and ports you want open.
165
Restricting Access to Management Ports on Self IPs
166 | ©2019 F5
You can further restrict access to Self IP address using packet filters.
166
Packet Filtering
DISABLED BE DEFAULT, BUT ONCE YOU ENABLE
167 | ©2019 F5
Packet filtering is disable by default. You must Enable packet filtering before
you can configure ACLs.
F5 Agility 2016 167

3.03 Explain management IP connectivity issue
If using OOB Management
• Is the IP, netmask and default gateway configured correctly

• Is the interface up
− At the Linux prompt: ifconfig -a mgmt
If using a Self IP
• Is the IP and netmask configured correctly
− Are they routable
• Are the appropriate ports open, 22 for SSH and/or 443 for the GUI interface
• Are the any packet filters blocking traffic
168 | ©2019 F5
168
5.02
Explain the processes of licensing, license reactivation, and license
modification
• Show where to license (activate.F5.com)
• Identify license issues
• Identify Service Check Date (upgrade)
169 | ©2019 F5
169
5.02 Show where to license (activate.F5.com)
K7752: LICENSING THE BIG-IP SYSTEM
About 5 minutes of video total, explains it as well as I could:
F5 YouTube: Licensing the BIG-IP system
F5 YouTube: vCMP licensing considerations
170 | ©2019 F5
So here are two YouTube videos that will tell you everything you need to know
about activating and view your licensing options.
170
(tmos)# show sys license
5.02 Identify license issues Sys::License

Licensed Version
Registration key
10.0.1
W8521-87284-29591-40029-4630899
K9245: VERIFYING THAT A BIG-IP LICENSE IS VALID Licensed On 2009/06/19
License Start Date 2009/06/18
License End Date 2011/07/06
Service Check Date 2011/06/06
tmsh show sys license Platform ID C62
Appliance Serial Number bip055932s
• If the system is properly licensed, the command output Active Modules
displays licensing information for the BIG-IP system Global Traffic Manager Module (C270772-7443956)
ADD IPV6 GATEWAY
STP Feature Module
If the license has expired, the BIG-IP system will display the Link Controller Module (D336898-2457178)
ADD IPV6 GATEWAY
following error: ADD RATE SHAPING
ADD ROUTING BGP
• Warning: license has expired ADD ROUTING OSPF
ADD ROUTING RIP
Local Traffic Manager Module (Z235635-4592979)
If the license process has yet to be performed, the license is ADD IPV6 GATEWAY
ADD RATE SHAPING
missing, or the license is not properly installed: ADD 5 MBPS COMPRESSION
ADD RAMCACHE
• The BIG-IP system will not function ADD ROUTING BGP
ADD ROUTING OSPF
• The tmsh show sys license command will display ADD ROUTING RIP
Message Security Manager
− Can't load license, may not be operational ADD CLIENT AUTHENTICATION
ADD SSL 100
171 | ©2019 F5
Beyond that, when you are troubleshooting a licenses there are a couple of
different places you can look. In TMSH the “show sys license” command will
let you know the date the BIG-IP license was activated (or re-activated), the
license end date (which is really only pertinent when you are working with
evaluation, aka strongbox, licensing. The Service Check Date, which is the
day the BIG-IP maintenance contract expires at the time the BIG-IP license was
activated or re-activated. This is an important distinction, because customer
are renewing maintenance contracts without re-activating licensing which often
means the Service Check Date is out of sync. This is not usually an issue
unless you are attempting to perform an upgrade, in which case you will want to
re-activate the license and update the service check date. The TMSH
command will also tell you which modules and features are licensed under
Active Modules.
171
5.02 Identify license issues
IS THE MODULE ACTUALLY LICENSED
172 | ©2019 F5
Active modules and licensing date and expiration can be found in the TMUI, but
the Service Check date is NOT available through the TMUI.
172
(tmos)# show sys license
Sys::License
5.02 Identify Service Check Date (upgrade) Licensed Version
Registration key
10.0.1
W8521-87284-29591-40029-4630899
Licensed On 2009/06/19
License Start Date 2009/06/18
License End Date 2011/07/06
Service Check Date 2011/06/06
Platform ID C62
Appliance Serial Number bip055932s
Active Modules
In the license file /config/bigip.license Global Traffic Manager Module (C270772-7443956)
ADD IPV6 GATEWAY
# STP Feature Module
Link Controller Module (D336898-2457178)
# Licensing Information
ADD IPV6 GATEWAY
# ADD RATE SHAPING
Licensed date : 20160617 ADD ROUTING BGP
License start : 20160616 ADD ROUTING OSPF
License end : 20160802 ADD ROUTING RIP
Service check date : 20160522 Local Traffic Manager Module (Z235635-4592979)
ADD IPV6 GATEWAY
#
ADD RATE SHAPING
# Platform Information ADD 5 MBPS COMPRESSION
# ADD RAMCACHE
Registration Key : NHQRP-YWHGO-WFQJK-YAZTM-FHJYBFE ADD ROUTING BGP
Licensed version : 11.5.3 ADD ROUTING OSPF
ADD ROUTING RIP
Message Security Manager
ADD CLIENT AUTHENTICATION
ADD SSL 100
173 | ©2019 F5
This information can also be found in the /config/bigip.license file. The reason
why the Service Check Date is so important to upgrades is that the BIG-IP will
not upgrade to a version of TMOS that was released after the Service Check
Date. So a current Service Check Date is always important when upgrading to
ensure the upgrade goes smoothly.
173
3.07
Identify which modules are licensed and/or provisioned
• Show provisioned modules
• Report modules which are licensed
• Report modules which are provisioned but not licensed
• Show resource utilization of provisioned modules
174 | ©2019 F5
174
3.07 Show provisioned modules
The Resource Provisioning page
• Shows licensed modules

• Show subscriptions license and expiration
• Show provisioned modules
A module must be License and Provision to process
traffic.
175 | ©2019 F5
175
3.07 Show provisioned modules TMSH
(tmos)# list sys provision (tmos)# show sys provision
sys provision afm { } ---------------------------------------------------------
sys provision am { } Sys::Provision
sys provision apm { } Module CPU (%) Memory (MB) Host-Memory (MB) Disk (MB)
sys provision asm { } ---------------------------------------------------------
sys provision avr { afm 0 0 0 0
level nominal am 0 0 0 0
} apm 0 0 0 0
sys provision dos { } asm 0 0 0 0
sys provision fps { } avr 1 702 768 3900
sys provision gtm { } dos 0 0 0 0
sys provision ilx { } fps 0 0 0 0
sys provision lc { } gtm 0 0 0 0
sys provision ltm { host 10 2298 0 19750
level nominal ilx 0 0 0 0
} lc 0 0 0 0
sys provision pem { } ltm 1 0 0 0
sys provision swg { } pem 0 0 0 0
sys provision urldb { } swg 0 0 0 0
tmos 88 4984 140 0
176 | ©2019 F5 urldb 0 0 0 0
176
3.09
Identify configured system services
• Show proper configuration for: DNS, NTP, SNMP, syslog
177 | ©2019 F5
177
3.09 Show proper configuration for: DNS, NTP, SNMP, syslog
MANUAL CHAPTER : GENERAL CONFIGURATION PROPERTIES
K13380: CONFIGURING THE BIG-IP SYSTEM TO USE AN NTP SERVER FROM THE COMMAND LINE (11.X - 13.X)
NTP is essential for:
• Device Service Clusters

• Configsync
• Logging
178 | ©2019 F5
There are a number of system services that either useful or necessary for the
proper functioning of the BIG-IP and its integration in standard monitor and
logging entities. The ones you should know are DNS, NTP, SNMP and syslog.
NTP is probably the most important system service to configure on the BIG-IP.
Proper and synchronized time is critical to the proper functioning of Device
Service Clusters and HA. Configure synchronization relies on the date and
time to determine in devices are synchronized or the modifications have been
made to one of the systems. Obviously proper and synchronized date and
times are important to event correlation and logging.
178
MANUAL CHAPTER : GENERAL CONFIGURATION PROPERTIES
DNS Lookup Server List enables users to use the following for
accessing virtual servers, nodes, or other network objects.
• IP addresses
• host names
• fully-qualified domain names (FQDNs)
The DNS Search Domain List enables BIG-IP to search for

local domain lookups to resolve local host names.
Additionally, you can manually configure the BIND Forwarder

Server List that provides DNS resolution for servers and other
equipment load-balanced by the BIG-IP system (for the
servers that the BIG-IP system uses for DNS proxy services).
179 | ©2019 F5
179
MANUAL CHAPTER : MONITORING BIG-IP SYSTEM TRAFFIC WITH SNMP
BIG-IP SNMP agent configuration
• The primary tasks in configuring the SNMP agent are configuring

client access to the SNMP agent, and controlling access to
SNMP data.
Task Summary
• Specify SNMP administrator contact information and system

location information
• Configure SNMP manager access to the SNMP agent on the
BIG-IP system
• Grant community access to v1 or v2c SNMP data
• Grant user access to v3 SNMP data
180 | ©2019 F5
You can use the industry-standard SNMP protocol to manage BIG-IP® devices
on a network. To do this, you must configure the SNMP agent on the BIG-IP
system. The primary tasks in configuring the SNMP agent are configuring client
access to the SNMP agent, and controlling access to SNMP data.
180
MANUAL CHAPTER : MONITORING BIG-IP SYSTEM TRAFFIC WITH SNMP
SNMP trap configuration

• Configuring SNMP traps on a BIG-IP system means configuring
how the BIG-IP system handles traps, as well as setting the
destination to which the notifications are sent.
The BIG-IP system stores SNMP traps in two specific files:

• /etc/alertd/alert.conf - contains default SNMP traps.
− Important: Do not add or remove traps from the /etc/alertd/alert.conf file.
• /config/user_alert.conf - contains user-defined SNMP traps.
Task Summary
• Enabling traps for specific events
• Setting v1 and v2c trap destinations
• Setting v3 trap destinations
181 | ©2019 F5
SNMP traps are definitions of unsolicited notification messages that the BIG-
IP® alert system and the SNMP agent send to the SNMP manager when
certain events occur on the BIG-IP system. Configuring SNMP traps on a BIG-
IP system means configuring how the BIG-IP system handles traps, as well as
setting the destination to which the notifications are sent.
181
MANUAL CHAPTER : ABOUT LOGGING
Log Destinations
• The High-Speed Logging (HSL) or Unformatted destination
• Defines the protocol to use (UDP or TCP)
• Defines the server pool the log message will go too
The Formatted destination defines the format of the messages being

sent
• There are two parts to a Destination
− Where a message is going : HSL Destination
− What the message looks like: Formatted Destination
Publisher
• A Publisher is a collection of Formatted Destinations
182 | ©2019 F5
Remote Logging for all BIG-IP modules consists of three common logging
elements; Pools, Destinations and Publishers.
Pools are a collection of logging servers defined by IP address and port.
Destinations define the format the messages and the pool the message is to be
sent too. You will always have to configure to high-speed destinations, a
unformatted destination and a formatted destination.
- Unformatted aka High-Speed Logging (HSL) destinations defined the pool a
message will be sent too.
- Formatted destinations define the format of the message (i.e. Splunk or
Syslog) and the HSL destination of the formatted message.
Publishers are collections for Formatted Destination. Messages generated will

be sent to each Formatted Destination in a publisher.
182
Remote Logging Steps
1. Create a Pool of logging server(s)

2. Create an HSL Destination (define the protocol TCP/UDP and Pool)
3. Create a Formatted Destination (define format ie. syslog, arcsight)
4. Create a Publisher
5. Logging Application Steps (varies by Application)
− System Logging
• linux host daemons, etc
• Uses filters
− Security Logging
• Advanced Firewall Manager, DNS Firewall, Protocol Security Module and the Applications Security Manager
• Uses Security Logging Profile
− High Speed DNS Query Logging:
• Uses Security Logging Profile
183 | ©2019 F5
Here are the steps involved in remote logging under the new logging paradigm.
While it appears to be a lot of steps, the flexibility and power are well worth the
additional effort.
The user creates a pool of remote logging servers, a High Speed Logging
Destination, a Formatted Destination, and a Publisher. Further configuration
steps depend on which logging application is being configured. System
Logging uses Filters. The Advanced Firewall Manager (AFM), Protocol Security
Module (PSM) and Application Security Manager (ASM) modules, along with
High Speed DNS Logging, all use logging profiles which are then attached to
the relevant configuration elements.
183
Logging Overview
System
Formatted HSL
Security Publisher Pool
Destination Dest.
High
Speed
DNS Different
HSL
Formatted Pool
Dest.
Destination
184 | ©2019 F5
Here's another way to look at it. Log Messages from the System, Advanced
Firewall Manager (AFM), or High Speed DNS logging all go through a
Publisher, which is a list of Destinations. Generally, those Destinations will be
Formatted Destinations. The formats supported in this release are Syslog,
Splunk, and ArcSight. Formatted Destinations forward to a High Speed Logging
(HSL) Destination, which consists of a pool name. The HSL Destination then
forwards to the Pool of log servers.
The publisher could actually send the messages to multiple locations in multiple
formats, if needed.
184
System Logging Filters
Under System > Logs > Configuration > Log Filters
Can create custom filters
• Name
• Description (optional)
• Severity
− Default is Debug
• Source
− List of processes
− Defaults to all
• Message ID
• Log Publisher
185 | ©2019 F5
The new way to configure System Logging requires the elements described
previously and a new feature call the System Logging (TMM) Filter.
The System Logging Filter configuration elements consist of a unique Name, an

optional description, a Severity threshold, a Source of log messages, which can
be a single process or all processes, an optional message ID to match against,
and a Log Publisher.
185
Tools for Testing – DNS, NTP, SNMP, SYSLOG
DNS
• You should know to use and interpret the results of the dig utility
NTP
• K10240: Verifying NTP peer server communications
SNMP
• There is a test snmp button on the configuration page
Good old tcpdump
Show services
• tmsh show service <service> or tmsh show service (shows all services)
• From the linux prompt: bigstart status
− This will show you the status of the various daemons the BIG-IP uses.
186 | ©2019 F5
186
3.08
Explain authentication methods
• Explain how to create a user
• Explain how to modify user properties
• Explain options for remote authentication provider
• Explain use of groups using remote authentication provider
187 | ©2019 F5
187
3.08 Explain how to create a user
MANUAL : BIG-IP SYSTEMS: USER ACCOUNT ADMINISTRATION
User and Password are required
Assign a role
Assign partition access

• A user may be assigned to one partition or All partitions
Assign the type of terminal access (Specify the type of CLI access)
• Disabled
− The user may access only the GUI interface
• TMSH
− Permits the user access to the TMOS CLI shell via SSH
• Advanced Shell
− Permits user access to the Linux prompt
Administrator and Resource Administrator only

188 | ©2019 F5
188
F5 Agility 2016 188

3.08 Explain how to create a user
189 | ©2019 F5
You will need to know how to create and modify users, what basic roles they
can be given and how to limit or expand their access to the BIG-IP system.
Users can be created and modified via the TMUI or TMSH. You access the
user menus in the TMUI under System >> Users >> User List.
1. You will be required to enter a username and password
2. You will assign the user a role. We will cover common user roles in a
minute.
3. You will then assign them Terminal Access
1. Disabled is the default and means the user only has TMUI access
2. Advanced shell can only be assigned to the Administrator role and allows access to
the Linux (bash) prompt
3. tmsh places the uses into the TMSH shell when they SSH into the BIG-IP. The user
cannot exit to the bash prompt
189
User Roles (most common)
No Access
• Prevents users from accessing the system. Basically turns off the account without deleting the account.
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. Cannot enable/disable virtual servers.
Application Editor
• Grants users permission to modify existing nodes, pools, pool members, and monitors.
Manager
• Permission to create, modify, and delete virtual servers, pools, pool members, nodes, custom profiles, custom monitors, and iRules.
Administrator
• Grants users complete access to all objects on the system.
190 | ©2019 F5
Here are the common user roles.
190
3.08 Explain how to modify user properties
JUST GO BACK IN AND CHANGE THEM
191 | ©2019 F5
Modifying user properties is as simple as going back in and changing things.
191
3.08 Explain options for remote authentication provider
Still will always need a least one admin local account
• For config sync functionality

• In case you lose access to authentication server
Supports AD, LDAP, TACACS+ and RADIUS
192 | ©2019 F5
You can also use standard authentication protocols, such as, AD, LDAP,
TACACS+ and RADIUS to integrate the BIG-IP into your standard
authentication infrastructure and grant access based on group. You should
always have at least one local administrator account configured in case you
lose access to the authentication server(s).
192
3.08 Explain use of groups using remote authentication provider
For a remote group you can chose to:
• Enable/disable remote access

• Assign a permissions role to members of the group
• Select All/Common/Specific name partition access
• Select the type of terminal access required.
193 | ©2019 F5
Here is an example of setting up access by groups when using remote

authentication protocols.
193
3.05
Apply procedural concepts required to create, manage, and restore
a UCS archive
• Summarize the use case of a UCS backup
• Execute UCS backup procedure
• Execute UCS restore procedure
• Explain proper long-term storage of UCS backup file
• Explain the contents of the UCS file (private keys)
194 | ©2019 F5
194
3.05 Summarize the use case of a UCS backup
K4423: OVERVIEW OF UCS ARCHIVES
A user configuration set (UCS) is a backup file that contains BIG-IP configuration data that can be used to fully restore a
BIG-IP system in the event of a failure or Return Materials Authorization (RMA) replacement.
A UCS archive is a compressed file that contains all of the configuration files that are typically required to restore your
current configuration to a new system
Contents of the UCS archive file

• All BIG-IP-specific configuration files
• BIG-IP product licenses
• User accounts and password information
• Domain Name System (DNS) zone files and the ZoneRunner configuration
• Secure Socket Layer (SSL) certificates and keys
• Startup ZebOS configuration
195 | ©2019 F5
195
3.05 Summarize the use case of a UCS backup
You should create a UCS archive before operations that modify the configuration.
• You can keep archives locally and/or download/upload archives to/from external sources
• By default UCS archives are stored in /var/local/ucs
Aside from the obvious, restoring your BIG-IP due to a corrupted/misconfigured configuration, a UCS is used to:
• Restore an RMA
• Manual Chapter : Migration of Configurations Between Different Platforms
• Manual Chapter : Migration of Devices Running the Same Software Version
• Manual Chapter : Migration of Devices Running Different Version Software
196 | ©2019 F5
196
3.05 Execute UCS backup and restore procedure
K13132: BACKING UP AND RESTORING BIG-IP CONFIGURATION FILES WITH A UCS ARCHIVE
You can create, delete, restore, upload and download UCS archives from the GUI interface:
197 | ©2019 F5
197
3.05 Execute UCS backup and restore procedure
MANUAL CHAPTER : ARCHIVES
You can also create, delete and restore UCS backups using TMSH, but TMSH has options the GUI doesn’t.
• Backup the BIG-IP: save sys ucs <ucs filename>
• Restore the BIG-IP: load sys ucs <ucs filename>
If you are restoring an RMA or migrating to a new platform you do NOT want to restore the license.
• load sys ucs <filename> no-license
If you are migrating platforms you may not want to restore the base configurations as interfaces may be different.
• On the system you are restoring you would build the base first, interfaces, VLANs, self IPs, etc
• load sys ucs platform-migrate <filename> no-license
Other TMSH options
• no-platform-check Bypass platform check.
• passphrase Passphrase for (un)encrypting UCS.
• reset-trust Reset device and trust domain certificates and keys whenloading a UCS.
198 | ©2019 F5
198
3.05 Explain proper long-term storage of UCS backup file
Store passwords and passphrases securely

• After you encrypt configuration object passwords or passphrases on any BIG-IP system, another system can only
decrypt them (during a tmsh load config operation) by using the same master key
• F5 recommends that you retain a record of each configuration object password or passphrase in a secure location on
a system other than the BIG-IP system that uses the password or passphrase.
− Doing so makes it possible for you to restore a UCS configuration archive when the original master key is not available.
Store UCS archives securely

• Make sure that you regularly back up the BIG-IP system configuration and maintain the backup UCS archives in a
secure manner.
• The preferred way to store UCS archives securely (encrypts the entire UCS file):
• (tmos) # save sys ucs <ucs name> passphrase <passphrase>
These recommendations can be accomplished via the GUI or TMSH interfaces.

199 | ©2019 F5
199
3.05 Explain the contents of the UCS file (private keys)
A typical UCS archive contains user accounts, passwords, critical system files, and SSL private keys.
• You can explicitly exclude SSL private keys from a UCS archive during the backup process.
From TMSH:
• save sys ucs test-backup no-private-key
From the GUI:
200 | ©2019 F5
You may not always want to store SSL keys in your UCS backup, particularly if
the archive will be easily accessible and/or unencrypted. You can opt to create
a UCS backup where the private keys are excluded. The caveat to this is the
private keys must be place on the BIG-IP prior to restoring from the UCS
archive if they are not already present, for example, if you are restoring to an
RMA appliance.
200
3.06
Apply procedural concepts required to manage software images
• Given an HA pair, describe the appropriate strategy for deploying a new

software image
• Perform procedure to upload new software image
• Show currently configured boot location
• Demonstrate creating new volume for software images
201 | ©2019 F5
201
YouTube: Updating BIG-IP HA systems with a point release
This video walks you through the steps to upgrade a BIG-IP HA pair:
• 0:13 Part 1: Installing the point release on the first device
• 0:40 Validating the configuration
• 1:53 Verifying the Service check date
• 3:23 Synchronizing the configuration
• 4:32 Creating and saving a UCS archive
• 5:52 Importing the ISO file
• 7:05 Verifying the MD5 checksum
• 7:45 Disabling the "Automatic with Incremental Sync" option
• 8:30 Installing and rebooting to the new version
• 14:16 Verifying the new point release version is active on the newly patched system
• 15:00 Forcing a failover
• 16:20 Part 2: Installing the point release on the next device
• 16:25 Repeat these steps
• 16:49 Verifying the new point release version is active on the newly patched system
• 17:46 Forcing a failover
• 19:25 Part 3: Performing the final ConfigSync
202 | ©2019 F5
Watch the YouTube video. I couldn’t explain it any better.
202
https://downloads.f5.com
REQUIRES AN F5 ACCOUNT
203 | ©2019 F5
You can find your software images on https://downloads.f5.com. You will be

required to have an F5 account.
F5 Agility 2016 203

3.06 Show currently configured boot location
(tmos)# show sys software
--------------------------------------------------
Sys::Software Status
Volume Product Version Build Active Status
--------------------------------------------------
HD1.1 BIG-IP 13.1.3.4 0.0.5 yes complete
----------------------------
Sys::Software Update Check
----------------------------
Check Enabled true
Phonehome Enabled true
Frequency weekly
Status failure
Errors 8
204 | ©2019 F5
Finding the boot location is relatively simple again you can do it through TMSH
or through the GUI when you go to system software management boot
locations the active status is the boot volume. Also in the Linux CLI you can
enter switchboot which will show you the current boot locations and allow you
to activate a boot locations, but it is recommended you do it through TMSH or
the TMUI.
204
3.06 Demonstrate creating new volume for software images
install sys software image <iso> volume <name>
205 | ©2019 F5
Creating software images can be done through TMSH or the GUI. When
installing a new software image you have the option of installing on a current
inactive boot volume or creating a new boot volume by using alphanumerics to
create a new boot volume. Except for BIG-IP VE 1 slot versions, BIG-IPs will
be able to have two or more boot volumes. If disk space is not available for a
new volume, then you will have to overwrite or delete and existing inactive
volume.
205
3.04 (R)
List which log files could be used to find events and/or hardware
issues
• Identify use of /var/log/ltm, var/log/secure, /var/log/audit
• Identify severity log level of an event
• Identify event from a log message
206 | ©2019 F5
206
3.04 Identify use of /var/log/ltm, var/log/secure, /var/log/audit
K16197: REVIEWING BIG-IP LOG FILES
/var/log/ltm
• The local traffic messages pertain specifically to the BIG-IP local traffic management events
• Can be found in the GUI under System >> Logs >> Local Traffic
• In TMSH: show sys log ltm
• In bash: cat /var/log/ltm
207 | ©2019 F5
You should understand and be able to interpret BIG-IP log files, particularly the
ltm, secure and audit log files. The ltm log file logs Local Traffic Manager
events. The secure and audit log files tend to compliment each other as we will
see. You should check out AskF5 article K16197: Reviewing BIG-IP log files
which has some excellent videos on logging, as well as other information.
207
AUDITING USER ACCESS
/var/log/secure
• Log information related to authentication and authorization

privileges.
• Can be found in the GUI under System >> Logs >> Audit
• In TMSH, show sys log secure
• In Bash, cat /var/log/secure
208 | ©2019 F5
208
K16197: REVIEWING BIG-IP LOG FILES
/var/log/audit
• Log changes to the BIG-IP system configuration. Logging audit events is optional.
• Can be found in the GUI under System >> Logs >> Audit
− In TMSH, show sys log audit
− In Bash, cat /var/log/audit
209 | ©2019 F5
In additional to knowing who has accessed the BIG-IP from the secure log, you
can see the modifications they made to the system.
209
Other Log Files
K15521451: BIG-IP TMOS OPERATIONS GUIDE | CHAPTER 12: LOG FILES AND ALERTS
• LTM - /var/log/ltm local0

• EM - /var/log/em local1
• GTM - /var/log/gtm local2
• ASM - /var/log/asm local3
• iControl - /var/log/ltm local4
• Packet Filter - /var/log/pktfilter local5
• HTTPD Errors - /var/log/httpd/httpd_errors local6
• Boot Process - /var/log/boot.log local7
210 | ©2019 F5
All local log files are kept in /var/log/. Which file the message is logged to
depends on the type of messages and where is came from. The locals can be
used by iRules to log message into a particular log file.
F5 Agility 2016 210

3.04 Identify severity log level of an event
The log levels that you can set on certain types of events, ordered from highest severity to lowest severity, are:
• Emergency
• Alert
• Critical
• Error
• Warning
• Notice
• Informational
• Debug
ltm 08-05 15:53:35 err bigip01 tmm1[16618]: No members available for pool /Common/purple_pool
211 | ©2019 F5
211
3.04 Identify event from a log message
Local Traffic
Audit
212 | ©2019 F5
So let’s look at some events. The Local Traffic log is sorted from most recent
event down (down arrow by Timestamp). So what happened?
1. The monitor http_200OK marked the pool member down after no response
2. No members were available in the pool (the pool is Offline)
3. Pool is offline, the Virtual is move to Offline (Red)
4. If we look at the audit log we find the admin made a change the pool and
http_200OK was part of that change
So its probably a wrong or misconfigured monitor
212
System Configuration Resources
• K15521451: BIG-IP TMOS operations guide | Chapter 12: Log files and alerts
− LCD https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/platform-b5000/2.html?sr=54998935
• K15040: Configuring and displaying the management IP address for the BIG-IP system
− K15040: Configuring and displaying the management IP address for the BIG-IP system
• K13309: Restricting access to the Configuration utility by source IP address (11.x - 16.x)
• K7752: Licensing the BIG-IP system
− F5 YouTube: Licensing the BIG-IP system
− F5 YouTube: vCMP licensing considerations
• K9245: Verifying that a BIG-IP license is valid

− K2595: Activating and installing a license file from the command line
− K16538: Functionality is inactive for features of optional modules in the BIG-IP license
− K7727: License activation may be required prior to a software upgrade for the BIG-IP or Enterprise Manager system
− K41458656: Reusing a BIG-IP VE license on a different BIG-IP VE system
• Manual Chapter : General Configuration Properties

• K13380: Configuring the BIG-IP system to use an NTP server from the command line (11.x - 13.x)
− K10240: Verifying NTP peer server communications
− K3381: Setting the time and date on the BIG-IP system
• Manual Chapter : Monitoring BIG-IP System Traffic with SNMP

• Manual Chapter : About Logging
213 | ©2019 F5
213
System Configuration Resources (cont)
• Manual : BIG-IP Systems: User Account Administration
• K4423: Overview of UCS archives
• K13132: Backing up and restoring BIG-IP configuration files with a UCS archive
• Manual Chapter : Working with UCS archives
− Manual Chapter : Migration of Configurations Between Different Platforms
− Manual Chapter : Migration of Devices Running the Same Software Version
− Manual Chapter : Migration of Devices Running Different Version Software
• Manual Chapter : Archives

• YouTube: Updating BIG-IP HA systems with a point release
• K33265170: Deleting a boot location volume to free up disk space
• K14403: Maintaining disk space on the BIG-IP system
• Manual Chapter : About Logging
• K16197: Reviewing BIG-IP log files
• Auditing User Access
• K15521451: BIG-IP TMOS operations guide | Chapter 12: Log files and alerts
214 | ©2019 F5
214
BREAKTIME
215 | ©2019 F5
215
HA and System State
Objectives 3.10, 3.02, 2.01
216 | ©2019 F5
216
3.10
Explain config sync
• Show config sync status
• Explain when a config sync is necessary
• Compare configuration timestamp
• Demonstrate config sync procedure
• Report errors which occur during config sync
217 | ©2019 F5
217
3.10 Show config sync status
MANUAL CHAPTER : MANAGING CONFIGURATION SYNCHRONIZATION
By default, synching a configuration is a

manual process
[root@bigip01:Active:Changes Pending] config #
218 | ©2019 F5
The config sync status can be seen in a number of different ways;

• It is in the upper left hand corner of the big IP GUI next to F5 ball as you can
see in the page here In Sync
• It can be seen under the device management overview
• And as part of the Linux or TMSH prompt
By default config sync is a manual process. The reason for this is to prevent a
user from making a misconfiguration and having that erroneous configuration
automatically pushed over to the other BIG-IPs in the service cluster so that
there is no recovery by just failing over. In that case, recovery would require
reconfiguring or restoring from a UCS.
218
3.10 Explain when a config sync is necessary
K39735803: WHEN TO PERFORM A MANUAL CONFIGSYNC
When you make a change to a device in the Device Service Cluster (DSC) and automatic sync is not enabled
Before you begin a software upgrade of a DSC to ensure all configurations are correctly synchronized
After you complete a software upgrade for a BIG-IP device group. after all of the BIG-IP devices in the device group are upgraded to the
new BIG-IP software version.
• This recommendation applies to device groups configured to use any ConfigSync option, including the Automatic Sync option.
You want to migrate a device group member to a new BIG-IP hardware platform.
• Note: For more information, refer to K15496: Migrating a device group member to a new BIG-IP hardware platform..
You want to migrate a BIG-IP configuration to new VIPRION blades.

• Note: For more information, refer to K63705154: Migrating a BIG-IP configuration to new VIPRION blades using ConfigSync.
You are using Automatic Sync, and you want to synchronize changes to device group members and immediately save the running
configuration to the configuration files on the peer devices.
219 | ©2019 F5
As you can see here there are number of reasons you may need to perform a
config sync.
219
3.10 Compare configuration timestamp
K81160517: MODIFYING THE CONFIGSYNC TIME THRESHOLD
Timestamps can be checks on the status page, switching to Advance will give you more information
Each device checks the remote device's time against its own system time.
• If the time is not within the ConfigSync time threshold default value of three seconds, the command prompt
changes to indicate that the time is out of sync (Peer Time Out of Sync), and ConfigSync operations may fail.
• You may have to increase the threshold to rectify the issue.
• This a reason configuring NTP on BIG-IP is so important.
• K81160517: Modifying the ConfigSync time threshold shows you how to check and rectify the issue.
220 | ©2019 F5
There is no concept of master or slave into device service cluster. This means
that if one admin was on bigip1 and made a change and another admin was on
bigip2 and made a change those changes wouldn't sync up. Each device would
have a different configuration at that point and a config sync from one device
would overwrite the changes on the other device. Comparing configuration
timestamps can help an administrator determine which device has the latest
configuration or if somehow the devices our out of sync. This is why NTP is
vitally important on BIG-IPs in a device service cluster.
220
3.10 Demonstrate config sync procedure (GUI)
MANUAL CHAPTER : MANAGING CONFIGURATION SYNCHRONIZATION
F5 YouTube: Performing a ConfigSync using the

Configuration utility ~2 min
You can Push or Pull a configsync
• You may want a pull if you make changes you

regret
221 | ©2019 F5
So when you need to do a config sync you will have two options, you can push
or pull. When you want to perform your config sync procedure you will select
the device and then you will either push that device’s configuration to all the
other devices in the cluster or you will pull from the other devices in the cluster
and overwrite the configuration of the device you selected.
221
3.10 Demonstrate config sync procedure (TMSH)
K14856: PERFORMING A CONFIGSYNC USING TMSH
F5 YouTube: Performing a ConfigSync using tmsh ~1min
run /cm config-sync <sync_direction> <sync_group>
<sync_direction>
force-full-load-push Sync configuration to the specified device group even if
the system would deem this unsafe. This may result in
loss of configuration on other devices.
from-group Sync configuration from specified device group.
recover-sync Resets the local device configuration and restores trust

domain, device, and device-group information to default
settings.
to-group Sync configuration to specified device group.

222 | ©2019 F5
This can also be done from the TMSH command line.
222
3.10 Report errors which occur during config sync
K13946: TROUBLESHOOTING CONFIGSYNC AND DEVICE SERVICE CLUSTERING ISSUES
To troubleshoot the ConfigSync operation, perform the following procedures:
• Verifying the required elements for ConfigSync/DSC

• Reviewing common reasons for ConfigSync failures (recommended viewing)
• Viewing the commit ID updates
• Verifying a ConfigSync operation
• Verifying the Sync status
• Understanding Sync status messages (recommended viewing)
• Reviewing the log files for ConfigSync error messages (recommended viewing)
223 | ©2019 F5
There are number of things that can cause errors in the config sync process or
in the device group .
• For one thing devices in in a cluster must have the same licensing and same
provisioning.
• They must be running on the same software version.
• NTP again is important they should all have the same time.
• The config sync IP has to be configured on each device, the failover IP has to
be configured on each device and the correct ports have to be open on these
IPs for the process to work correctly.
• Also a device trust must have been established and functioning so that we
have secure communications between the devices .
These are just some of the reasons you may have issues performing
synchronization. As you can see there are a number of links that I have provide
you to learn more about this topic.
223
3.02
Apply procedural concepts required to manage the state of a high
availability pair
• Report current active/standby failover state
• Show device trust status
• Execute force to standby procedure
• Execute force to offline procedure
224 | ©2019 F5
224
Before we begin: A little more on Device Service Clusters.
For BIG-IPs to be combined into clusters for high availability, certain things must configured:
• BIG-IPs must have a valid device certificate

• On the device, IP addressing must be defined for failover
• Devices must be place into a trust group
• Devices in a trust group and then be place into a failover group
225 | ©2019 F5
The blueprint is a little vague on how much you need to know about device
service clusters, so before we go any further let’s do a brief overview.
For BIG-IPs to be combined into sync-failover groups, that is be able to

synchronize configuration and failover to each other and a basic understand of
this process will help you troubleshoot HA issues. The following needs to
happen:
1. The BIG-IP must have a valid device certificate and IP address for
configuration sync, network failover (if desired) and mirroring (if desired)
must be configured.
2. The BIG-IPs must then be place into a device-trust-group. Here they will
share device certificates for secure communication and the aforementioned
IP addressing
3. The devices in a device-trust-group can then be place into a device-group,
which is define as a sync-failover group or sync-only
4. Traffic groups can then be configured, by default base IP address goes into
traffic-group-local-only and all other listeners go into traffic-group-1
225
3.02 Report current active/standby failover state
[root@bigip01:Active:In Sync] config # [root@bigip02:Standby:In Sync] config #
Active – there are one of more active traffic groups that can failover
Standby – there are no active traffic groups that can failover
226 | ©2019 F5
Like config sync, the failover state can be found in the GUI and at the command
prompt. A device in an active failover state simply means that there is an active
traffic group on the BIG-IP processing traffic . A big IP in a standby failover state
means that there simply are no active traffic groups on the BIG-IP. Although the
blueprint doesn’t specifically talk about traffic group, a brief explanation is
probably in order.
Traffic groups are a combination of listeners; virtual addresses, SNATs, floating

self IPs etc, that are required to process the traffic for one or more applications.
By default there are two traffic groups on a BIG-IP, traffic-group-local-only
(non-floating) and traffic-group-1 (floating). traffic-group-local-only contains
listeners that are unique to the BIG-IP (ie. Base self IPs) and go down when the
BIG-IP does. traffic-group-1 and all other subsequent traffic groups created
contain listeners that can and need to failover to other BIG-IPs.
On a pair of BIG-IPs, using the default configuration, having only one traffic
groups with all the applications in it, one BIG-IP will always be active and the
other in standby mode. If you were to configure a second traffic group and run
one traffic group on each BIG-IP they would be in an active-active mode.
226
3.02 Show device trust status
MANUAL CHAPTER : MANAGING DEVICE TRUST
(tmos)# show cm device-group device_trust_group
-----------------------------------------------------------
CM::Device-Group
-----------------------------------------------------------
Group Name device_trust_group
Member Name bigip01.f5demo.com
Time Since Last Sync (HH:MM:SS) 50:27:21
Last Sync Type full-load-auto-sync
CID Originator /Common/bigip02.f5demo.com
CID Time (UTC) 2020-Aug-05 18:53:10
LSS Originator /Common/bigip02.f5demo.com
LSS Time (UTC) 2020-Aug-05 18:53:10
-----------------------------------------------------------
CM::Device-Group
-----------------------------------------------------------
Group Name device_trust_group
Member Name bigip02.f5demo.com
Time Since Last Sync (HH:MM:SS) -
Last Sync Type none
CID Originator /Common/bigip02.f5demo.com
CID Time (UTC) 2020-Aug-05 18:53:10
LSS Originator /Common/bigip02.f5demo.com
LSS Time (UTC) 2020-Aug-05 18:53:10
227 | ©2019 F5
BIG-IPs must be part the same device trust group to be allowed to be combined
into device groups,. Should the device trust be broken, no synchronization or
failover can take place. An example problem might be the device certificate
expiring. You should always confirm the device trust status in In Sync.
227
3.02 Execute force to standby or offline procedure
(tmos)# run sys failover
offline Changes the status of a unit or cluster to

Forced Offline. If persist or no-persist are
not specified, the change in status will be
persisted in-between system restarts.
online Changes the status of a unit or cluster from

Forced Offline to either Active or Standby,
depending upon the status of the other unit
or cluster in a redundant pair.
standby Specifies that the active unit or cluster

fails over to a Standby state, causing the
standby unit or cluster to become Active.
228 | ©2019 F5
Important. You cannot force BIG-IP to become an Active BIG-IP, you can only
force it to Standby or Offline. At the device level, this will force all traffic groups
to failover to other members of the cluster. Under the Traffic Groups selection
on the side-bar you can force individual traffic groups to failover to other
devices in the clusters.
228
Other HA concepts not explicitly called out in the blueprint
Device Service Clusters (DSCs) can consist of more than two BIG-IPs supporting each other
• Know where to find where failover objects on BIG-IP in the DSC will fail to
• Understand the difference between Active-Standby and Active-Active
You probably should have a working knowledge of Device Trust and the Device Trust Group
Have a working knowledge of mirroring.
• SNAT
• Persistence
− Only if persistence records are kept locally on the BIG-IP, not necessary for Cookie persistence.
• Connection Table
− Only for long term connections, ie. FTP, resource intensive
229 | ©2019 F5
On the chance that you need more information on high availability for the exam,
let’s cover a few more items at a high level.
• Note that more that up to 8 BIG-IPs can be part of a sync-failover group
• You can find where a traffic-group will fail on the Traffic Groups page
• For seamless failover certain information may need to be mirrored to the next
active device (the BIG-IP a traffic group will fail to):
• SNAT mirroring makes sure the failover device knows which SNAT IP:port combination a
client was using to communicate to the pool member
• Persistence mirroring, send persistence records created and maintain be the BIG-IP to
the failover device
• Connection mirroring, done on a per virtual server basis, mirrors the connection table
entries for that virtual server.
229
Other HA concepts not explicitly called out in the blueprint
Devices (Self)
• On the (Self) Device, which is the device you are on there
are several configuration items you show know
− These must be configured prior to building the device trust group
• ConfigSync - IP address the BIG-IP listens for

synchronizing configuration changes (TCP port 4353)
• Failover Network - IP address the BIG-IP uses to send and
receive polls to determine the state of other BIG-IPs in the
cluster (TCP port 1026)
• Mirroring - IP address where mirrored information is sent
and received
230 | ©2019 F5
Other reasons high availability may not be working is because the correct ports
are not open on the failover IPs for the required communications.
Here are the IP addresses and primary ports required for high availability. Not
all the ports required are listed here.
230
2.01
Determine resource utilization
• Distinguish between control plane and data plane resources
• Identify CPU statistics per virtual server
• Interpret Statistics for interfaces
• Determine Disk utilization and Memory utilization
231 | ©2019 F5
231
2.01 Distinguish between control plane and data plane resources
HTTPS://TECHDOCS.F5.COM/KB/EN-US/PRODUCTS/BIG-IP_LTM/MANUALS/PRODUCT/TMOS-ROUTING-ADMINISTRATION-13-1-0.HTML
Control Plane Data Plane
• Linux OS • TMOS (Traffic Management OS)
• Hardened CentOS • aka TMM

• Use to boot HW/SW • Runs TMM switch interface
• Runs TMSH CLI and APIs • L3 Switching and Routing
− VLANs, Self IPs, Routing for TMM
• Runs Out-of-Band Management
− By default uses DHCP • Pools and Virtual Servers
− IP address can be assigned manually
• Monitors
− Unique IP subnet and default gateway
• And basically all things basic to Local Traffic
Management and application security.
232 | ©2019 F5
In general, the control plane refers to processes and configurations designed to

allow the BIG-IP to be configured via the TMUI, the CLI (TMOS or Bash) or API,
out-of-band management interface and anything else running out of the LINUX
subsystem. TMOS (TMM) provides the data plane and is responsible for the
switching and routing network, pools, virtual servers, monitors and basically
anything having to do with traffic management.
232
2.01 Identify CPU statistics per virtual server
233 | ©2019 F5
You can see the CPU utilization of a virtual server in both the TMUI and TMSH.
If you find the BIG-IP CPU usages high via the performance stats or overview
you may want to see if a particular virtual server has a high utilization to begin
your troubleshooting or tuning efforts. Reasons may be as simple as, it takes a
lot of traffic, to more complex, such as a poorly written iRules.
233
2.01 Interpret Statistics for interfaces
234 | ©2019 F5
We discuss this earlier. You should have a working knowledge of basic

networking.
234
2.01 Determine Disk utilization and Memory utilization
235 | ©2019 F5
You can find an overview of memory utilization in the Performance report. High
memory utilization, may indicate a high number of active connections. Each
connection in the connection table is maintained in memory. An abnormally
high number of active connections could be an indicator of a DoS attack.
Persistence records, except for cookies, are maintained in memory (source
address, universal persistence). Turning on RAM Cache, caching HTTP
content will also consume memory.
235
236 | ©2019 F5
You can also find more detailed information. Though I would be surprised if any
question went this in depth.
236
237 | ©2019 F5
The provisioning page will show you the required disk space and memory to run
a module. You will not be able to provision modules unless the requisite disk
space and memory are available. For example, if you look at the Resource
Provisioning picture in the slide you will see provisioning LTM and AVR have
allocated all the disk space and most of the memory. If you wanted to provision
Application Security (ASM) you would have to increase both, which is possible
on a BIG-IP Virtual Edition, but not on an appliance. Also note, the Disk space
allocated by provisioning is disk space outside of the boot volume.
237
K33265170: DELETING A BOOT LOCATION VOLUME TO FREE UP DISK SPACE
While the disk may show as full, this doesn't mean the space is occupied. It shows reservation for disk.
• K09538906: Disk Management Storage look full on GUI
238 | ©2019 F5
As stated earlier, you can create as many boot volumes as the disk space
allows. But you made need to delete boot volumes to free up disk space for
other purposes.
238
Determine Disk utilization and Memory utilization
K14403: MAINTAINING DISK SPACE ON THE BIG-IP SYSTEM
[root@bigip01:Active:Disconnected] config # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/vg--db--vda-set.1.root
427M 274M 131M 68% /
none 3.9G 2.3M 3.9G 1% /dev/shm
/dev/mapper/vg--db--vda-set.1._config
3.2G 87M 2.9G 3% /config
/dev/mapper/vg--db--vda-set.1._usr
4.0G 3.2G 655M 83% /usr
/dev/mapper/vg--db--vda-set.1._var
3.0G 792M 2.1G 28% /var
/dev/mapper/vg--db--vda-dat.share
20G 306M 19G 2% /shared
/dev/mapper/vg--db--vda-dat.log
2.9G 106M 2.7G 4% /var/log
/dev/mapper/vg--db--vda-dat.appdata
25G 190M 24G 1% /appdata
none 3.9G 35M 3.9G 1% /shared/rrd.1.2
none 3.9G 16M 3.9G 1% /var/tmstat
none 3.9G 1.6M 3.9G 1% /var/run
prompt 4.0M 28K 4.0M 1% /var/prompt
none 3.9G 0 3.9G 0% /var/loipc
239 | ©2019 F5
You can get a more detailed information with a “df –h” or “df –a” at the bash
prompt.
239
Performance Statistics
On the Statistics >> Performance page you can find:

• Memory Used
• System CPU Usage
• Active Connections and Total New Connections
• Throughput - (bits) and (packets)
• TMM Client-side and Server-side Throughput
• HTTP Requests
• RAM Cache Utilization
• SSL Transactions
• And more ……….
In TMSH, show /sys performance all-stats
240 | ©2019 F5
On the Statistics >> Performance page you can find a lot of statistical
information useful in capacity planning and troubleshooting.
F5 Agility 2016 240

K7318: Overview of the bigtop utility
QUERYING... | bytes since | bytes in prior | current
| Sep 3 17:36:53 | 0 seconds | time
BIG-IP ACTIVE |---In----Out---Conn-|---In----Out---Conn-| 08:15:43
bigip01.f5demo.com 26.97M 348.1M 57090 0 0 0
VIRTUAL ip:port |---In----Out---Conn-|---In----Out---Conn-|-Nodes Up--

/Common/10.1.10.100:http 144980 3.046M 56 0 0 0 3
/Common/10.1.10.30:https 108722 2.243M 21 0 0 0 1
/Common/10.1.10.100:ftp 186 244 1 0 0 0 1
/Common/10.1.10.105:http 0 0 0 0 0 0 0
/Common/10.1.10.30:http 0 0 0 0 0 0 0
/Common/10.1.10.35:http 0 0 0 0 0 0 1
NODE ip:port |---In----Out---Conn-|---In----Out---Conn-|--State----

/Common/10.1.20.11:http 56494 1.449M 19 0 0 19 UP
/Common/10.1.20.13:http 58993 1.438M 18 0 0 18 UP
/Common/10.1.20.30:http 52867 1.399M 9 0 0 9 UP
/Common/10.1.20.12:http 53905 806996 19 0 0 19 UP
/Common/10.1.20.11:ftp 222 244 1 0 0 1 UP
/Common/10.1.20.14:http 0 0 0 0 0 0 DOWN
241 | ©2019 F5
The bigtop tool is a command line utility that displays real-time statistical
information for BIG-IP LTM system objects such as virtual servers and nodes.
The display can be customized for different types of information
241
Topic Resources
• Manual Chapter : Managing Configuration Synchronization
• K39735803: When to perform a manual ConfigSync
• K81160517: Modifying the ConfigSync time threshold
• F5 YouTube: Performing a ConfigSync using the Configuration utility
• K14856: Performing a ConfigSync using tmsh
• K13946: Troubleshooting ConfigSync and device service clustering issues
• Manual : BIG-IP Device Service Clustering: Administration
• Manual Chapter : Managing Device Trust
242 | ©2019 F5
242
Use support resources
Objectives 5.01 - 5.05
243 | ©2019 F5
243
5.01
Define characteristics of a support ticket with F5
• List severity levels of a support ticket with F5
• List what to include in a support ticket with F5
• List ways to open support ticket with F5
• List where to open a support ticket with F5
244 | ©2019 F5
244
The following slides are based* on v13.1
for more current support procedures see:
K2633: Instructions for submitting a

support case to F5
* To the best of my knowledge and research. Though most things have remained the same (ie.
What to include in a support case), some things have changed slightly (ie. The web site for opening
and viewing cases).
245 | ©2019 F5
These slides are based on the 13.1 release and what we’re support
requirements at the time. The requirements may be different today, but you're
being tested on what was required then. As far as we can tell, from old
documentation, this is what you will be tested on. For instance, the response
times for Sev2 cases have changed slightly and there are some differences on
the web support site.
245
5.01 List severity levels of a support ticket with F5
K2633: INSTRUCTIONS FOR SUBMITTING A SUPPORT CASE TO F5
Sev1 –Site Down
• Software or hardware conditions on your F5 device are preventing the
execution of critical business activities. The device will not power up or is not
passing traffic
• 1 hour Initial Response
Sev2 – Site at Risk
• Software or hardware conditions on your F5 device are preventing or
significantly impairing high level commerce or business activities. The device
is in degraded state that places your network or commerce at risk.
• 2 hour Initial Response
Sev3 – Performance Degraded
• Software or hardware conditions on your F5 device have degraded service
or functionality for normal business or commerce activities. Network traffic
through the device is causing some applications to be unreachable, or
operate in a diminished capacity.
• 4 Business Hours Initial Response**
Sev4 - General Assistance
• Questions regarding configurations “how to”. Troubleshooting non-critical
issue or requests for product functionality that is not currently part of the
current product feature set.
• Next Business Day Initial Response
246 | ©2019 F5
The severity levels are pretty self explanatory and, unfortunately, easily
interpreted a dozen different ways by a dozen different people as to how critical
something is. When taking the exam and asked to determine the severity level
it will probably be best to determine the level that matches the Severity
description most literally.
246
Case Severity Definitions & Target Response Time
NOTE: It is recommended all Sev1 cases be opened with a Technical Support Coordinator (TSC) via telephone.
• This will ensure the most immediate response to your issue
Initial Response
• is defined as the time from when the F5 case was created to when a Network Support Engineer (NSE) first
attempts to contact the end-user for troubleshooting and updates the case log reflecting this action.
• NOT WHEN THEY START FIXING THE PROBLEM
Premium Support is based on a 24 hour clock.
Standard Support is based on business hours

• (8am-6pm, local time to the unit)
247 | ©2019 F5
247
5.01 List what to include in a support ticket with F5
Field Data Required
Name The technical contact for this case
Contact Cell (Mobile) phone or Desk phone
F5 Serial # Required to obtain assistance
F5 Product Platform – i.e., 1600, 3600, 8900, VE, BIGIQ, etc
F5 Version Version (and any hot fixes already applied)
Business
The criticality of this issue on your business
Impact
Provide as complete a problem statement as possible:
• What has happened?
• Are there error messages? What are they?
• When did the issue happen, where did it
Description happen?
• What changes have occurred in the
configuration?
• What changes have occurred in the network?
• Is the issue happening on other F5 appliances?
Instructions If you are able to replicate, please provide step-by-step K2486: Providing files to F5 Support
to replicate instructions
Remote Is it possible to access this unit directly?

Access Is it possible to access this unit via a WebEX session?
248 | ©2019 F5
Information
Getting the Support group all the information and a detail description of the
issue is a must and will ensure the best customer satisfaction. I literally has a
customer call in a Sev 2 case and in the Description put “Application is running
slow and we need to prove it’s not the F5”. Which is neither informative or
helpful. And, just so you know, it wasn’t the BIG-IP. So, understand the
information to be included in a support ticket and also understand what files you
will need to provide.
You will always, ALWAYS, need to provide a qkview which is a package of

relevant information on the BIG-IPs, like configuration files, log files, etc. The
sooner you get a qkview to support the better. The qkview view only provides
the current (daily) log files, support may ask to the archived log files also.
Support may also ask for a TCPDump of the relevant traffic. And, if you are
requesting an RMA, support will require you to perform an End-User-Diagnostic
(EUD) and return the results.
248
5.01 List ways and where to open a support ticket with F5
You can open a case by phone.
You can open a case by going to https://websupport.f5.com

• (or by selecting MySupport on AskF5.com post v13.1)
− The same general flow applies today
You must meet the following prerequisites:

• You have a serial number with an active support contract.
• You have a web support account with permissions for the
affected device.
• You have a problem or question that was not resolved
when searching AskF5
249 | ©2019 F5
You can not only open cases by phone, but you can also open and review
support cases via the web support site. Although the web support site is now
access via AskF5 (https://support.f5.com) you can still access it via
https://websupport.f5.com which was available at the time the exam was
written. To open a web support case or be allow access to the system, you
must have a serial number of a device with an active support contract. Once
you have access to the web support site you will have the ability to open cases
for all other BIG-IP devices under the same contract. If you have device under
multiple contracts or with multiple customers, then you will have to have be
attached to each of those contracts.
249
Websupport (v13.1)
Have your serial number ready
• K3782: Finding the serial number or registration key of your BIG-IP system
250 | ©2019 F5
Have your serial number ready. Serial numbers can be found in the license
file, /config/bigip.license, via TMSH, and on the chassis for appliances.
250
Once your case is open (v.13.1)
It’s time to upload your files
251 | ©2019 F5
Once you have your case created, upload the files you think support will need.
This will save you time and unnecessary correspondence.
251
Review your case at any time (v13.1)
252 | ©2019 F5
252
My General Guidelines
NOT ON THE TEST
We are not perfect, but a few steps can expedite/ease the process
• Open a Web Support case first
• Create and upload a QKView, support will ALWAYS want a QKView
• Upload a packet capture if possible.
• If it is a Sev 1 or Sev 2 call Support! Now you have something to start with…
• If Support asks for something get them the information ASAP
− They can’t resolve your problem without information
− I have customers complain about slow support when Support asked them for a QKView days earlier
• Give Support as much information as possible

− Customer: Can you expedite, we need an RMA, and Support wants an EUD
− Me: I see you haven’t sent the EUD. Why?
− Customer: The box won’t power up.
− Me: Have you mentioned that to Support?
− Customer: No.
− Me: Please call Support and let them know
− Customer (later): We called Support, they are sending us an RMA immediately
253 | ©2019 F5
253
5.01 Resources
• K2633: Instructions for submitting a support case to F5
• K3782: Finding the serial number or registration key of your BIG-IP system
• K23150073: Reopening a recently closed support case
• K16022: Opening a proactive service request with F5 Support
254 | ©2019 F5
©
2016
254
5.03
Apply procedural concepts required to perform an End User
Diagnostic (EUD)
• Understand requirements of EUD
• Understand impact of running EUD
• Identify methods of booting the EUD
• Understand how to collect EUD output (console/log)
255 | ©2019 F5
I really don’t expect you would see more than one EUD question on the test, but
you should be familiar with EUDs and how they function. It may be the one
question you need.
255
5.03 Understand requirements of EUD
MANUAL CHAPTER : THE END-USER DIAGNOSTIC EUD
MANUAL CHAPTER: RUNNING THE EUD TESTS
The End-User Diagnostic (EUD) is a compilation of tests for checking the integrity of F5® hardware.
• The EUD exists independently from the host software and is available as a separate download.
• You should run the EUD only when you are advised to by your F5 Support representative.
CAUTION:
• Before you run these tests, you should disconnect all network cables from the system. Any cables connected to the system during the
tests could cause false-positive results.
• On the VIPRION® platform, you can only run one instance of the EUD at a time. You cannot start multiple instances in the chassis.
• On the VIPRION platform, you must only run the EUD from the local console of the blade being tested.
Important:
• Before you run any EUD tests, you must download and install the latest EUD software version for your platform.
− To determine EUD Version and the linux command prompt type: eud_info
− Downloading the EUD Files
256 | ©2019 F5
EUDs test the hardware components of BIG-IP appliances. They will always be
required before an RMA can be completed, assuming the BIG-IP appliance will
power up. EUDs are incredibly disruptive and should never be run on a
production system that is processing traffic. The latest version of the EUD
software for the appliance should be running on the platform to be tested.
256
5.03 Identify methods of booting the EUD
MANUAL CHAPTER : VERIFYING INSTALLING AND LOADING THE EUD FILES
Boot the EUD from a USB flash drive
• Plug your EUD USB flash drive into the system, and boot to the EUD.
Boot the EUD from a USB DVD drive
• Plug your USB DVD drive into the system, and boot to the EUD.
Run the EUD from the system boot menu
• As the system is booting, select the EUD option from the boot menu.
• As the unit boots, it pauses briefly on the boot menu. Use the arrow keys to highlight End User Diagnostics.
257 | ©2019 F5
EUDs can be run from bootable USB drives or USB DVD drives with the
appropriate software. Instructions are how to build the USB or DVD or
upgrading to the latest version can be found in the manuals on AskF5. An
EUD can also be initiated when a system is booted. The system will pause
briefly and display the boot volumes available and the EUD.
257
5.03 Understand impact of running EUD
MANUAL CHAPTER : THE END-USER DIAGNOSTIC EUD
CAUTION:
You should not run these test tools on a system that is actively processing traffic in a production environment.
These tests stop the unit and prevent it from processing traffic.
Run this tool only if you are instructed to by an F5® Support representative or if you are verifying a hardware issue
with a unit that is already removed from production.
You WILL have to reboot the unit.
You may have to power cycle the unit
258 | ©2019 F5
258
5.03 Understand how to collect EUD output (console/log)
MANUAL CHAPTER : EUD TESTS
To collect EUD results, from the EUD menu select:
• D Display Test Report Log

• The report log is stored as the text file /shared/log/eud.log in the host file system.
• Important: You must run eud_log from the command line to create output for this report.
• S Display Test Summary

• This option displays a test summary report that contains the results of all tests run during a test session.
259 | ©2019 F5
There isn’t a whole lot for you to interpret from a EUD as it will basically passed
or fail, but there is plenty for support to look at and that is why you may need to
obtain the eud.log file in the /share/log/ directory.
Note: The /share directory structure is shared by ALL boot volumes, so the files
residing in /shared directory are always available. For example, downloaded
software images reside in the /shared/images directory.
259
Topic Resources
• Manual Chapter : The End-User Diagnostic EUD
• Manual Chapter: Running the EUD Tests
• Manual Chapter : Verifying Installing and Loading the EUD Files
• Manual Chapter : The End-User Diagnostic EUD
• Manual Chapter : EUD Tests
• Downloading the EUD Files
• Field Testing F5 Hardware: iSeries Platforms
260 | ©2019 F5
260
5.04
Apply procedural concepts required to generate a qkview and collect
results from iHealth
• Identify methods of running qkview
• Identify method of retrieving qkview
• Understand information contained in qkview
• Identify when appropriate to run qkview
• Understand where to upload qkview (iHealth)
261 | ©2019 F5
261
F5 Free Training: Getting Started with BIG-IP iHealth
This course is intended to help you get started using BIG-IP iHealth as an online diagnostic tool. You’ll learn how
to leverage this tool to proactively maintain and more quickly troubleshoot your BIG-IP systems. The course
describes how BIG-IP iHealth Diagnostics evolved from an internal tool into a free, online tool available to F5
customers. It explains the four-step process to generate iHealth Diagnostics and introduces iHealth reports. The
remainder of the course describes how to use iHealth to identify security vulnerabilities and performance issues,
prepare to upgrade your system, and leverage iHealth to troubleshoot system configuration issues and ensure
your hardware platform is running at peak performance. The course is based on user-centered simulations and
will take 15 minutes to complete.
Launch: Getting Started with BIG-IP iHealth
262 | ©2019 F5
You should run through this training, available from F5, prior to taking the exam.
262
5.04 Identify methods of running and retrieving qkview
K12878: GENERATING DIAGNOSTIC DATA USING THE QKVIEW UTILITY
Go to the Getting Started training
• F5 Free Training: Getting Started with BIG-IP iHealth

− Running the qkview utility from the Configuration utility (BIG-IP)
− Running the qkview utility from the command line (BIG-IP or BIG-IQ)
263 | ©2019 F5
Once again, this training will help you under the requirements for the exam.
263
5.04 Understand information contained in qkview
In general a qkview contains everything support might need for diagnosing issues:
• Statistics
• Log files
• /config directory
• /etc directory
• Performance graph rrd data
• Other miscellaneous configurations files
Potential sensitive data is excluded
264 | ©2019 F5
As I stated earlier, a qkview contains base information needed to troubleshoot

BIG-IP issues or investigate problems with performance. Configuration items of
a sensitive nature, like certificates, are excluded.
264
5.04 Identify when appropriate to run qkview
Always when opening a support case
Whenever you want to run iHeath against you BIG-IP
265 | ©2019 F5
265
5.04 Understand where to upload qkview (iHealth)
266 | ©2019 F5
266
5.05
Identify which online support resource/tool to use
• DevCentral
• AskF5.com
• iHealth
• Support Portal
267 | ©2019 F5
267
5.05 DevCentral
K20452352: F5 OPERATIONS GUIDES | OPTIMIZING THE SUPPORT EXPERIENCE
DevCentral (devcentral.f5.com) is an online forum of F5 employees and customers that provides technical
documentation, discussion forums, blogs, media and more, related to application delivery networking. DevCentral is a
resource for education and advice on F5 technologies and is especially helpful for iRules and iApps developers.
If you become a DevCentral member, you can do the following:

• Ask forum questions
• Rate and comment on content
• Contribute to wikis
• Download lab projects
• Join community interest groups
• Solve problems and search for information
• Attend online community events
• View educational videos
268 | ©2019 F5
268
5.05 AskF5.com
AskF5 (support.f5.com) is a great resource for thousands of articles and other documents to help you manage your F5 products more effectively.
Step-by-step instructions, downloads, and links to additional resources give you the means to solve known issues quickly and without delay, and to
address potential issues before they become reality.
Whether you want to search the knowledge base to research an issue, or you need the most recent news on your F5 products, AskF5 is your source
for product manuals, operations guides, and release notes, including the following:
• F5 announcements
• Known issues
• Security advisories
• Recommended practices
• Troubleshooting tips
• How-to documents
• Changes in behavior
• Diagnostic and firmware upgrades
• Hotfix informationProduct life cycle information
269 | ©2019 F5
269
5.05 iHealth
iHealth
This has already been covered in the previous section.
270 | ©2019 F5
270
5.05 Support Portal
AskF5
And this too…
271 | ©2019 F5
271
Topic Resources
• K20452352: F5 operations guides | Optimizing the support experience
• DevCentral
• AskF5
• iHealth
• AskF5
272 | ©2019 F5
272
LAB 3 - Administering the System Configuration
Performance Statistics
Self IP Port Lockdown and more
System Configuration
UCS (BIG-IP Archive) and Support
Maintaining the Device Service Cluster (DSC)
273 | ©2019 F5
273
Lab 4 – Challenge Labs
Modify and Troubleshoot Virtual Servers
Upgrading a BIG-IP Device Service Clusters (DSC)
iApps and Analytics
274 | ©2019 F5
274
F5 Learning: Getting Started with BIG-IP
This course is divided into two modules:
The Administration module focuses on basic administrative activities on the BIG-IP system. You’ll learn how to
activate a new BIG-IP system for operation, including configuring the management port, licensing, provisioning, and
basic network configuration. You’ll learn how to archive the BIG-IP configuration in support of data center backup
and recovery activities. Finally, you’ll learn how to verify the proper operation of your BIG-IP system by using the
online BIG-IP iHealth® diagnostic tool.
Launch: Getting Started with BIG-IP Part 1: Administration
Demo: Setup Utility
The Application Delivery module focuses on the basic building blocks of BIG-IP configuration in support of
application delivery including nodes, pools and pool members, virtual servers, monitors, and profiles. You’ll learn how
to configure a basic web application that is delivered through the BIG-IP system, and includes round robin load
balancing, HTTP application health monitoring, overcoming routing issues with SNATs, and SSL offload (client SSL
termination). You’ll also learn how to review the flow of application traffic through the BIG-IP system using local traffic
statistics.
Launch: Getting Started with BIG-IP Part 2: Application Delivery

Demo: Application Delivery
To access Getting Started Virtual Labs, please login or create an account in the new LearnF5, then search for
"Getting Started with BIG-IP".
275 | ©2019 F5
275
F5 Free Training: Getting Started with BIG-IP Local Traffic Manager (LTM)
This course is divided into four modules that are presented in two separate WBTs. The topics presented are organized
around a customer scenario that takes an organization’s globally expanding e-commerce site from a single server to
multiple load balanced back end servers behind a pair of BIG-IP LTM systems. You’ll learn how to implement the high
availability feature to establish an active/standby device service cluster. You’ll learn how to load balance web application
traffic across a pool of non-homogenous servers. You’ll learn how to use an iRule to customize traffic flow, selecting the
appropriate pool of back end servers based on the client’s preferred content language. And finally, you’ll learn how to
decrease existing server load reducing concurrent connections and connection rates using OneConnect.
Launch: Getting Started with LTM Part 1: HA and Traffic Processing
Demo: Configure High Availability
Launch: Getting Started with LTM Part 2: iRules and OneConnect
Demo: iRules
276 | ©2019 F5
276
This course is intended to help you get started using BIG-IP iHealth as an online diagnostic tool. You’ll learn how
to leverage this tool to proactively maintain and more quickly troubleshoot your BIG-IP systems. The course
describes how BIG-IP iHealth Diagnostics evolved from an internal tool into a free, online tool available to F5
customers. It explains the four-step process to generate iHealth Diagnostics and introduces iHealth reports. The
remainder of the course describes how to use iHealth to identify security vulnerabilities and performance issues,
prepare to upgrade your system, and leverage iHealth to troubleshoot system configuration issues and ensure
your hardware platform is running at peak performance. The course is based on user-centered simulations and
will take 15 minutes to complete.
Launch: Getting Started with BIG-IP iHealth
277 | ©2019 F5
277
278

F5 201 v13.1 Certification Prep V3a - With Slide Notes

Uploaded by

Copyright:

Available Formats

You might also like

F5 201 v13.1 Certification Prep V3a - With Slide Notes

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

F5 201 v13.1 Certification Prep V3a - With Slide Notes

Uploaded by

Copyright:

Available Formats

F5 201 v13.

LEIF RASMUSSEN, SR SOLUTIONS ENGINEER – CHANNELS

UPDATED: 13 AUG 2020

If you are almost ready, then it is an opportunity for

We will not cover every topic in depth

This isn’t a course to teach you how to configure a BIG-IP

TMOS Administration 201 Future Exams Pre-Sales Fundamentals 202

• All Certs/Exams are good for 2 years

*Secure Sauce (exam tips) at the end of the presentation!

- After first failure, you must wait 15 days to re-test

- After second failure, you must wait 30 days to re-test

- After third failure, you must wait 45 days to re-test

- After fourth failure, you must wait 1 calendar year to re-test

- 5th and subsequent failed attempts, you must wait 90 days

What is the F5 retake policy?

• Online exam study guides found here:

F5 Certified Professionals https://www.linkedin.com/groups/85832

- Give a shout-out to Eric Mitchell!

This is a direct link to the PDF

This class/presentation content:

Manual : BIG-IP Local Traffic Management: Basics

Manual : BIG-IP TMOS: Routing Administration

• Explain the dependencies of interfaces/trunks, vlans, self-IPs

• Compare Interface status (Up/Down)

• Illustrate the use of a trunk in a BIG-IP solution

• Demonstrate ability to assign VLAN to interface and/or trunk

• Distinguish between tagged vs untagged VLAN

• Identify, based on traffic, which VLAN/route/egress IP would be used

0. Configuring the out-of-band management interface (eth0) on the control plane

1. Set up Interfaces and Trunks (L1)

2. Assign interfaces and trunks to VLANs (L2)

3. Assign Self IPs to VLANs (L3)

4. Set up Default Gateway

• Networking Elements are found on the sidebar

As soon as the cable connection is performed on a physical BIG-IP device, the

• Drops – number of packets drop for

• Collisions – should only occur on half-

When does the configuration get written to disk?

A trunk is a logical grouping of interfaces on the BIG-IP® system.

• This is logical group of interfaces functioning as a single interface.

The purpose of a trunk is two-fold:

• To increase bandwidth without upgrading hardware

<intentionally left blank>

Place interfaces and trunks into the Untagged or Tagged boxes

Untagged interfaces do not require a Tag be entered

• The BIG-IP will assign a Tag to logically separate internal traffic

Tagged interfaces run 802.1q VLAN tagging

• You need to manually enter the tag

This is pretty simple. In the GUI:

net vlan ha_vlan { -------------------------------------

A self IP address is associated with a VLAN, to access hosts in that VLAN.

• The netmask of a self IP address represents an address space

Self IP addresses serve two purposes:

<intentionally left blank>

• A floating self IP address is an IP address that two BIG-IP systems share.

<intentionally left blank>

• Interpret availability status of interfaces

• Identify Speed and Duplex