Hi ww,   That was my assumption and have logged a ticket before we risk swamping our smaller MX's I can see some BGP route sumarisation in the DC teams future. ... View more

Cisco partners are hiring Meraki reps in Moscow, so you can probably expect the sales to begin in next few month. Here's the link to job listing https://hh.ru/vacancy/44334276 ... View more

@Pugmiester I think @m841 is correct, we are running 15.41 and on a VPN concentrator we can simply choose to enable BGP and see the following settings (to be edited to match what you need):   ... View more

I would like to implement something like that. I found this AWS document  https://aws.amazon.com/blogs/apn/exploring-architectures-with-cisco-sd-wan-and-aws-transit-gateway/ Maybe it could be usefull. Best. ... View more

I've had this on the back burner for a couple of weeks for one reason or another but am back at it today. Something I've noticed, and I don't remember seeing before, is that the vMX seems to be performing NAT on the traffic that passing between the subscriptions.   A quick recap, our network in Azure looks a little like this - Sub A > Sub B < Sub C. A and C are VNET peered to B and each have a local route table for our SD-WAN subnets associated pointing to the LAN IP of the vMX in Sub B. Sub B hosts the vMX and is happily talking to our SD-WAN. It's also passing traffic from any client across the SD-WAN through SUB B and onto servers in Sub A or Sub C with no issues at all. Our problem lies in getting traffic between Sub A and Sub C.   What I noticed today is that although I can ping from A to C, the packet capture on the vMX as well as the destination server (tcpdump) shows it being NAT'd and the source showing as the vMX LAN IP instead of the source server. The source server gets a reply so on the face of it connectivity seems to be working but if I hop up the stack with an HTTP connection, the same NAT appears to happen on the vMX and I even see a reply to the vMX LAN IP but then the vMX seems to have no idea what to do it it and the traffic never reaches the initial source machine.   I didn't think a vMX in one armed concentrator mode (that's the only choice you get with a vMX in Azure) was supposed to perform NAT at all. It's really confusing. ... View more

Thanks Philip, will take a look. I'm sure I'm just overthinking the problem. The eventual plan, once Meraki figure out the legal minefield, is to hook them up with a HA pair of MX's like every other site we have in EMEA but for the foreseeable future we cannot legally deploy any Meraki hardware to the country at all so we're stuck with whatever we can legally purchase in country, hoping it can support a reasonable security level, and try to connect that back to civilisation as best we can. ... View more

I had never really looked at or considered a HA vMX setup. Its a VPN Concentrator when you boil it down. Same reason we dont bother backing up the VM in Azure. It is actually easier and quicker to just redeploy it and let the config come back down!   Now the problem with the above is a lack of automation. It can mean downtime.   Something that would be really awesome is a monitoring method that would trigger a redeployment of the vMX through powershell scripts.   I have a good few vMX in the wild, and i have not had a blip on them. I wish they did more, but then, why would you buy an ASAv or CSR1000 for twice the price... ... View more

Nice! ... View more

No, disabling the SSIDs (even all of them) does not actually shut down the radios.  You can also disable the hidden meshing SSID as mentioned earlier, but there too it will not shut down the radios.  Note that on the Radio Settings page, you can turn off the 2.4GHz radio completely.  But the 5GHz radio minimum is 1dBm.  So if 5GHz, sounds like you would need to shut down every-other AP by disabling PoE on the respective switch ports, would probably be easiest & fastest.     However, if you're finding that there's way too much overlap and the APs are all tuning themselves down to only 2dB, and you have a high density deployment, sounds like 500+ devices in the same room, then the best way to deal with that is directionality.  That is, in a HD deployment the primary design priority is spectrum re-use, and the best way to achieve that is with directional antennas.  Pretty standard for auditorium and lecture hall or exhibit floor type of deployments.   If that's not an option and you'll have to use the APs you have on hand, then you'll need to keep fine tuning to find the sweet spot.  Be sure to try using 20MHz channels on 5GHz, go with 12 or 18Mbps minimum bit rates, and only after you've done all the standard fine tuning, you can then also play with RX-SOP, but only do that like 1 or 2dB at time, then re-test.  Leave time between each tweak, and run Update Auto Channels, and give that time to run.  There are built-in delays by design to prevent an unnecessary ripple effect of channel/power changes across the network, so run it overnight for example.   Also, if you're not using meshing, then disable it.  If that option is not visible on the Network Wide > General page, call Support ans ask them to enable that option in your Dashboard.     I'll assume you opened a Meraki support ticket earlier, and they did a scrub of your current config with the model of AP and the firmware it's running, just to rule out any known issues?  You might also try toggling the Client Balancing setting on/off, and possibly band steering on/off which has on occasion caused some strange disconnect issues, but there too, it's a function of AP model/chipset, firmware version, and client device make/model/drivers.  Will take a bit of trial and error to really narrow that down, but Support can assist.     ... View more

Done.  The magnet sculpture would look smashing next to my collection of hard drive magnets... ... View more

Hi @PhilipDAth, I'll ask our server team to double check but there was nothing that jumped out last time. We do have the Symantec AV client installed on all of the DC's, all running the same policy but some happily respond and others don't, but not consistently. MX1 might get a response from DC1 but MX2 doesn't. I'm not 100% certain how to confirm the certificates but is one MX works and another doesn't, I would have thought the certificate was OK. I'm just finding it difficult to find a pattern to be able to poke something with a stick. ... View more

That's the conclusion I was getting to as well. The good news is, we don't have to rip out the Checkpoint to get the MX's live so for a little extra breathing space I can leave the setup as it is initially so we can work out a solution with a little more breathing time. ... View more

Gateway for MX is IP of upstream router. 1:1 NAT Philip is talking about is for servers/workstations on LAN communicating to internet using upstream router's subnets. So... Pretend MX 10.0.0.2 talks to upstream router 10.0.0.1. Server on LAN has IP 192.168.0.100 which NATs to 10.0.0.100. From there setup rule on upstream router to NAT 10.0.0.100 to whatever subnet is available on WAN. Depending on your public IP block, you can give outbound an explicit IP which would be different from default gateway. ... View more

Thanks @PhilipDAth, not a bad idea at all, especially if there's not a big difference in cost to begin with. ... View more