Meraki

rhbirkelund

Bridge mode, or configure your ISP router to open or forward 2223 to your MX.

rhbirkelund

Yes, if the Uplink IP is set to 10.1.10.97, that means it's being NAT'ed. Your WAN interface simply shows your public IP address in the same way as if you'd use any tool on the internet to view your public ip, from your PC. You'll need to put the ISP device into Bridge Mode.

rhbirkelund

For good measure, could you try and replace your external IP on the Forwarding rule with "Any"? Allow the MX to update it's config, and then try to SSH to port 2223, then. Also, you mention that the MX has a Public IP on it's WAN. Is that also what you see when browsing to Appliance Status and clicking on the Uplink tab?

rhbirkelund

You might want to ensure that the openssh-server is installed on the Debian aswell. "apt install openssh-server"

rhbirkelund

Does anyone have more details on what this bugfix is about?

rhbirkelund

I'm rather intrigued about this as well!

rhbirkelund

Yes, both APs are supported on MS220 and MX84.

rhbirkelund

Instead of going to MR44 I'd go directly to WiFi6E due to the longer lifetime. MR44 is simply a WiFi6 AP. A Wifi6E AP could be CW9162-MR or CW9164-MR, as @rwiesmann mentioned. But before going the lengths of replacing APs due to IoT sensors going offline, I'd tweak the wireless settings first, and ensure that it isn't a configuration issue.

rhbirkelund

The IoT devices, are they Meraki MT sensors? I would look into tweaking the Wireless settings. IoT devices usually don't support modern technology, and even in some case don't support 5 GHz. Configure an IoT SSID for 2.4 GHz only using PSK, and enable datarates to make it more robust. On the RF profile in Radio Settings, make sure you have Client Balancing disabled, and as well as disabling Band Steering for your IoT SSID. Target Wait Time would only really be relevant towards llimiting power consumption.

rhbirkelund

IoT devices are notorious for not supporting modern technology. Why do you suspect that the issue might be your APs? What wireless standards do your IoT devices support?

rhbirkelund

Have you added the LogicMonitor IP address to the SNMP field on the Firewall page?

rhbirkelund

When you say vanity url, do you mean simply putting e.g dashboard.meraki.com as the logout url?

rhbirkelund

Oh, I agree.

rhbirkelund

What @RWelch is mentioning is most likely the thing that you are seeing. What networks are combined, containing network types for devices you don't have.

rhbirkelund

Did you try setting the APN manually? MX19.1.3 has some bug fixes relating to improved reliability on cellular connections on MX68, as well as a fix to a rare MX18.2 regression making MX68 not able to establish cellular connection on the integrated cellular. Perhaps you should consider moving to MX19.1.6 which has also been upgraded to Stable RC.

rhbirkelund

Is there by any chance an "Events Dropped" event? This usually indicates that there's been a burst of the preceeding event.

rhbirkelund

Same with missing updates on the Campus LAN Deployment Design guidelines https://documentation.meraki.com/MS/Meraki_Campus_LAN%3B_Planning%2C_Design_Guidelines_and_Best_Practices

rhbirkelund

Have you configured the network to the correct timezone? Looking at the eventlog, in the Time column, you can see the timezone, in a light grey color. You could also go to Network-Wide -> Configure -> General, and verify what timezone has been configured for the network.

rhbirkelund

You should also be able to poll CPU utiliazation via SNMP polling.

rhbirkelund

I would pull the Meraki Manangement interface out as a single vlan on an Access port, to ensure you don't risk getting WAN traffic L2 broadcasted into your core. Since Meraki also does Application Visibility stuff, I would also put the MS130 as a WAN switch in its own Meraki Network, thus not mixing it with the rest of your enterprise network. This allows you to patch your company switching layer irrespective of patching your WAN switch. That being said, there's some discussion on whether to use a managed switch as a WAN switch compared to using an un-managed. Some prefer one over the other, with pros and cons. For a managed switch: Pro: It's a managed switch. Con: You have to manage it. For an unmanaged: Pro: You don't have to mange it. Con: It's unmanaged. The WAN switch is only responsible for switching traffic. It shouldn't do any L3 forwarding, so is it really neccessary to use a managed switch?

rhbirkelund

I seem to recall, being told that it also shares the PMKID and PTKIDs, for Oppotunistic Key Caching. Unless I'm mistaken?

rhbirkelund

Congratulations everyone! 😄

rhbirkelund

One of the reasons for not putting all APs in the same network, is due to that fact that all roaming information, 11k/v, etc are shared between APs witihn the same network. If you have APs at different sites, but in the same network, they would essentially be sharing neighbor information, keys and sessions. Especially when using 11r Fast Transition. So you'd have APs at site A having information about clients at Site B, and reverse.

rhbirkelund

Is there a certain reason you wish to restrict bandwidth for guest and corporate? You might want to consider that restricting bandwidth may result in poor airtime utilization.Have a look at Jim Palmers session on rate limiting from WLPC.

rhbirkelund

Can you confirm with the other end of the 3rd party VPN, that they are building a tunnel towards the WAN1 uplink. and not WAN2?

About rhbirkelund

rhbirkelund

Community Record

Badges