Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About 80211WiGuy
Community Record
14
Posts
1
Kudos
1
Solution
Badges
Mar 29 2022
7:53 AM
Hey Gang, During my first deployment of 8x8 Radios in 2020 with the MR55, I noticed something concerning about the APs that had selected any channels in UNII-1 (36-48), they all had their Tx Power limited to 12dBm max. After scratching my head for a while and doing some further digging I realized that this was the max tx power that could be used by TxBF on an 8x8 radio to match EIRP regulations in Canada. https://semfionetworks.com/blog/industry-canada-new-5ghz-band-regulations/ It was a weird time, city was under isolating measures and very few people were in the office, but I was concerned. This meant that while client directed frames would benefit from TxBF, management and control frames would go out at 12dBm without any TxBF. I was concerned this would lead to client roaming and stability issues, opened a case to discuss with TAC but eventually had to settle for this just being the way that Meraki was interpreting the regulations and deal with the 12dBm limitation. It was a bit of an "agree to disagree" scenario. The site design was performed with 14dBm as the target power. As predicted, we're seeing a lot of unstable client connections and roaming attempts in areas where UNII-1 channels have been assigned by AutoRF. I suspect this is due to the client drivers relying on beacons for their roaming decision process but who knows what's in their secret sauce. I'm wondering if there's anyway to drop the MR55 down to 4x4 operating mode when on UNII-1 channels so that the Tx Power can be raised to 14dBm at least. So far someone had the bright idea that maybe dropping the PoE power down to 802.3af might trigger that but I wish there was a supported solution for this issue. Losing a block of channels also poses capacity issues but it may be the only option we have on this. Any professional insights and shared stories are welcome. Has anyone else struggled with low power limitations on 8x8 radios yet?
... View more
Labels:
- Labels:
-
Other
-
RF Spectrum
Jan 29 2020
6:14 AM
Thanks, 95 stuck in my mind as something familiar. -95dBm is the starting point for the RX-SOP slider in an RF Profile. I'm guessing -95dBm is also Meraki's min receive sensitivity.
... View more
Jan 14 2019
1:41 PM
I'm with you, not sure either. I just did a test and "Any" seems to include ICMP as it's allowing it on explicit allows but denying it on my 10.0.0.0/8 deny. I think I might have gotten mixed up on my original statement, I thought ICMP TTL Exceeded was coming back from the transit links but it seems to have stopped now. I must have made a mistake my original ACL.
... View more
Jan 14 2019
1:13 PM
Thank you, I totally forgot about that! Am I right to assume that the ACLs only work against TCP/UDP and not ICMP or other L4 protocols? Also, I was trying to prevent IPv6 on the network but IPv4 stopped working when I tried a "Deny IPv6 any any any any" rule. Is this something I should dig into with TAC?
... View more
Jan 14 2019
12:51 PM
Soooo while trying to restrict all clients on my campus network to access for the internet only, I did something dangerous and created an ACL that should have broken OSPF Routing on my network. Deny IPv4 Any 10.0.0.0/8 Any 10.0.0.0/8 Any Any In theory, this should block all private addresses (I'm only using 10.0.0.0/8) from talking to each other across VLANs. But then I realised, my transit links should have stopped being able to send/receive OSPF hello messages due to this, but they're still up. In addition, clients are still able to see each hop along a traceroute. In theory the ICMP TTL Exceeded messages should have been dropped also. Are there some additional nuances to how ACLs work which might not have been documented?
... View more
Aug 13 2018
7:36 AM
Also, I strongly disagree with that article and Meraki should consider pulling and rewriting it. I have a feeling the support department probably has a hard time explaining to customers why they cant achieve application throughput that equates to even half the transmission rates listed in this article. It's titled "Wireless Throughput Calculations and Limitations" and does not speak to throughput, it's specifically talking about transmission rates which do not compare to throughput at all. "Theoretical throughput" isn't an accurate statement either as it does not account for known mac layer overhead, inter frame spacing, etc. The "throughput" listings are not throughput, they are raw transmission rates based on MCS and # of spatial streams. My apologies if the wording above sounds a little harsh, it's not my intention to be rude. I'd just like to see more non-expert vendor communications that explains the difference between WiFi transmission speeds and what a user would consider actual throughput.
... View more
Aug 13 2018
7:28 AM
We used 40MHz exclusively, no 80s. I'm not sure you can even configure 160MHz in the dashboard right now (I understand why you'd want to prevent customers from doing this).
... View more
Aug 13 2018
6:46 AM
We own the speedtest server that was used during testing. Also confirmed no congestion along pathway from customer to server. Speed tests from 1Gbps wired client connection were 940/940.
... View more
Aug 13 2018
6:17 AM
1 Kudo
Could be mounting height and/or heat. Heat actually raises the RF noise floor in 2.4 and 5GHz, the AP might be rated to operate at higher temps, but no AP can operate well at high temps - it turns into an RF physics problem. The long dipole type antennas commonly used on outdoor APs typically squish the signal into a flatter pancake than most. Outdoor APs are also commonly placed too high for their attached antennas. Its possible that your AP may be high up enough that your missing the main coverage lobe from the antenna, giving the birds great signal but not the users down below.
... View more
Aug 13 2018
6:12 AM
I think RX-SOP actively drops connected clients at the the set threshold and will still back off the channel if energy detect is triggered. It's more useful for high density environments and forces clients to move to the next available AP. I don't think it will improve this situation.
... View more
Aug 13 2018
6:00 AM
I understand the differences between WiFi and Wired speeds. Is there anything specific you would recommend testing against to determine the cause of the significant difference between downstream and upstream throughput?
... View more
Aug 10 2018
12:30 PM
Hello, After a full deployment and site survey ensuring no CCI, I recently ran some speed tests for a client on their new deployment of MR53 APs. The APs have been deployed with 40MHz channels and the ones under test had no other clients associated. On an iPhone 8 (2x2 802.11ac) the application throughput was 150/300Mbps(down/up) give or take a few Mbps at each location. I'm assuming this could be Airtime Fairness in action but I want to confirm before reporting this to the client. It's my understanding that it's possible for the AP to control downstream traffic but not upstream which is what would make sense to me. I'm just a little skeptic as to why the AP would be reserving airtime resources with no other clients connected. Haven't had a chance to test this any further, time on site is limited. I hate including speed test results with reports because it tends to overshadow the capacity and reliability aspects of a good WiFi deployment, but I'm not able to dodge it in this case. Just hoping I can accurately explain to the customer what's going on.
... View more
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 4206 | Aug 13 2018 6:17 AM |
© 2024 Cisco Systems, Inc.
