The first problem that you encountered was due the fact of the network type
mismatch - different network types uses different timers.
For point-multipoint and non-broadcast:
Hello 30, Dead 120, Wait 120
For point-point:
Hello 10, Dead 40, Wait 40
So if you have differnt configuration at either end of the link, then there
will be no adjaceny formed between the two neighbours and as a result there
will be no routing info/LSA's transfered between then.
I would suggest that for this setup you should use the ospf network type "point
to mulitpoint", this way each connected is treated and a single point to point
network. This way you also rule and problems with DR election if using
broadcast (in this setuo you would need to make sure the hub was the DR to
ensure that the routing worked properly).
For some more info and a some sample configs have a look at the following link:
http://www.cisco.com/warp/public/104/22.html
Rich
On Jan 29, 1:58am, Bill Moran wrote:
> Subject: RE: Frame Relay - Lessons Learned...
> 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]
>-- End of excerpt from Bill Moran
--
*** Please copy your emails to [EMAIL PROTECTED] ***
#-----------------------------------------------------------------------#
# .. .. | Richard Gallagher | Office:+32 2 704 5000 #
# || || | Euro-CATS | Direct:+32 2 704 5421 #
# || || | Cisco Systems Belgium | Fax: +32 2 704 6000 #
# |||| |||| | Pegasus Park | email: [EMAIL PROTECTED] #
#.:||||||:.:||||||:.| De Kleetlaan, 6A | #
# Cisco Systems | BE 1831 Diegem | http://www.cisco.com/tac #
#-----------------------------------------------------------------------#
"Normal people believe that if it ain't broke, don't fix it. Engineers
believe that if it ain't broke, it doesn't have enough features yet."
Check out this link: http://www.cisco.com/warp/customer/63/
_________________________________
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
