Yeah, that's ok @FCU_JE I went through this thread here and you said "I'm still in rapid testing mode and in hindsight I may have exaggerated just how much luxury I have with regard to timeline."   So you ended up not creating a support case. That's ok. It would take some time to work on it and find a solution. ... View more

Thank you, @FCU_JE ! Can you please send me your support case number over a private message?   I'll have a look at your case.   And I need to quote you on this: "Agreed, but if you want to (continue to) sell the service/product (in the interest of retaining Meraki's place in the market and as a result, ensure your own self-preservation), it's got to be stable."   100% agree with you. I believe our community is a good space not just to vent our frustrations, but also to do bring your feedback to internal teams and work on it.   That's why I ask the support ticket number.   Let me take a look and I'll update you back.  ... View more

Yes, please! I'll try to find some pattern. ... View more

Oh my God, @bradly!!! 😮 Really??   Now you got me curious about it. What was their IOS XE version? Were they all running the same version? ... View more

Hi @bradly and @FCU_JE    Thanks for bringing this up, @bradly .   Does it happen all the time you offboard a switch? How often does it happen?   Answering your question, @bradly : no it wasn't.   @FCU_JE , I honestly share your frustration. From a customer perspective, it might feel like Support doesn't want to fix it. But I assure you it's absolutely not the case.   @bradly , If you confirm that this happens fairly often, then there might be a good chance We can identify a pattern and work from there. If that's the case, We would need you to create a support case and We would work with internal teams on that.   My understanding is this off-boarding issue has been an edge case that only happened like one in a million times and it's very hard to reproduce. Just so you have an idea, I've been working in support for quite a long time now; to be fair, I only saw it happening once.   Like I mentioned in my previous response, this behaviour was already reported and our Internal Teams Investigated it. Now that you asked here, @bradly , I went ahead and checked  that case again. I found my colleague did a repro lab and it didn't happen in a lab environment. Customer who opened that case closed it and did just like you did: moved on and removed configs manually.   As you know, When you off-board from Cloud Monitoring, dashboard pushes an EEM script that your switch runs after it goes off-line and detached/disassociated from your network. This document describes it. What causes this script to fail still unclear.   In my experience over the years in IT: by the end of the day, as large as Internal Teams can be, they are a limited resource and there are other issues to investigate. In addition, they also have to keep developing new features and working on Feature Requests. Every tech company have this limitation.   If you really want to move ahead and investigate this issue, maybe support isn't the best path in this case. It's definitely not like they don't want to work in this issue. They know the limitation above so actually they are saving your time.   Perhaps you would get better results if you discuss this with your Sales Account Manager. If you can expose your use-case and pain-points, they might get to Internal Teams to investigate more. Hope you can get more traction by discussing with your Sales Account Manager. However, keep in mind that even if you engage your Sales Account Manager, I suspect it isn't going to be a quick solution. That's because you have a workaround and this is a minor impact (IMO).   ... View more

Hi @ga123456 ,   Thanks for bringing this up. You raised very good points and MX could definitely offer these functionalities.   I believe We can get these new features available faster if We make separate a feature request (FR) per item using the Give your Feedback button.   To that end, I propose We follow this template below for each FR when doing this feature request. Doing this would improve the chances of moving your FR ahead.   FR-1 Feature Request Title: Implicit DENY in L7 rules Use-Case detail: Current L7 rules have and implicit ALLOW; i.e.: if you dont add a deny, then it's allowed.  "Deny" based. It would be useful to have the ability to create "Allow" (Accept) rules for specific L7 applications while maintaining an Implicit Deny at the end of the ruleset. This allows for a "Whitelisting" security posture (e.g., block everything except MS Teams and SASE traffic).   FR-2 Feature Request Title: Unified Policy Management & Source-Based Filtering Use-Case detail: Currently, Source-based filtering is splited between General Firewall policies (L3) and Group Policies (L7), which is cumbersome to manage. It would be a better UX if We integrate source-based filtering directly into the L7 ruleset. This would allow administrators to define who (source IP/User) can access what (L7 Application) in a single, unified policy view rather than jumping between different menus.   FR-3 Feature Request Title: Object-Based Management Use-Case detail: At this stage, We lack object support in Group Policies which forces us to manually enter FQDNs and subnets. It would be better to Support Network Objects and Groups in a single Instead of manually updating hundreds of IPs/FQDNs, the user wants to update one "Object" that automatically updates all associated firewall rules.   FR-4 Feature Request Title: Deep Packet Inspection (NBAR) Integration Use-Case detail: Full access to the Cisco NBAR (Network Based Application Recognition) Protocol Packs (specificallyProtocol Pack 59.0.0 - Protocols: 0-9, A [Support] - Cisco). This would provide much more granular application identification than what is currently available.   FR-5 Feature Request Title: Automated FQDN/Service Handling Use-Case detail: A feature similar to "Dynamic Objects" or "Service Tags" (like Fortinet’s ISDB). The firewall should automatically stay updated with the changing IP ranges and FQDNs of common cloud services (like Microsoft 365 or AWS) so the admin doesn't have to manage them via the API or manual L3 rules.   These are all really good FR you proposed. Hope all of them become available.   Feel free to post anytime if you have further FR or maybe questions / concerns.   ... View more

@Bits-n-Bytes ,   You may convert your VMX from passthrough to routed mode. Or maybe deploy a new VMX in routed mode.   This post has a really nice example on how to deploy a routed mode VMX and establishing BGP peering over IPsec. ... View more

Hi @Bits-n-Bytes ,   Yes, that's a current design limitation MX have. As per our doc, "iBGP sessions are automatically established between MX appliances over their Meraki AutoVPN tunnels. It is important to note that iBGP is only established between MX devices within the same AutoVPN domain".   So eBGP is the only option when doing non-Meraki VPN at the moment. You can make a Feature Request (FR) for that.   A possible workaround is to deploy a VPN hub/concentrator in a VMX in Azure. This VMX would be a transit network between your other MX (iBGP) and the non-Meraki (eBGP).   Alternatively, you may deploy Azure VPN Gateway to act like a VPN hub/concentrator instead of deploying VMX. Just like @PhilipDAth suggested later in this post.   I honestly don't know if VMX is cheaper than Azure VPN Gateway. But I believe it would be easier to support and troubleshoot than Azure VPN Gateway. ... View more

Hi All,   Yeah, finding balance between work and personal life, like being healthyer it's always in my mind. Considering the cost of living in Sydney, I think a new income stream would be great.   But as for networking, I wish I have more chances to brush up the Networking Fundamentals and also learn new things while helping people in Support or here in our community. ... View more

Congratulations to Everyone! You're relentlessly active here! I do my best to contribute to the community every break I have from Support work. But you all are in another level! Cheers! ... View more

Hi @JinSoo_Park    The 19.2.4 has demonstrated to be stable in my experience in Support Team.   But in my personal opinion (not as a Meraki empolyee) is don't run RC unless I absolutely need the new feature present only in RC.   Regarding BGP, TGW doesn't have BGP by itself. You would need to create a new AWS VPN endpoint this time it would be a BGP routed VPN and attach it to your TGW.   But if there are only some few EC2 it looks better to avoid complexity in your solution and just run 19.1.11 and do single tunnel with fail-over.   And for health-check, my personal suggestion is you check against your EC2s rather than something outside AWS.   Happy New Year!   ... View more

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

Hi @JinSoo_Park ,   Thanks for sharing such a detailed answer.   If you don't mind, I'm sending you a private message.   I would like to have a closer look at your support case.   I'm too curious to let this go now. I want to see how this evolves and get a solution.   Thanks again.   ... View more

Hi @JinSoo_Park ,   I'm back and sharing my findings.   We believe in this case you would benefit more from a Support Case. It's too hard to troubleshoot the behaviour you described without looking at your network and backends.   In any case, I'm answering your questions below, granted that you're running firmware higher than 19.2.2 where Multilink feature is enabled;   1. Is it expected behaviour for Traffic Selectors to change to 0.0.0.0/0 when health checks fail? - The traffic selectors would be 0.0.0.0/0 if health checks are enabled in general.   2. Are there known limitations or requirements for Health Checks with AWS TGW + Meraki IPsec? - No, there are no known limitations or issues for health checks.   3. Is there a recommended Health Check endpoint when using AWS Transit Gateway? - No, nothing special recommended here. Only thing you need is AWS side is routing traffic back.   4. Are there any additional settings required to keep both Primary and Secondary tunnels active simultaneously without breaking traffic selectors? - No, there is no extra config needed here.   In conclusion, let's examine your issue over a support case as this would allow us to look deeper into this behaviour.   Looking forward to your input on this.   ... View more

Hello there @JinSoo_Park ,   Thanks for your really in-depth scenario and follow-up questions.   I'm just missing which firmware version you're running at the moment.   I'll discuss this with Internal Teams and update you back with my findings.   I suppose it's 19.1.11 (the current Stable). Am I right?   I didn't have the chance to test peering with AWS TGW but I suppose if you want both tunnel active simultaneously and you're not using BGP, this would be expected.   But let me check this internally and I'll update you.     ... View more

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

Hello @Jhippleheuser ,   I'll ask my friends at Systems Manager team and update you back.   Systems Manager is pretty cool and Sentry is a very handy feature it. Sentry helps integrating your mobile devices to MR access points and MX firewall much easier.   Since Sentry is a Systems Manager feature, I suspect it's going to be discontinues along with Systems Manager itself. But I have to confirm this with my colleagues.   In the meantime, I recommend checking your migration options - just to be on the safe side. As per our Systems ManagerEnd Of Life (EOL) FAQ, Ivanti Neurons for MDM would be a viable MDM solution you can migrate to.   We recommend reading this document that has more insight into Ivanti Neurons migration.   We can provide you with more detailed steps on how to migrate Sentry Wi-Fi to Ivanti Neurons equivalent feature later on.   ... View more

Hello @jam0001 ,   Thanks for bringing your issue to our attention.   I apologise but I must ask the obvious first, ok?   1) Did you try logging in using another web browser and got the same error? 2) Did you try logging in using the same web browser but in anonymous mode and got the same error? 3) Did you clear your web browser cache and tried again? What happened?   I'm in a different time zone so I only saw your post 7 hours after you posted. If this issue is still happening after you tried everything from your side, then maybe it's time to call Meraki Support.   You can find regional Support number at the end of this page.   ... View more

Thank you, @IvanJukic ! Yes, CGNAT and IP brokers gave IPv4 an indefinite life extension.   This topics remind me of this old Packet Pushers episode where the guest has some sharp takes on IPv6 caveats. It gets to your point around 19mins.   Have fun listening, everyone!   ... View more

Hi @The_Phil ,   I love IPv6 and BGP. These two topics are very dear to me. I agree it's frustrating how long IPv6 has been going on and yet We don't see it implemented everywhere.   I understand that a Provider Independent (PI) range it's an IPv6 address block that you get from your local Internet Registry. So, I believe you would like to have an MX doing eBGP peering and exchanging both IPv6 and IPv4 prefixes with another Autonomous System (AS) over an IPv6 interface.   Let me know if I got your use-case right. Can you expand your IPv6 use-case?The reason I ask this is because We can increase the chances of our feature request getting to a production firmware if We add more details and advocate for it in a better way. Doing this would make a more compelling case to Internal Team when they get your feature request.   Anyhow, using the "Give your Feedback" button is a great way to plant ideas in the product team's mind.    I would like to add to your topic here. I propose We follow this template below when doing this feature request:   Feature Request Title: eBGP Peer LAN/WAN support for IPv6 Use-Case detail: As We know, MX firewall only offers the ability to establish BGP peering via IPv4 address when using eBGP in VPN Concentrator or in Routed Mode. With the progressive adoption of IPv6 and the carrier motion to support IPv6, having the ability to peer with an IPv6 neighbour is becoming a key compatibility feature. Customers and Service Providers are moving to an IPv6-only architecture so lack of IPv6 BGP peering leaves MX firewalls obsolete.       ... 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

Hi @eroche ,   According to this Cisco document, you can check it with the following command:   Switch# show snmp mib ifmib ifindex GigabitEthernet1/0/39: Ifindex = 47 unrouted VLAN 20: Ifindex = 200 unrouted VLAN 23: Ifindex = 230 GigabitEthernet1/0/28: Ifindex = 36 GigabitEthernet1/0/19: Ifindex = 27 Hope this helps you with your SolarWinds solution.   ... View more

Nice! Congrats Everyone! ... View more