From: Sean C. (Upp_and_Upp@hotmail.com)
Date: Sun Oct 08 2006 - 23:22:55 ART
I agree with Ghias.
Further, (and this is totally my guess) if you did needlessly configure
neighbors on the spokes, whoever or whatever grades the lab 'may' not score
you the points for that section. They may feel that since you applied
neighbors where they weren't needed, that you didn't know the technology or
underlying solution. Again, just my guess. Kind of like applying ospf
demand-circuit on both sides of a connection - again, not needed.
Also, maybe it's just because I'm gearing up for the lab (and am in the
'what's the underlying gotcha here'), but my first instinct when reading
your situation was to wonder what was the interface types - i.e. physical or
subints. You 'assumed' (or, more specifically made me assume), the topology
was physical interfaces. If the topology connecting the three weren't
physical ints, it's a different story.... I'm sure you knew that (and your
one comment about 'default NONBROADCAST' validated that), it's more my
current mindset of looking for all the little areas that raise a red-flag.
Now, on the flip side, and again, this is only my thinking, concerning the
dr/bdr, not only would I place priority 0 on the spokes, but I'd place
priority 255 on R1. It can easily be argued that maybe I'm overconfiging
(but I've seen reputable vendor labs where this is the configured solution).
So, applying the logic from my 1st paragraph, maybe I wouldn't score any
points for that task because maybe who or whatever graded my lab thought I
didn't show the appropriate skills. I can see Mr. Scott Morris (rightly)
jumping on my back because I, once again, overconfigured.
Right now, I have that old Ratt song playing in my head 'Round and Round'.
HTH (not sure if it helped me) ;-),
Sean
----- Original Message -----
From: "Alex De Gruiter (AU)" <Alex.deGruiter@didata.com.au>
To: "ghias hassan" <ghias.hassan@gmail.com>
Cc: <ccielab@groupstudy.com>
Sent: Sunday, October 08, 2006 3:48 PM
Subject: RE: OSPF neighborship on FR hub&spoke
Great, thanks.
-----Original Message-----
From: ghias hassan [mailto:ghias.hassan@gmail.com]
Sent: Monday, 9 October 2006 8:47 AM
To: Alex De Gruiter (AU)
Subject: Re: OSPF neighborship on FR hub&spoke
both the anwers are no.
its not recommended by cisco and u when u have already given neighbor at
hub and due to that command hub will send hellos as unicast ..spoke will
convert too for unicast
y would u need to configrue b/w spokes....routers only need to make
adjacency with DR...any spoke cant be ever DR or BDR
regards,
ghias.
On 10/9/06, Alex De Gruiter (AU) <Alex.deGruiter@didata.com.au> wrote:
> Hey Guys,
>
> I have a question about OSPF neighborship requirements in an OSPF
> non-broadcast topology.
>
> Lets say you have a hub & spoke frame relay topology, with R2 and R3
> the spokes from R1. If you are not allowed to change the OSPF network
> type, then you will need to use the default NONBROADCAST, and specify
> a neighbor relationship from R1 to the spokes.
>
> My understanding is that in this situation, we should set the OSPF
> priority on the spokes to 0, so that they can not become DR or BDR,
> and neighbor commands are required from R1. i.e.
>
> *=*=*=*=*=*=*=*=**=*=*=*=*=*=*=*=*
>
> R2/R3
>
> int serial0/0
> ip ospf priority 0
>
> R1
>
> router ospf 123
> neighbor 192.168.1.2
> neighbor 192.168.1.3
>
> *=*=*=*=*=*=*=*=**=*=*=*=*=*=*=*=*
>
> However, I have 2 questions:
>
> 1. Although not required (because they will have no impact on the
> formation of neighborships), should we also specify neighbors on the
> spoke routers? Would Cisco expect us to do this, or would the
> configuration on the hub suffice?
> 2. Should we also configure neighbor relationships between the spokes?
>
> Alex
>
> **********************************************************************
> ********
> - NOTICE FROM DIMENSION DATA AUSTRALIA This message is confidential,
> and may contain proprietary or legally privileged information. If you
have received this email in error, please notify the sender and delete
it immediately.
>
> Internet communications are not secure. You should scan this message
and any attachments for viruses. Under no circumstances do we accept
liability for any loss or damage which may result from your receipt of
this message or any attachments.
> **********************************************************************
> ********
>
> ______________________________________________________________________
> _ Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Nov 01 2006 - 07:29:04 ART