Hello @RWelch ,   Thanks for bringing this up.   @GIdenJoe is correct. I'm working with Internal teams on adding this info.     ... View more

Hi @Peter-DG ,   It looks like your non-Meraki switch is manageable because it has an IP address within VLAN49 IP address range.   I suspect your non-Meraki switch has the port connecting to your Meraki switch configured as Trunk, Native VLAN = 49 and Allowed VLANs = 49 and 50. Probably you have the port connecting to your MR Access Point (AP)configure the same.   Therefore, check if you non-Meraki Switch has a configuration interface. Usually, you just put the switch IP on your web browser. I assume you have the administrator password.   Then, make sure you non-Meraki Switch has all the three VLANs associated with your SSIDs. Finally, configure the Trunk ports connecting to your MEraki Switch and to your AP as Trunk, Native VLAN = 49, Allowed VLANs = (all three VLANs). ... View more

My pleasure! Doc is updated now! Thanks for bringing this up. ... View more

Hi @HectorM ,   Those are 10GBASE-SR (except the one at the bottom which is LR).   If you check our SFP and stacking accessories doc, you'll see MS250 supports this SFP.   I'm not a Cisco Catalyst or Nexus engineer, so I would check with Catalyst or Nexus support if your switch needs the commands @ww mentioned. This Catalyst doc has more details.   # no errdisable detect cause gbic-invalid # service unsupported-transceiver   Some older Catalyst firmware may have problems with those commands to support non-Cisco transceivers. Just make sure your OS image doesn't have any issues with those commands.   In the other hand, Cisco Meraki dosn't have any restrictions to third-party transceivers. As per our doc, "Cisco Meraki offers branded SFP modules, and while we do not prevent third-party accessories from functioning, users should conduct their own tests to ensure proper compatibility"   As @cmr said, checking the cable distance is a good idea; if it's below 300m I would double-check if the cable is the correct type. E.g.: MMF - OM3 instead of OM2 or OM1. Again, check this table to make sure your cable is correct.   I suspect you did it but I'll say it anyway: test your SFPs  in a switch that you know the SFP slot works fine. Next, try the known good SFPs in your deployment here.   And then, try swapping the SFPs between your switches. E.g.: insert the purple tag SFP in the Cisco Switch and the white tag SFP in your MS250; if you don't get a link UP, invert them; keep doing this until you try all combinations.   If all the above fails, then most likely your cable is damaged. ... View more

Well, that makes sense. That wifi client failed authentication so it was stuck in association phase and having no traffic after RADIUS Access-Reject message. It's essentially the same behaviour described in the doc.   This seems to be an expected behaviour since it is an unauthorised client. Unauthorised wifi clients show as connected with zero usage as long as the Access Point confirms they are associated.    I'll work internally to reproduce this scenario and add this behaviour to our doc. ... View more

Hi @RaphaelL    Thanks for bringing this up.   The document you mentioned has this section: "Clients List Displays Zero Usage for a Client, Though the Client Is Passing Traffic To ensure useful data usage and traffic analysis, certain types of client traffic are filtered and are not counted toward their network usage. Usage information is recorded differently depending on the network layer the client is operating at. Examples of such traffic are: Unauthorized clients that are operating behind a splash or captive portal DNS DHCP ARP Note that the above does not apply to switch clients."   Do you see that behaviour you described in a Guest wifi SSID that has splash or captive portal? ... View more

Whenever I see IP address conflict, I like to check the offending MAC Addresses in Wireshark OUI Lookup Tool. This tool can return the Interface vendor so you can have a better idea of what device or client is related to this issue.   When the Wireshark OUI Lookup Tool can't find the vendor, then there is a good chance it's the Operating System doing MAC Address randomising.   Either way, in most cases it's like @PhilipDAth and @Brash explained. ... View more

Hi @LukeSkyWalker , yes but it will also depend on the Switch PoE capability.   As per the MR36H datasheet (Power section), "Power consumption: 30W max (802.3at) or15W max (802.3af) - low power mode (Disables POE out functionality)".   So this means that if your switch is PoE+ (802.3at) your Phone can get energy from your MR36H. However, if your switch is PoE (802.3af) only then you will not be able to use the PoE port in your AP.   We advise you to read the MR36H datasheet carefully.    The back of the APs have two ports but only one can be used as uplink connection to your switch; this is also the port where your AP gets energy from switch. The other port is a "jumper" to the LAN ports.   You can check it on the MR36H Installation guide. ... View more

Hi @LukeSkyWalker , thanks for posting your question here in the Community.   I suspect your switches have some particular VLAN configuration applied to their ports. It looks like you will need to review your switches VLAN design and think your Access Points VLAN accordingly.   As per MR36H datasheet, your MR36H features a "Pass-through port. MR36H has a unique port which is called Pass-through port, which links directly the second port on the back in the first physical port on the bottom of the Access point. This ports works similar to an extension cord, meaning it will physically link the input of the back port to the output of the bottom first port.  The pass-though port it is a physical extension of the lower back port."   So the ports are like a bridge and would belong to whatever VLAN is configured at the switch port, if the port is configured as an Access Port only.   As you know, AP Port Profile is a feature that allows the MR to extend the SSID to devices connected to the AP LAN Access Ports. Basically, AP port profiles map an SSID to a wired port on an Access Point.   I'm assuming you are connecting your IP-Phones to MR36H LAN ports 2 to 4, hence, your phones would get either a VLAN mismatch or a VLAN double tagging, depending on how the old Cisco switch port is configured.   Regarding the APs connected to Catalyst Switch entering repeater / bridge mode, this is typical behaviour when the AP management interface IP and VLAN don't match the switch port; in some cases, it's just a bad ethernet cabling issue (i.e.: Rx and/or TX pair is damaged but PoE pair is fine).   In summary, I highly recommend you check with your sales contact and have a discussion with a Network Architect. You need to review your current switch ports VLAN configurations and probably redesign your VLANs and WiFi SSID vlan association. ... View more

Correctomundo! 😄 Thanks for correcting me, @PhilipDAth !   My apologies, @AY2022 and Community members.   MX doesn't allow you to configure NAT1:1, NAT1:many, Port Forward when the LAN server does not live in a local subnet. If you try, you would the the error below: I'm glad Mx does not allow configuring a NAT or Port Forwarding Rule when the Server is not in a local subnet. This completely prevents the problems I talked about earlier:   Your remote user connecting to 1:1NAT Public IP will experience slowness because the server is behind a VPN Your remote user won't be able to connect if the VPN goes down Remote user may have problems with some applications because the server behind the Spoke MX will have a lower MTU (remember the packets will be encrypted by VPN therefore, there is less space for user data). ... View more

Happy Birthday, Community! May We live on riding this path sharing and helping each other. That's what makes We grow! ... View more

@RobustMeraki , perhaps you would like to take a look at this design guide.   To my understanding: AnyConnect is the remote user client vpn software in the SASE solution context. The AnyConnect software that a user install in their laptop.  It was renamed to "Cisco Secure Client". ... View more

I never tested as well, but I think having SAML and Always ON feature together fits your customer's use-case.   You can have the AnyConnect client vpn software configured with a custom profile where the Always ON feature is enabled. You can read more about it here.   I would also Make sure that MX option Session Timeout is "None" ; doing this would allow a remote user to stay connected regardless of network activity over the tunnel and also reconnect when laptop resumes from sleep state. ... View more

Hi @AY2022 ,   That's an interesting question from an interesting design. 🙂   I understand your remote user will connect to 1:1 NAT Public IP in a HUB MX but 1:1 NAT translates the user connection request to a server behind a Spoke MX. Please, correct me if I'm wrong.   If I'm correct, then your design works. However, there are three problems: Your remote user connecting to 1:1NAT Public IP will experience slowness because the server is behind a VPN Your remote user won't be able to connect if the VPN goes down Remote user may have problems with some applications because the server behind the Spoke MX will have a lower MTU (remember the packets will be encrypted by VPN therefore, there is less space for user data).   In summary, this design is not the best but you have two alternatives: Move your server to the HUB MX Local VLAN Configure 1:1NAT on the Spoke MX and disable IPv4 default route in Site-to-Site VPN settings You can also use Port Forwarding on the Spoke MX if you don't have a Public IP - just don't forget to disable IPv4 default route. Disabling IPv4 default route on the Spoke will fix the routing asymmetry problem.   I'm adding a network diagram below to give you a better idea of the network flows. ... View more

Oh yeah, that works!   But think about the firmware upgrades, not just replacing stack members. Smaller stacks allows for more room to staged upgrades.   In any case, what matters most is your use-case. Like you said, this is an access layer deployment, not a high bandwidth server/SAN setup. ... View more

Ok @DMLUX1 , thanks for adding more details.   So your wifi devices connected to your SSID need to access the following IP list: 192.168.20.50 (printer) 192.168.21.201 (Keiths Airtame) 192.168.21.122 (Joe V Airtame) 192.168.21.156 (Joe M Airtame) 192.168.21.117 (Philly Airtame)   If wifi devices in your SSID are getting IP from Meraki AP (NAT mode) then your MR runs DHCP and does NAT for your wifi device traffic. In this scenario, your wifi devices don't get associated to a VLAN. As a result, there is no solution for you other than redesign your SSID. That's because your AP does NAT and so the wifi devices traffic gets kind of unidirectional - i.e.: wifi devices can initiate a connection to a LAN device but never the opposite way. Most screen-sharing requires BI-directional traffic therefore, this scenario would never work unless you redesign your SSID associating it with a switch VLAN.   I'm assuming your printer lives in a switch VLAN (e.g.: VLAN20) and your Airtame devices live in another switch VLAN (e.g.: VLAN21); I'm also assuming your SSID is associated with yet another switch VLAN (e.g.: VLAN100). Am I correct?   If my assumptions above are correct, then your Wireless firewall rules are correct and the issue might be related to: your switch or firewall doing the routing between VLANs has some Access Control List (ACL) denying traffic between these VLANs. So the solution is you add an Allow ACL. MS Switch ACLs are described here. MX Firewall Rules are described in this other Article here. your wireless screen-sharing relies on some broadcast or multicast kind of network traffic that requires them to be living in the same VLAN. Sometimes We can fix that kind of multicast traffic by allowing it to flood to other VLANs and switches as described here. Other few times you may need to convert Multicast to Unicast. ... View more

Hi @DMLUX1 ! Thanks for your question here. I noticed your question at the Security & SDWAN Forum but this is a better place to get an answers.   I understand you need to block users in an SSID to access local LAN resources but at the same time there is an exception which is your printer connected wired to a different VLAN. Let me know if I missed something.   So the answer is quite simple: you can keep the DENY to Local LAN and add a new rule having ALLOW , protocol ANY, IP address of your printer as destination (e.g.:192.168.100.123/32). It should be a /32 because it's a single device. Here's a screenshot for your reference:   You may want to be more specific and have ALLOW, protocol TCP, IP address of your printer, and then whatever ports your printer needs. For example, I used to have an HP Jetdirect that needed TCP ports 9100 up to 9102:   Lastly, be sure to read and understand this Meraki Article explaining the Wireless firewall options and the Deny Local LAN features.   Hope this information is useful. Looking forward to your input on this. ... View more

I concur! 🤓  ... View more

That's a very good question, @MikeHunt ! "Is there really that much difference in reality between the "Acceptable" and "Best" above in terms of the uplink positions in the stack?"   That recommendation is focused on resilience / fault-tolerance aspects. The idea here is all other stack members still have a path to Core if any member switch is powered down or doesn't boot. That's why you shouldn't connect your uplinks to the same stack member. This would bring you to the acceptable scenario.   Now the Ideal scenario is the last where any pair can be down and still the remaining switches have an uplink to Core. Like you said, bandwidth and latency aren't a priority here; it's more about fault-tolerance. ... View more

Thank you for bringing this up, @PhilipDAth .   I pinged Internal Teams and they will update the switch selector. ... View more

Hello @RobustMeraki ,   Thanks for your question. The answer is yes, Client VPN (a.k.a. L2TP/IPsec Client VPN) can have its Authentication configured to check credentials provided by Active Directory or other LDAP directory.   However, your use-case requires two things: A Site-to-Site VPN between your MX firewall and your Azure VPC A RADIUS server that will receive the Client VPN authentication requests and then kind of translate to a domain controller query to your Azure AD.   So this brings more questions like: How to establish a Site-to-Site VPN with Azure VPC? How to configure a RADIUS server?   I surely can point you to Meraki docs covering the above topics but I suspect you'll link this other solution and design better.   In this other post, people recommended implementing a Cisco AnyConnect using SAML to Azure AD. Cisco AnyConnect is our own Client VPN and I personally prefer it because: a) your MX already has a license and b) AnyConnect uses a TLS tunnel which is generally more resilient to NAT issues when your users are using mobile hotspots, for example.   You can find more details about configuring AnyConnect plus SAML Azure AD here.   And here you can read about AnyConnect setup.   ... View more

@RaphaelL is exactly right!   You have a nice design, by the way.   If you ask me, the only thing I would change is the number of stack members. If you have enough free ports in your core, it's better if you have several Access Switches stacked in groups of two or four. Doing this would allow you to isolate failures and do maintenance with less downtime / impact (e.g.: when doing firmware upgrades). ... View more

Hello @BlakeRichardson ! Thanks for your question and observation.   I consulted with Internal Teams and found that expired licenses in Co-Termination don't get removed from License history. However, expired licenses in Per-Device license get removed after 90 days.   In Co-Termination, it's just going to stay there and not harm the co-term date. A customer renew licenses for their devices that are currently active in this Organisation at the time of renewal. The previous licenses won't be counted towards the the overall license limit and won't affect the expiration date.   Like you said, basically the expired Co-Term licenses will just sit there doing nothing. The dashboard license section was designed that way but that doesn't mean Meraki won't change it. In fact, We rely on customer's feedback when implementing changes or new features.   Therefore, you can make a feature request by going to the bottom right-hand corner of your Meraki Dashboard and sending your Feature Request through the "Give your Feedback" bubble. Screenshot below:   Once you sent your Feature Request using the "Give your Feedback" bubble, our Internal Team will process your suggestion and eventually you'll have your feature in the future. Please, keep in mind that there will be no estimated time to implement such feature but rest assured they will have a look and work on it.   Hope this information is useful. Looking forward to your input on this.   ... View more

@KarstenI is right! Some other Vendors do that kind of configuration as well. And it kind of makes sense if you consider that "Native" VLAN is UNtagged.   So in that FMC interface actually implies that all subinterfaces are tagged and the only UNtagged would be the physical. By the way, allowing UNtagged isn't the rule but the exception. Usually, you wouldn't route untagged traffic.   If you're curious, check more here in this Cisco Doc.   ... View more

Hey everyone! It's good to notice that if you Schedule a firmware upgrade and your MX is a Legacy one, you'll not find the latest legacy firmware. E.g.: I have two MX64 and when I schedule a firmware upgrade, only versions listed are 18.211.3 and 19.1.3; however, the end result is both MX running 18.170.11 after successful upgrade.   Here you have some screenshots for your reference:   ... View more