From: Godswill Oletu (oletu@inbox.lv)
Date: Sun Jul 02 2006 - 12:23:58 ART
Sami,
A little clarity on the section "P2MP-Nonbroadcast Interfaces Advantages:"
from my last post as:
I meant to say:
*The use of unicast means, neighbor statements are needed.
and not:
*The use of multicast means, neighbor statements are needed.
HTH
Godswill
P2MP-Nonbroadcast Interfaces Advantages:
* Generate /32 host routes for your spokes (this was taken from P2MP
interface type).
*Uses unicast instead of multicast Hellos (this was taken from the
nonbroadcast interface type->with neighbor commands).
*The use of unicast means, neighbor statements are needed. (taken from
nonbroadcast interface type)
*No need for DR/BDR elections (taken from P2MP interface types).
HTH
Godswill Oletu
CCIE #16464
----- Original Message -----
From: "Godswill Oletu" <oletu@inbox.lv>
To: "Sami" <sy1977@gmail.com>; "Victor Cappuccio"
<cvictor@protokolgroup.com>
Cc: "ccielab" <ccielab@groupstudy.com>
Sent: Sunday, July 02, 2006 9:37 AM
Subject: Re: OSPF
> Sami,
>
> P2MP-Nonbroadcast as you can see from the name is a hybrid solution, it
> combines the best of both P2MP & Nonbroadcast Interface types.
>
> P2MP-Nonbroadcast Interfaces Advantages:
> * Generate /32 host routes for your spokes (this was taken from P2MP
> interface type).
> *Uses unicast instead of multicast Hellos (this was taken from the
> nonbroadcast interface type).
> *The use of multicast means, neighbor statements are needed. (taken from
> nonbroadcast interface type)
> *No need for DR/BDR elections (taken from P2MP interface types).
>
> Though there are many Task that will point to P2MP-Nonbroadcast, these are
> few:
> 1. Configure OSPF between your Frame relay Routers, ensure that your frame
> spoke reachability is facilitated via a dynamic routing protocol,
> your solution must use unicast hellos.
> 2. Do not use dynamic inverse-arp, do not configure mapping between frame
> relay spokes, do not use static routes, but enabled IP
> reachability between your frame spokes, your solution must ensure
that
> other OSPF enabled routers apart from R1, R2 & R3 do not intercept
> your OSPF communication.
> 3. Configure OSPF between R1, R2 & R3 with R1 as the hub, do not elect
> DR/BDR & do not use multicast hellos on this segment.
> 4. Configure OSPF between R1, R2 & R3, your solution may use unicast
hellos,
> but it may not rely on OSPF interface priority to function.
> 5. Configure OSPF between R5, R1 & R2; ensure that a 'show ip ospf
neighbor'
> & 'debug ip ospf hello' on R5 have outputs similar to the following:
>
> Rack1R5#sh ip ospf neighbor
> Neighbor ID Pri State Dead Time Address
Interface
> 150.1.2.2 0 FULL/ - 00:01:49 128.1.125.2
Serial0/0
> 150.1.1.1 0 FULL/ - 00:01:49 128.1.125.1
Serial0/0
> Rack1R5#
> Rack1R5#
> Rack1R5#debug ip ospf hello
> OSPF hello events debugging is on
> Rack1R5#
> *Mar 1 00:46:34.471: OSPF: Send hello to 128.1.125.2 area 0 on Serial0/0
> from 128.1.125.5
> *Mar 1 00:46:34.471: OSPF: Send hello to 128.1.125.1 area 0 on Serial0/0
> from 128.1.125.5
> Rack1R5#
>
> You see that, there are good ways of pointing you towards using
> P2MP-Nonbroadcast OSPF interface type and there are still 'evil' ways of
> doing it, but once you understand all the various OSPF interface types and
> how they affect your environment, you can see through any 'trick' in the
> wording of the Task ahead of time. This is why it is very important that,
at
> least before you configure your Frame Relay Section, skip ahead and read
the
> OSPF section, else you might find yourself coming back to tear down &
> reconfiguring your frame relay for things to work correctly.
>
> Note that, you can configure any OSPF interface type on any media type,
your
> task will direct you which way to go. Eg, Ethernet supports broadcast, but
> your task could be worded in such a way that, non-broadcast or other OSPF
> network types might be the only appropriate network type to be configured.
> This also goes for frame relay physical interface, which is by default
> non-broadcast, but can be configured to support OSPF broadcast or any
other
> OSPF network type.
>
> HTH
>
> Godswill Oletu
> CCIE #16464.
>
>
> ----- Original Message -----
> From: "Sami" <sy1977@gmail.com>
> To: "Victor Cappuccio" <cvictor@protokolgroup.com>
> Cc: "ccielab" <ccielab@groupstudy.com>
> Sent: Sunday, July 02, 2006 6:13 AM
> Subject: Re: OSPF
>
>
> > Thanks Victor , use P-2-MP non-brodcast where broadcast is not
> > supported...we need neighbour command also to make it work.. right ?
> >
> >
> > On 7/2/06, Victor Cappuccio <cvictor@protokolgroup.com> wrote:
> > >
> > > For Example when you have a Hub and Spoke topology in a Frame-relay
> > > Topology, and in the Frame-relay Could Broadcast is not supported
> > >
> > > The network type ospf OSPF does not depends on the Physical L2
> Interface,
> > > (OSI Modularity), cool right?
> > >
> > > HTH
> > > Vmctor.-
> > >
> > >
> > > -----Mensaje original-----
> > > De: nobody@groupstudy.com [mailto:nobody@groupstudy.com] En nombre de
> Sami
> > > Enviado el: Domingo, 02 de Julio de 2006 05:45 a.m.
> > > Para: ccielab
> > > Asunto: OSPF
> > >
> > > Group,
> > >
> > > Couldn't understand in which scenario do we need to use
> > > point-to-multipoint
> > > non braodcast. FR interface by default is non-braodcast mode.
> > >
> > > Appreciate if some one can shed some light on this ?
> > >
> > > Thanks
> > >
> > >
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:46 ART