From: Schulz, Dave (DSchulz@dpsciences.com)
Date: Mon Nov 07 2005 - 01:01:04 GMT-3
Chris -
Interesting thoughts. So, by your example, you are saying that there
would be mutual redistribution at R2 and R3. Is seems to me that if you
use the tag method and both routers, and changed made it effectively
doing the reverse at each location, that this should do the trick. What
do we believe would happen differently, and, what would be a better way
to accomplish this task?
Dave Schulz,
Email: dschulz@dpsciences.com <mailto:dschulz@dpsciences.com%20>
________________________________
From: Chris Lewis [mailto:chrlewiscsco@yahoo.com]
Sent: Sunday, November 06, 2005 10:29 PM
To: Schulz, Dave; kevin gannon; nobody@groupstudy.com; Cisco Nuts
Cc: ccielab@groupstudy.com
Subject: RE: Rip <--->Ospf Redistribution - using distribute-lists?
Tags as configured below are indeed a nice way to stop routes from being
fed back in to their IGP of origin. However, that is often not enough to
eradicate sub-optimal routing. For example, take the simple topology
below:
R1--------R2
| |
R3--------R4
Each has a loopback on it from 1.1.1.1 for R1, 2.2.2.2 for R2 etc.
Now say R2 and R3 both run OSPF and RIP,
R1 only runs OSPF and R4 only runs RIP.
The optimal position is to have R1 see equal cost paths to the loopback
of R4 via both R2 and R3, however with tags alone, you will not be able
to achieve this. It will only see one.
Netmasterclass has an excellent write up on this in their public PDF
section.
Chris
"Schulz, Dave" <DSchulz@dpsciences.com> wrote:
This is a great subject, and one that I have been wrestling with
for awhile.
I have used the ACLs for the distribution, but Kevin is
right...you have to
maintain the ACLs. And, in a dynamic environment, this may take
a lot more
admin than one would care to admit. I have found that easiest
way to do the
redistribution is by using tags. I try to keep the same tag
number as the
administrative distance to keep things straight. So, if I am
redistributing
from OSPF to EIGRP....I use 110 as the tag and 90 in the reverse
direction.
This seems to work well and is very easy to implement and keep
things
straight.
The one thing that I have learned with the redistribution is
applying the
metrics. For EIGRP, you must apply the metrics either as a
default in the
routing process or on the redistribute command line. You cannot
solely do
this within the metric. Here is an example of a route-map for
redistribution
that I have used:
router eigrp 1
redistribute ospf 1 route-map Ospf2Eigrp metric 100000 1 255 1
1500
!
router ospf 1
redistribute eigrp 1 route-map Eigrp2Ospf metric 10 metric-type
1
!
route-map Eigrp2Ospf deny 10
match tag 110
!
route-map Eigrp2Ospf permit 20
set tag 90
!
route-map Ospf2Eigrp deny 10
match tag 90
!
route-map Ospf2Eigrp permit 20
set tag 110
I am interested in any other great ways to accomplish this. You
can't know
enough of the ways to do things.
Dave
-----Original Message-----
From: nobody@groupstudy.com
To: Cisco Nuts
Cc: ccielab@groupstudy.com
Sent: 11/5/2005 10:13 AM
Subject: Re: Rip <--->Ospf Redistribution - using
distribute-lists?
Both using distance and or distribute lists is a valid way
of stopping the loops. The advantage of the distance way
where possible is you do not have to maintain ACLs so
as new routes get advertised you do not have to update
the ACL's.
It is not always possible to use distance on its own.
Regards
Kevin
On 11/5/05, Cisco Nuts wrote:
> Hello: Is distribute-lists a good idea to use when doing 2-way
> redistribution b/w Rip and Ospf or for that matter b/w any 2
IGP's in
> general? I have been reading a very good example of this on
CCO but
did
> not run into this kind of solution (if I recall correctly)
when doing
the
> InetExp Labs. Even a sample lab from DoIt uses the distance
109 for
RIP.
> Permitting all RIP routes into Ospf via the distribute-list
out rip
under
> Ospf while denying all RIP routes in via the distribute-list
out ospf
> under Rip seems to nail it down. Any thoughts on this?
Thanks!!
>
>
This archive was generated by hypermail 2.1.4 : Thu Dec 01 2005 - 09:12:05 GMT-3