From: Daniel C. Young (danyoung99@xxxxxxxxxxxx)
Date: Fri Apr 06 2001 - 03:12:04 GMT-3
Murphy,
Lab1 drove me bananas too, at first. You introduced some good points.
However, I believe that you're talking about "policy routing" as opposed to
"route-maps". Sure, policy routing applies route-maps, but the point of the
lab is that routing behavior can be "engineered" using local policies.
Mapping is still important. You'll notice that all spoke routers have
mappings to the hub router. Beyond that, however, communication between
spoke router themselves without mapping statements requires either policy
routing or, as you'll discover in subsequent labs, layer 3 solutions.
Hope that clarifies things a bit.
Daniel Young
Sr. Network Engineer
Internet Data Center
SBC Service Inc. - ITO
(949) 221-1928 Office
(714) 350-8945 Cell
ICQ# 109846891
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On Behalf Of
Murphy, Brennan
Sent: Thursday, April 05, 2001 2:59 PM
To: 'ccielab@groupstudy.com'
Cc: Murphy, Brennan
Subject: ccbootcamp Lab 1--lessons learned?
I had never worked with route maps before, so lab 1 drove me somewhat crazy.
At the end, I felt like I had definitely learned a lesson. I wanted to see
if
I learned what I should have learned by attempting a summary...and
seeing if others agree/disagree.
Disclaimer:
Don't read this if you want to approach lab 1 with nothing more than your
existing experience. But do read it if you are wondering if the issues
explored in
the ccbootcamp labs are worth plucking down the $$$.
Proposed summary:
On a hub-and-spoke Frame topology, OSPF can get confused when
your FR interfaces are all on the same subnet. The layer 2 structure
prevents the layer 3 structure from working as OSPF might have expected
it to. Thus, you get next hop routes for which there is no layer 2 mapping.
The idea might be to solve this with generic ip ospf network type statements
or FR map statements....but the lab requirements prohibit this. Thus, the
only other Cisco way of doing things is to employ Route Maps, which
over-ride what the route table is indicating the next hops are. You make
the hub
the next hop for all the routes that have incorrect next hops.
There are other minor excercises: virtual links, Designated Router, and
summarization.
...terminal server/frame relay switch as well.
Am I missing anything important or lacking in interesting detail?
I wasn't too enthused about the irrelevant config statements found in the
solutions
files....but I guess I can live with it....since there is an errata page on
ccbootcamp.com.
Thanks.....appreciate any pointers.
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:29:41 GMT-3