Meraki

GiacomoS · ‎Aug 5 2021

Hey @sixgigdan , Not yet unfortunately, but we have multiple teams assisting to resolve this as soon as possible. A root cause has been identified and we are currently working on a fix. I hear your feedback with the Status page and will ensure I raise it up. Many thanks for your patience everyone. Giac Meraki Support

GiacomoS · ‎Aug 5 2021

Good day everyone, We are currently experiencing an issue with multiple hosted services and configuration fetches from Dashboard. The impacted services would include: - Device configuration fetch (all devices) - Client VPN with Meraki Authentication - Systems Manager enrollment (if gated behind Meraki Authentication) - SSID scheduling - Any other service using Meraki Authentication - Site to Site VPNs in a few shards Our teams are aware and are working to resolve this as promptly as possible. The waiting times calling in are currently extended. We will provide further updates here as we receive them. Many thanks. Giac Cisco Meraki Support

GiacomoS · ‎Dec 17 2020

Hey folks, @webmanaus I think I understand what you are trying to achieve. In my experience with other vendors, I have observed the same behaviour; my gut reaction here is, why would you want an internal client to go through the LAN of the MX, being filtered, shaped, routed, NATted, fragmented, go out of the WAN and be back in the WAN to then be filtered, shaped, routed, NATted, reassembled, to go back into the LAN? 😛 In your situation, if you have a DNS server internally, I'd actually create an entry for the server that resolves locally, so you also don't have to modify every single host file out there. If you don't have an internal DNS, I'd consider Cisco Umbrella, as you can do this kind of split DNS resolution with a cloud managed platform. @phelpsa06 at the moment this is not possible with the MX. There is a source NAT feature in development, so this should eventually appear in one of the future firmware releases, but that's not available just yet. Hope this helps! Giac

GiacomoS · ‎Oct 29 2020

Hey Grillface! I'm not sure if I understood your objective properly here, but I'll try and break the question down. The Allowed Remote IPs field is sort of an access list. The only purpose is to restrict which IP addresses can make use of the NAT rule you created. The following is an example of a valid configuration, that would allow only 1.1.1.2 to use 1.1.1.1:12345 to access 192.168.0.52:54321 If I was instead coming from 2.2.2.2, the Allowed remote IPs list would stop me from accessing the server. In terms of what you can put in that field, we would allow any IP address or range, but remember that the MX would evaluate this from its WAN's perspective. Traffic from the LAN would never be inbound on the WAN, therefore having your LAN in the Allowed remote IPs would not have any effect; in other words, if you took a packet capture on the WAN, you would never see a packet with a 192.168.0.X address in the source (unless you have an MPLS), so the Allowed remote IPs rule would never kick in. On the second part of your question, am I understanding it right that what you are trying to achieve is NAT subnet A onto Public IP A, for it to then talk via Public IP B to subnet B (using the 1:Many NAT)? Many thanks! Giacomo

GiacomoS · ‎Apr 10 2019

Hey folks, Quick note to let you know that Windows 10 seem to have the horrible tendency of removing the security option every time you disconnect from VPN, reboot your PC, do updates, click the mouse on the Desktop or look away from the screen. Make sure you have "Require encryption" selected and under "Allow these protocols:" tick "Unencrypted password (PAP)" This should theoretically help as well. Thanks! Giac

GiacomoS · ‎Dec 5 2018

Awesome job everybody! Keep up the great work, as you are all totally awesome! 🙂

GiacomoS · ‎Oct 14 2018

Hey @nst1, I suppose the question actually becomes: Why are you using the switch in L3 mode if you don't want it to route any traffic? 🙂 If you configure a L3 interface, you will always need to have a route to reach out to the internet and therefore we will make sure that you do not delete it as it would cause loss of service to the device. Solution here, I think, would be to either move back to L2 if L3 is not required or create an alternative default route. Hope this helps! G

GiacomoS · ‎Oct 14 2018

Hey @ReneStoffels, Keep in mind that DHCP is normally requested by the client and an ordinary change will not necessarily prompt the clients to refresh their IP address on the new subnet. If you just change it from the 192.X subnet to the 10.X one, you might end up with a lot of clients with incorrect IP addressing which will not have network access until the lease expires. @PhilipDAth 's method will go a long way in helping refreshing everything, especially if powered via PoE. I know Windows client tend to be a bit stubborn and might retain the address even by doing this. An alternative method might be to reduce the lease time down to the minimum, wait 24 hours for all the devices to get the new lease time and then make the changes, so within a few minutes everything should get the new address. Hope this helps! Giacomo

GiacomoS · ‎Oct 14 2018

Hey @egassmann, Stacking is one of the things that can go horribly wrong, especially when replacing members. I would (very!) strongly advise to follow our documentation here: https://documentation.meraki.com/MS/Stacking/Switch_Stacks#Replacing_and_Cloning_Stack_Members I have seen many situations already where the instructions have not been followed, the stack gets messed up and you end up having to rebuild it from scratch. If you follow the steps in the guide you should be good to go 🙂 Let us know how you get on! Giacomo

GiacomoS · ‎Oct 14 2018

Hey guys, Just to chime in, make sure you first bring the unit online via a wired internet connection as it will need to download some firmware and configuration. Once it's up and running the first time, you should be able to use the cellular. As you rightfully mentioned, in some instances you might want to ask your provider for the APNS and set it accordingly on the Appliance status page. Thanks! Giacomo

GiacomoS · ‎Oct 14 2018

Hey Matt, This looks one of those tricky VPN ones. Not sure what you mean with the VPN is not NATed (if you have a network diagram of the devices involved with mock IP addresses it would be awesome), but it may be sensible to disable NAT-T on both ends of the tunnel (i.e. on the Meraki MX as well). Just to confirm, does the tunnel drop completely or does it stay up and drop traffic? If it is the latter, you could try release 15.X, but you'll need to ask the support engineer working on your case to set this for you. Alternatively, you could try to get both us and Juniper on the same call, so we can try and debug what's going wrong. Thanks! Giacomo

GiacomoS · ‎Oct 13 2018

Late to the party, but well done guys! Really appreciate all your help in reducing my day to day workload! 😜 G

GiacomoS · ‎Oct 13 2018

Hey @TimBisel, You want to set the uplink statistic up pointing to the public IP address of the remote end, not the LAN side. That way you will monitor WAN-WAN connectivity rather than over the VPN. Thanks! G

GiacomoS · ‎Oct 12 2018

Hi @TimBisel, I will echo @nwu1 response, and I would recommend to follow the article to troubleshoot this too. There is, however, another action you might want to take to understand if there is a break in the communication between the two sites: you can navigate in Security appliance > Traffic shaping and set up an Uplink statistic with destination the public IP address of the remote Meraki MX. You can then see the information from Security Appliance > Appliance status > Uplink and this would greatly help you to understand if there's any drop occurring over the WAN or if the issue is just on the VPN tunnel. If you see frequent disconnections on the event log to the VPN registry, give us a call as we might be able to take some remediation steps. Thanks! Giacomo

GiacomoS · ‎Sep 17 2018

Hey @Welles, From time to time a particular setup might cause some unexpected behaviours and we will need to tackle them on a case by case basis. Looks like unfortunately you came across one of these situation and I am sorry you had to go through it, but at the end of the day that's what our friendly support team is there for! 🙂 Hope this got sorted though. Regarding the Release notes, thank you for bringing this to my attention. We have raised it internally and we are expecting a fix within the next couple of days. Sorry for any inconvenience! Giacomo

GiacomoS · ‎Sep 16 2018

Hey all, I would like to chime in with what Dave is saying. Communication and continuous feedback is key for us, so we do try our best to be transparent with our customers in every step of the way; I think we do demonstrate this through our blog advisories, our efforts with the Meraki Community and the way we present the information regarding your network and your data. Regarding @aws_architect specific's issue, I think the catch here is the fact that there is no open beta for the Meraki MR at the moment. The Umbrella trial on 26.X is sort of a Closed Beta and is purposefully targeted to only test out the Cisco Umbrella integration, so no Changelog is present to show what other fixes or issues are present. This is not in an attempt to hide what is being changed in the specific version, but rather due to this being a specifically targeted build. Echoing @MerakiDave and @MRCUR, I strongly recommend to coordinate with the Sales representative in this situation, as they can tap into internal engineering resources; Support might also be able to help out, but the timescales to get feedback might be slightly longer. I would say though, that it may be good practice to carry out this due diligence prior to the upgrade, so you can make sure that there is no adverse effect to you applying the feature. @Welles, you should be able to have visibility of what's in all the releases by looking at the release notes via the Organization > Firmware upgrades page. We normally put in all the interesting stuff in a very summarised format there. If you are unsure of something, give Support a call and they should be able to clarify. Thanks! Giacomo

GiacomoS · ‎Sep 9 2018

Hey all, Just chipping in here to say we have created a FAQ page on our Knowledgebase: https://documentation.meraki.com/zGeneral_Administration/Support/MS225%2F%2FMS210-48LP%2F%2FFP_Proactive_Replacement This is following the advisory we released last month: https://meraki.cisco.com/blog/cisco-meraki-customer-advisories/ As @MerakiDave mentioned above, we have a software mitigation for devices that are not in the failure stage yet, so if you have concerns or you can see issues with the device, get in touch with us at your earliest convenience, so this can be applied for you. Thank you all for your understanding and patience on this! Giacomo

GiacomoS · ‎Sep 9 2018

Hey all, I have noticed that there is still a lot of confusion and skepticism in regards to our Firmware release process, in particular when it comes to the Beta release. I would like to try and clarify this as best I can, but keeping it nice and short as no one has time to read a long blob of detailed wording, right? 🙂 Stable Release As per the name, this is the current firmware version that has been in production for a while. On average, you would want to be running this unless...... Stable Release Candidate ...... you are facing a problem. There is an issue in the current software that you have encountered and we have already implemented a fix, not on the current stable release, but in the next planned one. Beta release "What about that new feature that I've heard about? I'd really like that. But I'm also facing a problem that is not being resolved in the Stable RC. What now?" Well now, that's what the Beta release is for. What we call beta is actually a version that has already been tested in house extensively and in a selected number of networks to confirm stability of the platforms before releasing it to the public. The beta cycle is very quick and allows us to implement fixes a little bit more dynamically than waiting a stable release that may be months away. I'll take the liberty now to give you my personal view (which having read the above, you can 100% skip!). From a personal point of view, I find the denomination a bit misleading. I'm not a software developer, so I will not pretend I know why a release has been called a name and not another, but I would say not to look at Beta firmware as if it was a car with just 3 wheels. The car is complete, we put a shiny new touch screen display next to the driver seat and maybe even integrated the sat-nav in the windshield, plus you can now regulate the headrest, which is something that has been bothering you for a while, but it's not very popular and known yet, so you may not find a review praising it around. With this, I'm not saying "Go and upgrade all your networks to Beta, NOW!" 🙂 As I mentioned earlier, we always recommend being in the latest Stable version (I would say it's important to keep up with the stable release train though). At times, Meraki Support will likely suggest to move up to a different version in order to fix that particular issue you are facing. I would encourage you, though, to cast a quick glance at the release notes that you can find under Organization > Firmware Upgrades , as they are normally going to state what we are fixing and what you should be expecting still being a problem. Regardless of the versions you decide to roll out in your network, you will always benefit from our support, though do keep in mind that the older versions are on a best effort basis. More info here: https://documentation.meraki.com/zGeneral_Administration/Firmware_Upgrades/Meraki_Firmware_Release_Process I hope this helps! Giacomo

GiacomoS · ‎Sep 9 2018

Hey @SlothSlayer , Keep in mind that there's two different sections for SNMP depending on whether you are polling internally in the network or externally from the internet. As you mentioned the WAN setups, I assume you are polling remotely, in which case you are looking at the Organization wide setting: https://documentation.meraki.com/zGeneral_Administration/Monitoring_and_Reporting/SNMP_Overview_and_Configuration#Configuration Remember that you are actually polling the information from the Dashboard and not directly the MX (hence the target being snmp.meraki.com ), although if you have allowed it, you should be able to carry out continuous pings to the MX. Also, remember to put the IP address you are polling from in the Allowed list. The Network-wide setting is useful only when you are polling internally from the LAN. If you are still having trouble, try following the testing steps here and see what you get: https://documentation.meraki.com/zGeneral_Administration/Monitoring_and_Reporting/SNMP_Overview_and_Configuration#Testing_SNMP Hope this helps! Giacomo

GiacomoS · ‎Sep 9 2018

Hey @RYN0 , I think you might be looking at doing this either from the server side or you'll need an App different from the inbuilt one. A Google search showed me you can install pretty much everything that is available on Android, so you should be able to find one where you can specify the subnets that should go via the VPN. Hope this helps! Giacomo

GiacomoS · ‎Sep 7 2018

Hey guys, We had another couple of cases regarding this issue. It seems that there's different solutions to this depending on the circumstances. The last case I'm aware about, Cisco TAC was involved and they confirmed a bug on the ASA with Id CSCso70269 . I would suggest to cast an eye on it and try the same commands to see if you are hitting that bug too. Hope this helps! Giacomo

GiacomoS · ‎Sep 7 2018

Hey @GianPaolo, The paragraph you posted is assuming that both sites in the MPLS are going to break out from a single internet link as per standard MPLS design; from the looks of your design, you seem to have 3 links at the branch, 2x direct internet and 1xMPLS with no WAN breakout. I have a feeling that this might not work as you expect it by default, but I think with some routing manipulation and traffic preferences (e.g.: push traffic destined to the Meraki cloud via the MPLS link) you might be able to achieve the result you want. It may be a good idea to give a quick call to your sales rep; we have engineers that are dedicated to helping out with design advice, so it might be a good port of call for this. Hope this helps! Giacomo

GiacomoS · ‎Aug 27 2018

Hey @--JayJay--, This sounds a bit of a weird behaviour. It might be something that we need to investigate a bit better... Feel free to raise a case either via Dashboard or give us a call on the support number, so we can have a look and try to find out what's going wrong. Giacomo

GiacomoS · ‎Aug 26 2018

@PhilipDAth, giving out all our secrets so blatantly!!!! XD

GiacomoS · ‎Aug 26 2018

Hey @BlakeRichardson, I used the C14 bars in deployments for the previous company I was working for; I don't remember the exact brand we used at the time, but I found the Transcension PC 08 with a quick Google search that might suit your needs. 🙂 Thanks! Giacomo

About GiacomoS

GiacomoS

Community Record

Badges