Meraki

cmr · ‎Oct 6 2020

Installed on a single MS210-48P and a MS120-8P this morning, no issues so far...

cmr · ‎Oct 6 2020

Finally fixes ARP entry timing out when still in use: Switch firmware versions MS 12.29 changelog Alerts MS210/225/250 switches cannot forward IPv6 Router Advertisement and Neighbor Solicitation packets when flood unknown multicast is disabled (has always been true) MS390 upgrades from MS 12.28 or later will result in minimal impact to client traffic MS390 client authentication may fail closed if RADIUS server passes unsupported AVPs Auth session state on RADIUS server may be stale following an MS390 CoA update until RADIUS Accounting is supported Additions Support for MS390 Series Switches Loop Detection on MS210/225/250/350/355/410/420/425/450 series switches MAC Flap Detection on MS210/225/250/350/355/410/420/425/450 series switches MS390 Local Status Page identifies ports on other stack members by name instead of MAC address Features now supported on MS390: RADIUS Testing, RADIUS CoA Bug fixes ARP entry on L3 switch can expire despite still being in use (predates MS 10.x) Editing properties of an existing L3 interface on MS390 switches don't take effect without a reboot Certain egress protocol packets missing from switch port packet captures Stack member switches might fail to forward multicast stream out ports with known receivers Changing configurations of various port settings on MS390 switches can result in the port not successfully participating in a configured LAG Ports configured for Access mode on MS390s can incur a 30sec delay before they forward traffic Known issues Routing to a particular next-hop can fail under specific conditions for non-MS390 switch stacks MS390 stack members may not report client-level detail MS390 series switches Max MTU is limited to 9198 bytes MS390 series switches will not display packet details in the DHCP Servers page MS390 series switches do not support the 'next-server' or 'bootfile' parameters in DHCP messages Rebooting a single switch in an MS390 stack will reboot the entire stack LLDP frames from MS390 series switches will use a single system name instead of the Dashboard given name MS390 series switches will not display the advertising router ID for OSPF MS390 series switches with OSPF enabled will default to an IP MTU of 1500 bytes on every OSPF enabled interface MS390 series switches do not support the multicast routing livetool MS390 series switches do not support tagged traffic bypass for voice on ports with a Multi-Auth access policy Dynamic VLAN assignment from a RADIUS server on MS390 series switches must already be an allowed VLAN on the port for it to function MS390 series switches may not display link state on links at mGig speeds (2.5G, 5G) MS390 series switches do not currently support the following features: VRRP, SM Sentry, Syslog server, SNMP, Traceroute, IPv6 connectivity to dashboard, Meraki Auth, URL Redirection, MAC Whitelisting, RADIUS Accounting, QoS, Power Supply State, PoE power status/usage, Loop Detection, UDLD, MAC Flap Detection SM Sentry does not support Windows based clients (predates MS 10.x) MS425 series switches do not forward frames larger than 9416 bytes (predates MS 10.x) MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (predates MS 10.x) Other Various performance and stability improvements

cmr · ‎Oct 4 2020

The Microsoft NPS is such a tool, it has RADIUS conversations on one side and talks to AD on the other.

cmr · ‎Oct 4 2020

@roesljas thank you and in answwr to your questions: Would this technically mean that there are two gateways on the network, the MX VLAN IP and the MS SVI? Technically yes, but you would point all devices to the gateway on the MS, either with the DHCP option or manually Also would the DHCP relay at the MS be required in this instance given that the VLANs pass from MX to MS? No need as the MX is on the VLANs itself Would you use L3 rules on the MX to ensure it doesn't inter-VLAN route? No need either as if no devices point to it then it won't route. However this all has one big caveat, we dont use that MX for the main external access, otherwise you will have the issues you are thinking about. We have a separate MX for the external access and the one used for DHCP is only for the wireless public customer network that doesn't route to any of the other networks and is protected by the SSID setting of not having LAN access. If you want to use the MX as the main gateway and providing DHCP then you would probably need to route on the MX as otherwise you would end up with inbound traffic from the outside using the SVI on the MX and outbound traffic using the VLAN interface on the MS. If you don't need a separate MX for public traffic it would still be economically better to buy a small MX just for DHCP than upgrade the whole stack to MS250s just for that feature...

cmr · ‎Oct 3 2020

@GIdenJoe any reason why you are using such an old MX firmware, 14.53 is current and about 6 versions newer?

cmr · ‎Oct 3 2020

I'm pretty sure it was trusing DSCP as it was routing the packets to the different queues before the MXs were put in place and we hadn't told them what traffic we wanted in each queue other than by DSCP value. We since disabled QoS on the MPLS so now it trusts no-one 😇

cmr · ‎Oct 3 2020

Just a pointer but we have tagged traffic that was going over an MPLS network and dividing into three classes. When we added MXs and created autoVPN over the MPLS, all the traffic ended up in the base class. This was with the 15.x release train. I didnt do any wireshark captures but I do know that once the autoVPN was created no tagged traffic matched to anything other than the base tier.

cmr · ‎Oct 3 2020

@roesljas In answer to your questions: 1) you need one IP for each switch management interface and one for the MX so I'd go with a /29 at minimum 2) access port to MX for management VLAN, trunk port to MX for VLANs that need DHCP 3) yes, routing IP on VLAN interface on MS and other IP just for DHCP on MX 4) yes 5) DHCP option set on MX, option 3 set to the VLAN interface IP on the MS

cmr · ‎Oct 2 2020

@roesljas I know that will work as we have exactly that setup at our HQ. MS210s stacked and doing L3 routing but using an MX as the DHCP server. 15 VLANs from memory, there is a limit of 16 VLAN interfaces. About half have their DHCP from the MX. Works just fine 😎

cmr · ‎Oct 2 2020

@rafaelertel This was the same issue that the dashboard page had and it was pulled after a few days never to return 🙁

cmr · ‎Oct 1 2020

@ToryDav unless you can use LACP port aggregation on the firewalls, just one link from the stack to each firewall will be active, spanning tree protocol (STP) should shut down the other ones so you don't get a traffic loop. If you can use port aggregation on the firewalls then you can have multiple active links and improved bandwidth.

cmr · ‎Oct 1 2020

@ValleyITPC are you sure you are seeing the port for an MX, I only have this option for combined networks that include an MX and when you look at the connected to, the devices that have an MX there have no port. If I go to an MX only network (even with an MX250) I don't get this option.

cmr · ‎Sep 30 2020

Can you see any clients connected to any of the MR33s, another place to look is Mesh neighbours, it will show what other APs each MR33 can see. Are the APs not placed on the map, or a floor plan?

cmr · ‎Sep 30 2020

Hi @maconte34 welcome to the Meraki forum, the friendliest and most helpful forum I have had the luck to find. I think the units that look like MR33s might be the MR74 patch or sector antennas. Have a look here and let us know if any of those look like what you have: https://meraki.cisco.com/product-category/wi-fi/wireless-accessories/wireless-accessories-antennas/ Cheers, Charles

cmr · ‎Sep 28 2020

That is why I said try, if it is also broken then that is good info for the Meraki techs, if it is not then you have a choice.

cmr · ‎Sep 26 2020

@MarcAEC glad to know you fixed it, out of interest, with the ones set to DHCP, were they getting their IP address from DHCP and if so do you have the domain option set on the DHCP server? I think it might actually be the fix as we always have that field set correctly and haven't had any issues with ours, so it does make some sense 😀

cmr · ‎Sep 24 2020

Have you tried the MX15 firmware, it is updated far more often and may work differently, if it doesn't work you can always roll back to MX14.

cmr · ‎Sep 23 2020

@CharlieCrackle not that it helps but we have some MX64s on 15.36, they were on 15.33 and upgraded the day 15.36 came out. Also MX65s, 67s, 84s and 100s. Have support any idea why yours are bricking?

cmr · ‎Sep 22 2020

@MarcAEC Is there a correlation between the sitrs that work and the sites that are/aren't over MPLS?

cmr · ‎Sep 22 2020

@MarcAEC I'd agree with @PhilipDAth, we have an MX based SD-WAN and Ricoh copiers with scan to email to local Exchange and don't see any issues. However we have the Enterprise license that doesn't include IPS/AMP as our WAN links are all flavours of MPLS...

cmr · ‎Sep 20 2020

@DarrenOC I'm sure I have those somewhere, would you like me to share? 😇

cmr · ‎Sep 18 2020

Wow, that is a rather good reason to have the MX concentrator as a single arm one without advanced licensing and to use a different vendor's equipment on the Enterprise edge then apply the advanced filtering there, thus protecting both. Either that or terminate the VPN as above and use MXs at the edge, but pay for Advanced licensing on both!!! I am astonished that Meraki think it is acceptable for home-working users to be exposed in this way and glad that by chance we are set up like the first option...

cmr · ‎Sep 17 2020

@colby_oc do the Dell XPSes have Killer(Intel) WiFi5 NICs, if so do they drop when on battery or also when wired?

cmr · ‎Sep 16 2020

Excellent, glad to help a fellow Merakier 👍

cmr · ‎Sep 15 2020

I thought we (the community) usually were in the dark... 🤔

About cmr

cmr

Community Record

Badges