I too discovered this last night. I believe that part of the problem may be
in the absence of frame map statements, more specifically the lack of the
broadcast parameter, the LSAs are not getting propagated to the neighbors.
Any thoughts to this theory?
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Nigel Taylor
Sent: Monday, December 25, 2000 11: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.
_______________________________________________________
To unsubscribe from the CCIELAB list, send a message to
[EMAIL PROTECTED] with the body containing:
unsubscribe ccielab
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
