Wednesday, December 31, 2008

IE Vol 1: Carrier Supporting Carrier - MPLS Enabled Complete

Nothing too fancy about this lab. About the only note worth mentioning is next-hop-self is required on the PE routers iBGP session. This is because the CE link is not advertised in OSPF, therefore the P routers don't have reachability to them. But, since we have the loopback interfaces in OSPF, the P routers have those links in their routing tables and build MPLS labels for them.

IE Vol 1: Inter-AS MPLS VPNs with Multihop MP-eBGP Complete

This was very similar to the last lab, with one fundamental difference. This time, the BGP AS border routers no longer participate in vpnv4. Instead, the MPLS PE routers peer directly via ipv4 and vpnv4.

A very interesting problem occurs because we're using MPLS VPNs. Remember that a MPLS VPN packet contains an IGP label and a VPN label. The situation encountered is as follows:

................AS1. AS2 ..............
C---PE----P-----P-----P-----P----PE---C
.................^... ^..................
..............BGP-ASBRs.............

The 2 BGP-ASBR P routers do not run MPLS on their neighboring interfaces. If we were not running VPN, the BGP-ABR router could simply pop the label, do an IP lookup, and then forward the packet to the next router.

But since we use VPN, when the BGP-ABR router pops the label, it now has a VPN label which it does not understand. Therefore, it must drop the packet.

To alleviate this, we need to ensure a single label switched path exists across both AS's.

This is accomplished with the neighbor send-label command.

Tuesday, December 30, 2008

IE Vol 1: Inter-AS MPLS VPNs with MP-eBGP for VPNv4 Exchange Complete

Wow, that title sure is a mouthful. This lab seriously threw me for a loop. No matter what I did, my provider PE routers would not load the vpnv4 routes advertised by the customer PE routers.

After playing with enough debug commands, I finally came across the following:

R2#debug ip bgp vpnv4 uni upd
*Dec 31 03:03:41.943: BGP(2): 150.1.3.3 rcvd UPDATE w/ attr: nexthop 150.1.3.3, origin ?, localpref 100, metric 0, extended community RT:1:100
*Dec 31 03:03:41.943: BGP(2): 150.1.3.3 rcvd 1:100:10.1.37.0/24 -- DENIED due to: extended community not supported;

Huh? What does it mean extended community not supported?

As it turns out, extended communities, by default, are not accepted from eBGP peers. This is the first lab that I've tried to exchange vpnv4 routes across eBGP, so it's the first time I've run into this.

The command to enable extended communities across eBGP peers is no bgp default route-target filter. The details can be found here.

IE Vol 1: Inter-AS MPLS VPNs with Back-to-Back VRF Complete

Things are starting to get really complex. I was stumped a few times on this one and had to look at the answers. Most of my problem involved incorrect assumptions about bgp vpnv4.

Prior to this lab, the general rule has been to only peer bgp vpnv4 with PE routers. But in this lab, two separate bgp ASs are peering separate vrf's over separate interfaces. Rather than two providers sharing routes over vpnv4, they split them over the interfaces as ipv4 neighbors.

So it actually ends up with each provider's edge router actually acting like a CE router and a PE router at the same time. Each provider is each other's customer.

I guess this is what back-to-back VRF means. Rather than sharing the vpnv4 information across bgp, we strip the rd information out, but dedicate a subinterface for each vrf. Then on the other side of the link, the router loads the routes back into bgp and reconstructs the vpnv4 routes.

Why do it this way? One reason seems to make sense--what if you need to carry MPLS VPNs across separate providers but each provider is using different route descriptors? This would allow each provider to load their own rd when the routes are imported. If vpnv4 routes were shared, rd's would need to be consistent across the entire path.

Monday, December 29, 2008

IE Vol 1: Carrier Supporting Carrier - IP Only

In this lab, the goal is to segment one AS (something like a tier-2 carrier) with another AS (a tier-1 carrier). It's quite interesting how this ends up working out. The Tier-1 carrier becomes the P network, and the tier-2 carrier becomes the C network. iBGP relationships can still be formed by CE routers across the P network, since as far as the CE routers are concerned, the routes are all being learned via OSPF. The entire separate AS is completely transparent to the C network.

There really wasn't anything particularly challenging about this lab, there was just a lot going on. It's definitely required to build each piece step by step and verify along the way. A simple missing mpls adjacency, ospf neighbor, or bgp next-hop-self missing could make troubleshooting really difficult.

The mpls verification was quite interesting. On the PE routers, a separate MPLS adjancency is actually formed inside of the vrf. To check this, the commands sh mpls ldp neigh vrf VPN_A and sh mpls for vrf VPN_A are required.

Aside from that, I had to go back and do a couple of redistribute connected's into bgp. This was required so that I could ping from the outgoing interface rather than the loopback of the true customer routers.

IE Vol 1: VPNv4 Route Reflection Complete

This was an interesting lab that took a heck of a lot of time to just reconfigure the topology.

Essentially, the configuration ends up with two separate route reflectors--one for ipv4 routes and one for vpnv4 routes. Amazingly, no real complex configuration is required. There's no need to mess with clusters or anything like that. Instead, simply configuring the route-reflector-clients under vpnv4 instead of directly under the bgp process takes care of it.

I did run into two issues due to simple mistakes. First, one of my PE routers showed all MPLS labels as being untagged. This was due to me forgetting to turn on cef on one of the P routers.

Second, one of my CE routers was not learning any RIP routes. This issue actually threw me for a loop for a bit. It turned out that on the PE router I didn't set RIP to version 2 under the appropriate address-family. By default, rip sends version 2 and receives versions 1 and 2. But when version 2 is specified, rip only sends and receives version 2.

Since the PE router did not specify, it received the version 2 routes from the CE router and entered them into the routing table. It also redistributed its bgp routes into RIP and sent them as version 1.

Since the CE router specified version 2, it ignored the version 1 routes sent by the PE router.

Wednesday, December 24, 2008

IE Vol 1 OSPF Domain-id complete

This was another interesting lab. Typically in MPLS, redistribution is done from OSPF to BGP and back to OSPF in order to connect OSPF together across the P network. Because of the redistribution, OSPF sees the remote sites as External (LSA type 5) networks.

But since these remote sites are likely to be within one company's control, having them marked external may not be the best option. Instead, the domain-id can be used on the PE router under the ospf process. When the PE router advertises the ospf route to the CE router, it looks at the domain ids of both routes. If they match, the ospf route is advertised as an inter-area (IA) route instead of an External route.

This seems like it would be important for a couple of reasons. IA routes are always preferred over E routes. Also, E routes are not advertised into stubby areas, while IA summaries are. In more complex scenerios with a mix of nssa areas and redistribution, a company may prefer to use its provider's MPLS network rather than another non-MPLS link. The domain-id allows for this much easier than filtering routes from the edges.

Tuesday, December 23, 2008

IE Vol 1 OSPF Sham Links Complete

This was an interesting lab on two levels. It was the first time I have configured isis and ospf sham links are an interesting subject.

I was really amazed at how easy it is to configure a simple instance of isis. Just configure a net address and throw isis on the interfaces, optionally set the interface type, and it's complete. No issues there.

OSPF sham links, on the other hand, I found to be a a much more complicated subject. Its purpose is to deal with a customer that has non-MPLS links neighboring via OSPF, yet the customer still wants to route this traffic over MPLS.

Once these OSPF routes hit BGP, they are seen as iBGP routes, which as an AD of 200, as opposed to the OSPF AD of 110. This means if the prefix-length and default AD is the same, the OSPF route is going to be entered into the routing table.

To prevent this, an ospf sham link must be created. This is configured by setting up an additional loopback interface on the PE router and adding it to the customer VRF. Next, these loopbacks need to be redistributed into the bgp ipv4 vrf. Once the loopbacks are reachable to each other via the P network, under the ospf vrf process, enter area 0 sham-link source-ip dest-ip. This, somewhat similar to a virtual-link, creates a logical link between the newly created loopback interfaces. Then, the path is seen via ospf rather than bgp and the MPLS route can be preferred over the customer link.

Monday, December 22, 2008

Study Plan

The following is a rough draft of my SP Lab study plan. I don't have a date set yet so this will become more precise once I do. I plan (so far) to use Internetwork Expert for all of my studying. The basic timeline that was successful last time was 1 month of studying one practice lab per week, and then two months of two practice labs per week leading up to the actual lab.

Already completed: Volume 1 MPLS VPN labs.

Week of 12/21: Remaining Volume 1 MPLS labs.
Week of 12/28: Volume 1 Multilcast labs.

1/4: Volume II lab 1
1/11: Volume II lab 2
1/18: Volume II lab 3
1/25: Volume II lab 4
1/31: Volume II lab 5

2/1: Volume II lab 6
2/7: Volume II lab 7
2/8: Volume II lab 8
2/14: R&S Graded Mock lab
2/15: Volume II lab 9
2/21: CCIE Assessor R&S
2/22: Volume II lab 10
2/28: R&S Graded mock lab
2/29: Repeat of one of the Volume II labs

So this puts me taking the lab sometime in March. Hopefully I can find a date around there. I'm still waiting for my exam to clear the CCIE site so I can see what dates are available. I should know within the next day or two.

SP Materials, and lack thereof

I don't have a lab date setup yet, but hypothetically I'd like to take the lab around April. I know from R&S that I need a good three months to prepare.

There are only 10 full Volume II labs in the Internetwork Expert labs, as opposed to 20 in the R&S curriculum. I wouldn't expect this to be too much of a problem since I really only went through 10 of the full workbook labs for R&S anyway.

That leaves 3 main gaps to cover. In R&S I relied heavily on a one week bootcamp, about 5 graded mock labs, and the CCIE Assessor.

In actuality, those three pieces were the most helpful to get me ready to tackle the CCIE itself, rather than specifically R&S material. So I think I can still take a couple of graded R&S mock labs to ensure my accuracy is ok. I'm hoping I won't need a bootcamp this time around, but I'm open to it depending on how the studying goes.

SP Community

Thanks to everyone for their positive comments over the past week. It's nice to see there are few others out there working on SP as well. Sometimes this feels like the loneliest CCIE since there's an absence of graded mock labs, groupstudy forum, and not many posts in the other forums out there. The rest of the non-R&S CCIE world seems to be working on Security or Voice for their second.

Good luck to Route Target as well, who will be taking his SP lab in February.

Passed CCIE SP Written 350-029

I thought I'd take a stab at the SP Written before year's end. I've heard rumors that this exam wasn't nearly as nasty as the R&S Written.

There was the standard 10-20% of questions that were just plain ridiculously hard. Aside from those, I'd say easily 50% of the exam is pretty basic to anyone with a CCNP and CCIP level of knowledge. Heck, quite a few of the questions were more on the CCNA level to be honest.

So that leaves the remaining 30%. They were difficult but strangely it was pretty easy to weed out the wrong answers. The usual questions such as, "Pick the best 4 out of 6". I'd have no idea about the 4 to pick. But two obviously didn't belong since they were part of a different technology altogether.

As far as written exams go, I'd rank them as follows in order of difficulty:

BGP+MPLS: 10
R&S Written: 9
Remaining CCNP and CCIP exams: 8
SP Written: 7
CCNA: 5

That's how I feel. If you know the CCIP and CCNP material, 50% the questions on the SP Written exam are actually easier than what's found in the professional level. So if you can deductively eliminate incorrect answers and get lucky on a few of the other half of the exam, you should be able to pass it.

And now it's time to begin studying for the lab. I'll put a study plan together in the coming days. I'm hoping to shoot for my first attempt in April or May.

Friday, December 19, 2008

From CCIE R&S to CCIP

While it's still fresh in my mind, I thought I'd put a little guide together for those who already have their R&S CCIE and want to work on the CCIP. One of the struggles I've found is there is very little study material out there geared directly toward the CCIP, aside of course from the exams that overlap with CCNP and CCVP.

I'd recommend taking the exams in the following order:
1. BSCI. If you already have a CCNP, you may have already passed the exam. I do find it strange that a CCIE R&S doesn't waive this requirement. I last passed the BSCI in 2002, so I needed to retake this. The only topic in the exam that is not really covered by R&S is IS-IS. This is a topic on the service provider blueprint, so take the opportunity to get some studying done on it.

2. QoS. You should already be pretty familiar with QoS from the CCIE R&S.

3. For the brave, go for BGP+MPLS. I will definitely say I found this to be one of the toughest exams I've taken. It's certainly up there on the CCIE Written calibur of exams. There are lots of very tricky questions that you have to pay close attention to. There's also an abundance of questions from obscure topics that I would have expected to be a small part of the exam.

4. Otherwise, go for BGP separately from MPLS. I did take the BGP exam as well, and found it to be MUCH simpler than BGP+MPLS. Of course having a CCIE R&S means you should already know BGP pretty well. Now I never did take the MPLS exam, so I cannot comment on it.

For BGP+MPLS, the following resources are very helpful. Make sure to know them inside and out. There were some more obscure topics that I could only find covered in the these links.

MPLS Virtual Private Network Enhancements
BGP Case Studies
Cisco Express Forwarding Overview
Configuring Cisco Express Forwarding
BGP: Frequently Asked Questions
MPLS Configuration on Cisco IOS Software (Book)

Also make sure to spend some time on MPLS technology labs from your vendor of choice. Internetwork Expert has a great price on an SP bundle, which includes Class on Demand.

Good luck!

RFC 3439

I'm normally not a big fan of reading RFCs. Aside from the funnier ones I've provided links for to the right, I tend to find them way to dry and academic. Short of pulling some information out, such as the meaning of a particular field in TCP, I almost never even look at RFCs.

In the SP Written blueprint, Cisco specifically mentions RFC 3439. Amazingly, I'm finding it very readable and interesting.

http://www.rfc-archive.org/getrfc.php?rfc=3439

Thursday, December 18, 2008

Finally! CCIP Complete!

I finally managed to pass BGP+MPLS tonight. I figured out most of the trick questions and brushed up on the topics I needed to and finally got through this. It took me a whopping 5 attempts to pass! I've never needed more than 2 attempts to pass an exam before. Not even the R&S CCIE lab itself.

Now it's time to start working on the SP Written. One look at the blueprint and I'll need to focus on the following topics:

  • Service Provder Network General
  • ATM, POS, DPT/RPR
  • ISIS
  • High Availability
  • High End Product

Friday, December 12, 2008

Holding Pattern

Since it's taken me so long to get the CCIP, I went ahead and took 350-001 again to recertify my CCIE. I just squeaked by, but I didn't study at all for the exam. I still find that exam particularly annoying.

So I've been back an forth trying to decide if I want to even bother with the CCIP or not. I think I'm going to take another stab at either the MPLS exam or the BGP+MPLS exam. I just don't feel up to studing for the SP written yet.