About Brash

Brash

Is there any correlation between the computers with the issue vs those that work,? Eg. Model, OS, wifi adapter and driver

Brash

Intel Wifi drivers have historically been pretty buggy. Here is a post raised for issues on Intel adapters last month. https://community.meraki.com/t5/Wireless-LAN/Intel-Wireless-Adapter-Client-loses-internet-connectivity-after/m-p/139936 See if your issue correlates to a specific driver version, check the release notes etc.

Brash

Have you verified that the ISP side is set to autonegotiate? When testing, did you try manually setting the speed on the port on both sides? I've heard of some issues with 10GB autonegotiating between mx250's and ISP equipment.

Brash

Not sure how well it would work but in theory you could create a group policy that blocks all traffic, then manually add the client with the Mac address and assign it the group policy.

Brash

Yes, you can use any standard c13-c14 cable. The Meraki power cables are c15 (they have the notch at the bottom of the plug) but the devices don't explicitly require this.

Brash

It seems like a device on the wifi is flooding the AP with broadcast traffic. More info can be seen in the air marshal docs https://documentation.meraki.com/MR/Monitoring_and_Reporting/Common_Wireless_Event_Log_Messages#Air_Marshal_Event_Log_Messages Typically flooding will cause problems when buffers are overloaded or specific devices (DHCP servers, gateways etc) are overwhelmed by requests. It's difficult to say exactly whether this would cause a major impact in your environment but I would think most enterprise equipment should be able to deal with 1000 packets in a 10 second interval.

Brash

There may be a battlecard or comparison in the Meraki Partner Portal or in Cisco Salesconnect. If not, check with your Cisco rep to see if there's some internal material they can share.

Brash

You can't apply IP addresses directly to the ports on Meraki. You will need to use Vlans and SVI's.

Brash

Both are acceptable options. It mainly comes down to design preference. One thing to be aware of with option 2 is that you'll have an SVI for each network on the MS, and therefore the ability to route between the networks. If you want to prevent this, you'll need to use Meraki ACL's which (in my opinion) will probably be harder to manage than Forti's stateful firewall rules and zones. Assuming the Forti can do SVI's, a 3rd option you could consider is having a single link between the MS and the Forti with all applicable VLAN's trunked up.

Brash

One thing to ensure is that if you're assigning vlans to clients via the Extreme Networks WAP you don't want that same vlan as native on the Meraki switch port.

Brash

What do your Layer 3 firewall rules look like under "Security & SD-WAN -> Firewall"? Are you using any group policies for either of the two devices?

Brash

Policy objects are available for Layer 3 firewall rules configured on the MX (under Security & Sd-WAN -> Firewall).

Brash

If the phone has an external power supply, it won't require PoE and therefore it will resolve your issue of the phone not powering up. I'm not confident it will solve all of your CRC issues though.

Brash

Meraki begun as a separate company and was acquired by Cisco. Therefore they don't typically use Cisco proprietary features, but opt for industry standards. One example of this that comes to mind is Spanning Tree. To be honest, I'm not even sure whether Cisco still uses their proprietary PoE implementation over the standard these days (haven't deployed a Cisco IP Phone in years).

Brash

Cisco 7940's only support Cisco's proprietary PoE implementation, which is not available on Meraki switches. Therefore it's expected that the phone will not power up via PoE. https://community.cisco.com/t5/ip-telephony-and-phones/7940-and-802-3af/td-p/795794 As for your other comment with CRC's and the phone only communicating when brought down to 100Mbps - that smells very much like a layer 1 problem somewhere along the line. Replace the cable (and SFP if applicable).

Brash

With the MS in a stack, they are essentially a single switch. When you connect a second cable to the MX, you're inadvertently causing a loop in the network as you have 2 connections between the devices. Because the MX does not run spanning-tree, it will pass BPDU's through between the two links. In theory, spanning-tree should detect this loop and disable (AKA spanning-tree block) one of the links. Have a look at the following thread for more info. Solved: more uplink from MS switch stack to MX firewall make switches unavailiable - The Meraki Community

Brash

You can access the MX and change it via the local status page https://community.meraki.com/t5/Security-SD-WAN/MX250-change-external-IP-without-internet/m-p/174662#M41326

Brash

Check the radius logs. It should indicate the reason for the auth failures.

Brash

Depends on the brand but In theory yes. Easiest way to check is see if it's still broadcasting. You can use simple free tools to pick up the broadcast MAC of an ssid. You can then use that to correlate to the source AP. I often use an Android app called wifi analyser. Other than that, you should also be able to see the AP as a rogue AP in the dashboard under air marshal.

Brash

You can certainly do this. You can use an MX as your router/gateway and connect your AP directly to it (either from a PoE port or with a PoE injector). You can then mesh other AP's from this one. I suggest looking into the advantages and disadvantages of meshing however as there is throughput and airtime impact to going down this route. https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Wireless_Mesh_Networking

Brash

Inbound firewall rules can be opened upon request via Meraki Support Solved: Meraki MX Inbound Firewall Rules - The Meraki Community That said, I'm not sure how exactly that would benefit for scanning devices within your network. How exactly do they intend to scan the devices in your network?

Brash

Assuming you need to statically set an IP address for the new ISP, you can access the MX's local status page to do so. Using the Cisco Meraki Device Local Status Page - Cisco Meraki

Brash

What version of windows server were you running before and what version have you upgraded to? Also, what version of MX firmware?

Brash

The thread has been updated to outline that engineering identified the impacted devices and Meraki is reaching out to customers. What it's lacking however is any detail around why it occured, and whether further safeguards are being put in place to prevent anything like this from occurring in future. I would expect monitor mode to be completely hands-off in terms of the ability to change configuration on a switch.

Brash

Jeez that's messy! Interesting to know what caused it for everyone to be impacted at the same time. I had expected something like that might happen in management mode but the fact it occured in monitor mode is deeply concerning.

Brash

Community Record

Badges