A clear connection
with Meraki MX.

01 / Before you configure

Gather the details and plan the change.

Confirm the handoff location, media, connector or optic, expected Ethernet speed, port requirements, and whether the provider requires a tagged VLAN. Obtain the addressing method: DHCP, or a static IPv4 address, prefix or subnet mask, gateway, and DNS information supplied for the service. Ask whether any additional addresses are routed separately.

Identify the Internet port and its capacity for the specific MX model. A port can accept a physical connection while the appliance, inspection features, or license and configuration limit the usable throughput. Check the vendor specifications for the deployed model and workload.

If the MX is part of a warm-spare pair, has a second provider, or is managed by a separate IT team, agree on the design and recovery plan first. Do not assume a single-device configuration applies to it.

02 / Physical connection

Check the connection to the handoff.

Connect the agreed handoff to the intended MX Internet port using compatible cabling and supported optics when applicable. Confirm link state and operating speed at the MX and at the adjacent device with the responsible teams. If there is a switch or other device between them, include its interfaces in the check.

Record interface errors and discards at both ends and along the path, along with the time, counter age or last reset if available, and a second reading after a known interval. An increasing counter is useful evidence; an old total alone does not prove a current problem. Preserve the evidence rather than clearing counters during an investigation.

Link up does not prove that addressing, VLAN tagging, routing, DNS, or the application is working. See the Internet handoff guide for physical details to exchange with your provider.

03 / Internet uplink

Choose DHCP or enter the assigned settings.

If the service uses DHCP, select DHCP for the correct Internet uplink and check the address, gateway, and DNS the MX receives. If the service uses static addressing, select Static IP and enter the values supplied for the MX interface. Do not assume that a separately routed block belongs on the uplink itself.

On the Dashboard, Meraki documents the uplink settings under Security & SD-WAN → Monitor → Appliance status → Uplink. Select the edit control for the intended WAN, choose the assigned addressing method, enter the required values, and apply the approved change. The labels may differ for your Dashboard and release.

Do not expose the local management page to the Internet to complete setup. Use authorized internal access. Meraki notes that WAN support for a /31 depends on supported firmware and that a /32 WAN mask is not supported. Confirm the addressing design and the exact model and release before turn-up.

04 / DNS, LAN & security

Make sure the right systems can connect.

The DNS servers configured for the MX uplink support the appliance’s own management and connectivity functions. They are not automatically the DNS servers handed to client devices; client DNS and DHCP are configured separately. This matters when a school or business relies on internal names, content policies, or managed resolvers. Use the approved DNS design rather than replacing it with a public resolver as a general fix.

Confirm the LAN addressing, DHCP scope or relay, and any VLANs with the local network team. A WAN VLAN tag and an internal LAN VLAN are different configuration decisions. Match each to the documented handoff and network design.

Review firewall and traffic policies for the intended flows and, where the design uses private IPv4 addresses, the required translation. A routed public address block, inbound service, site-to-site connection, or IPv6 deployment may have different requirements. Avoid broad allow rules or disabling security controls merely to pass a test.

05 / Verify the service

Work outward from the handoff.

1. 01

   Confirm the uplink

   Review the Internet port’s link state, expected speed, WAN address, gateway, VLAN tagging, and reported uplink status. Compare each against the actual service details.

2. 02

   Check management

   Confirm that the MX can reach the Meraki Dashboard. Dashboard status is useful evidence but does not prove every client application is working.

3. 03

   Test the path

   When the appliance is reachable in Dashboard, use its live Ping, Traceroute, MTR, or DNS tools where supported. Choose an appropriate destination and record the method and time.

4. 04

   Test an actual client

   From an authorized wired client, verify name resolution and representative applications. Repeat from an affected VLAN or location where safe; an MX-originated test and a client test do not necessarily follow identical policies or paths.

ICMP filtering or a nonresponsive intermediate router does not by itself establish an outage or packet loss. See latency, jitter, and packet loss for interpretation and examples.

06 / Troubleshoot

If the connection is not working.

Meraki’s MX Live Tools guide documents Dashboard Ping, Traceroute, MTR, DNS, and uplink observations. Available tools and their exact behavior can vary by firmware.

07 / Capacity

Check performance across the whole path.

Compare measured upload and download rates with the purchased service, the MX model’s published specifications for the enabled features, its interfaces, and the test device’s capabilities. Traffic shaping, VPN encryption, inspection, and the destination can affect results. Do not equate port speed with full-security throughput.

Run a coordinated test with capable wired equipment, when appropriate for the business. Preserve the timestamp and identify the source, destination, direction, and whether a VPN or another provider is involved. Our speed test guide explains test preparation and limitations.

08 / Support

Share what you observed.

Provide the affected service and location, when the issue started, the impact, handoff link state and speed, counter changes, affected clients, the addressing method, and relevant test results. Do not send passwords, private keys, full unreviewed configuration files, or other sensitive school or business information. Use an agreed secure channel if specific sensitive details are needed.

See preparing for an Internet support request. Existing Stealth customers can contact support@stealth.net or +1 212 232 2020.