Enough Study... Time For Fun

Time To Get Rid Of 7 IP Networking Myths - Based On Recent Interviews I Did

In last 6 months I got opportunity to work closely with HR teams from different regions within company and must have interviewed well over 200 People which gave me good opportunity to talk to so many candidates ranging from CCNA to CCIE & even Multiple CCIEs.

During this whole process I came across couple of Myths related to IP Networking which I would want to share so that together we can spread more awareness among other Engineers & Clients.

Myth 1 : vPC eliminates STP into the Network.

Well vPC tweaks STP behavior quite a bit for it’s operation but STP is still running in backend as fail safe. Even more vPC Primary switch send regular STP BPDUs by default over vPC member ports. Well the only solution to get rid of STP completely today from Cisco’s perspective is implementing Fabric Path.

Myth 2 : EIGRP is a better protocol for Cisco only network since it has better convergence features such as Feasible Successor if compare to OSPF. Same thought people have when comparing ISIS with OSPF.

Well convergence in itself is domain now from IP Networking perspective or perhaps always was. It’s just people these days talk more about it as requirements have grown tight in last 5 years because of Next Generation Network Requirements and more sensitive applications.

Most routing protocols don’t spend too much time for re-calculation once the primary path gets failed. The most contributing factor in convergence is detection of failure rather. A simple example would be to have two EIGRP neighbors connected through multiple links including a Ethernet connection through L2 Switch which is currently primary path. If link between L2 switch & Router 2 fails, Router 1 will notice the failure only after dead timer expire and than will run DUAL for recalculation depending upon it has Feasible successor or not. So in this case it’s not going to be any different than OSPF or IS-IS.

Myth 3 : OTV is the best solution for VMotion over Data Center Interconnect (DCI) or any Layer 2 extension requirements.

Well It depends. The part of equation here is VMotion requirements itself. For Hot VMotion the end to end delay requirements is less than or equal to 5 msec which in new ESXi version got relaxed to 10 msec I guess. So if the delay is higher and you have Hot VMotion requirements, OTV won’t do any good as DCI. Also choosing DCI Technology Between OTV and others like MPLS Martini Style, VPLS etc has lot to do with Scale related to number of MAC Addresses to be learned & Exchanged.

Myth 4 : One major benefit of using MPLS is that Router Switches packets faster since it uses LIB

Well it use be true in history but ever since the introduction of Hardware based forwarding in platforms and platforms having great amount of CPU and Memory, it’s not true any longer.

Myth 5 : Nexus 2000 is a Switch

Well it can’t perform local switching between 2 ports which might be even in Same VLAN. All the switching is still performed by Parent Switch (7k or 5k) based on VN Tags.

Myth 6 – Once the EIGRP SIA Timer Expires, The Neighbors are bounced

Well Cisco solved this problem I guess almost 10 years back with implementation of SIA Query & Replies. It’s just of those things which are not documented in most Cisco Press Books J covering EIGRP

Myth 7 – Traceroute is part of ICMP Suite

Well traceroute is an application but not a protocol or part of any protocol suite in itself. Traceroute has different implementations using ICMP, TCP & UDP by different vendors.

HTH...

Deepak Arora

Evil CCIE

VRF Routing Context - Lets Make Virtualization Life Easier

VRF aware pings and test are frustrating many times specially during troubleshooting where you try to ping or trace a destination or check routing table and later you notice you forgot to run vrf aware command. To solve this problem Cisco has introduced a cool feature known as VRF Routing Context into IOS and NX-OS which makes life lot easier specially during troubleshooting. Here is a quick example and topology details:

 

 

 

HTH....

Deepak Arora

Evil CCIE

 

Static Route Recursion - Why my static route is not going away ?

Static Routes are easy to begin with right ?

They must have saved your tail many times in production network outage situations.

Though inherent problem from Design perspective with Static Routes is that they are not considered as scalable solution except for small networks. But of course they can be used as duct tape in many cases just like my another favorite duct tape solution known as GRE Tunnels.

Normally Cisco documentation keeps pointing that Static Routes are recursive in nature. But I haven't personally seen many good documents going deep to explain it further with example.

Let's give it a try today :)


Consider the following network as shown below:

Two routers network using static routing...Can't be more simpler right ? :)


Now below are my traffic flow requirements.

 

The path through Ethernet Switch should be used all the time unless there is a problem, in which case the traffic should follow Backup Path (Point To Point) link.

Now it's easy right ?

One Normal Static Route pointing towards next hop reachable via Ethernet path and one Additional Static Route pointing towards point to point link next hop with higher AD (Administrative Distance) should be enough like shown below.

Let's verify our routing table quickly:

 That looks fine.... Cool :)

Now in our first scenario we are going to shutdown f0/0 of R2 to see if our Backup Route gets triggered.

 Let's see if our backup route is triggered:

Seems like a problem as we are still pointing route towards 12.0.0.2 which is reachable via our ethernet segment.

But that is something we all must have encountered at some point in production. R1 is not removing the primary route since it's local interface is up and it is completely unaware about the next hop being not reachable.

Simple solution to this problem is using Enhanced Object Tracking feature which can be integrated easily with static route in which there will be an IP SLA instance running and constantly checking next hop reachability and as soon as this probe detects next hop being unavailable, it will remove Static Route from RIB.

I tried by replacing static route from ethernet segment with "exit interface" syntax instead of next hop but that didn't help either.

Let's Unshut the interface back and move on to our next failure case.

Let's fail f0/0 of R1 this time and see if backup route gets triggered:

Now what ?.... Router Gone Crazy or IOS Bug ?

Let's examine some more details:

Let's review RIB:

Now here is a fundamental problem I talked about with Static Routing or Route Recursion process associated with it.

Although my local interface is down pointing towards Next Hop 12.0.0.2, but since 12.0.0.2 is reachable via another path (In Real Life Could Be Intentionally or Unintentionally...Less Specific Network Command under IGP, Redistribute connected etc), our router is not removing primary static route.

So how do we fix it. Simple :)

With this format of Static Route command, we basically force to recurse for next hop only via given interface instead of any interface which is default.

Now static routes should really be simple :)

HTH...
Deepak Arora
Evil CCIE

Scaling BGP Part 2 - Using Route Target Constrain To Scale PE

One of the common problem with MPLS based L3 VPN services from Service Provider perspective is PE Scalability. Specially If the Implementation in the Core is using VPNv4 Route Reflector (VPNv4 RR).

When VPNv4 RR receives routes from PEs, It's job is to reflect all different customer routes to another PEs without considering the fact that particular Customer VRF might not exist on specific PE. Which is most likely the case in Real world. Which is certainly a problem from PE Perspective.

One of the way PE get rid of this problem itself is that by Default Automatic Route Filtering (ARF) is enabled on all PEs which suggest a rule that if routes are received for particular VRF and that particular VRF doesn't exist on PE locally, it's gonna filter out those routes automatically. However this logic or rule doesn't apply to VPNv4 Route Reflector itself since it doesn't make sense to put it in Data/Forward Plane. And if it's not in Data Plane than creating and mapping VRFs locally doesn't make any sense.

On the flip side , however ARF is good tool to have in pocket from PE perspective. But problem is that routes are still getting received from Route Reflector (RR) and getting filtering after that which means wastage of local resources and bandwidth.

So the question is, How Do We Fix This ?

The Answer lies in something called Route Target Contrain as defined in RFC-4684. I'll talk about AFI and SAFI in next post. But lets assume that this feature signals the RR from PE perspective about which all VRFs locally exist on that particular PE, resulting RR not Reflecting unnecessary routes towards that PE for VRF that doesn't exist locally on it.

Here is a quick example :

In This Particular Example PE-2 doesn't have VRF-B configured locally. So It doesn't need to receive Reflected Routes from RR for VRF-B.

Before RTC: RR Sending All Routes for All VRFs to PE-2

After RTC: RR Sending Only Routes For VRF-A to PE-2

Configuration:

Further Verification:

Pitfall :

From Planning Perspective, you need to understand that this feature is not only IOS dependent but also would require to be enabled not only on VPNv4 RR but also on PE under consideration.


HTH...
Deepak Arora
Evil CCIE