quote:

---

Here is a suggested approach to addressing a complex redistribution scenario where “you to limit the damage (to the score on the lab) if, for whatever reason, redistribution doesn't completely work”:

First, perform as little redistribution as possible to attain the goal of universal connectivity. For example, if you have two or more potential redistribution points between two or more routing domains, perform redistribution on the minimum number of redistribution points to attain the goal of universal connectivity.

If the network topology you have been presented with provides multiple connections between two or more routing domains and you want to utilize all of the interconnection points for redundancy, load balancing and optimal path section, do not be concerned with these enhancements at this time. You will get there. Again, in your initial stage of configuring redistribution, configure the minimum amount of configuration to attain the goal of universal connectivity.

Once, you have provided this minimum requirement, run a test to determine whether you have attained universal connectivity. This can be done by performing a manual ping to every IP address within your test pod from all devices within the same pod. This is a time consuming and potentially exhausting proposition. Instead of performing a manual ping, consider running the following TCL script on a Cisco router:

foreach router {
 172.16.101.1
 172.16.102.1
 172.16.103.1
 172.16.104.1
 172.16.105.1
} {
puts "\n\n\n\n\n\n\n\n\n"
set hostname [rsh $router show run | include \^hostname]
puts "Changing Router to $hostname"
puts " "
puts "*********************************************"
foreach address {
 172.16.101.1 
 192.168.101.1 
 192.168.102.1 
 192.168.103.1 
 192.168.104.1 
 192.168.105.1 
 172.16.12.1 
 172.16.10.1 
 172.16.40.1 
 } {
puts "\n\n\n"
puts $hostname
puts $address
rsh $router ping $address
}
}

This script is executed using the "rcmd" commands on each of the routers in your test pod. For more details on this script, go to
http://www.netmasterclass.net/site/lib.php
and download the paper titled: "Cisco IOS TCL and RCMD Testing and Troubleshooting Scripting". This paper will walk through (1) how to collect all IP addresses within your pod using a TCL script, (2) how to configure the sample script above and (3) how to enter the appropriate RCMD commands on each router.

There are other ways of testing for universal connectivity. We use different methods in our CHECKiT grading tool. However, the method stated above is an excellent method to consider using in a Cisco CCIE lab testing environment because you can run the script right on a Cisco router.

Use whatever technique you are most comfortable with to test for universal connectivity. Once, you have proved that you have attained universal connectivity by configuring the minimum amount of redistribution possible, then begin to incrementally expand your redistribution configuration to deploy levels of redundancy, load balancing and optimal path selection.

With every incremental increase of complexity in your redistribution configuration, run a connectivity test using a tool like the sample TCL script displayed above. Performing a connectivity test every time you add an additional command to your redistribution configuration sounds like it is prohibitively time consuming. At first it will be time consuming when you are in the learning and mastering stage of the task of redistribution. However, once you developed a strong understanding of the topic and you have solidified your incremental approach to redistribution, you will not need to perform a universal connectivity test after each incremental increase of the complexity of your redistribution configuration.

Another recommendation to consider when performing redistribution is to enable the following IOS debugging tools:

  debug ip routing

If OSPF is involved in the redistribution process, then enable "debug ip ospf lsa-generation" If EIGRP is involved, then enable "debug ip eigrp" If ISIS is involved, then enable "debug isis local-updates"

If "debug ip routing" generates output that show a redistributed route constantly being ADDED and DELETED to the local routing table, more than likely you have some type of redistribution problem.

With the routing protocol specific debugs, if you see a prefix, LSA or LSP being constantly added and deleted, this typically reflects a redistribution issue.

For example, "debug ip ospf lsa-generation" will display the generation of external LSA's. When this debugging tool shows healthy External LSA's being generated, the LSA's will have an age of 0 and a metric of whatever value was assigned to the external prefix at the time of redistribution (the default value is 20). However, when OSPF wants to purge an external LSA, it advertises the prefix with an age of 3600 (the OSPF maxage) and a metric of 16,777,215 which is 2^^24-1. An OSPF External LSA has a 24 bit metric and when this 24 bit metric possesses a value of 16,777,215, it is being advertised with an infinite distance, i.e., the prefix is unreachable. In summary, when you see an OSPF external prefix being advertised in an alternating fashion with values of age=0/metric=20 and age=3600/metric=16777215, more than likely you have some type of redistribution issue.

You will see similar output from the debugging tools for EIGRP and ISIS listed above.

So to summarize......

If you encounter a complex redistribution requirement and you get stuck, consider the following points:

1. perform as little redistribution as possible to attain the goal of universal connectivity
   
   
2. Once you have provided the minimum configuration, test for universal connectivity. Consider using the TCL script mentioned above.
   
   
3. Once you have proved that you have attained universal connectivity with the minimum redistribution configuration, incrementally increase the complexity of your configuration to attain the desired goals of redundancy, load balancing, optimal path selection, etc.
   
   
4. While enhancing your redistribution configuration, enable some of debugging tools mentioned above. These will act as your "redistribution heart monitors".
   
   
5. Continue to test for universal connectivity frequently. If you lose universal connectivity while increasing the complexity of your redistribution configuration, revert back to your minimum configuration. This should be your worst case scenario.

Therefore, in your worst case scenario, you have configured minimal redistribution and you have attained universal connectivity; however, you have not taken advantage of the underlying physical topology of your Scenario network. For example, let's say your Scenario topology provides you with multiple interconnection points between two routing domains and you have not taken advantage of the redundancy your Scenario network provides you with. You may now have the connectivity you need to go on to other topics such as BGP and multicast, but you may not have fulfilled the redistribution requirements to the level of satisfaction that the particular CCIE lab is looking for.

Now, how do you deal with this situation? Unfortunately, there is no absolute answer. You can ask the proctor for some guidance and direction, but you are not guaranteed that you will get the response you hope for. It does not hurt to ask. Always ask the proctor a question when you have one!!!

The general recommendation for this situation is two-fold:

Recommendation #1: In a CCIE scenario, perform only as much redistribution as the exam asks you to perform. If the exam you are performing asks you to use all possible links for redundancy, then configure your redistribution to the multiple links to provide for redundancy. However, do not go over board and fret about optimal load balancing, optimal path selection and symmetric routing unless the exam scenario asks you to consider these issues.

Hopefully, when you are studying the topic of redistribution, you learn the techniques to deploy redistribution while considering all of these factors: redundancy, load-balancing, optimal path selection and symmetric routing. The NetMasterClass DOiT labs will expose you to all of these issues. If you want to learn about redistribution, consider performing the DOiT labs. The scenarios possess challenging redistribution tasks and the Spot the Issues Answer Key provides excellent diagrams, tables and descriptions of the solutions to these tasks.

Recommendation #2: Never blindly perform 2-way redistribution everywhere and then begin to pray. This is almost always a disaster.

As mentioned earlier, be incremental in your approach to any redistribution task.

I hope this helps.

- Bruce Caslow CCIE #3139
NetMasterClass, LLC

---

quote:

---

Here are some suggested tips and suggestions for dealing with redistribution issues. I originally drafted this e-mail earlier this year in response to a similar question posed by one of the NetMasterClass DOiT subscribers. When I drafted the original e-mail, it spiraled into a rather lengthy response. In an effort to avoid being too obtuse, I curtailed the drafting of this e-mail to a reasonable length. Topics and explanations contained within this e-mail, as well as follow-on topics, will be part of a series of tech-notes that will be published on the NetMasterClass web-site. Two of these Tech-Notes are referenced later in this e-mail.

References in this e-mail will be made to the NetMasterClass DOiT workbook; however, the techniques and points made can be applied to any other vendor's scenario involving redistribution. One of the original design objectives of the DOiT scenarios was to provide challenging redistribution problems. Many of the 22 DOiT labs possess rigorous redistribution problems. To provide a detailed explanation of each scenario's redistribution problem, the companion Spot the Issues Answer Key possesses a detailed color coded redistribution map, along with a redistribution table as well as a description of the redistribution solution. Finally, all related redistribution configuration commands can be accessed via the DOiT SHOWiT engine. To download a sample DOiT Scenario along with a Spot the Issues Answer Key, go to
www.netmasterclass.net
Also, to see how the NetMasterClass SHOWiT technology can help you get the most out of your answer keys, go to
www.netmasterclass.net
for a demonstration.

Now, let's begin to answer your question: "Is there some general strategy and approach to performing redistribution?"

In answering this question, let’s first consider the following three points:

1. Remember that redistribution is a non-standard operation. For example, there is no RFC that outlines how to perform redistribution. As result, there is no industry recognized technique for performing redistribution.
   
   
2. In production networks, the process of redistribution is not something performed casually. Redistribution must be performed in a very controlled manner and usually redistribution is performed as a last resort. The general practices are: (1) for a given single administrative routing domain, attempt to run a single routing protocol whenever possible and (2) if you are going to perform redistribution, perform it in a hierarchical manner. Remember this phrase “HIERARCHICAL MANNER”. It is the key principle to successfully performing complex redistribution.
   
   
3. Remember with redistribution, you usually lose information. For example, when you perform redistribution between EIGRP and RIP, how do you convert an EIGRP composite metric to a RIP hop count? Conversely, how do you convert a RIP hop count into an EIGRP composite metric? The answer is, “You really can’t easily convert these two metrics.” The best you can do is convert these metrics to an arbitrarily assigned metric. You can do this with a single metric statement or you can be more granular with this assignment with a route-map.

How does all of this help us in the CCIE lab? Upon first glance, not much since you know you are going to have to perform redistribution between at least three routing protocols. You will not have the opportunity to make the design decision of configuring a single routing protocol in the CCIE lab. However, the key points you need to take away from the three points stated above are: much of what a single routing protocol is designed to do – (1) select the best path to a given prefix and (2) prevent the development routing protocol pathologies such as the creation of loops and blackholes – is oftentimes broken by route redistribution. The key issue all of these points force us to address is: how is the best path to a given prefix selected in a fragmented multi-IGP environment? When a single path to a given destination prefix is made up of multiple IGP’s there is a high likelihood of inconsistent criteria for path selection (part of the path is selected based upon something like a “hop count”, the other part of the path is selected based upon something like “a composite metric”) – AND – the same path will be using different techniques for loop avoidance, blackholing and route flapping (for example, while an OSPF router might be recalculating its SPF tree to accommodate a route that has been reported as down, RIP might be placing that same route into a “holddown” state).

With these points made, let’s begin to answer the original question: “What is the best method to approach any redistribution problem, from the simplest to the most complex?” The answer lies in the following (4) points:

1. With your redistribution operations, CREATE A ROUTING HIERARCHY. (What is exactly meant by this? Please read ahead.)
   
   
2. When performing complex route redistribution tasks: initially, perform as little redistribution as possible to fulfill the goal of universal connectivity. Attaining this configuration will be called the “Golden Moment”.
   
   
3. Once universal connectivity is attained through the most minimal amount of redistribution, incrementally increase the complexity of your redistribution configuration to add more robust levels of redundancy, load balancing and optimal path selection.
   
   
4. DO NOT APPROACH A COMPLEX REDISTRIBUTION REQUIREMENT BY PERFORMING TWO-WAY REDISTRIBUTION EVERYWHERE. Many attempt to fulfill complex redistribution requirements in this manner with the hope that it will work without creating any types of reachability problems. If this method does result in the creation of routing problems, then attempts are made to adjust this “perform two-way redistribution everywhere” technique so that it works properly. DO NOT APPROACH COMPLEX REDISTRIBUTION REQUIREMENTS IN THIS MANNER.

As mentioned earlier, at the heart of implementing a successful redistribution configuration is the underlying task of creating a routing hierarchy. How do you create a routing hierarchy? Let’s consider the following steps:

First examine the physical topology. Are there any loops in the physical topology? There will be two possible answers to this opening question:

1. There are no physical loops.
   
2. Physical loops exist.

A REDISTRIBUTION SOLUTION ON A PHYSICAL TOPOLOGY WITH NO LOOPS

If there are no loops in the physical topology, then any redistribution requirements you have should be simple. A loop free physical topology directly supports the creation of a routing hierarchy.

If there are no loops in a physical topology, there will be an unambiguous set of transit physical links and non-transit physical links. In a loop free physical topology, all non-transit physical links will be “stub” links. A “stub” physical link is defined as a link that has one and only one connection into the rest of the physical topology.

Now, let’s apply the theme of a “routing hierarchy” to a loop-free physical topology. The routing protocol(s) deployed on the transit physical links will be classified as “core” routing protocol(s). The routing protocols that are deployed on the non-transit “stub” physical links will be classified as “edge” routing protocols. A loop free topology creates an implicit two tier routing hierarchy: (1) transit routing domains in the core and (2) edge non-transit routing domains on the edge. (Question: Can you think of any IGP’s that create a two tier routing hierarchy? Answer: OSPF and IS-IS.)

Here is the Redistribution Solution to this type of topology: One-way redistribution will be sufficient to fulfill the redistribution requirements in a loop free physical topology. The edge non-transit routing domains will redistribute their prefixes into the core transit routing domains. This is performed to allow the core routing protocols to provide return path routing paths back to the edge routing domains. (NOTE: Performing one-way redistribution will make the core routing protocol domains a “default free (routing) zone” – DFZ. The DFZ is a very important concept in large scale hierarchical routing. For more info on DFZ routing, do a google search on “DFZ routing”. The concept applied in “DFZ routing” will be important to our topics covered later in this e-mail.) A default route can be injected into the edge non-transit routing domains on the routers performing the one-way redistribution. There is no problem or danger with performing two-way redistribution between core transit routing domains and edge non-transit routing domains. In a loop free physical topology, such operations do not create a danger; however, such operations can be superfluous and highly inefficient.

Great, we now have a solution for redistribution. However, this solution is for a loop-free topology that facilitates the creation of a two tiered routing hierarchy. This is the simplest type of topology to deal with.

Now, closely examine the physical topologies of all of the Scenarios in the DOiT workbook. Question: How many of these Scenarios possess a loop free topology? Answer: Very few of them. Therefore, the redistribution solution described above is of minimal use for the majority of the DOiT Scenarios.
Now, we must examine the following type of redistribution problems:

A REDISTRIBUTION SOLUTION ON A PHYSICAL TOPOLOGY WITH LOOPS

When you have identified that a Scenario’s physical topology possesses one or more loops, perform the next step:

Are the loops in the physical topology contained within a single IGP routing domain? If the loops in the physical topology are contained within a single IGP, life is good. The single IGP that contains the physical loops will select the best possible path between the two or more paths created by the loops AND the single IGP will apply consistent loop avoidance methods.

Are the loops in the physical topology spread over multiple routing domains? If yes, well NOW you have encountered the most challenging type of redistribution problem! Let’s outline an approach to this type of redistribution problem. When you examine the physical topology’s of most of the DOiT Scenarios AND you examine the layout of the IGP routing protocols over these physical topologies, you will see that many of these Scenarios contain looping physical topologies that are spread over multiple routing domains. These characteristics can be easily –and colorfully seen – by examining the Redistribution Section of each Spot the Issues Answer Key for each Scenario (RIP links are colored blue, OSPF links are colored red, EIGRP links are colored green, ISIS links are colored magenta). Along with this diagram is a description of the logic applied to the redistribution for each Scenario along with a redistribution table summarizing whether one-way or two-way redistribution was performed between two routing protocols, and whether some prefixes were filtered during the redistribution process as well as whether the administrative distance has been adjusted for a set of prefixes.

Review and examine the contents of the redistribution section of each of the DOiT Scenarios. When you examine the redistribution solutions supplied in each DOiT Scenario, look for the key ingredient of a successful route redistribution configuration – it was mentioned earlier in this e-mail – THE CREATION OF A ROUTING HIERARCHY.

Now the next issue that must be addressed is: How is a routing hierarchy created when you are presented with a looped physical topology and the loop physical topology is spread over multiple IGP domains?

This is not an easy or straight forward question. Here is a suggested approach:

Classify the links in your topology by bandwidth capacity. Let’s use the following assignments.

ATM OC-3 155 Mbps
FastEthernet 100 Mbps
Ethernet 10 Mbps
Frame-Relay 128 Kbps
ISDN 128 Kbps
Point-to-Point Dedicated 128 Kbps

With this information, you must answer the following types of questions:

What is a better path to a given destination, a path made up of a single 128 Kbps Frame-Relay link OR a path made up of 1 ATM OC-3 link and 1 FastEthernet link?

Answering these types of questions will allow you to determine where you want to place the backbone of your Scenario topology.

Once you have determined where you want to locate your Scenario backbone, determine which IGP routing protocol(s) contain these links. These routing protocol(s) will constitute your core transit routing domain(s).

All other routing protocols will comprise the set of non-transit routing domains. Non-transit routing domains can be further classified into the following two groups:

1. Stub non-transit routing domains
   
2. Multi-homed non-transit routing domains

Of the two non-transit routing domains, stub routing domains are the more simplistic. As mentioned earlier, a stub routing domain has only one physical connection to another routing domain.

A multi-homed routing domain is more complex. It possesses two or more connections to another routing domain or set of routing domains.

IT IS THE CREATION AND THE PROPER TUNING OF THE NON-TRANSIT MULTI-HOMED IGP ROUTING DOMAIN(S) THAT IS A KEY ELEMENT TO PROPER COMPLEX ROUTE REDISTRIBUTION CONFIGURATION. THE NON-TRANSIT MULTI-HOMED IGP ROUTING DOMAIN IS THE KEY BUILDING BLOCK TO CREATING A “ROUTING HIERARCHY” IN A COMPLEX REDISTRIBUTION SCENARIO.

Methods of tuning non-transit multi-homed IGP routing domains involve the configuration and application of distribute-lists, route-maps and distance commands to the redistribution process.

Before going any farther, let’s define the difference between a transit routing domain and a multi-homed non-transit routing domain.

A transit routing domain, imports external routes from one routing domain and advertises these same external routes to another routing domain.

A non-transit multi-homed routing domain, can import external routes from one routing domain; however, it does NOT advertise these external routes to another routing domain. A non-transit multi-homed routing domain advertises only prefixes that originate from the domain itself and nothing more.

Central to the definition of the both transit routing domains and non-transit multi-homed routing domains is the issue of what a given routing protocol ADVERTISES. Therefore, by controlling what a routing protocol domain advertises will determine whether the routing domain is a transit or non-transit domain. Controlling what a routing domain advertises during the redistribution process will involve either a distribute-list or route-map.

I am going to stop drafting this e-mail here. Please let me know if any of this e-mail makes sense to you…. or if it is in any way helpful. We are planning to publish a number of tech-note papers on the topic of “redistribution”. These tech-notes will be available on the NMC web-site.

What the upcoming tech-notes will introduce is an IGP route redistribution technique that applies many of the same path selection and loop avoidance techniques used by BGP. These techniques will apply using routing tagging during IGP route redistribution.

IN CLOSING, SOME SUGGESTED STEPS TO APPROACH A REDISTRIBUTION TASK:

Here are some suggested steps to perform when planning your route-redistribution configuration for complex redistribution scenarios:

1. Examine the physical topology of the Scenario. Is it a loop-free topology or does the topology possess physical loops?
   
   
2. If the physical topology contains loops, are the loops contained within a single IGP routing domain or are the loops spread over multiple IGP routing domains?
   
   
3. If the physical loops are spread over multiple IGP routing domains, determine where you want to establish the transit core routing domain(s). Typically, you want the core transit routing domain(s) to possess the highest concentration of high-speed links.
   
   
4. Whatever routing domains are not core transit routing domains are non-transit routing domains. Non-transit routing domains can be classified as stub or multi-homed. To assure that a multi-homed non-transit routing IGP domain retains its non-transit status, care must be taken during redistribution. Whenever possible, only one-way redistribution should be performed from the non-transit routing domains into the transit routing domains. If two-way redistribution is being performed, filtering must be performed to prevent non-native (or external) prefixes from being advertised into the transit domain. Again, if a non-transit IGP routing domain advertises non-native (external) prefix, the non-transit routing domain is no longer non-transit. It becomes a transit routing domain for the prefix it just advertised.
   
   
5. Get to the “golden moment” – the stage in your redistribution configuration where universal connectivity is attained for all routers and switches within your topology WITH THE MOST MINIMAL LEVEL OF REDISTRIBUTION CONFIGURATION AS POSSIBLE.
   
   
6. Once the “Golden Moment” has been attained, enhance your redistribution configuration incrementally to provide your topology a more desired level of redundancy, load balancing and more optimal path selection. Whenever possible, use IGP route tagging techniques, to help identify routes as they pass throughout your routing domains. (More on IGP routing tagging in an upcoming tech-note.) Test for universal connectivity as you incrementally enhance your redistribution configuration. Streamline your testing with the tcl ping script that has been discussed several times on this discussion forum. If you are not familiar with this script download the tech-note titled “Cisco IOS TCL and RCMD Testing and Troubleshooting Scripting” from the following NMC site:
   http://www.netmasterclass.net/site/lib.php
   
   
7. For routers that are performing redistribution between two or more redistribution points, make sure the administrative distance is set so that prefixes originating from a native routing domain will select the native routing domain as a routing information source. For more information on manipulating the administrative distance in routing domains that possess two or more redistribution points, download the tech-note titled “A Scenario with Multiple Redistribution Points” from the NMC tech library:
   http://www.netmasterclass.net/site/lib.php

MORAL OF THE ROUTE COMPLEX ROUTE REDISTRIBUTION CHALLENGE:

“It is difficult to establish a hierarchical routing topology within a routing domain comprised of multiple routing protocols when your physical topology is not hierarchical AND the deployment of IGP routing protocols is performed in a non-hierarchical manner.”

I hope the contents of this e-mail has provided some useful points and suggestions to approaching route redistribution configuration requirements.

Best regards,

-Bruce Caslow CCIE #3139
NetMasterClass, LLC

---

• why connected ISIS networks are not redistributed as for other routing protocols
  
• why when I add redistribution of connected routes some prefixes which were redistributed from routing protocols prior to that go missing

   redistribute connected

• a protocol level (such as to apply to all routes entering the protocol on the router)
  
• on redistribution command level (such as to apply to all the routes entering the protocol via the particular redistribute command)
  
• on per-prefix basis via a route map attached to a redistribution command

quote:

---

Q: Should multipoint redistribution be considered in a scenario which does not specify such requirement or redundant path requirement?

---

• If you at home practicing for the exam preparation, I say time invested in IGP redistribution is well spend. IGP routing protocols continue to represent major portion of the exam points significant enough that it is not possible to pass the exam without getting IGP right. So in my view there efforts put in learning IGPs and redistribution is a great tool for that will not go wasted. Here is an opinion of one of the students
  

  quote:

  ---

  Originally posted by Chris Bryant:
  ...
  The one part of the DoIt labs that really stand out are the redistribution scenarios. I personally would say that when you can do the DoIt redistribution, you won't have much of a problem with Cisco's redistribution.
  
  The DoIt labs have very difficult redistribution, but take it from me, you learn a lot going through the process that will help you greatly on exam day.
  
  Chris Bryant
  CCIE 12933

  ---

  Note that the above is not limited to redistribution section of DOiT scenarios, the scenarios were build to ensure that a student who can comfortably complete them would not have technical difficulties on CCIE exam as DOiT scenarios are often more complex then actual exam.
  
  Having said all that, there is nothing in most of DOiT scenarios to make you adopt complex redundant multipoint redistribution design; you do have a freedom of adopting simpler approach of doing single point redistribution, and DOiT will continue to be a great learning tool then. (You would have configurations which vary more from SHOWiT versions though.)
  
  
• If you are on real CCIE exam, do not invent difficulties for yourself. This is a general rule applied to each and every part of the exam. To quote one of the proctors “the exam is difficult as it is and by adding extra requirements which are not there one would make it impassable”. So on the real exam if there is not a requirement for multipoint redistribution, only redistribute on a single router between 2 IGPs, even if you could have redistributed on two routers. Just carefully follow all explicit and implicit requirements present and do not invent your own. The exam is about router configuration and not about network design and best practices.

      / Lo0 172.16.102.0/24
    R2 
   /  \         RIP
  /    \        
R1      R3   ============
  \    /        OSPF
   \  /
    R4
      \ Lo0 172.16.104.0/24

      / Lo0 172.16.102.0/24
    R2 
   /  \         RIP
  /    \        
R1      R3   ============
  \    /        EIGRP
   \  /
    R4
      \ Lo0 172.16.104.0/24

• General Discussions:
  DOiT R&S Workbook « Scenario 2 » Question on Redistribution on R1
  DOiT R&S Workbook « Scenario 17 » filter routes vs resilience
  
  
• EIGRP unequal cost loadbalancing:
  DOiT R&S Workbook « Scenario 12 » EIGRP Load Balancing
  DOiT R&S Workbook « Scenario 12 » 12.7 EIGRP variance
  DOiT R&S Workbook « Scenario 19 » EIGRP
  DOiT R&S Workbook « Scenario 20 » EIGRP 20.6.2