Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 3 replies
  • Subscribers 13 subscribers
  • Views 2076 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Moved AP from XG mgmt to SC mgmt. Seems OK. Suggestions...

Wayne Folta

Switched from XG management of an APX320 to Sophos Central management.  Things went pretty well. A couple of suggestions:

1. It would be nice to be able to bulk-upload static IPs to the XG's DHCP server. When I killed the VXLANs and added VLANs, it was a pain to enter the DHCP static addresses one-at-a-time.

2. One of my favorite things in XG management of APs was being able to see all clients for each SSID, along with signal strength and channel for each. This is very valuable for seeing interference from nearby unaffiliated APs and for seeing poor-reception zones. In SC, you can drill down to an individual machine and see its signal strength over time, which is nice, but you can't see the channel and you can't see across many clients simultaneously.

3. In an online example somewhere on a Sophos site, I noticed that it was recommended to have a VLAN for AP control. A little more explanation of that would be nice. Currently, my AP has three SSIDs: two are guest networks (isolated, etc) and are assigned to VLANs which are in their own Zone, while the main SSID is assigned to a bridge of the AP's port and another port that has a network storage and printer server. This seems to be the equivalent of what was done under the XG management, I think, but I wonder.

4. There was an initial transient bug when I turned off auto channel for both radios (this is an APX320, with both radios set to 5 GHz). It initially wouldn't show the box to manually enter the channels. Eventually, with a little clicking it let me set the channel for the second radio, but not the first. Save and come back and it let me set the channel for the first.



This thread was automatically locked due to age.
Parents
  • 0

    Followup suggestions for SC Wireless:

    1. In Devices, in the main window allow sorting/filtering by AP, SSID, and Band.

    2. In Devices, in the main window add additional columns: a) Channel, b) recent signal strength. This would give an overview of how devices are doing in terms of movement and interference from nearby unaffiliated APs. (I.e. lower-than-expected strength, moving to another channel.) When you add Channel, be aware that the APX320 is a bit different from the rest of the APX's and radio 0 can be 2.4 GHz or it can be the high 5 GHz channels. (The Firewall Wireless gives this kind of information, but it reports radio 0 in 5GHz mode as "2.4 GHz". Confusing at first, but sort of cute once you figure it out.)

    3. When displaying AP workload the phrase "[[ value ]]" appears in it which I assume is a tag that's supposed to be replaced with something else.

    4. The Insights is turned off by default and you get warned that it will cause performance problems to enable it. What is the ramification? Is it still in beta? Or is it meant to be used for limited periods of time without issue, but long-term use could cause problems? Might it fill the AP's RAM and as long as we monitor the RAM we can use it for a while? It's not totally useful to me, though I'd love to see overall traffic levels without specific classifications if that's simpler.

    5. Airtime Fairness warns that the network could become unstable. How so? Does that literally mean that all devices might experience drops and things, or does it mean that older, legacy devices (which are affected by this feature) might not be happy? Or that legacy devices could be unable to receive some data at all?

    6. Packet Capture to Wireshark needs a bit more explanation. In particular, you can set up Wireshark's UDP Listener Remote Capture (via udpdump) for the most efficient capture. You can set UDP Listener to listen on the appropriate port and set the payload to "tzsp" and it works and avoids all of the ICMPs being sent from the Wireshark machine that result if you just capture from the interface and don't actually listen on the port. Plus, you don't need to do a BPF filter, since it's receiving only the packets intended for it, not everything on the interface.

Reply
  • 0

    Followup suggestions for SC Wireless:

    1. In Devices, in the main window allow sorting/filtering by AP, SSID, and Band.

    2. In Devices, in the main window add additional columns: a) Channel, b) recent signal strength. This would give an overview of how devices are doing in terms of movement and interference from nearby unaffiliated APs. (I.e. lower-than-expected strength, moving to another channel.) When you add Channel, be aware that the APX320 is a bit different from the rest of the APX's and radio 0 can be 2.4 GHz or it can be the high 5 GHz channels. (The Firewall Wireless gives this kind of information, but it reports radio 0 in 5GHz mode as "2.4 GHz". Confusing at first, but sort of cute once you figure it out.)

    3. When displaying AP workload the phrase "[[ value ]]" appears in it which I assume is a tag that's supposed to be replaced with something else.

    4. The Insights is turned off by default and you get warned that it will cause performance problems to enable it. What is the ramification? Is it still in beta? Or is it meant to be used for limited periods of time without issue, but long-term use could cause problems? Might it fill the AP's RAM and as long as we monitor the RAM we can use it for a while? It's not totally useful to me, though I'd love to see overall traffic levels without specific classifications if that's simpler.

    5. Airtime Fairness warns that the network could become unstable. How so? Does that literally mean that all devices might experience drops and things, or does it mean that older, legacy devices (which are affected by this feature) might not be happy? Or that legacy devices could be unable to receive some data at all?

    6. Packet Capture to Wireshark needs a bit more explanation. In particular, you can set up Wireshark's UDP Listener Remote Capture (via udpdump) for the most efficient capture. You can set UDP Listener to listen on the appropriate port and set the payload to "tzsp" and it works and avoids all of the ICMPs being sent from the Wireshark machine that result if you just capture from the interface and don't actually listen on the port. Plus, you don't need to do a BPF filter, since it's receiving only the packets intended for it, not everything on the interface.

Children
No Data
Unfiltered HTML