RE: generic redistribution question

From: Rik Guyler (rik@guyler.net)
Date: Tue Apr 27 2004 - 20:40:29 GMT-3


If you can do this without killing too much time then I think it
simplifies things in the long run, especially when troubleshooting. I
too have been "bitten" with redistribution issues.

As for "over configuration", I don't think that's possible. The latest
edition of Packet Magazine had an interview with one of the Telephony
lab proctors and he stated specifically that the lab is graded on the
end result and not configuration. I think it's a resonable assumption
to say that these grading guidelines apply to all of the various labs.

Rik

-----Original Message-----
From: Edwards, Andrew M [mailto:andrew.m.edwards@boeing.com]
Sent: Tuesday, April 27, 2004 4:20 PM
To: ccielab@groupstudy.com
Subject: Re: generic redistribution question

All,

In the lab examples I've done so far I think I'm reading too much into
redistribution such that I might actually loose points because of "over
configuration". Looking for some feedback on this...

For example,

Single router is the border router for an OSPF and EIGRP routing domain.
Requirement is to redistribute OSPF to EIGRP such that all routes are
visible on all routers.

The approach I generally take and make brain not swirl too much is to
build route-maps such that I tag redistributed routes from one routing
domain into another, and then deny those tagged routes on the
redistribution to the original routing domain.

More specifically,

1. OSPF to EIGRP with a tag of 222. EIGRP to OSPF deny tag 222. 2.
EIGRP to OSPF with a tag of 333. OSPF to EIGRP deny tag 333

Makes sense to me, but from an "over configuration" standpoint, would it
be more correct to just simply redistribute the routes and then let AD
work on my behalf where applicable?

This all stems from my attempt to build a model for redistribution...
cause sometimes the redistribution gets a little too much to keep track
of in my opinion.

Andy



This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 19:48:57 GMT-3