Fw: [MLB-WIRELESS] OSPF BGP

Sun Jun 26 20:35:05 EST 2005



I cant ping waggy since him and Nigel where playing around with bandwidth
 sharing to gho.
 I have noticed when coping large files over multiple link that ospf routes
 seem to become dropped, the download doesn't resume until the routers have
 been updated. This is why i am trying to get some people to try out bgp
 routing to see if it has the same problem, which i doubt because it uses
 tcp, and not multicast like ospf
>
> Thanks 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: "mike campion" <mikecamp at optusnet.com.au>
> To: "Brenton D." <ivile01 at yahoo.com.au>
> Sent: Sunday, June 26, 2005 8:09 PM
> Subject: Re: [MLB-WIRELESS] OSPF BGP
>
>
>> nigel was telling me you were having a problem with ospf and gho, i think 
>> i'm having the same problem.
>> when i have ospf running on my box connected to gho its showing all 
>> routes to 10.10.130.176/28 ok, when i ping to ip's on that subnet on that 
>> box all is ok.
>> but when i do it from another box i can ping 10.10.130.178(ges) ok but 
>> not 10.10.130.180(waggy).
>> is this the same problem you were having and if so did you sort it out.
>> nigel also said waggy was looking into it
>>
>> thanks michael
>>
>> ----- Original Message ----- 
>> From: "Brenton D." <ivile01 at yahoo.com.au>
>> To: "Steven Haigh" <netwiz at crc.id.au>; <melbwireless at wireless.org.au>
>> Sent: Sunday, June 26, 2005 7:22 PM
>> Subject: Re: [MLB-WIRELESS] OSPF BGP
>>
>>
>>>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
>>>
>>
> 


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