From: Andrew Caslow (abcaslow@netmasterclass.net)
Date: Tue Jun 08 2004 - 17:56:41 GMT-3
Tim,
You asked,
"if there's a way to limit the damage (of a faulty redistribution
configuration), in relation to the score on the lab if, for whatever
reason, redistribution doesn't completely work."
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: When you are presented with a complex redistribution
configuration requirement, never blindly perform 2-way redistribution
everywhere and then begin to pray. This oftentimes ends in chaos.
As mentioned earlier, be incremental in your approach to any
redistribution task.
I hope this helps.
- Bruce Caslow CCIE #3139
NetMasterClass, LLC
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
ccie2be
Sent: Sunday, June 06, 2004 6:46 PM
To: Andrew Caslow; 'Charles T. Alexander'; ccielab@groupstudy.com
Subject: Re: Redistribution - Limiting the damage
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
This archive was generated by hypermail 2.1.4 : Sat Jul 03 2004 - 19:40:35 GMT-3