About Brash

Brash

As per the license overview doc: Licenses in the Co-Termination model start consuming time from the date purchased, not the date they are added to an organization. Waiting to activate a license in the dashboard does not delay its activation date. There is no time benefit gained from delaying an activation. https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview

Brash

There is no way to dynamically adjust bandwidth limits. SpeedBurst being enabled will allow for some bursting over the limit but not for sustained amounts of time. You could get creative with attempts to allow users greater bandwidth. For example, you could place VIP users on a different policy with greater bandwidth allowances. Or you could place a bandwidth limit on the SSID (Eg. 200Mbps), and a looser bandwidth limit on users (Eg. 30Mbps). This could get somewhat messy though if not tuned as you're purposely introducing contention.

Brash

The API should also output the OS fingerprinting information for each client. If the issue is that there are a number of devices that do not have valid OS fingerprinting and you'd like to redirect the DHCP fingerprint information to the NAC, I don't think there's a way you can do this. As you mentioned, running DHCP relay on the Meraki device and running DHCP service on the NAC would be the only method to allow the NAC to perform the fingerprinting.

Brash

I'm not sure about the specifics of DHCP event logging. If you're just trying to capture IP to MAC bindings, one way you could do it (albeit not super elegant) is to use the API to periodically pull the clients in the network/organisation and extract the associated IP and MAC addresses. This will give you a list of the IP and MAC bindings, however it won't be limited to DHCP clients

Brash

Love the idea and the shirts look great. Thanks for the opportunity to provide feedback. 🙂

Brash

Just to round out this thread, only Meraki MX devices have been listed as impacted in Cisco's PSIRT. The fixed release for the MX is 16.16 Multiple Cisco Products Snort Modbus Denial of Service Vulnerability

Brash

If you're seeing the packets reach the WAN port, sounds like the ISP side is fine. Does the MX have a route to the 10.12.12.252 network?

Brash

The image you provided is for creating a routed vlan interface (or SVI) on a Meraki Switch. MS120's are layer 2 switches only. They do not support the creation of virtual interfaces. For your design, you would need to trunk both VLAN 100 and VLAN 300 up to the MX65W and have the VLAN interfaces created on there. The configuration for the VLAN interfaces is configured under "Security & SD-WAN" -> "Addresses and VLANs". Once they're created, you then need to ensure that the ports connecting between the MX and the MS are trunking the VLANs and you should be good. Be aware though that if you're trying to push a lot of traffic between the two VLAN's, the MX may struggle from a performance perspective. If you find that this is the case, you may want to swap the MS120 for an MS2xx which supports the VLAN interfaces to be present on the switch, and will offload the inter-vlan routing from the MX down to the MS. You would then configure a point-to-point link between the MS and the MX for internet traffic as you originally had.

Brash

Clients connecting to the AP can be authenticated by RADIUS, but the AP's themselves are authenticated to the organisation and configured when connecting to the Meraki cloud. That said, if you're looking to authenticate Meraki devices on the network, you can look at enabling Secure Connect. SecureConnect - Cisco Meraki

Brash

You absolutely can configure before connecting hardware or having the SN# https://documentation.meraki.com/General_Administration/Organizations_and_Networks/Pre-configuring_Dashboard_networks_before_receiving_order_or_serial_numbers

Brash

I'm not aware of any easy way to do this. With port 5938 blocked, it will fallback to port 443 or 80. You can try to block all of the Ip addresses of the TeamViewer cloud brokers but there's no guarantee they won't just change at some point. I think you're better off changing the password and security code on the computers with TeamViewer installed to block access to the vendor. Otherwise you could restrict computers from installing or running TeamViewer via an MDM solution

Brash

I don't have any experience with what you're asking but just came to say that there is a Spanish section of the forum (forgive my ignorance if the question was not in Spanish but in a different language). https://community.meraki.com/t5/Temas-en-Espa%C3%B1ol/bd-p/espanol One thing I will say is that you may run into some issues with the Z3 regarding data rate (max 100mbps) and potentially with latency trying to push streamed video data over a mobile network from a device that's roaming between towers all day). I'd say you'd really have to do a proper PoC in your area to get a good idea whether it's feasible or not.

Brash

Similar questions have been asked previously. I suggest checking out the following threads. https://community.meraki.com/t5/Security-SD-WAN/Migrating-rules-from-Sonicwall-TZ215-to-Meraki-MX64/m-p/46855 https://community.meraki.com/t5/Security-SD-WAN/Migration-from-Sonicwall-TZ-400-to-a-Meraki-MX67/m-p/135186 The short answer is that there's no tool or documented method. You essentially just need to copy and paste the values into their appropriate places.

Brash

VLAN segmentation is the most logical way to do this, and probably the simplest in terms of future network management. You typically wouldn't want an L2 domain spanning across multiple buildings anyhow.

Brash

The same document also says the following "Expected behavior. If the MX losses connectivity to the VPN registry, peer information gets purged over time but not immediately. Connectivity to the registry matters when a node changes its contact information after losing connectivity to the VPN registry. Both the hub and spoke will still be able to form the tunnel if the contact information remains the same, and they lost registry connectivity. Peer information will purge after a few hours causing the tunnel to be marked down." It sounds like there is a timeout where the peer info gets purged and connectivity to the VPN registry is required for the tunnel to remain established. That said, I've never seen this occur. For the exact length of time the tunnels remain up for, you'd probably need to ask Meraki support.

Brash

Are these domain joined computers? Do you have VPN configuration settings pushed via group policy or something similar that is overriding your manual configuration?

Brash

Sounds like the previous admin has made bulk overrides to the RF settings for your AP's. Under wireless -> RF settings you can see/change the profile used by your AP's. You. An also override some of these settings by selecting the AP's and clicking "Edit Settings" -> "Bulk edit settings..." My guess is that they've manually overridden channel assignment or power. 90% of the time these settings take care of themselves on auto but in some circumstances these can be manually tuned for better performance. You can clear overrides by re-assigning the profile to the AP. Select the AP -> edit settings -> assign profile, select the profile and on the next page, check the boxes for clear overrides. The review page that follows it will then tell you the changes it's about to make.

Brash

The license is a separate purchasable item to the hardware. You can find the exact PID in the datasheet for the switch or from your Meraki rep.

Brash

Interesting. From Australia and I haven't had an issue here today on n280. That said I haven't logged in many times today.

Brash

I'm using it at one of my sites and It's been perfectly stable for me. It's just a bit of a 'non traditional' deployment type.

Brash

I'm assuming by giving it a kick, @UCcert meant power cycling one AP to test and confirm whether that brings it back online. The AP's should constantly be trying to reach out to the cloud. Do you have any not connected to MS390's? Given they're fairly flakey and are running beta code I would initially be thinking they might be an issue. A couple of other things to check, is the AP"s MGMT IP reachable within your network? Can you do packet captures to verify the AP is sending packets to the Meraki cloud? I can't remember if capturing of the AP"s LAN interface will capture management traffic.

Brash

You can do routed mode with No NAT, but it requires Meraki support to enable it on your dashboard. Once the feature is enabled on the dashboard, NAT bypass can be enabled on a per WAN interface or per vlan basis.

Brash

According to the datasheet, flashing white indicate that a firmware upgrade is in progress. My Status LED is blinking WHITE A blinking WHITE Status LED indicates that the device is in contact with the Dashboard Cloud servers and is performing a firmware update. This can sometimes take 20-45 minutes or more to complete depending on hardware and other factors. MS225 Overview and Specifications - Cisco Meraki Does the dashboard indicate that you have any currently running firmware upgrades? Did you notice the issue prior to running the firmware upgrade or only afterwards? Which firmware version are you running? You could try rolling back the upgrade and pushing it again to see if the changes it. Managing Firmware Upgrades - Cisco Meraki

Brash · ‎04-18-2022

Sounds like either an ACL issue or a routing issue. Are you able to reach anything else on the camera vlan from your computer? Can the camera ping it's gateway, or reach anything else outside its vlan? Can you provide a basic network topology between the devices? I also suggest checking all of the firewall ACL's on the Meraki side (under Security, Switch and Wireless).

Brash · ‎04-18-2022

It's a recommendation that a maximum of 3 SSID's are used. Enabling more than that can introduce interference and performance issues. https://documentation.meraki.com/MR/WiFi_Basics_and_Best_Practices/Multi-SSID_Deployment_Considerations I believe the hard maximum is 15 SSID's per network.

Brash

Community Record

Badges