If your ceiling is only 70 meters long and putting that AP in the middle will create a 35m radius that needs coverage. If the aisle itself is obstacle free you would have no problem reaching both ends using simple MA-ANT-20 antennas. Using the MA-ANT25 on hight ceiling is also a viable option but 5 meters is not really that high.  In that case you'd be better off hanging it on the wall pointing down the aisle however you need an actual wall and then you'd have the entire 70 meters to cover.  And the MA-ANT25 is IMO a little too wide and too little gain to do this.  In that case the MA-ANT27 would have been better since that one has higher gain and narrower beam. The reason to discourage the antennas in different directions has to do with the fact that you would get strange results.  The Meraki AP has 2 radio's, one for 2.4 and one for 5.  So theoretically you could have a 2.4 cell in one direction and 5 in another but that does not make sense.  Also trying to extend your cell by cross connection your antennes will have weird results since the AP will try to to spatial multiplexing or ratio combining to your wifi client.  However if both antennas are pointed in different direction that will yield in possible destructive signales instead of constructive. So if it's only one aisle. Stick to the center and use omni's pointed vertically.  Make sure the antennas have complete clearance.  If you have multiple aisles then you'd normally stagger the AP's, so one at 1/3rd of the way in one row, and the next row one at 2/3rds. That depends on the situation though. ... View more

Nope, that connection is wrong. You have radio's that expect two spatially diverse antenna's to do 2x2. By connecting the antennas that way you basically create two independent 1x1's and this will cause problems. Connect one antenna to both 5GHz ports and the other to both 2.4GHz ports. ... View more

I got it mixed up: It's when your route comes from another source than BGP and is preferred over the BGP route it only displays the preferred route source (like VPN peer). ... View more

The routing table view will only show the RIB. So only the selected path will be in there, not the alternate paths. It will however display internal BGP as route source. So there is no show ip bgp/ show bgp ipv4 unicast equivalent. And there will be some weird IP address as hop between hub and spoke beginning with 6.something.  I believe this subnet is created inside the AutoVPN tunnels to allow BGP messages to flow between all BGP speakers. ... View more

I'm no expert on the matter but the basics things I know: 1) Your clients will be configured through intune with the SSID to connect to using WPA2-Enterprise and EAP-TLS and the correct certificate to use.  Also if it's using machine or user auth or both depending on login screen or logged in. 2) When the client connects the AP will transmit the radius attributes service-type:framed (for dot1x) and a called-station-id which contains SSID and AP MAC address.  The client will also transmit it wants to do EAP-TLS. 3) The NPS server would have been configured with: A list of IP's or radius clients (the AP's) or a subnet where the AP's live The policy where it matches on service-type framed and called-station-id containing the SSID, and EAP-TLS as auth method. The fields to look at in the certificate mostly common name and the attributes containing the AD group. 4) NPS sends it's cert to the client which is signed by the same CA, so the client trusts the NPS server 5) The client sets up the TLS connection and sends it cert over it containing all necessary fields 6) NPS evaluates and sends access-accept with attributes or access-reject if something is wrong If I'm mistaken somewhere, please correct me 😉 ... View more

Yep, the spokes choose their own priority by configuration of yourself. And the upstream DC devices just need a route back to your spokes pointing to your MX in the DC. The BGP solution is more if you want to vMotion between DC's and have the ability to go through the interconnect if needed or directly down to the spokes if needed.  Or if those routes go beyond the datacenter into the ISP where traffic can be routed through either DC depending on the spoke to reach. ... View more

Not sure Meraki supports /31 subnets.  You could surely use /30 but if you ever consider HA pairs then you'd need /29's.   You would not need any routing to the internal subnets on the router because the MX box'es NAT all traffic going to the internet via that link.  And the AutoVPN is tunneled OVER that WAN address space.   So to recap once more: You could have 2 WAN subnets behind the router, each serving as a point to point subnet between MX hub and router and also MX spoke and router.  If that router then further uplinks to the internet you will have following traffic patterns.   Hub internet traffic leaving WAN1 comcast will be NAT'ed to the comcast uplink. Hub internet traffic leaving WAN2 would be NAT'ed to the small subnet between Hub and Router (say for example 10.0.0.2/29) and then routed to the internet and be NAT'ed again.  If double NAT is not your cup of tea you'd need public subnets between MX and router instead. Hub local traffic going to spoke will be policy routed between both VPN tunnels.  So in case of going over comcast the UDP encrypted VPN traffic will just go over the internet to the spoke MX. Hub local traffic going to spoke via the MPLS will first be encapsulated in VPN then go to the router, the router having both WAN subnets will just route between interfaces and will send the traffic over the MPLS to the WAN interface of the spoke MX. I hope this clears it up a bit? ;D ... View more

You should use the powershell command Add-VpnConnectionRoute.   If you add a bunch of VpnConnectionRoutes to an already defined VpnConnection those routes will only be added when the VPN is dialed. ... View more

That is certainly not a recommended topology. If you're doing Concentrator HA mode each MX must have it's own IP in the same subnet as the virtual IP and the upstream router. You should also not have too much latency between both sites since VRRP hellos need to be succesful all the time. If you only have 1 layer 2 link between the sites and that one goes down you'll effectively have a dual master scenario where routing towards your inside IP's will be indeterminate.   Using MX'es in VPN concentrator mode is usually intended for datacenter designs where you can have the same address space across multiple datacenters.  But then if you do HA both MX'es are on the same location. So is there a reason outside of not wanting to pay another license why you'd want an HA pair over a longer distance link? ... View more

So those 2 VLANs are meant to be routed subnets for your two MX'es? Do those 2 VLANs exist behind the router? I'm confused about about your drawing because it does not provide enough data about the subnets and the router. 1) You should be consistent with your internet connections, so on both MX'es put them on WAN1 or WAN2 but not mixed. 2) I'm guessing one of those VLANs exist behind the router as an uplink to the router to go to the internet via that MPLS provider.  So if it's only one VLAN behind the router you'd need that VLAN subnet to be /29 or lower so both MX'es and the router can have an IP in that subnet.  And that VLAN needs to cross the link between the sites.  If they are 2 separate VLANs for each site one. Then you can go with a /30 and have both MX'es in a separate VLAN and subnet with their WAN connection.  Then only that VLAN needs to match with the VLAN crossing the link to the other side. In both cases you can have a full SD-WAN as long as you have the two VLANs at the router. ... View more

As I understand it you simply don't have an internet connection at the remote site. You can't have an MX there if you don't have an internet connection. To be able to use the full SD-WAN you'd need an internet breakout on that MPLS circuit. Since that's not the case you could however do the static LAN route over the MPLS circuit by defining a small subnet that is common to both main and remote and point to each others LAN subnets via that small subnet and make the route conditional to a ping to the other side. But then you'd need an internet connection on the remote site to have an MX link to the internet and build an AutoVPN between the MX'es on both locations.  However that VPN will only be used as backup if the MPLS would have failed. ... View more

Ok, that makes sense. So the reporting you see in dashboard also will only mention the best uplink's status. So it will continue to show the WAN1 connection to multiple registries using public IP while the other uplink is behind NAT. ... View more

That can be a bit confusing if you also deal with Cisco AP's because some of them have the XOR radio enabling them to point to antennas in different direction because the extra radios is also set to 5 GHz and puts all it's spatial streams on one antenna for radio 0 and the other antenna for radio 1. If you go to Cisco Live events you can see the setup like that. ... View more

From your end you could try a factory reset with the pin in hole solution for 20 seconds.  Sometimes that retries the whole process that could have been stuck. If that doesn't work then you'll need to open a case and the Meraki support agent will change some backend parameters and the switches will magically work 🙂 ... View more

Non Meraki VPNs use ESP tunnel mode encap. However Meraki VPNs encrypt their packet directly under UDP. Screenshot below, mind that 10.10.10.x is the actual WAN IP of the MX but it's behind a NAT.   ... View more

OK thanks for clarifying that 🙂 ... View more

Afew important considerations you need to make: For HA MX'es don't forget your WAN1 and WAN2 on both appliances need to connect to the same respective upstream ISP circuits. So you'll need to have one ISP come in building 1 and connect that one first on the switch there on an external VLAN and then have two ports connecting to both the WAN1's of the MX'es, so the third link will also be going over the fiberlink.  And then the reverse of ISP2. That one will connect first to switch 2 and then back up to the MX'es WAN2. However I'm considering you might need separate links from the switch to the MX on the other side.  There are some fate sharing scenarios that could lead to black holes.  Hmm this setup needs to be thought through. Secondly you will have a blocked link due to spanning-tree with this design. Alternatively but way more expensive is doing a pair of 425's with flexible stacking so you can have both downlinks forwarding at the same time ... View more

I would personally consider it a lost investment. As said before.  I would position Meraki go to anything bigger than a single small office or store or restaurant. The moment you realize they probably would grow beyond a single building or are considering some cloud service or having the need to VLAN off certain traffic I'd immediately go the regular Meraki gear. I know it is a bit expensive but not quite as expensive as Cisco gear (exception for mobility express/EWC access points).  Once the customers realize how easy the regular setup is they usually bite.  Be mindful of pitfalls like unsupported features.  Meraki is easy but don't try to squeeze it into positions it's not meant to or you'll have some trouble 🙂 I even have small business owners that just buy Meraki gear for their homes. ... View more

Well, you should get it to work if you don't over complicate things. You'll need to use IKEv1 for the exchange and only policy based VPNs are supported. The Meraki side will need to be configured as Hub. You cannot have traffic going through a non-meraki VPN and then through Auto-VPN.  Each Meraki peer needs a direct non-meraki VPN connection to each remote peer. Try to use as few traffic selectors as possible. Rather use a supernet than use individual subnets if you can. Because there sometimes are issues where a tunnel is basically up but one of the Child-SA's is not and you have to bounce the entire tunnel to get them all back. ... View more

Greetz fellow Belgians, West-Vlaming here.   I wouldn't personally use Meraki Go on anything larger than a shop/restaurant/single office basic company. It's not really meant to use as an MSP and even VLANs are not even fully supported. We also have alot of smaller customers but they usually end up with MX67 appliances with MS120 series switches and some MR33's soon to be replaced by MR36 deployments. ... View more