You should be able to retain your CCO account. I've had the same one for almost 20 years now, I just change what company I'm associated to.    Also, I hope a CONGRATS! is in order for the new job 🙂 ... View more

@KarstenI Not planned per se I don't think, but more a side effect of the way NAT was implemented. @GiacomoS commented on this solution in this post:   https://community.meraki.com/t5/Security-SD-WAN/HairPin-Nat-Loop-back-NAT/m-p/24563/highlight/true#M5921 ... View more

It's possible, but not in the way you think. Please see this thread:   https://community.meraki.com/t5/Security-SD-WAN/HairPin-Nat-Loop-back-NAT/m-p/24563/highlight/true#M5921     ... View more

Sorry, maybe I misunderstand, but are you just trying to do a full tunnel from the spoke to the hub? You can do that in the site to site VPN settings:     You cannot put a default route with a next hop reached via a LAN port. That will break the MX completely as it interferes with the WAN port reaching the cloud. If the WAN port can't reach the cloud then the MX doesn't forward traffic. It will also interfere with AutoVPN and establishing tunnels.    The above isn't true and I misspoke.   ... View more

Well done everyone! Great work. ... View more

This was a fantastic podcast. @BrechtSchamp and @PhilipDAth are simply the bee's knees!     ... View more

I'd suggest actually doing the opposite. Set the HQ as the primary DNS server, and the OpenDNS as the secondary.    I assume the HQ DNS is configured to use OpenDNS itself for zones it's not authoritative on?     ... View more

Hey @Scott_Sassin,   You just hit on a use case that is not truly supported by the MX. In order to do this you'd have to create either individual port forwards, or 1:1/1:Many NAT entries for every inside host... Or more likely a combination of all three of these. None of those are good options for you, or going to actually be manageable. Sorry 😞 ... View more

Good stuff!    Just remember that when you start dealing with networks over 1000 clients you're going to have to revisit this and figure out how to fetch the 'next' page to get the remaining clients. The next URL is returned in the headers of your first request, so you have to get that URL, and then make a GET to it. The next URL will be populated as long as there are more clients to be returned. When you've got them all the next URL value will be NULL.     ... View more

If I was to guess it's because you're either not setting the 'perPage' value to something greater than 10 (default is 10), or you're not fetching the 'links.next.url' returned in the headers of the first (and subsequent) requests you're making.      ... View more

@Mikeylad I'm not following why you want to clone a network at all. Do you have a specific reason why you want to clone? I don't agree with your statement that the cloning method is the best way. How did you arrive at that conclusion?   That said, perhaps an explanation of combined networks will help clear this up?    Combined networks are actually just a little bit of sleight of hand on Meraki's part. A combined network is actually just a container that has the actual device type specific networks inside. So if you have a combined network with MX, MR, and MS, you really still have three networks that are being shown to you as a single. This is why you can split them and combine them any time you want.    If you clone your combined network, and add a new MX to that network, your original network is still there and functioning as it always would. If you move devices between networks then yes, there is a brief period of time where technically the devices do not have a config. There's a "move to new network" action you can do, and in that case the time the device doesn't have a config is essentially nil, however if you have any device specific configs (radio settings on the AP's for example) then you need to set those again in the new network as they do not clone over.    None of this is the simplest way though. I would suggest you take another look at the KB I linked to, and check out Method 1 again (Quick Swap). If all you need to do is replace the MX then simply removing the old one followed by adding the new one to the existing network is far and away the simplest method.  ... View more

I'd start with this doc:   https://documentation.meraki.com/MX/Other_Topics/MX_Cold_Swap_Replacing_an_Existing_MX_with_a_Different_MX     ... View more

Sure, the members are the ones asking questions and engaging in conversation in the community, but none of that could happen without the work of @MeredithW and @CarolineS who ensure we even have a platform in the first place. Congrats to the two of you, and all rest of the Meraki team who keep this place running! ... View more

Congrats @Johan_Oosterwaa and @Greenberet !   Great job to the top four too! ... View more

There is no alternative with Meraki to extend L2 between sites like that. You'll need to go elsewhere for that functionality.  ... View more

No. You will need some sort of middleware no matter what. The output format of Meraki webhooks is not compatible with MS Teams and must be modified to match. Neither system offers the functionality needed to make this format change to the data on the fly, so you need a third system.  ... View more

Unfortunately, no. You can't monitor anything other than Meraki in the Meraki dashboard. You will need another solution to monitor other vendor's devices.  ... View more

Congrats @Network-dad & @DarrenOC ! Very well deserved! ... View more

@LuigiJuve wrote: jdsilva, so what do you mean my 15 installations are not working please explain.. Sorry, I think I didn't make that statement very well. I was trying to say that yes, your deployments are probably working just fine under normal network conditions. But, based on your comments around the heatbeat VLAN I do not believe they are working the way you think they are working. If you believe that you have a dedicated VLAN that's being used purely for heartbeats then you are operating under an incorrect assumption, and you don't fully understand how your network is operating. Again, I'm not trying to be harsh, I'm simply trying to point out an incorrect assumption and help you understand the way Warm Spare actually works 🙂       @PhilipDAth wrote:   My understanding is if VRRP fails on any VLAN the entire unit fails over.  I don't think this is true, and the way I read the doc you linked to doesn't support that.    Because the MX uses a single VIrtual Router with multiple Virtual IP's it can't actually detect a failure of a single VLAN. The heartbeat sent on each VLAN is identical to the heartbeat sent on every other VLAN. The only thing that the MX VRRP process is able to detect is whether it received a heartbeat at all within the dead time. As long as any heartbeat reaches the standby it will not assume the Master role. It must have a complete and total loss of all heartbeats on all VLANs to make the transition.  ... View more

Hi @LuigiJuve,   I'm not saying it won't work. What I'm saying is that it's not possible to configure a "heartbeat VLAN" as described in that document. It's a completely false pretense to think that this supposedly magical VLAN is any different from any other VLAN you have configured. As @NolanHerring pointed out, VRRP hellos (the "heartbeats") are sent out on every VLAN. Further, Meraki's implmentation of VRRP has elected to use a single Virtual Router with multiple Virtual IP addresses as opposed to a Virtual Router for each VLAN, meaning, that as long as a VRRP heartbeat makes is to the standby unit on ANY vlan the current active master will remain the master for all VLANs. It's not possible for only one VLAN to fail over. This is truly and Active/Standby only implementation.   So please forgive me if this sounds harsh as it's not meant to, but your 15 installations are not working because you followed that guide, and they also are not working the way you think they are working.   This is actually my objection to this configuration, and Aaron Willette's design. It's based on a falsity, and that falsity has been propagated to many corners of the Internet. Quite often people chime in here in the Community and reference that design, and nearly every time the person making the reference has no idea that it's simply not possible to actually designate a VLAN as a "Heartbeat VLAN".   My preferred way to do Meraki Warm Spare, which has come from my own experience deploying Warm Spare for numerous customers, and through the very insightful advice of @PhilipDAth, is to NEVER EVER directly connect the two MX appliances together, and in stead singly connect each MX to a single switch or switch stack (the latter preferred for redundancy). See, having the MX's directly connected actually can cause issues under certain failures with Spanning Tree convergence. Further, it's also desirable to have the VRRP heartbeats traverse a path more representative of the path that user data actually takes. By creating a shortcut that heartbeats can take, but not user traffic, you are actually exposing yourself to a failure scenario where user traffic is blackholed, but VRRP is operation just fine and not allowing a failover to occur.   Failovers are a good thing! You want failover to occur when there's a failure. A direct link cheats the system and can actually prevent a failover when you actually want one.   I'll close this by pointing out that Meraki has actually changed their recommended topology for Warm Spare by removing the direct connection between MX's. It took me some time to convince them to do it, but they did come around 🙂   https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair#Recommended_Topologies     ... View more