From: Stull, Cory (cory@xxxxxxx)
Date: Wed Dec 27 2000 - 18:37:56 GMT-3
They might be referring to route-map where you use the route-map to set the
next hop on each remote site router to the central site router. So that in
order for one remote router to talk to another remote router the route-map
tells the router it needs to communicate through the central router... this
would be similar to using a frame-relay map ip statment at the remote sites
but would be an alternative. I have seen this done in a practice lab...
Good studying
Cory
-----Original Message-----
From: Ronnie Royston [mailto:RonnieR@globaldatasys.com]
Sent: Wednesday, December 27, 2000 10:20 AM
To: 'Nigel Taylor'; CCIE_Lab Group Study; Cisco Group Study
Cc: Bryant Andrews
Subject: RE: Frame Relay - Lessons Learned...
Can someone please clarify something. When you are asked to set up frame
and not use frame mapping, I was thinking to let inverse arp do it for you
on that particular router if you need that router to be multipoint,
otherwise point-to-point is the answer. Is that what they are looking for?
-----Original Message-----
From: Nigel Taylor [mailto:nigel_taylor@hotmail.com]
Sent: Monday, December 25, 2000 9:21 AM
To: CCIE_Lab Group Study; Cisco Group Study
Cc: Bryant Andrews
Subject: Frame Relay - Lessons Learned...
Well, =20
I hope buy now everyone has opened all their gifts and already =
know what it is they want for christmas next year.
In joy of the spirit I decided to work on some areas which I believe as =
mentioned by numerous member on list is of crucial importance in CCIE =
lab. In this spirit I've learned another lesson, which goes as =
follows...
In this lab scenario the goal was to connect 3 routers R1, R2, and R3 in =
the typical HUB and Spoke topology. In a partial=20
mesh all routers should be able to ping each other with out the use of =
the "frame-relay map" command with only sub-interfaces allowed in the =
HUB device.
Now, this is reasonably easy as this leaves 2 options to complete the =
required task. Configurations as follows=20
could get this done. The use of various sub-interfaces with the =
"frame-relay interface-dlci" command depending=20
on other lab specific requirements(i.e multiple nets/subnets) or the use =
of a multi-point sub-interface to support both=20
spoke(s) over one network address assignment. =20
I used 2 sub- interfaces to specify 2 networks. What I observed was, =
although I had a neighbor adjacency between
both spokes and the HUB(R1), the spokes was not learning the other =
network through OSPF. I could ping the=20
HUB(R1) from both spokes, but could not ping through to R3(spoke) and =
vise-versa. I know.. no ospf what do you expect..! =20
Another observation was from the Spoke devices R2 and R3 the HUB(R1) =
showed up as a BDR in full state.=20
As well from the HUB the both spokes(R2,R3) showed up as adjacent =
neighbors in FULL state. =20
Closer investigation showed that from the HUB both sub-interfaces were =
using ospf network type point-to -point, however=20
from the spokes(R2,R3) being physical interfaces and using the default =
of broadcast. Well, this really doesn't stand
as both of these network types use a 10 sec Hello timer and a 40 sec =
Dead timer.. right!
Wrong, apparently although the ospf network types hello/dead values =
matched this did not allow ospf to propagate the other networks to the =
spokes. What solved this was either changing the spokes ospf network =
type to p-t-p as to match the HUB, or=20
changing the HUB links to broadcast. When this was done the spokes both =
now knew of the other net work. =20
In doing some quick research Calsow's book makes mention of setting all =
interfaces to point-to-multipoint. He also=20
mentions the problems faced with ospf network type mis-matches. If one =
is not careful this could present a few problems and being not overly =
confident in my frame-relay skill-set would likely look to something in =
that part of the config for the answer to
my problem....
Thoughts anyone...or is this common knowledge....?
Nigel.
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 08:26:11 GMT-3