If the traffic was sourced from an IPv6 client and WAN2 does not have IPv6 then it is pretty logical it could only use the only IPv6 interface available. If you would test on a client that is IPv4 you should see traffic going out the WAN2 port.  Try temporarily disabling IPv6 on the LAN or on your client and test again. ... View more

Having a vIP is the better option since it smoothes out a failover between primary and spare and allows for port forwards to remain on the same IP.  However it is not a requirement.  In my opinion it is better to have a vIP that is private and NAT'ed than to have physical IP's and not NAT'ed. ... View more

Niiice 😉 ... View more

Using non-Meraki VPN's to tunnel all traffic will most probably not work.  You need to define specific local and remote networks for this. AutoVPN is a different beast.  If you set a default route on a spoke to a hub you can tunnel all local traffic over that for local networks that are subjected to the VPN tunnel.  In that case you would have to tunnel to a Meraki hub that then has a default route to the internet where you can allow or deny traffic using those other technologies. ... View more

You can manually put Meraki group policies on devices that are on Wi-Fi or have to pass an MX.  In case of Wi-Fi you can effectively block them from gaining any access to the network.  In case of MX you can only block their traffic from passing the MX towards other VLAN's or the internet but you can't block local traffic if they are on switches.  Not sure what happens to clients that are on an MX68 direct LAN ports though. To have these kind of blocks you'll need to deploy 802.1X access policies on the switches or try to work with manual port security. ... View more

You don't have a choice.  If you use 2 WAN interfaces you need to have both of them on physical or vIP. Usually if your second provider uses NAT behind it's routers you can use a vIP there too like a 192.168.0.10 for example. ... View more

If you are sure your routing is ok and you did the capture correctly and not see anything on UDP port 1812 leaving the switch, then you should capture the EAPoL frames on the port.  Your supplicant might not be sending EAPoL frames to the switch. ... View more

So if you do the capture on the MX you would have to see it on the LAN side and in the site to site side if you are doing an AutoVPN to Azure.  So then you should also see the packet on the vMX. So if you're are not seeing any packets you have a policy or routing issue.  That means the interface of the switch can't reach the NPS server.  So you'll have to check if the subnet of the switches is included in the VPN and all routing is correct. ... View more

That would be extremely weird since the switch is only encapsulating the EAPoL messages inside Radius and decapsulating in the return.  It does not matter what kind of EAP protocol you are using between the supplicant and the authentication server.  The only thing the switch needs in the end is an access-accept with potentially some AV pairs. ... View more

You're supposed to do a packet capture on the switchport leading to the NPS server while filtering on UDP port 1812 just to see if the access-request message is even reaching the NPS server and if a response is sent back. If you have to do a dashboard capture then you will have to coordinate a test while capturing. ... View more

That's strange because the whole reason the UDP/4500 header is added in front of the ESP header is to get through NAT since NAT on most devices only supports TCP, UDP and ICMP.  The only reason you would get an ESP header right behind an IP header if the two VPN endpoints can reach each other without NAT unless for some reason NAT-T was disabled but then it would not be able to pass through a NAT.   So if you had an MX without NAT then you would never be able to match purely on ip protocol 50 or 51 since that is not supported on the MX.  You would have to allow all IP traffic towards that destination. ... View more

If a device is behind the MX it would be NAT'ed which means the IKE negotiation is done with UDP/500 and the ESP would be encapsulated within a UDP/4500.  So you could match this. However if you would have disabled NAT for this specific then it would send direct ESP behind the IP header and would only match in a rule with Any as protocol. ... View more

When you do a packet capture on port 1812 you should see access-request packets being sent from the switch and access-challenge back from the NPS server. So first make sure the messages reach the NPS server and see if the server responds. If the server does not respond then you will need to look purely at the server (are the switches present in the radius clients configuration?). If you are seeing access-reject messages from the NPS server then you are probably not matching an access rule. There are many more issues but at least start with the basics. ... View more

As of now the tunnels are policy-based VPN tunnels, so no VTI. Tag based failover is the only way for the moment. ... View more

You can use BXD SFP's on Meraki managed/monitored Catalyst switches but on native MS switches it is NOT supported.  The choice of switch is not fitting for this requirement. ... View more

You should be able to have a rough estimate how much bandwidth you could have using 20 MHz by using a taking the average PHY rate of all clients you expect to be connected to the AP and then taking about 2/3 to 1/2 of that as actual goodput. However the best thing you can do is allow for a few testing days of normal usage and just check the AP's of interest what their average airtime is.  If you keep below 50% in heavy use you should be fine using 20 MHz. ... View more

Nuff said 😉 ... View more

You may have a bad cable or the QSFP is not seated 100% inside the slot. Maybe try switching around your cables and see if the problem follows the cable or not. The speed should also be 40 Gbps. ... View more

Jep that does look bad :s It does not make sense an AP would choose 40+44 or 44+40 since that effectively causes problems for channel 36 and 48.  This would only make sense if channel 36 is disabled in the RF profile but this does look like bad behavior in the algorithm. ... View more

It has to do with the way the channels are displayed. When you select your channels in the RF profile you get like "in between" channels if you look at the 40 MHz and the 80 MHz lines. However what happens in effect that your have a primary 20 MHz channel + a secondary channels.  So 36+40, 44+48 etc etc.  Primary channels are used for all mgmt and ctrl frames and only the full 40 MHz is only used during datatransfers if your client supports it. The problem you do have to look at is that you don't have any overlapping areas where the primary channel is swapped.  You would risk more collisions when you have 2 BSS'es where one is 44+48 and the other is 48+44.  This will cause issues because channel looks clear during mgmt and ctrl frames and then collide during the data frame transmission. I also found that the auto-rf sometimes still uses a channel that has been used even within range so while it is working it is not perfect and needs checking into.  I'm hoping the new AI-RRM with the use of NDP will improve this. ... View more

I would still push the support engineer to escalate internally. This is too big of an issue to just leave it alone. I'm also curious what the technical reason would be since those switches still are regular C9300L's. As an engineer for an MSP I'm always looking for detailed information. I also recently had to ask the question about cross compatibility between BXD SFP's and C9300-M and regular MS switches.  Luckily I got an answer there before committing to a buy. I do feel your pain, damn... ... View more