About ww

ww

Yes, Devices you remove from the network are still in your inventory. If you have a empty network and you dont need it anymore you can remove it.

ww

Yes, put all meraki hardware in the same vlan and add that subnet to the radius. Another option is radius proxy https://documentation.meraki.com/MR/Encryption_and_Authentication/RADIUS_Proxy_for_WPA2-Enterprise_SSIDs

ww

No. Switch / MX need to match the exact model https://documentation.meraki.com/General_Administration/Licensing/Meraki_Co-Termination_Licensing_Overview#MS_Licensing_Options

ww

Was the lic for all devices in your org? At the license page it should show you which devices need a license.

ww

The dc needs routes to your networks. Not sure its the problem here, but that would be the first thing i would check. A default route or all specific routes in your network/vpn networks. Or In case you would run ospf to the dc then autovpn subnets would be advertised. (But this options doesnt work with vlans enabled)

ww

https://documentation.meraki.com/MR/MR_Splash_Page/Custom_Splash_Page_Themes

ww

Could you try with this rule Allow any any port 53

ww

The ubiquiti has a route to the datacenter subnet? And the datacenter has a route for the subnets behind the ubiquiti?

ww

Only thing i can think of is that its related to mac randomization. Ask if the customer have this enabled and if they can try without it https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Meraki_and_MAC_Address_Randomization

ww

You can find dhcp info in the event log. So you could enable syslog and sent the event log (to the nac?)

ww

The cloud/dashboard is the meraki brain /config. But you can use several setups, read this doc regarding the mr AP wifi https://documentation.meraki.com/MR/Client_Addressing_and_Bridging/SSID_Modes_for_Client_IP_Assignment

ww

Icmp is a specific protocol, its not udp or tcp. So if you want to keep using specific rules you should allow the icmp protocol to that ip adresses

ww

You could build/host one yourself https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Configuring_a_Custom-Hosted_Splash_Page_to_Work_with_the_Meraki_Cloud Or use a external provider, you can find some at https://apps.meraki.io/en-US/listing?cat=106395

ww

https://documentation.meraki.com/MR/Wi-Fi_Basics_and_Best_Practices/Extending_the_LAN_with_a_Wireless_Mesh_Link

ww

https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Alerts_and_Notifications#Wireless_Alerts

ww

If your zoom traffic has already dscp tag from the application/client. why would you enforce it again?

ww

https://documentation.meraki.com/MX/NAT_and_Port_Forwarding/Port_Forwarding_and_NAT_Rules_on_the_MX#Port_Forwarding

ww

Look at the top left. That are ipv6 inbound rules. I think ipv4 inbound rules only work on request at meraki support. With ipv4 nat mode you can allow ipv4 traffic in using port forwarding/nat rules

ww

https://documentation.meraki.com/Go/How_To_Guides/Security_Settings_for_Meraki_Go_GX_Series#Claiming_your_Security_Subscription

ww

Meraki Support can disable hub to hub communication.

ww

Just put the url you want to forward them here https://documentation.meraki.com/General_Administration/Cross-Platform_Content/Customizing_the_Splash_Page#Splash_Behavior_-_Frequency_and_URL_Redirect

ww

On the MG local status page you can set pin. I dont see that option for mxC

ww

No. wan links always need reachability to meraki cloud. You could connect the link on the lan side and use static routes (+ tracking) Something like this https://documentation.meraki.com/MX/Networks_and_Routing/Integrating_an_MPLS_Connection_on_the_MX_LAN

ww

If you could place another device at the hub site that build the tunnel to the non meraki fw. And then point static routes from the hub to that device it would work

ww

No, all spokes also need a tunnel to the non meraki fw

ww

Community Record

Badges