This can be done without any downtime, but it depend on the neighbouring device of the MX. This is the way to go: Activate OSPF on the MX and on the connecting router. When the neighbour device has learned the OSPF routes you can remove the static routes. Migration completed. You hopefully know that the MX will only advertise VPN-routes but not learn routes? https://documentation.meraki.com/MX/Deployment_Guides/VPN_Concentrator_Deployment_Guide
... View more
Then I would suggest: 2*MX (any actual model, AdvSec License) 2* MS with routing capabilities 2* MR (any actual model) 1* MV (any Gen2 model) some SM licenses Yes, will be expensive just for a lab ...
... View more
I would say that it is a normal situation for all customers that migrate slowly to Meraki. Always when a Switch needs a refresh, it is replaced by a Meraki switch. I have done it both where the core was migrated first and also where the access is migrated first. Some migrations were more challenging than the others, always because of STP. That always needs good planning and some testing.
... View more
Adding to what @ww said: The final "exam" at the end of the on-demand-learning is to prove that you really worked through the course and you also qualify for CE points. The "real" exam is for the CMSS certification.
... View more
Sadly, the dashboard doesn't tell us which firmware is running on the device, only which firmware should run. I also had situations where things didn't work and Support told us that the device was running an old version although it showed the new version. Here Meraki is definitely hiding too much from the customer.
... View more
Tip 1: Use the photo-upload feature to document at least all your APs Tip 2: (contrary to others here): Only use templates if you really understand the drawbacks and limitations of them. Also think about the API as an alternative approach to templates Bonus Tip: Always use MFA with any cloud dashboard out there.
... View more
If there are peers using NSF, it should not cause any trouble if it is enabled on the core. The NSF-capable switch will see that the MS is not capable and just ignore this feature. Still, I would disable anything that is not needed.
... View more
I never heard of Meraki supporting NSF. So I took a short capture of an OSPF hello from a Meraki switch: No option for this extension. I would keep it disabled on the core.
... View more
I am not aware of any customisations. But I assume that letting the MX doing this job is likely not working as there is no TLS inspection on the MX (at least not as general availability). I would go with Cisco Umbrella where you can both customise the block pages and also provide a block page for HTTPS blocks.
... View more
Scenario 1: Yes, the L3 rules are only for internet- and inter-VLAN traffic. For AUtoVPN, you have to configure the outbound filter under S2S-VPN. For extranet-VPN you can't filter the traffic on the MX. You need to use a different firewall for your extranet VPNs. Scenario 2: There is role-based access-control to assign differentiated access to your networks. You have to decide if these fulfilled your needs. At least you can restrict on a per-network level.
... View more
Are you talking about the content-filtering features of the MX? These are not used in this scenario. I would go for Cisco Umbrella in this use-case.
... View more
I also eagerly want them. Most of the time we have an additional ASA side by side for all extranet VPNs, same as @DarrenOC. Well, not all customers, some time ago a potential customer completely decided against the Meraki Fullstack because he thought we want to fool him with that approach.
... View more
The meaning of the base rulesets are also explained in the Snort-FAQ: https://www.snort.org/faq/why-are-rules-commented-out-by-default I remember a discussion here that also the MX implementation is mostly (but not completely) aligned with this definition. But I don't find that at the moment.
... View more
