Hi @JinSoo_Park ,   I'm sharing here what I found after looking at your support case.   1. Your ticket covers mostly MX High Availability (HA) a.k.a. Warm and Spare ; the failover behaviour in HA isn't directly related to IPSec VPNs. 2. In your use-case, your primary MX is running firmware 19.1.11; therefore, multilink isn't stable here. Multilink requires 19.2.2 3. In your use-case, MX would have one active tunnel at a time. The other tunnel endpoint would be established but in standby mode. 4. Refer to this document. It explains tunnel failover feature and scenario and how health-check triggers tunnel failover. 5. Like you said, a health-check probe getting 404 would flag target as down and result in tunnel failover. As per above document, "“Down” means that the most recent probe has failed (ICMP unreachable, TCP reset, HTTP 4xx or 5xx code or similar) or timed out (packets lost) after 10 seconds." 6. [most important in my opinion] If possible, run firmware 19.2.2 even though it's a Release Candidate (RC) if you want multilink (active-active). Or even better, run 19.2.2 RC and BGP peering to AWS VPN and TGW with BGP rather than static route. Doing this would allow you to disable health-checks and just rely on BGP timers to detect tunnel and peer state. This ultimately prevents incorrect failover due to health-check 4xx or 5xx status codes. Another advantage is you don't need to manually update TGW route tables because BGP would auto-propagate any routes back to on-prem that VPC would need. Hope this information is useful. Feel free to post here further questions / concerns.   ... View more

I would suggest looking for alternatives to SM sooner than later which gives you plenty of time to migrate to something else.    At least with Apple devices running OS 26 and later you can migrate between MDM without the need for erasing the device.  ... View more

I'm happy and sad...   ... View more

Haha I reccognise that Voice... That's Geoff! Brings back memories.. He is a nice guy. ... View more

Congrats to all !   ... View more

Good day!    C9300 series running in "Meraki Mode" (CS 17.x.y.z firmware family) behave just as a regular MS family switch with regards to Netflow.   Our MS Netflow document explains you can basically configure the Collector IP and port , which in your case is your Solarwinds NTA service IP and port.   Now, to your point, I agree that the Cisco page doesn't say anything about where the traffic needs to come from; however, Netflow analysis doesn't send traffic back to the devices. Instead, netflow server consumes and process that data and then generates usage graphs and reports.   @eroche , are you trying to find which IP address belongs to Meraki Cloud so that you can identify them in a netflow usage report?   Looking forward to your input on this.   ... View more

It's very simple, the priority is from bottom to top according to the numbering, that is, number 1 has greater priority over number 2. ... View more

Yes Tony, thank you . I can solve using your method... ... View more

Hi @KarstenI ,   Thanks for bringing this up.   I've forwarded your feedback to the documentation team and We'll update you back. ... View more

The only downsides to those are your RO admins could see the info, but if you are small enough to not have any background api tools where you could add password management and your password system not have an API where you could easily keep things in sync, that is less likely to matter, certainly seems like a usable workaround. Run your script 1x a week or similar. ... View more

Hi @InfraSE2020 ,   Sorry about this delay. I checked and found it was my confusion. My apologies.   Your configs were correct. I noticed you changed inside tunnel subnet from 10.104.0.12/30 to a 169.254.X.Y/30 and the behaviour was the same.   I did a lab at home and I was able to reproduce the issue. I have an MX67 and found the exact same behaviour you're having.   So I had to check further with Internal Teams and found there are some ongoing work in firmware 19.2.2 regarding BGP engine and the inside tunnel interface.   And then Today I saw that you changed your VPN with AWS to a Static Routing and remote network is a summary / supernet that contains all your VPC subnets.   It seems to be working fine and that's a good workaround at the moment.   Let's keep an eye on the firmware release feed and check if the next MX firmware gets BGP flowing through the inside tunnel interface in a better way. ... View more

Thank you, @ww !   That's right! Usually there is no configuration change.   But the way event log type and description is implemented gives the impression something changed.   Feel free to make a feature request by going to the bottom right-hand corner of your Meraki Dashboard and sending the request through the "Give Feedback" bubble.   Once you sent your Feature Request using the "Give Feedback" bubble, our Internal Team will process your suggestion and eventually you'll have your feature in the future. Please note that there will be no estimated time to implement such feature. Hope this information is useful. Feel free to post or comment anytime if you have further questions / concerns. ... View more

Hello everyone!   I see this kind of events in Catalyst switches running in Hybrid mode (cloud managed) all the time.   Actually, it doesn't mean a config change. In reality, t's a config refresh. The issue here is the event type and description are the same whether effectively there was a config change or not.   The dashboard UI is trying to say: "switch synchronisation module checked in and got the config file". However, UI doesn't mention if the config file has changed since last time.   It would be nice to have a better event log type and description, though. So feel free to make a Feature Request.   You can make a feature request by going to the bottom right-hand corner of your Meraki Dashboard and sending the request through the "Give Feedback" bubble.   Once you sent your Feature Request using the "Give Feedback" bubble, our Internal Team will process your suggestion and eventually you'll have your feature in the future. Please note that there will be no estimated time to implement such feature.   Hope this information is useful. Feel free to post and comment here anytime if you have further questions / concerns. ... View more

This will probably not be the productive/utilitarian response you need.   Purely 9200L units for us. I think all I can say with regard to the Hybrid mode is that it is incredibly disappointing. IMO Cisco/Meraki engineering didn't actually test this new management model before rolling it out and deciding to deprecate the old method.   While I like the change of not needing a separate onboarding application, the problem I have is that the new onboarding process is *really* bad for switch stacks. Not to mention that if you need to replace a stack member (or expand/shrink a stack for that matter) it's not clear how you are meant to do that as the administrator with hybrid mode. With the cloud monitoring model, I had tested this and found that you simply remove the old switch, put in the new one, and .... Merkai catches up automatically. No additional action required.   From what Meraki support has told me, you need to basically do onboarding of each individual stack member to Meraki which to me sounds insane. ... View more

Thank you, @Slobs2 ! I was hoping to find some Public document about it based on your explanation.   That behaviour makes sense as you described. I was researching internally and found something.   Too bad I there is no Public document about it.   Thanks anyhow! It's good to know! ... View more

Hi @TBHPTL ,   Thanks for correcting me! Forgot to mention the adapter. ... View more

Hi @Ratatui ,   Thanks for sharing your experience.   That's exactly right. I'd like to add perspective as a Support Engineer.   In my experience in Meraki Network Support, individual C9300 can take between 15 and 25 minutes to pop up online in dashboard. Stacked C9300 can take longer.   The key to having the best onboarding experience is to be prepared. The following actions help not just in Hybrid mode, but also can they help in cloud native:   Make sure all trunk ports have your management VLAN allowed throughout your network and also make it the Native VLAN. We know that management VLAN doesn't need to be Native; but doing this is better for onboarding as this is the first VLAN that cloud connector will try to reach the cloud on. Configure your switche's management IP and VLAN as Static using either Local Status Page or CLI. Doing this speeds up a little bit since you don't rely on or wait for a DHCP lease. Ensure you have just one upstream cable and trunk port; i.e.: configure redundancies later after onboarding. Doing this saves you some time with STP convergence during boot. [Cloud Native] Avoid using the NM8 module port as upstream until you have the latest stable firmware. Older cloud native firmware sometimes have problems using this module as upstream trunk. As a result, it does a number or retries; sometimes you got to reboot. 😞 [IOS XE] If your management VLAN ID is above 1000 or if your trunk Allowed VLAN list has above 1000, be sure to enable VLAN Database. Go to menu Organisation -> Early Access, Opt-in (enable) VLAN Database; next, edit your default VLAN Profile in a way that your C9300 isn't limited to 1-1000.   Hope this information is useful. Feel free to comment or post if you have further questions / concerns. ... View more

Hi @NetworkNetwork , thanks for bringing this matter here.   If your tunnel is going down every day, it's usually a racing condition in either Phase-1 or Phase-2 negotiation and SA database; or DPD timers like I mentioned in my first reply.   In some edge cases, it might be related to packet loss in transit between peers.   I would recommend you check the time of day when it goes down and try to find a pattern.   In addition, run MTR with 20 cycles to that Cisco peer right after the the tunnel is down - before even trying to reestablish tunnel.   Doing MTR would tell you if there is some level of packet loss.   After identifying which hop has packet loss, check in a WHOIS tool to find if that hop is within your provider network or some other provider Autonomous System (AS).   ... View more

I have not had any usage issues, the 2x40gig QSFP and 8x10gig modules have been working fine. ... View more

I have had this issue with Apple devices. I think it has to do with the Private Wi-Fi Address feature. This has only become an issue with Meraki in the last 1-2 updates.  ... View more

Hi @JamesTIP ,   Thanks a lot for sharing. This workaround surely will help other MS130 owners.   I wonder if someone else has seen this behaviour (switch not responding to ARP) on other switch models.   In that collaboration spirit, I'm sharing here how to add the switch mac address to ARP in a MacOS or Linux Ubuntu.   Launch the Terminal application Run command "sudo arp -s <IP address> <MAC address>" E.g.: sudo arp -s 1.1.1.100 b8:ab:61:aa:bb:cc use sudo arp -a to display the local ARP table   Back to firmware aspect you mentioned, I did some research internally and found a similar behaviour in older firmware (below 16.8).   There's a combination of hardware and firmware/software conditions that could result in that behaviour (switch not replying to ARP).   So one MS130 had a really bad hardware and you had to process RMA as the workaround didn't work.   The other was onboarded to dahsboard and I supposed you upgraded to latest MS firmware 17.2.1 (as of this writing).   Let's see if see if someone else finds this behaviour on other models or firmware. ... View more

Nice @PhilipDAth !! Being an ex-AWS employee I loved your solution! Nothing better than a full armour against DDoS and other attacks. Combining WAF and a Load Balancer or CloudFront and WAF is a powerfull solution.   Migrating the Web App to cloud and protecting it with cloud-native solutions (first choice) would keep your MX firewall mostly out of the hacker's scope. I.e.: allow-list and/or Layer-7 country deny rule filter the attacks BUT the MX would still have to deal with discarding the packets. Therefore, in a DDoS situation MX might slow down or even stop due to high CPU usage.   However, the downside is cost increase plus the time to migrate the web app to cloud.   Second and third choices are great as they don't require migrating the web app to cloud. But still, this is kind of an overkill from a cost perspective.   @alemabrahao solution would be my first choice but I understand most companies don't know the source IP. So the ideal (from a cost perspective) is just do Layer-7 country deny rules.   What I personally do is to google what are the top 10 attacking source countries and add those to my country deny list.   And of course, no solution comes without a downside / side-effect. In my case is the ones I already mentioned (MX would still be a target) but the problem is sometimes you end up blocking legit traffic. E.g.: some web pages might host part of the content on a denied country or maybe some of your web app clients do come from those countries.   If you get affected by those scenarios perhaps it's better to increase your budget and move your web app to the cloud and protect it with cloud native solutions. ... View more

 @AhamBramhasmi rising star 👏 ... View more