[MLB-WIRELESS] OSPF BGP

[Brenton D.]

I would really like to test bgp out especially on the routers directly 
connected to node GHO!
We can still run ospf as a backup.

Nigel?
Nevyn?

Brenton.

ivile01 at yahoo.com.au | ivile at ivile.bur.st
http://bur.st/~ivile (waveguides) | http://ivile.bur.st | 
http://ivile.bur.st/ivile/64/ (my car)
http://www.melbourne.wireless.org.au/users/?ivile
----- Original Message ----- 
From: "Steven Haigh" <netwiz at crc.id.au>
To: <melbwireless at wireless.org.au>
Sent: Thursday, June 23, 2005 2:05 PM
Subject: RE: [MLB-WIRELESS] OSPF BGP


>
> 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
> 


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