I like your spoiler 😄 ... View more

Yep, as suspected. Meraki switches do the slow version once every 30 seconds. So I believe your Avaya's are timing out the channel and therefor you get a regular blocked link or issue due to the lacp mismatch. Since this is non-configurable on Meraki you'll have to change it on the avaya. ... View more

Ok, I won't be configuring any Avaya switches willingly any time soon.  God that CLI is butt-ugly to look at. Sorry... I have issues with switches where ports are configured under VLANs instead of VLANs in the ports 🙂 Anyway after looking and trying to understand the logic of that CLI I have come up with a Cisco variant that I could understand: Trunks on 1/23 and 5/24 switchport mode trunk switchport native vlan 128 switchport trunk allowed vlan 128,172,180,185,187,190,196 (global command)vlan dot1q tag native Etherchannel Po2 ports: 1/23, 5/24 Po2 enabled as multichassis etherchannel with a shared MAC address containing 180c.200f Following Avaya commands make me suspect that switch is running Fast LACPDU's (1s) lacp timeout-time port 1/23,5/23-24 short vlacp port 1/23-24,5/23-24 timeout short vlacp port 1/23-24,5/24 timeout-scale 5 vlacp port 1/23,5/24 enable Cisco switches themselves default to Slow LACPDU's (30s) Not sure about Meraki, I'll have to run a capture but I believe I saw a capture once where it said slow LACPDU's. So that could be the issue that the LACP is timing out too soon on the Avaya switches. Maybe if you could change it slow LACPDU's (timeout long I guess)... ... View more

Come on Philip you can do better than that. "The standard" of MST IS the use of multiple instances. It's the industry standard approach to getting some load balancing on your uplinks as an answer to Cisco's PVST+/RPVST. MSTP uses RSTP as convergence method so no changes there but there is a need to have at least two spanning-tree instances.  And then Meraki just uses a half baked solution to get rid of PVST compat issues instead of going the extra mile and supporting "The standard" fully. ... View more

Yeah, why don't you guys support MST fully.  Why only single instance? It does not introduce much complexity if you would allow multiple instances. I agree it's a step up to finally support MST so you only have a single set of BPDU's floating around the network as long as the Catalyst switches are also running MST.  But in a design where the core switches are not stacked (physical or virtual) you still end up with a blocked link... ... View more

Are your multicast sources on the same subnet/VLAN as the multicast receivers? If they are on different VLAN's where does the interVLAN routing happen? On the CORE switches or Firewall?  Or do you have multiple hops between your multicast sources and receivers? If they are on the same VLAN.  Are you running PIM on the first hop or do you use IGMP querier on the CORE switch? ... View more

Hey, you have not provided the exact config that is on your Avaya switches which makes it a bit hard to help troubleshoot. If you would paste each individual port config, the port channel interface config and some port channel verification command outputs on the avaya switch we could rule out any typical errors before it's a suspected bug or something. ... View more

Also make sure every single access port (connecting end devices) on your switches in your entire network is running in portfast/edge mode. If you don't every time a device turns off or on you will get a TCN flood in your network causing shortened MAC address lifetimes. ... View more

Yep, should be bidirectional.   On access points when capturing from the dashboard however it's only upstream (RX) traffic. ... View more

That's a bad way to have your devices in netflow. Isn't there a manual way to add your nodes in that software and then just get the netflow params right? The Meraki stuff is cloud managed not locally managed so there is no local way to affect them.  Device discovery can only be done through ping, cdp, lldp and SNMP in this case. You can use SNMP read community but that's about it. ... View more

For the SIP thing according to the documentation you shouldn't even need to enable default traffic shaping rules. All incoming DSCP EF PHB's are put in an unconfigurable real-time queue.  (I assume this is a strict priority queue) and the rest just gets the CBWFQ treatment. For the rest it's just guessing at the moment. ... View more

I have a similar bug where I want to apply a new Rf profile and only select override static power assignments but it also overrides the static channels and perhaps antenna assignments. So this is a bug and needs to be reported to support. ... View more

QoS features on MS switches is extremely basic. ... View more

Then traffic should all be tagged. It would be a great idea if that is indeed the case to capture that traffic using another vendors switch like a catalyst where you can use encapsulation replicate to see if the traffic is indeed tagged or not.  On windows pc's you do need to modify a registry key though. ... View more

I always do the following: - BPDU guard on all client ports and access point ports if they are Meraki (Meraki AP's don't send BPDU's). - Root guard on all downlinks from CORE to access layer - I would have wanted to put loopguard on uplinks of access layer switches but Meraki won't let me because we use the management inline with the network.   Also and this is important.  If you have a MX warmspare with the four uplinks from the switch network towards those MX's that you DON'T enable bpdu guard on those ports leading to the MX and never ever use drop untagged traffic on the MX because that causes a loop. ... View more

Yes it is a bit of a pickle. On one hand you want to use an unused VLAN as native to prevent VLAN hopping but that VLAN does not allow for a new MS switch or a factory defaulted one to come online without manual intervention. I'm not sure if Meraki does this but does the switch when trying to find it's initial connection to the could use something else than only native traffic.  Like does it try natively and then VLAN 1 tagged or not.   If it would you could set VLAN 1 up as a severely limited staging VLAN that runs tagged on the trunks down from the distribution/core switches.  By then setting the management VLAN to the definitive VLAN for management in the switch settings page, your switch would automatically switchover.  But I think this is wishful thinking. ... View more

I have a few customers where I use an external VLAN on the same switches to split an ISP modem into two ports for both MX'es.  According to the docu, I should add another switch that's not in the same dashboard network. So for those customers the feature cannot be used because I don't intend to introduce other switches just for this feature to work.  I hope they find a way around that. But all in all it's a move in the right direction since having an L3 switch behind the firewall has always been best practice design in campus environments. ... View more

Well I wouldn't call it SDA just yet. If it's just the SGT's they will be supporting you could call it trustsec. Up until now the MS switches only supported VACLs, not even PACLs or RACLs that's why you could only push a dynamic VLAN onto a port instead of a dACL which technically is a per session PACL.  So making the jump to SGT's makes me wonder where they will be supporting the SGACLs. Enough ACL'ing for today 😉 ... View more

The image is just wrong.   If you look at the switch image on this page: Main MS390-48 page  You'll see the correct module inserted. ... View more

You only have a few options. You could try to change the subnet you're on. You could change the subnet where the pc's and server are at. You could put yourself behind a NAT in that subnet you're on and try to build your VPN from there.  For example if you're on an AP SSID that does NAT instead of bridge mode. Finally there's another more expensive option to buy a Z3 appliance and do Site2site VPN instead. ... View more

"The subnet I'm in before I connect to VPN is 192.168.0.0/23." That's the problem:  The subnet you're in before connecting to the VPN overlaps in address space with 192.168.1.0/24. Your client will be arping for the destination on his own adapter, not the virtual adapter created by the L2TP. ... View more

My personal biggest beef is the lack of differentiated support for people in the networking field. What I mean is that as a network engineer myself I always try to give as much information as possible when opening a case by clearly formulating the problem and providing drawings and packet captures. I then always wait a few minutes before effectively calling support and expect them to first read the info I have given them instead of having to answer noob questions like 'have I tried using a factory made cable'.  My usual calm self quickly escalates to an erupting volcano if after 20 minutes on the phone I'm still answering silly questions after I explained the situation clearly enough for the third time. I do understand that I can make a mistake myself and perhaps have made a premature conclusion but in most of the cases the conclusions are correct and escalation is in order, but then some engineers just won't escalate and keep you answering noob questions and trying to find bogus reasons in the configuration why the problem exists. I think the engineer should be able to quickly gauge the skill level of the person on the other end of the line and adjust troubleshooting accordingly. ... View more

Or if you really want their email you could setup an excap. Then you need a website with php that just lets the users fill in their email and then sends the OK to the access point. ... View more

First the basics: So the LAN behind the MX is 192.168.1.0/24.  Do the PC's and server point to the LAN IP of the MX as default gateway? Second when you connect using L2TP/IPsec to the MX from a remote location do you have a full tunnel config or a split tunnel?  If you have split tunnel then you need to add a route in windows for the network 192.168.1.0/24. Thirdly also very important since you're using a very common subnet of 192.168.1.0/24 behind the MX you'll have to make sure the subnet where you're in at the remote location should not also be 192.168.1.0 or the connection will definitely fail. ... View more