Throughput

Consider a link between two routers with bandwidth of 1Gbps and RTT of 200ms.

The maximum throughput of the link is 1Gbps (Bandwidth). In a normal link, the throughput will be lower than the bandwidth because of overhead in transmission and loss.

Assuming there is zero loss in the network, the maximum possible window size in order to maximize the throughput is provided by the Bandwidth * Delay product (BDP).  This is also the buffer that is allocated on the client and server side for receiving data.  For a bandwidth of 1Gbps and 200ms RTT, the BDP is (10^8)*(0.2) = 20Mbit or 2.5MByte.

Throughput for a single TCP session is (Window Size / RTT). Assuming a window size of 60,000Byte, throughput will be (60,000/.2) = 300,000Byte/s or 2.4Mbps. Increasing the throughput for a TCP connection can be done increasing the window size by utilizing window scaling.

For a link with losses, maximum data throughput will be less than (MSS/RTT)*(1 / sqrt(p)), according to the Mathis formula. 

Max DATA throughput rate < (MSS/RTT)*(1 / sqrt(p))

In order to increase throughput for a single TCP connection, the window size and MSS can be increased, RTT can be lowered (CDN usage), reduce loss percentage (p) by using a reliable link.

Basics – IPSec VPN

The following article is a brief introduction to IPSec VPN that is utilized to provide a logical connection between 2 sites (Site to Site) or a client and a site (Client to Site). The article is written to provide the key terms behind IPSec VPN implementation in a Cisco ASA Firewall or any other similar device.

IPSec Virtual Private Network (VPN) provides the following services:

  1. Authentication
  2. Confidentiality
  3. Integrity
  4. Anti-Replay

Internet Security Association and Key Management Protocol (ISAKMP):

  1. ISAKMP is a Framework for secure communication channel.
  2. Specifies that authentication/keying should occur.
  3. Procedures to negotiate, establish, modify and delete Security Associations (SA).

ISAKMP is the framework and IKE is the actual implementation of ISAKMP framework.

Internet Key Exchange (IKE):

There are 2 main versions of IKE – IKEv1 and IKEv2. In this document, we will stick with IKEv1.   IKE runs over UDP 500 and consists of 2 Phases.IKE Phase I can utilize either one of 2 modes – Main or Aggressive mode in order to establish ISAKMP SA. IKE Phase II utilizes Quick Mode in order to establish IPSec SA.

Phase I:

Establish a secure communication channel (SA) through verification and authentication of peer.

The following is performed during Phase I:

  1. Encryption and hashing algorithm are negotiated.
  2. Session key parameters using Diffie-Hellman (DH) are negotiated.
  3. Negotiate authentication and peer is authenticated.
  4. ISAKMP SA is established in Phase I . Only one SA (bidirectional) is setup for Phase I.
  5. Two Modes possible in Phase I. Main mode & Aggressive mode.

Phase II:

  1. Establish IPSec SA and protect communication between peers for secure symmetric key distribution/data communications.
  2. Pre-shared keys, Public Key Signatures and RSA encryptions are different authentication methods used.
  3. Quick mode occurs during IPSec Phase II SA establishment.

Main Mode:

  1. Initiator peer sends acceptable encryption/authentication algorithm.
  2. Responder Peer chooses to accept or not accept the proposed encryption/authentication algorithm. If accepted, negotiation continues.
  3. Initiator sends key and nonces (anti-replay).
  4. Responder responds with it DH key and nonces.
  5. Initiator signature, ID & shared key/certificate.
  6. Responder responds with its signature, ID & shared key/certificate.

1-4 steps are unencrypted and in the clear. 5-6 steps happen after in an encrypted environment.

Aggressive Mode:

  1. Originator provides keys (pre-shared keys/certificate) IKE-ID, nonce and encryption/authentication proposal.
  2. Responding peer: Key exchange, IKE_ID, nonces, encryption/authentication.
  3. Originating signature, hash and IKE_ID

IKE Phase II:

  1. Security protocol (AH/ESP)
  2. Algorithms for encryption and hashing.
  3. Proxy ID (Subnets)
  4. Perfect Forwarding Secret (PFS) Support.

Quick Mode: Two IPSec SA created. One in each direction.

IPSec uses the following protocols to perform various functions:

  • Authentication Header (AH)
  • Encapsulating Security Payloads (ESP)
  • Security Associations (SA).

AH: IP protocol 50. Supports Authentication & Integrity.

ESP: IP Protocol 51. Supports Authentication, Integrity, Encryption and Anti-replay.

IPSec Modes of Operation:

Transport Mode:

Only the payload of the IP packet is usually encrypted and/or authenticated.

Tunnel Mode:

The entire payload of the IP packet is usually encrypted and/or authenticated. Dynamic / Static NAT will work natively with ESP-Tunnel Mode.

Ansible hostfile Deprecated

While using Ansible 2.4.3 for the very first time after upgrading, I received the following error:

[DEPRECATION WARNING]: [defaults]hostfile option, The key is misleading as it can also 
be a list of hosts, a directory or a list of paths . This feature will be removed in 
version 2.8.

It looks like if you have hostfile = ./hosts within the ansible.cfg file, you would have to change it to inventory = ./hosts

Reference Link.

Serial Number – Viprion Blades and Chassis

# 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.

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.