wright-fi

I'd recommend questioning each company you contact for a quote to assess the quality of the equipment they use and the skills of the engineer they’re sending to site. As your site is quite challenging and the demands are high it’s important to use accurate tools and have an engineer who can interpret the findings. Here is a list of questions I would ask and the response you should (in my opinion) expect: What Wi-Fi Survey tool do you use? - (Ekahau is the market leader, but Hamina is also a good solution, I’d avoid companies that user cheaper tools). Will the Survey equipment be able to measure 6GHz? – (If 6GHz is not supported, it suggests the company is using older tools and your new network would likely use 6GHz so it’s important to measure the spectrum). What Wi-Fi qualifications does the survey engineer hold? – (Due to the complexity of your requirements, I would look for a minimum of a CWDP or CCNP, but if you can a CWNE or CCIE would be better). What is included in the deliverables? – (Some companies will conduct a survey, generate the default report and send you an invoice. You want to avoid this. The final report should be customised to your needs, it should make recommendations on how to improve your current network and also recommend how a new design would look if you decide to replace your Wi-Fi). Good luck

You can add additional names to your NPS Server: NETDOM COMPUTERNAME *.ad.fXXXXXX.hXXXX.sch.uk /ADD fXXXXXXX.hXXXX.sch.uk NETDOM COMPUTERNAME *.ad.fXXXXXX.hXXXX.sch.uk /ENUM The first command adds the name and the second command prints all names. As you're using a self signed cert, BYOD users won't recognise your CA. So you would have to manually install the cert on each BYOD device (not ideal) or use a cert from a trusted certificate authority (such as GoDaddy).

From your list, you may need to add the Ruckus Controller/APs as a RADIUS Client. Also your NPS Server will likely provide more helpful error messages. This can be viewed in Event Viewer: Custom Views > Server Roles > Network Policy and Access Services.

The problem you have is that you can only login using user or device authentication, not both. You would need to use EAP Chaining to do both simultaneously, but this is not support with Windows NPS.

Yes, you will need to tag all of the ports. By all ports I mean (uplink ports on all switches and the ports connecting to access points). If you tag the SSID with a VLAN, but the switchport is not configured to use that VLAN, the switch won't know what to do with the VLAN tag and will drop the packet.

There is quite a bit to unpack here, so apologies if I miss anything. If your DHCP Server is managed by your ISP, you will need them to create a new scope. If the DHCP Server is in a different subnet to the new VLAN(s) you will need to setup dhcp relay, so that the client devices can find the DHCP Server. You will also need to create the new subnet, this would usually be created on the device that is the current default gateway of your network. This could be a Layer 3 Core Switch, router or firewall. This may be hosted by your ISP, as it could reside on the router. If it is from your ISP, it is important to know how the VLAN will be presented to your network switches, this could be a single port tagging all VLANs, a single port with a native VLAN and all other VLANs tagged, or multiple ports with a single untagged VLAN on each port. You will then need to start VLAN tagging, for the VLAN to move across the network every port carrying the traffic needs to have the correct VLAN tag in place. The devices that would need to be configured to use VLANs are likely be your router/core switch, uplink ports on all switches and the ports connecting to access points. It is important to remember that ports need to be tagged in both directions. If I were in your position, for connections between switches and access points, I would leave the native VLAN 1 as untagged, and tag all other VLANs. Over time you can created a dedicated VLAN for access points and switches, which is a good idea, but maybe one to review when your create VLANs for wired devices. Once all wired ports are tagged you can, as you rightly stated start to create SSID with VLAN tags on your Wi-Fi infrastructure. If this is your first time working with VLANs, starting on a network as large as yours is quite a daunting task, so you may want to seek some outside help. I hope this was helpful.

If your BYOD network is using RADIUS authentication I would check your NPS Server to see if your certificate has expired.

I would guess that this issue is due to the different way that the controller architectures talk to the radius server, let me explain my logic first. So with some of the original physical controllers from Ruckus (such as the ZoneDirectors) the AP would talk to the controller and the controller would talk to the RADIUS Server. AP -> Physical Controller -> RADIUS Server With the Cloud it would be very inefficient for this traffic to go to from the AP to the Ruckus Cloud (outside of your network) and then back inside your network to the RADIUS Server. So the AP talks directly to the Radius Server. AP -> RADIUS Server So I would firstly go to the GUI of one of your APs and ping the radius server (just to establish that a connection can be made). Then I would go to your RADIUS Server and confirm that the Ruckus APs have been added as RADIUS clients, previously you probably only added the physical controller as a client. Here are more detailed instructions on how to add new RADIUS Clients: https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-radius-clients-configure

Wow that is a lot of APs to use on a single channel architecture, I'm not surprised you're having issues. Can I also recommend changing the 5GHz channel in 1 classroom as most devices will likely default to the 5GHz frequency. Then you can monitor that classroom and see if your issue is fixed.

Yes that AP in the room should be able to cope with 30 laptops. I think the issue here is that all the APs are on the same channel, Meru does support a single-channel architecture. While a single-channel architecture has its uses a School is not one of them, it just can't cope with the throughput and density that most Schools require today. Are you able to confirm that a single-channel architecture is in use? Can I please ask how many wireless devices (roughly) are in use throughout the school? How many access points do you have in total? If I am correct in the above I would recommend moving to a traditional multi-channel architecture. This would require re-designing your wireless network.

Yes that's right

Assuming you work for a school (this is Edugeek after all) you can get a free access point from Cambium Networks here: https://www.cambiumnetworks.com/cnpilot-free-ap/ You can then configure the AP to have the same SSID and password as your Sky Q device.

I've got quite a bit of experience with Wi-Fi (I work at a wireless focused company and hold CWNA, CWSP and CWDP professional wireless qualifications), so I'm hoping I can help here. I have a few questions regarding your current setup if I may. So with your current system you're getting a dismal 600kbps, how does that compare with your previous Ruckus system? What channel widths are you using? What power setting are you using (auto or a specific value)? How many AP do you have in total? Are you meshing? I'd also like to understand a little more about your environment. Can you tell me more about the walls in your school, are they thick and brick, so they have soundproofing? And how many classrooms do you have? Are you using a 1 AP per classroom approach? Are you need an Airport? Have you or anyone else completed a spectrum analysis of your school?

Cambium and Unifi are both good products. In addition to the free cloud Cambium also offer free telephone/online support and a 5 year warranty.

IMO that's not a fair analysis of what happened. Ubiquiti software was open source and Cambium made a sold a software version that would would enable some Ubiquiti products to talk to Cambium products. The judge dismissed the case before it went to court. Here were his comments: "The disconnect between the broad claims articulated in the complaint, on the one hand, and Ubiquiti’s acknowledgement that the GPL and other open source software licenses limit its rights and therefore the scope of its claims, on the other, makes the scope of defendants’ allegedly unlawful conduct unintelligible." Source: https://law.justia.com/cases/federal/district-courts/illinois/ilndce/1:2018cv05369/355208/59/

A controller is a centralised place to manage monitor and maintain your wireless network. There are many different deployment options for wireless controllers and sometimes that can cause confusion. Here is a very simple breakdown of the common controller types I can think of: Physical onsite controller - This is the first controller ever to be created, one of the drawbacks is that a secondary controller is usually required to provide redundancy. This type of controller still works well and some people like to have a physical bit of tin but in my opinion this design a little old fashioned. Cloud controller - This seems to be the way the of the future, they have redundancy built in and even if your internet connection goes down the APs will continue to function (limited to local resources and depending on vendor some features may cease to work). The drawback is the ongoing cost that some vendors charge for use of the cloud controller. Self-hosted cloud controller - If you have an existing server infrastructure you can host your own private cloud, this acts like a cloud controller without the ongoing costs. This also works well for multi-site deployments for example a multi academy trust. Controller built into the AP - Some vendors allow one of the APs to act as the controller (the AP uses its existing CPU / RAM to build a controller within the AP), this is a good way of saving costs as you don't need any additional hardware or to pay ongoing hosting costs. The drawback is the limited scale and reduced feature set but this would likely work well in a network of 12 APs. All of that said a controller isn't required, most AP's vendors can be configured on a per AP basis. While this can work it's not a practice that I like, if you want to make a config change you have to do it on 12 APs not 1 controller. Monitoring is limited to 1 AP at a time. Also some other services like guest portals can be affected, one example is that users have to re-authenticate to the captive portal when roaming between APs.

Cambium cnPilot certified administrator weighing in here. We've helped to deploy Cambium into lots of Schools and it's been very successful (although we don't actually sell to schools directly). Personally I think it's a perfect fit for Education, their indoor APs come with a 5 year warranty (Ubiquiti APs only have 1 year warranty) and a free for life cloud controller is provided by Cambium (hosted in AWS). Also I encourage you to take a look at the specs of the cnPilot APs, their APs are very well built, Wave 2 chipsets, strong antennas, good CPUs and loads of RAM. Their feature set is quite complete as well, fast roaming (r/k/v), meshing and rogue AP detection are all available out of the box. Although in my experience most schools WLANs are relatively simple in comparison to the feature set of cnPilot APs. Sorry if I'm sounding like a sales person, that's not my intention but I'm a big fan of their cnPilot Wi-Fi solution. Feel free to ask if you have any questions I'd be happy to help if I can. EDIT: Typo

Sent pm