Author: Christopher Miles

Infrastructure Engineer currently pursuing a CCIE certification in Routing and Switching.

CCIE Strategy – Config Section

This post will detail a strategy that I personally used during my recent attempt(s) at the CCIE R&S lab exam, specifically on the configuration section. This was a strategy that a few of my study group members and I curated during our time studying for the lab together. I’ve spoken to some others who followed a very similar approach, just with a few tweaks.

***CURVEBALL FROM CISCO***

So… Cisco decided to drop a major update to their certification program a few weeks ago at CLUS, shortly after I started drafting this blog post. That being said, this post is focused on v5 of the R&S lab. Therefore, it will have a shelf life of about 8 months until the test changes in February of 2020. Some of the content may still be applicable afterward, but since the entire test format changed, I won’t bank on it. 😉

Assumptions:

In this post, I’ll be assuming the reader is familiar with the format of the CCIE lab. Specifically the format and content of the CONFIG portion.

Credits

Throughout this post I will be utilizing a lab that was actually created by a good buddy of mine, Tim McConnaughy. Tim created this lab as a means to help people studying for the lab to have some extra practice material after he passed the lab. He’s done a great job contributing back to the community that helped him and I thank him for letting me use this material. He presented at CLUS 2019 in San Diego and has a great blog. Check out his content and harass him into making more labs like this 😉

https://carpe-dmvpn.com

https://bit.ly/2Y0ivHh : Introduction to IP Multicast – BRKIPM-1261

Why is a strategy important?

First of all, I want to stress that everyone is different and it is important to find out what works for you. There are people out there who could probably walk in, start at task 1, go to town, and walk out with a fresh set of digits. That didn’t work for me. One of my prominent struggles in the lab exam centered mainly around reading comprehension and retention. So I needed a little more structure to my approach in order to conquer the lab. My buddy, Henry Pardo, and I used techniques from others and created a quick strategy for us that really helped us save time and effort while in the lab. This strategy helped us put everything in a very particular order on how to approach the lab. This kept me from having to jump around, wondering what to do next, and having to go back and reconfigure items. I was able to have it it all in a nice format so I spent even less time scatterbrained.

Ok… let’s get to it.

Step 1 – Go ahead and complete the Layer 2 section

Once you get to start the config section of the lab, I think it’s best just to keep rolling with your momentum and jump right into configuring the Layer 2 section. Many people will say, “NO! You should start by reading the entire list of tasks/requirements before doing anything!” If this were a real-world scenario, I would wholeheartedly agree. But if you understand the virtual topology you’ve been dealt, you know nothing is going to work until you get the Layer 2 section configured and running first, so you might as well do it (this will make more sense later). By this, I mean go ahead and read the entire Layer 2 section, digest the requirements, and get it done.

By the time you’re done with this, it will probably be a little close to lunch time.

Step 2 – Number your sheet

This is where you’ll want to grab the scratch paper. Since you’ve already configured the Layer 2 portion of the lab (Section 1), we’ll start with Section 2 and so on. This will include Layer 3, VPN Technologies, Security, and Services.
Without actually reading any of the tasks, just scroll through and see how many tasks are in each section and jot them down in a column on the left side of your paper. For example, if you notice the Layer 3 section has 12 tasks, write down 2.1 all the way through 2.12. You’ll want to leave a little space on the right-hand side for checking off these items later. In the end, your sheet will look something like this:

Step 3 – Analyze the full topology divide into “sites.”

Like I said before, I’ll be using my friend Tim’s lab as an example here. You’ll then take a look at the full topology diagram they provide you in the documents section. Like so:

Lucky for us, Tim made this pretty easy to see where the site boundaries are. We have a DC, an HQ, offices in Beijing and Shanghai, and some remote worker sites down in the bottom. Also, we have an MPLS provider in the middle connected to some other SPs. We’re going to basically start putting these sites on our paper in the shape of how they appear on the diagram. We’ll put a header on each one with the site name, and I also like to go ahead and add the BGP AS on there as well (where applicable). This will come in handy later when you’re crafting configs and don’t want to dig through the documents to find the AS number. You can just glance over at your sheet.

Step 4 – Read through each task and assign to the appropriate site.

This is where you’ll spend the most time. Read each task, starting at the beginning, and digest what’s being asked. Then write the task number under the site where it’s applicable. For example, here’s the first task of Tim’s lab:

Write this task under the MPLS Core site with some shorthand about what the task is. “2.1 – OSPF.” In the description of the task, you can also add a keyword to help you remember something unique about the task that you don’t want to forget. If you read a task, later on, that implies you should use named mode when configuring EIGRP instead of classic mode, jot it down on the primary task that tells you to configure EIGRP. Then move along to the next task and continue.

Tip
As you go, pay attention to which tasks give you tasks for verification. i.e., if a task tells you to “match this output” or result in a particular routing behavior, you’ll want to make a note of that. Any task that requires such a thing put a tiny “v” next to the task in the column you made on the left-hand side. By doing so, you’ll know precisely the tasks to revisit during your verification process.

You’ll find that some tasks apply to more than just one site. Let’s say you get a task that involves configuring eBGP at all sites. You’ll want to list this task under every single site that needs eBGP configured. Here’s an example from Tim’s lab:

This task requires configuration of the HQ, Home User, and CC agent sites.

Repeat this as you study.
The first time you do this step, it might take a good 30-40 minutes. Don’t worry, you’ll get faster. Make this part of your routine, and you’ll become more efficient. One of the biggest mental hurdles I needed to get over was the fact that reading ≠ wasting time. I knew I was against the clock and wanted to skim as quickly as possible get in the damn CLI! What I found was taking this time to put together your plan of attack kept me from wasting time later on. It was critical.

Once you’re done with this step, you’ll have a full sheet that basically outlines where you’ll go, start to finish.

Step 5 – Get in that CLI, baby!

This is where you get to crack your knuckles and jump in. Start with whichever site you want to do first and get going. After doing this a few times, you ‘ll develop a method of determining what the best site to start with based on your requirements is.

From our example lab, let’s say you start with the Headquarters location. You’ll roll through these tasks, directly in order:

Once you’re done, you’ll know you completed all the tasks for HQ, and you move onto the next site.

Tasks that encompass multiple sites
Let’s go back to our eBGP example task. Let’s say you get to the first instance of this task when you’re configuring everything per-site. Depending on the task, it may be a good idea to go ahead and configure all the devices involved with this particular task. For example, you may only be configuring the HQ, but for this task, you go ahead and configure this item at all the sites. My argument will be only to do this if you can RE-USE config. You can hop in the first device, configure BGP from scratch, and the view the running config and have the exact syntax that you’ll use everywhere. Just copy, pop it in notepad and replace what variables you need to (i.e., the BGP ASN, neighbor address, etc.). This could potentially save you a few minutes, and then you can actually cross this particular task off for every site instead of just 1.

Just keep rolling
The goal here is configuration, not verification. Don’t spend too much time checking little details while moving through this. The goal here is to FINISH all the configuration items. By design, you should have a good chunk of time at the end of the exam, specifically for verification.

Step 5 – Verify and verify again.

At this point, all the configuration items that you were able to complete are done. Take a look at the left-hand column you made with the list of the tasks and notice all the ones that require verification of some sort. You can go in numerical order, or start with the most important ones.

Once you’ve gone through this a few times with separate labs, you’ll notice that you’ll start to have more and more time for this step. This is very useful, and you’ll find a lot of critical items you may have missed along the way. Here’s where you’ll match outputs, tweak routing policies, and maybe notice some little “gotchas” that you may not have picked up on the first time you read a task.

Summary

I know what you may be thinking. You just read over 1500 words about something somewhat meticulous and stressed on “saving time.” It may seem like overkill, but if you’re a person that has trouble keeping things in order, this may add some coordination to the chaos. Plus… the time is ticking on CCIE RS v5.0, so I think going in with a strict plan of attack can’t hurt you any more than it can help.

If you think it will help, work this into your labbing routine. You don’t necessarily have to do this start to finish in every single session. If you only have a couple hours to kill, start up a lab, and work your way through this. Once you get to a stopping point, you can save your progress and come right back to where you left off the next day. There were even times where I just practiced putting together the plan. I’d grab a brand new lab (or maybe one I simply hadn’t done in a couple weeks) and just do steps 2 through 4. As i said, I struggled with reading comprehension. This repetition helped me get to the point where I could have it all done in about 10-15 minutes.



MPLS VPNs – Fundamentals

Ok… I have a confession to make.  I’ve worked for an MPLS L3VPN provider for about 5 years now.  For most of that time, I did not have a real grasp on what MPLS was or how it really worked.  When I first got to digging around and working tickets I basically just thought to myself “oh, it’s just all different VRF’s.  The VRF’s separate all the routing tables for each customer.  That’s MPLS.”  I undersold it quite a bit.  But that’s the thing….  I got by with knowing just that.  I guess that’s a wonderful thing about an MPLS backbone.  You configure it once and for the most part, it just works!  I want to go over a few of the fundamentals of MPLS and how they specifically apply to MPLS VPN’s.

Purpose/General Concepts of MPLS:

The good description I’ve heard about MPLS is that it’s “a way to achieve Layer 3 routing at Layer 2 speeds.”   Update: I’ve realized with modern hardware, this statement is no longer relevant 😉  MPLS is essentially a different mechanism that can determine how routers actually forwards packets.  Instead of doing a deep inspection of the IP header, MPLS routers can make all  or most forwarding decisions based on a 4 byte header that is injected between the L2 and L3 headers.  This is known as an MPLS header.  There are instances where you will have more than one MPLS label encapsulating the L3 header, but we will get to that later.

CEF plays a big part in MPLS.  After a router has decided the best routes to put into its routing table (RIB), it then takes that a step forward with CEF and puts those into its FIB.  MPLS goes even one step beyond that and keeps track of all the label bindings for those destination prefixes and places them into something called the LFIB.

LDP:

Label Distribution Protocol is the primary way that routers can exchange the labels they have allocated for the destination prefixes.  LDP uses unicast over TCP port 646 to form adjacencies.  Routers that apply, remove, or change MPLS labels are referred to as LSR’s.  This is often referred to as “push, pop, and swap.”  By default, routers will automatically generate and advertise an MPLS label for each prefix in their routing table to be advertised via LDP when an adjacency is formed.  When the routers are advertising their local generated labels, they are essentially telling the other routers “if you have packets destined for a specific prefix, send the packets to me using this label.”  This will occur across an entire LSP or Label Switched Path.

An Edge LSR is a router that handles both labeled and unlabeled packets.   There are times that these routers will not want traffic to come in with a particular MPLS label.  For example, if a router were to receive a packet with an MPLS label and it knew that the packet would be forwarded out an interface that is not enabled for MPLS, it would have to inspect the L3 header for more information anyway.  Therefore it would prefer to receive the packet as unlabeled to reduce uneccessary processing time.  In order for the router to inform other routers to do so, it will send over an MPLS label of 3 for those prefixes.  MPLS label 3 is reserved and known as the “implicit null” label.  You will also hear this referred to as Penultimate Hop Popping.

Label Stack:

As I said before, there will be times when multiple MPLS labels are applied to a single packet.  This is referred to as the MPLS Label Stack and is very important when it comes to MPLS VPNs.  Depending on the situation, the router will most likely make it’s forwarding decision based on the outermost label, or the one at the “top of the stack.”  The router will know if the Label is the “bottom of the stack” if it has its S bit set to 1.  This lets the router know that the next thing to follow will be the Layer 3 header.

label-stack

MPLS VPNs:

So why would you need multiple labels?  The MPLS label stack is a critical piece of traffic forwarding for MPLS VPNs.   Pairing MPLS with other technologies such as VRF’s and Multi-Protocol BGP is a powerful tool for SP’s to deliver WAN services to customers.  Let’s go over these topics and how they can work with MPLS.

VRF:

In order to adhere to to the “VPN” part, there needs to be some kind of segmentation between customers.  This is where you will use a VRF, or Virtual Routing and Forwarding instance.  When you create a VRF the router creates a new virtual instance of the routing table.  In addition, only interfaces that are specifically assigned to that particular VRF are belong in that specific routing table.  What you have created it essentially a VPN.  The VRF contains it’s on control plane instances as well as the data plane is separated based on routing.  One of the most important things here is that you can have overlapping address space between VRF’s since they are all within their own virtual routing table!

Now that you have interfaces segmented into different VRF’s, how do you scale this?  If you’re a glutton for punishment and have a large network, you can do something referred to as “VRF Lite.”

vrf-simple

VRF Lite:

VRF Lite is essentially the barebones approach to using VRF’s.  In order to maintain traffic segmentation through the network, VRF’s must be locally created on every device in the path if you want correct functionality.  This is obviously not the preferred approach because of its issues with scalability and overhead.

In order to efficiently exchange routes, but still keep them within the VRF’s you have defined, you can use Multi-Protocol BGP.

MP-BGP:

Multi-Protocol BGP is a number of extensions built on top of BGP that allow you to do more than just normal exchange of NLRI’s.

Let’s take a look at one of the issues you will obviously see with our previous example of multiple VRF’s on a single router: overlapping address space.  Normal behavior of BGP consists of only advertising the BEST route for a specific prefix to its neighbors.  If you have the same prefix in multiple routing tables… how does the router know which one to advertise?  You overcome this issue by defining something with the VRF known as the Route-Distinguisher.

Route-Distinguisher:

The purpose of the Route-Distinguisher is to do just that… DISTINGUISH the route.  It is an 8 byte value that is added to the beginning of the NLRI prefix.  It must be unique per VRF.  The format is two values, separated by a colon.  Often, the format you see used is below:

  • ASN:nn
  • IP-addres:nn

However, this value is truly arbitrary and can be whatever you’d like it to be.

The combination of an NLRI prefix and it’s RD is known as a VPNv4 route.  This is what gives the router the ability to advertise the same prefix multiple times to its BGP neighbors.  Each VPNv4 route is truly unique.  For example, if multiple customer are using the 10.1.1.0/24 prefix, here is how the router will advertise each of the unique VPNv4 routes:

vpnv4-route-advertisement

Note: The RD only makes the route unique so that it can advertise each prefix to its neighbors.  The RD does NOT determine how the receiving router will inject those routes into the corresponding VRFs.  That is actually done via the route-target.

Route-Target:

The route-target is a specific 64 bit extended community value that is applied to each NLRI in BGP VPNv4 route.  This is how the VRF’s both IMPORT and EXPORT routes.  The RT is an 8 byte field that follows the same format as the RD (ASN:nn or IP-address:nn).  The VPNv4 speaking router actually only accepts VPNv4 routes that have a local VRF importing that specific route-target.  Route reflectors are the exception to this rule, as they are responsible for sending all VPNv4 routes to all routers within that AS.

You can define specifically within each VRF what route-targets they would like to import and export.  They can have multiple import and export statements if necessary.  You can also apply filters to these imports and exports if necessary via a route-map.

Capabilities Exchange:

As with normal behavior of BGP, routers must exchange capabilities in the OPEN message to determine what each BGP speaker supports.  Normally, IPv4 route exchange is enabled by default (you can disable this behavior, which is necessary in some cases).  In order for routers to exchange VPNv4 routes, or IPv6/VPNv6 routes for that matter, that specific neighbor must be enabled to do so under the appropriate address-family in BGP.  Both routers must be in agreement on their capabilities for them to send/receive these specific routes.

Provider/Client Edges:

When delivering an L3VPN for a customer, every router plays a specific role on the end to end path.  There are P Routers, PE Routers, and CE Routers.

  • PE Routers
    • Provider Edge
    • Need to be VRF aware
    • Import/Export routes in and out of specific VRFs
    • Peer MP-BGP with other PE routers
    • Peer BGP or IGP with CE routers
  • CE Routers
    • Client Edge
    • Do not need to be VRF aware, but can be in some cases
    • Responsible for taking in customer routes and sending them to PE routers
  • P Routers
    • Provider Routers
    • These are what will be seen as your “backbone” MPLS routers.  Speed is key here.
    • Not VRF aware, do not even need to run BGP
    • Only need routes for loopbacks of PE routers that are peering MP-BGP
      • Can be done with an IGP like EIGRP or OSPF
routerroles

Where does MPLS fit into this?

All the topics I just went over with respect to MPLS VPNs all had to do with route-exchange.  So how is the traffic actually forwarded?  Why do we need MPLS to form the VPN?

The need for labels comes in when you further dissect the logic that the router will use to forward the traffic.  Sure, you may have set up all the routers to exchange the appropriate VPN routes, but you did those across GLOBAL interfaces (or at least interfaces that are not associated with the “customer” VRFs).  If a packet were to come in on an interface that is no associated with a VRF, why would that router ever consult the VRF’s specific routing table?  How would it know to do so?

I previously mentioned the fact that you may have more than one MPLS label on a particular IP packet.  The concept of the MPLS label stack is not only how the router forwards VRF traffic across a global interface, but it also let’s the receiving router know which VRF the traffic is destined for.  I’ve heard these labels given a few different terms, but I’ll refer to them as the Transport Label and the MPLS Label.

  • Transport Label:
    • Generated by LDP across MPLS backbone
    • Outermost label or top of label stack
    • Used to forward traffic between PE routers
  • MPLS Label:
    • Generated by BGP
    • Innermost label, or bottom of stack
    • Used to get traffic into the appropriate VRF

So… when a router is forwarding traffic that is within an MPLS VPN, it must perform 2 label lookups, one for the MPLS label and one for the Transport label.  Let’s look a the traffic flow:

  1. A packet comes in on a VRF enabled interface.  The destination address in the IP header is inspected and compared to that VRF’s routing table for the best match.
  2. A match is found in a route learned from BGP.  This route is flagged that MPLS is required and includes the MPLS label that was learned via BGP from the other PE router.  This is your MPLS label.
  3. Now, the router needs to find the label to use for the next hop address, which is another PE router.  The router will then consult the MPLS forwarding table, or LFIB to get the label for the next hop router.  This is your Transport label.
  4. The labels are stacked onto the packet and encapsulated in the L2 frame to be forwarded to the P router.
  5. The P routers label switch based on the outermost label, or the Transport label.  Before the last P router sends the traffic to the appropriate PE router, it pops off the transport label, leaving only the MPLS label.  As we discussed before, the PE will not need the transport label, because it is the router that generated it.
  6. The PE router receives the packet and sees only the MPLS label.  The router refers to it’s LFIB and see that this particular label is an aggregate label and to consult the RIB for that particular VRF to make it’s next forwarding decision.
label-stack2

As I said, MPLS VPN’s are a powerful tool in a Service Provider toolset in order to provide scalable WAN connectivity for multiple customers.  There are a number of other technologies and caveats that come into play with MPLS VPN’s, but this post was just to cover some of the fundamentals.