[MLB-WIRELESS] GHO ----- UPDATE!

[Brenton D.]

Is this what happened to your ap Ryan to many people connected to it and it 
just died?

Hopefully Node IBG should be up within a few weeks. It will be running a 
senao 200mw AP and a 15dbi wave-guide, i will connect to it from either node 
fuu or fut, i just need to get a PCMCIA to pci adapter.


But GHO seems to be running okay. I have a better link to it than i did to 
FKR.



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: "Ryan Abbenhuys" <sneeze at alphalink.com.au>
To: "Dan Flett" <conhoolio at hotmail.com>; <sneeze at alphalink.com.au>; 
<melbwireless at wireless.org.au>
Sent: Monday, June 20, 2005 5:07 PM
Subject: RE: [MLB-WIRELESS] GHO ----- UPDATE!


> Dan, you're spot on the money.
>
> Eventually to maintain any usefulness they need to be restricted to around
> 3 connections each and used to link the large clusters together via a
> nominated node in each cluster.
>
> Each nominated uplink node should not be propogating their entire route
> table but rather aggregating their routes and propogating only a couple
> that will cover everyone in their cluster.  ie, 10.10.128.0 with a mask of
> 255.255.254.0 (/23) which would cover 10.10.128.1 right through to
> 10.10.129.254
>
> This is done to prevent unnecesary routing traffic.  A node in RGsouthern
> doesn't really need to know about each individual nodes status in
> RGInnerNorth, they only need to know how to get to the entire cluster of
> InnerNorth.  If the particular node is down, their pings timeout after 
> they
> get as far as they can.
>
> Sure it gives you a warm a fuzzy feeling to see a nice big route list but
> technically you want the opposite of that. You want the smallest route 
> list
> you can get and this is what route aggregation is for.
>
> The next thing to look at is those backbone uplink nodes should setup some
> simply QoS.  QoS tags won't be that useful because not everyone is going 
> to
> be reading/supporting them so your best option is to queue packets based 
> on
> port numbers.  For example give high priorities to ports for gaming, chat,
> telnet, etc that want low latency and give ports for http, ftp, etc a low
> priority.
>
> ...however before a lot of this happens the IP allocation system needs a
> complete overhaul or you're in for a painful surprise further down the
> track.
> This is something I unsuccessfully tried to campaign for. :-\
>
>
>>> -----Original Message-----
>>> From: owner-melbwireless at wireless.org.au [mailto:owner-
>>> melbwireless at wireless.org.au] On Behalf Of Ryan Abbenhuys
>>
>>
>>> Are you guys still not familiar with the term "backbone"?
>>>
>>> After 4 or more people connect to any AP I guarantee you'll be better
> off
>>> using dialup modem links.
>>
>>Ryan, what would you suggest for GHO?  Are three 2.4GHz interfaces - each
> on
>>a different channel serving a different area - not an improvement over a
>>single interface?  A 5.8GHz interface is also planned.  At the moment the
>>idea is to allow people to connect from wherever they can to do signal
>>strength and data rate testing.  We should also start experimenting with
>>network Quality-of-Service (QoS) applications and be measuring their
>>usefulness.
>>
>>FYI, as of this writing:
>>
>>GHO-North has two OSPF clients:
>>10.10.129.3 Node GWS - nice webpage and propagating 13 /28 subnets!
>>                     - also propagating 127.0.0.1.  Naughty!
>>10.10.129.4 Node IKD - no webpage and is propagating 192.168.20.0/24
>>                     - and 192.168.60.0/24 onto the network.  Naughty!
>>                     - nice work on the long link though. :)
>>
>>GHO-South also has two OSPF clients:
>>10.10.130.178 Node GES - propagating 4 /28 subnet, a /30 and a nice
>>                         webpage
>>10.10.130.180 Node FKR - propagating 3 /28 subnets. (no webpage on the
>>                         router)
>>
>>GHO-Mobile has one OSPF client:
>>10.10.131.70 - Node FUT - propagating 3 /28 subnets and a nice webpage
>>
>>Running ARP on the GHO router reveals no other clients connected at all.
>>
>>Of course, too many clients on any one AP will cause it to slow right down
>>with hidden-node problems - negating GHO's usefulness.  So I believe the
>>longer-term plan is to work out who are the best candidate nodes to retain
> a
>>permanent direct-link to GHO.  Once chosen, only they will be allowed
>>access.  I would hope that the method used to choose these nodes is fair
> and
>>open, and provides the best technical outcome for the overall network.
>>Perhaps some generally-agreed-upon official guidelines should be drawn up
> so
>>that everyone is clear on what is required to become a permanent client of
>>Node GHO.  If we don't I can see GHO becoming a source of discontent and
>>dissatisfaction once again.
>>
>>At this point I'd say that the most likely nodes to be allowed to retain a
>>GHO connection are those who serve traffic to a cluster of Melbourne
>>Wireless nodes.  GHO is too important to allow permanent leaf-node access,
>>except maybe on the "GHO-Mobile" interface, or to providers of important
>>content to the network.
>>
>>The point is important enough to be made again:
>>For technical reasons, GHO cannot offer open-slather access if it is to be
>>truly useful to the Melbourne Wireless network.  Just because you *can*
>>connect to it doesn't necessarily mean you *should* connect to it.  If you
>>can connect to a more local node, please do so.  If you can set up a
>>multi-radio routing node in your area, even better!
>>
>>Cheers,
>>
>>Dan
>
> 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