i have share two project  ... View more

Glad it worked for you. I'd love to see an update version. ... View more

a pair of MX450 that i manage have the same issue.  i have a ticket in.   ... View more

I think you can use syslog for the event logs (network-wide), but not for the change log (organization). ... View more

Hi, thanks but there is no mention about order/priority and monitoring the status when there are multiple AutoVPN paths, internal and external, between VPN concentrators. ... View more

Hi Ivan,   Like with Alemabrahao, thank you for stepping up and opening yourself to helping me. I will get you the topology map you asked for as soon as I get a chance, and I will also answer your questions to the best of my abilities ASAP. I have been in the field all day and am just catching up, but will try to put something together over the next couple of days. Thanks again!  ... View more

Thank you all for the information, much appreciated. ... View more

Hi @MichaelN ,   "Uplink packet loss and latency for this location is around 10-20ms, and 1-2%."   Packet loss at 1-2 % may not seem much. But with TCP it is a lot. I would focus here on eliminating the Uplink packet loss. Try changing cables, checked Traffic Shaping with ISP. Run ping tests to various end points (Public DNS Servers, ISP Gateway & DNS, any popular Internet site of choice). This will give you a good benchmark to confirm if the 1-2% is consistent or transient. ... View more

To assign an SSID to a VLAN with a specific IP range, you will have to config the SSID in bridge mode, not the default NAT mode. Tag the relevant APs with the correct VLAN ID, and make sure your trunked switch ports for those APs allow the new VLAN, too. That one tripped me up. ... View more

Hi @ALE727 , @PhilipDAth , @rwiesmann & @Brash  are spot on. A 'Soultions Engineer' will work with you (in tandem with the acounts team) ensuring critical services and sites are taking into consideration with a large deployment like this. ... View more

Hi @cabricharme ,   Mar 20 07:12:53 R12 Sw2 Port 22 Switch port Port status change port: 22, old: down, new: 10fdx Mar 20 07:12:26 R12 Sw2 Port 22 Switch port Port status change port: 22, old: 100fdx, new: down If we focus just on these two event logs. We see that Whatever device is connected to Port 22 on Sw2. The Speed is fluctuating from 10 megabits per second to 100 megabit per second and then back again. This would only be due to Layer 1/Physical conditions. I.e. faulty, cabling, ports or port controller misbehaving.   Judging from my experience and the frequency that this is occurring. I would;   a.) Replace the cable first. Use a known working cable. I.e. already used from another device not having this issue. Then if it is still occurring, b.) Connect a known working device to the same port. Then if it is still occurring on Port 22. It looks to be the switch port. Raise a case with Support. If it stops, then move the affected device to another good working port. If the issue occurs, then you know it is the end device. ... View more

I wish Meraki would suppress the link down -> RSTP disabled and link up -> RSTP designated on portfast/edge ports cause these just flood the eventlog for no real benefit.  It is already enough to have the link down link up on these ports. ... View more

Thanks Ivan! ... View more

Thanks for the replies. ... View more

yeah I see how this works, but this creates a problem: the internet firewall is now processing the decrypted internal traffic as well, because the MX decrypts the incoming traffic, and then routes it back to the internet firewall, which now routes the traffic back (again) to the internal network. This places an unnecessary load on the internet firewall to process additional traffic. ... View more

Already done good sir, I even have my replacement unit that has been solid so far but the last unit took months before I saw the issue pop up. ... View more

Hi @Ab79 , Looking at the screenshot, the signal strength is excellent! So that doesn't look like the issue here. What is the user actually reporting? or was this just simply 'noticed' in the Dashboard?     ... View more

Good stuff man!!! ... View more

I agree with Ivan that ‘MS series switches can participate in spanning tree only when a spanning tree instance is running on Native VLAN of ALL switches. In addition, Native VLAN must be allowed on all Trunk ports running Rapid-PVST, so that BPDUs are seen by the Meraki switches in the topology.’ ... View more

Hi Ivan,   Nope, it's 47.2W. Please find the sample output below. Is this normal? I mean, the AP is overconsuming above than the stated wattage on the device manual?   I do not think spanning tree is shutting ports, since the port is not disabled. Only the device is going down the up again. I have checked, my switch is configured in power sharing.   I only connect 1 LAN into the MR57 AP. So I do not have aggregation towards the AP in my deployment.   ... View more

Possibly a faulty controller? Let us know how you go. ... View more

BPDUs are never sent untagged. It must have a VLAN-ID. So then yes, you must tag on the non-meraki switch Trunk ports. Which is more manual work to do and get working, and a pain to tshoot..  You don't have to use Option a. You mention the non-meraki switches can run MST. If you run the same Spanning Tree Protocol across all switches. Then it's very easy to design and tshoot.  Here is the rest of the quote: "MS series switches to participate in spanning tree a spanning tree instance must be running on VLAN 1 of all switches and VLAN 1 is allowed on all trunk ports running PVST+ so that BPDUs are seen by the Meraki switches in the topology." ... View more

Hi @allywenzel , I do see this type of situation often. Usally something changes to cause this.  That log "stp_tcn_error" 'Topology Change Notification". Meaning the Layer 2 path or Spanning Tree is changing where all traffic should go. Most of the time, someone plugged in something. Or in your case, most likley a cable or device is misbehaving. As @RaphaelL reccomended, check you RSTP Root and make sure it is it is in fact the Root. Use the following guides to assist in the investigating and mitigation.    https://documentation.meraki.com/MS/Monitoring_and_Reporting/Loop_and_MAC_Flap_Detection_on_MS   https://documentation.meraki.com/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MS_Switching/General_MS_Best_Practices       ... View more

For beginners, there is a Getting Started with Cisco Meraki webinar scheduled for Thursday 12/12 at 9:00am PST.   ... View more

Oh damn, of course, you are right. It is even clearly described in the link I added, but I messed that up. Thanks for the correction. ... View more