[Cu-wireless] Re: Cu-wireless digest, Vol 1 #134 - 3 msgs
The Morenz Family
mmorenz at ameritech.net
Sun May 26 12:25:58 CDT 2002
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
More information about the CU-Wireless
mailing list