About cmr

cmr

Purely from the spec I'd agree with you, but as it was mentioned that new devices were coming for fridges and freezers, I think the spec may be "optimised" shortly...! I'm getting an MT10 shortly and will test it in a fridge with a known temperature to see if I get the same errors.

cmr

A fridge should be at 3-5C so if the MT10 supports down to 0C then it should report that. In another discussion it was asked if the MT10 could be used in fridges and freezers and the answer was no, it was not designed for that and there would be new devices to support those scenarios. I'd think it might be calibrated more for room temperature?

cmr

@ScottHardin you should really post this in the Wireless LAN forum but in answer to your question, all Meraki APs support mesh and it does just work. However a wireless only AP can, as far as I know, only mesh with a wired wireless AP. So in your case AP1 and AP2 would work, but AP3 would look for AP1 rather than AP2. Also remember that ever wireless hop halves the data rate so AP3 would be a quarter of AP1 speed if it were able to work.

cmr

Switch firmware versions MS 14.8 changelog Alerts MS390 stacks of 4 or more may experience instability on this release. For stacks of 4 or more please stay on the current general release to ensure stability and functionality. MS390 upgrades from MS 14.7 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 MS210/225/250 switches cannot forward IPv6 Router Advertisement and Neighbor Solicitation packets when flood unknown multicast is disabled (has always been true) Bug fixes Rare chance non-MS390 switch stack can crash and reboot using multicast routing Incoming packets to a non-MS390 switch stack can be routed suboptimally after members of the stack reboot Known issues MS425 stacks directly exposed to large L2 domains can experience stability reduction 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 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, 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

Ambient temperature of location Workload (look at Organization / Summary Report to see loading) Is it in free air (the case is a heatsink for the unit)

cmr

Is the MR all DHCP or do you have some static settings?

cmr

If you set your PC to one of those DNS servers, can you lookup domains, particularly Meraki ones?

cmr

Sounds like it is in dual master mode where both MXs would want to use vIP, or are you not using that option?

cmr

@xeg12 it is pretty much a ball, check out the bottom of the datasheet here: https://documentation.meraki.com/MR/MR_Overview_and_Specifications/MR36_Datasheet

cmr

I'm going with C...

cmr

So far I have checked all the below devices on firmwares from 15.37 to 15.40 Z3 64 65 67 84 84 HA pair 100 HA pair 250 HA pair None populate the CPU graph with any data ☹

cmr

@PhilipDAth as long as the alerts act on both scales at the same actual point, I'd think it is good. We are in the UK but our parent company is in the US so different users would want the different scales. If the alerts aren't bi-temperate then it should be an overall setting as you said.

cmr

I know this is an old thread, but yes you can, our MX250 HA pair have been running old GLC-T modules for over a year without any issues. We are using the ones with the plastic and wire as we find the metal clip ones can get stuck in devices...

cmr

If the ethernet port on the Pi is set as the LAN then the PC should be simply able to plug into it, pretty much every ethernet port does auto X-over these days, so you shouldn't need a switch.

cmr

@BrianPay you stated you monitor the Comcast gateway IP, do you not also monitor the AT&T gateway IP? If not then it is no surprise that they are affected at the same time as you are monitoring the Comcast network from both WANs. This also ties in with the MX that only had AT&T connected being okay. Add a second monitor and remember that although each monitored IP will have graph data for both, only the Comcast IP from the Comcast link and the AT&T IP from the AT&T link are good measures. It won't fix the issue but should at least confirm if both links are fully affected. For the VPN users, do they come in on the Comcast link, or do you use DNS round robin with them coming in on both?

cmr

Today we upgraded a L3 stack of 3xMS210-48Ps and so far so good, we had been stuck on 12.17 due to not all VLANs routing properly after trying to upgrade to a later 12.x release.

cmr

@AndyP it has been previously noted in the community that there are no plans for enhancing the current SNMP functionality as the APIs are the preferred method of managing and monitoring Meraki equipment outside of the dashboard. I'd make a wish though as you may get lucky.

cmr

Beware the golf ball

cmr

Switch firmware versions MS 14.7 changelog Alerts MS390 stacks of 4 or more may experience instability on this release. For stacks of 4 or more please stay on the current general release to ensure stability and functionality. MS390 upgrades from MS 14.6 or earlier will trigger a full system reload 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 MS210/225/250 switches cannot forward IPv6 Router Advertisement and Neighbour Solicitation packets when flood unknown multicast is disabled (has always been true) Additions Performance improvement to MS390 cold boot-up and reload time Bug fixes Dashboard traffic analytics data can erroneously report certain clients are directly connected to a port on an MS390 Cycling a large number of ports on an MS390 stack can produce a temporary Dashboard connection interruption Known issues MS425 stacks directly exposed to large L2 domains can experience stability reduction 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 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, 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

MS390 - Adaptive policy, QoS, mGig port display fixes, dashboard client display fixes MSother - Group policy ACL Assorted bug fixes I'd have thought other new features, MS390 fixes will all be in this release train

cmr

If they won't let you see what the MX does then ditch it, the whole point of Meraki is you get good visibility! If they want you to go to 1Gb then BT would have to replace the MX68 as it only supports up to 450Mb. What a waste of a good piece of equipment 🤦‍ ♂️

cmr

I think the MX may be routing, we usually have the fibre coming in, the full width 1U ADVA with the two power connectors on the left hand side, then a second 'smarter' half width ADVA with a single PSU that breaks out the services to individual ports. I'm guessing the MX is playing that role, but is way over engineered to be just splitting up a trunk into it's constituent VLANs. For you if you only have pure Internet access it is pretty much just being a wire... Before removing the MX do a traceroute to the Internet to see if you can tell which mode the MX is in and if in routed, what the IP on the MX WAN port is. We had a similar problem with ISP kit in South Africa about a year ago and did remove the intermediate device and they never complained!

cmr

You might be better with a layer 2 device like an ADVA, it doesn't sound like the MX is giving you any value and only potential incompatibilities. Can you not at least get read only access to it, seems a strange choice for an ISP to issue a very capable edge device and neuter it...!

cmr

@Brian_R if you want to do this, I think you'll need to use private DNS, so the traffic doesn't try to go out of the WAN port. At the moment you have traffic heading out of the WAN only to be sent straight back on the same interface (different IP?), In through to the LAN, to the Exchange server. The return traffic gets confused as it'll head back to the MX, finds out that the IP address it is looking for is on a different LAN port, wants to head off that way back to the client but as it is a stateful firewall there is no return path that way so gets dropped. If you have private DNS to give the client the internal IP then it can route that way, if you want it to be totally separate, run the public connection on a separate device.

cmr

@Matt7 Am I right in that you are using the MX and Draytek in line with both NATing? May I ask why, is the MX managed by BT and can you not control it?

cmr

Community Record

Badges