Overview of Routing Protocol Redistribution in CCIE Exams:

You might be able to avoid redistribution in your production environment, but in CCIE lab exams, sorry – it is inevitable. Redistribution is covered here and there in the massive CBT Nuggets CCIE Part 3 course, but I thought I would review some things and provide guidance for you here specifically on this topic. This area has been known to freak students out, especially since routing loops and feedback allow you to instantly fail your CCIE lab exam. Hopefully after you read this, your fears are destroyed. And let’s face it, routing loops and routing feedback issues are very rare.

Review and Guidance:

• Routing protocol redistribution refers to  taking prefix information from another routing domain and bringing that in to your local routing domain. Here routing domain simple refers to the group of routers that are all speaking the same routing protocol. We typically redistribute so that we have full IP reachability between these different routing protocol domains. You might have multiple routing domains because your company is merging with another company, or you want to mesh different parts of your company running different protocols for some reason.
• When you redistribute from one routing protocol to another, you immediately discover an issue. Different routing protocols use different metrics. For example, if you are bringing RIP routes (heaven forbid!) into EIGRP, you have a Hop Count metric that does not directly correlate to the potential composite metric of EIGRP (Bandwidth, Delay, Reliability, Load, MTU). How do routing protocols handle this? It is called the seed metric. This is what the external prefixes will have for a metric as they start life in the new routing protocol domain (the internal domain). Different routing protocols have different default seed metrics. For example, OSPF will default prefixes to a cost of 20 if you do not specify another value, while EIGRP will not accept external prefixes without a seed metric specified.
• I recommend you always set a seed metric in the CCIE lab exam. This prevents you from worrying about whether or not it is required. The only exception to this of course would be if the explicit redistribution instructions tell you that you are to use the default seed metric. Note that this is highly unlikely.
• Context sensitive help is absolutely critical during redistribution. This will remind you of particulars for each protocol. For example, during redistribution into OSPF, you will be reminded of the subnets keyword and the two different types of external prefixes that you can specify.
• What can go wrong after redistribution? Well, two things really. One is that your traffic can take a suboptimal path through the network. This is not really a scare in the CCIE lab exam, unless the instructions explicitly or implicitly indicate a path a to take. The second is the scarier one, routing loops. The great news is these are much harder to create then they are to fix typically. Routing protocols have built in mechanisms like administrative distance and routing logic to avoid these loops. The chances of you accidentally stumbling into a routing loop creation during your lab configuration is pretty slim.
• The success of your redistribution, or its failure, or even the rare creation of a routing loop can easily be detected with the powerful debug command of debug ip routing.
• If full reachability is the goal of your redistribution in the lab exam, this can easily be tested with a ping script to automate this testing.

The next post regarding CCIE lab redistribution will demonstrate what we have discussed in this first post. As always, thanks for reading and I welcome your comments below!