# clsh tmsh show sys hardware | grep 'Host Board Serial'
The above command is run from bash shell on the F5 in order to identify the serial number of all the blades in an F5 Viprion device.
# tmsh show sys hardware | grep 'Chassis Serial'
The above command is run from bash shell on the F5 in order to identify the serial number of the chassis in an F5 Viprion device.
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.
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 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.
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:
(/Common)(tmos)# show sys software
(/Common)(tmos)# show gtm server | grep -e "Gtm::" -e "Availability" -e "State"
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.
This is a short list of commonly available network troubleshooting tools that has been of use to me:
- Error logs on the device.
- Developer tools within a browser like Chrome/FF.
A simple way to clear the contents of ssh key file without deleting the file:
echo -n > /home/user/.ssh/known_hosts
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:
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.
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
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.
$ cat ansible.cfg
hostfile = ./hosts
host_key_checking = False
timeout = 5
log_path = ./logfile.txt
forks = 50
gathering = smart
pipelining = True
The above file shows the content of ansible.cfg file. I have added the following to make my playbook run faster:
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.