Meraki

RaphaelL

Bummer... couple minutes up to 10 I would understand , but hours... I wonder if that is expected. It is not mentionned in the documentation.

RaphaelL

Hi , I'm currently testing 802.11r and roaming and I noticed that logs/events on the page "Roaming" takes forever to show up. They are present on the page "timeline" : They will probably show up in 3-4 hours... I'm running MR30.6 , has anyone noticed that ?

RaphaelL

Indeed , I just read it. However , I'm not getting any results either but I'm getting a HTTP 200 with an empty list. if I remove the filter on the MAC the client is present. https://api.meraki.com/api/v1/networks/xxxxxxxx/clients?perPage=1000&mac="de:89:c2" returns http 200 [] https://api.meraki.com/api/v1/networks/xxxxxxxx/clients?perPage=1000 returns a client with the MAC de:89:c2 ... Weird.

RaphaelL

Hi ! Sadly it is a private KB and cannot be shared ! The public release is planned next month or so

RaphaelL

Hi Phil , I suppose the MAC has to be in the format xx:xx:xx:yy:yy:yy and not just with the OUI.

RaphaelL

One year later ... we have received the test KB from Microsoft and I'm currently testing 802.11r and roaming. From 2 days of testing this looks promising ! No issues so far.🤞

RaphaelL

I don't see that as being a "hole in their portal". getOrganizationNetworks , getNetworkClients with a Org small like yours it will take maybe a minute or 2 to run. Having Org-wide calls with "volatile" info such as client info is pretty hard to run on big orgs , that is one of the reason they don't exist.

RaphaelL

Because 18.208.0.1 is out

RaphaelL

Your MX version is not a beta version. It is a Stable Release Candidate

RaphaelL

Ahhhhh ! This is way better than "CTRL+F" in the openapiSpec ! love it.

RaphaelL

RADIUS accounting is not supported yet on the MX.

RaphaelL

This is the reply I got : After discussions with a few different members of my team that worked on the original bug report, the reason why the fixes weren't working for us here is because I originally misinterpreted what the report sought to fix. The original report was related to seeing the Multiple DHCP servers detected in the event log when only one dhcp server was specified as dhcp relay. In short, activating any DHCP relay at all even with one relay agent upstream would trigger this and that behavior specifically was what was fixed*. With that said, it was explained to me that since more than 1 DHCP server is specified as a relay for the same vlan upstream in this situation, then the Multiple DHCP servers detected alert is actually true in this case since clients could receive offers from two separate servers, and therefore the DHCP server detection feature is functioning as intended in this case. + They had me test a private build ( 30.7 ? ) which didn't fix anything. Per support there is nothing to fix since this is expected. This is debatable. *Not fixed since removed from the changelog as you mentionned

RaphaelL

Support told me that this fix is for single DHCP relay ( one DHCP reply ) and not for multiple DHCP servers like my setup 😣

RaphaelL

Mmmm.... we were having these before MR30.X , still I don't think that this makes any sense. Or am I missing something ?

RaphaelL

Hi , I'm testing MR30.6 in a Lab. Since the upgrade , my event logs are flooded with : Vlans are configured on the MX , and the MX relays the DHCP requests to multiple DHCP servers , so of course multiple DHCP responses will be received. Support says this is expected... Anyone experiencing the same thing ? That doesn't make any sense to me... Clients connected to the MX or the MS on the same vlan do not generate these logs despite receiving multiple dhcp offers.

RaphaelL

Yup this is exactly what we are doing ! It's just one more annoying thing to do 😞

RaphaelL

The changlog is way different from what the dashboard is recently displaying... I don't like that

RaphaelL

Hi , Let's say I create a brand new Network 'NetA'. It contains the default rule base : {"rules":[{"comment":"Default rule","policy":"allow","protocol":"Any","srcPort":"Any","srcCidr":"Any","destPort":"Any","destCidr":"Any","syslogEnabled":false}]} Now If I create a new network 'NetB' and I PUT the firewall rules that I got from 'NetA' , I will end up with 2 default rules ... That's annoying... I have to modify the payload received by the API ( once again ) before doing a PUT to other networks... @sungod Have I missed something ? Support says this is expected since there are no checks to prevent duplicate rules. So depending where you source your 'GET' , you could end up with a tons of dupplicate default rules.. Eg : Get NetA , Put NetB , Get NetB , Put NetC , Get NetC Put NetD [...]

RaphaelL

No that information is not visible on the dashboard and not available via the API.

RaphaelL

Been using that feature for more than a year and it works fine ( most of the time ). Upload is not supported and won't be supported and that's pretty sad, it would have been a perfect feature !

RaphaelL

From what I understood , Support says they had a similar case with a customer with a "large" rulebase and everytime the cellular interface flaps , the MX has to "recalculate" the rulebase, and that would explain why they are seeing CPU spikes or peg @100% during the same timeslot.

RaphaelL · ‎Mar 18 2024

Upgrading to MX 18.107.9 ( latest patch ) doesn't fix this issue. Support is pointing to our "large" L3 firewall rule base ,which currently has 70-75 rules. We didn't have these issues before upgrade to MX18. I will keep digging.

RaphaelL · ‎Mar 15 2024

That's why I'm wondering if that behavior has changed in recent firmwares like MR30

RaphaelL · ‎Mar 15 2024

This page might help : https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Alert_-_Recent_802.1X_Failure Seems like your radius server is not responding to the testing done by Meraki : A node displays the Recent 802.1X Failure alert when the RADIUS testing feature is enabled and it doesn't get a reply from one or more of the configured RADIUS servers. The alert may just mean that the device didn't get a reply from the server once due to network conditions in that particular moment. Please keep reading to verify if is this a one-time situation or if there's a bigger problem.

RaphaelL · ‎Mar 14 2024

Hi , This is not enabled by default. It was a special request from our security teams. This has been working perfectly in 99.9% of our sites expect for the ones which contains Zebra devices ( however this issue can be replicated with other devices ) It is specified in the documentation , but can still bite you ( like it did for me )

About RaphaelL

RaphaelL

Raphael Letourneau

Community Record

Badges