From: ccie2be (ccie2be@nyc.rr.com)
Date: Sun Jun 06 2004 - 19:46:05 GMT-3
Hey Andrew,
What a great email!!!
Have you considered writing a book on redistribution? I know I'd buy it.
Anyway, I'd like to ask you if there's a way to limit the damage ( to the
score on the lab) if, for whatever reason, redistribution doesn't completely
work.
Here's the scenario.
We're back from the lunch break about an hour. There's a route missing from
one of the routers. For some reason, although it was redistributed, it only
made it one hop away from where it was redistributed. Can't figure out why.
And, I can't spend too much more time on this - I still have another 30
points or so to do. But, I know I need it for BGP to work properly - it's a
loopback address to which I'm suppose to peer.
I can afford to lose the few points assigned to this redistribution task,
but if I can't get BGP to work even though it's configured 100% correctly,
there's virtually no chance of passing.
So, here's my question. Is there any way to work around this problem so
that even if I don't get the points for the redistribution portion of the
lab, I can still configure BGP, get it to work and still have a chance of
passing the lab? Is there any way to break the dependancy on redistribution
working 100% so that if everything else that depends on redistribution is
properly configured, the only points that are lost are the ones directly
assigned to redistribution?
My assumption is that if ibgp doesn't work, I'll probably lose all the BGP
points and use up most of the 20 point margin of error one gets going into
lab.
To me, it seems like a shame that someone should fail the lab because of the
cummulative affect of missing one little thing related to redistribution.
I've thought about this alot after my last attempt, but never came up with
way to limit the damage.
Thanks, Tim
----- 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 2: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