From: Narbik Kocharians (narbikk@gmail.com)
Date: Tue Nov 06 2007 - 01:50:25 ART
Ajay,
Read the entire post, after the routers go into full state you will create a
GRE. But this is IF you are asked NOT to configure priority, which to me is
pretty crazy.
On 11/5/07, Ajay Prakash <ajay.prakash@networkpeople.co.in> wrote:
>
> Are the Broadcast and P2P network types compatible with each other? As per
> my understanding, even if you match the timers, the adjacency would come
> up,
> but the routes would not be exchanged. Will try to lab it up and see.
>
> As I know it P2P is compatible with P2P and P2Multipoint (No DR/BDR)
> Broadcast is compatible with Broadcast and Non Broadcast (Required a
> DR/BDR)
>
> Please let me know if I am missing on something here.
>
> Ajay
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Narbik Kocharians
> Sent: Tuesday, November 06, 2007 4:58 AM
> To: Eric Phillips
> Cc: Mark Mahan; ccielab@groupstudy.com
> Subject: Re: Any way to force OSPF DR other than "priority 0"?
>
> Can we set the network type of the spokes to P2P and the hub site to
> Broadcast. Next we have to set the timers to match, that way the
> routers will go into full state but they won't exchange any routes,
> then you would configure a GRE tunnel to resolve the networks. This
> way the hub will always be the DR.
> That's if i am reading the requirements correctly.
>
>
> On 11/5/07, Eric Phillips <ephillips@squick.cc> wrote:
> >
> > Very interesting solution Mark!
> >
> > I quickly labbed up a slightly similar situation, where R1 is the
> > preferred
> > DR, and R2 and R3 are on the same broadcast domain.
> >
> > I set the priority high on R1, and created an access list on R2 blocking
> > traffic from R3, and an ACL on R3 blocking traffic from R2. What is
> > astounding is R1 became the DR, and both R2 and R3 throught they were
> the
> > BDR, and R1 was the DR. R1 thought R3 was the BDR, and R2 was the
> > DROTHER.
> >
> > In this strange mismatched case, routing still worked! Routes were
> > passed,
> > a "debug ip ospf events" did not show any errors or anything odd.
> >
> > Then, even stranger, I cycled the OSPF process on R1, and now both R2
> and
> > R3
> > thought THEY were the DR; and R1 picked R3 to be the DR. And still
> > routing
> > worked and debugs showed no error messages.
> >
> > So this didn't get what I wanted, but a very interesting find; I would
> > have
> > thought routers had to agree who was the DR/BDR.
> >
> > I will have to play with private VLANs a bit for sure, I didn't think
> > about
> > those at all.
> >
> > Thanks again!
> >
> > -Eric
> >
> >
> > On 11/5/07, Mark Mahan <mmahan@caprock.com> wrote:
> > >
> > > I haven't set my home lab up for remote access yet so can't verify my
> > > supposition. Since I'm supposing...
> > >
> > > If they are all connected to a switch, block direct multicast
> > > communication between R2 and R3 using private VLANs and use local
> > > proxy-arp at R1 for unicast communication between R2 and R3. OSPF
> > > neighbor relationships will form between 1 and 2 and 1 and 3 and with
> > > 1's priority set high then it will be the DR and if it dies then OSPF
> > > dies but you are assured R1 being the DR when it comes back up. Be
> > > great is node 1 was a routing switch and the other two were routers...
> > >
> > > I don't know if the DR would react to the R2 or R3 hello not showing
> the
> > > other in the neighbor list.
> > >
> > >
> > >
> > >
> > >
> > > Mark Mahan
> > > Network Engineer
> > > -------------------------------
> > > CapRock Communications
> > > 4400 S. Sam Houston Parkway E.
> > > Houston, Texas 77048
> > > Office: 832 668 2528
> > > mmahan@caprock.com
> > > www.caprock.com
> > >
> > >
> >
> --------------------------------------------------------------------------
> > > NOTICE OF CONFIDENTIALITY: This e-mail message may contain
> confidential
> > > information and is intended only for the person(s) named above. Any
> > review,
> > > use, disclosure or distribution by any other person is prohibited. If
> > you
> > > are not the intended recipient, please contact the sender by e-mail
> and
> > > destroy all copies of this message.
> > > -----Original Message-----
> > >
> > >
> > > From: Mark Mahan
> > > Sent: Monday, November 05, 2007 12:07 PM
> > > To: Eric Phillips; ccielab@groupstudy.com
> > > Subject: RE: Any way to force OSPF DR other than "priority 0"?
> > >
> > > If there is no restriction on setting network types, then what about
> > > making the interfaces on the segment non-broadcast and setting the
> > > neighbors' priorities to 0 with the neighbor command on the DR?
> > >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > > Eric Phillips
> > > Sent: Monday, November 05, 2007 11:05 AM
> > > To: ccielab@groupstudy.com
> > > Subject: Any way to force OSPF DR other than "priority 0"?
> > >
> > > Hey all,
> > >
> > > I have done quite a bit of Googling and DOC-CD reading, and have not
> > > found
> > > anyone offering any clever ways to force the election of a certain
> > > router as
> > > the DR besides setting the priority to 0 on all other routers.
> > >
> > > For example, if I had a question that asked me to ensure Router1 was
> > > always
> > > the DR on a certain segment without touching the configuration of
> > > Router2
> > > and Router3 I can set the priority very high on Router1, but if
> Router1
> > > boots a few seconds later than Router2, Router2 will be the DR even if
> > > it
> > > has it's default priority of 1. The only way I can think to
> completely
> > > guarantee Router1 is always the DR is to make the priority 0 on all
> > > other
> > > routers.
> > >
> > > Am I missing something obvious, or am I over thinking this too
> much? I
> > > have
> > > not seen this asked in any practice labs, just theorizing what could
> > > happen.
> > >
> > > -Eric
> > >
> > >
> _______________________________________________________________________
> > > Subscription information may be found at:
> > > http://www.groupstudy.com/list/CCIELab.html
> >
> > _______________________________________________________________________
> > Subscription information may be found at:
> > http://www.groupstudy.com/list/CCIELab.html
> >
>
>
>
> --
> Narbik Kocharians
> CCIE# 12410 (R&S, SP, Security)
> CCSI# 30832
> www.Net-WorkBooks.com
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
>
-- Narbik Kocharians CCIE# 12410 (R&S, SP, Security) CCSI# 30832 www.Net-WorkBooks.com
This archive was generated by hypermail 2.1.4 : Sat Dec 01 2007 - 06:37:28 ART