Posted on

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.

Posted on

Network Troubleshooting Tools

This is a short list of commonly available network troubleshooting tools that has been of use to me:

  1. Ping.
  2. traceroute.
  3. nslookup/dig
  4. curl.
  5. Error logs on the device.
  6. tcpdump.
  7. Developer tools within a browser like Chrome/FF.
  8. Wireshark.

 

 

Posted on

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.

 

Posted on

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

Posted on

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

Posted on

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.

Posted on

Ansible & Python 3

While using Ansible 2.2 and Python 3.x, I ran into the following error:

ERROR! Unexpected Exception: No module named 'urlparse'

Workaround: 

1. Downgrade Python to 2.x

2. If there is no root level permission, use virtual env:

virtualenv --python=python2.7
Posted on

iRule HTTP Referer

This is a simple iRule that performs redirects based on HTTP Referer:

when HTTP_REQUEST { 
if { ([HTTP::header exists "Referer"]) and 
    ([URI::host [HTTP::header value Referer]] eq"special.com") } {
HTTP::redirect https://www.site.com/special-client/
} else {
HTTP::redirect https://www.site.com/generic-client
}
}