I would suggest opening a case too for Support to do a cursory check, just in case there are any back-end messages or warnings correlating with this output. Feel free to mention the community post in the description of that case also! ... View more

Hi RaphaelL!    I can't seem to find any details on this event type under our release notes or the firmware changelog - I'll raise this with the relevant team internally for further advice.    Let me know if you have any further questions on this in the meantime! ... View more

Translated:    Hello,   I work for a School District. Each of our schools has at least two wiring closets (mdf & idf). The primary closet (MDF) is connected directly to a Cisco Catalyst 9500 for internet access, with the 9500 being the root switch for STP. Each closet has several Meraki ms225, connected to each other through a stack of switches. At the same time, each closet connects to the MDF and the latter to the 9500. On the 9500 port, towards the MDF, I have "Root Guard" configured to prevent one of the Meraki from becoming a root bridge. What would be the port configurations for each of the connections from each idf to the mdf? I want to know if Root Guard also applies or if I have to declare it Loop Guard?   Thank you,   --- Response: Hola Domntr05! Hay un documento bastante completo que detalla el caso de uso para cada una de las opciones de protección STP, vinculado aquí: https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_Spanning_Tree_on_Meraki_Switches_(MS)#Configuring_STP_Guard_on_a_Switch_Port Como breve explicación: Root guard generalmente se aplica a los puertos que se encuentran frente a los conmutadores descendentes que están más cerca de los dispositivos cliente en la topología de la red. Evita que esos conmutadores inferiores se conviertan en la raíz STP al evitar que pasen mensajes BPDU superiores. Loop Guard se utiliza para evitar que se produzcan bucles en la topología STP, cuando parte de un enlace falla y se vuelve unidireccional. Esto se aplica más comúnmente para conexiones de fibra óptica, ya que un cable se usa para transmitir datos y el otro cable para recibir datos. En su caso, si no tiene cables de fibra óptica que conecten el IDF y el MDF, no necesitará configurar ninguna función de protección en los conmutadores descendentes. Si está utilizando cables de fibra para conectar el MDF y el IDF, entonces debe agregar Loop Guard a los puertos que se conectan desde el MS and upstream. --- Translated response:  Hi Domntr05! There is a quite comprehensive document that details the use-case for each of the STP guard options, linked here: https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_Spanning_Tree_on_Meraki_Switches_(MS)#Configuring_STP_Guard_on_a_Switch_Port As a short explanation: Root guard is usually applied to ports that face switches downstream who are closer to the client devices in the network topology. It stops those lower down switches from becoming the STP root by preventing them from passing any superior BPDU messages onwards. Loop Guard is used to stop loops from occurring in the STP topology, when part of a link fails and becomes unidirectional. This is more commonly applied for fiber optic connections, as one cable is used to transmit data and one cable is used to receive data. In your case, if you do not have fiber optic cables connecting the IDF and MDF, then you would not need to configure any guard functionality on the downstream switches. If you are using fiber cables to connect the MDF and IDF, then you should add Loop guard to the ports which connect from the MS to the upstream. ... View more

Hi shan_k!   I would recommend starting off by validating the scanning API calls themselves are working first, before troubleshooting their integration via Meraki Sandbox.   The validation can be performed with any HTTP server configured to receive JSON objects which returns the organization-specific validator as detailed in the introduction guide.   Also important to note are the differences between the V2 and V3 versions of the Scanning API, which can be found in this KB article.   Let me know if you have any further questions on this too! ... View more

Hi Schweb!   I'm looking at specifically the error "no installation source found" received when trying to manually push apps to those devices.    Based on your screenshot showing the update mode as high priority, it seems the data is hosted in Asia-Pacific.   If you go to the client device, click on "missing" under the "Apps" section, and click on the specific app name, does it show an App source whose region differs from the device's physical location itself? I'm thinking there could be an issue trying to fetch it from a certain store's region it would not originally reach to, which results in a response that there's no source to install from.    Please let me know if you can modify that field, and if it changes the outcome or results in a different error. ... View more

Hi Refyne! In scenarios such as this, more in-depth troubleshooting on your context would typically be required, to understand the failure stage and root cause of failing to log in via a certain OS or device type. As this may involve detailing private information pertaining to your dashboard or configuration, I would recommend to open a support case if you are still experiencing this issue, via any of the channels as noted here:  https://documentation.meraki.com/General_Administration/Support/Contacting_Support Let me know if you have any further questions on this too! ... View more

Hi sc2!  It doesn't seem like there is any function that logs the date and time of changes made to the note field of a specific client device. I use a text expander software that replaces a given shortcut phrase (like /date) with the current date and time, which makes the function available system-wide too. We would recommend that you leave this as a feedback suggestion for the product team via the Meraki dashboard Give your feedback function, so the product team can look into the possibility of adding it in future dashboard updates. ... View more

Translated version:  I am using CW9162I, but even if I set the target output high in the RF profile (for example 22-30), the transmission output on the radio wave setting screen is 15, and it seems that the output has not actually increased (I checked with an app called NetSpot), but what are the possible causes? The same goes for standard indoor profiles and newly created profiles. The environment is an office of about 140 square meters with six CW9162I installed. --- Response: こんにちは！   この動作は、規制ドメインの最大送信電力制限に達したことが原因である可能性があります。 各国には、無線認証ステータスに応じて、アクセス ポイント モデルごとに使用できる帯域、チャネル、最大送信電力を記述する指定の国コードがあります。 たとえば、日本で動作する CW9162I では、次の最大伝導送信電力で動作できます。 チャネル 1 ～ 13 間で 2 GHz、最大電力 23 チャネル 36 ～ 64 間で 5 GHz、最大電力 15 チャネル 100 ～ 144 間で 5 GHz、最大電力 22   これが、このような制限が適用されている理由である可能性があります。5 GHz 帯域の大きい番号のチャネルをテストして、より高い送信電力を達成できるかどうかを確認することをお勧めします。   この件に関してさらにご質問がございましたら、お知らせください。   Greetings!  This behaviour may be due to hitting the maximum transmission power limits in your Regulatory Domain. Each country has a designated country code which describes the band, channel and maximum transmission power that can be used per Access Point model, dependent on its wireless certification status.  For example; on the CW9162I, operating in Japan, this can operate on the following maximum conducted transmission powers: 2 GHz between channels 1 to 13, maximum power 23 5 GHz between channels 36 to 64, maximum power 15 5 GHz between channels 100 to 144, maximum power 22 This may be why you were seeing such limits being applied - it would be recommended to test the higher numbered channels on the 5 GHz band to confirm if you can hit a higher transmission power.  Let me know if you have any further questions on this! ... View more

Hi Raphael!    I've logged a ticket with the Documentation team to get this KB article updated with the relevant screenshots and text to detail the Sticky clients mechanism.    I'll let you know as soon as it has been updated too!   Regards,  Joshua ... View more

Hi MerakiGary!    Looking at our internal issue report history and for any support cases noting this firmware and model, I cannot immediately see any reference that directly correlates to your issue.    I would suggest first upgrading to the latest stable firmware (currently Stable Release Candidate CA 16.4 which runs an IOS image based on 17.9.3 CCO) before raising a support ticket if you still encounter the same behavior with that option enabled.   Please let me know if you have any further questions on this also! ... View more

Hey Don,    devInterfaceModel is also an object-type with the same syntax of DisplayString, and it would appear as an Object passed in the cellularNetworkUp and cellularNetworkDown SNMP Traps, along with other details. For example, the full list of the cellularNetworkDown Trap shows it passes all of the following Objects: organizationName networkName devMac devInterfaceModel devInterfaceCarrier devInterfaceName These were taken from the list in the Meraki Proprietary MIB, which can be downloaded from the "Download MIB" link under Organization > Configure > Settings > SNMP.   Regards,  Joshua ... View more

Hi Mateusz!   The History API call should return the counts aggregated per minute for the zone ID for Corridor that you would have had defined in the call.    This averageCount should map to the occupancy of the zone over that time period (raw detections of objects per frame over the 60 second interval) and entrances should map to only crossings in to the defined zone for that time period also.   For "Zones", the Analytics tab references that "a person is counted when crossing a defined line or remaining in a zone", the combining of which may be why you see the discrepancy between the two formats.   However, we are in the process of deprecating the "Zones" functionality and transitioning to "Areas", which has additional functionality for line crossings counted as "In" and "Out" dependent on direction of travel over the threshold, as well as specific area occupancy and crossing parameters such as entered, exited, appeared, and expired.    Whilst the API does have support for historical data and even live data polling with a short delay, we could suggest using MQTT messages for the purpose of data aggregation. As it is streamed continuously to the broker, it removes the possibility of any timestamp overlap in sequential API requests. Please let me know if you have any additional questions on this! ... View more

Hi Don!    If you are referring to the the actual attributes that are received from the Object being polled, they are data pulled from the Meraki dashboard, which are relevant to the devices referenced in the polled Object.    Descriptions of the Objects can be found within the Meraki Proprietary MIB, which can be downloaded from the "Download MIB" link under Organization > Configure > Settings > SNMP.   For example, within in the downloadable MIB we see devInterfaceCarrier is listed as an object-type, details a syntax of DisplayString, and a description of "The carrier for the interface. Useful for cellular interfaces." The carrier name may match what you see in the Security & SD-WAN > Monitor > Appliance Status > Uplink under the Cellular > Provider section.  Please let me know if you have any additional questions on this! ... View more

The Source NAT feature is currently still considered Beta and under continued development. We have a lot of features being worked on and at times some need to take precedence over others. As we aim to release features that are ready for implementation in your networks, source NAT is at the moment not recommended for production environments. ... View more

As this is being referenced in cases currently, I'd like to clarify the following:   "Disable NAT per uplink" is known as No-NAT, and this is a beta feature that isn't fully supported yet, as it is still undergoing internal testing and improvements. We do not recommend beta features for production environments, however, if your deployment requires the use of this feature, we recommend testing in a lab environment first.   "Source NAT" is currently not a supported feature, and will not function as intended, as it is also undergoing internal stability and performance testing at this time. We cannot recommend the use of this feature currently. ... View more

I would like to add some additional information to this:   When support initiates a change to your registry contact points, a migration period will occur, within which changes to your registry contact points cannot be performed. Any additional changes to these will require an additional waiting period while the migration finishes.   An additional port of 9351 has been added, which you will see is also listed under Help>Firewall Info>VPN registry. Upon issuing a registry IP change from our side, you will see the addresses on this page update automatically, so be sure to check this page after any registry IP change is made from the Meraki Support side, and update your upstream firewall/device rules with the new information accordingly. ... View more

As we've seen this referenced on some cases recently, I'd like to clear up that the reference to a "cache clear" actually pertains to a "configuration fetch" issue. Root causes for these cases have been seen to be either a back-end change that Meraki Support is required to implement, or were found to be routing/allowed outbound port issues on the Azure side (as listed in the "Help>Firewall info" page).    I'm posting the above terminology so that any Support Engineer on your next case may be able to follow up on your request with more efficiency. ... View more

Due to this post being referenced recently, I'd like to clarify that RADIUS hostnames are only usable when configuring RADIUS Authentication with a Sign-on Splash Page. For other RADIUS server configurations (such as Client VPN with RADIUS authentication, or RADIUS Authentication with WPA2-Enterprise) only IP addresses are accepted; using a hostname is not currently supported.   ... View more