[Cu-wireless] Re: Cu-wireless digest, Vol 1 #134 - 3 msgs
David Young
dyoung at ojctech.com
Sun May 26 13:11:32 CDT 2002
Hi Mark,
Must an NBMA network have a D.R.? If we set every router's priority for
election as D.R. to 0, do we get broken routing or working routing w/o
any D.R.'s ?
Suppose we enumerate the hosts on a pod (there are at most 16 or 32),
and we make each a point-to-point link. Will that work?
Suppose, too, we enumerate the hosts on an uplink network and make each
a point-to-point link?
It is more clear all the time that OSPF is not the routing protocol we
want to use. I think that the protocol we do want to use, we will have
to program ourselves to operate in Zebra. It is probably DSDV, AODV,
or one of the other new-fangled routing protocols for ad hoc networks.
Dave
On Sun, May 26, 2002 at 12:25:58PM -0500, The Morenz Family wrote:
> Hi All:
>
> I finally had time to read and digest the most recent digests
> (including the much-anticipated goals, etc. post) and it sounds good
> (as in "so far,..."). Some feedback:
>
> To the extent that pods won't be full-mesh (at least we've never said
> they had to be), you must run in PMP mode. NMBA is not really an
> option. You don't want "designated router" elections to occur (which
> router would be the backup D.R., for example?)
>
> The way I see it the two big drawbacks to PMP are: that routing
> overhead for such a system is usually beyond what low-end routers
> (which I believe our boxes would qualify as) are geared up for
> (especially if link integrity is a problem and the spf algorithm is
> constantly cycling...which sounds like wireless to me).
>
> Two, you generally need to manually configure each router in this
> type of network. Despite what RFC 2328 says, inverse arp doesn't
> auto-detect for OSPF. The two don't automatically work together. OSPF
> only uses Hellos to detect neighbors. Therefore OSPF needs to know
> how to broadcast over a non-broadcast medium. Cisco built on what the
> RFC recognized and engineered this into their products (and I believe
> it does have an 'inverse arp' functionality). I leave it up to others
> to decide if they want to do the same.
>
> There are other technical issues as well, of course. Duplicate LSAIDs
> can be a problem if you lose your discipline and give anything but
> host routes out. And, once again, if you decide to try to scale by
> using virtual links, you are introducing routing loop scenarios into
> what should be a loop-proof protocol.
>
> Also, here's something I'm not clear on...can multiple
> networks/subnets run over the same channel? If not, then it would
> seem that a pod could not be a collection of OSPF routers running in
> PMP mode advertising themselves as host routes. But my ignorance of
> all things wireless is showing, so I'll stop there.
>
> Take Care!
>
> :-{)]
>
>
>
> >
> >
> >Message: 3
> >Date: Fri, 17 May 2002 16:24:01 -0500
> >From: David Young <dyoung at ojctech.com>
> >To: cu-wireless at ucimc.org
> >Reply-To: dyoung at pobox.com
> >Subject: [Cu-wireless] OSPF and non-broadcast networks
> >
> >
> >Below, I have snipped some text from RFC 2328, which defines OSPFv2.
> >Zebra implements OSPFv2. It seems to me that in pods, we should run OSPF
> >in a point-to-multipoint mode. Does anyone else have a different reading?
> >
> >Zebra appears to support point-to-multipoint mode through its command
> >"ip ospf network point-to-multipoint".
> >
> >Dave
> >
> >*** snip snip ***
> >
> > Non-broadcast networks
> > Networks supporting many (more than two) routers, but having
> > no broadcast capability. Neighboring routers are maintained
> > on these nets using OSPF's Hello Protocol. However, due to
> > the lack of broadcast capability, some configuration
> > information may be necessary to aid in the discovery of
> > neighbors. On non-broadcast networks, OSPF protocol packets
> > that are normally multicast need to be sent to each
> > neighboring router, in turn. An X.25 Public Data Network
> > (PDN) is an example of a non-broadcast network.
> >
> > OSPF runs in one of two modes over non-broadcast networks.
> > The first mode, called non-broadcast multi-access or NBMA,
> > simulates the operation of OSPF on a broadcast network. The
> > second mode, called Point-to-MultiPoint, treats the non-
> > broadcast network as a collection of point-to-point links.
> > Non-broadcast networks are referred to as NBMA networks or
> > Point-to-MultiPoint networks, depending on OSPF's mode of
> > operation over the network.
> >
> >*** snip snip ***
> >
> > Designated Router
> > Each broadcast and NBMA network that has at least two
> > attached routers has a Designated Router. The Designated
> > Router generates an LSA for the network and has other
> > special responsibilities in the running of the protocol.
> > The Designated Router is elected by the Hello Protocol.
> >
> > The Designated Router concept enables a reduction in the
> > number of adjacencies required on a broadcast or NBMA
> > network. This in turn reduces the amount of routing
> > protocol traffic and the size of the link-state database.
> >
> >*** snip snip ***
> >
> > 2.1.1. Representation of non-broadcast networks
> >
> > As mentioned previously, OSPF can run over non-broadcast
> > networks in one of two modes: NBMA or Point-to-MultiPoint.
> > The choice of mode determines the way that the Hello
> >
> >
> >
> >Moy Standards Track [Page 15]
> >
> >RFC 2328 OSPF Version 2 April 1998
> >
> >
> > protocol and flooding work over the non-broadcast network,
> > and the way that the network is represented in the link-
> > state database.
> >
> > In NBMA mode, OSPF emulates operation over a broadcast
> > network: a Designated Router is elected for the NBMA
> > network, and the Designated Router originates an LSA for the
> > network. The graph representation for broadcast networks and
> > NBMA networks is identical. This representation is pictured
> > in the middle of Figure 1a.
> >
> > NBMA mode is the most efficient way to run OSPF over non-
> > broadcast networks, both in terms of link-state database
> > size and in terms of the amount of routing protocol traffic.
> > However, it has one significant restriction: it requires all
> > routers attached to the NBMA network to be able to
> > communicate directly. This restriction may be met on some
> > non-broadcast networks, such as an ATM subnet utilizing
> > SVCs. But it is often not met on other non-broadcast
> > networks, such as PVC-only Frame Relay networks. On non-
> > broadcast networks where not all routers can communicate
> > directly you can break the non-broadcast network into
> > logical subnets, with the routers on each subnet being able
> > to communicate directly, and then run each separate subnet
> > as an NBMA network (see [Ref15]). This however requires
> > quite a bit of administrative overhead, and is prone to
> > misconfiguration. It is probably better to run such a non-
> > broadcast network in Point-to-Multipoint mode.
> >
> > In Point-to-MultiPoint mode, OSPF treats all router-to-
> > router connections over the non-broadcast network as if they
> > were point-to-point links. No Designated Router is elected
> > for the network, nor is there an LSA generated for the
> > network. In fact, a vertex for the Point-to-MultiPoint
> > network does not appear in the graph of the link-state
> > database.
> >
> > Figure 1b illustrates the link-state database representation
> > of a Point-to-MultiPoint network. On the left side of the
> > figure, a Point-to-MultiPoint network is pictured. It is
> > assumed that all routers can communicate directly, except
> > for routers RT4 and RT5. I3 though I6 indicate the routers'
> >
> >
> >
> >Moy Standards Track [Page 16]
> >
> >RFC 2328 OSPF Version 2 April 1998
> >
> >
> > IP interface addresses on the Point-to-MultiPoint network.
> > In the graphical representation of the link-state database,
> > routers that can communicate directly over the Point-to-
> > MultiPoint network are joined by bidirectional edges, and
> > each router also has a stub connection to its own IP
> > interface address (which is in contrast to the
> > representation of real point-to-point links; see Figure 1a).
> >
> > On some non-broadcast networks, use of Point-to-MultiPoint
> > mode and data-link protocols such as Inverse ARP (see
> > [Ref14]) will allow autodiscovery of OSPF neighbors even
> > though broadcast support is not available.
> >
> >
> >
> >
> >
> >
> > **FROM**
> > +---+ +---+
> > |RT3| |RT4| |RT3|RT4|RT5|RT6|
> > +---+ +---+ * --------------------
> > I3| N2 |I4 * RT3| | X | X | X |
> > +----------------------+ T RT4| X | | | X |
> > I5| |I6 O RT5| X | | | X |
> > +---+ +---+ * RT6| X | X | X | |
> > |RT5| |RT6| * I3| X | | | |
> > +---+ +---+ I4| | X | | |
> > I5| | | X | |
> > I6| | | | X |
> >
> >
> >
> > Figure 1b: Network map components
> > Point-to-MultiPoint networks
> >
> > All routers can communicate directly over N2, except
> > routers RT4 and RT5. I3 through I6 indicate IP
> > interface addresses
> >
> >
> >--
> >David Young OJC Technologies
> >dyoung at onthejob.net Engineering from the Right Brain
> > Urbana, IL * (217) 278-3933
> >
> >
> >
> >--__--__--
> >
> >_______________________________________________
> >Cu-wireless mailing list
> >Cu-wireless at lists.groogroo.com
> >http://lists.cu.groogroo.com/cgi-bin/listinfo/cu-wireless
> >
> >
> >End of Cu-wireless Digest
>
> _______________________________________________
> Cu-wireless mailing list
> Cu-wireless at lists.groogroo.com
> http://lists.cu.groogroo.com/cgi-bin/listinfo/cu-wireless
--
David Young OJC Technologies
dyoung at onthejob.net Engineering from the Right Brain
Urbana, IL * (217) 278-3933
More information about the CU-Wireless
mailing list