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 [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.
While using Ansible 2.2 and Python 3.x, I ran into the following error:
ERROR! Unexpected Exception: No module named 'urlparse'
1. Downgrade Python to 2.x
2. If there is no root level permission, use virtual env:
I have utilized the following steps to install terraform in Ubuntu 16.04
Download Terraform for Linux 64 bit version.
Save the downloaded version in a specific folder. (Example: /home/user/terra)
Within the folder where the downloaded version is saved, use “unzip” command:
Set the path: