If you have the IP address space or are using private IP's on the WAN you could ferry both ISP's over to the other building using 2 "external" VLANs.  So you could get WAN circuit redundancy for both buildings.   However your MX'es will remain single unless you get a secondary device of each type which doesn't cost that much and does not require a separate license. Trying to mix both networks to both MX'es is only technically possible if you use a Cisco native Catalyst mode switch and VRF's and use some fancy floating static routes.  However in that case you would never be able to announce these networks to each other over SD-WAN since that would require NAT.  So as already been said, your solution would reach quite a complexity without much added benefit. ... View more

Thank god for dashboard to point you in the right direction! There are many kinds of transmitters that transmit smallband signals in the 2.4 GHz including: cameras, baby monitors, RF based security motion detectors. If the environment is large it will be difficult to pinpoint the issue wihout knowing exactly what kind of devices could be transmitting there.  In that case you could hire someone who has a spectrum analyser type of device for example Ekahau Sidekick or Sidekick 2 that can search for where the signal is received strongest. There is a chance however that the machine that is transmitting the signal is in fact necessary and that would make a good case for avoiding 2.4 GHz SSID's in that area. ... View more

Alas you can't.  For that you would need a C9500 with Stackwise virtual. I don't have any customers with a full 3-tier network topology so all of them use collapsed core simplified campus architecture.  So the choice between C9500 and C9300 usually comes down to the fact if both collapsed core switches reside in the same closet or in different closets.  That and the fact that C9500 supports ISSU 😉 I believe you'll have to be on the lookout for the IOS XE 17.15 release on Meraki before having access to these features.  So at this time you will be a little stuck on a single coreswitch for routing. ... View more

If you are doing a design on 6 GHz in Europe 40 or even 20 MHz is considered normal.  Since if you use 80 MHz channels you only have room for 6 AP's within each other's range. So if you are purist and don't want any OBSS above -86 dBm you may very well need the extra channels. ... View more

Oh wow, it has been a while since I saw something to be really excited about.  This just has done it.  Now I fully understand why they couldn't deploy on the C9200 because they are still using the container way of configuring the device. ... View more

Of course, if you pit an MS355 to a C9300 switch you probably will get a better deal for the moment for the C9300.  However if the bulk if your customers use MS210, 225's for access layer switching then it is still a leap to the C9300's. I can totally see the appeal for C9300's or C9500's in distribution layer switching and I can more easily position those to customers. Usually our customers already have some cheap non monitored HP switch line present like a 2530 which you can't really compare.  So the price up is always a challenge to get them on board. ... View more

Absolutely! ... View more

EOS is a year away and then 5 years until EOL. But yes it has been a while in the cards. I'm hoping they will be able to fill the hole of the MS210-225 with the C9200 series.  I'm literally waiting on that since even with discount the C9300 is a rather expensive switch for my customers. ... View more

Pulling cables won't have any effect on the Cisco side with the default behavior of port channels.  The moment you configure a port to be in a port-channel with LACP it will by default not allow the link to pass traffic if it does not negotiate LACP.  So it will be in suspended mode as you mentioned. However if you disable that feature by using the command on the port channel like I said and the behavior returns you should see interfaces being up with a capital i (individual).  But it should pass traffic. If you want to have any foot in the door with the Meraki devs you'll need to provide some evidence that the Meraki's are not sending LACPDU's after reboot causing the link to come up individually.  Then you can use show commands on the Cisco side to verify if LACPDU's are being received from the Meraki switches. ... View more

Hairpin NAT works by default.  Just reach your own pub IP with the destination port you are forwarding and the MX will hairpin it back.  Be mindful however that if your MX is behind NAT itself (double NAT) the upstream device is in that case the one that needs to hairpin. ... View more

On the cisco core on a port-channel interface add the configuration.  no port-channel standalone disable. This will allow the ports to come up as individual ports and then you should check via the Cisco CLI if the Meraki switch are or are not sending LACPDU's. ... View more

If the C9300 is the L3 switch, first make sure that switch has a mgmt IP in a VLAN that exists directly behind the MX so that swtich can come online and receive it's config.   Then you create your SVI for  your uplink towards the MX with the default route in one go and then can you make each SVI. ... View more

The moment you go above 8 meters (26 feet) the signal via normal omni antennas may be insufficient on ground level for your handheld devices to receive.  Downtilt omni's don't cover the same horizontal distance at the same height but they concentrate more signal downwards so your usable signal on ground level covers a greater distance. The lightbulb with hat is a nice representation if that hat reflects the light rays downward to make them brighter. ... View more

Well I'm a little skeptical what an AI can offer who just gets it's information on any other public website 😉 I'm hoping since the MS130X/R series have some sort of advanced ASIC to support Adaptive policy it would also support NBAR at least for fingerprinting traffic. My question originates from the time you could not have non-NBAR and NBAR capable devices on the same network while NBAR was enabled.  Since newer networks are usually combined even MS210's with Wi-Fi 6(E) hardware it still can use NBAR on the Wi-Fi and MX side.  But this would cause inconsistencies in the traffic analytics. ... View more

If you are routing your internal VLAN's on those MX'es then that design will not work at all. If you have routing on an L3 switch you could have an option with a floating static route.  However with the mandatory default static route Meraki switch routing has this could be an issue to.  So in this case I would recommend a Catalyst based switch where you optionally use Meraki monitoring. You can have a Catalyst based switch that as a floating static pointing to the secondary MX exit and have a primary route that is dependent on an IP SLA or just line protocol status.  You could even throw in some VRF's to segregate VLAN's that must traverse an MX for policies. ... View more

Strange, the switch should be fully backward compatible with 802.3at and af standards. There could be an issue where the switch only gives power in mode A and the device is expecting mode B (using the other pair).   ... View more

I get your screenshot.  But can you provide a link to the documentation that states this feature.  I can't find anything on the IGMP querier page or the DHCP for MS page that states these switches have that feature.  The multicast page explicitly shows support starting from the MS250 family and does not specify any MS families for the IGMP querier function.  It would be a serious omission if there is no documentation on this. The specifications and overview document should also mention specific support on said product families that they support DHCP relay and IGMP querier functionality.   It's kind of hard to provide meaningful insights if the documentation omits crucial information like this. ... View more

Start by checking the timeline in dashboard.  If it says the client is leaving then it's definitely a client issue.  If it is some weird error number then it could be a myriad of problems.  Also check if the clients have good RSSI/SNR. ... View more

You should not be able to create an SVI on an MS125.  It has no SVI capabilities, it's a pure L2 switch.  Since that screen is general for your network, are you sure you didn't create an SVI for another switch? Since you can't make an SVI you also can't do any DHCP relaying. ... View more

Let me kindly add to your logic here. - If you would have a feature like DHCP discover or request suppression which most likely would be an option you could add into the DHCP snooping featureset.  This would in fact NOT be a feature you would do in the helper address since your topology could change during operation (links going up and down, STP reconvergences) making it undefined if you would have a mapping to the current DHCP server.  The fact a MAC address times out after 5 minutes especially if the DHCP server is quiet otherwise makes it's port towards that server uncertain.  So that will have to make flooding again. It would make sense to add a feature like this to the DHCP snooping featureset.  However on Meraki they chose to implement DHCP snooping through using MAC addresses.  On Cisco software DHCP snooping is done through trusted and untrusted ports which would be a good candidate to have only trusted ports forward any DHCP discover and request messages. The method proposed of the message starter has following caveats. To have DHCP relay on each switch would mean that each switch would have to have an SVI in each VLAN. The only good thing you are achieving here is limiting broadcasts to other switches in the network but each port on the local stack will still receive the discovers and offers. ... View more

No problem 😉 Btw Catalyst based switches have a maximum MTU of 9198 which is a tad lower. In my personal view, the only reason to actually need higher MTU is in fabric networks, what Meraki managed switches do not currently support or high end storage networking. All the rest uses the standard 1500 MTU anyways. ... View more