Kevin Dorrell, CCIE #20765

23 Feb 2008


Filed under: IP Routing Protocols, Redistribution — dorreke @ 06:47

One topic that wastes a lot of my time during CCIE practice labs is redistribution.  The issues often catch me unawares.  I wonder whether I can improve my performance by changing my approach.

So far, my method has been “detect, diagnose, and fix”.  Detect by setting debug ip routing and by examining routing tables.  Diagnose by looking at the symptoms to try and to figure out what is going on.  Fix by filtering and by manipulating distances.   It is the diagnose bit that takes the time.

Many people emphasise prevention.  This is largely based on making sure you don’t redistribute more than is absolutely necessary.  That helps, but it does not guarantee there will be no issues.

I want to see if I can benefit from a topology-based issue-spotting approach.  I’m sure that the successful CCIE condidates have a wide experience to draw on: that they can recognise certain situations and instinctively know how to deal with them.  I would like to build up a repertoire of issues that I can address before they trip me up.

For each case, I want to list:

  • the alarm bells that should have alerted me to the impending issue
  • the contributary factors, the circumstancial evidence
  • the modus operandi of the issue
  • the tools and techniques for fixing it.

For example, I tripped over an issue in NMC Lab 08 that could briefly described like this:

Name: RIP border loop 

Alarm bell: Border router with two “neighbors” (i.e. next-hops) in RIP domain

Contributary factors: Route injected into RIP at AD > RIP (120)

Modus operandi: Bidirectional route feedback within RIP, leading to race condition, and possibly overwriting the injected route at the border router.

Tools and techniques: Try not to inject route at AD > RIP.  If that is not possible, filter routes coming into border router from the RIP neighbors to allow only RIP native routes.

 Here is another one:

Name: OSPF<–>RIP, redundant BR (I need a more succinct name for this one)

Alarm bell: Two border routers between OSPF and RIP

Contributary factors: None – this situation is already the issue itself

Modus operandi: Bistable sub-optimal routing for RIP-native routes. (One border router will route RIP routes correctly, the other will route them via the OSPF external route.)  Possible race condition if both are redistributing OSFP<–>RIP.

Tools and techniques:  Each border router punishes OSPF external routes from the other by setting AD > RIP (120).  Filter redistributed routes to prevent RIP routes finding their way back into RIP.

For each of these cases, I would like to write a posting with a lot more detail under each of the four headings.


Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at

%d bloggers like this: