powmia's CCDE marathon

powmia

I haven't seen anybody else start a CCDE journey thread. So I'll step out on the ledge. Primarily, this will be my reference to use after my practical exam (scheduled for August 27th). This will be a reference for one of two scenarios:

If (I pass)
I will use this as a reference of what worked for me. One of the first questions asked of someone passing an expert level exam is always "what did you use to study?"
else
I will use this as a reference of what I did wrong. After seeing the exam and failing, it will be good to either see that I left out some material, or that I was looking at the right material, but in the wrong light.

### Background ###

I am a CCIE (R&S). I am contracted out from the service delivery unit of a Cisco Gold Partner. In this position, I am the senior network engineer in the engineering & architecture branch of a large organization. We have ~50,000 users accessing multiple networks simultaneously. 9 data centers and ~300 sites (ranging from 10 users to ~10,000 user campuses) spread across ~30 countries. My work split is about 40% Data Center, 35% R&S, and 25% UC. 50% design, 20% architecture, 10% implementation, and 10% troubleshooting, and 10% training.

Before coming here, I was the lead engineer for a facility that was part data center for various enterprise networks, and part WAN hub for those and other networks. 50% implementation, 25% design, and 25% O&M.

Before that... blah blah blah, more network stuff... less interesting.

### Initial thoughts on the CCDE ###

Intimidating. Quite a few people holding multiple CCIEs have failed this practical exam... some more than once. A test that can get a 4x or 5x CCIE to go home empty handed is not one to be taken lightly.

I'm taking this as something to my advantage. It's easy to say, "oh wow, that guy has 5 CCIEs and failed that test, it must be impossible." I'm just going to assume that most of the guys like that thought they could walk into a design exam and put another knotch in their belt, no problem. The reason I passed my CCIE on the first attempt; I didn't take it lightly.

### Why I want to get my CCDE ###

There are currently only about 130 people with this cert. The CCIE count is exponentially increasing, and I feel the need to have something to set myself apart. To be fair... the IT industry is exponentially increasing, hence the growth in CCIE numbers. In no way, shape, or form, do I feel that the CCIE has any less value. I merely am not satisfied.

Instead of getting another CCIE, I've chosen to get the CCDE. Aside from getting another number to put in my sig block, I think this is much more beneficial to my career as a whole. Once you get a CCIE, it doesn't matter what track it was. There's no telling people, "R&S, I'm a CCIE R&S... hire someone else to do your UC." Service Provider, Data Center, Security, Voice, I have built networks using those technologies, no different than someone with a CCIE in that track would have. I am an expert implementer... If you throw something at me I'll get it done. This is exactly "why" the CCDE. I figure that a much more useful skillset to work on, is my ability to look at things from a different angle. A more top-level, yet more in-depth perspective of the big picture and all of its moving parts. I'll tell you now, I was 100% correct. I do some form of design/architecture work on a daily basis, but since I got hard core about the CCDE, the ability to do my job has increased 10 fold. This is definitely a skillset worth validating.

powmia

Let's start with the books.

I've broken out all of the books on the official CCDE reading list into 3 categories: Books
that I have read since looking towards the CCDE, books that I had read prior, and books that
I'm not going to read. The books that I'm not going to read, are either due to the fact that I
feel I have reached the level I need to be at for that topic, or there was a better book to
use. Notice that I have no 4th category of books from the reading list that I still need to
read... checked that box already.

Have Read

---

# Optimal Routing Design
This is definitely a good book, and probably on of the most important on the list. Russ White
wrote this book... he's the creator of the CCDE, and a lot of people say that the most correct
solutions for the CCDE exam are the solutions that Russ would use. Outside of the CCDE, still
a must read book.

# IS-IS: Deployment in IP Networks
Another book written by Russ White. Very good book for IS-IS. Excellent book for gaining a
better understanding of the SPF algorithm in general. I highly recommend this one.

# Network Security Architectures
Good book, very high level and a bit outdated... but the design principals hold true.

# IPv6 Enterprise Networks
I only read this one, because it's the most recently published Cisco Press book on IPv6. IPv6
is still young and changing, so it's good to keep current. Other than that... the best take
away from this is the different uses for various IPv6 transition mechanisms. Deploying IPv6
Networks was a much better, much more in-depth read. No regrets, though.

# EIGRP Network Design Solutions: The Definitive Resource for EIGRP Design, Deployment, and
Operation *
Essential for understanding the the beauty, and repercussions of the DUAL algorithm.. as well
as why EIGRP was created in the first place. Old book, I got it used on Amazon for a buck...
still a great book.

# Layer 2 VPN Architectures
More technical than is needed for the CCDE, but neccessary knowledge. Good book.

# Traffic Engineering with MPLS
Excellent book. Aside from being good for someone in need of a "from-scratch" intro to MPLS-
TE, the case studies for strategic vs. tactical TE are essential.

# End-to-End QoS Network Design
I don't see what all the hype is about. Everyone says they love this book. It's pretty basic
and just a regurgitation of every QoS doc on Cisco.com.

# QoS for IP/MPLS Networks
This... is a great book. Short and to the point. If you combine basic DS-TE stuff from
Traffic Engineering with MPLS with the inaccuracies in Definitive MPLS Network Designs (the
only flaw of that book).. you have a good understanding of DS-TE.. but not good enough. This
book puts the picture together.

# Network Management Fundamentals
Ugh... I flipped through most of this book, and read the chapter that covers the actual
management protocols. Written by a Ph.D. (Paper heavy Dude) and it shows. If you already have
an understanding of TOGAF and ITIL, you don't need this book... just skim the network
management config guides for any IOS release instead.

# Definitive MPLS Network Designs
My favorite book in the history of ever. Essential CCDE material.

# Top-Down Network Design, 2nd Edition
My least favorite book in the history of ever. Her process sound, but her technical
understanding of some things is not. Combined with the fact that Cisco had the nerve to
release this in a new edition recently, but still left in some outdated content... this one
pissed me off.

# Designing Cisco Network Service Architectures: Foundation Learning Guide
Good, broad coverage... yet, found this to be a waste of time. Probably would have been much
more useful if I hadn't already gone deep on all of the topics covered in this.

# Practical BGP *
Another Russ White book. This one is good, and has some great insight that you won't get from
most books. Things like "don't use MED," hot vs. cold potato routing, scaling mechanisms that
hinder redundancy if done incorrectly, and when to use route reflectors vs. when to use
confederations... definitely make for a good BGP review.


Have Read (prior to working towards CCDE)

---

# MPLS Fundamentals
Great book

# Cisco QoS Exam Certification Guide: MQC, QPM, and AutoQoS
Good book, outdated, but combined with up-to-date config guides, this was essential for my
CCIE.

# Deploying IPv6 Networks
Good book. Some information in there has probably changed between its publication date and
now, but good. Highly recommended.

# CCIE Routing and Switching Certification Guide, 4th Edition
A lot of people say this is all they needed for the CCIE written, and I can see that. I don't
know why the h* this is on the CCDE reading list, though.

# BGP Design and Implementation
THIS BOOK... is awesome. I don't know why the first book people recommend for BGP is "Internet
Routing Architectures." That is a great book... but doesn't compare to this IMO. The only
reason, is probably because this one is much newer. There are a lot of things in this book
like source-based RTBH, QPPB, and general design concepts that go in-depth on the potential of
BGP communities that just aren't found many other places. In fact, I'm probably going to re-
read this book if I have time before my practical exam.

# MPLS and VPN Architectures, CCIP Edition
I actually read Vol. I and Vol II instead of the consolidated CCIP edition. Great books,
definitely some CCDE type material in there. For those going for their CCIE, I always
recommend reading MPLS Fundamentals and MPLS and VPN Architectures Vol. II.

# Designing Cisco Network Service Architectures (ARCH) (Authorized Self-Study Guide), 2nd
Edition
So yeah, why are the 2nd edition and 3rd edition both on the reading list? Trying to sell more
print? I read the 3rd edition.

# Routing TCP/IP, Volume 1, 2nd Edition
Absolute Necessity for CCIE

# Routing TCP/IP, Volume II
Absolute Necessity for CCIE - Good Multicast coverage when combined with Developing IP
Multicast Networks.

Not going to read (either don't need it, or there's a better book)

---

# Advanced MPLS Design and Implementation
If I had more time, I would probably read this, because of the reviews. Other than that, I
don't feel that I need to.

# IP Quality of Service
Don't need any more QoS

# MPLS Configuration on Cisco IOS
Configuration? On the CCDE reading list? I can already configure MPLS on Cisco IOS, and...
Configuration? On the CCDE reading list?

# Fault-Tolerant IP and MPLS Networks
I haven't read this, but I did read Building Resillient IP Networks when going for my CCIE, and
my impression is that the latter is just an update to the former... minus the MPLS.

# Troubleshooting IP Routing Protocols
I can already troubleshoot IP Routing Protocols.

# OSPF Network Design Solutions, 2nd Edition
Bought this book used on Amazon for under a buck. Maybe some day I'll read it, since I don't
like having books on my shelf that I haven't read. Other than that... I don't need anymore
OSPF.

# Voice-Enabling the Data Network
After reading all of the CCNP Voice books for work this year, and already considering myself
expert enough at QoS, I didn't feel the need to read this.

# EIGRP for IP: Basic Operation and Configuration (The Addison-Wesley Networking Basics Series)
This was a tough one to pass up. Two of the authors hold a CCAr, one of whom, is Russ White
(again), the other author is pretty much the creator of EIGRP. However, EIGRP Network Design
Solutions (on my "have read" list) was written around the same time by the guy that did most of
Cisco's internal EIGRP training, and has the word "Design" in the title, as opposed to "Basic"
and "Configuration" ... I'm sure it wouldn't have mattered much either way... it's all material
I've seen too many times before.


SO... that covers the official CCDE reading list. Now for the books I have read since starting
the CCDE journey, that are NOT on the official reading list.

# Comparing, Designing and Deploying VPNs
This is definitely a good book. Not so in-depth on any one subject, but a good review of all
the individual books I had already gone through. This is the most recent book I have
completed, and I definitely recommend saving this for next to last in anyone's CCDE prep.

# OSPF and IS-IS: Choosing an IGP for Large-Scale Network
If you don't already know... Jeff Doyle's books are awesome (TCP/IP vol 1 and 2). He wrote
this as well. Every chapter is one piece of link-state operation, in the format of a side-by-
side comparison of OSPF and IS-IS. I recommend this book to anyone that's ever configured a
link-state routing protocol. Icing on the cake... he switches between IOS and JUNOS in this
book. For example: In one chapter, he'll show the config for OSPF in IOS and the debugging for
OSPF in JUNOS, with a side-by-side comparison of IS-IS... config in JUNOS and debugging in IOS.

# IPSec VPN Design
A bit dated, but good. Just replace TED with GET, and take it for what it is. Good coverage
of the impact of IPSec and tunneling on networks and the hardware running it.

# Optical Network Design and Implementation
Definitely don't need the implementation parts of this... but working in organizations big
enough to have separate transport shops has left my optical knowledge with some gaps in it.
This helped with the big picture. Hopefully it pays off...

# Data Center Fundamentals
Great book, but dated. I hear there isn't much data center stuff on the CCDE, but I read this
anyways. 50% of my job is data center stuff, so this was a lot of info I already knew...
still, this helps put in perspective the effects of the network on the applications using it.
I recently purchased Data Center Virtualization Fundamentals (same author, basically a next-gen
edition of this book). I haven't been so excited to read a book in quite some time.

# Internet Routing Architectures
This was a re-read. Probably not needed, but probably didn't hurt.

# Interconnecting Data Centers Using VPLS
This is the book I'm reading now. I am pretty sure that I already have enough of an
understanding of VPLS design and config for the CCDE, but "pretty sure" isn't enough. So far,
meh... nothing new, aside from the EEM semaphores. Honestly, if my techs have to maintain and
troubleshoot EEM, I did a piss poor job of designing a solution. A-VPLS (ICCP, VSS, whatever)
is the proper solution for a redundant N-PE... so I'll take about half of this book as
historical reference (sad... because it's only about 4 years old).

For those keeping score at home: That's 20 books that I've read since getting serious about the
CCDE, in addition to the many others I have read in the past (most of which aren't listed here
as a part of the CCDE reading list, but have all helped get me to this point).

powmia

Greatest office supply ever: White board wallpaper. I bought a couple rolls and turned an entire wall in my home office into a whiteboard. Each time I fill the wall, I use my phone to take pictures of the various parts. The very last thing I will do in the hotel room before my exam, will be to go through all of those pictures. I'm at about 500 images at this point.

reaper81

Great stuff. I'm planning on starting studying for CCDE "soon" At least need to pass the written to recert RS. How tough was the written?

powmia

The written isn't bad. Similar in difficulty to a CCIE written. The difference, and what I see most people have trouble with, is the attention to detail and the broad variety of topics. You might need to show why a particular MVPN design went wrong in one question, and have to recommend the best way to bring wifi into the network on the next. (no, that's not an NDA violation... I didn't have either of those scenarios)

powmia

I'll try to compile a list of RFCs, SRNDs and other various material. Might take a bit, though.

carterw65

Nice write up. Best of luck with your journey. Keep us posted.

chanakyajupudi

Best of luck ! Once you pass you should train some of us !

powmia

chanakyajupudi wrote: »

Best of luck ! Once you pass you should train some of us !

hmmm, business idea

chanakyajupudi

Maybe !

First customer !

powmia

For anyone that doesn't already know... The only officially published Cisco Best practices are typically contained in what used to be called an SRND (Solution Reference Network Design). Now, it is CVD (Cisco Validated Design).

I wanted to post a list similar to the CCDE reading list above, but that's going to be impossible. For one, I can't recall all that I have read. Second, there are some that I have found links to throughout the net, but can't find them on cisco.com when I go browsing. I don't really have the time to collect all of those... so... If you go to cisco.com and highlight "Products & Services" you will see a link in the lower right for Cisco Validated Designs. From there... have fun. I'm basically just browsing through there every couple of days until my lab, looking for documents that I haven't read yet. As I read them, I'll post which ones to the thread and if I find some that I have read, I'll post that along with a good/bad/whatever opinion (maybe).

For now... I actually just came across one that I had previously read.

# DMVPN Design Guide
Dynamic Multipoint VPN (DMVPN) Design Guide (Version 1.1)* [Design Zone for IPv6] - Cisco Systems

My opinion on that document, is exactly what the CCDE is all about. There are some things you just won't find an answer for in a book... or in a design guide.

The DMVPN Design guide tells you that the current best practice is to use EIGRP as your IGP when deploying a DMVPN with spoke-to-spoke communication (Phase II DMVPN... or III, for that matter). Not only for this example, but for everything, here is exactly what a CCDE needs to understand: "WHY?" Nowhere in that document does it say "And here's why!" Only that it is the best practice. This is a perfect example, because most DMVPN examples on cisco.com use EIGRP as the routing protocol. Ivan Pepelnjak (author of EIGRP Design Solutions) has a blog and hosts 'webinars' about building massively scalable DMVPNs using EIGRP. I haven't signed up for the webinars, so maybe he explains why in there... but NOWHERE else have I been able to find an answer to my question of "Why is it best to use EIGRP on a DMVPN."

It's funny how I learn the most about some protocols, when thinking about other, completely different protocols. The answer to this one actually came to me while in the shower (don't picture it, just go with the story).

Why do we use EIGRP on DMVPNs? EIGRP is so bound to the DMVPN implementations, to the point that Cisco has released an informational RFC (making it pseudo-open) for "Open EIGRP." This means that other vendors are now allowed to implement EIGRP in their networking equipment... Except for one thing. Cisco did not let go of the EIGRP stub feature. Their word is that they will make the EIGRP stub feature available when the BU (Business Unit) for DMVPN makes DMVPN an open technology. WOW... those two technologies are tied at the hip.

So... the answer to the million cent question: Well... to answer that (lol, wait for it... wait for it...) will only come to you when you're thinking about a completely different protocol.

By the laws of nature, out of the box, EIGRP, being a route-by-rumor protocol is more suited for a hub-spoke topology. There are ways to make OSPF and IS-IS come close to the scalability of EIGRP on a hub-spoke topology, and that's typically a combination of network types, mesh-groups, and default routing. I'll use OSPF for this explanation. How do we make OSPF start to get close to the scalability of EIGRP on a hub-spoke VPN?

I'm not going to go into a full-blown OSPF network type discussion, so I'll straight up throw this at you. The most scalable method, is to set the network-type on the hub and all spokes to point-to-multipoint. ptp won't work, it's a hub spoke. Broadcast isn't as scalable, aside from the chatty behavior of OSPF on this network type to both the DR and BDR, the spokes need to have the other spokes as next-hops for all of the routes behind them... basically, they need full visibility. Hiding visibility is stability and scaling 101. NBMA... nope, not here. Like I said, point-to-multipoint, this will treat each connection from the hub to its spokes as a point-to-point link, but allow them to all be on the same subnet (address conservation). The only downside to ptm, is that you add a bunch of host routes at the hub... whoopy doooo.

The next step is to do in OSPF what IS-IS has been doing much longer... mesh-groups (google it). OSPF creates this same behavior by using the command "ip ospf database-filter all out" on the head-end tunnel interface. This essentially says, don't send any LSAs to my spokes. This doesn't mean the spokes can't send updates to the hub The only thing that will pass to the spokes, is a default route after you configure a default-inform originate on it. You could also just use static defaults on the spoke.

So, there's your answer. That's why we use EIGRP on a DMVPN. You don't see it? It's right there!!!! What's the point of a DMVPN? Aside from ease of configuration (that's a management advantage), the technical advantage is dynamic spoke-to-spoke tunnel creation and IKE/IPSec SA establishment. How does a router know that it needs to dynamically create a tunnel to another spoke to reach a given destination? It knows, because it learned through the IGP that there is a route reachable from a next-hop that is another spoke. The router then queries the NHRP server for the public (NBMA) address of that spoke and establishes a dynamic vpn to it. How does a router get a route pointing to another spoke, when it is only peering its IGP with the hub? Well, with EIGRP... you use (in addition to disabling split-horizon) the "no ip next-hop-self eigrp NNN" command. With OSPF, on a broadcast segment, when you have a DR, each DROTHER on that segment receives routes from other DROTHERs (via the hub) that point to a next hop that is that other DROTHER... tracking? So the only way to get OSPF to dynamically create tunnels on a DMVPN, is to use the network type "Broadcast"... and as I said above... using network type broadcast is the biggest hinderence to the scalability of OSPF on a VPN. So the one thing that makes OSPF work on a DMVPN, is the one thing that prevents it from working BIG. Merry Christmas.

Wow, that rant was a little longer than anticipated.

Now... reading Trading Floor Architecture:

Trading Floor Architecture* [Design Zone for Financial Services] - Cisco Systems

Mrock4

Definitely will be following along. I almost detoured in the middle of my CCIE journey to go for the CCDE. My better judgement said keep going, but I'm really interested in the CCDE.

Interesting note about the whiteboard wallpaper- I almost bought "idea paint" which is paint that once dry, turns your walls into whiteboard. I was going to do this for an entire wall in my office, and dedicate that to studies and such but didn't. I have a large whiteboard now, but it turns out, I rarely use it anyway (still default to paper and a pen). Anyways, weird tangent.

Best of luck to you in your new journey!

powmia

The wallpaper was cheaper than idea paint... and I'm in a rental home, so the wallpaper will just rip right off.

And this is an old journey that never ends. I hope to see you get your CCIE right around the same time, it's just the beginning!

gorebrush

I will be watching this thread with interest. Good luck on your journey.

snadam

While this is miles above my experience, its still enjoyable to follow along. Thanks for sharing your progress.

FWIW, I know a 3xCCIE who failed the CCDE exam twice and got it on his third attempt, so there is hope.

Best of luck and looking forward to seeing your progress!

powmia

Trading Floor Architecture - Architecture document, so very broad. The only useful info was the multicast architecture. It's good to see a use case for PIM-Bidir and PIM-SSM outside of an MVPN core.

Not as good of a document as "Financial Services Design for High Availability [IP Multicast]":
Financial Services Design for High Availability  [IP Multicast] - Cisco Systems

I recommend this latter document, just ignore the following statement:
"Because it is the most widely deployed protocol on trading floors today, we recommend that you use PIM-SM"

That is not sufficient justification for a design choice.

Key take-aways from the two documents:

Some applications go silent for periods of time. The statelessness of PIM-Bidir is perfect for these circumstances here, since the forwarding path is pre-determined between the source and the RP (if one exists).

I would assume that PIM-SSM would be beneficial for reduced latency. My next assumption is that using PIM-Bidir with Phantom RP, each source using it's upstream subnet (this would imply either not using /30s or stretching layer-2 for address conservation, which would come with STP issues and require consideration of aligning your PIM DRs with your STP roots and active FHRP gateways), would give you an equal amount of latency benefit, while sill eliminating the need for physical RP placement, the associated inefficient forwarding, and the issues associated with intermittent sources.

To get similar behavior to the PIM-Bidir with Phantom RP solution, a PIM-SM deployment can place anycast RPs as close to the sources as possible, with each group of RPs (and each group meshed together via MSDP) only acting as the RP for the groups that are being used by their respective sources. The difference here, of cource, being the fact that you do have all of the state information that causes scalability issues in many-source, many-receiver scenarios.

Final take-away:

"IP Multicast Best Practices for Enterprise Customers [Multicast Enterprise]" is a better document than either of the two above, it just dosn't give case studies.
IP Multicast Best Practices for Enterprise Customers  [Multicast Enterprise] - Cisco Systems

jamesp1983

Good luck! I look forward to seeing your updates.

powmia

[OSPF]

You know... if we would just add the area ID as an attribute to type-3 LSAs... we could use those attributes in a path-vector manner and would no lonsger be limited to a two layer hierarchy. It's not like that would give modern routers any trouble.

NetworkVeteran

powmia wrote:

You know... if we would just add the area ID as an attribute to type-3 LSAs... we could use those attributes in a path-vector manner and would no lonsger be limited to a two layer hierarchy. It's not like that would give modern routers any trouble.

Brilliant! You've got my vote. OSPFv3 would've been a nifty opportunity to introduce such an extension. I suppose, for now, many are content with the 3-layer OSPF hierarchy that super-backbones introduced.

powmia

Definitely. Since v3 switched from a fixed-field to a proper TLV hierarchy, it would be too easy to do. Could you imagine the possibilities? super-backbone... :P a side-effect, nothing more... they got lucky that it actually does provide some benefit!

I would really be surprised if nobody had thought of that before. The closest thing I can think of is that they designated type-8 opaque LSAs for "external attributes" as a means to replace iBGP, but that was never implemented anywhere.

Hmmm, I'll bet someone at Cisco thought about it and got their idea shot down. After all, the biggest benefit of EIGRP in a standard campus network is the flexibility to create as many levels of hierarchy as you want. I suppose that if OSPF wasn't limited to 2 levels, they wouldn't have been able to con as many people into maintaining EIGRP campus-wide to this day. Imagine having that same flexibility for hierarchy without it being 100% reliant on whether or not you've maintained perfect address management throughout the life of your network, just to sustain your query scoping. You could have 'pockets' of summarized address space, and in the places that still have disorganized space... you still benefit from minimizing your full SPF runs.

Master Of Puppets

This is a great thread! Thanks for sharing your experience/thoughts with us. It will be great following you on your journey. I'm curious - how much networking experience do you have?

powmia

Thanks for listening to my mad scientist rambling! Not toooo much experience. IT for 12 years, networking for almost 10.

powmia

I read this one a few years ago. Just went through it again... worth every penny.

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6552/ps6592/prod_white_paper0900aecd80310db2.pdf

"In Bidir, redundancy consists of a primary/secondary model, there is no load sharing as was possible with the Anycast-rendezvous point sparse-mode case (it's impossible to load share without maintaining source information)."

So, no anycast RP in Bidir. We have to rely on what's called a phantom RP for redundancy....

Basically, with a typical Phantom RP deployment, you point the routers to a non-existent IP that belongs to a subnet on a layer-2 segment. That segment has multiple entry points, and that's how your redundancy is achieved. That segment, could be nothing more than a single link between two routers... not very redundant. That segment could also be a switch, still not redundant... or multiple switches.. mmmmm, spanning-tree.

Then, we have the longest match method. Take two routers. Router 1 gets a loopback with IP address 10.0.0.1/31. Router 2 gets a loopback with IP address 10.0.0.1/30. Both routers advertise the 10.0.0.0 network into their IGP... one advertising 10.0.0.0/31, and one advertising 10.0.0.0/30. You then point all PIM routers to an RP address of 10.0.0.1 and VOILA!, you have active/standby redundancy. All multicast traffic will flow through the RP that is reachable via the longest prefix match in everyone's routing table. If router 1 dies... everyone is still pointing to 10.0.0.1, but it's on router 2 now.

This sounds like two things to me. First, it sounds a lot like anycast RP (yes, the downside is no load-sharing or "close-to-many-sources" placement... still, one address on multiple hosts). Second, it sounds a lot like pure awesome.

powmia

The best advice I've heard when listening to podcast and techtorials; for every single technology that you encounter, ask yourself "Why do I care?"

Service Provider Security - Cisco Systems

This document won't teach you anything new and exciting. The reason I recommend this, is that it should be used as a checklist. CCIE R&S, CCIE SP, or CCDE... candidates should have an in-depth understanding of every technology mentioned in that doc.... Why, where, when, and how are they used, and how they impact a network.

Let's take RTBH from this document as an example.

Why: To mitigate DoS and DDoS attacks.

Where: Service Provider networks, or large WANs.

When: Implemented prior to any attack, activated during an attack. Possibly activated in advance for specific blocks of addresses.

How they are used: I won't go into the intricate details. It's a pretty simple concept, but still, it's worth reading up on.

How will it impact a network: Here's the most important piece of the puzzle. Once you have determined that there is a business case to implement this technology, a designer needs to know exactly what impact it will have.
What are my options?

I could implement simple RTBH, which will require every edge router to have static routes to provide a recursive lookup that ends up at null0. The downside, is that simple RTBH will kill all traffic to a customer, not just traffic from the parts of the internet that are currently generating malicious traffic.

I could implement source-based RTBH, which will allow you to only blackhole traffic from malicious sources, but will require the addition of uRPF on all edge routers. Do I use strict or loose uRPF?

In either solution, All of my edge routers need to take part in my BGP. I need to pick a router that will act as the trigger, do I pick two? Do I even use routers, or do I use route servers instead? WHO will initiate the trigger? I need a policy in place. I need redundancy built into that policy. Do we initiate the trigger because our NetFlow says we should, or do we wait for a customer to request the trigger... what if their only method of comm is VoIP that has been hit by the same DoS?

Is blackhole even the only option? What if I want to do more with that traffic than simply discard it? RTSH.. Remotely Triggered SinkHole? Maybe it isn't enough to just trigger an event that causes all routers to send malicious traffic to the bit bucket and forget about it. Maybe just using counters of the traffic going to null0 isn't enough. We can redirect all of that traffic to a box that will perform analysis on it. Source-based routing... PBR? Manage that... yeah right. uRPF is out... now we're back to triggering on destination traffic.. again affecting all traffic to our customer. Now analysis isn't enough... we need to perform scrubbing. Pass the good back to the customer, drop the bad.

In the end: We do not create a solution that is the most technically efficient and cool solution, and we don't just hear "DDoS" and say "RTBH"... we pick the solution that meets our requirements, nothing more, nothing less... and the benefit of that solution needs to outweigh the cost/impact of that solution.

powmia

I should probably throw this out there for anyone reading these.

You'll notice I'm jumping around from topic to topic. There is a method to my madness.

If you're learning the fundamentals, don't try this at home. Don't learn the basics of OSPF, BGP, and MPLS, then learn advanced topics on all 3, then lab OSPF, lab BGP, and lab MPLS. This will kill your progress. Why would you read fundamental MPLS stuff, that requires you to know advanced OSPF and BGP features? Are you going to flip back and forth between three different books just to understand the material in 1? There will always be questions that are temporarily left unanswered, but it is far worse to answer all of your questions and forget why you asked them in the first place.

Master each IGP one at a time. Then master BGP, then master MPLS. If you're just starting out for something like the CCIE R&S, plan your attack. Get a learning bundle from someone like INE. Don't expect them to teach you everything, and don't just keep hitting next. Starting with the layer-2 material. Read any relevant books on the switching, watch the layer-2 videos, get familiar with the switch config guides, then do the technology focused labs. Then you move on to the next topic.

I'm topic hopping now, and have been for about a month. That's two months prior to my exam that I dedicated to this form of preparation. My intent is to not only have a fresh review of all the technologies that I, individually, covered in-depth, but to constantly be in the mindset of accounting for the impact that what I'm looking at now has on every corner of my network.

powmia

Just read this one, good overview of NSF:

http://www.cisco.com/en/US/technologies/tk869/tk769/technologies_white_paper0900aecd801dc5e2.pdf

But I highly recommend this one for anyone actually deploying NSF:

Cisco NSF and Timer Manipulation for Fast Convergence  [High Availability] - Cisco Systems

powmia

Finished "Interconnecting Data Centers Using VPLS" last night.

This book reaffirmed my belief that DCI is the wrong place for this technology. It's currently the best solution for metro aggregation, and that's where VPLS needs to stay for the time being. TRILL and OTV (I know, I try not to go proprietary as much as possible... but the vendor lock-in isn't outweighed by the benefit here) are far better mechanisms for DCI.

Here's the way I see it. The benefit of VPLS that is boasted, is that you remove STP from the core that is interconnecting two sites. That's great for a single link interconnect... and I'll agree, it's a benefit. However, when you add redundant N-PEs at each site... it's layer-2, and you still need a way to maintain loop-free redundancy. Cisco's solution (Pre A-VPLS and ICCP... A-VPLS being proprietary) was to create EEM scripts that rig the devices to act in an active/standby partnership and only interacting with their local STP topology. Will I ever in my life design a solution for a customer that is dependent on EEM scripts... hell no.

I would rather have STP running across my core... wouldn't that be easier? For a simple two data center connection, It sure would... obviously, until you decide that you're connecting more than single distro blocks and hit your STP scalability limits. This brings up the point... why VPLS? Couldn't I just run AToM or L2TPv3 and let the bridging start at my aggregation switches, as opposed to the N-PE? OK, so now we're comparing the management of individual pseudowires vs single multipoint pseudowires. This is why VPLS is appropriate for metro aggregation. I sure wouldn't want to deal with provisioning thousands of PWs when I could just have one per access block. For a handful of data centers, sure... I'll manage individual PWs. VPLS split-horizon... the fundamental flooding operation of the switches on the other end of a standard ptp PW will create that same behavior. Redundancy... same mechanisms as with VPLS... without the VPLS. Whatever...

I could rant for hours on this. Bottom line, we will have better methods of performing a DCI in the near future (they are here now, they will just be more prevalent and standard).


Starting my re-read of BGP Design and Implementation. I've officially finished everything I needed from the CCDE Reading List. I'm on my final leg. After the re-read, I will re-read a couple sections from Optimal Routing Design, and go through my white board photos... all the while, keeping up with my SRND reads.

Master Of Puppets

Are you planning on putting in some lab time as the day nears or just reading?

powmia

I've put in my lab time, and none of the technologies I'm reading about are new to me. The CCDE takes a higher level perspective, all about the "big picture." There isn't a single piece of physical equipment, and not a single piece of configuration code on the exam.

Master Of Puppets

Yup, as we can get out of the whole thread you are very well prepared. I was thinking more of something like a pre-exam ritual - I have read over the web that some candidates lab in the final days just as some sort of a final review of the technologies and was wondering whether your approach is something like that.

powmia

I'm not sure about for the CCDE, but that does work for some people taking their CCIE

I'm taking this exam with a similar approach to when I did my CCIE. I'm less than a month out from the exam. If I'm not confident that I'm an expert in the material at this point, I shouldn't be taking the exam yet. When I was going for my CCIE, I went from doing 3-5 8 hour labs a week, to 1 a week for my last month. More than anything, I just did them to keep my proccess in muscle memory; reading the entire lab and visualizing everything I am about to build, without wasting too much time, the layout of my text document, which initial commands and tcl templates will be at the top of that file, how I will separate the sections and tasks, how I will handle the organization of those configs when they overlap, how I will generate the code for each technology in the fastest way possible... to the granularity of; which lines to I copy and paste, which parts of those lines need a blank space at the end of them so I can "down arrow" through my text file and fill in the relevant information, etc etc. At the end of my CCIE lab, I had a text file with 900 lines, most of which were config. That's the entire config for all devices in my lab, in a very organized state. After my complete run of the lab tasks, I was able to go back and clearly see the couple of tasks that I had saved for later.

This is what the last leg of preparation is all about. The knowledge and skill should be there, it's just about preparing for the test itself. The difference now, is that the CCDE is obviously not a config pounding exam. It's about quick analysis with attention to detail (that's the tricky part) and generating solutions while taking everything into account. So, that's exactly what I'm doing, analyzing designs and extracting all of the relevant information... taking into account how each technology impacts a network, why and when that technology is chosen, and how best to use that technology to my advantage.

I can only hope this approach works for me. I wish it was as straight forward as a CCIE exam, where you're either ready or you're not. When all is said and done, I think that my best tool will be a good night sleep before my attempt. Taking my work experience, my CCIE, and the fact that I am the only CCDE candidate I know that even came close to reading the entire recommended list... I'll be able to sleep just fine.