Configuring OTV - Site Redundancy - Multiple AEDs

In this blogtorial we are going to expand on my previous blogtorial "Configuring OTV - OTV Configuration and Verification" and configure an extra AED on the West Site to achieve site redundancy.

Here is the topology.

Since the underlay network configurations are the same, please see my previous blogtorial for that part of the configuration.

Configuring OTV - Unicast Transport Mode - OTV Adjacency Server

In this blogtorial, we will be configuring OTV using unicast-only transport mode as opposed to using multicast to discover neighbors etc. In order to use unicast-only transport, we have to enable and configure OTV Adjacency Server feature. Please see previous blogtorial (Configuring OTV - OTV Configuration and Verification) if you want more information on configuring OTV using multicast.

This topology is the same as my previous blogtorial.

What is an OTV Adjacency Server?

"Overlay Transport Virtualization (OTV) provides support for nonmulticast-capable, unicast-only core networks through the OTV Adjacency Server feature. An edge device is configured as an adjacency server (primary or secondary). All other edge devices are configured with the IPv4 addresses of the primary and secondary adjacency servers, after which the edge devices communicate their reachability and capability information to the primary and secondary adjacency servers. Wide-Area Networking Configuration Guide: Overlay Transport Virtualization, Cisco IOS XE Release 3S 2 OTV Adjacency Server Restrictions for OTV Adjacency Server You can configure more than one adjacency server per VPN. An adjacency server can serve multiple VPNs. An adjacency server can also connect an OTV site to one or more VPNs." - Cisco.com

First let's get the IP and the transport layer or the underlay network configured.

We will start with the East site.

Configuring OTV - OTV Configuration and Verification

In this blogtorial, I will go through OTV configuration on virtualized routers on Eve-NG and go through a few verification commands. I will also touch on key OTV terminologies and design considerations.

If you need any assistance on how to get Eve-NG up and running on google compute, please see my previous blogtorial - Configuring Eve-NG on Google Compute Engine

Here is the topology. Our goal is to establish layer 2 connectivity between 5.5.5.5 (ESXi-West-1) and 5.5.5.10 (ESXi-East-1). One of the key advantages of using OTV versus other technologies such as VPLS is that spanning-tree domain will not be extended between the sites. Other benefits include ARP suppression, Unknown flooding suppression, Hardware acceleration, and multi path tunneling.

First thing we will configure is the transport network or the underlay. We will start with the devices in the East Site.

Configuring Eve-NG on Google Compute Engine

In this blogtorial I will walk-through on how to deploy Eve-NG on the cloud and more specifically on Google Compute Engine. I've tried Eve-NG on AWS and Azure but neither of them actually worked since nested virtualization isn't supported or is a very convoluted process (i.e Ravello).  Google Compute Engine was also the cheapest option at the time of this writing. 

Why deploy Eve-NG on the clould?

This whole blogtorial came about because I wanted to study advanced topics in the CCIE DC curriculum such as VXLAN with BGP EVPN. In order to virtualize the type of routers capable of running these advanced DC technologies it requires a lot of RAM and CPU. In addition, I didn't need these routers to be running all the time wasting power, so I needed the flexibility of powering these devices on and off. I decided to search google on how to virtualize the topology and much to my surprise, I could not find an article that encompassed all the steps. After reading about 15 different articles and stitching together all the information, I decided perhaps I should write an article that has everything you need to know (the whole nine yards!!) on how to get Eve-NG on the cloud (Google Compute Engine). 

If you follow this article from step 1 to step Z, you will end up with a fully functioning google instance running Eve-NG. 

First, register for a free google compute engine account and then log into the console (I believe you get $300 in free credits ... so enjoy!!). Once you log into the console, click on "Activate Google Cloud Shell". 

Once you activate it you should see something very similar.

High CPU on Nexus 3K - Solved

In this blogtorial, I will demonstrate how I used 'ethanalyzer' on a Cisco Nexus 3K to solve an intermittent issue -- random adjacency drops of various routing protocols. Before we get into the details. let me first share with you on how I got involved in this troubleshooting to begin with. My good friend and colleague "BGP" bill aka self proclaimed "Multicast Guru" 😊 turns around says "Hey Weezy, you are a CCIE right? I have an open case with Cisco for a month why don't you just solve this issue?". Hmmmm ... above all else, one thing I've learned from the journey of becoming a CCIE is that I know very little. There is so much more to learn than you can imagine. In any case, I thought it was a noble challenge and as a bonus it peaked my curiosity. So Bill and I started chatting about the issue and as we were going through the motions, he gave me a great piece of information that would eventually steer me down the path to solving the issue, "Pete reported that he saw HIGH CPU usage compared to other similar routers".

So my 2 questions were:

ITHITMAN GIT Repo - https://github.com/ithitman/

Well it is official. I've signed up for a git hub account. I can now start publishing some open source tools on my free time to help my fellow engineers and tech enthusiasts.

Here is the link to my git repo that you can clone for yourself and contribute or use it.

https://github.com/ithitman/

Interaction between TLP (Tail Loss Probe) and SolarFlare EF_DYNAMIC_ACK_THRESH

In this blogtorial I will briefly discuss a performance issue that had me stumped for a bit. But after some googling around I stumbled up on the answer. I then started to take apart the RFC to gain a better understanding at the mischievous protocols at play. Oil powers the world and water sustains life, however they do not mix well together and the same concept applies here. Tail loss probe on its own is a great feature reducing the time it takes to detect packet loss and makes the TCP connection much more efficient. SolarFlare EF_DYNAMIC_ACK_THRESH is also a great feature which helps TCP performance. But enable these features at the same time and your TCP performance will suffer greatly.

CCIE #52966 R&S - First Attemp Pass

Hello fellow future CCIE's and blog readers ... I've done it and I can't express my excitement in words. I know I have not posted in a while due to personal issues right after achieving my CCIE, however I am starting the blog engine again. In this blog I am going to document some important information regarding my preparation, stuff I did before/during/after the lab exam, and hopefully give some insights / motiviation that might help you during your exam.

Lots of people ask me how do I feel being a CCIE? First off, I feel no different as I am the same engineer I was before I passed the CCIE exam, but the journey of becoming a CCIE has greatly changed my attitude and my day to day behavior on how I approach issues (both personally and professionally). The journey itself was much more important to me than passing the actual lab exam ... and as you go through your preparation keep one thing in mind "Championships aren’t won in the theater of the arena. They are won in the thousands of hours of training ... when everyone else is sleeping. That’s where it’s won. The heart of a champion is a light switch that’s always on – it doesn’t go on and off when someone’s watching – it’s constant" - (Greg Plitt RIP). The passing of the exam was just a general indication of my progression so do not get discouraged if you fail the first time. Just keep trying till you get to the finish line and grab that number.

Date Set - 5/27/16 - CCIE R&S v5 1st Try

Booked my CCIE R&S v5 lab on 5/27/16 in San Jose, CA. Check back here for more updates on my experience ...

Let's do this ...

This is why I post ...

I normally post "How-to articles..." however, I figured this time I'd share a thought that came into my head yesterday as I was watching "Grey's Anatomy". Now I am not particularly a big fan of that show but my wife had a surgery recently and while she was on bed rest, I started to watch the show with her. In one of the episodes, it was revealed that Meredith's mother wrote down all of her research because she was going to get Alzheimer and would eventually forget everything. As I was watching this episode, suddenly a thought popped into my head ... "why do you write how-tos/blogs? ... it's time consuming ... you could be doing something else instead...?" ... As I laid awake mulling over on this thought ... I realized that there are more than one reason as to why I write ...

Configuring LDP - Label Distribution Protocol

In this blogtorial we will go over the basics of LDP, discuss how LDP adjacencies are formed, and also take a look at LDP packets on the wire to gain better understanding of the inner workings of LDP.

LDP stands for Label Distribution Protocol and it is used by routers to share label information about prefixes. For more information regarding LDP check out RFC 5036. At a high glance, LDP first uses UDP hello messages to discover neighbors on the shared segment and then forms a TCP peering with the LDP neighbor to share the label to prefix mapping information. We will see this in detail (packet captures) later in this blogtorial. 

Here is a simple topology to follow along.

Configuring DMVPN Phase 3 w/ EIGRP

In this blogtorial we will configure DMVPN Phase 3 and run EIGRP over the tunnel. After reading this blogtorial, I hope that you will have a clear understanding of DMVPN Phase 3 and how it interacts with EIGRP. If you need a primer on DMVPN Phase 1 and Phase 2, please see my DMVPN blogtorials.

Here is the topology.

Configuring DMVPN Phase 2 w/ EIGRP

In this blogtorial we will configure DMVPN Phase 2 and configure EIGRP over the DMVPN tunnel. Over the past few blogtorials we've been concentrating on how to configure DMVPN Phase 1 and routing protocols over DMVPN Phase 1. One of the key disadvantage of Phase 1 is that all spoke to spoke traffic must pass through the HUB which is a bit inefficient. DMVPN Phase 2 improves on DMVPN Phase 1 by allowing for on-demand dynamic spoke to spoke tunnels based on traffic patterns.

Here is our topology.

Configuring DMVPN Phase 1 w/ OSPF

In this blogtorial, we will configure DMVPN Phase 1 with OSPF and walk through some gotchas and some pitfalls to be on the look out for.

Due to the hierarchical nature of OSPF and other adjacency intricacies, OSPF is generally discouraged in a DMVPN design. 

We are using the same topology as my previous blogtorial "Configuring DMVPN w/ IPSEC and EIGRP", however I'll post the base configs here as well. 

Here is our topology.