Tuesday, November 18, 2008

MPLS VPNs with BGP Site-Of-Origin Complete

This was an interesting lab that took a bit of research for me to understand what was happening.

When we use as-override, the intention is to work around the loop prevention mechanism of eBGP so that a CE router will accept a route from another CE router with the same AS.

But sometimes that loop prevention mechanism is still needed. This typically occurs when two CE routers have a backdoor (i.e. non-PE) connection to each other, in addition to the PE connection.

Such a connection can create a routing loop when used in conjunction with as-override. This is because the PE router strips the originating AS and then advertises the route back out to the other CE. This CE router has no idea that this is the same route it is learning from its backdoor neighbor, so a routing loop can be created.

To prevent this, the site-of-origin (soo) extended community can be set via a route-map. No filtering is required, everything happens automatically once it is set. When a PE router learns a route with an SOO set, it will not advertise another route with the same SOO set to its CE neighbor.

The catch to this is that the backdoor route cannot be used as a redundant connetion to the other CE router. If the MPLS connection drops, traffic cannot be rerouted dynamically through the other CE router.

To check if SOO is set on the PE router, use sh ip bgp vpnv4 all X.X.X.X

Monday, November 17, 2008

MPLS VPNs and VRF Export Map Complete

The Export Map allows much more granular control over which networks get advertised to which vpnv4 prefixes. There's a great example at http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_e1.html#wp1012602

I learned a bit more about the order of operations of MPLS during this exercise. I mistakenly forgot to import the route-targets on R3. During troubleshooting, I noticed that the routes that were supposed to be imported were not present in sh ip bgp vpnv4 all. Apparently this table does not get populated until the specific route-targets are imported by a vrf.

Sunday, November 16, 2008

MPLS VPNs with Extranets Complete

I was pretty surprised I got this one right the first time. It's simply a matter of getting the route target imports and exports correct.

I think I'm still a little fuzzy on the transition from an IP address to a route descriptor to a route-target, and how they all interoperate with routing protocols and redistribution.

This lab did help to tie it together somewhat. I suppose my understanding is that it goes something like this:

When an interface is setup for vrf forwarding, it is no longer part of the global routing table. Instead, the router performs a lookup to get more details about the vrf that the interface is an instance of. It goes to the vrf configuration and finds the route descriptor, which is uses to relate this interface to IGPs and ipv4 BGP. Then, it sends out a BGP vpnv4 route for each export target. These export targets get flooded throughout the BGP vpnv4 peers, which should encompass all PE routers. Finally, with these vpnv4 routes flooded, the import route-target is used to load the remote vpnv4 routes into the particular vrf routing table.

Saturday, November 15, 2008

Central Service MPLS VPNs Complete

I found this lab really neat. They had me go back to RIP as the PE-CE routing protocol, which was nice to help me commit the syntax to memory. The trick this time was I had to create 4 different vrf's and allow the R5 vrf to act as a central services VPN. This acts kind of like a promiscuous port in switching terminology: all the other vrfs can access it, but individual vrfs are isolated from each other.

The interesting part here is I finally got to play around with import/export route targets. It actually worked pretty intuitively. Under the R5 vrf, I configured it to import and export all of the other route-targets. Once RIP propagated about 30 seconds later, everything magically worked. That was all there was to it. Way too easy.

The solutions guide specified to import R5 into the other 3 vrfs, instead of exporting to the other vrfs from R5. It appears to be 6 one way and a half dozen the other, but I do wonder if there is a standard to try to import when possible. Sort of like in an access-list it's a good idea to set it up inbound. This makes sense on an access-list because filtering it ingress saves processor time and bandwidth utilization.

MPLS VPNs with eBGP Complete

Two interesting pieces to this lab.

First, when a route comes in from a CE router, it has its AS listed in the AS path. The route crosses the core to the far end PE router, where it gets advertised out with the original AS number along with the PE AS number. The the CE router receives this, it drops the route because it sees its own AS number in the path.

To prevent this, the neighbor as-override command is placed on the PE ipv4 address-family. This command advertises the routes to the CE router with only the PE's AS in the AS path. This way the CE router does not drop the routes coming from the other PE router.

The second issue I ran into is that I needed to redistribute connected into the PE bgp address-families. I was a little confused as to exactly why, even though the CE routers could only ping each other if this was present. So I removed it to see what was happening.

Here's the BGP table with the redistribute connected removed from the R6-SW2 address-family:
Rack1R3#sh ip bgp vpnv4 all
BGP table version is 74, local router ID is
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1:57 (default for vrf R5-SW1)
*>i10.1.5.0/24 0 100 0 100 i
*> 0 0 100 i
*> 0 32768 ?
*>i10.1.45.0/24 0 100 0 ?
Route Distinguisher: 1:68 (default for vrf R6-SW2)
*>i10.1.6.0/24 0 100 0 200 i
*> 0 0 200 i
*>i10.1.46.0/24 0 100 0 ?

Note there is not a route to in BGP. But who cares? And then it dawned on me.

When we ping, the router uses the IP from the outgoing interface, unless a different ip is specified during the ping. Sure enough, pings work fine when sourced by the loopback address, since that is contained in the BGP table. But when the ping is sourced from the outgoing interface, BGP doesn't have a route to it.

This wasn't an issue with RIP, OSPF, or EIGRP, because IGPs automatically add the interface that the protocol is running on to the routing table. But BGP does not do this. It only adds routes specifically injected via the network command, or routes redistributed into BGP.

To prove the theory, I'm going to use a network command for the connected interface rather than redistributing connected. I typically prefer not to redistribute so I can avoid ugly RIB tables.

Sure enough, that did the trick. And note how the origin is internal for the network'ed route as opposed to unknown for the redistributed route.

*>i10.1.38.0/24 0 100 0 i
*> 0 32768 ?

MPLS VPNs with EIGRP Complete

Nothing too challenging with this lab. EIGRP is configured similarly to RIP where address families are named under the EIGRP process. What is interesting is that different autonomous system numbers are used for each EIGRP vrf.

Friday, November 14, 2008

MPLS VPNs with OSPF Complete

I'm getting faster and faster at these. OSPF was pretty straightforward, there was probably just one oddity I found.

When redistributing BGP into OSPF, there's no need to mention the VRF name since OSPF can figure that out by the OSPF VRF.

However, when redistributing OSPF into BGP, you do have to explicitly put the VRF name in addition to the process number. It would seem to me that BGP should be able to figure out the VRF name from the address family.

MPLS VPNs with RIPv2 Complete

Wow, I actually am getting better at this MPLS stuff. When moving from static routes to RIP, the complexity increases greatly. It's a good thing RIP itself is such a simple protocol.

So the main difference here is that address-families must be created under global RIP process. All the configuration is then applied under each RIP address-family. I found it very interesting at first that none of the redistribution in BGP or RIP requires the naming of the address-family. The router is smart enough to keep track of all this based on the address-family it is under, and the vrf assigned to the interface.

For example, when I first configured RIP, I was concerned about the network statement. Being that multiple interfaces fell under, I thought all of the interfaces would be advertised into the particular address-family of RIP and that I'd have to use passive-interface or filtering to block them. Nope. The router only advertises the interfaces that have the vrf of the applicable address-family. Makes perfect sense, and makes my life a lot easier.

I also got stuck for a bit because I couldn't find the RIP routes getting distributed into BGP. Turns out I needed to use sh ip bgp vpnv4 vrf instead of sh ip bgp. Makes sense, as I needed to see the routing table of the vrf instance, not the global bgp table.

I'm feeling a lot better about MPLS VPNs today, and have a better understanding the significance of route descriptors as well.

Thursday, November 13, 2008

MPLS VPNs with Static Routing Complete

Points to remember when configuring MPLS VPNs:

First create the vrf and associate the rd and import/export rules
Next assign the interfaces to the vrf and reapply IP addresses
Then configure the BGP vpnv4 address family, activating the other PE router and send both communities
Also under BGP, configure the ipv4 vrf address family, redistributing as appropriate
Finally, configure any necessary ip route vrf's.

Use show ip route vrf *, show ip bgp vpnv4 all, and ping vrf to verify connectivity

I really need to commit to memory when to use the vpnv4 address family and when to use the ipv4 vrf address family. It makes sense conceptually. The vpnv4 family includes the extended communities, and basically acts as a type of tunnel between PE routers. Then, each ipv4 vrf is like a pvc inside of that tunnel. Finally, the vrf itself describes what routes get leaked between each individual vrf.

The router uses rd's to keep track of vrf's. We use the vrf name to associate the vrf with interfaces and bgp.

The router uses rt's to advertise vrf's across vpnv4 through the use of extended communities.

SP Volume I Basic MPLS Complete

The biggest challenge here was in getting Dynamips up and running and configured. Fortunately, IE has a great guide which saved me a lot of work. I first tried to run it in Windows, but the performance was too poor. So I switched to Linux, and I can get the Vol I equipment up and running just fine.

The Basic MPLS lab was just what it says. Just needed to throw OSPF and BGP on a few routers and then put MPLS on the core. It was a nice exercise just to watch the pings propagate even though the core routers don't have a route to the final destination.

I had two mistakes in my configuration that I was able to correct pretty quicly. First, I missed mpls ip on one of the interfaces. Because it was missing, some of my hops were untagged in the mpls forwarding table. Simply checking the mpls neighbors at each router pointed me to the issue pretty quickly.

The second mistake was that I didn't put next-hop-self on the PE routers. This is necessary because the core needs a route to the next BGP hop, just not to the final destination. By deafult, iBGP does not update the next-hop and leaves it as the first eBGP hop.

Monday, November 10, 2008

My New MPLS Strategy

Now the other 3 CCIP exams are out of the way and it's time to focus on MPLS. I usually pick up networking technologies pretty easily, but there are a few in the past I have had a hard time with. One of those, in particular, was BGP.

This is one of my favorite responses to one of my groupstudy posts when I was struggling with BGP and another member made a humerous analogy to learning BGP from a book.

I have to agree with that to a certain extent. I was completely clueless on BGP a few years ago, eventhough I read Internet Routing Architectures cover to cover at least twice. It wasn't until I performed enough complex redistribution labs and worked with it in the real world before I got my arms around it.

I now seem to be having the same struggles with MPLS. I have the fundamentals more or less memorized, but I don't really understand the how's and why's of what's going on. I think that is what's keeping me from getting through the MPLS exam.

So rather than continue to brute force the exam, I've decided to pick up the InternetworkExpert Service Provider material. I'm hopeful reviewing their Class on Demand and working through their techonology labs will help to get me up to speed.

Thursday, November 6, 2008

A Little Redemption

I passed the BGP exam today with a lot of room to spare. There were a lot more questions on this than on the BGP+MPLS exam, with a lower passing score to boot. A few of the questions were tricky, but for the most part they were pretty much what I was expecting.

So on the bright side, I now know I was doing pretty well on the BGP portion of the BGP+MPLS exam. The problem with this is I was doing a heck of a lot worse on the MPLS portion. If my scores were similar, that would mean I must have been getting approximately 50% on the MPLS portion of the combined exam.

Now it's time to focus on MPLS. I've tried just reading books and that doesn't seem to help it sink in. I ran into the same thing with BGP a few years back and just didn't "get it" until I did enough labs. It may be time for the same approach with MPLS.

Wednesday, November 5, 2008

The (Alleged) Recession's Impact on CCIE Numbers

With the performance of the stock market and layoff announcements rising, even though it's not official yet I think it's pretty safe to say the US has been in a recession for at least the past quarter.

The question I ask is, does a recession make more or less people attain their CCIE? I could see two possibilities here. First, perhaps the fear of a tightening job market would drive some to get this certification knocked out. On the other hand, having less money to pay for training and lab attempts, along with perhaps a lower possibility of rewards from passing, may cause some to put the CCIE on the back burner.

Between March and September, the rate of attainment of new CCIEs was 9.7 per day. According to InternetworkExpert.com, their latest CCIE number as of November 5th was 22542, vs 21910 on September 3rd. Therefore, over the past two months, this equates to 10.0 CCIE numbers awarded per day.

Now this is hardly a scientific study, since I don't have access to the exact amount of CCIEs given out on a particular day and I'm comparing a 6 month timeframe to a 2 month timeframe.

But it certainly does appear that this global economic slump is having no effect, or even a slightly positive effect, to the attainment of new CCIEs.

BGP Exam 642-661

I'm gonna take a stab at this exam sometime this week, possibly as early as today. From looking at the exam topics I just couldn't imagine having too much difficulty with this. Aside from ORF and Hierarchical Route Reflectors, I have quite a bit of experience on the rest of items.

I hope I can pass this today and get myself back on the right track.

Monday, November 3, 2008

I have been defeated by BGP+MPLS

Today I failed BGP+MPLS for the 3rd time. During the exam I thought I had it this time. Many of the questions were repeats and I felt pretty good about the answers. I did do better this time, but I wasn't quite there.

I'm throwing in the towel on this one. I'm pretty sure what's killing me is that I just don't have the practical experience with BGP.

Jumping in to CCIE studying would certainly give me the hands on. I was hoping to use the CCIP to springboard into that, and to be honest I feel like it has already served that purpose. I understand the concepts of MPLS pretty well, I think it's just some of the peculiarities that are throwing me off.

So what now? I've had it with this exam and I'm giving up on it. I was hoping to be into CCIE SP studying by the end of this month. I really want to recertify my CCIE R&S by the end of the year as well.

That basically leaves me with three options:
  1. Take the BGP and MPLS exams separately. I think that would be helpful because the score reports should be a little more granularized. That way I should at least know what my weaknesses are. The BGP+MPLS score report is pretty vague.
  2. Take the R&S CCIE Written again to renew my cert and then decide what to do next.
  3. Jump straight to the SP CCIE Written. I might end up failing it repeatedly as well.
  4. Jump straight to studying for the CCIE Lab. I should get enough hands on experience with MPLS to come back and knock out the CCIP after a little while with it. Of course once I'm a month or two into labbing it up on the IE, I probably wouldn't want to bother backtracking for the CCIP.
I think I'm going to knock out the BGP exam because I shouldn't have any problems with it. Then, depending on how that goes, I'll regroup from there.