powmia's CCDE marathon

FloOz

Goodluck!! You really do have the best possible mindset going into these exams. I hope to try and be the same way when I go for my CCIE.

silver145

When i get into a car, i think IM GOING TO DIE A HORRIBLE DEATH AND BE IMPALED. is not exactly the best mindset for me personally, but each to their own.

I understand people get nervous about exams, i get excited! a challange and all that but the end of the day: It is an exam, the only worry is the cost.


And honestly, from the way you write the posts within your thread, i say no! if you believe you will fail. You have a belief in your abilities which you can tell when reading your posts. You may say one thing in your head but you write another

powmia

silver145 wrote: »

When i get into a car, i think IM GOING TO DIE A HORRIBLE DEATH AND BE IMPALED. is not exactly the best mindset for me personally, but each to their own.

I understand people get nervous about exams, i get excited! a challange and all that but the end of the day: It is an exam, the only worry is the cost.


And honestly, from the way you write the posts within your thread, i say no! if you believe you will fail. You have a belief in your abilities which you can tell when reading your posts. You may say one thing in your head but you write another

LOL

I believe in my abilities. My expectation of failure is purely based on the fact that I don't know the exact format of the exam, or the way questions will be asked (or asked without asking). That's what helps me. I am 100% confident in my knowledge and skills. I am also confident that there is a high probability that I will get tricked by Cisco. Expecting the worst, but knowing that I have the proper tools at hand is what keeps me from freaking out when sh** hits the fan in one of these exams.

Oh, and Heisenberg is the frickin man.

gbadman

powmia wrote: »

Oh, and Heisenberg is the frickin man.

Werner Heisenberg? How so?

gorebrush

My concern would be that I've spent $1000+ on an exam (not to mention the costs for travel, hotel etc) and the possibility of failing would be a little harder to take than usual

powmia

Hey, well, whatever works. I'm only giving what worked for me... not trying to provide a "how to" here. The key thing is to do whatever it takes to keep your mind functioning properly, because it is a brutal exam and will leave you pretty exausted by the end of the day. Getting too worked up will affect your focus and start inducing brain farts. My method, obviously worked for me. Expecting to fail, doesn't mean trying to fail (really think I want to go through all of that again? The extra study, extra travel, and extra money out of my pocket..). I give it 100%, but acknowledge the fact that some things will just be out of my control at that moment. Like I said, works for me.

powmia

gbadman wrote: »

Werner Heisenberg? How so?

No. Well... I just googled him, and being as he is one of the creators of quantom mechanics, I would have to say that he is also the man.

gorebrush

powmia wrote: »

Hey, well, whatever works. I'm only giving what worked for me... not trying to provide a "how to" here. The key thing is to do whatever it takes to keep your mind functioning properly, because it is a brutal exam and will leave you pretty exausted by the end of the day. Getting too worked up will affect your focus and start inducing brain farts. My method, obviously worked for me. Expecting to fail, doesn't mean trying to fail (really think I want to go through all of that again? The extra study, extra travel, and extra money out of my pocket..). I give it 100%, but acknowledge the fact that some things will just be out of my control at that moment. Like I said, works for me.

And I wasn't for one second disagreeing with your methodology...

I think it's a fair way of tackling the exam.

powmia

Here's something I'm going to have to pound into my head. Single provider means single point of failure. That's what I've seen as a recommendation for the practical. I hate that, and don't agree with it. Yes, it may be 100% true in many cases... but it's something that would need a much closer look in the real world. What would you consider more robust; connections to two different Verizon PoPs, or a connection to Verizon and a connection to some random local provider?

I'll shut up and color for now.

powmia

gorebrush wrote: »

And I wasn't for one second disagreeing with your methodology...

I think it's a fair way of tackling the exam.

Understood, but FYI: if I didn't want anyone to disagree with me... I would write a blog and turn off the comments. I'm hoping you guys disagree with me on some of these

hono

Very interesting thread.
I'm also interested for the Practical exam but for next year,
Did you took a Bootcamp (Jeremy Fill....) or an another?
Good luck on your journey.

powmia

hono wrote: »

Very interesting thread.
I'm also interested for the Practical exam but for next year,
Did you took a Bootcamp (Jeremy Fill....) or an another?
Good luck on your journey.

Funny you should mention it. I haven't taken any bootcamps, but I did take a practice exam from Jeremy Filliben. I've never been a fan of bootcamps. I don't see a bootcamp as being any benefit to me, especially for something regarding design. Not that I know it all (as much as I like to think I do), but just that I learn better when I come to my own conclusions. I also don't think a cram session will do me any good for a test like this, which may not hold true for everyone. I did, however, want to see example scenarios written by someone that has passed the practical. I needed to see the depth of the questions, the way they are worded, and the mindset that the test writers were in when they generated the scenarios. Basically, I felt like I was completely blind going in. I used Filliben's practice exam, and now I feel a bit less blind.

I haven't mentioned this previously, because I don't want to recommend anything until I get a chance to see how much of a benefit it actually was. I will know this once I take my practical. So, aside from the content. He's a good guy. I could probably shoot him an email right now criticizing one of his questions, and asking for clarification because I don't understand it. I would probably have a good response by the end of the day. Can't say that for the big name vendors.

powmia

http://www.ietf.org/rfc/rfc3439.txt - This should be taken to heart.

7. The Myth of Five Nines

Paul Baran, in his classic paper, "SOME PERSPECTIVES ON NETWORKS--
PAST, PRESENT AND FUTURE", stated that "The tradeoff curves between
cost and system reliability suggest that the most reliable systems
might be built of relatively unreliable and hence low cost elements,
if it is system reliability at the lowest overall system cost that is
at issue" [BARAN77].

Today we refer to this phenomenon as "the myth of five nines".
Specifically, so-called five nines reliability in packet network
elements is consider a myth for the following reasons: First, since
80% of unscheduled outages are caused by people or process errors
[SCOTT], there is only a 20% window in which to optimize. Thus, in
order to increase component reliability, we add complexity
(optimization frequently leads to complexity), which is the root
cause of 80% of the unplanned outages. This effectively narrows the
20% window (i.e., you increase the likelihood of people and process
failure). This phenomenon is also characterized as a
"complexity/robustness" spiral [WILLINGER2002], in which increases in
complexity create further and more serious sensitivities, which then
requires additional robustness, and so on (hence the spiral).

The conclusion, then is that while a system like the Internet can
reach five-nines-like reliability, it is undesirable (and likely
impossible) to try to make any individual component, especially the
most complex ones, reach that reliability standard.

powmia

Finished my re-read of BGP Design and Implementation. Still one of my top 5 favorites. Nothing revolutionary in the book, but I'm glad I moved some of the practices in that book to the front of my mind again.

I've appropriately titled this thread "powmia's CCDE marathon." Appx 10 months ago, I created a list of all the books I wanted to read. My exam is in 8 days, and I just finished that list last night. Talk about keeping a pace. For me, planning on how to study is just as important as the study, itself. I went so far, as to white board a matrix of those books. I needed to come up with a ranking system that would determine the order in which I was to read the books, and which ones I would consider optional reads. The attributes of each book that I took into consideration were:

Need to Read (positive points, scale of 1-20)
Want to Read (positive points, scale of 1-20)
Already Expert on Topic ( negative points, scale of 1-10)
Redundant Info w/ other book on list (negative points, scale of 1-10)
Redundant Info w/ book I read in the past (tie-breaker)

Once I had my prioritized list... I made some modifications to suit my learning style. I grouped those together that I though should be, for example; I made sure that Layer-2 VPN Architectures, Traffic Engineering with MPLS, QoS for IP/MPLS Networks, and Definitive MPLS Network Designs were read in that order, and in succession. The IS-IS section in TCP/IP Vol 1, IS-IS deployment in IP Networks, and OSPF and IS-IS: choosing an IGP for Large Scale Networks were also grouped together in that order. I also saved some books for my last leg. These books are the ones that tie multiple technologies together, such as Comparing, Designing, and Deploying VPNs and BGP Design and Implementation (This one touched on Inter-AS MPLS and CsC, as well as inter-AS Multicast). I saw some recommendations to make Optimal Routing Design both the first and last book that I read. That sounds like a good idea. This book covers design for OSPF, IS-IS, EIGRP, and BGP. It's a Russ White book. This was actually the 3rd book that I read, but the first of my routing books on the list that I read. I have 8 days left... sounds like a golden opportunity to take the advice and make it my last book. I actually have Metro Ethernet open right now. This one is written by Sam Halabi (dude that wrote Internet Routing Architectures), and it's short.. so I figure why not. I'll probably go through Optimal Routing Design when I have time at home this week.

I've also read the primary SRNDs/CVDs and RFCs that I wanted to go through... as well as quite a few that I had stumbled upon. I'll keep up with trying to find one or two docs a day to read in addition to the books. And.. I want to go through a few slide decks from Cisco's NANOG presentations. I'm pretty much just looking for things now. Trying to keep my mind right. I will read at a faster pace this week, extracting good info while not reading word for word. That's how it will be in the exam, so I need to get out of the habbit of reading like I'm enjoying a novel.

powmia

Just finished reading Metro Ethernet. I wish cisco press would release some updated coverage on the topic. I suppose that since there is still a lot of work going on with optical networking, maybe we'll get something once the dust settles a bit. Good book, but very top-level. Don't quote me, but I *think* this one is on the CCIE SP reading list... probably not good for that, since it provides architectural concepts, not implementation. If for nothing else, the GMPLS coverage makes this worth reading... much better than the RFC.

powmia

IGP Convergence Brain ****

---

Upon a topology change, a convergence event consists of the following:

1. Identify the change.
2. Propagate information regarding the change.
3. Calculate new path, taking the change into account.

Anyone know what #4 is?

...

4. Update hardware with new forwarding information. *Yes, that is very significant.


### Identify the change ###

The event that triggers a convergence event will typically be one of two things; a link failure or a node failure. Failures could, of course, also be detected by a probing mechanism. Probes are straight forward enough, and the efficiency of the probe depends on the probe type and the configuration of that probe.

Link Failure

---

Forget about Hello timeout values, if a device detects a loss of carrier, the convergence process begins immediately. It is because of this, that point-to-point links are one of the most beneficial aspects of a resillient network. Keep in mind that there is typically a delay between the actual loss of carrier, and the reporting of that loss of carrier to a devices routing process. Carrier-delay can be modified, but can also be risky to modify. The more sensitive a network is to change, the more unstable a network tends to be and precautions must be taken. If modifying carrier-delay, route dampening should be implemented in conjunction.

Things become much more complicated when point-to-point links are not in place. The best example is a peering between two routers, that traverses a layer-2 switch. If one router loses it's link to the switch, the other router will not detect a loss of carrier and will, therefore, be relying on another failure detection mechanism. Aside from an ethernet network, this scenario occurs in any instance of intermediary equipment that does not kill both sides of a circuit when one goes down. Think about an optical network. If I connect a router to an ADM or something similar, and my optical network loses an active path... that doesn't necessarily mean that the ethernet port on the router will go down as well. This is great if the optical network is protected (my router won't flap while my optical handles the convergence), but if there is no protection, we want the router to go down before a 40 second hello timeout.

The best tool to use when there is a need to detect link failurs on non ptp links, is going to be BFD. BFD provides similar behavior to hello packets, but is typically performed "in hardware." This means that the handling of BFD is handled by line cards, or forwarding engines.. the impact to a routing engine (CPU) will be minimal.

Node Failure

---

There are two types of node failures:

A router/switch completely sh*** itself (power outage, reload, or explosion of some sort).
A routing process fails.

When a router sh*** itself, this will cause all of its links to go down as well. Convergence in this case is no different than in a link failure event.

When a routing process fails on a modular system, it is possible for the routing process to be completely dead, while all of the links remain active. NSF/GR can protect against this, but the only way for neighboring devices to detect a non-recoverable node failure while all links remain active, is going to be with hello messages. Since BFD is performed in hardware, BFD cannot be relied upon for node failures of this nature. It is for this reason, that you can't just decide to implement BFD instead of tuning hello intervals. Node failures of this nature are extremely rare, however, so the typical recommendation would be to use BFD and hellos in conjunction; set BFD intervals extremely low, while setting hellos moderately low. In other words, subsecond hellos typically aren't neccessary. A 1-3 second hello value with a subsecond BFD interval is a good recommendation. Of course, this all depends on given requirements and hardware platforms.


### Propagate information regarding the change ###


For RIP this invol..... just kidding, don't care.

For OSPF and IS-IS, this is going to be flooding of LSAs or LSPs. The entire network needs to be notified of the change, this notification process is called flooding in link-state routing domains. The values here are tweakable (more so with some vendors than others). You typically want all of the routers in your network to be notified of the change as fast as possible. You also don't want continuous network churn to make flooding the only thing you do. The recommendation here is to set initial LSA/LSP generation/flooding as low as possible, while using some form of rate-limiting (packet pacing or throttling) for subsequent LSAs/LSPs. The caveat here, is that if there is a node failure that causes 50 links to go down, that might mean an LSA/LSP coming from 50 different routers. You wouldn't want to set your initial value so low that you don't receive all 50 updates before packing them and flooding... that would mean you send the first update extremely fast, and pace the rest in an exponential fashion.

EIGRP.. meh... this will be DUAL. This is a route-by-rumor protocol, so you don't have the same requirement of flooding information to all routers so that they can calculate a new path. When a router detects a change, it converges itself (though this self convergence relies on the query process... therefore, if a neighbor (or a neighbor's neighbor) has an alternate path... the self convergence will actually trigger other routers to converge prior to the original router converging). Once that router converges, it tells everyone else about the change... then DUAL... diffuses through the nework. The biggest thing you can do to help this process out, is scope your queries. The fast convergence of EIGRP depends almost entirely on failure detection and query boundarys. Your query boundaries are stub routers and summarization boundaries.


### Calculate new path, taking the change into account ###

This step only pertains to the link-state protocols. I suppose I could be creatively specific and break out DUAL into separate progagation and calculation processes, but I won't... I honestly don't care enough about EIGRP to go into it, and DUAL is best if not compared directly to link-state behavior. There is no mass computation of the network in EIGRP... the propagation of information creates computation which creates propagation of information... the lines are blurred and I don't care enough.

For OSPF/IS-IS, this is your SPF run. Again, this is a tweakable value... and again, this should be trottled just as the generation/flooding is. The difference, is that an ideal network would flood information to every router/node, then every router/node would simultaneously (close to) compute the new path. This means you don't want your SPF to kick off and cause you to wait 50-100ms before flooding info to the rest of your network. Some code might allow you to do two things at once, but I wouldn't count on it. I also wouldn't want to set my SPF throttling too low. I want to look at my average SPF run time and throttle at slightly above that pace.


### Update hardware with new forwarding information ###

So, carrier delays can be tweaked to almost nothing. Information propagation can be tuned to only take a matter of miliseconds, and so can our path calculation. Updating our FIB is another beast. On a pizza box, no problem... single set of ASICs tied directly to the route processor. This will be quick. On a distributed system, however... not so much. If you have an RP updating 5-10 or more line cards, which in turn update their ASICs... a network with enough prefixes could get us talking in the minute range. Yes, an OSPF network can handle 2,000 routers and 20,000 routes... but if 10,000 of those are external and that external link causes a convergence event, that will not be meeting any SLAs. Summarization is your biggest friend in purely IP networks. In an MPLS environment, this is why we only advertise our PE loopbacks in LDP and rely only on those PE loopbacks for forwarding to external destinations.



I'm sure I could have thrown a lot more in there... but time's a wastin.

powmia

Some more convergence affecting rambling......

IS-IS treats all networks as external. A link down is treated as a lost leaf node, only runs a PRC (Partial route computation).

OSPF treats connected networks as internal (within an area). This means they are included in Type-1 LSAs, which means that a link down event triggers SPF runs.

PRC is inherent in IS-IS, iSPF can be enabled.

iSPF can be enabled for OSPF, encompases PRC.

OSPFv3 treats networks the same way as IS-IS. FYI, OSPFv3 can be used for IPv4 as well.

When OSPFv3 is used for both IPv4 and IPv6, two topologies are created... which takes up more resources.

IS-IS originally only maintained a single topology that included both IPv4 and IPv6 networks. This saves resources. This is a mistake, though. If you have a single topology and chose a given path as the shortest path to reach an IPv6 destination, but one of the links in that path is only IPv4 enabled... the IPv6 traffic gets blackholed... visa versa. An RFC was written and vendors have now implemented M-ISIS (Multi Topology IS-IS). This is not enabled by default in IOS.

Inter-area / Inter-domain (level) convergence is typically more straight forward. People refer to this as distance vector behavior... this is pretty accurate. It's a result of inter-area prefixes being treated as leave nodes, ie... PRC is run for these prefixes, never an SPF run. Same thing with redistributed routes. This brings the question... why does everyone say external routes are bad in OSPF? Yes, they do take more memory than an Type-1/2/3 LSA, but they will never trigger an SPF run. Yes, if they are redistributed into a non-backbone area, the ABR will have to generate Type-4 LSAs and if it's an NSSA will have to translate the Type-7 to Type-5 as well.. these are resource intensive. However, if you're a service provider with a single area OSPF domain... wouldn't redistribution of connected interfaces (as opposed to passive-ints and bringing them into your Type-1s) be a much better way of doing things? If your routers can all handle multiple instances of the global BGP table, I'm sure you have the memory space for using Type-5s instead of adding them to Type-1s.

For S&Gs, this is a memory test... if anyone is still reading this thread, you can proof this for me:

### LSAs ###


OSPFv2

---

Type-1 = Router
Type-2 = Network (pseudonode LSA)
Type-3 = Summary
Type-4 = ASBR Summary
Type-5 = External
Type-6 = Group Membership
Type-7 = NSSA External
Type-8 = Never implemented, was meant to carry external attributes (ie... iBGP type attributes)
Type-9 = Link-Local Opaque - used for Graceful Restart
Type-10 = Area-Local Opaque - used for CSPF (MPLS-TE)
Type-11 = AS-Local Opaque - not sure what these are used for, probably just there for future reference... seams kinda dumb since LSA flooding doesn't occur across ABRs.

OSPFv3

---

0x2001 = Router
0x2002 = Network
0x2003 = Inter-Area Prefix (same behavior, new name)
0x2004 = Inter-Area Router (same behavior, new name)
0x4005 = External
0x2006 = Group Membership (some will say this is deprecated in OSPFv3... well, it was pretty much deprecated in v2 as well, it just would have been retarded to shift things up and make us remember that externals are Type-6 in OSPFv3.
0x2007 = NSSA external
0x2008 = Link-Local LSA (lists addresses on a link.. IPv6 can have multiple addresses per link.. hence the need)
0x2009 = Intra-Area Prefix (this is the magic that seperates prefixes from Type-1s to create IS-IS like behavior)

You would think that's too granular of knowledge for a design cert... but a lot can be learned from comparing those two lists. Notice there are no opaque LSAs in OSPFv3.... they wised up and moved away from a fixed format to a good TLV hierarchy... again, similar to IS-IS. My personal opinion... OSPFv3 is the correction to link-state routing that has been needed for quite some time.

powmia

Reading Optimal Routing Design again.

I've used this example from the book a couple of times to get the point across, as to why we need maintainers, and why proper network design is crucial.

You have a device that you anticipate will experience a failure/change once every 5 years.

If your network consists of 5 of these devices, that averages out to 1 failure/change per year.

If you have 1000 devices in your network, this works out to once every 1.8 days.

powmia

4 days to go until the big day. Really... what can I do? If I'm not ready now, I won't be in 4 days. Still, I'm reading this last book (hard to stay motivated, this is my second read and all it is doing is confirming that I know everything in it), as well as going through my whiteboard notes. The notes I'm paying attention to the most... are the ones that reminded me to look something up.

Having a bit of trouble with this one.

BGP address families. Log into a router running IOS 15.3(2)T or later (or IOS XE 3.8S or IOS XR 2.0 or later) and do this:

router bgp 1
address-family ?

I know what everything is in there, except for one.

address-family ipv4 - ipv4 AFI
address-family ipv6 - ipv6 AFI
address-family l2vpn - only SAFI is vpls, this is "auto-discovery" as opposed to ldp based vpls signalling
address-family rtfilter - efficiency mechanism for rr to rr-client communication in an L3VPN environment
address-family vpnv4 - ipv4 L3VPN
address-family vpnv6 - 6VPE

For the SAFIs

address-family ipv4 mdt - used to identify PE routers that should establish an mVPN GRE tunnel for the MDT
address-family ipv4 multicast - for RPF information
address-family ipv4 mvpn ??????????????????????????????????????????????????????

wtf is that? The documentation doesn't say crap about it. The only hinting piece of information regarding this command is "Configure address-family ipv4 mvpn to enable IPv4 multicast customer-route (c-route) exchange. "

Am I reading this wrong, or isn't that exactly what "address-family ipv4 multicast vrf XXX" does?

The only reason this is concerning me, is that the CCDE creators have put forth a lot of effort to make the exam vendor agnostic. They should only be testing on technologies/protocols/methods that are widely used. Is this command implementing a new protocol or modification to a protocol? If that is the case, I sure would like to know what this command is referring to. I can create an Intra or Inter-AS mVPN without this command, so wtf is the actual "mvpn" command for? If this isn't a new technology, but is only a tool for implementing something else in a more efficient manner (such as the address-family rtfilter SAFI)... I suppose I've no cause for concern. Anyone?

nel

Best of luck man. I have been a silent reader of your posts for some time now. Its great following your guys progress to the top!

reaper81

I think it might be related to mLDP.

powmia

That was one of my guesses. Funny, I think I actually recall someone mentioning that in a comment under one of Petr Lapukhov's blog posts. It would make the most sense... especially since it appears to be a beta test (with visible commands, which is odd).

If being for mLDP is accurate, it is a bit of cause for concern for me. I was under the impression that there were numerous approaches to the problem that mldp solves.. and that no single technology had been definitively chosen. I also was under the impression that mLDP itself was still a work in progress. If it's in the code, I don't know if that would make it so that this is considered "widely available technology" enough to be testable on the CCDE... hmmm, oh well.... from a design standpoint, I still know "why" mLDP... so I would probably still stand a chance if I was faced with it (so I hope). Thanks Reaper.

powmia

It is pretty cool to see the progress that I've made. Optimal Routing Design was the 3rd book I read when I started studying specifically for this exam; the first routing design book. The first time I went through this book, I hit a couple of chapters that I thought I needed to read some refresher material before continuing with those chapters. 10 months, 20 books, countless hours of drawing out my own networks, and a bit of lab work... and now I read Optimal Routing Design again. Not only do I understand everything in the book beyond the detail the book goes into, but I actually get frustrated with how much errata exists in it. Honestly, it's the most poorly written book I've ever seen from Cisco. It seams like the authors just sat down over some beers and started going to town on a book. The worst part, is that even though it is the worst written... you can tell that the authors do understand some very important concepts that aren't condensed into any other individual pieces of writing. The worse worst part, is that these are the guys that created the CCDE... so I need to understand how they think. Oh well.

Less than 24 hours to go. I'm anxious for one thing only; getting it over with. I really hope I pass. I really feel that there is nothing more I can do to prepare. No more books or labs will improve my knowledge beyond what is required for this test. My fate relies entirely on how clear my head is and which scenarios I am presented with. If I go in tomorrow and understand everything they throw at me, but still fail due to the exam format... It will be so frickin hard to even think about the exam while waiting 3-6 months to re-take it.

reaper81

Good luck! I think you are very well prepared. I agree that the book definitely could have been better written. Like you said it's one of few books that actually discuss design beyound the regular CCDA/DP level.

FloOz

Good luck!!!

Master Of Puppets

Good luck tomorrow!

gorebrush

Best of luck for tomorrow!

hono

Good luck for tomorrow!

carterw65

Good luck brother. You can do it!

powmia

Thank you gentlemen. At the hotel. Found the test center, less than a one minute walk away. Didn't realize where I was staying. I've seen this hotel before. If I pass, I'll pick up a bottle of champagne and my favorite mango curry from across the park on my way home. If I fail, I'm still getting the curry.