We’ve been experimenting with the networking configuration for our EOS hosts, for our a CTA instance. One option that was preferred (from a site networking perspective) was to have the EOS hosts primary addresses as private addresses, and add externally accessible addresses to the hosts that need external access (e.g. the EOS nodes). This has a number of advantages for security and network design, but I have concerns about how EOS is going to cope with this setup.
In basic testing, we ran into the somewhat expected redirection issues with external clients being redirected to FST’s primary addresses, but also other odd issues (e.g. external ‘eos ls’ command work fine, but ‘xrdfs ls’ commands stall as the client gets redirected to the MGM’s private address).
We experimented with defining the split network topology in the various EOS XRootD config files, which didn’t seem to make a difference, FSTs and MGMs still appear in EOS as their ‘private’ hostnames, and redirections to the private addresses still occur.
Does anyone run EOS with this sort of network configuration, or are there good reasons why this isn’t going to work (e.g. it isn’t designed to work like this) and we should simplify our network configuration?