powmia's CCDE marathon

flashdumper

powmia wrote: »

To add to this.. and to agree w/ flashdumper. This is exactly what the CCDE is all about. Anyone can memorize best practices. Throughout your career; sure, you'll see poor designs, but you'll also correlate the proper ones with the documented best practices. Eventually, it's easy to get the idea that "this is how it's done, because it's a best practice..." without understanding why. The exam is all about understanding not only why something is done that way, but why it isn't done other ways. You need to understand the other methods of designing a technology, what their pros and cons are, and how you can modify them accordingly to any situation... basically, you need to understand the technology, not just pull out the cookie cutter.

Going back to the iBGP example above. The exam is based on real life, and in real life.. those edge routers might be 1000km apart and you have a customer that tells you they don't want a direct circuit between them, for whatever reason (usually a dumb reason, and that's what you'll see in the exam).

Basically, before u answer the 1st question, be sure that u know the answer on the next ones, which are "why did u pick that?" and "how do u implement this?".
As I said, this exam is tricky, u must answer what is right for the business. And if later on your scenario will go another way around, that doesn't mean u was wrong, it means u have a dumb customer that doesn't follow your advices


And yes, u forgot to add that u shd analyze reeeeeealy fast these situations, like a lightning

Master Of Puppets

I'm sure you'll get it next time. Now you know what the exam is like.

powmia

Went ahead and knocked out the CCIE SP written yesterday. No preparation needed to sail through the IS-IS, OSPF, BGP, MPLS, QoS, etc stuff.... pretty sure I didn't get a single platform specification question right, though. Contacting your AM wasn't an option on those questions.

I've also gone through about 1/4 of the INE ATC videos. The material is pretty much just foundational... covering the common topics and basic config. They assume you already have a CCIE R&S, so I can understand not going in-depth on OSPF, LDP, or BGP. I would have thought, however, that they would have covered IS-IS a bit better. I'll probably just see a flat level-2 domain in the lab, but an expert in SP technology should at least have seen overlapping level-1/level-2, overlapping level-1s, backdoors, and mesh-groups. Still... I just need to see the config going in front of my eyes so that I mitigate some potential brain-farts and have my speed up when I take the lab... so I think the INE stuff will be good for me. I'm just watching the videos straight through, then I'll do the workbook start to finish, then I'll take my lab.

Anyways... this is still a CCDE thread, so I'll try to keep it that way. Aside from the IE SP stuff, I'm reading Data Center Virtualization Fundamentals, working on a Europe-wide Telepresence deployment and an OSPF mulligan for one of our campuses. It will definitely take a conscious effort to make time for some SRNDs... but don't worry, anything design related will make its way here.

powmia

Anyone want to chime in with option B?

flashdumper

Option A solution used for different ISPs interconnection. That way you don't mess up with both ISPs IGP & MPLS.

flashdumper

Option B is something like this.


Cons are:
Each AS must have loopback interfaces through eBGP, which could be not an option in some cases.
Multiple LSPs, which implies more processing, lookup, push/pops.

Pros:
Much more scalable solution, comparing to Option A.
No VRFs on the ASBRs,
Only ASBR keeps VPNv4 labels

powmia

Thank you much... I would consider the biggest issue with Option B, to be that your IPv4 convergence at that peering point will take a hit from the added resource load on the ASBR.

Here's C.

flashdumper

Naaa, Option C doesn't look like this.
I'll draw it just a bit later.

flashdumper

This is Option C

powmia

The difference being...?

flashdumper

ye, u have BGP+Label going all along the path, with no basic MPLS IGP within ASs.
and u shd run BGP+Label only between ASs

powmia

That would be because there are two different ways to accomplish Option C. You need the LSP to be end-to-end, which means your PE routers need transport labels to reach the PE routers in the other AS.

Option C-1: Redistribute the other PE host routes into your IGP and let LDP generate the labels for them. This is more simple, because it essentially requires the configuration of only a single device.

Option C-2: Use iBGP+Label to give your PE routers the transport labels for the remote PE. This requires the enabling of send-label on all of your iBGP peerings.

Option C-1 is probably what I would do in the CCIE SP lab, because it's the quick and dirty method. Option C-2 is what I would go with in the CCDE, though. It gives you much more granular control over the /32 propagation and their associated label allocation. It is also exponentially more scalable. The entire point of going with Option C over Option B is the increased scalability. So you're going to redistribute all of those PE host routes into your IGP? In the real world, if two providers (whether they're two actual providers or just two geographic regions of one provider) were to have a blanket agreement that they were going to share all /32s in order to support VPN connectivity for anyone in the future... that means adding a couple thousand /32 routes into your IGP. Given that an MPLS core is essentially nothing but a provider of reachability to PE routers anyways... why don't you just merge the two ISPs IGPs and call it a day

flashdumper

I can say that to connect two ISPs ppl usually using Option A. It's not scalable, but this is what's going on all over the world.
About scalability of Option C-2 I strongly don't agree with you. You MUST enable BGP+label on all of the links, between all the peering routers all along the path. This is a FULL MESH topology and it equals to NOT-SCALABLE one.
This topology requires too much configuration and due to multi hop iBGP nature u still must use LDP, or u'll have ridiculous iBGP peereings over each and every link...

U can make it working but in some very specific scenarios, but I can't imagine any.

You say that that way u have much more granular control over /32 routes. But what for do you really need that /32? For one solid LSP, right? And what for do you really need that one LSP? The answer is less processing on the CORE.
So that way you choose between less processing or less trust between the boundaries. I mean u choose between option B and Option C.

The better picture of how these Options work comes when u'll configure it and understand step by step processing of Control and Data planes.
I can show u that on Dynamips, of course it'll take several hrs to configure it but it worth of it.

powmia

I've configured them both once or twice... or some multiple of that. I don't think I need a tutorial.

The use of LDP and an IGP is implied. Obviously, you are running those internally. The iBGP + label is only used for PE loopbacks that are not in the local AS.

Did you think I was saying to not run LDP internally at all?

powmia

Best breakdown of the iBGP+Label functionality for Option C that I can find:

JunosE 14.3.x BGP and MPLS Configuration Guide

There is plenty of documentation out there that uses Cisco parlance to show both methods for Option C.

flashdumper

ur Picture is telling it, and there's no mention about LDP in Option C-2 at all.
So, ye, I was thinking that u're not running LDP at all... and it's possible

If u'll be running BGP+label on top of LDP, then it makes some sense and it will work, but i didn't see anywhere implemented or suggested.
With that solution u r adding complexity to complexity, which isn't recommended, but still valid.

About scalability. I think thinking that Option B is much more scalable than this Option C, because with Option C u have to have full table of PE's Loopbacks. And if u have 10000 PEs among several SPs, this is not an option. With option B though u r limiting next-hop to AS boundary and number of LSPs/Loopback-routes that way. Don't u agree?

flashdumper

powmia wrote: »

Best breakdown of the iBGP+Label functionality for Option C that I can find:

JunosE 14.3.x BGP and MPLS Configuration Guide

There is plenty of documentation out there that uses Cisco parlance to show both methods for Option C.

I took a look at that implementation. it's much more complicated. It has 3-label stack in the path. Usually u'll see 3 labels with CSC, RSVP, MPLS-TE.

powmia

Yep, my diagram was about as specific as it would be in the CCDE lab I was just worried about the BGP control plane... at least I tricked you into putting more good info in this thread

I don't agree. With Option C, you are using the RR to exchange VPNv4/6 routes. With the ASBR receiving IPv4 + Label prior to sending to the internal RR, you can filter the loopbacks that you are receiving routes for at this boundary. Even if you were accepting all /32s, it will typically be a drop in the bucket compared to the amount of NLRI in the full VPNv4 table (Option B to Option C comparison). The router with the eBGP peering doesn't get to selectively keep only the VPNv4 information that pertains to its locally configured VRFs as the remaining PE routers do. The scalability of Option C vs. Option B comes from the fact that you are taking a device (router or server) that is out of the forwarding path and typically installed with the sole purpose of being a RR as opposed to an ASBR that will typically be nothing more than a standard PE router.

If you go through it, the ONLY difference between the two sub-options of Option C are that one method has all of your PE routers learning remote PE addresses through an IGP, while the other method has them learning those same addresses through iBGP. It is obvious that BGP is more capable of handling an increase in routes than an IGP is.

I don't see how it's possible to say that one method of implementing Option C is more scalable than Option B, while the other method of Option C is less scalable than Option B.

powmia

flashdumper wrote: »

I took a look at that implementation. it's much more complicated. It has 3-label stack in the path. Usually u'll see 3 labels with CSC, RSVP, MPLS-TE.

Yes, it is much more complicated. We both agree, you will rarely see anyone implement Option C at all... or B for that matter. If you're going through the complexity of implementing Option C in the first place, you might as well go all out and just make it efficient.

Like I said, from a design standpoint, I would go with the iBGP + Label. When I take my CCIE SP, I will avoid that and just redistribute with route-maps.

My opinion only. Of course, I'm sure in the CCDE there would most likely be a statement somewhere in the documentation that hints at one method versus the other for something like this.

flashdumper

powmia wrote: »

Like I said, from a design standpoint, I would go with the iBGP + Label. When I take my CCIE SP, I will avoid that and just redistribute with route-maps.

And you fill fail the exam that way

flashdumper

powmia wrote: »

Yep, my diagram was about as specific as it would be in the CCDE lab I was just worried about the BGP control plane... at least I tricked you into putting more good info in this thread

I don't agree. With Option C, you are using the RR to exchange VPNv4/6 routes. With the ASBR receiving IPv4 + Label prior to sending to the internal RR, you can filter the loopbacks that you are receiving routes for at this boundary. Even if you were accepting all /32s, it will typically be a drop in the bucket compared to the amount of NLRI in the full VPNv4 table (Option B to Option C comparison). The router with the eBGP peering doesn't get to selectively keep only the VPNv4 information that pertains to its locally configured VRFs as the remaining PE routers do. The scalability of Option C vs. Option B comes from the fact that you are taking a device (router or server) that is out of the forwarding path and typically installed with the sole purpose of being a RR as opposed to an ASBR that will typically be nothing more than a standard PE router.

If you go through it, the ONLY difference between the two sub-options of Option C are that one method has all of your PE routers learning remote PE addresses through an IGP, while the other method has them learning those same addresses through iBGP. It is obvious that BGP is more capable of handling an increase in routes than an IGP is.

I don't see how it's possible to say that one method of implementing Option C is more scalable than Option B, while the other method of Option C is less scalable than Option B.

OK, I finally got ur point! It makes sense!

But then again from the scalability and complexity point of view... It's better use Option C-1 rather than C-2, coz that way you can avoid over-configuration and redundancy of the label distribution protocols and still save scalability of VPNv4 labels propagation through RR MP-BGP peering.

flashdumper

Man, r u alive or being dead?

Ismaeljrp

flashdumper and powmia, thank you so much for motivating me indirectly to keep on learning. This is way ahead of me right now, but it's really great stuff. Can't understand much as most of it are protocols I haven't even started to learn about, but it is highly motivating.

powmia

I'm alive, but feeling a bit dead... zombie? :P In-laws have been staying with us for the past two weeks. Work, entertaining, and still trying to squeeze in a bit of study have left me with no time for this thread. I'll be back at it soon enough, don't worry

powmia

Oh, and one of our sites had two of their 6509s crash this week from an STP loop. I don't get to troubleshoot too often, so that was a fun one.

flashdumper

6509s in a loop! Nice! They shd lay down the network and keep themselves alive

powmia

The customer carrier wants to encrypt all of their customer VPN traffic. They are deploying a GETVPN solution. Which routers would be GDOI group members?

flashdumper

I think it's only PEs!

powmia

Think? Anyone else?

I'll give you a hint. The answer will lead to a much more interesting discussion.

deth1k

CPE's of course, why on earth would you want any encryption running on your PE's that would only slow them down aside of that majority don't support those protocols anyway as it's not their function.