How to monitor / fix the work of network interfaces on the Trassir server?

Question

System administration

There is a Trassir video server (official, not assembled + license), it has two network interfaces.
On the first interface, one subnet and gateway are specified, on the second interface, only a subnet (without specifying a gateway).
Routing accordingly works through the first interface, there is access to all. But it is necessary to turn off / restart the server, then routing gets lost. The second interface is activated first and makes it the main one, and then the first one is activated, but the server starts to perceive the second interface as the main one and tries to transfer all data through it. Accordingly, the connection is lost. The problem is corrected if I log in locally, open the interfaces, disable them (by unchecking them) and then check the boxes again, but first activate the interface where the gateway is specified, then turn on the second one. After that everything is back to normal.
I thought maybe it's the interface, okay, I swapped the data. specified the gateway on the 2nd interface, and made the first without the gateway (ie made castling). Loaded the server and now it is the first to turn on the 1st interface, the one without a gateway, and the situation repeats exactly the opposite. I can't figure out what is the reason. Updates are the latest.
I thought to monitor the fall of the interface or something else, but it does not work out. The address is pinged normally and there is no way to understand if the routing has changed or not. I find out about the problem when they call me and say: "It does not work."
Who faced a similar feature of servers?
And how can I set up monitoring (I'll never know what to monitor on it)?

Answer 1

This is called a "race" when two devices are initialized at the same time and have a floating response time - it turns out "who is the first one and sneakers."
Do you have access to the console? If on Linux, then in udev (device manager) you can register the correspondence of poppy addresses and interface numbers (if the hardware there has a hardwired poppy address) or solve the problem in another way - they must have a different hardware path. The problem is easily solved at the kernel level - but not at the level of the crooked Trassir interface.
I would have presented Trassir's claims officially, this is their cant.