Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Register or Sign in
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
About General-Zod
General-Zod
Getting noticed
Member since Sep 5, 2017
Apr 3 2022
Kudos given to
Community Record
48
Posts
40
Kudos
3
Solutions
Badges
Dec 7 2020
12:45 PM
1 Kudo
Greetings @GregoryW Can you please disable NATing on your fortigate IPsec firewall policy. Local>remote Your IPsec interface on the fortigate doesn’t have a ip associated with it (unless you have configured one) so the NAT function won’t do you any good. This would also explain why traffic initiated from the Meraki to Fortigate is working. The fortigate IPsec firewall Policy remote>Local should also have NAT disabled, however it’s still working as the egress interface “local-lan” does have a ip attached to its interface. make sense?
... View more
Jul 21 2020
5:41 PM
4 Kudos
Hi @SCC I most definitely would ‘always’ have AV running on your desktop / server environment. Security has and always will be a layered approach. there is no silver bullet cheers
... View more
Jul 8 2020
6:15 AM
1 Kudo
You are not alone, welcome to my world, and many others! https://community.meraki.com/t5/Dashboard-Administration/Unable-to-fetch-configuration-Unresolved-software-bug/td-p/68559 we are growing in numbers I’m afraid...,
... View more
Jun 29 2020
8:55 PM
Generally speaking, simply having a device that is unused in your inventory won't go towards a license count. In the case of MX's, if you go down the HA path and add the 2nd MX to the same network with a existing MX you will still be within the license limits as you don't need another license if you setup a MX HA pair. Hope this helps
... View more
Jun 29 2020
7:38 PM
1 Kudo
Hi @Noffal Licenses are applied to Orgs not devices. If you purchased another MX64 to use in the event of a failure you could simply have the device sitting in the inventory (not assigned to a Network). If the time comes you can simply remove the faulty MX from the network and add the new one from inventory to the network in question. On a side note, if you going to the expense of purchasing another MX for business continuity why not create a HA pair (2 x MX64 - Active-Passive). One of the good things if you go down this path is that you don't need another license. Only 1 ENT or ADV license is required for MX HA setup. You'll need to be able to span some vlans/ports on a switch to cater for the connections but at least you will have automatic redundancy. https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair Hope this helps
... View more
Jun 23 2020
7:45 PM
That's a shame @CountRushmore A big thank you for being the guinea pig though, you have saved me a lot of time and effort. We are still running on 14.50, since then we have experienced 15 x "Unable to fetch" occurances. Approx 3 per month. No end in sight, despite esculating this with Meraki. 👿 Has been dragging on since Q4 - 2019
... View more
Jun 1 2020
6:48 AM
2 Kudos
It is my understanding that this issue can only be resolved by Meraki support. Unfortunately I have seen it many times, Meraki know of the problem and are working on a real fix. They have been for sometime now.... still waiting.
... View more
Mar 3 2020
10:08 PM
Just a update for those of you who are also experiencing the problem. Problem is due to internal storage not being mounted correctly. Meraki stated that v14.50 (Stable release Candidate) fixes this problem - as per release notes. Unfortunately the problem of Unable to fetch configuration still remains. Meraki support informed me that the identified bug has been fixed in version 14.50 and this new "unknown" bug displays the same symptoms resulting in the storage being dismounted and ultimately displaying "Unable to fetch configuration" - this is of no comfort to the customer. Seen 3 occurances of this since moving to rls 14.50 in as many weeks. Have seen over 10 occurances of this issue on 14.49 since Nov 2019 at difference sites This has been esculated to Meraki and they have assured me this is a high priority and they are working on a "real" fix. At any moment in time a site can go off the air. This is supposed to be a rare occurance despite it happening at 13 sites, same customer. Customer not happy.
... View more
Jan 9 2020
3:16 PM
2 Kudos
Hi @samgbuyi If the src and dst are on the same vlan that resides behind the MX there would be no enformement being done on the MX as there is no L3 involved. I believe you problem is in relation to something else. I'm certain you will have the same result if you unplug the lan interface on the MX from your switch. Perhaps check the server itself.
... View more
Jan 3 2020
2:25 AM
Correct As mentioned previously, if you want to use a mx there are 3 foreseeable options. 1) use 1-1 NAT on MX, your other customer routers would have a private IP on each wan ip, but at least the customer will have the same ip ingress and egress. does this impact your offering? I guess it depends on the service your selling? 2) use beta code on mx and disable Nat on mx and assign the real public ips from your /29 to mx LAN and to your customer router. 3) same as option 2 but with Gold release software and accept the fact that outbound comms from customer router will src translate to mx /30 3 mx options aren’t enough for you? 🤓
... View more
Jan 2 2020
11:24 PM
Greetings! Sounds like they have assigned you a /30 and a /29 public address block and the ISP is simply routing the /29 to your CE device (MX), please clarify. You should be able to setup the LAN side of your MX with the /29. Depending on how many ports your MX has you could plug in your addition routers that you want to have a public IP into the MX LAN ports. Just ensure the LAN side MX ports are in the same vlan (/29). If you don't have enough ports you might need a switch for extra port density. Even if you were to do the above keep in mind all traffic from your downstream router with a public IP will NAT to that of the MX's public IP /30. Probably not ideal, unless you want to run BETA code that support "no NAT". Because of this limitation I would use a different router at the edge where NAT isn't enforced and setup like above and connect said device to a switch to extend the /29 vlan to accomodate your additonal routers etc. or.....you could do 1-1 NAT on the MX to your downstream routers, but the public IP won't be assigned to the physical WAN interface of the downstream router. So a few options here, hope this helps Cheers
... View more
Dec 21 2019
3:02 PM
1 Kudo
I have seen this before on a MX using its dhcp mechanism. There was a rouge ip phone that kept changing the last part of its MAC address and it kept consuming IP’s until the pool was exhausted. The dashboard however showed plenty of available addresses. After a call to Meraki support they were able to dig deeper and they could see that the pool was indeed exhausted. It is my understanding that the dashboard only shows successfully accepted dhcp offers. The rogue IP phone in question just kept flipping the last part of its mac and exhausted the pool. Sadly whenever the event occurred I wasn’t available to perform a capture. Hope this helps. cheers
... View more
Dec 10 2019
7:51 PM
Actual device uptime in additon to current dashboard checkin uptime. For MSP accounts, have the Orgs name in the subject line with the notification message. Able to add "inbound" firewall rules to IPSEC VPN tunnels
... View more
Dec 6 2019
2:34 PM
As mentioned by others I don’t see why this wouldn’t work. You mentioned you have 2 available IP’s on wan1 for HA. You really need 3 to include the vrrp address. Not vital but best practice. cheers
... View more
Nov 24 2019
7:37 PM
...very yucky. They have dual WAN configured also, so would need tech onsite to change LAN4 > WAN2, ip details etc. definately not ideal.
... View more
Nov 24 2019
7:04 PM
3 Kudos
Greetings, I know this has been flagged previously in other threads however I thought I'd put a bit more focus on it. We have a customer (large retailer) who has a fleet of MX64's. In the last 3 weeks we have had 5 occurances where "Unable to fetch configuration" was displayed on the dashboard. This co-incides with the MX going offline - at least from the dashboard's perspective. Customer was running 14.39 software. Whilst a call to Meraki resolved the issue, they had to fix something in the backend concerning local storage on the MX, the customer is still impacted. Apparently Meraki fixed and flagged this behaviour as a rare occurance according to release notes, 14.35, thanks @PhilipDAth "Resolved an issue that could result in devices failing to pull configuration updates from the Meraki Dashboard in rare circumstances" So not only is the issue _not_ fixed, it certainly is _not_ a rare circumstance. Too boot the Meraki employee I spoke to informed me that this issue is fixed in 14.40 despite the rls notes not stating such. Was informed by same individual not all bug fixes are stated in the release notes. I took it on face value and requested the customer to upgrade to 14.40 to prevent the issue re-occuring, which they did only to find that another event of the issue occured. Was informed by different Meraki support engineer that this bug is still present and it's still under investigation. This does not sit well with my customer, especially coming into the Christmas period. Have requested if Meraki can proactivily perform some action to prevent downtime during business hours but to no avail. Have also requested list of devices in which the storage space is critical in a effort to help identify which units will suffer the same fate, no avail. Have also been informed that even the RC and BETA software don't have any fix for this issue. These units were installed approximately 3 years as part of a large project and it's almost as if the internal storage has been filling up eversince and reached a critial threshold causing this anomoly, so I suspect that most units that are part of this fleet will have the same fate at some stage. There is a detailed internal document regarding this issue however it's not public facing. Have asked Meraki to reference the bug ID and a commitment that the issue has high visibility with L4 engineering. Hopefully my customer will swallow that instead of a RCA. Cheers
... View more
Nov 20 2019
12:59 AM
3 Kudos
Negative, MX’s participating in HA are only active-passive, at least in the current software. The active MX can however utilise dual wans simultaneously, if applicable. hope this helps
... View more
Oct 29 2019
4:40 PM
1 Kudo
Hi @cmr As the 15.x release is in BETA, support will be limited and it wont fly with the customer. Glad it's functional for you though. Cheers
... View more
Oct 28 2019
10:38 PM
2 Kudos
After raising a ticket I got the following: This is not a supported design for MX devices. MX may still be able to pass the traffic on the LAN side without any WAN or cellular connections. However, this will be no visibility of the configuration and operation of the device and not able to modify any configurations. Please review this documentation regarding the behavior of MX loss access to the Meraki Cloud. Thanks! https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Behavior_during_Connection_Loss_to_Cisco_Meraki_Cloud good to know! Cheers
... View more
Oct 27 2019
11:03 PM
Thanks @PhilipDAth RE: Proxy, that is exactly what I want to confirm. Passthrough no go, as the MX will be the MPLS router itself, so must be in routed mode. Could use WAN1 for MPLS but then it will NAT which isn't ideal for site to site traffic. Arrrrhh When is the No-NAT feature going gold again? this would solve this issue and many others I have. Cheers
... View more
Oct 27 2019
10:39 PM
Thanks @HitoshiH Was hoping someone else in the field had actually tried this already saving me being the guinea pig. I will have to setup a lab otherwise, thought I'd try here first though. Thanks
... View more
Oct 27 2019
10:12 PM
Greetings! I have a interesting tbc scenario in which a MX won't have anything connected to WAN1 or WAN2 or USB cellular.(until NBN is installed) However there will be a MPLS link connected to a LAN port. The MPLS will provide site to site connectivity. The HQ which hangs off the MPLS has a proxy server and a local internet breakout. I wish to deploy a MX in this fashion whilst leveraging the proxy server at the HQ not only for the MX management but for clients on the LAN. This would be the mode of operation until the NBN service is installed. Seeking some clarification that this would work. Not sure how the MX will behave if there is nothing connected to WAN1 / WAN2 or cellular. Anyone had any exposure to this in the field? Thanks in-advance
... View more
Sep 16 2019
3:27 AM
Having a no NAT function would certainly open up more possibilities, which is why I’m stinging for the gold release with this feature. i have many use cases for this feature but have had to re-engineer accordingly with alternate products. hopefully we don’t have to wait too long cheers
... View more
Sep 16 2019
12:36 AM
2 Kudos
Hi Jai1, I'm assuming you have a internet service hanging off the MPLS network upstream somewhere? Since you have no local internet break out this gets complicated. The default route for a MX is always a Internet Port, not another vlan'd interface (MPLS). The assumption with the MPLS failover to Auto-VPN is that you do indeed have a local internet breakout. The other complication is that if you assign the Internet port on the MX to face your MPLS service your MX will automatically perform source NAT, as you mentioned before the No-NAT feature is only available in BETA at this stage so definitively not suitable for prod environments. If your after a DHCP mechanism at each site perhaps the telco provided router can have DHCP relay configured for each vlan pointing back to the Head Office DHCP server? You could also have a suitably spec'd MX at the Head Office which faces a local internet connection in which you could perform the client VPN termination and leverage the Advance License (webfiltering, amp etc) Cheers
... View more
Kudos given to
My Accepted Solutions
| Subject | Views | Posted |
|---|---|---|
| 6403 | Dec 7 2020 12:45 PM | |
| 2397 | Jun 29 2020 7:38 PM | |
| 2431 | Jul 29 2019 4:43 PM |
My Top Kudoed Posts
| Subject | Kudos | Views |
|---|---|---|
| 4 | 2021 | |
| 4 | 2473 | |
| 4 | 34962 | |
| 3 | 5452 | |
| 3 | 9177 |
© 2024 Cisco Systems, Inc.
