RE: Multiple route redistribution points

From: Scott Morris (swm@emanon.com)
Date: Tue Jan 30 2007 - 23:00:23 ART


During practice, you take the extra steps... Until you can anticipate
what's going to happen. (think like the router does)

As for mutual redistribution on the same router, it often poses no problem.
Most protocols (other than RIP) notice the difference of internal vs.
external routes. Other times, the AD may already be in the direction you
want it to be, so nothing needs to be done.

Don't count on this though! Especially in the lab. Things are seem TOO
EASY are often areas where points are lost!

But watching what happens to your routing table(s) is really the way to go.
Even in the lab, doing "debug ip routing" isn't a bad thing as long as you
are used to seeing the output and therefore know what it is you are looking
at!

 
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-J
IPexpert VP - Curriculum Development
IPexpert Sr. Technical Instructor
smorris@ipexpert.com
http://www.ipexpert.com
 
 

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of Li
Guoyi
Sent: Tuesday, January 30, 2007 8:11 PM
To: Scott Morris; Filyurin, Yan; ccielab@groupstudy.com
Subject: RE: Multiple route redistribution points

Hi Scott,

I am a bit confused by mutual redistribution also.
Are there any rules for multiple route redistribution points? Is it always
necessary to adjust AD? In the workbook solutions, sometimes no loop
prevention measures (like ajusting AD) are taken at all. How do we know when
the prevention measures are necessary? In addition, there are many
combinations of mutual redistribution, like Rip and OSPF, OSPF and Eigrp,
OSPF and BGP, etc. Will the rules apply to all the combinations?

Or as you said, we need to perform the step by step redistribution during
lab exam? It will take long time to finish redistrition portion this way.
Please advise.

Thanks,
Li

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Scott Morris
Sent: Tuesday, January 30, 2007 3:48 AM
To: 'Filyurin, Yan'; ccielab@groupstudy.com
Subject: RE: Multiple route redistribution points

As opposed to their being a "best way" (which there rarely is anything that
fits all circumstances), the best thing you can do is sit and plan,
configure and watch what occurs at each point.

A good way with this involves both TCL script for pinging (every IP address
of your network should be listed) and debugs...

Before doing any redistribution it is simple to predict what things you can
or cannot ping from any one location. Before doing any redistribution,
enable "debug ip routing". Assuming you have stable protocols to begin
with, when you do your first redistribution, you should see a predictable
influx of routes and be able to know what things can or cannot be pinged
from any location. (gaps here may answer your redistribute connected
question)

As you add more and more redistribution points, each time, repeat the
process. Again, you'll be able to watch the routes move (from the
debug) and test things with pings to make sure what you are getting lines up
with what you thought should be happening.

This process, while very tedious, is the best way to get a true grasp about
what your router is (or is not) thinking during the redistribution
processes. The ability to think it through and predict what will happen
will help you figure out what will happen in any situation that you happen
to run across. Also, using route tags may be a more efficient way of
allowing/not allowing routes in different places.

HTH,

 
Scott Morris, CCIE4 (R&S/ISP-Dial/Security/Service Provider) #4713, JNCIE
#153, CISSP, et al.
CCSI/JNCI-M/JNCI-J
IPexpert VP - Curriculum Development
IPexpert Sr. Technical Instructor
smorris@ipexpert.com
http://www.ipexpert.com
 
 

-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Filyurin, Yan
Sent: Monday, January 29, 2007 2:03 PM
To: ccielab@groupstudy.com
Subject: Multiple route redistribution points

Hello Group Study. I have a possible set of questions regarding route
redistribution. Let's say I have 4 routers A, B, C and D, all
interconnected and running the same routing protocol. For example OSPF.
Routers A and B connect to the same RIP domain and routers C and D connect
to say EIGRP domain. Mutual redistribution needs to be done between all IGP
protocols.

The first task that needs to be done is that since there are multiple
redistribution points, all I have to do is through the use of route tags
control so that routes from one routing protocol don't redistributed back
into it. That is pretty straightforward.

What becomes interesting is when it is a good idea to use distance command.
For example if routers A and B are acting as redistribution points into RIP
and RIP has higher distance than OSPF, then router B or router A will have
RIP routes from RIP domain and OSPF E1 or E2 routes that got redistributed.
So it would see logical to set distance of RIP to be 109 for example.
And if I do that suddenly OSPF routes from C and D not to mention routes
that came from EIGRP domain have a similar problem. On A an B they become
preferred through RIP. Similar problems could exist with EIGRP, but at
least with EIGRP it is easier since it does differentiate between external
and internal

Since RIPv2 does not distinguish between internal and external routes, I
guess I could do something, assuming I can't summarize and need complete
redundancy. I can set distance command to selectively choose which routes
get what distance and from what sources, but that takes access lists and I
have to do it both redistribution point routers. Is there anything else I
can do to make the whole thing easier and does any of this sound right?

Also is it always a good idea when doing mutual redistribution to
redistribute connected routes into all IGP protocols, that haven't been
redistributed previously or were not part of the network statement?

Yan



This archive was generated by hypermail 2.1.4 : Thu Feb 08 2007 - 23:46:58 ART