About Brash

Brash

Static routes can only be added to the MX where the next hop is on a local subnet. From what I've read, most people are working around this by placing a switch between dishy and the MX. They then connect both the MX's WAN port and LAN port to the switch, and create a vlan on the MX with the 192.168.100.x subnet in order to reach the stats page. Can't say its elegant but apparently it works...

Brash

Speaking from gleaned knowledge rather than experience. You can't have two tunnels to the same destination on the Meraki side. The way to implement redundancy for a non Meraki S2S connection is to have a second WAN link on the MX with a separate public IP. On the ASA, you then configure the backup IP for the tunnel to point to the MX's second WAN link. In this way, is there is an issue with the primary link, the tunnel will be re-established on the backup link with a very minor impact to network traffic.

Brash

If all of your AP's are wired into the network, then yes you don't need meshing. Disabling it will stop it from broadcasting the mesh SSID thereby freeing up some airtime. Meshing isn't required for AP to AP communication in terms of client balancing etc. This information is sent as encrypted broadcasts over the LAN connection. https://documentation.meraki.com/MR/Other_Topics/Client_Balancing#Information_Exchange

Brash

Quick check of the Microsoft doco shows you've covered most of the ports. Can you run a packet capture (on whichever Meraki device is most applicable in your network) to see which other ports the PC is attempting to communicate to the DC?

Brash

If you configure the VMware side as a LAG, you will need to configure the Meraki side as a LAG too. Load balancing mechanism of SRC/day IP hash. If you simply have the uplinks in the vswitch, the ports need to be regular ports of the Meraki side. Load balancing must be either route by virtual port ID or source mac hash.

Brash

Not much to go on but initial guess is your vSwitch isn't failing over properly. What is your teaming policy and settings? A few things to try: - Try manually pinning vmk0 to vminc1, and verify whether the server is still reachable. That will rule out the Meraki side switchport config etc. - With the vmk0 pinned to vmnic0, try removing the cable on vmnic1 and verify whether the UI shows the link as down. If you have VM's, you can also verify that any that were connected to vmnic1 have successfully failed over to vmnic0 - Ensure that your NIC drivers on the server are up to date.

Brash

As @Ryan_Miles said, you're looking under "wireless" which is configuration for standalone AP's. Configuration for the wireless functionality built into the MX device is under Security & SD-WAN/Teleworker Gateway > Configure > Wireless settings https://documentation.meraki.com/MX/Wireless/MX_and_Z-Series_Wireless_Settings

Brash

No, the maximum runnable firmware for MR32's is version 26. If you have newer AP's in the same network and apply the 28 firmware upgrade, the newer AP's will run 28 while the MR32's will remain on 26 https://documentation.meraki.com/General_Administration/Firmware_Upgrades/Product_Firmware_Version_Restrictions#MR

Brash

Basically all RMA's need to be issued by support. If you can't open a case via the portal, you can call up Meraki support via phone. In some exceptional circumstances, your Meraki rep may also be able to assist. https://documentation.meraki.com/General_Administration/Support/Contacting_Support#Online Is there a reason you can't open a case with Meraki support via the dashboard to request troubleshooting and an RMA?

Brash

Meraki client vpn doesn't natively support MFA. You will need to use a 3rd party solution for auth, most if not all of which would be a paid solution in some way. https://documentation.meraki.com/General_Administration/Other_Topics/Two-Factor_Authentication#Using_Two-Factor_Auth_with_Client_VPN If your users have m365 licensees, you could look at RADIUS auth to AD/AAD and using MFA built into AAD.

Brash

It looks like HA is constantly kicking in and failing over the MX VRRP IP. Are you seeing this on the dashboard? What mode are the MX's in and what does the topology look like? Are you seeing any issues with the uplinks?

Brash

As @KarstenI mentioned, SSID's can be enabled and disabled without disruption. You're correct, using tags would allow you to test on a single AP. When you're done testing, turn off per AP availability and all AP's will broadcast the SSID. https://documentation.meraki.com/MR/Other_Topics/Using_Tags_to_Broadcast_SSIDs_from_Specific_APs#Specify_Which_APs_Should_Broadcast_a_Specific_SSID

Brash

How exactly does the casting via url and pin work? What is the communication between house and Chromecast? Typically for Chromecast discovery across subnets you need to enable bonjour forwarding. https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/Bonjour_Forwarding

Brash

Meraki switches run RSTP. https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Configuring_Spanning_Tree_on_Meraki_Switches_(MS)#Configuring_STP_Globally They are interoperable with (but do not run) MST and PVST. The Vlan 1 requirement is if you connect a Meraki switch to a device that does PVST. The connecting device must have a PVST instance on vlan 1 in order for the Meraki switch to receive BPDU's. https://documentation.meraki.com/MS/Deployment_Guides/Advanced_MS_Setup_Guide#PVST.2FPVST.2B

Brash

Meraki SFP's are fully supported with Meraki Go - https://community.meraki.com/t5/Questions-and-Answers/SFPs/m-p/100004#M428 I don't have experience with Meraki Go equipment but it seems like supported SFP's for GS switches align with the MS equivalent. https://community.meraki.com/t5/Questions-and-Answers/GS110-SFP-ports/m-p/138809 From the above thread, It seems that similar to MS switches, only Meraki SFP's are supported but other branded SFP's will work.

Brash

169.x IP address indicates that the PC hasn't received a DHCP response. Do you see a response received on the client Wireshark capture?

Brash

This question appears to be specific to connecting to a remote database rather than questions about Meraki networks. This isn't the right forum to be asking this question. I'm sure the community will be happy to help out if you have any questions related to Meraki networks.

Brash

This was my initial assumption but reading a few non authoritative comments (Meraki community linked above and some Reddit posts), it seems to indicate that any NAT or port forwarding rule will bypass the layer 7 rules. I did a quick and dirty test this morning by geoblocking my own country and testing my VPN (which is a port forward) from my phone. Even with the rule in place, the vpn connected without an issue. I might try to do another test tomorrow.

Brash

Right, that makes sense. 1:1 NAT and port forwarding are not inspected by layer 7 firewall rules. https://community.meraki.com/t5/Security-SD-WAN/MX-GEO-IP-filtering-on-Port-Forward-rules/m-p/60930/highlight/true#M15576

Brash

RADIUS testing polls the RADIUS server once every 24 hours to verify that it's online and serving requests. Disabling it means that you lose the alerting to indicate that the Meraki device cannot reach the RADIUS server. https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Alert_-_Recent_802.1X_Failure#RADIUS_Testing

Brash

I don't think Meraki publicly advertise where they pull the IP address geolocation data from. Are you seeing traffic pass from IP's that other internet tools identify as from a location that you're blocking?

Brash

You can logically group networks with network tags. They're somewhat useful by themselves but are especially person when played with the API https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Organization_Menu/Manage_Tags#Creating_Network_tags

Brash

As @GreenMan said, there's no need to create separate organisations. The dashboard is for management only and any country specific regulatory settings are applied on a per network basis. https://documentation.meraki.com/MR/Radio_Settings/MR_Regulatory_Domains#Regulatory_Domain_Setting_for_a_Network

Brash

Interesting. My tests are quite similar. ISP <-> MX <-> MS <-> AP MX: 51mbps MS: 10mbps AP: 51mbps This network has a 50mbps ISP uplink. Assumedly the switches have some sort of rate limiter applied for dashboard communication? Either way, Meraki make it very clear that the test is not a valid dataplane speed test and so I don't see a limited dashboard throughput being a problem.

Brash

Sounds like you're talking about changing the management IP address is the switch (via the left hand pane). Setting the Ip address statistically and assigning the vlan there is a valid way of configuring it. Once configure on the dashboard it should push to the switch. It's possible that there was a misconfiguration elsewhere that meant when the new IP and the vlan were set, the switch became unreachable from the Meraki cloud portal.

Brash

Community Record

Badges