This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Ryan, > Thanks for the info. Another idea we're tossing around is using the > firewall to allow only the virtual IP address (assigned to the active > server) to go out and request data. The question with this approach, > however, is whether or not we can be certain the LDM will connect to > upstream LDMs using the virtual IP. For example, the network interface > for our _active_ server might look something like this: > > eth0 xxx.xx.xxx.51 > eth0:0 xxx.xx.xxx.50 > > where the eth0:0 is assigned the virtual IP. Meanwhile the network > interface for the _inactive_ server would look like this: > > eth0 xxx.xx.xxx.52 > > The question is, for the active server, is there a way to force LDM to > use the eth0:0 and associated virtual IP for connections? According to our system administrator, Mike Schmidt, the LDM can be forced to use the virtual IP address as the source IP address in outgoing connections via "host routing": /sbin/route add -host <LDM upstream> dev eth0:0 Mike goes on to say the thing I'm not positive about is when the virtual IP swings over to the backup machine (ie eth0:0 and the host route is config'ed), if the LDM will automatically be bound to that interface. I think the answer is yes, but they must be using INADDR_ANY (not binding to a specfic IP in the LDM config). A test would be in order to be sure... Also, there are, potentially, other mechanisms that you could use to throttle bandwidth via iptables(8) -- so that your backup LDM would receive data from the upstream site more slowly than from the primary LDM. This would make the connection from the backup LDM be in ALTERNATE mode (and, hence, low bandwidth) while its connection to the PRIMARY LDM would be in PRIMARY mode. Alternatively, you could configure the firewall to discard outgoing attempts from the backup LDM, which would still have two REQUEST entries: one to the upstream site and one to the primary LDM. This would, unfortunately, result in at least 172800 error-message in the log file of the backup LDM per day. > Thanks, > Ryan Regards, Steve Emmerson Ticket Details =================== Ticket ID: IPH-715301 Department: Support LDM Priority: Normal Status: Closed