DTC Manager - Network Address

[Daniel L Grahek]

I am running dtcmgr on an L2000 11.00 OS, and use it to remote boot several DTC 16RX's Currently the manager resides on two different networks, one of which will be going away in the near future. Currently the dtc's are configured to boot from the managers address on the network that will be going away. We have tried changing the address in the DTC's to look at the managers address on the network that is not going away, but the DTC's fail to download. Any suggestions? I have a couple of theories, but am hoping for some confirmation of my ideas before changing something in a production environment.

[harry d brown jr]

Is it possibly a network routing issue?

live free or die
harry

[Daniel L Grahek]

The DTC itself isn't changing its ip address. So the dtc manager should be able to still reach the dtc. The change that is being made, is telling the dtc that its dtc manager is located at an ip address that is on its same network. It seems that would reduce the possibility of routing problems.

[Rodney Hills]

DTC's do not use IP addresses when being downloaded.

When a DTC is booted, the daemon RBOOTD listens and supplies the necessary download data. Examine the file /etc/rc.config.d/netdaemons, you will find the line-
export RBOOTD_DEVICES=/dev/lan1

Change /dev/lan1 to the lan device that is to respond to DTC boots.

-- Rod Hills

[Daniel L Grahek]

Nice try Rodney, and a valid point, However by default with START_RBOOTD=1, when no device is specified, rbootd will use the device corresponding to the ethernet address of the machine. If this is the case, then why does the DTC even have a specification for DTC_Manager. The network that the DTC is located on is the network that I am trying to change the DTC Manager over to. The problem with the DTC is not a problem with rboot, rather a problem with the dtcmgr's ability to manager when accessed via the newer network. I have not found any evidence within dtcmgr that there is a means to specify which network it managers from. This has lead me to believe that the dtcmgr is only able to download to a DTC via the network that the HP9000 is using as its default gateway. Any thoughts?

-Daniel

[Rodney Hills]

I believe DTCMANAGER just sets up some configuration files. The DTCs (which should be powercycled to establish a new connection) broadcast a request for any host to supply their configuration (they have no IP or MAC address of the host). rbootd which is listening to the network specified, responds with the necessary data for the DTC to boot and configure itself.

I have a K360 running HPUX10.20 and /dev/lan0 could not be used because it was a 100Mbps network. I used /dev/lan1, which was 10Mbps, and configured rbootd to respond to that device.

If you have not specified a lan device in the netdaemons file, and you are sure that it defaults to the one you want, then I can't see why it shouldn't be working.

-- Rod Hills

[Daniel L Grahek]

The answer, ended up being as harry questioned, a routing issue. The DTC 16RX, being routable and on a different subnet, did require the ip address of the dtc manager specified, as well as its own gateway, etc. The default gateway on the dtcmgr was set to the address of the network which will be going away. By adding a static route to the dtcmgr system, to route data back down the new network when requests came in on that network, we were able to get the dtc to properly download. We then took advantage of the backup dtcmgr setting on the dtc to set the backup as the network that will be going away. We cannot add the new route until all of the dtc's are configured, as they would stop working if we added the route and they still wanted to be served down the old network. Currently until all of the DTC's are reconfigured, at which time we will add the static route, they try the new network, which times out, then the old network which they can successfuuly download on. When the are all configured, we will add the new route, or better change the gateway on the dtcmgr, and the will all be able to download on first try without a time out. Thanks for all of your input.