As I said, there is a myriad of scripts there.
But here is what I have found, looking at 2 scripts that deal with the routing (routeupd and nb_setnexthop).
The whole logic in SZ, as I predicted, assumes the following rules, based on the nb gateways configuration:
a) A gateway is valid if either the INTERFACE or IP (address of nexthop gw) is defined.
b) If the gw IP is defined, then it’s used for the routing
c) If the gw IP is not defined, then the INTERFACE will be used
This is the logic all over. This works fine for Point-to-Point interfaces, like PPPoE (as well as any other P-t-P interaces) but will NEVER work for broadcast interfaces like ETHERNET. Point-to-Point do not require a gw address cause the gateway is always at the other end of the line. But for broadcast interfaces, unless the gw address is known, the route will not work.
It tried hacking these 2 scripts to check for a DHCP supplied default gateway in case the information was not there (that is the nb gateway definition includes the interface and it has DHCP client services enabled).
The code to pick the DHCP default gateway is kinda simple, thanks for the fact that there is a lease file per interface, so just grep for the proper like and “tac” + “head” to get the last entry then awk to extract the ip address. Works fine (I’ve wrote an external script for that).
But there seems to be a lot more involved than these 2 scripts. Still looking, but it’s kinda hard without a good understanding of how all those scripts interact (and there is a lot of interaction there).