From: Andrew Caslow (abcaslow@netmasterclass.net)
Date: Sun Jun 06 2004 - 15:03:43 GMT-3
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.
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:33 GMT-3