White_Fi

You don't have some software offering out DHCP on your laptop do you? It is unheard of for 1 AP let alone 3 all doing the same?

Yes it should do unless the reset isn't performing correctly. Try again for 15 seconds in the pin hole. We may need to RMA this AP but I have never seen an AP that won't FR correctly. Odd one.

I see. Sorry i assumed that since the AP was not on default it was getting it from DHCP.. this is odd then. can you login to the AP with the ZD admin / password?

But the AP is still plugged into the network. So it will FR then DHCP request. It will also broadcast for a ZD. So either: 1) Keep AP on network... Go to ZD - config - access points - and disable AP auto join. Then FR AP and webgui into 10.42.0.1 and load standalone FW. When FW upgrade is complete either approve AP in ZD or enable AP Auto join 2)Get AP off network - Plug cable into laptop with IP 192.168.0.5/24 will do. FR the AP and browse to 192.168.0.1 and load standalone FW. When complete plug AP back into network. - - - Updated - - - 9.12.x is likely to be last release the 7363 will support.

The AP will be under ZD mgmt then. You can login with ZD admin credentials but you wont be able to load any firmware until it has been factory reset. If you want to keep it on the network and not isolate it for the FW upgrade please disable "Approve all APs automatically" under Configure - Access Points on your ZD then FR the AP. Or just FR it off the network without changing this ZD settings.

Sounds like it hasn't been factory reset... or if it has it has been reset and plugged into a network with DHCP. Can you web browse to the AP via that IP and load standalone AP software on it? You may need to factory reset and take off the network as it may be under mgmt from your ZD... which we want to avoid until we have a newer FW on it.

I can see the AP sending out for DHCP requests so it looks like it boots normally. If you can't ping it on 192.168.0.1 after a factory reset (pin in the hole for 10 seconds whilst powered) I would suggest requesting an RMA / RTF from Ruckus. Ensure that your adaptor is in this subnet and you are using a standard cat5 cable. Thanks

If the new VLANs are working in most parts of the school then it's safe to rule out your Ruckus configuration (unless you are using AP groups with overriding VLAN tags) and your core switch. I would focus on looking at the edge switches in the locations of failure. Does the client fail to obtain an IP address if you use Ethernet and untag the VLAN on a port at the edge? Double check that the VLANs are untagged (trunked) on the uplink ports. Thanks

Best setup would be to have the ZD and APs in there own VLAN or an existing mgmt VLAN. The switch ports should be untagged (native) on this VLAN and tag on any VLANs you wish to carry over the WLANs. It is not necessary to have the ZD switch ports also tagged with your WLAN VLANs unless you want to make use of the Bonjour Gateway feature on the ZD.

The ZD3000 is fine but I would consider upgrading the AP as the 7363 are EOL and 9.12.x is going to be the last supported revision for the APs. High-end smartphones and tablets do have 802.11ac chipsets and some are even MU-MIMO ready, such as the Galaxy S6. Samsung are likely to capitalise with releasing a new phone rather than enable the feature on the current handset but it shows "wave-2" ac features are out there and ready. With that in mind the question is do you go "wave1" with the R5/6/700 or straight in with the R710 "wave2" to support, in my eyes, the only big 802.11ac features that makes sense in an enterprise wireless network: MU-MIMO. And that feature is a game changer for wireless capacity in general.

There are bug fixes in 9.12.1 that fix watchdog timeouts for the 7363 APs. It is still recommended to free some memory up ont he AP by disabling IPv6 (if not in use) and disable NTP

Yes the 7363 is supported on 9.12.1.0.140. However, I believe 9.12 may be the last support release for the 7363 AP. Thanks

Great thank you. First i would recommended upgrading the ZD3000 to the latest 9.12.1 FW as it does contain not only AP bug fixes but captive portal fixes. When newer devices are released (Android 5.x for example). Google changed the way the device handles the captive portal. The newer Ruckus ZD code also contain changes to its Captive Portal engine in order to support newer OS'. You will need to upgrade to a flavor of 9.9 before continuing to the upgrade to 9.12. As always, save the config backup file the ZD will offer you when you upload the fw .img file. Regards

Hello, Could you let me know what ZD version and firmware is running on the ZD and what AP models you have? Many thanks

Hi gmbaxter, iBoss is focused around scale-ability and the standard appliance that we supply for secondaries is good for up to 10,000 users. Further more, being a gigabit capable layer2 network bridge it doesn’t have the bottleneck issues of proxy based devices, so you will only need the one SWG box. Let us know if you’d like us to setup a web or onsite demo for you.

Id suggest trying the downgrade via CLI. Use putty or similar to SSH in and upgrade/downgrade the FW using FTP or HTTP. If you'd like feel free to send the config file over to us. I'll have it brought up to compatibility with 9.7

Glad to here it. Always happy to help. Are you trying to downgrade your ZD1100 directly to 9.3? Here is the suggested downgrade path for you ZD1100 on 9.7.1.0.32 9.6.2.0.13 > 9.5.3.0.44 > 9.4.3.0.22 > 9.3.2.0.3

Yes the ZD1100 has also recently been announced EoL. Support will remain on the box until June 30th 2020

Hello Aqua, I'm not sure why the reseller had claimed that the R500's were not compatible with the ZD1100 as they are very much compatible. However with that said lets take a look at the config backup / import to the new ZD1100 model. The ZD1100 does support a lower version of code that such as the latest the 1000 can support (9.4). I have been made aware of some bugs when downgrading the ZD1100 and not using a particalar downgrade code pattern. Can you please let me know here or via DM which version of code is currently on the ZD1100 so i can suggest the best downgrade path and methods for the ZD1100. The alternative it take the back up the ZD1000 anyway... send it over to me and i will bring one of our lab boxes down to that code. Import your config and bring the ZD code upto your chosen code ready to import on your box.

Ah, thats the issue then. By default the ZD does the mdns proxy so it needs to be aware of the vlans. Get the vlans tagged on the switch ports and you should be ok.

Yes you are correct, the ZD will act as an mDNS (bonjour) "proxy" for multiple layer2 subnets/networks what ever you want to call them(VLANs - multiple layer2 networks on the same switch). The ZD will only act as a proxy for the mDNS traffic which is layer 2 so you must ensure that you have layer3 routing between the vlans for the service traffic to work after discovery. The ZD will not route the traffic only make the Layer2 discovery traffic available from 1 VLAN to another. Since the discovery isnt working I suggest you enable the bonjour rule on your ZD bi-directionally. VLAN 7 - 1 and VLAN 1 - 7. Make sure you have the correct apple service as well.

Have you tried reversing the Rule, so from 1 to 5? It would seem you need the iPad (VLAN 1) as the from VLAN and ATV (VLAN 5) as the to VLAN

This is true but discovery would still work as mDNS is Layer2 and the ZD will be forwarding that request. It would stop working at that point should no Layer3 routing be available. The first place to check would be the correct VLAN tagging and configuration on the ZD such as BJGW enable/ setup and that the WLAN is not dropping MCast traffic.

OP: As mdrabble has stated; have you got the VLAN tagging correct? When doing BJGW on the ZD the ZD needs to be able to throw traffic into those VLANs. i.e the switch port the ZD uses must be a Trunk port with the relevant VLANs tagged. This will allow the ZD to proxy the MCast traffic (which is Layer2) it will not, however, route the traffic once the discovery between devices has been established. The VLANs Gateway or other Layer3 device will do the routing between the VLANs. The second part is that when both devices are in VLAN5 you are still unable to to discover via mDNS... Is there anything dropping multicast packets in this subnet? There is a setting on the ZD to drop MCast traffic on WLANs.. My guess if there is nothing else dropping the MCast traffic then you have that enabled under the WLANs (VLAN5 WLAN) advanced settings.

What firmware are you running?