:Book:MPLS-Enabled Applications from a CCIE candidate perspective

I started reading MPLS-Enabled Applications: Emerging Developments and New Technologies 3rd Edition with the goal of learning more about MPLS for my next CCIE attempt.  MPLS was one of the areas that I identified as needing improvement.  So please understand that my primary goal of reading this book was to understand MPLS for the CCIE RS v5.  I ordered this book last summer shortly after I failed my first CCIE attempt.  I read most of it while on holidays in France.  The downside of reading while on holidays is that I wasn’t able to supplement the reading with real world examples but the upside is that I had the time to read most of the book.

I don’t have a huge service provider background, so I’m always interesting is seeing how things are configured from the SP side.  Apart from understanding MPLS at a much deeper level, it was invaluable to understand the deployment and use cases for each particular MPLS technology.  I particularly found the concept of layer-1 fault protection very interesting.  The idea of having two paths pre-determined is similar to how routing protocols such as EIGRP feasible successors work but it’s on a layer-1 level.

After reading this book has made me ask different questions when ordering or enquiring about a particular service from an SP, especially in the fault tolerance and path protection areas.

Recommendation? Most definitely a Yes!

Would I recommend this book to CCIE candidates?  Absolutely, I would try to read this early on in your path as it provides a very vendor agnostic view of MPLS so you will still need to understand how those technologies are implemented by Cisco.  The entire book I was constantly thinking, ok I understand that concept I wonder how Cisco implemented it?  If you are pressed for time, you could probably get away with only reading Chapters 1: Foundations, 7: Foundations of Layer 3 BGP/MPLS Virtual Private Networks and 8: Advanced Topics in Layer 3 BGP/MPLS Virtual Private Networks.

I would also recommend this to any person who is designing or planning on designing a network.  The perspective it gives you is extremely useful, especially if you are ordering services from a service provider.

BGP and EIGRP mutual redistribution routing loops and prevention…

The dreaded routing loop, I ran into an interesting problem the other day regarding a BGP/EIGRP mutual redistribution configuration.  There was an issue with the secondary router receiving BGP advertisements, but the resulting behavior was unexpected.  It created a loop in the network, every 30 seconds the routes either went into the routing table or were flushed out.  I’ve recreated the scenario in a lab environment and I can recreate the problem but not the exact symptoms.  I still can’t get the 30 seconds in/out, this could be because I’m using newer code or IOU or I don’t have all the pieces exactly recreated.

Here is what the topology looks like in the lab:

Here is what the routing loop looked like from L3

 L3(config)#do traceroute 10.100.201.1
 Type escape sequence to abort.
 Tracing the route to 10.100.201.1
 VRF info: (vrf in name/id, vrf out name/id)
 1 10.107.163.6 4 msec 5 msec 5 msec
 2 192.168.101.49 5 msec 5 msec 5 msec
 3 * * *
 4 * * *
 5 10.51.157.10 2 msec 5 msec 1 msec
 6 10.107.163.9 1 msec 1 msec 1 msec
 7 10.107.163.6 0 msec 1 msec 1 msec
 8 192.168.101.49 0 msec 0 msec 1 msec
 9 * * *
 10 * * *
 11 10.51.157.10 3 msec 1 msec 1 msec
 12 10.107.163.9 1 msec 1 msec 1 msec
 13 10.107.163.6 1 msec 1 msec 1 msec
 14 192.168.101.49 1 msec 1 msec 0 msec
 15 * * *
 16 * * *
 17 10.51.157.10 8 msec 6 msec 2 msec
 18 10.107.163.9 1 msec 6 msec 1 msec
 19 10.107.163.6 5 msec 1 msec 2 msec
 20 192.168.101.49 1 msec 1 msec 1 msec
 21 * * *
 22 * * *
 23 10.51.157.10 1 msec 1 msec 1 msec
 24 10.107.163.9 1 msec 3 msec 1 msec
 25 10.107.163.6 1 msec 1 msec 1 msec
 26 192.168.101.49 1 msec 1 msec 1 msec
 27 * * *
 28 * * *
 29 10.51.157.10 3 msec 1 msec 2 msec
 30 10.107.163.9 1 msec 5 msec 3 msec
 

After drawing up what I thought was happening, it was clear that because the BGP prefix was being blocked into CE2 it was learning the prefix from EIGRP and then advertising into BGP.  Normally this wouldn’t matter because CE1 would recognize that the BGP advertisement had it’s own as-path and would reject it.  But due to some legacy configuration, as-override was running on the service provider PE routers.  So when CE1 saw the BGP advertisement from CE2 with a shorter as-path it installed that route.  This meant that the packets went from L3 -> CE1 -> CE2 -> CE1 until the infinity count expired.

To clear this looping, I first thought of setting a tag outbound on the BGP neighbor route-map and then block inbound. You can block the route, using an inbound route-map but you can’t set a tag on an outbound route-map.

 % "PREPEND" used as BGP outbound route-map, set tag not supported

I then tried to set a tag from EIGRP->BGP then blocking that route using a route-map when redistributing from BGP->EIGRP. I ran into a restriction on setting the tag on redistribution.

 % "BGP-EI" used as redistribute eigrp into bgp route-map, set tag not supported

Finally I settled on setting a tag on the redistribution of BGP->EIGRP, and then blocking that tagged route when redistributing EIGRP back into BGP. The configuration is below.

 route-map BGP-EI permit 10
 set tag 666
 route-map EI-BGP deny 10
 match tag 666
 route-map EI-BGP permit 50
 
 router ei 50
 redistribute bgp 65003 metric 10000 1000 255 1 1500 route-map BGP-EI
 
 router bgp 65003
 redistribute eigrp 50 route-map EI-BGP

A much simpler solution would be to use network statements under the BGP process instead of redistributing EIGRP into BGP, but it is very handy to understand how to stop routing loops when you are restricted either by an existing production setup or by the CCIE.