Systems reporting wrong IP addresses to Satellite

Latest response

We have a Satellite server which manages a number of multi-homed systems. The two interfaces are on different subnets, one for the application and the other for systems management (Satellite, SSH, SMTP, etc.). We have static routes set up so that communication to Satellite goes through the management interface.

However, when Satellite gets a hardware profile for some of the servers, it will associate one of the other IP addresses. For example, we have a system with a bond0 and bond1. The bond0 is for the application and bond1 is for management. The static route forces traffic to Satellite through bond1 but when I go to the Satellite WebUI and look at the properties of the server, it shows the bond0 IP address.

I have run tcpdump traces to verify that traffic from the server to Satellite is actually going through bond1 like it should (and our firewall rules only allow traffic to Satellite from that interface, anyway).

So, why is Satellite showing the address for bond0 instead of bond1? Any ideas? Is more information required to identify this issue?

Thanks in advance!


Are your systems sending both bond0 and bond1, but the webui showing only bond0? You can run a script like


use Frontier::Client;

my $HOST = '';
my $user = 'admin';
my $pass = 'redhat';

my $client = new Frontier::Client(url => "https://$HOST/rpc/api");#, debug=>1);
my $session = $client->call('auth.login',$user, $pass);

$systems is a array reference

my $systems = $client->call('system.listSystems', $session);

dereference (@) the perl array to loop

for (@{$systems})
print "system id: " . $->{'id'};
my $devices = $client->call('system.getNetworkDevices', $session, $
for (@{$devices})
unless ($->{'ip'} eq "")
print " is using ip address: " . $
->{'ip'} ;
print "\n";

$client->call('auth.logout', $session);

and that will give you output like:


system id: 1000010083 is using ip address:
is using ip address:
system id: 1000010044 is using ip address:
is using ip address:
system id: 1000010043 is using ip address:
is using ip address:
system id: 1000010041 is using ip address:
is using ip address:
is using ip address:
system id: 1000010042 is using ip address:
is using ip address:
is using ip address:
system id: 1000010103 is using ip address:
is using ip address:
is using ip address:

The output from that can be better written, but that's a decent start.

What does

echo "select * from RHNSERVERNETWORK;" | sqlplus spacewalk-cfg-get default_db

give? You can use

echo "select * from RHNSERVERNETWORK where server_id=1000010043;" | sqlplus spacewalk-cfg-get default_db

to get results from just one system.

What do you have in the /etc/hosts file for these systems?


Hi Pete,

Because adding # to the start of a line affects formatting as shown above, when you're entering commands/code snippets it helps to put ~~~ above and below the string

# so that it will look like this

Check out the "Formatting Help" link below for details


It appears to be sending only bond0 information, though it's communicating over bond1. I'll try going through some of the scripts you've offered and see if that narrows things down and leads to a solution. As for the /etc/hosts file, that's part of the issue as I am using Satellite macros to populate the IP address, but I want it to use the bond1 address rather than the bond0 address which, as you might well imagine, is causing some issues.

Thanks so much for your response. I'll try your suggestions as soon as I can and report on the results.

Ok...I ran the perl script after modifying the Satellite server name, login information and putting '#' characters in front of the lines that show up in the above post in BOLD lettering.

The result was:

Fault returned from XML RPC Server, fault code -1: com.redhat.rhn.common.translation.TranslationException: Could not find translator for class java.lang.String to class java.lang.Integer

For the sqlplus select statements, it seems to be a syntax error as I just get the same thing you get when you run 'sqlplus --help'

In my experience so far, this is the behavior I see:
Satellite will use whatever IP address that the client resolves its hostname to, regardless of the IP address that it is communicating from.

For example, if you have a system with the hostname: systema
If this name is defined in the host file like so: systema

...then satellite will use that IP address. You can even change the hosts file so the system name maps to a completely false IP address, and satellite will use that address.

On the other hand, I have also found the following to be true:
If your host system cannot resolve it's hostname to an IP address, then satellite will use the address that communicates to it.

Another example:
I have a system registered to Satellite with a name of mysystem.
I change the hostname to systema, and leave systema our of the hosts file. The next time I run rhn-profile-sync, the system's registered name will stay the same, but the hostname will be updated with systema, and the IP address will be updated with the one that was used to communicate to it.

Hope that makes sense to you.