the way i have configured some seasonal sites is to simply put starlink in priority 1 slot. when service is active its the primary wan. when its inactive it stays as priority 1 but is disconnected so not utilized as a wan as the lower prioritys stand-in. this also allows me should the need arise to remotely reactive starlink if the other WANs become unavailable and once its reprovisions, i will have it as the primary wan without further intervention. however, now starlink is going to charge for when its paused and keep service active albeit at slower speeds. is there any easy way to keep starlink as the primary WAN when its fully active (not paused) but put it at a lower priority/standby when its paused (but partially active at the slower speeds)? can peplink see the state (paused @ slow speed versus fully active)? is a feature request needed to handle this or just some creative outbound rules or other configuration?
There is (AFAIK) no click-and-play function in the firmware to do so. What you could do, is write some script that changes the interface priority using the Peplink API. You can host that script on a device somewhere in the LAN, or on some Peplink devices also as a Docker container on the device itself.
If you want to hosting that script outside the device or LAN, make sure the health monitoring of the other WANs is really good in order to have them disconnected (and the Starlink in prio 2) connected again once they become “unavailable”. Bad cellular links can stay available/connected even if their quality is that bad that you can’t get any decent communication through again.
Other option is to have all WANs set as primary and play with outbound policies.
Perhaps silly question, what are your inactive seasonal sites consuming internet-wise that 512Kbps wouldn’t work? Unless you’re trying to do video monitoring it would seem that the Starlink plan should work for most maintenance tasks.
Hi,
Do you have outbound policies configured?
You might be able to push outbound policies based on tag. While you need to enable/change the Starlink subscription anyway you can then add a different tag with a different outbound policy configuration in InControl2.
With this you can leave the WAN options on prio 1 and use for example Priority outbound policy to use one WAN option at a time.
More on the different outbound policies here:
Hope this helps. 
main bandwidth use is security cameras but i do visit and do need internet for remaining connected to work during my brief visits. and i thought they said 256kbps.
so the tag can see the starlink subscription status?
Not automatically, no, but as you change the subscription yourself, it’s pretty straigtforward to just enable/apply the outbound policies that you pre-configured under this tag. Only a few extra clicks without hard thinking work.
Other option would be to use the API to apply these rules by a script that also checks subscription status…
This is probably a feature request:
With Starlink changing their «pause» to active standby (and claiming it an upgrade to pay for!) it would beneficial if Peplink’s Starlink integration allowed us to test for the status of the Starlink connection w.r.t. what is considered connected (or as part of outbound policies).
Cheers,
Z
“Standby Mode, where available, offers speeds up to 500 Kbps download and upload.”
https://www.starlink.com/na/support/article/37bb3b47-9525-7224-5f0a-6d016ce26975
Would indeed be very interesting, although I wonder whether this information can be retrieved from the dish API or whether Peplink needs to have access to your account on Starlink and use the Starlink API to retrieve this information.
In the absence of direct access from the router to the status information of the subscription at the dish, is there sufficient correlation with latency or response time that one could use one of those outbound rules as proxy? A kluge, I know.
You could do a “speedtest” from time to time, but depending on the frequency of those tests you might consume quite some overhead data… Latency won’t make a significant difference on those small PING packets, neither response time as that are also small packets. Major difference is bandwidth, which requires some data to see the impact when the pipe gets filled up.
I agree some work around this new style of “plan” is needed to use efficiently.
For lots of people this is a useful feature, especially for low-bandwidth stuff.
There are still a few things that needs to be known before a solution can be implemented:
- If we can get status via API, then it is easy to add a feature on a WAN and perhaps some pre-specified outbound policies. Similar to how we want to handle Iridium and other low-bandwidth sources @JoeyJanssen
- If we implement further Health Checks on WAN that include some sort of speed test (like other companies has, Celerway etc…) then we can measure based on this metric as well, latency, download speeds etc…
Alternatively, we ask for a special feature called “Low Bandwidht WAN” that we can turn on ANY WAN interface to treat it a special way. Again, this would be very useful for other styles of WAN interfaces such as Iridium. @Eddy_Yeung, thoughts on this one?
Unfortunately manual testing does not scale.
Cheers,
Z
We do have part of that solution in place already: Scheduled speed tests in IC2. If one could hook policy actions to the results of those then that would be sufficient for our use cases (we don’t need the testing to be performed frequently - once every 24 hours should suffice)).
E.g., deprioritize a connection if the speed test fails (where failure is defined by the scheduled test set-up).
Having to mess with an API would be undesirable - our shop is not set up to handle that.
Cheers,
Z
WAN Management is coming to IC2 - but this is a fair bit of management, and involves IC2, no local control.
Would be nice to see something local too for this use case.
In that respect: how do you handle Iridium now? I just stay far way from it FTM. Way to expensive for most use cases for me, only for some small direct applications like a relay board or a dedicated telemetry application or something like that.
Honestly - we don’t. Because there’s no way to manage a connection like this.
In some rare cases we use Iridium or FB which are unlimited at slow speeds, but totally useless through Peplink. We use products like PredictWind DataHub or the WiFi off the device and use their own tools to manage internet access.
We should have features to manage ultra-low-bandwidth devices such as Iridum and this new Starlink plan.
Maybe the partnership with Iridium will bring those kinds of integrations…