About Ryan_Miles

Ryan_Miles

It would need to be tested, but the other option would be place 2 APs in 2 different networks. Each network would contain one gateway and one repeater. That would keep the repeater assigned to a single gateway AP. No idea how the switch would treat it though. I'd have to set up a lab to test.

Ryan_Miles

I would not expect this to work as it's effectively this unsupported topology https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireless_Mesh_Link#Unsupported_Topology_Example:_Additional_MR_on_Remote_Side

Ryan_Miles

You should contact Meraki Support and have them roll you back to 25.13 and monitor if the issue still persists

Ryan_Miles

Any of the MX license levels will support what you stated. For the full list of features for each license level refer to this doc https://documentation.meraki.com/General_Administration/Licensing/Meraki_MX_Security_and_SD-WAN_Licensing#Features_by_License_Option

Ryan_Miles

The CW9164 PoE requirements are in the datasheet https://documentation.meraki.com/MR/MR_Overview_and_Specifications/CW9164_Datasheet#Specifications It can operate on 802.3at and bt. There is no supported low power mode on af power.

Ryan_Miles

I run RADIUS with WPA3 and have seen no issues.

Ryan_Miles

You lost me with your topology explanation. However, the two common topologies we recommend are documented here https://documentation.meraki.com/MX/Deployment_Guides/MX_Warm_Spare_-_High_Availability_Pair#Recommended_Topologies MXs don't participate in STP, but the BPDUs from switches will flow through the MX LAN ports as long as you aren't dropping untagged traffic. As long as STP is configured properly on your switches spanning tree behavior should behave just as if the switches were directly connected as the MX LAN is just kind of a passive bump along the way in this design. I also have an animated deck showing the behavior of MX HA and dual switches in this deck https://docs.google.com/presentation/d/1yFB7tffTaBexz2mq7UWBJaUiiGhV45bzIZRmuo3b7R8/edit?usp=sharing

Ryan_Miles

Passthrough where you connect the WAN port and a LAN port is for placing the MX inline and doing traffic inspection and optional enforcement. If you want to use the MX for SSID tunneling you should be using concentrator mode topology in which you only connect the WAN port. The MX would typically reside in a DMZ network only connected via its WAN port. All traffic entering and exiting on that same WAN interface. I show an example topology in this old thread https://community.meraki.com/t5/Wireless-LAN/Reference-architecture-for-Guest-SSID-tunneling/m-p/151519

Ryan_Miles

Customer premise is maybe a little vague. It means when using "my RADIUS server" vs. local auth or Meraki auth. My RADIUS server can be on prem or cloud hosted. I use Jumpcloud with the RADIUS attribute of Filter-ID to assign a Group Policy I have defined in Meraki dashboard and it works fine. AnyConnect VPN should also be able to leverage a Meraki defined GP. I haven't tested it though.

Ryan_Miles

It's important to understand how Sensors communicate with gateways. It's not like a wireless client connecting to an AP in which you typically expect a connection to the nearest AP based on signal strength. The Sensor periodically wakes up and sends an advertisement. That can be intercepted by any gateway in the same dashboard network and within BLE range. The gateway will reject the connection if heard at less than -85 dBm. We still report these connections in dashboard however which helps to show which gateways are out of usable range for each Sensor. In the table above I assume the gateway is what shows on the Sensor overview page RSSI column? That will report the most recent gateway to hear BLE from the Sensor (even if worse than -85 dBm). That doesn't mean it's the only gateway that heard it nor is it the best RSSI gateway. You can see the entire list of gateways that hear the Sensor by drilling into the Sensor detail page and viewing the Device details tab. Finally, the gaps in the charts. I too see that every now and then specifically for my MT40s. I've also chatted with MT Prod Mgmt about it. Please open a Support case on this one so it can get some visibility.

Ryan_Miles

The C9800-L-F-K9 is a Wireless Controller and we don't today support this in dashboard

Ryan_Miles

You could move to templates but that does require evaluation, testing, and downtime. If you plan to remain non template bound the API would be the way to go. https://developer.cisco.com/meraki/api/update-network-wireless-ssid-firewall-l-7-firewall-rules/

Ryan_Miles

Meaning you have other mesh repeaters APs in this network and people could gain access to it physically to connect to the eth port and it would still be powered via some other source? The wired port config is a network wide setting. I suppose the only way to limit the scope here is move two APs to their own network. One is the gateway and one is the repeater.

Ryan_Miles

This thread contains a diagram of how to connect a passthrough mode MX https://community.meraki.com/t5/Security-SD-WAN/Physical-connections-for-MX-in-passthrough-mode/m-p/127859

Ryan_Miles

For a visualization it should look something like this example. Just make sure in Network-wide you map the "clients wired directly to Meraki APs" to a SSID with the VLAN you want. It can be any bridge mode SSID including a SSID already used for regular wired clients.

Ryan_Miles

I would not expect that to extend your time. But you can give it a try.

Ryan_Miles

You should have applied this license key as a renewal. If it's been less than 7 days since you claimed the license undo the claim then re-claim the new key as a renewal. https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview/Removing_and_Undoing_License_Claims_-_Co-Termination_Licensing#Using_the_Undo_License_Tool

Ryan_Miles

This topic has been covered over and over on the Community. If you can't find the original owner to have them remove it from their network then you cannot use it.

Ryan_Miles

Refer to this doc https://documentation.meraki.com/MX/MX_Overviews_and_Specifications/WAN_behavior_on_MX75%2F%2F85%2F%2F95%2F%2F105#MX75 On the MX75 the first 2 ports are both "WAN 1" and you can only use one or the other. It will detect for presence of a SFP on boot.

Ryan_Miles

I'm not completely following you here or understand quite what outcome you're trying to achieve. However, I will say GPs in templates are for MX and MR and only would apply to MX and MR devices in networks which are bound to the template. A switch in a network bound to a template also need to be bound to the switch template (inside the main template). But again, GPs don't apply to switches directly in anyway. There are ACL GPs for switches, but that's a different thing https://documentation.meraki.com/MS/Access_Control/Meraki_MS_Group_Policy_Access_Control_Lists.

Ryan_Miles

If the previous owner doesn't remove it from their network you're stuck

Ryan_Miles

I agree with @alemabrahao and keep it simple. Put APs in a mgmt subnet. Drop clients in another subnet(s). A /22 isn't unreasonable for wireless networks. And with our APs you can use L3 firewall rules to stop some of the noise if you want (example, deny netbios and other unnecessary and chatty protocols). Not sure how many SSIDs you intend to have, but fewer is always the aim. As for the clients joining APs on other floors. There's nothing inherently wrong or bad about that. As @alemabrahao said roaming is a client decision and if a client can obtain a usable signal from another floor AP so be it.

Ryan_Miles

How are you measuring throughput? From the Tools tab on the switch or from a wired client using some other test method? If you're talking about the Tools tab throughput test that won't show maximum speed of the switch or internet circuit. Not even close. And, MS390s will generally show a much faster throughput using the dashboard test tool versus traditional models like MS35x, 2xx, 1xx due to underlying architectural & software differences. To measure wired client throughput you should be using standard tools like iPerf, speedtest.net, etc. Are you troubleshooting a specific issue here or just seeing unexpected results using the throughput test?

Ryan_Miles

https://documentation.meraki.com/General_Administration/Tools_and_Troubleshooting/Throughput_test_to_the_Cisco_Meraki_Dashboard#Comparing_to_Similar_Throughput_Tests

Ryan_Miles

Seeing as that's a MX specific alert I'd say yes that's your issue

Ryan_Miles

Ryan Miles

Community Record

Badges