[MLB-WIRELESS] OSPF BGP

[Dan Flett]

> From: owner-melbwireless at wireless.org.au 
> [mailto:owner-melbwireless at wireless.org.au] On Behalf Of Ryan 
> Abbenhuys
> BGP (Border Gateway Protocol) is actually, as strange as this 
> may seem....a "Border Gateway Protocol". Meaning it is 
> designed to run on the border of network clusters (Autonomous 
> Systems) to link them together.

And I would argue that each Melbourne Wireless node is an Autonomous System.
Generally speaking, a cluster of nodes doesn't have one administrator who
has control over all the routers in that cluster.  Each node and it's owner
is an island, so to speak.  That is, each node is Autonomous.
 
> For example, an ISP would use BGP to communicate routes 
> (heavily aggregated of course) out of their links to other 
> ISP's, however within their own building/network they will 
> use OSPF, EIGRP, or similar.

And if a node-owner or organisation administers more than one node in a
cluster then it might make sense to use an interior routing protocol between
them, and advertise a single ASN to the rest of the network.  Otherwise,
nodes that are separately administered should speak an exterior routing
protocol to each other.

> To relate this to the Melbourne Wireless network, it would be 
> like us using BGP to link regional clusters together, while 
> within the clusters using OSPF.  This would work perfectly 
> fine, although possibly a little overkill due to extremely 
> small size of our network, when compared to the internet, 
> OSPF should be quite sufficient.

I can see that idea working in theory, but not in practice.  As has been
demonstrated, using BGP in eBGP-only mode is very easy.  You only need to
specify your direct neighbors IP address and ASN in the config file.  Not
many non-backbone nodes will ever have more than 5 or 6 routers directly
connected to them.  If you want to also use an interior routing protocol
such as OSPF to communicate amongst a number of nodes and have them all
advertise a single ASN to external clusters, things get very complex.  Every
BGP node in the cluster needs to know the IP's of every other BGP node so
that they can co-ordinate external routes.  They use the iBGP protocol to do
this.  iBGP requires that all routers speaking it be fully meshed - all
directly connected to each other.  If they are not then this has to be
specified in the config file.  Basically, this isn't practical even within a
single small Melbourne Wireless cluster, unless all the nodes in that
cluster are administered by a single (knowledgeable) person.

When considering the routing protocol, the human factor is vitally
important.  If it is too hard to configure, you will greatly cut down the
number of people who want to get involved.

> So really the only people who would need to confuse 
> themselves with learning a second routing protocol would be 
> those who are running the backbone links between regional clusters.

If we decide that eBGP is the way to go for all our nodes, the config files
will be so simple it may be possible to create wrapper scripts to
automatically create them.  More simple than the current OSPF config files
we use - and therefore less prone to errors. 

> As for the OSPF not functioning too well with everyone on 
> area 0, that is correct, it won't work too well.  Search 
> through the mailing list archives, I brought up this subject 
> several times after a lot of research and discussions with 
> networking industry experts (who would normally charge a LOT 
> for their time) in an effort to steer people onto the right 
> path, although like IP allocations, with little success.

I would argue that any attempt to aggregate routes in a network like ours is
doomed to failure.  No matter where you draw the geographic boundaries of
the IP supernets, someone will come along and make a cross-border link that
totally screws everything.   You can ask that person to discard their
current IP range and re-apply for an IP range from the region group that
they are linked to, but people will get pretty sick of having to do that as
inter-region links change every couple of months.  Basically, it should be
assumed that any node in Melbourne can link to any other node.  More
importantly, it should never be assumed that nodes from the same region will
never use inter-region links to connect to each other.  Whilst this doesn't
happen a lot in practice, it happens often enough to make a mess of any
attempt to aggregate routes.

This is the difference between a wireless network and a wired network - with
which the networking industry experts you speak of are probably more
familiar.  In a wired network, you can allocate an address range to a whole
building and there will almost never be a need for any node within that
building to make a separate external link outside of the main backbone.
Basically, it's easy to exert control over the network topology in a wired
network.  In a wired network, physical distances between nodes place real
boundaries - boundaries that can be covered with IP supernets.  In a
wireless network like ours, physical distances less than 30km or so do not
have the same constraining effect.  I think it's a mistake to assume that
the Melbourne Wireless network resembles a wired network, and that
traditional rules regarding route aggregation can be applied.

Imagine that we somehow grow to a point where we have 1000 routers on the
network - with 1000 /28 subnets.  I'm sure most would agree that such a
network is beyond our wildest dreams at this point.  Can our routers handle
a routing table with 1000 entries?  I don't know the exact formula for
calculating the amount of RAM required for each entry, but Internet routers
have to deal with routing tables with 62000 entries, and BGP ASNs on top of
that.  These routers require approx. 16Mb of RAM to do what they do.
WRT54G's have 8Mb of RAM and a far smaller network to deal with.  So I don't
see route aggregation as a burning issue for us right now.  I see making
participation in the network much easier and more interesting as being a far
more important issue.

Dan

To unsubscribe: send mail to majordomo at wireless.org.au
with "unsubscribe melbwireless" in the body of the message