From: Chuck Larrieu (chuck@xxxxxxxxxxxxx)
Date: Wed Dec 27 2000 - 13:53:21 GMT-3
Spot the issues.....
No sub-interfaces
Sub-interface point-to-point
Sub-interface multipoint
( and what can be mix-and-matched? Where? )
With no frame-relay map commands, what are your options in each situation?
As important, what are the issues ( the "pitfalls" if you will ) with each?
( with regards to routing protocol behaviour )
Chuck
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Ronnie Royston
Sent: Wednesday, December 27, 2000 8: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