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

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

@nickydd9 wrote: I think @jdsilva understands this entirely, he's just trying to get @LuigiJuve to arrive at that answer on his own.... 😃  Shhh! 😉 ... View more

Hi @LuigiJuve ,   No where in there did you designate that VLAN as heartbeat. You simply created a VLAN, assigned it a subnet. Can you please clarify what makes this VLAN a heartbeat VLAN different from all the other VLANs?   How do you control which VLAN is used for hearbeats?  ... View more

@RichardChen1 wrote: Check this out: https://www.willette.works/mx-warm-spare/ Yeh... There's falsities in that and I would not recommend you follow that guide. There are some good things in there, but the whole heartbeat thing is not truly possible and very misleading.  ... View more

@LuigiJuve wrote: I tested many scenarios but the best to get this to work is to have a designated vlan set on the MX for the heartbeat for example vlan 1111 ip 1.1.1.1/30.   Can you please show me exactly how you designate a VLAN as heartbeat?     ... View more

Woohoo nice work @Shadius @Maclanta @MrBear ! Keep it up!   @Network-dad very well deserved. You were a power house this month. Well done!   Yeh yeh you guys too @PhilipDAth @BrechtSchamp  😛 ... View more

Yeh that's odd. Maybe things don't work the way I think they do?   Are you doing full tunnel or split tunnel? ... View more

@swifty wrote: In fact I was successfully using the SD-WAN, VPN traffic, Uplink selection policy to send particular traffic down WAN2. (otherwise with WAN1 as the primary uplink, WAN2 would never get a look in) So are you saying you're using the VPN Traffic section for Internet breakout traffic? ... View more

I'm not even sure I can name 11 types of eggs... But here goes!   Fried eggs Poached eggs Basted eggs Scrambled eggs Omelette Quiche Hard/Soft boiled eggs Deviled eggs Pickled eggs Egg salad ... ... ... Um... Easter eggs? Do they count?   Welcome!   ... View more

Ahh, gotcha. Yeh I assumed you meant AutoVPN traffic. Unfortunately, there is no way to monitor traffic forwarding that's being done through the Internet Flow Preferences section that I'm aware of, at least not in a meaningful way. You can see how much traffic each uplink is passing on the Uplink tab of the Appliance Status page, but that's about it. If you just want to test it to confirm it's working you can create a rule for a device and visit What is My IP to verify that you have egressed the correct WAN interface, but I know that's really not what you're asking. 😞 ... View more

Hey @swifty,   You can monitor the policy under Security & SD-WAN > VPN Status. The lower section of that page contains "Uplink Decisions" where you can see which flows have been mapped to which uplink, and the reason why they were mapped there.  ... View more

Totally agree with @BlakeRichardson on this one. Packet capture is the way to go. I would also capture on the MS to compare to the capture from the Mac.    https://documentation.meraki.com/zGeneral_Administration/Cross-Platform_Content/Packet_Capture_Overview     ... View more

Hey @Jwiley78,   You need a minimum of 3, max of 4.    One for the upstream gateway (likely your ISP, but not necessarily) One for the physical WAN port of each MX (two total) Optionally, one IP for the VIP These don't need to be public, but they do need reachability to the Internet, and should all be in the same subnet.    The physical WAN IP's are so each MX can maintain a connection to the Meraki Cloud. The optional VIP is used to provide stateful NAT failover. If you do not require statful NAT failover then you can omit this IP and just go with the IP for each physical WAN port.  ... View more

Uh oh... There goes the neighbourhood.   I mean, welcome @noblinkyblinky !   🙂 ... View more