Meraki

MerakiDave · ‎Jan 19 2022

Hi @Martin_Rowan I am not aware of anything specific being mentioned or discussed in our Meraki Support channels. There is a relatively new discussion forum here on the Community specific to service outage/impairments: https://community.meraki.com/t5/Meraki-Service-Notices/bg-p/service-notices and at this point nothing there either specific to degraded API performance. And that's a valid data point that you are noticing this across multiple Dashboard organizations on different shards. I would open a ticket with Meraki Support for further investigation, they will be best equipped to correlate your issue with any others and engage with Engineering.

MerakiDave · ‎Jan 17 2022

Hi @MikeZ can you share the details on which make & model of SFP and which devices you are connecting together. I see this is in the "switching" forum but it wasn't clear if you were referring to a particular model of switch, and if it was switch-to-switch or maybe a switch uplinking to an MX appliance or something else. Also I'm assuming the SFP port(s) themselves are enabled. And when you say you cannot get the SFP ports to work, in what way - not getting link lights, or Dashboard is not reflecting any SFP inserted, or maybe Dashboard shows the SFP info but you're not getting a link, etc? Also want to confirm you are using the same type of SFP on both ends if it's a fiber link, needs to be SR-to-SR or LR-to-LR, or LRM-to-LRM, etc.

MerakiDave · ‎Jan 16 2022

Hi @bigkeoni64 I won't say it's going to have zero impact on the CPU, while port mirroring is not completely CPU-bound, my concern is definitely with the oversubscription. You'll have a point of diminishing returns. So if you start mirroring ports 1-47 to port 48 for example, and then maybe another 48 ports from another switch in the same stack, on a very busy network by the time you start to notice a CPU/performance impact, the mirror destination port will be dropping so many frames it would have become rather useless anyway. Sounds like you already have a handful of TAPs you can leverage, please do, and I'd proceed with care on the port mirroring at that scale, perhaps first set it up on a subset of ports that represent your more critical devices.

MerakiDave · ‎Jan 16 2022

@Basicme just checking back on this, it sounds like you were able to create the multi-room group of Echo devices, but they will not all play music at the same time, it only comes through on a single device or maybe on none of them? You are running in Bridge Mode now for your SSID, and there is no L2 LAN isolation turned on right? That setting is under the Wireless > Firewall and Traffic Shaping page. So if you go to Network-Wide > Clients you are able to see each of the Echo devices in the clients list? They all have an IP address on the same subnet/vlan? And perhaps from some other device on your home network you can ping the IP address of each Echo device?

MerakiDave · ‎Jan 16 2022

Certainly @cmr I'd say so for client access that could also be pretty easy via GP. Wouldn't cycle ports off/on but chances are that part isn't important for a typical home office type setup 😀

MerakiDave · ‎Jan 15 2022

Hi @Dinger you could certainly do that for what you are describing without much concern. The MX75 is not a switch of course but for what you are describing you can likely use the MX75 as your switch for a home office setup, where you probably have a single VLAN anyway, or of course the MX75 can do your interVLAN routing if needed like if you're already doing that on your 64. As you mentioned you'll only have the two PoE+ ports, which might be fine if you only have the pair of MR36 APs and no other PoE devices. The other switch-specific items you would lose are things like switch ACLs, access policies, and port schedules for example. Check if you're using any of those things beforehand.

MerakiDave · ‎Jan 14 2022

Hi @Cagg I wouldn't be too concerned, I think you're referring to the brief throughput and remaining file size status message when exporting video from a camera, like in this attached image. I tried a couple quick ones and got 7 and 11Mbps. That is not necessarily showing that the camera itself is exporting the video slowly, but I believe is an overall rough average that would include multiple factors, including the throughput of your camera's control plane connection all the way through Dashboard as well. Sure 1.1Mbps seems a bit slow but there are many variables including things external to MV and Dashboard itself. Sort of like when you run a Dashboard throughput test from the Tools tab, like for a wireless AP, that is not meant to reflect the throughput capability of the AP or serve as a speed test, but just to show there is an adequate control plane connection to Dashboard. The cameras themselves have pretty high-end processors (since they perform advanced analytics as well) so your MV72 should be connecting at 1Gbps full duplex and the chipset is certainly capable of putting more than several Mbps on the wire. I'd say try this at different times on different cameras and if this seems to be consistently slow across the board - or perhaps just the opposite, if you find only a few cameras that are much lower/slower than most others, let's get a case open to investigate a little deeper. Also check the wired connection itself, run a cable test, check to make sure there's not a duplex mismatch for example. Hope that helps.

MerakiDave · ‎Jan 14 2022

Hi @bigkeoni64 while you could configure it like that, and I don't think there would be any major performance impact on the switch CPU to simply mirror/copy frames to the mirror destination, the issue is going to be one of major oversubscription and dropped frames on that mirror destination port. Depending on what you're trying to accomplish or capture, you might need to consider an alternative like a Gigamon TAP or similar.

MerakiDave · ‎Jan 14 2022

Hi @hmc25000 this also came up in another recent thread below. Check here https://documentation.meraki.com/MX/Other_Topics/MX_Cold_Swap_Replacing_an_Existing_MX_with_a_Different_MX In particular look over the section "Adding a Second MX to Form a Warm Spare Configuration" which seems most relevant and is going to minimize your actual downtime if you've got a tight outage window. Hope that helps.

MerakiDave · ‎Jan 14 2022

@Akash_5321 what @Greenberet said is correct about the offline storage, in the event your network is down and the MT sensors have no Dashboard connectivity, they can cache reading for 5 days. MT sensors are always sensing and report into Dashboard every 20 minutes, or immediately upon violations or a state change with customizable alerting you can configure. This default of 20 minutes regardless of state changes is in order to help guarantee the long battery life. I've had my own MT20 in my home lab well over a year and the battery is currently at 70%. Changing the sampling rate is possible on the back-end but is experimental only, it's not supported and could cause suboptimal performance and faster battery drain, so even Meraki Support may not be permitted to adjust. What I mean is the 20 minute default is obviously something that is "configured" but it's a back-end setting not meant to be adjusted. I would agree the wording in the data sheet "at the default sampling rate" leads one to believe it's adjustable. It's not officially adjustable at this time. Was there some concern about increasing the frequency at which the MT20 checks into Dashboard?

MerakiDave · ‎Jan 14 2022

Hi @CWK_Rob the semi-official answer is no. This is ALWAYS the client's decision, which AP to connect to and when to roam. Every client of course will have its own unique perspective of the RF environment and make its own decisions accordingly. Plus every client device will approach such decisions depending on the underlying OS, chipset and driver versions, etc. So even client devices from the same manufacturer, but perhaps with different OS or driver versions, can behave differently for how they associate and roam. Very client dependent and lots of variables, not to mention the actual RF in your residential building, which can literally change from minute to minute based on doors opening/closing, people moving around, etc. If these are the only clients connecting, you can make some adjustments like with radio transmit power, RX-SOP, or minimum bit rate settings to expand/contract the effective coverage cell. But if other client devices are also connecting for other purposes, proceed with caution when making certain adjustments. And as Brandon mentioned, perhaps another possibility is to leverage AP tags and SSID Availability for a separate SSID with fine tuned settings that will encourage the locks to join the AP you intended. But notice I said "encourage" and not "force". We can fine tune and encourage the clients to behave the way we want, but cannot force them.

MerakiDave · ‎Jan 11 2022

I believe this is resolved, was just a cosmetic issue. Anyone still seeing missing MR licenses? If so ping Support.

MerakiDave · ‎Jan 11 2022

Correct, sorry that wasn't clear - will be very similar to the MR44 BLE cut charts, not exact of course on a different model AP with a different shape and board geometry, but overall it's (generally speaking) a somewhat spherical / omni pattern. Would be pretty tough to determine if an MT just happened to be sitting in one of the indents, and of course typical Bluetooth distances will apply (unrelated to the actual client-serving radios and their respective omni coverage patterns), plus whatever else might be going on in the 2.4 space. And yes, if it's not inconvenient, something as simple as changing the AP orientation or even moving it by a couple inches could provide a data point and compare signal strength reported on the MT's status page.

MerakiDave · ‎Jan 11 2022

@Crocker curious if any of you are still seeing this issue? I did not see it myself on a couple of my own co-term orgs, and I just checked a few others just now and the MR licensing is all there across 7 or 8 orgs I checked.

MerakiDave · ‎Jan 11 2022

@cmr the BLE radio and separate dual-band scanning radio are also omnidirectional in nature, same as what the WiFi6 data sheets show, but when the data sheets were created they only developed the charts for the client-serving radios. So for those 3rd and 4th radios on the WiFi5 models, all of the XY/XZ/YZ cuts would look VERY similar, but the charts were not generated. If I come across something that can be shared I'll unicast it to you.

MerakiDave · ‎Jan 3 2022

Hi @FailSafe I haven't heard of any ongoing issues specific to the device list being empty, and I just checked a handful of SM networks and toggled between the Overview and Device list pages without any issues. Are you seeing this behavior on multiple devices/browsers? Not sure if you have access to any other SM networks to compare and see if same or different behavior. I'd say if a device reboot or browser restart (and/or maybe a temp/junk cleaner utility) doesn't fix this, or especially if this behavior happens on multiple devices, let's definitely get a case open with Meraki Support to investigate.

MerakiDave · ‎Jan 2 2022

Hi @PhilG yes, you can order hardware and licenses using two different email addresses for your own billing purposes, and you may claim the hardware and licenses into the same Meraki Dashboard organization. It might also prove helpful to make sure you define both of those email addresses as organization admins on the Organization > Configure > Administrators page. The important thing is not which email address was used for ordering/shipping, but simply that you use one of your Meraki Dashboard administrator accounts to "claim" the order number into your organization on the Organization > Configure > Inventory page. Then you would have a network defined for each of the two sites and place one MX67 into each network. You can create a new network also under the Organization > Configure menu. As Ajit also mentioned, you will need to purchase the same license levels for both sites, because the Meraki licensing exists at the Organization level, not individual networks. So if you need the Advanced Security license, then the entire Meraki Dashboard organization would be licensed for Advanced Security, so then for two sites you would purchase two MX67 appliances and two Adv Sec licenses. If you were going to configure the pair of MX67 appliances as an HA pair in the same network, then you would only need one license, since it would be an active/standby failover pair and only one appliance would be active at any time. But in two networks you do need two licenses, and they need to both be the same level (Enterprise, Advanced Security, or SD-WAN). Here is the documentation on the different licensing levels: https://documentation.meraki.com/General_Administration/Licensing/Meraki_MX_Security_and_SD-WAN_Licensing Hope that helps.

MerakiDave · ‎Dec 31 2021

@ArshadSafrulla thanks for the details. Based on your input, (although I haven't seen the case notes) I'd say this request is non-standard and not necessary. You clearly stated that all 4 APs are faulty and you have tried multiple tests on each individual AP and there is no status LED of any kind on any of them. You even tried PoE injectors. I cannot imagine why they might want a photo or video, this seems pretty simple, and if you have 1500 APs deployed, you are well aware of how to diagnose a faulty AP. I don't see what a photo would or video would prove beyond the info you provided. I would call into the Enterprise Support hotline for your area https://meraki.cisco.com/support/ and select option 1 for an existing case and when the next available NSE picks up the call it might be best to re-explain this on a live call and ask them to process the RMA. It's possible since you might have a single case to RMA all 4 APs, they may have a different protocol for "bulk RMAs" which might have prompted the request, not sure. And if that's the case, you certainly have the option to take a few minutes to open a case for each failed AP, but I wouldn't think that should be necessary. Will have to speak with your NSE. And if there is still pushback, engage with your local Meraki sales team to assist. Good luck.

MerakiDave · ‎Dec 30 2021

@ArshadSafrulla is Meraki Support asking for specific pictures prior to processing an RMA of an AP? That is uncommon but if they have a reason they should state why and specifically what pics or vids are needed. Maybe they just want to get a picture of the AP's label with the S/N and MAC address. Or if it's a dead AP that will not power up, then perhaps a video that shows a good AP powered up and status LED on (therefore proving it has good PoE power), then unplug the good AP, plug the same wire into the bad AP and show that the status LED doesn't come on. But that seems like quite a hassle to prove an AP won't power up. Perhaps they want to better understand the deployment environment, or to see if something has voided the warranty, like if you have an indoor AP mounted outdoors, or the AP was painted, etc. Why is the RMA being requested? What is faulty with the AP? Like maybe if the AP stays in a continuous reboot cycle, they might be requesting a video of the status LED and the pattern it cycles through. This is the type of case where I have seen videos requested, to document and understand a specific (perhaps faulty or unexpected) status LED sequence.

MerakiDave · ‎Dec 30 2021

@Ubaidkhan if you have Organization-wide write permissions, you would find this under the Organization menu locale: Organization > Configure > Create Network and on that page you can give it a name, select the network type, and choose the default config or bind to a template or clone an existing network. If you do not have this menu locale/option then that would indicate you do not have organization-wide write permission, even though you might have full read/write access to one or more specific Dashboard networks, possibly not for the entire organization. Note that even if you do have the "Organization" menu locale, if you only have read permission and not write permission then the "Create Network" option will not be listed under the Organization > Configure menu. If that is the case and you need to create a new network, you will need to work with another Dashboard admin who has full org-level write access to update your permissions. Hope that helps! Here is the documentation article: https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Creating_and_Deleting_Dashboard_Networks

MerakiDave · ‎Dec 29 2021

@bigkeoni64 sorry no, once the ports are aggregated there is no longer an option to configure a port mirror. https://documentation.meraki.com/MS/Monitoring_and_Reporting/Packet_Captures_and_Port_Mirroring_on_the_MS_Switch

MerakiDave · ‎Dec 28 2021

Oh yeah good catch @Ryan_Miles I looked right past the repeater status icon, so that's ok. But, @macsolutions are any/all of the TVs running off one of the repeater APs, and could the AP they're connected to be 2 mesh hops away? So with the responses so far, we've asked a ton of questions, let us know your thoughts and the details of the physical setup and SSID config, firmware versions (both TVs and APs), etc.

MerakiDave · ‎Dec 28 2021

Sounds like it could be a difficult RF environment causing it, but then again, it's not like the APs or the TVs are moving. The RF environment can still change of course, the trick may be finding what other variables we have since the equipment is stationary. Where are the APs in relation to the TVs and what is in between them? How often is the pixelating an issue, is it fairly frequent, or any particular rhythm to it, or it's only on occasion and completely random? Also curious that all 3 APs landed their 5GHz radios on channel 44 when the RF profile is set for auto channel. You're close enough to DCA there's the radar question, do you have DFS channels enabled? And if you look at each AP's list of clients, what are the client TVs actually connecting to, 2.4 or 5? When you look at the TV's client page, what are its capabilities and SNR? Perhaps toggle a few things such as making the SSID 2.4GHz vs 5GHz only for a period of time, and on the 5GHx side perhaps manually setting 20MHz channels and manually set 3 non-DFS channels like 36, 44 and 153 for example.

MerakiDave · ‎Dec 27 2021

Not the first time I've heard someone say the website redesign was a solution looking for a problem... Not to mention certain aspects of it are broken. Like, try going to meraki.cisco.com/library, and click the "datasheets" link and then from the "Product" drop-down select MR Wireless - and no data sheets are listed. Then select MS Switching, and only the MS210 and SFP data sheets are listed... I'm sure this will all be addressed and corrected but agree how frustrating it is.

MerakiDave · ‎Dec 27 2021

Hi @SimonT I think you were referring to the Meraki equipment itself and as you pointed out that is why it still lists UDP/123 outbound to ANY destination IP for NTP. However that is really for initial connections, and afterwards NTP is actually handled over the control plane connection (which was typically always UDP/7351 and in the latest MR/MS/MX firmware it'll happen over TCP/443). The “ANY” destination is not actually a hard requirement and you can assign any NTP server you like via DHCP options from an upstream DHCP server, and so long as that NTP server is aligned with global NTP to within a few seconds that can also work fine and without having to make a mess of the firewall rules. Sorry if I misunderstood.

About MerakiDave

MerakiDave

Community Record

Badges