Meraki

cmr · ‎Apr 3 2022

The existing connections should stay up, but if they do go down, then they will not re-establish until the access to the Meraki cloud VPN registry has been restored. In our case we can take down our internet access at the main DC and we don't see any interruption to the site-to-site connections over the MPLS.

cmr · ‎Apr 1 2022

We always get at least 3 IPs so it is just for the physical switch, if you only get one IP then I'd get a basic router to NAT the WAN interfaces of the MXs, we do this where we have to have a VDSL circuit as you'd need a modem anyway so might as well get the ISP to provide a router that also gives you multiple IPs.

cmr · ‎Mar 31 2022

Tried on the site where we actually need it and just couldn't get the SD-WAN to come up on the direct internet connection. It works fine for internet traffic, no errors anywhere, just the tunnels don't establish. The only difference between the sites is that the working one has MX100s and the failing one has MX84s. We've got support to arrange a downgrade to 15.44 to see if it makes a difference and replaced the patch lead to the new ISP device, which made 4 out of the 11 tunnels come up, spread randomly across three of the other sites....

cmr · ‎Mar 31 2022

We always put a switch in between the ISP NTE and our firewalls as in the UK you only ever get one port per service. I generally use Cisco small business unmanaged L2 switches and have had great reliability with them. We don't count it as a single point of failure as we have two ISP connections at each site 😉

cmr · ‎Mar 30 2022

Another option would to have the guest SSID tunnel back to an MX, that would remove the layer-3 roaming load from the MR in reception.

cmr · ‎Mar 30 2022

It has to be... Alan Jackson, Jimmy Buffett - It's Five O' Clock Somewhere (Official Music Video) - YouTube For the audio, not the video...

cmr · ‎Mar 30 2022

There are two radios in each MR (2.4 and 5) and it is the number of clients per radio that matters for local connections. The anchor is only for layer-3 roaming SSIDs, are you using them then, and if so why? They are only needed if the same SSID has different subnets underneath it, i.e. 10.1.1.0/24 at reception and 10.1.2.0/24 somewhere else on site.

cmr · ‎Mar 30 2022

@Thygesen a few things you can try: Reduce transmit power on this AP so that the signal drops off faster as you move away Increase minimum bit rate as well, for the same result Split the employee / guest SSIDs onto different bands, we put guests on 2.4 and have corporate devices on either 5 or both.

cmr · ‎Mar 30 2022

If the Meraki cloud, or more importantly access to the VPN registry part of it, is lost then the following should happen: Existing VPN connections should remain up New VPN connections cannot be established There isn't a timeout on this as far as I am aware. for example: You have Meraki devices talking over an MPLS circuit that has internet breakout allowing them to talk to the cloud / registry. The internet breakout goes down, but the MPLS stays up The VPN should stay up, but it wouldn't re-establish if there was any outage before the internet access returned.

cmr · ‎Mar 30 2022

I think only internet traffic makes it appear on the list, as I have seen the same with devices like Dell iDRACs where they hardly chat at all unless you connect to them.

cmr · ‎Mar 29 2022

That is truly pathetic from support, how on earth could a device firmware issue affect data sorting on the dashboard?!? Tell them to try harder from all here! In case they need to see up to date firmware, we have sites where everything is up to date and we have the same issue, shard 184.

cmr · ‎Mar 29 2022

@ToryDav do you need meshing? We commonly disable it and I think that would stop the issue occurring?

cmr · ‎Mar 29 2022

Managed to test with a mix of MPLS and internet and did get it balancing across the two. A couple of observations: You have to disable virtual IP for both WANs, it would be better if we could have a VIP on one WAN and use MX IPs on the other. The virtual IP has to be static so having one carrier on the primary MX with the other on the secondary forces disabling VIP. If it supported DHCP this would be better. When the primary WAN (over MPLS) no longer has connectivity beyond the local site (MX physical interfaces still up), it takes about 5 minutes for the WAN IP at the top of the interfaces tab to update and even when it has, on the VPN status page it says no connectivity to VPN registry and the NAT type shows the now disconnected IP and NAT type etc. However the VPN actually only has 15-20 seconds of downtime at most. I left if for over 10 minutes to see if it would fix itself. Putting the MX WAN ports behind another MX in the same Org caused the VPN to never come up. No firewall rules blocking anything so not sure what is going on there. Might be something to do with it being the DHCP server for the switch VLANs behind the other MXs...

cmr · ‎Mar 28 2022

Thanks @Ryan_Miles I am going to test this tomorrow and will report back what I find 😎

cmr · ‎Mar 24 2022

28.6 fixes this issue (at least it has for most people and support confirmed that the release is intended to fix it.

cmr · ‎Mar 23 2022

Also, the fibres are MPLS, so the tunnels are built using the actual device WAN IPs, whereas the VDSL and MG are internet, so would build direct to the main DCs internet IP (as opposed to its actual WAN port IP). Do you foresee any issues there?

cmr · ‎Mar 23 2022

So to move from where we are, I'd guess we delete the virtual IPs, that should then allow us to assign the VDSL and MG IPs to the warm spare device's WAN ports. If both fibre WANs went down (as is expected in the roadworks), then the SD-WAN would just rebuild over the VDSL and the MG, as they are load balanced for fibre and the MX doesn't know it has different circuits now... How would the solution deal with the fact that the fibre and VDSL/MG bandwidths could be very different, is it just a 'hope' moment?

cmr · ‎Mar 23 2022

We want to load balance the two main connections and have a backup VDSL and cellular as connectivity is critical to us. They are all HA pairs and I've been asking for 4 years so far, but still live in hope! I'm thinking we might need to double stack MXs, bit that really isn't the cleanest design.

cmr · ‎Mar 23 2022

I saw when the MX85/95/105 models were released that the datasheet say only two active WAN ports are supported at the moment. This suggests that we might finally get the ability to have more than two connected WANs (excluding built in or USB cellular) in the not too distant future. Is there any estimate of timeline on this as I cannot be the only customer who really needs this feature? For anyone interested, we always install two fibre lines at each site with as much diversity as possible, but I'm now approaching the third occasion when both are affected by roadworks at the same time meaning we have to hook up a temporary Copper-fibre hybrid connection and an MG to try and maintain connectivity. Having more WAN ports, even only as failover, would be a godsend. Please Meraki, please!

cmr · ‎Mar 23 2022

I have just checked a coupe of HA pairs and have: VPN concentrator mode - MX16.15 - virtual MAC beginning cc:03:d9, physical MACs begin e0:cb:bc (primary) and 68:3a:1e (warm spare) Routed mode - MX16.16 - virtual MAC beginning cc:03:d9, I don't see physical MACs

cmr · ‎Mar 23 2022

@Anonymous Unfortunately you are one model too low 😞 The MS250s and up can run a DHCP server.

cmr · ‎Mar 21 2022

The list of clients under a switch still seems okay, and occasionally the main clients list sorts properly, though I can't seem to find a repeatable way of getting it working...

cmr · ‎Mar 18 2022

If you search this forum you will see that it has been going on for a long time, bit was only recently flagged on the dashboard. Previously it was hidden in the event logs. We have about 4-5 APs that have shown similar in the last 2-3 weeks.

cmr · ‎Mar 18 2022

@NetEngJH same here in the UK both lo and hi and the UNI4 channels only where MR56s exist.

cmr · ‎Mar 16 2022

I agree with @Inderdeep as the other document has the same for all models and that is not correct!

About cmr

cmr

Community Record

Badges