From: Nigel Taylor (nigel_taylor@xxxxxxxxxxx)
Date: Thu Jan 18 2001 - 09:27:44 GMT-3
See Inline.......
----- Original Message -----
From: Chuck Larrieu <chuck@cl.cncdsl.com>
To: Nigel Taylor <nigel_taylor@hotmail.com>; <ccielab@groupstudy.com>;
<cisco@groupstudy.com>
Cc: <Bryant_Andrews@hotmail.com>
Sent: Wednesday, January 17, 2001 9:50 PM
Subject: RE: Redistribution - Slattery/Burton more questions..?
> First edition, correct?
>
> There is a website,
http://www.netcordia.com/advip-first-edition/bugs1.html
> 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
and
> 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 162.16.0.0 0.0.255.255" What I
am
> wondering is if, because that list permits a very broad network range, if
at
> 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
subnets
> other than those which are coming in.
>
> I wonder, Nigel, if you have a moment to test this:
>
> Access-list 1 permit 162.16.1.192 0.0.0.3
> Access-list 1 permit 162.16.1.32 0.0.0.31
> 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 162.16.0.0/16. 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 "162.16.0.0 0.0.0.0"
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
scanerio.
-And still there is the original question in reference to eigrp and
summarization...
Using the "ip summary-address eigrp <process-id> <summarized net & mask>" at
the major network boundary. Or through mutal redistribution of summarized
routes...
My intent is to mock up ex.#10 again and see what happens using doing as was
done in ex. #11.
Nigel..
>
> Chuck
>
> -----Original Message-----
> From: Nigel Taylor [mailto:nigel_taylor@hotmail.com]
> Sent: Thursday, January 18, 2001 1:49 AM
> To: ccielab@groupstudy.com; cisco@groupstudy.com; chuck@cl.cncdsl.com
> Cc: Bryant_Andrews@hotmail.com
> 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
> 162.16.0.0/16(pg. 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 162.16.0.0/16 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
> 162.16.0.0/16 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
made
> 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....
>
>
> TIA
> Nigel...
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:27:34 GMT-3