2008 Network Washup

From MelbLCAWiki

Jump to: navigation, search

Backup to Networking

Contents

Adhocs after thoughts

Thoughs about things we did because cunning plan X fell through

  • one of our master plans was to implement VLANs for all sorts of things. this would have made some admin on the APs easier, made traffic accounting easier and probably allowed us to split the IP address space up into more assignable chunks ... but I could not get the Cisco switch to talk to the HP switch with a VLAN'd port. talking to our local Cisco guru, he suggested enabling "portfast". now i really don't know what this does, as I'm not a CatOS kind of guy, but there you go.
  • we staticly routed everything in the end. i wanted to enable some dynamic routing to get the subnets up and announced when things came online and when they dropped etc. this turned out not to be so easy to do without the VLANs and using the tunnels we did. however, there is always next year =) all depends on your network architecture and how much you trust your users ;)
  • the tunnel between the colleges didn't work reliably. they should have, so we statically routed everything to the venue conf router
  • the tunnels between the colleges and the core seems to work fine. i am pretty sure we ended up using GRE tunnels. sit is IPv6 in IPv4 IIRR.i know we tried it, can't remember if we used it in the long run. the TUN stuff flat out did not work, don't remember why.
  • the colleges had good switch and cabling infrastructer. we located APs in the common rooms and in my room in St Marys. That worked out ok.
  • it took a lot of effort (and gaffer tape) to get the APs cabled up the way we wanted, even if the location wasn't really what we had in mind.
  • check out in advance what options you have to run APs and cabling in your colleges.

What I would do differently next time

  • Point to point WiFi instead of tunnels, or maybe go for dark fibre or ethernet. some things are possible, the LCA08 network team didn't have this option, but it would make life a lot simpler, explore your options.
  • we assumed that the APs were going to be flakey as heck. they weren't. they took lots of abuse as stayed up!thank you kamikaze 7.09. update with your latest firmware and brutalise it! they only way you know it will be ok is to test it.
  • test the AP firmware on the AP you want to run. i have a WRT54G at home and did the testing on it. we used WRT54GLs and they are different!!!
  • we used freenode to run the IRC channels for support and tech/network discussion. maybe a private one? maybe jabber instead? if the internet link goes away it makes it hard to talk to those on the ground to debug why, etc.
  • maybe assign the APs statically, it might not actually help. but it bears more thinking about better management options.
  • take more time to get the routing done in a more sensible and possibly dynamic way. this all depends on the network structure, how the switches are layed out around the build(s), if the network is flat, whether or not if you care that the clients can roam, or even if you think WPA might be useful.
  • OLPCs will be different to last time. there was an "update or die!" type message come out just before the conf and all attendees needed to updated to very recent version of the firmware etc. maybe its worth contacting the OLPC folks in advance to help the antendees get this sorted with out all the fuss etc.
  • i would perhaps split the network up a bit more to reduce the mdns frenzy, and perhaps put in some mdns service that caches this cruft. it was hurting on e of the old cisco switches, IIRR.
  • while most folks didn't need it, some signage up about what the APs and internet access policy is about. especially in the colleges. ie. bittorrent is not cool, yes you up the back in the baggy pants!
  • get the VLANs setup earlier and know how to drive the switches you have in advance. i didn't and my knowledge was out of date. we didn't run VLANs.

Things I would do again

  • Run a Linux box as the core router for the conf. need to be able to run random services on the core. need to be able to look at the logs any time. my cisco fu is old and rusty and hey, this is LCA after all ;)
  • get as much dark fibre/ethernet between rooms and buildings
  • radio space audit what channels are in use already and setup our APs not to clash.
  • use that multi ssh client thing again that Stuart worked wonders with, maybe called cluster-ssh. was very cool to setup an alias to hit all the APs

in a building. then, all in a college.

  • run DHCP on each network at the router, the core served the conf venue, all the clients and all the APs, same at the ressies, eachrouter served the local clients and APs.
  • we ran a Xen box. Steve did magic there and it worked a treat.
  • the DHCP setup was fantastic. all the APs were pre-populated as we got the MAC list from LCA07. the DNS to go with that was a life saver. name things sensibly. maybe by lecture room again? make short sane names and the cluster-ssh stuff is so much easier.
  • configs for APs per radio channel, ie, 1, 6, 11. three scripts on the venue, and but cluster-ssh group ;)
  • Donalds idea about labelling the ethernet cables at the lectern and noting what power circuit we're plugging into helped. we had a bunch of folks pop a power circuit in a lecture room taking out the lectern and ALL the AV gear. additionally a print out of the expected IP range, netmask, router and DNS server for the speaker would be good. also throw in there, what port numbers you use under the lectern and what ports they are on your switch gear. would make debugging easier.
  • get black gaffer tape for running cables and a roll of white gaffer tape for runs across doorways and hallways. do the run across the floor in white and then put black tape on the flat sides to make a highlighted bump where the cable is, makes a big difference to the visibility - nice tip from Steve.

Adhoc reminisce about the network of LCA08

Tunnels

  • We used GRE. finding out how to add more than three tunnels would be a good idea. gre0 is taken and you have gre[123] to play with per host.
  • the core router has two attached subnets, the external side had the services on it like ftp mirror and other stuff. the internal was where all the

venue APs, the wirelessly attached clients and the wired attached clients.

  • the routers at the colleges had two tunnels each, one to the core, one to the other college router.

Access Points in the venue

  • WRT54GLs are pretty amazing
  • OpenWRT Kamikaze 7.09 was a real performer for us. Whiterussian rc5 didn't really cut the mustard for the guys at LCA07.
  • our script took quite a bit of debugging, we did not use the config files as part of Kamikaze

Access Points in the colleges

  • a single WRT54GL was handling 69 simultaneous associated clients!

Routing

  • it was static. what this meant was that when the tunnels flapped, timeouts were painful.
  • all the traffic from the colleges was routed down the tunnel to the core router, then out to the internet.

Adhoc ToDo List

Things to add info about what we did and why

  • hmm what else do i need to add? Steve?

Backup to Networking

Personal tools