F5 – RST or ICMP Packet Rate

You can follow SOL13151 in order to increase the packets/sec value. However, I would caution against doing it or at least recommend keeping the value smaller. The default setting is in place to prevent the F5 from overwhelming its resources by sending out RST. This could potentially end up being a self-inflicted DoS. So, either don’t change the value or increase the value in minimal steps like +50 to 300 packets/sec.

tmsh
modify sys db tm.maxrejectrate value 300
save sys config

You may have to use SOL13223 in order to identify the reason for RST. SOL9812 provides reasons for which the F5 sends RST.

In order to understand which monitor is marking the pool member down, see this SOL13898. If you are using 11.4 and after code version, the monitor that triggered the failure should be auto-displayed as per K14407

K12531 is a good reference for troubleshooting monitors in F5.

F5 iControl REST

F5 utilizes iControl REST API as part of their automation toolkit. REST API is a powerful way to automate F5 management. iControl REST API was introduced by F5 in 11.5 code version. 11.6 code version is the first major code version with a relatively stable release. However, 11.6 does not support remote authentication like TACACS+. For iControl REST API with remove authentication, it is important to utilize 12.x code version. F5 programmability training documentation and related information are available here.

GTM Code Upgrade

These are a few quick checks as part of the GTM code upgrade maintenance that will be useful.  As part of the maintenance preparatory work, check the license “service check date” as per K7727

Before starting the code upgrade and after the code upgrade, the following can be utilized to check the status of the devices:

From tmsh:

(/Common)(tmos)# show sys software
(/Common)(tmos)# show gtm server | grep -e "Gtm::" -e "Availability" -e "State"

From bash:

/shared/bin/big3d –v

From another client machine:

dig @<GTM1_IP> <WIP_FQDN>
dig @<GTM2_IP> <WIP_FQDN>

Just after the code is upgraded, make sure to run the big3d_install commands as per K13312. This will help to make sure that all the devices run the latest big3d version.

Basic VTP

VTP stands for VLAN Trunk Protocol.  VTP is used to propagate VLAN cconfiguration. VTP advertisements are multicasted. They are sent every 5 minutes or whenever there is a change in VLAN configuration. VTP revision number is included in these advertisements. Whenever a client receives a VTP advertisement with a higher revision number, the client will update its vlan configuration with the vlan information being advertised.

There are 3 modes:

  1. Server
  2. Client
  3. Transparent

VLAN cannot be edited on a switch operating as a client.

VLAN can be edited on a switch operating as a server. This information is propagated to the switches operating as clients.

VLAN can be edited on a switch operating in transparent mode. However, these changes are not propagated. Switches operating in transparent mode do not update their configuration based on advertisements from the switch operating in server mode. All change are local for a switch operating in transparent mode.

 

Basic DHCP Configuration

This is a simple DHCP configuration on a Layer 3 Switch:

SW1(config)# ip dhcp excluded-address 10.10.10.1

SW1(config)# ip dhcp pool VLAN20POOL

SW1(dhcp-config)# network 10.10.10.0 255.255.255.0

SW1(dhcp-config)# default-router 10.10.10.1

SW1(dhcp-config)# lease 2

Lease is in hours. Default-router IP indicates the default hop for the 10.10.10.0/24 network. The excluded-address will not be available to the DHCP client hosts.

DHCP negotiation utilizes the following DHCP messages:

DISCOVER – Broadcast – Client to Server

OFFER – Unicast – Server to Client

REQUEST – Broadcast – Client to Server

ACK – Unicast – Server to Client

F5 GTM – DNS Query Processing Order

When a DNS query arrives at a F5 GTM/DNS, this is the processing order for the DNS query.

1 – DNS Query is processed by the Listener.

2- If Recursion Desired (RD) flag is set in the incoming query and if the DNS Profile associated with the Listener has “Process Recursion Desired” enabled, the following is done:

a. DNS iRule

b. DNSSEC Key Processing

c. DNS Express

d. DNS Profiles

3 – If Recursion Desired (RD) flag is set in the incoming query and if the DNS Profile associated with the Listener has “Process Recursion Desired” disabled, the query is considered “Un-handled” and dispatched according to “Unhanded Query Action” set in DNS Profile.

4 – DNS Cache is used to handle any DNS query that doesn’t match Big-IP GTM/DNS or DNS Express Records.

Reference: K14510

Ansible Playbook Optimizing

$ cat ansible.cfg 
[defaults]
hostfile = ./hosts
host_key_checking = False
timeout = 5 
log_path = ./logfile.txt
forks = 50
gathering = smart

[ssh_connection]
pipelining = True

The above file shows the content of ansible.cfg file. I have added the following to make my playbook run faster:

forks
gathering
pipelining

Forks indicate the number of parallel processes spawned to communicate with remote hosts. Default forks is 5 in Ansible.

Gathering indicates the default policy for fact gathering. When “gather_facts” is True within the playbook, facts are gathered for each host. The facts associated with each host will be discovered only once even when the host is referred in multiple plays when we use “smart” within the ansible.cfg file.

Pipelining enabled will reduce the number of SSH operations required to execute a module on a remote host.