About cmr

cmr

@UCcert that naming convention looks awfully similar to the one I've been using for the last 25 years 😈 . It works worldwide though I add one extra letter: Country code | site code | technology | device type | number i.e. UKBNES1 - United Kingdom, Brighton, Ethernet, Switch, 1 For a fibre switch replace E with F, for Token-Ring we used a T, however ES is replaced entirely with FW for corporate firewalls and PI for public internet ones as we aren't entirely consistent and we've never had a firewall that isn't Ethernet! Ultimately if everyone can find the device from the name then who cares what format you use! 🙂

cmr

@Shadius have you ever had any such devices in the organisation?

cmr

@theshmike did you use the Meraki cable testing function on the edge switch or something else for the wired clients?

cmr

@Inderdeep I'm saying we need to test as the MX100 can potentially have ~10 WAN interfaces according to the LEDs on the front, but in actual fact it can only have 2 in the software. I hope the MX105 can have four 🤞

cmr

@MeredithW any chance of getting @Inderdeep an MX105 so he can test the theory? 😇

cmr

@UCcert and @Inderdeep are you sure that you can setup three WANs and it isn't just two WANs out of the pair of SFP+ ports and pair of RJ-45 ports? @UCcert you should be able to test on the device you have as that has more than two physical WAN ports, does it allow more than two WAN connections?

cmr

@HaniAbuelkhair in short, from the dashboard, no! You might be able to using the APIs, it might be worth asking in that section as some people only look at areas they have expertise in.

cmr

Switch firmware versions MS 14.24 changelog Alerts MS390 upgrades from MS 14.19 or later will result in minimal impact to client traffic Branch additions SNMP support for MS390s RADIUS accounting support for MS390s Alternate Management Interface support for MS210/MS225/MS250/MS350/MS355/MS410/MS425/MS450 series switches QoS support for MS390s CoA support for MS390s STP anomaly detection events for non-MS390 series switches Adaptive policy support for MS390 series switches SecureConnect support for MS210/MS225/MS250/MS350/MS355/MS410/MS425/MS450 series switches Bug fixes in 14.23 MS390s - If duplicate DNS IPs were used in an SVI configuration, the MS390 SVI would not be updated Access policies configured in hybrid mode with critical auth VLANs defined would fail to authenticate MAB clients MS390 port traffic in the UI on occasion can show negative traffic for a client MS390 - OSPF area ID could not be configured higher than 65535. This has been resolved so a 32-bit value can be used In rare instances, MS390s can lose connectivity to dashboard and require a manual reboot to recover. Data plane traffic is not impacted when this issue is encountered. L3 stacks will experience packet loss after an L3 configuration change is made. In order to restore complete stack stability, a reboot may be required. MS390 stacks could report incomplete RSTP root information MS390s acting as STP root incorrectly reports "00:00:00:00:00:00 (priority 0)" on the switch details page (present since MS 12) MS390 ARP tables would show incorrect age values The UI for MS390 series switches will report the old STP bridge information until rebooted Bug fixes in 14.24 A port's STP configuration could be placed into a disabled state incorrectly if the port was removed from an LACP bundle MS390 stability enhancements MS120/125 series switches with multi-host authentication would not update hardware with new client information resulting in all traffic being inspected Adaptive Policy tag configurations on non-SGT peer interfaces received incorrect port configurations MS390 series switches have the option to have uplink client sampling disabled by Support. This is helpful for some deployments (https://documentation.meraki.com/MS/Monitoring_and_Reporting/Last_Seen_Switch_Port_of_Client_Keeps_Changing) Known issues Multiple RADIUS timeouts can lead to the switch rebooting In rare instances, a stack member may go offline until rebooted (present since MS 12) In rare instances, non-390 stack members will reboot (present since 12.29+) Due to FEC incompatibility between MS450 and Cisco Fabric Interconnect 6454, 100GbE links do not establish MS120s switchports with MAB authentication may randomly deauthenticate clients. In order to resume client authentication on that port, a switch reboot is required (present since MS 12) Packet loss is observed when pinging the MS390 management IP MS120s on rare occasions will reboot (present since MS 11) Stackpower is not enabled on MS390s by default Broadcast types of traffic can leak into the Guest VLAN if a port that fails authentication has a Voice VLAN configured, and dashboard has a Guest VLAN defined (present since MS 11) Links being established on a MS120 can result in neighboring ports to flap (present since MS 11) MS120s with multiple access policies enabled may reboot when port changes are made The traceroute live tool fails to run The UI will show clients connected to MS390 access ports as being on the "native" VLAN Stackings running PIM may encounter synchronization issues which can result in some receivers being unable to receive certain streams Enabling Combined Power on MS350/355 switches results in events being logged once per minute (present since MS 11) Networks containing a high number of switches may encounter issues saving changes on the Switch Settings page MS220 and MS320 switches may randomly reboot in large L2 domains (present since MS 11) The list of switches to clone from fails to load when cloning a switch in an organization with a large number of switches and networks Switchport tags cannot be removed if they are added after a port profile is attached to the switch In rare instances, when a stack reboots, ports may come up as "LACP blocked state", even if LACP is not configured (present since MS 10) MS390 stacks on rare occasions will require a manual reboot after the upgrade has completed MS390 series switches do not support SM sentry MS390 series switches do not support Syslog MS390 series switches do not support Meraki authentication MS390 series switches do not support URL redirection MS390 series switches do not support MAC whitelists MS390 series switches do not support loop detection MS390 series switches do not support warm spare/VRRP MS390 series switches do not support UDLD MS390 series switches do not support MAC flap detection MS350-24X and MS355 series switches do not negotiate UPoE over LLDP correctly (predates MS 10) Rebooting any MS390 stack member via the UI will result in the entire stack rebooting

cmr

@Twitch it is a big job if you have a lot of devices, but the APIs can be used to make a lot of it less bad...

cmr

@Twitch why not combine the two organisations?

cmr

@RameshSesetti this error is logged when a device leaves the APs coverage area. It might also be logged at other times. What firmware are you running and what are the devices that are connected?

cmr

@KarstenI I'll second that, we've got a couple of APs that keep dropping down to 100Mb/s a few days after a reboot, despite being on shielded CAT6/A structured cabling and patch leads. I think there are some contacts that need cleaning in the chains, but as our wireless traffic isn't high speed, just lots of users, fixing it isn't a top priority yet...

cmr

@UCcert I think @FlyingDutchman wants to use their internal DNS for internal servers, but not for the VoIP server. However they have a DNS entry for the VoIP server on their internal servers that points to a suboptimal IP address. Therefore the only options I can think of are: Remove internal entry for VoIP server and use public expressway for all connections Allow remote users to connect to VoIP server via existing MPLS route Maintain a second internal DNS server with only a subset of internal entries (not including the VoIP server) and point the VPN clients to that Somehow filter the responses the DNS server gives, so only internal hosts get the private VoIP server entry, but VPN hosts get the public entry <--- can this be done? Unless of course I am overthinking this!

cmr

@Brian_Scheele they are org wide, there is only Organization - Policy Objects. I think the use is more aimed at say access to central servers where multiple networks are traffic to servers x,y and z is allowed, with policy objects you can define the server group once and re-use. Are you managing multiple ASAs on different sites through one console?

cmr

@luanvh did you try with the power supply connected to the laptop?

cmr

@luanvh check the wireless chipsets in the Ubuntu laptops, if they are Intel WiF5 chipsets (826x, 926x) then see if they are okay when plugged into the power. If they are then check for power saving settings in the wireless drivers and disable Mu-MIMO /SIMD power saving first, then all power savings if that doesn't work. There seems to be an issue when those kick in that causes packet loss, performance drops and then effective disconnection.

cmr

@BHDJon the management IP on a Meraki switch is purely for that, think of it as an out of band management interface on more traditional switches. All VLANs that you want data traffic on can have SVIs to route between them and will act as normal.

cmr

A quick comparison on what might have been..

cmr

Looks a bit like an Anglepoise lamp, quite an interesting idea: https://meraki.cisco.com/product/security-cameras/indoor-security-cameras/mv2/

cmr

Includes a 1.2Gb Cat 18 LTE (4G) modem, still no 5G: https://meraki.cisco.com/product/cellular/integrated-antenna/mg41/ Also MG41E released, same but with external antennas: https://meraki.cisco.com/product/cellular/external-antenna/mg41e/

cmr

@AVIF as the MS-120s cannot stack, I'd connect each to the MX with two cables if traffic is mainly to the internet. If traffic is mainly internal then is connect the switches in a loop A-B, B-C and C-A. Spanning tree will block one connection, then connect one MS to the MX.

cmr

@BHDJon MS390 is a Cisco 9300 with a software layer on top, hence it behaves like other Cisco iOS switch stacks

cmr

@UCcert you can stop being quiet now 😉

cmr

I've been applying 28.1, but WiFi5 wave1 APs only update to 26.8.1 for that version, even thought both 28.1 and 27.7 include the security updates...

cmr

In addition to @Bruce's comment above, we actually run a setup like this where each site has 2 WAN connections from the MX pair, with either one or both as VPLS (L2 MPLS) circuits. At the main data centre the WANs are terminated on routed ports of a L3 switch stack and the MX250 pair are connected to them as single ended VPN concentrators, terminating all of the SD-WAN site-to-site connections. It's worked well for about 2 years now on 15.x firmware and although we got no-NAT enabled, we never used it as the user traffic all goes through the tunnels anyway, with only the MX to cloud traffic passing outside.

cmr

Community Record

Badges