CHAPTER 4 – Introduction to LTM – Initial Access & Installation

1. License key is 27 character long stored in /config/RegKey.license file.

2. Once the license has been installed it is stored in the /config/bigip.license file.

3. Dossier is generated in “dossier.do” file.

4. Default management port IP address – 192.168.1.245/24

5. We can assign 5 resource level to any module that is provisioned

a. Dedicated – when only one module is provisioned
b. Nominal – this will give minimum resource to the module, if some resource is spare, it will be given
to this module
c. Minimum - this will give minimum resource to the module, if some resource is spare, it will be given
to other modules.
d. None – similar to the module is turned off or not provisioned at all
e. Lite – this is used for selected modules for trial purposes.

CHAPTER 8 – Profiles
1. Compression profile is used at client side.

2. The default profiles are stored in /config/profiles_base.conf.

CHAPTER 9 – Persistence
1. Source Address – Persists connections based on the source IP address or subnet.
Persistence record consists of:
- Persistence value – IP address or subnet it applied to
- Persistence mode – Method like source or cookie
- Virtual server persistence is applied to
- Pool name that the pool member is the part of
- Pool member details like IP and port
- Age of persistence record or timeout value.

2. Cookie – uses a cookie stored on the client.

a. Cookie insert – BIG-IP inserts a Set-cookie header into the HTTP response. Always send cookie
option is used when we set cookie expiration time and we need BIG-IP to send cookie everytime
the connection is made.
b. Cookie Rewrite – this method intercepts the Set-Cookie header and then overwrites the cookie
name and value. The pool member inserts the empty cookie into the HTTP response, the BIG-IP
intercepts the cookie and modifies it before sending it to the client
 c. Cookie Passive – BIG-IP system don’t insert the cookie, the pool member or the end server will
insert the cookie with pool members details and BIG-IP will simply pass it on to the client.
d. Cookie Hash – The pool member inserts the cookie, BIG-IP parses it and applies a configured hash
offset to create a has value that will be stored in the persistence table. This is the only cookie
method that creates record in the system.

3. Destination Address – All request from any client to a specific destination address is directed to the
same pool member.

4. Hash – It uses an iRule or profile to find one or more values in the request/response and generates a
hash based on this. The values could be source IP, destination IP, port etc. iRule is mandatory for this. It
does not create any persistence record.

5. Microsoft RDP – based on the unique remote desktop session identifier within a packet. Independent
on source IP.

6. SIP – based on the session initiation protocol (SIP), session ID is used between client and the pool
member. Independent on source IP.

7. SSL – Based on SSL/TLS session ID between client and BIG-IP or between client and pool member.
Independent on source IP.

8. Universal – similar to Hash method but it does not create hash, instead it use the actual value in the
request/response. It uses an iRule to locate this unique value like cookie value, string, URI etc.

9.
CHAPTER 13 – The Traffic Management Shell (TMSH)
6. Hierarchical structure of TMSH
a. TMOS – highest level of hierarchy referred to as the root
b. Modules- underneath the TMOS examples GTM, LTM, ASM, net, cm sys
c. Submodules – like profiles, monitors are submodules of LTM module
d. Components – bottom most of the hierarchy. Node, pool, VIP, self IP etc

7. On BIG-IP, the configuration is stored in 3 different states

a. The text configuration – contains all the changes saved by the BIG-IP. The files are bigip.conf and
bigip_base.conf
b. The running configuration – contains the configuration stored in the text config and new changes
made after the last save. If you have unsaved config, it will lost if the system reboots
c. The binary configuration – starting with BIG-IP 9.4.0, when the system first boots up, the mcpd
process builds a binary configuration which creates the 2 files. It enables the system to save and
load the configuration from the storage instead of text config files, making the system startup fast
and efficient.
/var/db/mcpdb.bin
/var/db/mcpdb.info

8. Text configuration files

a. Bigip.conf – the file contains objects for managing local traffic including virtual servers, pools,
profiles, policies, SNATs and traffic group objects associations.
b. Bigip_base.conf – it contains the BIG-IP system specific configs such as network components, self
IPs, VLANs, interfaces, device trust certificates and traffic group associations. This file is not synced
between HA pairs
c. Bigip_gtm.conf – this includes unique GTM configuration such as servers, datacenters with their
respective virtual servers and wide IPs
d. Bigip_user.conf – this file contains all user roles on the bigip system.

9. It is possible to factory reset the device using the default configuration files located on the system. It is
stored in - /defaults/defaults.scf

10. In administrative partitions, the objects created in common partition can only be referenced to other
partitions. If an object is created in partition_1, it cannot be referenced to any other partition.

11. User Roles

Administrator All object, all partition, can change their own password
Resource Admin All object except user account, all partition, can change their own password
User manager Can manage all partition user accounts, modify, create, delete user and
password
Manager Create, modify, delete VS,pool, nodes iRules etc view all object, can change
own pwd
Certificate manager Can only manage device certificates and keys and FIPS
iRule manager Create, modify,delete iRules only. Cannot add them to VIP. Universal access to
admin
Application editor Modify monitors, pool, nodes and pool member
Acceleration policy Can manage all partition acceleration policies and profiles
editor
Firewall manager Can manage all firewall rules and policy
Web application Can manage only ASM security object, cannot manage HTTP or FTP
security
administrator
Application Security Can manage ASM module and not other BIG-IP objects.
editor
Fraud protection Grant permission to configure BIG-IP fraud protection service (FPS)
manager
Operator Grant permission to enable disable nodes and pool members. Can view all
objects and change their password
Auditor Read-only access, can view all config data, view logs and archives, cannot view
ssl keys and user passwords, access to all partitions
Guest Able to view all objects except archives and logs. Can change their own
passwords
No Access No access to BIG-IP
CHAPTER 15 – Selected Topics
1. AOM (Always on Management) – only available in physical devices, its purpose is to provide lights out
management and other basic supporting functions in BIG-IP system, accessible via HMS or through
serial console, it can also be accessed via SSH but must be assigned a sperate IP.

2. iRule scripts are based on TCL (Tool command language).

3. iRules are built upon following structure

a. when a specific event occurs (Event)
b. if the condition is true (Conditional Statement)
c. then perform the specified action (Action)

4. Operators
a. Logical operators – Not, And, Or
b. Relational operators – Contains, Matches, Equals, Starts_with, Ends_with, Matches_regex

5. Rule commands of an iRule causes the BIG-IP system to perform a specific action
a. Query commands – the query commands search for content and displays it. Ex. – IP::remote-
addr will search for the remote IP address and returns its value.
b. Action/modification commands – these commands will alter the traffic passing through system. Ex
– adding HTTP header into HTTP request.
c. Statement commands – It states where traffic should be sent whether pool, URL or HTTP
redirection.
d. Universal Inspection Engine (UIE) commands – it performs deep packet inspection and one of the
primary use is to return a string that can be used for persistence.

6. iRule events
a. CLIENT_ACCEPTED – This event will be triggered whenever the BIG-IP system receives a new entry
in its connection table. If it is TCP, it will trigger whenever TCP 3-way handshake is completed. For
UDP, the system creates a table entry for the first request and assigns a timeout value. If no
request arrives within timeout the entry will be removed and the event CLIENT_CLOSED will trigger.
If request arrived within timeout, it won’t issue new CLIENT_ACCEPTED.
b. CLIENT_DATA – for TCP, this will be triggered whenever data is received from the target node after
the TCP::collect command is issued. For UDP, this will be triggered every time the system receives a
segment.
c. HTTP_REQUEST – this will be triggered when system has fully parsed the complete HTTP request. It
will not process HTTP request body else will process all other details.
d. HTTP_REQUEST_DATA – this will only trigger whenever the command HTTP::collect has been used.
In HTTP::collect command, we specify how much data that should be collected. It will also be
triggered if client has terminate the session before HTTP::collect has finished fetching the data.
e. LB_SELECTED – it is triggered when LB has chosen a pool member.
f. SERVER_CONNECTED – it is triggered when the system established a connection with target node.
g. CLIENT_CLOSED – this is the last event, triggered when the connection is terminated.
CHAPTER 16 – Troubleshooting Hardware

1. EUD – End User Diagnostic is accessible via console only on system boot.

2. The menu has following options.

- System Report
- Sensor report
- SFP/XFP report
- LED test
- SCCP I2C test
- PCI test
- Quick system RAM test
- System RAM test
- LCD test
- Internal packet path test
- Internal loopback test
- PVA memory test
- SSL Test
- FIPS test
- Compression test
- SMART test
- File system check
- Run all test (no user intervention, Use normal RAM test)
- Run all test (need user intervention, use quick RAM test)
- Display test report log
- Quit EUD and reboot the system.

3. The EUD file after the test is created as eud.log and stored at /shared/log directory.

4. LED indicators – the legacy systems use 4 types of LED indicators.

a. Power – Solid Green – normal power, None – Power off, Solid red – standby power/failure
b. Status – Solid green – Active, solid yellow – standby
c. Activity – Flickering yellow – activity happening (Traffic processing)
d. Alarm – warning (0) – Solid yellow, Error (1) – blink yellow, Alert(2) – Solid red, critical (3) – solid
red, emergency (4) – blink red

5. All of the alerts are defined in the file /etc/alert/alert.conf

6. The file that UCS gather while performing backup is defined in /usr/libdata/configsync/cs.dat

7. To clear the warnings displayed on the LCD issue the command – “lcdwarn –c [level] [slotid].
Level=0/1/2/3/4/5, slotid = 0/1/2/3/4/5/6/7 (For VIPRION), 0 for others.

8. Flow control is the function responsible for adjusting at what rates the frames are sent between the
network devices by sending “pause frames”
a. Pause None – Disable flow control
b. Pause Tx/Rx – device will honor pause frames received from its peer, but it will also generate and
send pause frames to peers when necessary.
 c. Pause TX – Will ignore pause frames from peer but will generate pause frames and send to peer.
d. Pause RX – will receive pause frames from peer but not generate and send frames to peer.

9. The transparency mode setting specifies how the BIG-IP system forwards a message to a host in a
VLAN.
a. Translucent – layer 2 forwarding with locally unique bit
b. Transparent – layer 2 forwarding with the remote system’s original MAC address preserved across
VLANs.
c. Opaque – layer 3 forwarding with proxy ARP.
CHAPTER 17 – Troubleshooting Device Management Connectivity

1.
CHAPTER 18 – Troubleshooting & Managing Local Traffic

1. Order of operation once the packet arrived at BIG-IP

a. Packet filtering
- Enabled or not
- Are ruled applied to relevant VLAN or tunnel
- Is the unhandled packet action – accept, reject or discard
- Are there any MAC, VLAN or IP address exemption
b. DDoS functions
- Are packets malformed in some way
- Have SYN cookies been activated due to high connection rate
c. Established connections
- Packet processed based on the connection table entries and other features like persistence.
d. New Connections
- Is there a listener for the destination
- Listener enabled on correct vlan and tunnel
- Is source address allowed
- Is network protocol configured
- Is address and port translation enabled

2. Listener objects processing order:

a. Existing connection in connection table or persistence
b. Is the traffic allowed by packet filter rule (if enabled)
c. Virtual server
d. SNAT
e. NAT
f. Self IP
g. Drop

3. Virtual server priority

a. IP Address : Port
b. IP address : *
c. IP Network : Port
d. IP Network : *
e. * : Port
f. * : *

4. If a matching virtual server is down or disabled, any other low priority VS will not be selected. This
behavior can be changed by setting the BigDB TM.ContinueMatching variable to enable.

5. If traffic matches both a destination (VS, SNAT or NAT) and source listener (SNAT and NAT), the
destination listener will take precedence

6. Three different setups to configure SSL on BIG-IP

a. SSL Offloading – BIG-IP handles all the SSL connections. Traffic to pool members is unencrypted.
b. SSL Bridging – BIG-IP terminates the client SSL connection and establishes a new SSL connection to
pool members.
c. SSL Passthrough – BIG-IP simply forwards the SSL connection to the pool member.
7. There are 2 SSL stacks Cipher suits
a. NATIVE – Delivered with TMOS, optimized SSL stack that system can optimize using hardware
acceleration and recommended by F5, used by default by all SSL profiles
b. COMPAT – based on open SSL library, have to specify if to be used in SSL profile.

8. If a node or pool member is put into disabled mode, active and persistence connections are still
allowed.

9. If a node or pool member is put into forced offline mode, only active connections are allowed.

10. To configure the logging of statistics and the cause of TCP reset, we can use – “tmsh modify sys db
tm.rstcause.log value enable” command.
Chapter 21 - Identify and report current device status

1.
OTHERS
1. Below 3 methods can be used for initial access to a BIG-IP system.
a. CLI access to the serial console port
b. SSH access to the management port
c. HTTPS access to the management port

2. If a connection is made to virtual server using cookie persistence but client is not accepting the cookies,
then the request is normally load balanced instead of getting persisted.

3. The client address will be changed to the floating self IP address of the VLAN where the packet leaves
the system, when SNAT automap is defined within a Virtual Server configuration.

4. The SNAT must be enabled for the VLANs where desired packet arrived on the system.

5. A streaming profile will Search and replace all occurrences of a specified string in requests and
responses processed by a virtual server.

6. When DNS_REV is used as the probe protocol by the GTM System, The FQDN of the local DNS being
probed for metric information will be returned in the response from the probe.

7. The client IP address is unchanged between the client-side connection and the server-side connection
when no SNAT is enabled on the Virtual Server.

8. Ports
a. iQuery – 4353
b. Network failover – 1026
c. TCP mirroring port – v11.0.x to v11.3.x=1028, v11.4.x to v11.5.x=1029-1043, v11.6.x to
v13.x=1029-1155

9. File locations
i. QKview - /var/tmp
ii. Core file - /var/core
iii. When core file is generated, it is written to - /var/log/tmm
iv. Logs of packet filter - /var/log/pktfilter
v. DNS config - /etc/hosts
vi. HTTPD specific messages - /var/log/httpd/httpd_errors
vii. Linux specific boot messages - /var/log/bootlog
viii. Messages related to system daemons - /var/log/daemon.log
ix. Kernel messages - /var/log/kern.log
x. Messages related to user processes - /var/log/user.log
xi. SCF file - /var/local/scf
 xii. UCS file - /var/local/ucs
xiii. Files to be included in UCS is defined in - /usr/libdata/configsync/cs.dat
xiv. alerts are defined in the file - /etc/alert/alert.conf