Meraki

RaphaelL · ‎Sep 23 2019

Found the ''answer'' With RADIUS testing enabled, all RADIUS servers will be tested by every node at least once per 24 hours regardless of test result. If a RADIUS test fails for a given node it will be tested again every hour until a passing result occurs. A subsequent pass will mark the server reachable and clear the alert, returning to the 24 hour testing cycle. 24 hours , pretty long time to find that a radius server is down

RaphaelL · ‎Sep 23 2019

This is also enabled : Radius testing If enabled, Meraki devices will periodically send Access-Request messages to these RADIUS servers using identity 'meraki_8021x_test' to ensure that the RADIUS servers are reachable. How often those packets are sent ?

RaphaelL · ‎Sep 23 2019

Ahhhh ! I was searching for MS ! This might be indeed the same thing. I will read that ! Thanks !

RaphaelL · ‎Sep 23 2019

Hi , I have a simple question. Let's say you have .1X enabled on your switch with 2 Radius servers ( RAD 1 and RAD 2 ). RAD 1 goes down , how will the switch notice that RAD 1 is down. From what I have heard , the ''keep-alive'' timer is from 0-24 hours. Since there is no reauth timer on the MS series, how will the stack notice that RAD 1 is down and forward the requests to RAD 2 ? Thanks

RaphaelL · ‎Sep 23 2019

Had similar issues , 26.X ( I tested 26.1 to 26.4 ) both my Samsung S8 and S10+ were pretty much unusable on Wifi ( felt like latency was rocking 600-700ms but speedtests were accurate ) Notifications ( snapchat , IG , facebook and so on , could take hours to get on my phones ). My Samsung Smart TV and sound bar were both connected on 5Ghz and they had no issue... Rolled back to MR25.13 and all issues are gone.

RaphaelL · ‎Sep 23 2019

Any solutions yet ? Thanks

RaphaelL · ‎Sep 4 2019

We have the exact same issues. I opened a case couple weeks ago without any way to fix it. Open SSID , IOS only and MR33/MR32 running on the 25.13 firmware. This is really annoying and currently affecting over 7k of our users.

RaphaelL · ‎Aug 26 2019

Do you mind sharing your source code or a part of it. I'm having the same exact issue as you and it was working in the past. I was so close to open a ticket / post here about this issue , but I figured out that my code might be in cause , although it was working in the past... Thanks

RaphaelL · ‎Aug 20 2019

MX67-68 still don't support .1X with the latest Beta software and doesn't seem to be in their roadmap either.

RaphaelL · ‎Aug 8 2019

Well , Support was able to reproduce the same issue in their lab. But it is only affecting Windows OS... "I was able to get a Windows 10 client setup in my lab and in that case I am now seeing the client perform a DHCP Renew every time it reauthenticates via .1x, exactly like we're seeing in your client sites. So in this case it appears that the DHCP transaction after a .1x reauth is expected for Windows 10 clients at least. " Has anyone experienced this issue ? Anyway to fix it ( parameters in windows or something ) ?

RaphaelL · ‎Aug 5 2019

Well , long story , I'm fully aware that Meraki products do not fit us at all. Also our 500-600 MX are all in configuration templates so the less we mess with it , the better. Thanks for the suggestions the public IP is always my last resort ( and I have used it in the past ). Preconfiguring our MX is always the best idea, but since we are a big company it's not always easy to keep track of everything. I might close this thread since there is no way to configure a mgmt interface. Thanks !

RaphaelL · ‎Aug 5 2019

Well , maybe my first post wasn't 100% clear. We have already set the creds within the cloud management and yes within the same subnet you can go to https://mx.meraki.com . But let's say the MX is installed in a remote site and https://mx.meraki.com ( These URLs will work for any Cisco Meraki devices listed above, but will only access the first device in its path. ) so we have to reach it with an IP that is configured on the MX. To do so , you have to create a vlan interface and set an appliance IP. That IP will get you to the local page, but at the cost of creating a useless vlan interface. This is how we are dealing with the local page for the moment.

RaphaelL · ‎Aug 5 2019

We are on the same page. But we have many cases that we need to configure the MX from the local page ( PPPoE ) which ( why ? ) can't be done from the dashboard

RaphaelL · ‎Aug 5 2019

I was wondering if it is possible to configure a management interface on a MX without having to create a dedicated vlan. Let me show an example : We have a router , a MS switch and a MX. The management vlan is defined on the router and the MS as a management IP from that vlan ( lets say vlan 100 ). Is it possible to configure the MX to have an IP on that VLAN ? Only way I found to achieve this is my creating the same vlan on the MX and giving the ''appliance IP'' a different one than the router ( router as .1 and MX has .10 for example ). This is not really ideal. Thanks !

RaphaelL · ‎Aug 2 2019

Thanks for the info. I'm not really a fan of this , so I'm going to configure these rules on our NGFW behind the MX. I don't like to idea to mess with those site-to-site firewall rules and accidently blocking the traffic for our 2k remote sites. I will mark this as resolved

RaphaelL · ‎Aug 2 2019

Let's say I want to block the remote site from reaching the servers. I would have to do this with the site-to-site VPN firewall outbound rules ? And these rules would also apply to ALL my other remote site ( 2k ) ?

RaphaelL · ‎Aug 2 2019

Hi there , We have a remote site ( MX65 ) with site-to-site VPN tunnel going to one of our MX cluster. Somehow , someone managed to configure many Site-to-site outbound firewall rules ( those rules are Org wide ! ). Those rules are only there to permit or deny specific traffic comming from the remote site. Why would you configure those rules on the site-to-site outbound firewall and not the MX ( remote site ) ? Currently any remote site ( that is participating to the site-to-site VPN ) is bound to those rules ( they are org wide ) Site-to-site Vs firewall rules Am I missing something ?

RaphaelL · ‎Jul 29 2019

This is what I got from support : After gathering the data and discussing this with our Engineering team we've determined that this is the expected behavior for MX devices using 802.1X based authentication. The current reauthentication timer on the MX is set at 3600s / 1hr, and I've confirmed that unfortunately at this time we are unable to change that value at all, so this is all working as expected in this situation from what we can see. I'm still worried about the DHCP renew at every reauth. I don't think that is a expected behavior...

RaphaelL · ‎Jul 17 2019

I don't know about the SDK but I'm using this : import os proxy = 'proxyURL' os.environ['http_proxy'] = proxy os.environ['HTTP_PROXY'] = proxy os.environ['https_proxy'] = proxy os.environ['HTTPS_PROXY'] = proxy works like a charm.

RaphaelL · ‎Jul 17 2019

No worries ! That is part of the issue , there is 0 settings for MAB / 802.1X on the MX ( except de radius port and server ) and I can't find any documentation from Meraki. I think I will have to open a support ticket about this one and post the result here.

RaphaelL · ‎Jul 17 2019

There is no switch in the situation the devices are directly plugged into the MX. Device -> MX -> ISE. In that case the MX is the Authenticator.

RaphaelL · ‎Jul 17 2019

Thank you , but I'm well aware of the situation of the MX68 , the log below is exactly the same for all our MX65(W) , should have mentioned it.

RaphaelL · ‎Jul 16 2019

Hi , This is a fairly complex issue. We are running the 14.39 firmware with MX65(W) and MX68. We activated the 802.1X / MAB auth ( hybrid ) and since that activation every device is renewing it's DHCP lease every single hour ( 1 hour 16-18 secs ) This is annoying because it is flooding our logs and the lease we are giving to our devices are 24h ( should renew at 12h ) This is affecting all our 2k teleworker. Devices that are authenticated via MAB do not renew every hour. Cisco IP phones ( multiple models , also do not renew but are reauthing every hour ). In Cisco ISE we don't see anything suspicious and everything is working fine on our MS. MX is a different story. See the logs below : As anyone seen this issue ?

RaphaelL · ‎Jun 18 2019

I guess there are 2 types of straight people also. People that are open minded and people that feel intimidated by a temporary logo supporting a good cause. Thanks and have a great day.

RaphaelL · ‎Jun 5 2019

Well another case this morning , a teleworker reported some issue with his MX : Latency dropped right after the reboot but is still high. Maybe a 3rd reboot would fix it.

About RaphaelL

RaphaelL

Raphael Letourneau

Community Record

Badges