Hey guys, I'm wondering if anyone has some ideas to how I should set up, or things to keep in mind when implementing a network for a 200 person lan.
I am going to assume this will be a hostile environment so I need to keep security in mind, also I'd like to have it organized well so that diagnosing network problems is quick.
I have a /23 block of public IP addresses to work with.
Some of the equipment I've been provided with is sub-par: 24port 10/100 switches without a gig uplink.
How much of an impact will there be on the gaming traffic of 23 people going through a 100mb link to the core?

What I'm thinking is that I will assign an IP for each attendee (no dhcp) and each table with 23 people will be in a seperate vlan.
Most of the games will be going through the internet, however there will be a few lan game servers.
I might have access to a cisco router, but if not I'll be using pfsense for inter-vlan routing.
Should I implement QOS? How do I prevent torrents from sucking up our bandwidth?
The internet connection will be a 100Mb up/ 100Mb down.
Ty for any considerations you come up with :)

i don't know why it needs to be that fancy.... a collapsed backbone network is easiest for LAN gaming.. and you won't run out of addresses on a single subnet. Stackable smartswitches are a must... aggregate linked with ethernet or with SC fiber. And packet inspection capable so you can see pin down a wormed machine or 2 that is nuking the performance of your network.

With PF sense you can throttle the bandwidth so frames meant for gaming apps are prioritized over web,ftp,torrent traffic.

Security shouldn't be a problem.. make the users know that they are at a LAN and if their machine gets hacked it's their problem. The only security I would be concerned with is the on-site game servers.

pro - if the user brings a PC, laptop, tablet and smart phone they won't be consuming 4 IP addresses in DHCP mode which will exceed your address limit on a single sub-net (you should assume for this)

con - it only takes one dumb-ass to enter in a wrong address causing IP address conflicts with other participants.

con - if someone brings another device they are probably going to TRY to enter a different static IP address anyway to guess their way onto the network... again causing an IP address conflict with another participent

con - this is more paperwork you have to manage (who has what address) when you would probably rather be troubleshooting LAN performance or internet performance issues during the party

Thanks for the input!
I agree with you, DHCP is the way to go, and I watched a video on the dreamhack network, and they used DHCP as well.
I'm wondering if I'm trying to get too fancy here, maybe I should just use one big subnet with no NAT. There will be about 230 clients on it though.. I'm thinking this might be too big of a broadcast domain, especially considering that for 8 tables, there are 23 clients, on a switch with a 100mb uplink.
If I don't use the router, I could setup a mirroring port on the switch for monitoring the network.
Any thoughts?

The access switches are dumb, so no stp.
The core switch does have stp, and storm control if there is a loop on an access switch - which limits the %of broadcast traffic it will accept compared to regular traffic.
That's a good idea to have a few vlans instead of 10. The only thing is if i go the vlan route, I'll need to use a router and 1:1 nat which increases the complexity, since we have a /23 for our use, but we cant change the gateway ip, so I don't believe its possible to make use of smaller subnets in the /23, like /26s.
I don't really need the monitoring, but I figure it would help in locating faults, or people that are torrenting.

So if anyone is wondering..
I ended up going the simple route - had 11 x 24port 10/100 uplinked to my managed switch - which was running a DCHP server for the public ips from the /23.
DHCP snooping on the core switch came in handy when someone plugged into their access switch with a DHCP server running on their computer. The core switch turned off that port, though this was before we started so it didn't cause an inturruption. Also, my core switch was running a different spanning tree protocol, so it wouldn't negotiate with the uplinked switch until I talked to the network admin.
Next year I plan to have a SPAN (mirrored) port dumping the traffic out so I can anaylze it.