From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Tue Jul 19 2005 - 13:51:00 GMT-3
I usually recommend against making complicated checklists like
this because before you know it you're rewriting a book on all of the
technologies. Instead of memorizing which network types to use in which
situations, learn what the differences are between the network types and
the appropriate cases for them will become evident.
The OSPF network types are:
Broadcast
Non-broadcast
Point-to-Point
Point-to-multipoint
Point-to-multipoint Non-broadcast
Loopback
They affect whether updates are sent as unicast or multicast,
whether there is a DR/BDR election, and how next-hop processing is
performed. Specifically the network types are outlined as follows:
OSPF Network Broadcast
Default on broadcast medias (Ethernet / Token Ring)
Sends hellos as multicast
Performs DR/BDR Election
OSPF Network Non-Broadcast
Default on multipoint NBMA medias (Frame Relay / ATM)
Sends hellos as unicast ("neighbor" command)
Performs DR/BDR Election
OSPF Network Point-to-Point
Default on point-to-point medias (HDLC / PPP)
Sends hellos as multicast
No DR/BDR Election
Only two neighbors on the segment
OSPF Network Point-to-Multipoint
Not a default option
Sends hellos as multicast
No DR/BDR Election
Modifies next-hop processing (Best option for NBMA)
Point-to-Multipoint Non-Broadcast
Not a default option
Sends hellos as unicast ("neighbor" command)
No DR/BDR Election
Modifies next-hop processing
OSPF Network Loopback
Loopback and Looped back interfaces
Advertises network as a stub host (/32 host route)
Now as for deciding which of the network types is appropriate
for a certain configuration you need to ask yourself:
Are there restrictions on which I can use?
Do I need a DR/BDR election?
Do I need to send hellos and unicast or multicast?
Is next-hop resolution an issue?
Are there more than two neighbors on the segment?
Generally in the CCIE lab the questions will eliminate various
options either directly or indirectly. Therefore by internalizing the
above questions you can isolate an option or reduce your available
options. In the case that options are not eliminated then you need to
make your best judgment. My best recommendation would be to try out all
the network types in different topologies and track your findings.
Based on these results you should see when one type is more appropriate
than another.
Also if you're still reading this the above outline (and what
Amit posted) is from our CCIE R&S Advanced Technologies Class (and
class-on-demand) in which all these situations are covered in depth. :)
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
> Arun Arumuganainar
> Sent: Tuesday, July 19, 2005 11:03 AM
> To: Chris Lewis (chrlewis); Brian Lee; ccielab@groupstudy.com
> Subject: Re: Re: Ospf network types
>
> For choosing the right ospf network types . Let me summarize it this
way
> .
>
> 1) Find out what is network topology : Your topology could be Full
mesh
> or
> Partial mesh ( include Hubs and spoke also to partial mesh group )
>
> 2) If its Full Mesh : All ospf network types will work . This includes
.
> a)
> NBMA ( Default ) ,b) BMA ( ip ospf network broadcast ) ,C) P2MP , D)
P2MP
> Non-broadcast , and E) P2P
>
> 3) For A and D : Use Neighbor Statements . For A and B : Influence DR
> election ( configure ospf priority for Neighbors or on the interface )
>
> Note : For P2MP( Both broadcast and Non Broadcast ) and P2P case DR
> election
> will not happen .
>
> 4 )For Partial Mesh : Use only P2P or P2MP ( both Broadcast and Non
> broadcast modes can be used ) .You will have manually configure
neighbor
> in
> case of P2MP.
>
> With the above 4 point you will be able to arrive at correct ospf
network
> type base on the topology and also the constraints given in the
question
> sheet .
>
> Hope this helps
>
> Thanks and Regards
> Arun
>
>
> ----- Original Message -----
> From: "Chris Lewis (chrlewis)" <chrlewis@cisco.com>
> To: "Brian Lee" <ipgirl@gmail.com>; <ccielab@groupstudy.com>
> Sent: Tuesday, July 19, 2005 8:17 PM
> Subject: RE: Re: Ospf network types
>
>
> > Just to add some detail to what others have already said.
> >
> > One of the reasons P2mp non-broadcast came in to being was because
lots
> > of TAC cases were created by people forgetting to put in the
broadcast
> > keyword on the frame map statements. So p2mp non-broadcast is a way
to
> > get p2mp to work with the neighbor command, making the broadcast
> > keyword on the map statement not necessary. In the exam this is used
if
> > you are told not to use the broadcast keyword on the map statements.
> > Consider the following
> >
> > R1:
> > interface Serial2/0
> > ip address 10.1.1.1 255.255.255.0
> > encapsulation frame-relay
> > ip ospf network point-to-multipoint
> > no fair-queue
> > frame-relay map ip 10.1.1.2 122
> > no frame-relay inverse-arp
> > !
> > router ospf 1
> > log-adjacency-changes
> > network 10.1.1.1 0.0.0.0 area 0
> > neighbor 10.1.1.2 cost 100
> >
> > R2:
> > interface Serial1/0
> > ip address 10.1.1.2 255.255.255.0
> > encapsulation frame-relay
> > ip ospf network point-to-multipoint
> > no fair-queue
> > frame-relay map ip 10.1.1.1 221
> > no frame-relay inverse-arp
> > !
> > router ospf 1
> > log-adjacency-changes
> > network 10.1.1.2 0.0.0.0 area 0
> > neighbor 10.1.1.1 cost 100
> >
> > R1 and R2 can ping each other's 10.0.0.0 interfaces, the network
type is
> > p2mp and there is a neighbor statement, however the neighbors do not
> > form, as each router is still trying to send to the multicast
address
> > with this network type, which leads to an encapsulation failed error
> > when the router tries to ship the packet over the frame link. To get
> > this setup to work, all you need do is change the network type to
p2mp
> > non-broadcast, the neighbor statement takes effect, R1 and R2 start
> > sending unicast OSPF packets and neighbors form.
> >
> > Chris
> >
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
> > Brian Lee
> > Sent: Monday, July 18, 2005 10:56 AM
> > To: ccielab@groupstudy.com
> > Subject: Re: Re: Ospf network types
> >
> > hi,
> > I have the same question, could anyone gives us an explanation ?
> >
> > Thanks
> >
> > Lee.
> >
> > ----- Original Message -----
> > From: "Sharma, Mohit" <mohit.sharma@hp.com>
> > To: <ccielab@groupstudy.com>
> > Sent: Sunday, June 20, 2004 10:36 PM
> > Subject: Ospf network types
> >
> >
> > > HI All,
> > >
> > > Could somebody please explain the difference between using ospf
> > network
> > > type point-to-multipoint and point-to-multipoint nonbroadcast.
> > >
> > > The only difference I could read on the doc cd's was that with the
> > added
> > > nonbroadcast option you can use neighbor statement and assign
costs to
> > > the neighbor spokes to distinguish between more or less preferred
> > links.
> > >
> > > But I did the same thing with just using the p2m option without
using
> > > nonbroadcast and was able to assign the cost to the spokes.
> > > Then why do we need the nonbroadcast????
> > >
> > > Also another question-IF ospf should send ONLY unicast messages to
the
> > > neighbor, then the only option would be to use nbma with neighbor
> > > command or is there any other option available which is send
unicast??
> > >
> > > Thanx,
> > > Mohit.
> > >
> > >
> >
This archive was generated by hypermail 2.1.4 : Sun Sep 04 2005 - 17:00:30 GMT-3