Router – How to configure 3 vlans on HP Procurve 2920 switch and Gateway is a CISCO router

That's close to what we have, right down to the Untangle gateway. We do it a little differently, though. It helps visualize if you start from a completely flat network with no vlans. Represent this with everything untagged on vlan 1.

Now we want to add support for wifi traffic on vlan 2. To do this, set both ends of every trunk line (lines connecting two switches) to also be tagged for vlan 2. There is no need to switch vlan 1 from untagged to tagged, as you do in your current proposal; all you need to do is add the port as tagged member of vlan 2. Additionally, ports needing to talk to wireless clients should be added as tagged members of vlan 2. This includes the port your untangle server is connected to, and the ports for any servers (like dhcp) that wifi traffic should be able to see without routing. Again, you want to leave them untagged on vlan 1; just add them as tagged members of vlan 2 also.

One important key here is that our central switch supports layer 3 routing, and we have an ACL there that tells it when it's allowed to route traffic from one vlan to another. For example, all of our printers and our printer server are on vlan 1. We use a software package on the print server to count jobs and bill students for print usage, so we do want to allow wifi traffic to hit the print server. We do NOT want to allow wifi traffic to hit individual printers directly, which would bypass that software, and so the printers are restricted in the ACL, but the print server is allowed.

You will also need to do some work on your untangle box itself, depending on how things are set up. Look under Config->Networking->Interfaces and edit your internal interface. There you want to see your untangle server's Primary IP Address and Netmask set for an address on your vlan 1 subnet. We also have an IP Address Alias setup for each vlan we use, NAT policies defined for each vlan network address and netmask, and routes for each vlan to send traffic for those vlans to the internal interface.

I should add that we run our untangle in router mode with a single internal interface and have dhcp/dns on a windows server box. Your setup may be different if you use bridge mode or want to run dhcp/dns off of untangle, or use separate interfaces for each network.

Now your network is prepared to add access points. Whenever you add an access point to the network, set it's port as untagged for vlan 2, and tagged for vlan 1. That vlan 1 tag here is optional, but I often find it helpful.

Finally, depending on the size of your installation, you may find that one vlan for wifi is not enough. You generally want to keep it down to about one /24's worth of clients online at a time. Fewer is better. Any more than that and broadcast traffic will start to eat up your airtime. You can get away with larger address spaces (say, /22's), as long as all of the addresses aren't in use at one time. That's how we handle it here. I support about 450 residential college students on a single SSID with a /21 subnet, but I'm really stretching it and probably should start carving my assignments up so that broadcast traffic from students in different buildings doesn't interfere with each other. If this is more of a single large building like a high-school, you probably want to choose different SSIDs per vlan. If it's a multi-building campus where the buildings are separated by some distance and you won't be pushing coverage to the space between buildings, you can get by with one SSID for all of the vlans.

Hopefully, your controller/wifi vendor covers all that, but if you're like us you don't have the funds for $600/access point or $3000+ per controller unit. It might be worth remembering that you can use simple consumer routers as access points by turning off dhcp and using a LAN port rather than WAN port for the uplink. You'll miss out on some reporting and automatic power and channel adjustments, but with some good access points and some careful work at setup you can put together quite a large network this way.

LACP is the Link Aggregation Control Protocol. It is all about setting up link aggregation automatically and dynamically whenever more than one link is available and the other side speaks LACP as well. It typically is used with redundant server-switch interconnection since a static setup with link aggregation would break server connectivity as long as the NIC drivers (where link aggregation is implemented) have not been loaded, thus effectively breaking pre-boot server management or network boot capabilities.

For switch interconnects, usually a static setup is preferred - although I would consider it purely a matter of taste.

"Link aggregation" and "trunking" are usually used as synonyms. There is a defined IEEE standard for LA (802.3ad) and many proprietary vendor extensions have arisen before standardization, most of which have implementations even in newer switch models for backward compatibility reasons.

If you set up a link aggregation or trunk group (LAG/TG), you should define the same VLANs as members of the group for switches on both sides. You only should define more than one path (i.e. more than one LAG interconnection) between two switches if you a) know exactly what you are doing and b) have enabled STP on both connected switches.

If you just suspect a bandwidth bottleneck, use the port statistics counters of your switches to verify it - quite possible that the bandwidth usage will turn out fine and your problem is an entirely different one. Mostly, switches do have rather slow CPUs and fast ASICs able to do most of the processing without any burden on the CPU. Some operations still would eat CPU cycles, one that is quite "popular" is the reception of broadcasts or multicast packets. If your network is generating a lot of broadcast/multicast traffic, processing and discarding the packets itself might saturate the CPU of a switch beyond reason. Again, check the counters to see if an excessive number of broadcasts is seen on the net.