From: ccie (ccie@netchild.pub.sa)
Date: Sun Jun 06 2004 - 16:15:34 GMT-3
Andrew,
I have to say thank you for this great explaination.
NetChild,
----- Original Message -----
From: "Andrew Caslow" <abcaslow@netmasterclass.net>
To: "'Charles T. Alexander'" <charles.t.alexander@verizon.net>;
<ccielab@groupstudy.com>
Sent: Sunday, June 06, 2004 9:03 PM
Subject: RE: Redistribution Headaches
> Charles,
>
>
>
> 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 <http://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
> <http://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:
>
>
>
> 1). 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
>
>
>
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Charles T. Alexander
> Sent: Sunday, June 06, 2004 10:40 AM
> To: ccielab@groupstudy.com
> Subject: Redistribution Headaches
>
>
>
> The most difficult problem in doing labs I find is multiple
>
> redistributions on several routers. I have read all the usually books
>
> many times. I still run into issues. I guess I am looking for an
>
> article on the strategy and approach to redistribution.
>
>
>
> _______________________________________________________________________
>
> Please help support GroupStudy by purchasing your study materials from:
>
> http://shop.groupstudy.com
>
>
>
> Subscription information may be found at:
>
> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Please help support GroupStudy by purchasing your study materials from:
> http://shop.groupstudy.com
>
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:33 GMT-3