[MLB-WIRELESS] OSPF BGP

[Steven Haigh]

I agree on some of this...

Having this easily administered via a web page on, say, a WRT router would
make things very easy for the average joe to configure.

Might be well worth adding this info onto a custom firmware for the WRTs...

On Thu, June 23, 2005 13:34, Dan Flett said:
>> 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
>


-- 
Steven Haigh

Email: netwiz at crc.id.au
Phone: (03) 9308 3238 - 0412 935 897



-- 
Steven Haigh

Email: netwiz at crc.id.au
Phone: (03) 9308 3238 - 0412 935 897

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