CCDE Study

CCDE Topic: docs I found useful

ryan.niemes@gmail.com (ryan) — Sun, 06 Dec 2009 17:48:00 +0000

CCDE Topic: docs I found useful

Step One: the written (read this even if you already passed!)

I found the written outline to be the most useful preparation not only for the written exam, but also the practical. I went through all of the topics outlined and made sure I understood exactly what they were trying to get at. Honestly, there were a number of items I had never heard of, so doing the research felt like I was accomplishing something. I've posted a few of the written items on this blog, like What is the issue with re-marking and OoO packets? and What is fate sharing, and what is its impact?.

If you want to see more about the security portion of the written outline, be sure to check out this post too.

In case you can't tell, I'm saying that even if you passed the written easily, you probably want to go back & make sure you understand everything that's covered on the outline.

Step Two: the practical

This is the difficult part, but I'll try to give a summary of what I found most useful for me. Of course, you may already be an expert in one of these topics and won't need to review it (but you probably should anyway).

SRND:

High Availability Campus Network Design--Routed Access Layer using EIGRP or OSPF

Enterprise QoS Solution Reference Network Design

RFCs (in no particular order):

OSPF RFC2328
TCP RFC793
BGP RFC1771
GRE RFC2784
IS-IS RFC1195
BGP/MPLS RFC2547
Multicast RFC1112
DSCP RFC2474

e-Learning:

If you have access to the Partner Education Connection you're in luck. If not, your best bet is to check out elementK. Your company may already have a subscription. I'm sure there are others with equivalent training, but I'm speaking specifically about the path I took.

I took the online MPLS SE training, reviewed the Multicast training, and reviewed the EIGRP training.

I'll go into the specific courses in a later post, as well as a book listing & the Cisco Live / Networkers materials I found useful.

CCDE certified, now what?

ryan.niemes@gmail.com (ryan) — Fri, 04 Dec 2009 15:33:00 +0000

So it's been a few weeks since learning that I passed the practical, and other than NOT having to attend the next practical in December, not much has changed. I think the marketplace is still trying to determine the value of this certification, and my feeling is that some employers may think it's nothing more than a written exam. They're right, of course, but it is a hard written exam. It remains to be seen just how / when employers will start to recognize the value. I think if the CCDE team published some statistics on the pass/fail rate it might help (along with the level of experience most taking it have), but I'm not holding my breath.

The path I took in studying for this exam made me a much stronger network engineer, and IMO that's the whole point. Now the question will be whether or not others become stronger engineers in their pursuit of the CCDE.

Some people have emailed me asking how they should prepare for the practical, and I would say the following has been invaluable preparation for me:

1. Get a job where you're tasked with maintaining & troubleshooting a production network.
2. Never be satisfied when something magically starts working - troubleshoot & solve real-world issues and find the root cause (wireshark is your friend).
3. Visualize how you would change the network to solve systemic problems with the network (and maybe even implement some changes).
4. Work with the applications people to help them understand how the network affects their applications (and vice-versa).
5. Become the 'buck stops here' person, meaning that if you cannot solve the issue, nobody can. You need to take ownership of the entire system - don't pass off issues to the applications people / server people.

In short: you cannot just have book knowledge to pass this exam, you will need real-world experience troubleshooting and designing solutions to solve systemic problems. If you gain this experience, you won't need the CCDE to prove your level of knowledge, your CV will speak for itself.

My background is in UNIX systems administration, networking, and security. I've also worked in several industries including Financial Services, SP, and DoD. I worked in small companies where I was in charge of everything, and large organizations where I was in charge of just one small part of the network. In all cases, I knew not just what I was responsible for, but all (or most) of the applications and systems running within the system. Personally, I believe this experience was key preparation for the CCDE. You need to understand real-world design issues, not just the best practice picked up from reading in a book. You need to never be satisfied with the design either - always look for ways to improve it. This quote from fellow blogger Jeremy Filliben sums it up nicely:

"When I take two eggs out of the carton, I take one from each row. It isn’t more correct, but it makes me feel better."

Isn't that the whole point anyway? If you have a passion for this stuff it will show, and you will be rewarded with an infinite number of interesting problems to solve.

CCDE 20090006

ryan.niemes@gmail.com (ryan) — Tue, 17 Nov 2009 13:42:00 +0000

Yesterday I received the letter from VUE confirming my pass of the CCDE practical exam: 352-011. I am now CCDE #20090010. At least according to VUE - the Cisco site is still not updated with a number. Correction: the Cisco site was updated with a number (20090006). The results were mailed on 11/13/2009 so it's taken at least 3 days to update the Cisco system.

Needless to say, I'm thrilled.

I will begin posting some info on my path in the hopes that it will shed some light on the process for others. I will say, it certainly helped that I had the requisite 10 years of industry experience before attempting the practical. It may be possible without this, but the breadth is wide enough, and the depth just deep enough that you can't really study for this exam.

That being said, I did study for it, and learned quite a bit over the last year and a half of reading & watching VoDs. The reading list is good (and yes, I recommend you read all of them), but there are a few books that should be highlighted:

Definitive MPLS Network Designs
Optimal Routing Design

I'm old enough to remember reading (several times) the precursor to Optimal Routing Design : Advanced IP Network Design, which is not on the reading list, but I recommend with the caveat that not all of the material is relevant anymore.

This gets into one of the most difficult parts of any exam: ignoring or realizing what is no longer relevant.

Anyway, thanks everyone for the congratulations, and keep tuned in for more.

What is the issue with re-marking and OoO packets?

ryan.niemes@gmail.com (ryan) — Sun, 30 Aug 2009 16:14:00 +0000

This question, taken from the CCDE Written Outline, taught me something new. Since that's the purpose of any certification, I welcome these interesting, if somewhat vague, questions.

The main issue with re-marking and Out-of-Order packets can be found in RFC3819: (aka BCP89)

"reordering does come at a cost with TCP as it is currently defined. Because TCP returns a cumulative acknowledgment (ACK) indicating the last in-order segment that has arrived, out-of-order segments cause a TCP receiver to transmit a duplicate acknowledgment. When the TCP sender notices three duplicate acknowledgments, it assumes that a segment was dropped by the network and uses the fast retransmit algorithm [Jac90] [RFC 2581] to resend the segment. In addition, the congestion window is reduced by half, effectively halving TCP's sending rate. If a subnetwork reorders segments significantly such that three duplicate ACKs are generated, the TCP sender needlessly reduces the congestion window and performance suffers."

In English, this means that if your Service Provider is doing any sort of re-marking (with a traffic policer, for example) your TCP flows may suffer due to re-ordering within the network. Let's say your SP provides a subrate Ethernet attachment circuit to you at 10Mbps. You're permitted to go over this rate but your traffic will be classified as less-than-best-effort (COS=1). You begin transmitting a large PDF via FTP. Once your flow goes over the committed rate, it was remarked to COS=1. Next, those packets are delayed within the core through a shaping mechanism (realizing that in the real world, less-than-best-effort would most likely be policed). Anyhow, the packets are delivered out-of-order due to this shaping policy. Meanwhile, the TCP session established by FTP notices segments are arriving out-of-order and performs the fast retransmit algorithm. This causes your FTP transfer to slow down during the transfer.

Now that we know this, how will it influence our design?

The first and most obvious result would be to configure an outbound shaping policy to match the SP's subrate Ethernet AC. In general, reordering is not something that we can design for, as once we hand-off the packet to the provider we cannot control the path it takes. Within our own network, we can reduce the number of paths a packet takes by using traffic engineering or reducing the number of equal-cost links. Within Cisco devices, CEF attempts to ensure the same path is taken by using a hash of the socket information. This is one of the reasons equal-cost paths may not show equal utilization.

RIPv2 advantages & disadvantages

ryan.niemes@gmail.com (ryan) — Sat, 13 Jun 2009 15:36:00 +0000

RIPv2 gets a bad rap, in my opinion, because it still has some suitable network topologies that it works well for. It's kind-of like the visceral reaction some people have towards static routing. There's no 'right' answer for most of these design types of decisions, only 'better' answers. As for RIPv2, let's see some of the advantages:

It's a standardized protocol
It's VLSM compliant
Provides fast convergence, and sends triggered updates when the network changes
Works with snapshot routing - making it ideal for dial networks

Of course, it's not all sweetness & light, there are some disadvantages:

Max hopcount of 15, due to the 'count-to-infinity' vulnerability
No concept of neighbors
Exchanges entire table with all neighbors every 30 seconds (except in the case of a triggered update)

I think the biggest advantage of RIP are its simplicity, standards compliance, and snapshot routing capability. I've recently had to use RIPv2 on a customer network to solve a very specific problem. The reality of the situation was that no other protocol would work as effectively as RIPv2 does.

I work a lot with Linkway TDMA satellite modems at work, and while these modems do support OSPF and BGP, they also support RIP. We found that the use of RIP solved a problem elegantly and with a minimum of configuration overhead. It's also much easier to teach the operators than something like OSPF or (gasp) BGP.

I failed the CCDE... now what?

ryan.niemes@gmail.com (ryan) — Thu, 30 Apr 2009 15:03:00 +0000

I checked the online certifications tracking tool and found out that I have failed my first attempt at the CCDE. What does this mean to me, and what am I going to do about it now?

I've already registered to sit for the next practical exam in August (Chicago, IL). This leaves me with roughly 4 months to prepare for the next attempt. While balancing other work obligations that cause me to learn fairly unrelated topics, how will I study and what will I study until then?

I'm going to review the SRND documents posted on CCO. I really haven't given these a serious chance, with the limited exceptions of the document: Layer 3 Routed Access Layer, and Enterprise QoS. Both documents were useful, and I'm sure there are more useful SRND documents that I need to look at.

I'm going to reread Optimal Routing Design and Definitive MPLS Network Designs.

As everyone knows who has been preparing for this exam - it's exceedingly difficult to study for, so that's my tentative plan. I will most likely cram more material in there over the next 4 months, but it's going to be very difficult as there are several competitive forces for my time. Specifically, summer in San Diego is going to be nice (as usual) and I'm currently supporting a major wireless deployment that has my time solidly booked up.

Regardless, I'm disappointed I didn't pass the CCDE, but excited to deepen my understanding of network design.

Update

ryan.niemes@gmail.com (ryan) — Fri, 10 Apr 2009 03:14:00 +0000

Nothing yet from the CCDE team. It's only been 8 weeks.

Next date for practical

ryan.niemes@gmail.com (ryan) — Fri, 13 Mar 2009 14:39:00 +0000

Registration opens 1 April for a 26 August lab date. More info.

New lab location: Hong Kong.

IS-IS, MPLS-TE, and wide metrics

ryan.niemes@gmail.com (ryan) — Tue, 17 Feb 2009 19:38:00 +0000

I came across an interesting topic in the book Traffic Engineering with MPLS yesterday. The topic involves migration from narrow to wide metrics. As you know, wide metrics are required to support MPLS TE, so if you have a network that is currently deployed with narrow metrics (the default) you will have to migrate to the wide metric style. You may even have devices that only support narrow metrics, so you'll have to figure out what to do with them in the meantime - perhaps they won't be in the path of TE tunnels, so you might not need to replace/upgrade them immediately. Anyway, starting on page 465, the book details two procedures to migrate from narrow to wide metrics:

migrating from narrow to wide metrics in two steps
migrating from narrow to wide metrics in three steps

Why the difference in steps? Well, the first one involves enabling all routers to advertise & accept both styles of metrics, which will increase the size of your LSDB by roughly 2x. The three step program takes longer but does not require the same amount of memory.

Here's a good link from cisco referenced in the book. Transitioning IS-IS to a New Technology

Took the CCDE Practical Exam Today

ryan.niemes@gmail.com (ryan) — Thu, 12 Feb 2009 00:22:00 +0000

14 people in Chicago and 14 people in London took the test today.

First impressions:

1. It's very, very difficult
2. I don't think it's "impossible"

However, I will caveat this with - I don't really think I have a chance at passing.

In all, I had fun taking it. I'm mostly relieved to have had a chance to finally see what it was all about. I think Cisco has done a good job with this test.

There's nothing I can say that has not already been posted/said before. If you haven't gotten a chance, you should check out the demo posted on the Cisco learning network.

Now I wait - 6 to 8 weeks - for the results.

Content Networking & Satellite Communication

ryan.niemes@gmail.com (ryan) — Sat, 13 Dec 2008 16:56:00 +0000

I work primarily on satellite communications systems. TDMA and FDMA satellite networks present interesting data communications issues, since our RTT is usually on the order of 700ms. One thing we've been experimenting with is caching of data. The NME-WAE product works well for caching, but can occasionally 'cause' problems that are exacerbated by virtue of the highly latent network. An example is the 'bypass' feature. By default, if the WAE sees an error returned by the web server, it will install a bypass rule in the attached WCCP device and allow the traffic to be forwarded normally. Now, the WAE isn't causing the issue - it's simply responding to the fact that the web server has returned an error. The bypass also prevents objects that have been previously cached from being hit. I suppose this behavior is to prevent the caching of bad data. On a normal low-latency network the bypass wouldn't be an issue but since we have such high latency, the entire site being bypassed causes the user experience to suffer.

When desigining for this type of issue, you would have to make a decision on how to handle errors. Fortunately, the NME-WAE gives us a few options on how to handle errors. You can configure the WAE to send the error message to the user (which renders in their browser and can be pretty ugly). You can also configure the WAE to simply reset the connection and allow the user to try again.

I configured the following commands:

ContentEngine(config)# error-handling send-cache-error
ContentEngine(config)# error-handling reset-connection

Of course, the explicit configuration is bit-level and unlikely to be on a CCDE exam, so I'm really just documenting it so I don't forget.

To see if you've got sites being bypassed you can use the command:

ContentEngine# show bypass summary
Total number of requests bypassed = 0
Requests bypassed due to system overload = 0
Requests bypassed due to authentication issues = 0
Requests bypassed due to facilitate error transparency = 0
Requests bypassed due to static configuration = 0
Total number of entries in the bypass list = 1
Number of Authentication bypass entries = 0
Number of Error bypass entries = 0
Number of Static Configuration entries = 1
L2 Bypass:
Number of L2 bypassed packets = 0
ContentEngine#

ContentEngine# show bypass list

(SOURCE: http://www.cisco.com/en/US/docs/app_ntwk_services/waas/acns/v55/configuration/local/guide/55ldg.html)

What can you take away from this? Basically, unless you work on or design for LFN style networks, you can lose sight of how you must design for latency. I think we'll start seeing increasingly latent networks moving forward, as satellite communications systems start being used more and more.

Fast convergence & carrier-delay

ryan.niemes@gmail.com (ryan) — Fri, 12 Dec 2008 15:57:00 +0000

I'm reading Definitive MPLS Network Designs and I came across an interesting detail with respect to carrier delay. Carrier delay is how long to wait before signaling to the control plane a detection of a network link failure. By default, the interface will wait 2 seconds before signaling failure. Typically, it is a best practice to configure the carrier-delay to 0 so it signals immediately. However, if the underlying transport has a recovery time, it may be better to wait before signaling the carrier loss. For example, if you have a protected SDH link with a recovery time of 80ms, you should wait at least this long to allow SDH to recover the transport.

The same question applies if you're configuring a carrier-delay on a transport where the circuit frequently drops and then recovers itself. A good example would be a dirty serial link that frequently drops for a few seconds and then recovers itself.

References:
IOS Command Reference

IP SLA & DSCP testing

ryan.niemes@gmail.com (ryan) — Wed, 26 Nov 2008 22:56:00 +0000

I had an occasion to do some IP SLA testing. We needed simple icmp-echo probes that would measure delay & loss. We also wanted to configure icmp-echo probes with DSCP=EF in order to measure delay & loss of our priority traffic.

Interestingly enough, the DSCP values are copied in the reply packets - at least from a Cisco router. IP SLA responder is not necessary for this to work.

The following configuration worked for us:

ip sla 1
icmp-echo 172.16.0.4
source-ip 172.16.0.2
frequency 5
history distributions-of-statistics-kept 10
history statistics-distribution-interval 100
history lives-kept 2
history buckets-kept 60
history filter all
ip sla 2
icmp-echo 172.16.0.4
source-ip 172.16.0.2
tos 184
frequency 5
history distributions-of-statistics-kept 10
history statistics-distribution-interval 100
history lives-kept 2
history buckets-kept 60
history filter all

You can then use the following command to schedule both probes:

ip sla group schedule 1 1-2 schedule-period 5 start-time now

You can see that in probe 2 I added a TOS value of 184, which is equivalent to DSCP=EF. I used the probe to generate traffic and captured the resultant packets to verify they were indeed DSCP=EF.

NMS Topic : NetFlow

ryan.niemes@gmail.com (ryan) — Fri, 19 Sep 2008 02:55:00 +0000

NetFlow began its life as a routing technique similar to Fast Switching or CEF. It has since evolved to become a useful accounting technology.

Cisco NetFlow consists of three components:

Network traffic analysis and collection (performed on a network element)
Flow record export (network device sends the records to a 'collector')
Flow analysis (automated or performed by humans at a NMS console)

Flow records contain any number of KEY fields, including

Source/destination IP address
Protocol and Port
ToS values

NetFlow has gone through several revisions, but the most popular ones are:

version 5 - probably the most widely deployed version
version 8 - specific to the Catalyst 6500
version 9 - this is the version you should be deploying

For those of you looking for an IETF standard, the IPFIX working group used the version 9 architecture as a starting point.

What NetFlow is:
You can use NetFlow to help you with Traffic Engineering, security analysis, and billing. Since it is low cost (free on Cisco devices), you can more easily deploy NetFlow than external RMON probes.

What NetFlow is not:
NetFlow is not a replacement for a protocol analyzer. Think of NetFlow as a "phone bill" for your network. You are less concerned with the details of a particular conversation, but you are concerned with who talked with whom, and how long the conversation lasted (the cost). NetFlow Data Export (NDE) rides UDP, so it susceptible to the same problems as other UDP applications.

Under what circumstances would you deploy NetFlow, and what design considerations do you need to keep in mind?

Engine (Record Generator) Placement
Try to minimize the amount of duplicate records. Configure NetFlow accounting on ingress and egress interfaces. It is usually not necessary or desireable to configure NetFlow on transit devices.

Record Collector Placement
Place the collectors as close to the sources as possible.
You could use Anycast as a collection mechanism, with an out-of-band backhaul to a central management station.
Keep in mind the UDP nature of export.

NetFlow resources:

Flexible NetFlow Whitepaper

352-001

ryan.niemes@gmail.com (ryan) — Fri, 12 Sep 2008 22:18:00 +0000

Sorry I've not posted anything recently: I've been studying intently for 352-001. It must have worked out because I passed the qualification today. First attempt.

Here's what I need to work on:

QoS is definitely my weakest area. I think it's probably good to revisit my original plan of taking and passing 642-642

I am also weak in Management. Unfortunately there's not a good test to study for this, so I'm going to at least begin by reading Network Management Fundamentals.

I will also need to more intensely study the variety of MPLS offerings available. It opens up a whole new area of service provisioning.

study re-think

ryan.niemes@gmail.com (ryan) — Thu, 17 Jul 2008 01:14:00 +0000

I came to the realization after taking the demo that I should probably be changing how I'm studying for the CCDE. When I went for the CCIE I followed the path laid out from Cisco going CCNA -> CCNP -> CCIE and was satisfied with the preparation that this entailed. When I began in earnest to study for the CCIE lab I was much better prepared. Primarily in knowing exactly what I did not know and needed to concentrate on. I think the design track may be a better path for me to take in my pursuit of the CCDE - rather than proceeding directly to the CCDE written without getting the CCDP first. I've not taken the written exam yet, but plan to take the CCDP exam I need, 642-873, soon. What I've found so far is that the materials to prepare for 642-873 are just what I've been lacking. It goes into design topics at a more basic level than CCDE (obviously) but with enough detail to sate my appetite for network design that I've been looking for. The CCDP is a good certification to strive for, especially if you're on the fence about how to study for the CCDE. Regardless, I recommend the CCDP as an end in itself, whether you want to pursue the DE or not.

CCDE Demo and Practical information posted!

ryan.niemes@gmail.com (ryan) — Thu, 10 Jul 2008 23:20:00 +0000

Check out the demo here.

Practical book list here.

CCDE Written Outline Topic 4 : Logging Config Changes

ryan.niemes@gmail.com (ryan) — Tue, 08 Jul 2008 21:11:00 +0000

For "Identify best practices for configuration management (i.e. logging config changes, auditing "as running" vs "as configured," consistent feature application, etc.)"

I found some information in the IOS Configuration Fundamentals Configuration Guide.

Specifically, how to configure logging of config changes.

New Cisco Forum

ryan.niemes@gmail.com (ryan) — Tue, 08 Jul 2008 20:24:00 +0000

Cisco has recently introduced a new collaboration site: Cisco Learning Network

It looks like it will be pretty helpful to those of us preparing for the CCDE.

CCDE Written Outline Topic 4 : CMIP and TMN

ryan.niemes@gmail.com (ryan) — Tue, 08 Jul 2008 20:19:00 +0000

A few notes from the Written Outline Topic of Management:

"Identify when use of CMIP is appropriate"

CMIP stands for Common Management Information Protocol and was designed for OSI-based network management. It was designed as a competitor to SNMP and supports the following:

The ability to perform tasks - as opposed to SNMP which can only perform SET and GET
Logging and AAA
Better reporting of network conditions

SOURCE

"Identify when use of TMN is appropriate"

TMN stands for Telecommunications Management Network

I found this on Wikipedia : "TMN can be used in the management of ISDN, B-ISDN, ATM, and GSM networks. It is not as commonly used for purely packet-switched data networks."

TMN uses CMIP.

From what I've been able to gather, TMN and CMIP are appropriate for GSM and circuit-switched networks. I don't know of any implementations for packet-switched networks. Anyone care to disagree?

TMN Tutorial

CCDE presentation from Cisco Live 2008

ryan.niemes@gmail.com (ryan) — Sun, 06 Jul 2008 13:19:00 +0000

I did not attend Cisco Live, but someone has posted the presentation Russ White gave on the CCDE here.

A few comments on the information in this presentation.

Under the "why are we doing this" section they note that a lot of L3 design issues are coming up, despite being "easy". Expect a lot of L3 issues on the CCDE.

Business problems are the primary driver of the CCDE test questions.

The skill set tested should be timeless.

Is generally vendor neutral.

The practical will be computer-based - no lab environment.

You'll be presented with a bunch of information, from which you generate requirements. After answering some questions through a variety of means, you'll gain access to additional information.

CCO Documentation?

ryan.niemes@gmail.com (ryan) — Sun, 06 Jul 2008 12:46:00 +0000

CCO contains a wealth of information for those preparing for the CCIE exam. Unfortunately, that same information is not necessarily good preparation for the CCDE exam. The CCDE won't be testing your CLI skills, or even your Cisco feature implementation skills. No, the CCDE claims to test timeless network design skills, which requires something different. Design is considered a dark art, since most of the answers begin with 'it depends'. The trouble is, you're expected to know what the conditions for deployment will be, and as network designers we work with imperfect information. Customer requirements are fuzzy since customers sometimes don't know what they want. Feature parity between platforms can be frustrating. The CCDE will most likely be testing your ability to see big-picture issues instead of digging into the weeds. Nobody but the CCDE creators know, of course, but we can infer this information by the reading list and written outline.

Let's look at the first topic: IP routing

Explain route aggregation concepts and techniques.

Purpose of route aggregation
Scalability and fault isolation
How to Aggregate

Nothing in here will be specific to Cisco products. Nothing in here will be feature/platform dependent. What is in here, however, is IP routing protocol dependent.

What is the purpose of route aggregation?

We aggregate to scale our networks. By aggregating, we reduce the impact of a link flap in one area of the network. We hide topology through aggregation. Link-state and Distance-vector routing protocols aggregate in different ways. If we want to hide topology in link-state, we need to use areas for aggregation. Distance-vector by definition hides topology.

Do you notice what's left unsaid in the above question? I think a key question you need to ask yourself is:

What are the problems with route aggregation?

Route aggregation hides topology. Route aggregation can result in suboptimal routing. How do you fix these issues if you need to? Why should you care? Topological information hiding can be useful, but can be detrimental in the case of Traffic Engineering and Mobility. With Mobility, as your users move around the network you will be unable to aggregate as effectively. Suboptimal routing is something you may not care about immediately, but it could cause problems for your customers depending on link speed, etc, and you should know how to address these issues in your design.

back home..

ryan.niemes@gmail.com (ryan) — Sun, 06 Jul 2008 12:03:00 +0000

Hi everyone, I'm finally back home after a week without Internet access. I've received a lot of comments & emails that deserve replies and/or posts. I'll be working to address these issues shortly. Bear with me please as I recover from jetlag.

Fast Convergence Techniques: IS-IS

ryan.niemes@gmail.com (ryan) — Mon, 23 Jun 2008 04:09:00 +0000

We would be irresponsible as network designers if we did not study and appreciate IS-IS for the problems it can solve. IS-IS is a link-state protocol similar to OSPF. IS-IS uses TLVs (similar to BGP), and is thus easily extended. IS-IS and OSPF are the two choices you have when deploying TE on MPLS networks, so you should know how IS-IS compares with OSPF when your design requires fast convergence. Cisco has several resources on their site, which I've distilled into a few rules of thumb:

Increase LSP refresh timer to a high value
Increase MAX LSP lifetime to a high value
Tune PRC interval
Tune SPF interval
Tune LSP generation interval
Use BFD in lieu of fast hellos (on multiaccess networks)
Tune ISIS retransmit interval
Set overload-bit on startup
Disable hello padding
Use a single IS type where possible (note that Cisco default is L1/L2)
Use metric-style wide (not necessarily FC related, but is req'd for TE)

Also related: use isis mesh-group and configure point-to-point interface type on multiaccess interfaces where they are really point-to-point (think 2-member Ethernet segments).

References:
Cisco Technology Support Page
Cisco IOS 12.4 IS-IS Fast Convergence
Cisco Configuration Example

wordle.net graphic of CCDE outline

ryan.niemes@gmail.com (ryan) — Fri, 20 Jun 2008 04:40:00 +0000

courtesy of wordle.net