TCP SACK Demystified

In this blogtorial, we will briefly explore TCP SACK (Selective Acknowledgement) option and the benefits of using TCP Selective Acknowledgement. TCP SACK is negotiated in the initial 3-way TCP handshake and both parties must agree to use this option or TCP SACK will not be permitted.

Let's walk through an example and observe what happens when SACK is not enabled.

BGP Wedgies - Demystified

Usually when we configure BGP we expect the network to converge correctly after all the peerings come up, however under rare circumstances this is not the case. In this blogtorial, we will explore one such corner case scenario in which depending on the order of operation, the BGP topology can end up in a unpredictable topology or a BGP Wedgie.

Here is the topology.

As usual let's go ahead and get the routers configured and give this topology a wedgie.

Configuring Cisco - BGP Best External

In this blogtorial, we will briefly explore "BGP Best External" feature and walk through a scenario on how we can achieve sub-millisecond convergence with BGP. This feature is usually used in MPLS environment, although you can pretty much use it anywhere if the design allows it. Here is a simple topology so follow me.

What are TCP Spurious Retransmissions?

First time I saw on "TCP Spurious Retransmissions" on Wireshark, I had to look up the definition of Spurious on Google as I've never heard that word before :). It reads "not being what it purports to be; false or fake". Fake retransmissions? hmmm ... interesting ... started to wonder what this really means. After some investigation, I found out what these mysterious Spurious retransmissions really are. In Wireshark, TCP retransmissions are classified as one of three categories.

Key terms: 

RTO - Retransmission Timeout. Every TCP segment as it is sent to the IP layer has a timer associated with it and an ACK should be received before this timer expires. This timer is dynamically adjusted according to RTT and other factors. Here is a good write-up RFC 6298 if you want to get more information on how RTO is calculated. 

Troubleshooting eBGP peering

Simple .... BGP topology ... can you get eBGP up and running between R1 and R2?

Objective:

Establish successful and stable eBGP relationship between R1 and R2. With the current start-up config, BGP is IDLE. 

Topology diagram and startup config are posted below.

Configuring OSPF - area range vs summary-address

In this blogtorial we are going to take a look at the difference between area range vs summary-address command both of which can be used for OSPF summarization/filtering. Both area range and summary-address commands can also be used for OSPF route filtering. In addition, we will also discuss a few options that are available with area range and summary-address command and pitfalls to be on the lookout for.

Simple topology below and let's get started.

Configuring OSPF - Summarization Lab

As the CCIE Lab exam requires you to the think outside the box a bit, I will do the same on this lab. Here is a simple topology and the basic start up configuration.

Objectives:

• Summarize 192.168.1.2/32 from Area 2 as 192.168.1.0/24 into area 0.

Restrictions:

• Do not use area-range command or summary-address to summarize the routes into Area 0.
• R3 and other routers in Area 0 or any new additional areas should only have the summary address to reach 192.168.1.2. 
• If prefix 192.168.1.2/32 is withdrawn (i.e shutdown loopback0 on R2) from R1 OSPF database then 192.168.1.0/24 should not be summarized/advertised into area 0.

Cisco BUG - PIM join does not make it to CPU

Cisco BUG

CSCue52328 Bug Details

PIM joins for some groups not processed at CPU level

Symptom: Under very rare conditions PIM joins from a downstream switch are not forwarded my mcastfwd to PIM to be processed. This has been seen under the following conditions a) Downstream device sending PIM joins is a Arista switch b) There is a local receiver sending IGMP joins for the same group for which PIM joins are received c) Exact trigger is unknown at this point, could be the remote receivers (which result in PIM joins) flapping

Precision Time Protocol PTP - Demystified

As Network Engineers we build highways (maybe Bundesautobahn where there are no speed limits) on top of which various protocols travel. As designers/architects, perhaps it would be beneficial for us to understand what is traveling on the highways we build.

I started to dip my feet into PTP and I realized there is more to PTP than meets the eye. I also realized that I knew very little about its operations so I decided instead of dipping my feet why not just dive right in -- head first. As any curious person would do, I started to read the RFCs and white papers. But before we get into PTP's operation, let's define a handful of key terms.

40G MORE is NOT always BETTER - Why 40G can potentially delay your packets?

40G might actually delay your packets and here is the reason why. 

Before we get too much into the semantics behind this, let define some key terms in latency measurements. I am also going to leave out the minor benefits gained from "inter-frame gap" of 40G packets. If you are interested in further information regarding latency testing/benchmarking standards please see RFC 2544.

Troubleshooting OSPF - LAB 1

Here is a quick lab I put together to really test your knowledge about OSPF Path selection and some of the hidden rules behind the path selection.

Simple topology below.

Objective: 

• R3 should choose R2 over Gi1.23 to reach R1 loopback 150.1.1.1/32. Imagine that this is a 40Gbit link where as Gi1.13 is just a 100Mb link. Currently R3 is choosing Gi1.13 to reach R1 loopback 150.1.1.1/32. 

Restrictions:

• Do not configure any new routing protocols.
• Do not change Area numbers.
• Do not create any NEW areas. 
• Do not change OSPF cost values
• R3 should choose R1 with OSPF as the routing protocol so no STATIC routes etc. 

Configuration excerpts below so you can configure it in your lab.

EIGRP - Troubleshooting LAB 1

Objective:

• When Gig2 is shutdown on R1, metric for the route to reach Loopback1 should not change on R2.  

Here is a simple topology and let's get started.

EIGRP - Extended NAMED ACLs are not allowed in distribute-list.

Quick post regarding an error message I came across when trying to configure eigrp distribute-list with extended NAMED ACLs.

% The ACL cannot be created or an ACL with the same name but incompatible type already exists.

Router version CSR1000v - Cisco IOS Software, CSR1000V Software (X86_64_LINUX_IOSD-UNIVERSALK9-M), Version 15.4(2)S, RELEASE SOFTWARE (fc2)

 R5(config)#ip access-list extended PBR_EIGRP  
 R5(config-ext-nacl)#deny ip host 155.1.0.1 host 150.1.4.4  
 R5(config-ext-nacl)#deny ip host 155.1.0.3 host 150.1.4.4  
 R5(config-ext-nacl)#deny ip host 155.1.0.4 host 150.1.4.4  
 R5(config-ext-nacl)#deny ip host 155.1.0.1 host 150.1.6.6  
 R5(config-ext-nacl)#deny ip host 155.1.0.3 host 150.1.6.6  
 R5(config-ext-nacl)#deny ip host 155.1.0.4 host 150.1.6.6  
 R5(config-ext-nacl)#deny ip host 155.1.0.1 host 150.1.1.1  
 R5(config-ext-nacl)#deny ip host 155.1.0.2 host 150.1.1.1  
 R5(config-ext-nacl)#deny ip host 155.1.0.4 host 150.1.1.1  
 R5(config-ext-nacl)#deny ip host 155.1.0.1 host 150.1.2.2  
 R5(config-ext-nacl)#deny ip host 155.1.0.2 host 150.1.2.2  
 R5(config-ext-nacl)#deny ip host 155.1.0.4 host 150.1.2.2  
 R5(config-ext-nacl)#deny ip host 155.1.0.3 host 150.1.7.7  
 R5(config-ext-nacl)#deny ip host 155.1.0.2 host 150.1.7.7  
 R5(config-ext-nacl)#deny ip host 155.1.0.4 host 150.1.7.7  
 R5(config-ext-nacl)#deny ip host 155.1.0.3 host 150.1.9.9  
 R5(config-ext-nacl)#deny ip host 155.1.0.2 host 150.1.9.9  
 R5(config-ext-nacl)#deny ip host 155.1.0.4 host 150.1.9.9  
 R5(config-ext-nacl)#permit ip any any  

 R5(config-router)#distribute-list PBR_EIGRP in
 % The ACL cannot be created or an ACL with the same name but incompatible type already exists.
 R5(config-router)#^Z

CCIE v5 INE Home Lab - Part 3 - Console to Routers / Automating scripts

Don't you love it when it all comes together and all the puzzle pieces fall into place. Well I hope that this blogtorial does exactly that. In part 1 and part 2, we laid the groundwork and the foundation to successfully get a lab up and running and in this blogtorial we are going to finish it off with:

• How to console into the virtual routers? 
• How to get all initial configs prep'd so we can have concentrate on doing the labs rather than setting up the labs?
• How to automate the loading of the initial configs? 

I know it's a lot to cover in one post, but I also didn't want to breakup this series into too many parts. So without further adieu, let's get started and I will try to streamline it and post as much screenshots as possible. Here is the overview and where we will be spending most of the blogtorial.

I normally would do it for free but I have had tons of requests and questions regarding the lab setup and scripts. So for a nominal fee I will configure your entire VMWare ESXi server / all the routers / the Linux VMs / auto loading scripts. More importantly it includes an easy to use WEB GUI to load the config files. Contact me via arwinr@gmail.com if you are interested. 

Screenshot of the WEB GUI. 

Note: Thomas Kjær pointed out in one of the comments below that ESXi version 6 recently released does not limit 4 serial per Linux VM. Therefore, instead of creating 4 linux VM you could just do it all in one Linux VM, but you would have to edit the scripts accordingly.