- A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: Redistribution - Slattery/Burton more questions..? posted 01/18/2001
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]

See Inline.......

----- Original Message -----
From: Chuck Larrieu <chuck@xxxxxxxxxxxxx>
To: Nigel Taylor <nigel_taylor@xxxxxxxxxxx>; <ccielab@xxxxxxxxxxxxxx>;
Cc: <Bryant_Andrews@xxxxxxxxxxx>
Sent: Wednesday, January 17, 2001 9:50 PM
Subject: RE: Redistribution - Slattery/Burton more questions..?

> First edition, correct?
> There is a website,
> where ostensibly there are bug reports listed. I don't find yours in
> particular - most of them appear to be cosmetic things such as typeface
> missing lines.

NT: Thanks for the link.....!

> In looking over the configurations in the second edition, and the first, I
> am wondering about the distribute list behaviour
> Recall that the access-list reads "permit" What I
> wondering is if, because that list permits a very broad network range, if
> the time of redistribution Cisco creates this null route. Recall that you
> have the redistribution happening with the "subnets" switch. The OSPF
> process sees 162.16.a.a, 162.16.b.b, and knows that anything in the
> 162.16.forever range is permitted.
> Therefore it creates the null route in case any traffic shows up for
> other than those which are coming in.
> I wonder, Nigel, if you have a moment to test this:
> Access-list 1 permit
> Access-list 1 permit
> Access-list 1 deny any

NT: Chuck I was able to try this with no luck the OSPF summary route was
still imported into the routing table of the Tokyo router and replaced the
external eigrp route to network  The only way I got the tokyo
route to keep the eigrp external route in it's RIB was by applying a filter
to the ospf process denying trhe specific ""

In looking at this, although the summary route will most likely not ever get
used(because of a possible longer match) in the RIB of the tokyo router, the
external eigrp router as shown in tokyo's RIB(pg. 330) would use sub-optimal
routing in directing traffic through the eigrp domain to get to the OSPF
domain.  So with the OSPF route I'm recieving it would correct this problem
and forward traffic directly into the OSPF routing domain.
> i.e. redistribute the specific subnets that are configured on Tokyo
> interfaces, and see what happens.

NT: I looked into this and I'm excited to say that the use of varied metrics
in the tokyo router compared to the redistribution of the same eigrp routes
in the london router made identifying which process I was observing
redistribution from within the OSPF AS so much easier.

> Another variation might be doing the redistribute without the subnets
> switch.  I'll see if I can take a look a little later. I have some other
> labs to finish up first.

NT: I observed no changes with or without the subnets. In this example all
the eigrp routes are on a classful boundary so this would be expected. I
figured since there is another ASBR(london) providing the exact same
functions as the tokyo router with the exception of passing the route(s) for
the RIP domain/network.

This excercise really shows me the importance of documenting you network as
to determine key point like;
-  Specific metrics to use when doing multiple redistribution
-  Indentifying specific paths within the topology that would ensure optimal
rouitng once the protocol(s) are all implemented.
- Although the tokyo router had a single (stub)network redistribution from
the external routing domains was still done.  I didn't do this initially
when attacking this lab. Is this assumed with redistribution.....? NOTE: I
didn't say mutual redistribution.
Or is this some that would be pointed out as a task/requirement in a typical
-And still there is the original question in reference to eigrp and

Using the "ip summary-address eigrp <process-id> <summarized net & mask>" at
the major network boundary. Or through mutal redistribution of summarized

My intent is to mock up ex.#10 again and see what happens using doing as was
done in ex. #11.


> Chuck
> -----Original Message-----
> From: Nigel Taylor [mailto:nigel_taylor@xxxxxxxxxxx]
> Sent: Thursday, January 18, 2001 1:49 AM
> To: ccielab@xxxxxxxxxxxxxx; cisco@xxxxxxxxxxxxxx; chuck@xxxxxxxxxxxxx
> Cc: Bryant_Andrews@xxxxxxxxxxx
> Subject: Redistribution - Slattery/Burton more questions..?
> All,
>    I'm still working through the Slattery/Burton ex. #11, pg. 328-338 and
> I'm still trying to get a fix on some of the things I'm seeing.  My fist
> concern was with the summary route that is shown in the London router for
> 333).  In looking at the London configs I see no summary
> route defined under the ospf 200 process that would create the above
> mentioned summary route in the routing table.  I figured this was either a
> mis-print or a lack thereof which is fine.
> However, when you look at the routing table of the Tokyo router(pg. 330)
> there is a eigrp external to the network.  With the existing
> configuration I do get this route as noted but once the OSPF adjacency
> between london and tokyo achieves the full state the OSPF summary for the
> replaces the eigrp external route in Tokyo because of the
> lower AD of OSPF(as it should).
> My other thoughts also goto the different techniques used to pass the
> summarized routes to external routing domains.  In ex. #10 the example
> use of the interface specific command;
> "ip summary-address eigrp <process-id> <summarized network & mask>
> to summarize the OSPF network into the EIGRP routing domain, but in ex.#11
> it was done through the use of a redistributed summary route.
> I just wanted to know if there are any clear guildlines in use when
> summarized routes are proprogated into external routing domains....
> Nigel...
> _________________________________________________________________
> Get your FREE download of MSN Explorer at
> _________________________________
> FAQ, list archives, and subscription info:
> Report misconduct and Nondisclosure violations to abuse@xxxxxxxxxxxxxx

To unsubscribe from the CCIELAB list, send a message to
majordomo@xxxxxxxxxxxxxx with the body containing:
unsubscribe ccielab