From: CCIEin2006 (ciscocciein2006@gmail.com)
Date: Mon Apr 17 2006 - 16:10:19 GMT-3
Perfect - thanks!
Probably the issue I experienced was trying to connect a DR supported
network type to a non-DR supported network type.
Thanks all for your input!
On 4/17/06, Brian McGahan <bmcgahan@internetworkexpert.com> wrote:
>
> As long as the network types are compatible it will be fine. The
> compatibility is based on the DR/BDR election, which results in the
> following successful combinations:
>
> DR/BDR Support
> Broadcast - broadcast
> Non-broadcast - non-broadcast
> Broadcast - non-broadcast
>
> No DR/BDR Support
> Point-to-point - point-to-point
> Point-to-multipoint - point-to-multipoint
> Point-to-multipoint non-broadcast - point-to-multipoint non-broadcast
> Point-to-point - point-to-multipoint
> Point-to-point - point-to-multipoint non-broadcast
> Point-to-multipoint - point-to-multipoint non-broadcast
>
> Other factors still need to match for adjacency to occur however,
> such as area, stub flags, authentication, mtu, timers, unique router-ids,
> etc.
>
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
> 24/7 Support: http://forum.internetworkexpert.com
> Live Chat: http://www.internetworkexpert.com/chat/
>
> ________________________________________
> From: CCIEin2006 [mailto:ciscocciein2006@gmail.com]
> Sent: Monday, April 17, 2006 1:30 PM
> To: Plank, Jason
> Cc: Brian McGahan; ccielab@groupstudy.com
> Subject: Re: IE LAB 17 task 4.1 - for the Brians please
>
> You can match the timers to force adjacency but from my experience no
> routes will be learned.If you look at the OPSF database it will show "Adv
> router is not-reachable." Therefore while the connection might look like
its
> up in fact you are not learning any routes.
>
> Brian can you confirm or negate this statement?
>
>
> On 4/17/06, Plank, Jason <JPlank@concordefs.com> wrote:
> You can have the network types mismatch, but the TIMERS have to match.
>
> -------------------
> Jason Plank
> Network Engineer
> 101 Bellevue Parkway
> Wilmington, DE 19809
> E-mail: JPlank@concordefs.com
> Phone: 302-793-5913
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> CCIEin2006
> Sent: Monday, April 17, 2006 2:01 PM
> To: Brian McGahan
> Cc: ccielab@groupstudy.com
> Subject: Re: IE LAB 17 task 4.1 - for the Brians please
>
> Cool - but won't that result in OSPF network type mismatch? Isn't that a
> bad
> thing?
>
> On 4/17/06, Brian McGahan < bmcgahan@internetworkexpert.com> wrote:
> >
> >Okay so the spokes are using the main interface in Frame Relay
> > which results in the OSPF network type of non-broadcast.R5 has a
> > multipoint subinterface.Restrictions are don't use the neighbor
> statement
> > and don't use any interface commands on R1 and R2.This means that R1 and
> > R2 will stay non-broadcast with the default timers.So to solve this set
> > the OSPF network type to broadcast on R5's interface and match the
> timers
> > with R1 and R2's non-broadcast.
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> > ________________________________________
> > From: CCIEin2006 [mailto: ciscocciein2006@gmail.com]
> > Sent: Monday, April 17, 2006 9:07 AM
> > To: Brian McGahan
> > Cc: ccielab@groupstudy.com
> > Subject: Re: IE LAB 17 task 4.1 - for the Brians please
> >
> > Yes but theworkbook specifically states do not use neighbor
> > statements.Itdid not say do notuse neighbor statements on the spokes
> which
> > would haveled me to believe that itwas okay to use on the hub. Do you
> see
> > what I mean?
> >
> >
> > On 4/15/06, Brian McGahan <bmcgahan@internetworkexpert.com > wrote:
> > It doesn't require neighbor statements on the spokes but it does on the
> > hub.
> >
> > HTH,
> >
> > Brian McGahan, CCIE #8593
> > bmcgahan@internetworkexpert.com
> >
> > Internetwork Expert, Inc.
> > http://www.InternetworkExpert.com
> > Toll Free: 877-224-8987 x 705
> > Outside US: 775-826-4344 x 705
> > 24/7 Support: http://forum.internetworkexpert.com
> > Live Chat: http://www.internetworkexpert.com/chat/
> >
> >
> > > -----Original Message-----
> > > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> > Of
> > > CCIEin2006
> > > Sent: Saturday, April 15, 2006 12:37 PM
> > > To: ccielab@groupstudy.com
> > > Subject: IE LAB 17 task 4.1 - for the Brians please
> > >
> > > This question is for Brian Dennis or Brian McGahan but anyone else can
> > > feel
> > > free to chime in.
> > >
> > > Regarding IE version 3 Volume 1, Lab 17, task 4.1 :
> > >
> > > The task states to configure OSPF between R1, R2, and R5 which are
> > > connected
> > > by a multipoint frame relay network with R5 as the hub.
> > >
> > > The task states to NOT use the neighbor command to accomplish this and
> > it
> > > also states not to use any interface level commands on R1 or R2 (which
> > > rules
> > > out changing the ospf network type on these routers).
> > >
> > > Your solution states to use ospf network type non-broadcast and does
> > not
> > > include any neighbor statements.
> > >
> > > Aren't you required to use neighbor statements when configuring
> > > non-broadcast?
> > >
> > > I tried your solution but adjacency is not being established across
> > the
> > > frame relay network.
> > > What is the correct solution?
> > >
> > > Thanks in advance!
> > >
> > >
> > _______________________________________________________________________
> > > 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
>
> -----------------------------------------
> The information in this message may be proprietary and/or
> confidential, and protected from disclosure.If the reader of this
> message is not the intended recipient, or an employee or agent
> responsible for delivering this message to the intended recipient,
> you are hereby notified that any dissemination, distribution or
> copying of this communication is strictly prohibited. If you have
> received this communication in error, please notify First Data
> immediately by replying to this message and deleting it from your
> computer.
This archive was generated by hypermail 2.1.4 : Mon May 01 2006 - 11:41:57 GMT-3