Return to Question

The reason why I made this a point-to-point connection separate from the LAN, is that the connection with the PLC needs to work even if there is no LAN (network down or misconfigured). I have very little control over the LAN, and the connection to the PLC needs to be very reliable.

I configured the PLC to use 192.168.60.2 (fixed IP) and added the following lines to /etc/dhcpcd.conf:

Is this the right way to do this, and if so, how do I automate this? Is there a better way, maybe by adding something to dhcpcd.conf?

Some background, as requested in the comments: a PLC is a Programmable Logic Controller, a device commonly used in industrial control applications. It doesn't really matter, the main point is that it is closed source and I have very limited configuration options: I can set it to use DHCP for IP configuration (i.e. as a DHCP client - it doesn't have a server), or assign a fixed IP and netmask.

Here is an attempt to depict the situation with ASCII graphics:

   PLC (fixed IP 192.168.60.2; alternative: DHCP client)
    ^ 
    |
    | 
    v   eth1 (fixed IP 192.168.60.1)
   RPi
    ^   eth0 (DHCP client, using default dhcpcd config)
    |
    | LAN with DHCP server + gateway to internet

I configured the PLC to use 192.168.60.2 (fixed IP) and added the following lines to /etc/dhcpcd.conf:

Is this the right way to do this, and if so, how do I automate this? Is there a better way, maybe by adding something to dhcpcd.conf?

One possible alternative would be to run a DHCP server on eth1 on the RPi, and configure the PLC as a DHCP client. The challenge would then be to make sure that the PLC always gets the same IP address, even if I replace it with a different PLC (different MAC address). Note: there will always be only one PLC; this is a point-to-point connection.

I suspect that messages to 192.168.60.2 are not routed to eth2:

I suspect that messages to 192.168.60.2 are not routed to eth1: