Meraki

GIdenJoe · ‎Mar 17 2022

The bulk of the problems stem from having one or both devices behind a NAT which makes the IKE remote ID a problem if you cannot customize it or do it incorrectly. Also make sure you configure a policy based VPN and not a route based one since Meraki does not support the latter yet.

GIdenJoe · ‎Mar 17 2022

Right back at you (respectfully): Aiming for 1 Mbps on a survey is really stupid. You have to make sure your RF environment can atleast reach 12 Mbps everywhere which isn't that hard btw. Even with your directional antennas which are a great idea inside aisles on 2.4 GHz you can still have too many AP's dealing with too much unnecessary overhead and have too clingy clients if you use 1 Mbps. Having 1 Mbps rate means your clients are already at an RSSI of -78 to -80 which is insanely low. I'm not claiming expertise here but I have done a few surveys and deployments myself in warehouses and have never had any issues with 12 Mbps minimum. My surveys are done with -67 dBm minimum with an offset of -10 dB. Of course I'm talking about newer deployments that use android based scanguns with an 802.11ac wifi chip, not some old windows CE that's hanging together with tape 😉

GIdenJoe · ‎Mar 17 2022

Simple answer to your first remark: Because we assume nobody uses the same channel everywhere we never noticed it on the screenshot 😉 Second if you can't even guarantee 12 Mbps then the survey never was done correctly in the first place. It's not that hard to achieve 12 Mbps especially with more modern Android based scanners. I personally prefer Ekahau over Airmagnet due to lack of development for the latter and in Ekahau you can easily offset your coverage results with x amount of dB or just say it uses mobile device coverage.

GIdenJoe · ‎Mar 16 2022

Oh I didn't realise I still have the original excel file. Here are the calculations for 1Mbps as your situation was:

GIdenJoe · ‎Mar 16 2022

Ok I hope that works for you without too many deadspots. If it does improve and you have deadspots you might want to consider doing a validation survey by a professional. There might be an issue with how the current AP positioning has been done. Btw: without any user traffic you can have high levels of management frame overhead with low minimum bitrates. The screenshot below is from wifi professionals showing the effect of 6Mbps minimum rate: It is even way worse in 1 Mbps but you need the excel sheet for that 😉

GIdenJoe · ‎Mar 14 2022

Ok, it seems like best practices are not followed and you are able to fix alot of the airtime by channging these. 1) if you do not use any 802.11b devices in your network you should be safe to use 12 Mbps as a minimum bitrate, this will alleviate most of your airtime shortage. If you do still have 802.11b then try 11 Mbps. (risk: if you don't have enough coverage you might have more dead spots with higher bitrate but your survey should have taken care of this) 2) try getting more done with fewer SSID's. If you are segmenting onto VLANs using SSID's you're better off using iPSK on one or two SSID's. iPSK couples each pre shared key with it's own Meraki group policy which can set a custom VLAN and this all on one single SSID 😉

GIdenJoe · ‎Mar 14 2022

Usually your power levels should be no higher than 14 dBm on 5 GHz and 8 dBm on 2.4 GHz to kind of have the same coverage area. Your ceiling height is a bit high so you could have made the case for directional antennas. How many SSID's are you transmitting ( no more than 3 hopefully )? How high is the minimum bitrate (12Mbps minimum I hope) Did you check for any non WiFi interference using a spectrum analyser?

GIdenJoe · ‎Mar 14 2022

Hey, If you are used to working with Cisco gear you should know that in Meraki you don't have a real peek inside the inner workings of the gear itself. There are no debug modes, so you can only rely on general logging, your own knowledge and packet captures. Due to being easy and extremely managable you do miss out on features that are almost taken for granted in Cisco gear. Usually when there are some kind of complexities or special requirements you really need to research if Meraki is a good fit because it's quite hard trying to shoe horn your wanted features in if they aren't supported. That said however the biggest positive is the ease of managing your gear from anywhere and the fact that you don't need any extra servers to just monitor your network and clients. It comes with the license. My personal peeves: MX: no support for route based IPsec VPN's, no spanning-tree and port-channel support, no full FTP or other protocols with secondary sessions support. no service objects support (yet), no support for public NAT subnet behind MX (your interfaces need to be in the same subnet as NAT'ed addresses), limited to two WAN interfaces, no ECMP routing on static routes, no switchport monitoring MS: small TCAM memory space causing limited QoS, ACL, Filter-ID ACL support. no strict priority queue, no ECMP routing on static routes, no SFP DOM monitoring, no modern network support yet (VXLAN-EVPN). MR: no explicit state machine monitoring for each connection.

GIdenJoe · ‎Feb 14 2022

I don't think there is one. However once you open the box it should make sense on it's own. The antennas already have a metal ear mounted to it with another one in the box that connects to that one with the bolt. You first take that piece and mark drilling holes if you need to mount to a surface. Then you can join both ears together at the correct downtilt degrees by tightening the bolt. Make sure you always connect one antenna to the two connectors on the top or on the bottom of the AP. Do NOT connect one lead to a top connector and one to a bottom, that is wrong. The antenna wires are quite short so you'll have to mount the antennas really close to the AP. If you're not connecting 2.4 GHz then you'll need to buy N-type screw on caps to protect from dust and water.

GIdenJoe · ‎Feb 4 2022

What I meant was 1 cable between each switch and the firewall and 2 cables between the switches as aggregation. The reason why I do this is because intra VLAN traffic between users doesn't have to pass the firewall if both devices reside on each switch freeing up CPU cycling on the MX to purely pass packets between local VLAN's and the WAN/Internet. Also virtual stacking is a dashboard feature not an actual network feature. Virtual stacking just lists all switchports on one page for awesome simultaneous management of switchports on several different switches. But it does not do anything like actual stacking where you have stacking bandwidth starting at 80 Gbps between switchmembers. So recap: 1 individual port on each switch towards the MX where on one switch there will be a blocked port 2 ports in an aggregation between both switches.

GIdenJoe · ‎Feb 2 2022

The topology you need to look for is indeed like @PhilipDAth mentioned having an aggregation of at least 2 links between both switches. Also you should connect both switches with 1 link towards the MX so you basically have a triangle with two bases. By default because you use an aggregation the link between the switches will not be blocked but one of the links to the MX will be blocked until the link between the switches fails. Traffic by default will travel from one switch directly to the MX for the internet and coming from the other switch it will first pass to the other switch and then to the firewall. Best of success!

GIdenJoe · ‎Jan 26 2022

If the featureset is the same you should be fine. Maybe avoid salt and pepper designs if possible.

GIdenJoe · ‎Jan 26 2022

Ok thanks for sharing your experience @Nordinio . The issue was not happening with windows based clients at that time so it's very specific to certain ways of TLS session building. As a follow up question. I noticed that there was no traffic going towards the cloud from the AP while the client was attempting to authenticate. Is it so that users are stored inside the AP's instead of AP's reaching out to the cloud every time a new auth comes in.

GIdenJoe · ‎Jan 26 2022

Hi, could someone confirm that there possibly was a change in the security policy of Meraki radius on the AP's? I have a customer that works with older scanners that use Meraki radius to join the SSID but started failing since yesterday. An OTA was not possible but I could capture from the AP that the user was trying and thus I only have upstream packet capture. This showed that the scanners associate but stop at the EAP client handshake. I see modern cipher sets but only older TLS versions in use. Could this be it?

GIdenJoe · ‎Jan 18 2022

@Troy360have you made a wireless capture from the AP you're connecting to or an over the air capture through another AP on the same channel. You have to first determine at what phase your sharp device is stuck. A full WPA2 PSK auth would like like this: Client to AP: Auth AP to client: Auth success Client to AP associate (if this is missing client probably does not like association params) AP to client: assoc success or fail (if fail check!, could be some reason code) AP to client: 1st message of 4 way handshake (shows as dot1x even for pre-shared key) Client to AP: 2nd message (this one gets stuck if you have wrong PSK) AP to cleint: 3rd message Client to AP: 4th message Client does the DHCP DORA dance. Do mind that if you capture from the AP you are connecting to you'll only have half of the messages (Meraki issue) It's better to have another AP on the same channel and capture there. Then you'll have the entire conversation.

GIdenJoe · ‎Dec 23 2021

Well the MR advanced is more than only the umbrella integration. It also covers the adaptive policy paradigm. However the intention is that you do not need to integrate with an umbrella portal but you can use the existing presets that can be fully selected on the dashboard. That means when all your AP's have that license you don't need a separate license for Umbrella.

GIdenJoe · ‎Dec 17 2021

Where did you take the captures? Do you have a capture at the source (the client and/or server) and another capture inside the tunnel? Usually your client and the server determine their own window sizes and the network gear in between should not change these values. You could have maximum segment size manipulation but this should not affect your TCP receive windows.

GIdenJoe · ‎Dec 14 2021

Usually if your DHCP works correctly and all necessary ports are open it can still happen that a new device has issues getting it's newest firmware and not fully connecting to the dashboard. After a factory default it usually fixes the problem. Do make sure you have nothing blocking dashboard traffic. Check help->firewall

GIdenJoe · ‎Nov 29 2021

While that would be awesome, I don't see that happening before any official announcement. I.E. don't bet on it.

GIdenJoe · ‎Nov 29 2021

While the graph is handy to have as a quick check, indeed you'll only have alot of interference if you see alot of red in there. Green specs is usage but still low duty cycles. I might wanna think about bringing someone in with an Ekahau sidekick and do some checks for retransmissions when your call quality comes down. Also you have pinpointed the issue to a specific floor so maybe go check there to see how your signal fares there. Also try to determine if it is one client type experiencing the issue or all of them. There can be a huge difference between wifi client chips.

GIdenJoe · ‎Nov 29 2021

32dB not great, are you kidding? 32dB is roughly a -60 dBm RSSI upstream from a client. I find that to be pretty great if all your clients are at that level.

GIdenJoe · ‎Nov 29 2021

Also if you're only using one antenna make sure you are not running dual band on these AP's. And to avoid moisture problems get waterproof metal caps to cover your open N-type ports.

GIdenJoe · ‎Nov 29 2021

As ww has stated if those are mac addresses from wireless clients and you have alot of roaming then you won't be able to get rid of these warnings. Catalyst switches also exhibit this so I guess the default timewindow switches use to determine if a mac is flapping might be too long.

GIdenJoe · ‎Nov 29 2021

So you're 100% sure it are different sites each time the vMX restarts? If there is a pattern please check at the branch locations if you have an intermittend VPN registry disconnections causing a less than stable VPN. Else this is a good reason to have a support case open.

GIdenJoe · ‎Nov 29 2021

Indeed, WAN1 has two interfaces and WAN2 has two interfaces and you have to select which one to use for each WAN.

About GIdenJoe

GIdenJoe

Joey Debra

Community Record

Badges