Meraki Community

RaphaelL · ‎Jan 12 2022

Yeah no surprise there. Run a packet capture to see the LLDP packets maybe ? I'm pretty sure this is how they request the required power

RaphaelL · ‎Jan 12 2022

This may sound stupid , but have you checked that both devices are running and send LLDP packets ? I'm guessing that the MX needs the LLDP packet to know that the MR is requesting 802.3at power. That could be a bug.

RaphaelL · ‎Jan 11 2022

Only the Meraki Support can see the Uptime. Why ? Good question...

RaphaelL · ‎Dec 9 2021

Thanks for the quick reply ! 1- We can't upgrade the firmware yet. Long story with a current bug regarding DHCP 2- Is there a easy way to determine the uptime of a switch ? 3- A Support case was already open , but we couldn't determine if the switch did reboot or not. I think we had a power outage on that site, but I couldn't confirm it.

RaphaelL · ‎Dec 9 2021

Hi , In the past few days I have extracted via API all the events '' stp_no_longer_root " and "stp_elected_root" to see if any Meraki switches were becoming the Root bridge. Here is our config : Switch 1-8 are stacked with stack cables and only switch 1 and 2 are connected to our distribution layer ( Cisco VSS C6800 series ). Meraki switches uses the default priority of 32678. Our distribution layer is running 4096 priority. The ''only'' way I could explain all the STP events would be a sudden power loss and some members are rebooting faster than the switch master ( the one connecting to the root bridge ). Without any way to receive the root bridge bpdus , the stack member elects itself as the root bridge for a moment... I'm having a hard time to figure out if a meraki switch really rebooted or even finding out the uptime... Am I misinterpreting the logs ? Thanks ,

RaphaelL · ‎Nov 30 2021

Hi , Even with MX 14.53 and Win 20H2 we are still seeing Windows PC renewing their lease at every reauth on MX ( only on MX once again ... ) Has anyone tested with Win11 ? We don't have Win11 devices yet. Thanks ,

RaphaelL · ‎Nov 8 2021

I wasn't excepting a trunk port and a access port to return the exact same data structure : {"portId":"1","name":null,"enabled":true,"poeEnabled":true,"type":"trunk","vlan":1023,"voiceVlan":1031,"allowedVlans":"all"} {"portId":"2","name":null,"enabled":true,"poeEnabled":true,"type":"access","vlan":1030,"voiceVlan":1031,"allowedVlans":"all"} ( I removed some fields ) No mention of native vlan ( which is in reality the ''vlan'' ) Allowed vlans list in access mode ( which is not shown in the dashboard ) and so on...

RaphaelL · ‎Nov 8 2021

Hi , I have noticed that the call : https://api.meraki.com/api/v1/devices/*******/switch/ports was returning me Trunk ports with voice vlans , which seems fishy at first. For example : https://api.meraki.com/api/v1/devices/XXXX-XXXX-XXXX/switch/ports {"portId":"1","name":null,"tags":[],"enabled":true,"poeEnabled":true,"type":"trunk","vlan":1023,"voiceVlan":1031,"allowedVlans":"all","isolationEnabled":false,"rstpEnabled":true,"stpGuard":"disabled","linkNegotiation":"Auto negotiate","portScheduleId":null,"udld":"Alert only","accessPolicyType":"Open"} https://api.meraki.com/api/v1/devices/XXXX-XXXX-XXXX/switch/ports/1 {"portId":"1","name":null,"tags":[],"enabled":true,"poeEnabled":true,"type":"trunk","vlan":1023,"voiceVlan":1031,"allowedVlans":"all","isolationEnabled":false,"rstpEnabled":true,"stpGuard":"disabled","linkNegotiation":"Auto negotiate","portScheduleId":null,"udld":"Alert only","accessPolicyType":"Open"} Both endpoints are returning me voicevlan 1031 which is not present in the actual config : But when looking at the ''access'' tab , I can see the ''other'' config : I'm pretty sure there is a reason for that , something like you can have ''both'' configs ''ready'' in the dashboard so the API returns them. If the switchport is in trunk mode , just display the trunk values , not the access values. I don't want to go over 3K switchports to remove the values in the access tab for the API to return the correct data. Well...

RaphaelL · ‎Nov 2 2021

MXs do not support LACP or any form of LAG.

RaphaelL · ‎Nov 2 2021

@DCrab Well no surprise here from Meraki. The lack of support of industry standards in pretty common. Also MX do not run STP so here goes another surprise.

RaphaelL · ‎Nov 1 2021

Hi , I was looking at some events logs I came upon some events that are misleading when compared to the documentation. https://documentation.meraki.com/MX/Monitoring_and_Reporting/Primary_Uplink_Status_and_Ethernet_Port_Carrier_Change_Events The documentation states that : uplink: 2 - indicates Cellular is being used. When in reality it is displayed as is_cellular : 2 Same with the API call '{0}/networks/{1}/events?productType=appliance&perPage=1000&includedEventTypes[]=failover_event' 'eventData': {'is_cellular': '2'} 1- Is the documentation wrong ? 2- In my screenshot , I have a hard time understanding the events... We have 2 dual WAN + Cellular as a backup. I was expecting to see uplink0 and 1 fail, then see a failover to cellular , then see another failover to uplink0-1 when they came back online. The lack of info on these logs makes it hard to identify if a link went down or not. Thanks ,

RaphaelL · ‎Oct 29 2021

Mmmmm I always thought that ''fall'' was the term for Autumn in North America. So yeah saying the season Fall implies that it is in north America. Or I may be wrong.

RaphaelL · ‎Oct 22 2021

@PhilipDAth Seems to be right once again : A test is considered successful if the Meraki device receives any kind of legitimate RADIUS response (i.e. Access-Accept/Reject/Challenge) from the server.

RaphaelL · ‎Oct 22 2021

We just found out that the user test is missing from our Cisco ISE config : I would advise you to verify your RADIUS server

RaphaelL · ‎Oct 22 2021

Well ! I was about to post here. I have the exact same issue and this is the response from Meraki Support : I would recommend looking at some of the historical logging on ISE. RADIUS traffic is also UDP, so there is a potentially that it may not have arrived and could be the cause of this alert showing. Although this feature is not available to see syslog or logs in dashboard for recent 802.1X failure, we take our customer feedback seriously. We encourage you to use the Meraki dashboard to "give your feedback" and submit a feature request. You can submit a feature request at the bottom of any dashboard page. Any wish that is made sends an email to our Product Managers and Development Teams. These wishes are taken into consideration and are used to help shape our product roadmaps. The most wished-for items are incorporated into product development. My response somewhere around : You are offering me a health checking service that has no logs , so no way to see what went wrong, how it went wrong. This is basically useless.

RaphaelL · ‎Oct 21 2021

I have over 5000 networks in that Org and I like to be able to go to Overview -> Networks / Devices to see if there is any issues. I know that when using the API it returns me the correct number of devices that are ''alerting''. The dashboard isn't. I'm not refering to alerts from network-wide -> Alerts page to send alerts when ''X'' event is happening. I did open a ticket and I have a strong feeling that the TAC will suggest a feature request, which to me is absurd considering that the API returns the info ,you just have to display it correctly in the dashboard. Anyway, to be continued.

RaphaelL · ‎Oct 21 2021

@BlakeRichardson I totatly agree with you ! In my case a device has been reporting ''Config is out of date'' for more than 3 weeks ! I would have like to be informed of that issue way earlier than randomly coming across it.

RaphaelL · ‎Oct 21 2021

It really should ! Just found out that "Recent 802.1X Failure" and "This switch's current stack members differ from the dashboard configuration" alerts are also affecting MS Switches. It is odd enough. I will open a case.

RaphaelL · ‎Oct 21 2021

Hi , I have been experiencing some issues to properly identify Networks and devices that are alerting. For example , I have a device that is in the "Configuration is out of date" state for months but the Overview -> Devices page doesn't display the device as alerting. When going to the network Appliance Status OR via API ( {0}/organizations/{1}/devices/statuses ) it correctly identify the device as ''alerting'' : Appliance status page : Org -> Overview -> Device page I think that the events ''Configuration is out of date'' and ''Unable to fetch config" are the 2 states that do not trigger in the Overview Page , which is a bit odd to me. Has anyone experienced this before ? I'm about to open as case to see if it's a bug or not. Thanks ,

RaphaelL · ‎Oct 15 2021

Hi , I manually selected channel 100 and it seems to be working fine. I'm the only AP in all 30-40ish SSID near me in that channel. I will test it out. If I'm running into compatibility issues with some devices ( TV , smart IoT ) I will revert to channel 40.

RaphaelL · ‎Oct 14 2021

Where you able to confirm if the VRRP MAC between your MX450 and MX250 followed the same mechanic ?

RaphaelL · ‎Oct 13 2021

Woops ! I just edited my post to include the firmware versions. I will have to test in my lab if bringing the MX250 to the MX450 version will change the behavior ( which is still not the one expected from the RFC ) I was expecting a MAC 00-00-5E-00-01-XX

RaphaelL · ‎Oct 13 2021

Hi , I was curious about that behavior so I did a couple packet captures on both our MX450 and MX250 Warm Space ( LAN captures ) MX450 MX 15.40 : Uses the burned-in MAC for the VRRP MAC ( not following the standard in RFC 5798 ) MX250 MX 14.53 : Uses a special MAC CC:03:D9 + End of the burned-in MAC of the device ( not following the standard in RFC5798 ) I'm a little bit surprised to see that both MX450 and MX250 are not following the RFC AND they are not even using the same mecanic for the VRRP MAC selection....

RaphaelL · ‎Oct 11 2021

Hi, Have you tried multi-auth ( the last one ) ?

RaphaelL · ‎Oct 10 2021

Hi , Thanks for the reply. I thought I could use the first channels for UNII-2E as shown : Not a single AP is broadcasting in that range. But It could be simply due to your first explanation. Thanks

About RaphaelL

RaphaelL

Raphael Letourneau

Community Record

Badges