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

Hi, @Mr_Meraki ,   It's a hard reality in computing: you add complexity every time you tighten security.   As you know from @EAzevedo reply, this change was made to comply with EU RED standard.   I'll say it again and you can see it in my earlier reply "I feel your pain. I also miss that old feature". I'm not just saying.   I'd better stop here before I start getting off topic while I runt about the good old days... And then someone will post that meme "Old man yells at cloud" making fun of me.   Anyhow, I'm not trying to convince you that the new local password feature is good or using a centralised password management solution is a great solution.   I'm here to help, just like you. Those are my insights on how We can adapt to that new regulation. The dashboard can change if enough people make feature request and We find a way to still comply with EU RED.   Thanks for your insights and thanks for understanding, @Mr_Meraki . ... View more

If I were to manage such MSP, I would seriously evaluate a corporate password manager. Assuming MSP has it's own Directory Service (MS Active Directory or any other), it's key that the password manager solution accepts logins from your Directory Service. This would allow you to disable just one login in case an employee leaves MSP.   For extra security, you may rotate device's local password by using API calls in all managed orgs. 😄 Don't ask me exactly how to do it. I just know that this API exists. ... View more

Hi @Mr_Meraki , these two scenarios are valid concerns and they can be addressed as follows.   Device is offline; you setup a password and manage it with your own solution. Here, the device will synchronise with dashboard and apply that local password once it goes online. After that, you will use the local password you defined in dashboard and stored in your own solution. You may define it every time you need local access; nothing prevents you from doing that. However, the only time you need local access is when you are doing a basic config to make it connect to dashboard or some troubleshooting. Therefore, it's not best practice to change it every time as the consequence is two fold: [a] device might be offline so it doesn't get the new password, [b] new password applies to all devices so you would need to know it when you troubleshoot a different device. So this last fold brings us to your second scenario Device is offline but a password has been set and nobody knows it; so here a factory reset would erase it along with any other config. As a result, you would login locally with serial number and configure it to be online in dashboard. Once device is online, it would sync with dashboard and get the new local password again. Therefore, if you don't know the last password, you'll have to redefine it every time you do maintenance or add a new device. That's what I call administrative overhead and definitely not a best practice.   In summary, We can think of a "situation where the device has been statically set so you can't get it back online." and that's the case where a factory reset is useful. For example, a config that brings the device offline, like adding the wrong management VLAN. You can bring it back after factory reset but the device would synch with dashboard and put the wrong management VLAN again. The result is a kind of a racing condition where you need to know the local password and also revert the change in dashboard. Otherwise you may get an offline and online loop situation. ... 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

Hi @SteMeDi ,   Yes, I feel your pain. I also miss that old feature.   However, I believe they made it that way to also avoid someone "shoulder surfing" when you're checking or even eavesdropping. Imagine an employee that checks it and then leaves the company; now potentially this person has the ability to login locally if they leave the company and the other admins forget to change the local password. See the problem?   It's very common to have admins forgetting to rotate key / sensitive network passwords when someone leaves the company.   In that sense, your password management over API is a nice solution. I checked Cisco Meraki marketplace but couldn't find one.   Perhaps the best way to move ahead is for you to leverage a corporate password manager. There are plenty of options out there. E.g.: Proton password , Bitwarden , Keeper...   Hope this helps. ... View more

Hi @InfraSE2020 ,   Yes, so it doesn't seem to be related wit inside tunnel IP inverted.   Thanks for sharing the support case info over PM. I was able to look at your non-Meraki VPN peer and fount the remote-network seems to be incorrect.   As per the document I mentioned before, "Non-Meraki peer must support route-based VPN" is needed along with the other requisites.   So in route-based VPNs the remote networks is always 0.0.0.0/0. However, you have Azure's defined IPSec Subnet: 10.104.0.12/30 in your config.   I believe this is creating an issue with the way the inside tunnel virtual interface communicates. Hence, BGP state never established.   In addition, don't worry about remote subnet 0.0.0.0/0 as it doesn't create a default route in this case. It is there just to allow the inside tunnel (a.k.a. VTI) and all routing is controllerd by routing engine together with BGP.   By the way, this topic reminds me of another requisite: "When establishing an eBGP peering on the WAN in routed mode, NAT must be disabled on that uplink (see NAT Exceptions with Manual Inbound Firewall) otherwise the subnets advertised by the MX will be behind NAT and unreachable via eBGP subnets upstream." (document source here)   So here's another config that you need to check: be sure to open menu Organisation -> Early Access and then opt-in (enable) "NAT Exceptions with Manual Inbound Firewall"   I also shared my findings with my Support colleague working in your ticked. Maybe you get a reply from him first.   In summary, change the remote networks to 0.0.0.0/0 in your VPN peer settings and enable NAT exceptions. Doing this would fix your BGP. ... View more

Hi @InfraSE2020 ,   Thanks for bringing this topic here. Feel free to share the support case number with me over private message here in community portal.   In the meantime, be sure to check this document and make sure your MX is running the most recent firmware version 19.2.2 that supports Multihop bgp session.   In addition, your idea makes total sense. I checked this Microsoft document and it seems to me that first IP within the /30 subnet would belong to Azure. But maybe it's the opposite.   Did you test configuring MX BGP interface as 10.104.0.13? ... 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

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, @Slobs2 ! Thanks for sharing the solution.   Can you give us more details about the solution?   I'm curious about that DNS snooping feature.   ... View more

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

Hi @MaxMartini ,   Thanks for sharing! That's a nice gallery.   As you know, AIR-AP-BRACKET-2 mount works with the Catalyst Wireless CW91xx and MR33, MR42/42E, MR44, MR52, MR53/53E, MR45/55, MR36/46/46E/56 indoor access points.   Personally, I'm always confused when it comes to mounting and assembling these kits. 😜It feels like assembling IKEA furniture: looks easy in the manual but you can't figure out what's that last screw for...🤔   So I'm adding here links to Installation instructions to some CW91xx:   CW9166D CW9162 CW9164 CW9176D1   Hope this information is useful.🤓 ... 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

Well, I'm happy you're not going through any issues other than dashboard not showing the NM8 module.   Honestly, I wouldn't worry about it. Dashboard team is regularly working in New View and Old View.   If you suspect the module is malfunctioning, then you may want to open the terminal and run command "show inventory".   If you see good response, then it's just the dashboard.   IOS XE 17.15.3 is currently a Stable Release Candidate (RC) when it comes to running in cloud native mode. As any RC, it is stable but it may have some unexpected behaviour as you can see it in this case.   That's not to say IOS XE 17.15.3 is a Release Candidate, as you can read on Cisco's Release Notes page. But with regards to dashboard integration, it is RC.   As a general best practice, I recommend you keep an eye in our Firmware Upgrades Feed and plan for your next Production Stable version. Our Internal Teams would have fixed it by that point in time.   ... View more

Hi @GL ,   Hope you're doing great! Thanks for bringing this up.   This behaviour you're describing can be a simple dashboard delay. Usually, if you go to switch ports menu and select an active port within NM8 module, then the dashboard will refresh and show it.   Another possibility is the IOS XE 17.15.3 conversations with dashboard backend servers might be having some problem.   If this is the case, you would see other problems like your switch going offline, for example.   I've seen this happening in my support cases. But on those cases the switches were having issues due to other unrelated things. And then, as soon as the issues were resolved, dashboard displayed the module without delay.   I'm curious to know some more details:   Are you viewing your switch in Old View style or New View? Did you add your C9300 IOS XE 17.15.3 in hybrid operating mode or in cloud native operating mode? Would you be able to capture a .HAR file when it happens and share it with us?   Looking forward to your input on this. ... View more

Ok. Thanks for clarifying.   If your Guest network has Meraki DHCP (NAT mode) , then the Access Point will offer 10.x.y.z IP to wifi clients.   If you have a large number of clients in and out everyday, you may have duplicated IP every now and then.   In addition, sometimes a user might add the leased IP statically to his/her device.   ... View more

Hi @sflitcraft ,   Is that client connected to wired network or wireless network?   Is it a tablet or a laptop?   Do you have a DHCP fixed IP assignment?   The reason is ask is I saw some devices sharing the same mac address on their wifi and ethernet cards. So if the SSID this device is connecting is associated with the same VLAN present on wired connection, it's possible DHCP assigns the same IP.   And also @cmr has a good point. ... 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

Hi @JamesTIP    Thanks for sharing. I'm curious about the firmware version your MS120 is running. This is a rather unusual behaviour.    I mean, after a factory reset, if you configure 1.1.1.99 in your client host, there should be no need to hard code your switch mac address resolving to 1.1.1.100. I.e.: was the switch not responding to ARP? ... 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