Starlink DHCP Route Injection dropping if DHCP expires briefly

[M.Vietorisz]

This is a remote location with a Starlink connected directly into a Palo Alto 510. We have another backup satellite connection provider which should be used for emergency / comms only when Starlink goes offline.

Starlink renews its DHCP lease every 5 minutes. Normally, this works fine, and gets renewed successfully without interruption.

Once in a while, the lease expires seconds before Palo Alto renews it. When this happens, the backup satellite connection kicks in and takes over (with metric 100).

Moments later, Starlink gets its lease renewed, but it does not take over routing of traffic again, even though it has a metric of 10.

Both connections are in the same virtual router, dedicated interfaces, same DHCP client settings, with Starlink metric 10, other provider metric 100. Both are set to 'Automatically create default route pointing to default gateway provided by server'.

Getting someone to physically reboot the Palo Alto at the site when this occurs is the only recourse to get it back up with proper routing.

I simply dont get why Palo wouldn't properly inject and use the lower metric route when the DHCP gets renewed. What am I missing here?

[JayGolf]

Hi @M.Vietorisz ,

One thing I’d like to understand more closely is the DHCP lease expiration itself. Since the firewall is acting as the DHCP client, PAN-OS should normally attempt to renew the lease before it reaches expiration at least a couple of times. That is standard behavior. 

When the issue occurs, do the system logs show that the PA-510 is attempting DHCP renewal but not receiving a response from Starlink, or does it appear that the firewall is not initiating the renewal at all?

The next time this happens, could you capture the DHCP-related system logs around the expiration event before rebooting? I’m particularly interested in whether there are renewal retries, NAKs, or messages indicating that the request retries were exhausted. You can try something like ( subtype eq 'dhcp' ). 

That will help determine whether we’re looking at Starlink not responding to DHCP renewal requests versus the firewall DHCP client not attempting the renewal as expected.

[M.Vietorisz]

Hi JayGolf here are the system logs from one of the occurrences. 

22:03:39 dhcp client IP assigned (renewed successfully)

22:06:11 dhcp client IP assigned (renewed successfully)

22:11:11 dhcp lease expires causing backup emergency link/route to take-over

22:11:14 dhcp lease renews 3 seconds later, but the route does NOT take over in the routing table leaving all traffic on the back-up emergency connection (which we block almost everything since it's very low bandwidth/costly)

So two issues really; #1 why did DHCP not renew before expiry? and #2 why, after it does get renewed seconds later, does the automatic route injection not take-over from the backup link, until we physically reboot it?