VRF is a routing enhancement mechanism which fits in the scenarios of the customer’s overlapping IP spaces. It separates RIB (routing table)  into multiple instances and allows to conserve IP addresses whilst also provides the end-to-end connectivity as normal global RIB does. This also means that the same devices can be re-used to accommodate multiple clients/services aka forwarding paths which in effect minimizes CAPEX.

One of the newest IPSec enhancements adds the VRF capability to allow multiple , i.e. MPLS VPN connected sites with overlapping IP space to benefit from the additional layer of IPSec framework on the top of it to secure and achieve data integrity, data confidentiality (encryption), and replay protection.

VRF enabled IPSec environment is driven by  two key definitions, namely VRF domains:

  • The outer encapsulated packet belongs to one VRF domain FVRF (front VRF). Our VPN endpoint termination is FVRF and can reference the source IP for multiple client-enabled IPSec tunnels. VRF enabled IPSec can exists without the FVRF too, however in order to distinguish the global RIB service from the VRF enabled service it’ll be used in the topology. The FVRF contains encrypted traffic aka this is VPN tunnel endpoint.
  • The inner, protected IP packet belongs to another domain called the IVRF (internal VRF). This VRF references the VRF which is assigned per client basis. The iVRF contains decrypted (clear text) traffic aka it references the interesting traffic.

Read More

TCP retransmission and fast retransmission


From unknown source…

TCP retransmission:

TCP starts a retransmission timer when each outbound segment is handed down to the Internet Protocol (IP) layer. If TCP does not receive an acknowledgment for the data in a given segment before the timer expires, the segment is retransmitted. The retransmission time-out is adjusted on the fly to match the characteristics of the connection, using Smoothed Round Trip Time (SRTT) calculations as described in Van Jacobson and Mike Karels’ paper “Congestion Avoidance and Control” in Proceedings of the ACM SIGCOMM Conference on Data Communication, November 1988. The retransmission time-out for a given segment is doubled after each retransmission of that segment. Using this algorithm, TCP tunes itself to the usual delay of a connection. TCP connections over high-delay links take much longer to time out than those over low-delay links, in order to avoid incorrectly timing out when a connection is merely slow rather than not present.

TCP fast retransmission:

Under some circumstances, TCP retransmits data before a particular segment’s retransmission timer expires. The most common such circumstance occurs because of a feature known as fast retransmit.
When a receiver that supports fast retransmit receives a packet with a sequence number higher than the current expected one, it proceeds as if some data was dropped. To help make the sender aware of the apparently dropped data as quickly as possible, the receiver immediately sends an acknowledgment (ACK), with the ACK number set to the sequence number that seems to be missing. The receiver sends another ACK for that sequence number for each additional TCP segment in the incoming stream that arrives with a sequence number higher than the missing one. When the sender receives a stream of duplicate ACKs that acknowledge the same sequence number and the indicated sequence number is earlier than the sequence number of the current segment being sent out, the sender can infer that one or more segments it previously sent were dropped. After receiving a certain number of duplicate ACKs, senders that support the fast retransmit algorithm resend the segment or segments that the receiver is requesting to fill the gap in the data, without waiting for the retransmission timer to expire for the missing segments. This optimization greatly improves performance in a busy network environment. With fast retransmit, the sender retransmits the missing TCP segments before their retransmission timers expire. Because the retransmission timers did not expire for the missing TCP segments, missing segments are received at the destination and acknowledged by the receiver more quickly than they would have been without fast retransmit and the sender can more quickly send later segments to the receiver. This process is known as fast recovery. Fast retransmit and fast recovery are described in RFC 2581: TCP Congestion Control.

Intra-area OSPF logic


Most of us know that the usual path selection process for OSPF is:

  1. Intra-Area (O)
  2. Inter-Area (O IA)
  3. External Type 1 (E1)
  4. NSSA Type 1 (N1)
  5. External Type 2 (E2)
  6. NSSA Type 2 (N2)

However, the above applies to the inter-area route selection.

What kind of underlying logic happens within OSPF engine before leaving the area? How can we traffic engineer the most optimal path based on the requirements?  It appears that the cost of the prefix is not only tie-breaker…

The following rules apply (https://www.ietf.org/rfc/rfc2328.txt):

  1. Bandwidth for metric calculation (higher bandwidth is preferred).
  2. If same bandwidth, then it would load balance.
  3. On configuring maximum path 1, then the path is selected based on network type P2P is more preferred over Broadcast.
  4. On configuring same network type on both interfaces,lower router-id wins

Let’s lab it, the topology is as follows:

intra-area OSPF

Read More

PFR Lab 1: auto-learn process and route enforcement


As a continuation of the previous introductory article http://www.4pronetworks.co.uk/blog/pfr-and-why-do-i-bother/ where we touched upon the general mechanics of the PfR, we are now going to observe how it really works and how the roue changes are enforced. For its purpose we will use the existing topology and introduce traffic simulators to reflect the real-time raw conditions.


First of all let’s choose the Border (BR) and Master (MC) devices. According to the topology, our BRs sit at the edge of the WAN demarcation point, hence the election.

For the Master device we’ll choose the one within our HQ network (and Branch should we need more comprehensive solution). We could configure the Master on the Border routers if we really need to, however given the big number of the BR devices can cause performance issues in the real life scenarios, therefore its recommended to keep it separate.

Read More

PfR and why do I bother…


The idea behind the Cisco PfR (Performance Routing, formerly known as OER) is to extend the capabilities of the traditional IP routing packet delivery based on the associated cost and destination prefixes.
In constantly changing network landscape the solution was required to be developed to take into the account more sophisticated metrics such as delay, packet loss, jitter, QoS values and throughput and enhance the traditional packet delivery to provide the more dynamic and pro-active solution.

The new trend in the networking industry SDN (Software Defined Networking) utilizes the idea of the controller which “programs” dummy networking devices that are only in charge of packet switching without any control plane decision making.

Therefore I like to think of PfR as poor SDN brother because the main difference is lack of the programming capability in the Cisco software to execute particular decisions. However, given the richness of the available built-in  tools, we can introduce more clever way of delivering our precious traffic.
As a result, we can utilize PfR to address few particular real life scenarios:

Introduce unequal load-balancing across the links

Route voice traffic over the lower latency line

Automatically fall over the priority traffic class if the utilization exceeds the set % threshold

Analyze the traffic based on the DSCP values and route via the specified WAN links

Black-hole the particular traffic flow – i.e. DDoS traffic – when the throughput exceeds set % threshold

Optimize not only outbound but also inbound traffic.

Switch over the traffic without hard interface or BGP session drop – i.e. based on the availability of above dynamic metrics.

Restore the traffic flow to the original path upon restore of the network conditions.

and many more.

Since you cannot achieve it with the traditional routing protocol, extra configuration and design approach is required which I aim to provide over the series of the articles.

The first post will be focused entirely on the mechanics behind this concept, we will also set up the stress test bed topology to help us understand the concept better.

1. Topology and engine required to enable PfR:


Read More

Encrypted VNC session over SSH tunnel


I use VNC to connect to my Raspberry Pi to perform multiple management tasks over GUI, usually for the Web Browser access from my WAN IP address.

The free version of the VNC encrypts only initial login handshake, the session’s traffic lacks encryption meaning its prone to interception of the rogue sniffer.

Read More

Expect script


The expect script gained its popularity by overcoming admin burden of manual update of bulk of the devices. The way it works is simply by specifying the end host-names and the commands to be applied to.

The classical expect script requires you to store the usernames/passwords in clear text in the related expect script text file. The same applies to the host/commands – they need to be stored in the separate files requiring manual update each time the exercise changes.

Below I present a solution on how to overcome these obstacles. Whilst the expect script has been derived from the http://docwiki.cisco.com/wiki/Remote_VTY_Command_Script the rest of the underlying framework has been written in bash.

Bash function calling the expect script upon manual specification of the username/password/devices/commands:
Read More

Random bash one-liners and functions


1. Read user’s input without printing to the screen:

read -sp "Username: `echo $'\n> '`" ruser


2. Read user’s multi-line input, end with ESC character, store in a variable and send to the text file:

read -d `echo -e "\e"` input
echo "$input" > input.txt


3. Extract the line containing the “word” and print the last column only:

ls -la | egrep -ri --color=always 'word' | awk '{print $NF}'


4. Find all the filenames with the .txt extension and delete them:

sudo find . -name "*.txt" | xargs sudo rm

Read More