Skip to main content
Cisco Meraki Documentation

Meraki and Starlink Deployment Guide

  1. Last updated
  2. Save as PDF

By: Anthony Belcastro 

Overview

Satellite technologies have had resurgence with the introduction of Low Earth Orbit (LEO) technologies such as Starlink. Geostationary Earth Orbit (GEO) services had several challenges including latency (250-500ms) and loss due to the nature of the technology. Compounded with the low shared bandwidth meant they were generally only as a last resort. LEO satellites such as SpaceX’s Starlink improve on several of these traditional limitations which has led to rapid adoption as there is now a means to provide data services in remote and underserved areas. The Starlink WiFi router provides connectivity but little security outside of NAT, the MX can supplement the connection to ensure the network is secured by the Meraki enterprise-grade security suite while also optimizing bandwidth available at the site via SD-Internet controls. 

Setup 

Prerequisites

  1. Active Starlink Connection
  2. Starlink Kit
  3. Starlink Ethernet Adapter
  4. MX

Physical Topology 

This topology applies to the second generation Starlink WiFi Router.

Initial Starlink Setup

  1. Position Starlink Kit as per vendor recommendations.
  2. Bring Starlink Modem online and ensure it is upgraded to the latest firmware.
  3. Enable Bridge Mode on the Starlink Wi-Fi Router.
    1. Open the Starlink App 
    2. Select Settings then Advanced
    3. Enable Bypass Starlink WiFi Router
    4. Press Save
  4. Plug the ethernet port into the MX WAN port.
  5. MX will get an IP address via Starlink DHCP. If this is the only uplink the MX will undergo its check in procedure,  when the MX has fully checked into the Cisco Meraki dashboard, the LED will turn solid white. If it is the first time connecting to the cloud, the MX may need to download the latest firmware image from the cloud. While upgrading, the power LED will flash white. 

For more details on Meraki setup, please follow the MX Installation Guide for your model.

Verification

  1. Navigate to Security & SD-WAN > Monitor > Appliance status
  2. The uplink connected to Starlink should now show Active as by now it has passed the health checks and is ready to be used.
  3. You can verify the IP address that the MX is using by navigating to the Uplink tab. If the Starlink router was put into bridge mode, you will receive a public IP address on the MX

Troubleshooting

When leveraging a technology like this, it is important to try and isolate the issue to one of the following four areas:

  • Initial Check In
  • Host and network edge
  • Satellite hop to ISP Point of Presence (POP) 
  • PoP onwards

If the device is not appearing online and checking into dashboard please follow these steps

  • Ensure the device is claimed and added to a network.
  • Confirm the light status, it should be solid white. 
    • If the device is showing a flashing white LED, it means the device has a connection to the cloud and is performing a firmware update. Give the device a few minutes and you should see it check in.
    • If the device is showing an amber or cycling rainbow LED colours, there is an error connecting to the cloud. If this is the case, use the local status page to verify the MX has an IP address. If the MX does not get an IP address, try and restart the upstream modem or confirm with your PC that it is able to get an IP address. 
  • Additional troubleshooting steps can be found here Dashboard Alerts - Connectivity Issues - Cisco Meraki Documentation

When looking at the lan to the edge of the network, troubleshoot as you would a normal issue. This may involve taking packet captures at the host level to ensure traffic is bidirectional between the host and its server, from there it may be a matter of following along on a hop-by-hop basis to make sure it egresses the MXs WAN interface.

Satellite hop to ISP Point of Presence (POP) 

At this point your visibility becomes less as the MX has passed it on to its next hop and it will traverse the first Starlink hop. At this point there might be physical issues impacting the data flow such as obstructions, weather or satellite coverage. Latency is added in this hop which may negatively impact performance and throughput. It may be more difficult to get visibility into network performance at this stage, especially if your destination is in the cloud. Like many other DIA services, your connection will be contended, in this case there is contention both at the satellite level and at the PoP. If your connection is provided via a Starlink reseller, they will provide a console that has data to troubleshoot this hop.

PoP onwards

This is where you would resume troubleshooting resumes as normal, tools like the Meraki Thousand Eyes integration can be used to further provide visibility at this stage. 

Optimization Best Practices

SD-WAN

When using Auto-VPN to connect from a Starlink spoke into a hub there are two recommendations to assist with overlay convergence: 

  1. Configure the hub the spoke is connecting to with Manual NAT traversal, this assists with the tunnel formation when there is CG-NAT (Carrier Grade Network Address Translation) in the traversal path. Additional information can be found in the Meraki SD-WAN KB. 
  2. If the Hub MX is behind a strict firewall, you may need to allow a wider UDP port range inbound as CG-NAT may rewrite the source ports outside of the expected port range of 32768-61000. 

Uplink Preference and Traffic Shaping

It is recommended to set the Uplink configuration to match your service speed, this can be set under Security & SD-WAN > SD-WAN & traffic shaping

By setting the upload speed, it will ensure that egress traffic is shaped to match the service speed, this will assist in maximizing the available bandwidth. Primary uplink and load balancing can also be configured below, for more information please see Configure a Primary WAN interface and Enhanced WAN failover and failback & Configure traffic shaping and QoS.

Custom Performance Classes

Due to the nature of the technology, it is recommend to engineer your traffic so it is optimized to use the bandwidth effectively, by creating a custom performance class you are able to determine if the Starlink connection should be leveraged as either a primary or secondary connection provided it is meeting a defined service level. 

Starlink's guidance at the time of writing is that latency ranges between 25 and 60 ms on land, and 100+ ms in certain remote locations. To determine the correct values for the performance class latency, you can use the historical data live tool to see latency to a monitored destination. Alternatively, you can use the Starlink Availability Map to determine what the connection quality is expected to be at your geographic location. Once the latency value has been selected, input your acceptable loss rate and then apply the performance class to the desired applications and traffic types. 

Please see the SD-WAN Internet Policies (SD-Internet) KB article for a full breakdown of configuration options.

IPv6 

Depending on your connection type, you may be subject to CG-NAT. This may be a point of contention for the service while also limiting availability of services such as VPN. Leveraging IPv6 for connectivity will bypass CG-NAT and allow devices to have end to end communication. 

Additional Considerations

  • For security reasons, the MX doesn’t support DHCP Option 121 Classless Static Route Option. As a result, statistical data will not be sent to the Starlink router and subsequently the app. We recommend leveraging your Meraki dashboard or service providers for visibility into service health.

IPv4 Specific Considerations

  • Due to CG NAT imposed upstream, you will not be able to forward inbound connections such as 1:1 NAT, Port Forwarding and Client VPN
  • Outbound connections such as IPSec and AutoVPN may appear to be less stable than on traditional connections, this may be caused by latency, loss and CG-NAT. 
  • As AutoVPN is an outbound connection, due to this there should be a return path for the overlay to form on. However, if the CG-NAT is aggressive the tunnel may drop. The Meraki MX will automatically attempt to establish new connections if an asynchronous connection is detected.