From: Chris Lewis (chrlewiscsco@yahoo.com)
Date: Mon Nov 07 2005 - 12:25:37 GMT-3
In this case ACLs might not help either, as all routers in OSPF domain will have the same LSA database. If you just manipulate distance as the NMC note shows, there is not need for ACLs or tags.
If this is not clear, lab it up, then change out EIGRP for OSPF and see that you do get equal cost paths to 4.4.4.4, then try to make OSPF behave the same way with the distance ospf external command.
Chris
"Schulz, Dave" <DSchulz@dpsciences.com> wrote:
v\:* {behavior:url(#default#VML);}o\:* {behavior:url(#default#VML);}w\:* {behavior:url(#default#VML);}.shape {behavior:url(#default#VML);}
Thanks, Chris. So, would you suggest to redistribute (in this case) based specifically on the routes (using ACLs) and use the distance command to prefer a specific route/direction?
Dave Schulz,
Email: dschulz@dpsciences.com
---------------------------------
From: Chris Lewis [mailto:chrlewiscsco@yahoo.com]
Sent: Monday, November 07, 2005 8:57 AM
To: Schulz, Dave; kevin gannon; nobody@groupstudy.com; Cisco Nuts
Cc: ccielab@groupstudy.com
Subject: RE: Rip <--->Ospf Redistribution - using distribute-lists?
Tags in either direction would not do the trick, or at least they would not solve the problem I am describing. For a full description see
http://www.netmasterclass.com/site/member.php?&category=demo&togo=category=Lib
Click on public files then download the PDF "A scenario with multiple redistribution points"
The short answer is this.
R2 and R3 both learn 4.4.4.4 via RIP and send it in to OSPF via redistribution on both routers. All teh taggin you show does is stop that route from being fed back in to RIP. This does not allow R1 to see equal cost routes to 4.4.4.4.
The reason is that either R2 or R3 (depending on timing) will become the ASBR for this route and R1 will only end up seeing one route to 4.4.4.4
The simplest way to solve this is via distance.
The reason I point this out is that the tagging method shown solves a particular issue, not all issues in redistribution and I do not believe anyone should use the tag method as a default cure-all method to resolve mutual redistribution issues.
Chris
"Schulz, Dave" <DSchulz@dpsciences.com> wrote:
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
________________________________
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" 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