Servers unable to connect to their own DRAC

Matthias Saou thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net
Tue Sep 16 10:24:39 CDT 2008


Matthias Saou wrote :

> Thanks for reporting a working configuration! I'm assuming from this
> that I should be able to get it working too...
> 
> One setting I've always changed for all DRACs is to enable IPMI on the
> DRAC. Maybe this is what's causing problems?
> 
> I really don't think the problem is Linux specific, though, since I
> have the problem even when using the DRAC's dedicated port (which should
> have it be completely independent from the server/OS). The only way it
> could be related is if for some reason the OS thinks it can reach the
> DRAC MAC address through some other way than over the external RJ45
> link it has to it, but that doesn't seem to be the case from what I've
> tested.
> 
> I'll keep digging, but thanks for the feedback!

I think I'm onto something! Looks like the DRAC inherits some part of
the host GNU/Linux network configuration indeed!!!!

Here's a snippet from "racadm racdump" on a simple system (one NIC on
the public network, the other on the private network, the DRAC
configured as shared and reachable on the private network) (edited to
fit email width) :

=======================================================================
 Network Interface Statistics
=======================================================================
Kernel IP routing table
Destination  Gateway        Genmask       Flags MSS Window irtt Iface
192.168.46.0 0.0.0.0        255.255.255.0 U       0 0         0 eth0
127.0.0.0    0.0.0.0        255.0.0.0     U       0 0         0 lo
0.0.0.0      192.168.46.254 0.0.0.0       UG      0 0         0 eth0
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address        State
tcp        0      0 192.168.46.17:22 192.168.46.254:2685 ESTABLISHED

And here's the same from a server which can't reach its own DRAC :

=======================================================================
 Network Interface Statistics
=======================================================================
Kernel IP routing table
Destination  Gateway        Genmask       Flags MSS Window irtt Iface
192.168.46.0 0.0.0.0        255.255.255.0 U       0 0         0 bond0
127.0.0.0    0.0.0.0        255.0.0.0     U       0 0         0 lo
0.0.0.0      192.168.46.254 0.0.0.0       UG      0 0         0 bond0
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address      State
tcp        0      0 192.168.46.2:22 192.168.1.56:37372 ESTABLISHED

As you can see, the DRAC reports "bond0" here. All of the servers I'm
seeing the problem on are either using Xen (which creates bridges
automatically in the host) or have "manually" created bond interfaces.

Why the installed OS's network configuration seems to affect the DRAC's
network interfaces, I have no idea!

Note that all DRAC5s I've been testing this on have all been upgraded
to firmware 1.33.

I'll continue digging. Right now some more things I've noticed are :

 * The DRACs don't answer or don't receive ARP requests from the
   server's OS. It's a "low level" problem, not IP level.
 * When the ping from the DRAC to the server's OS works, the OS's
   MAC address never appears in the "racadm arp" output (normal??).
 * When the ping from the DRAC to the server's OS doesn't work, the
   OS's MAC address shows as <incomplete> in the "racadm arp" output.
 * The bond0 vs. eth0 in the DRAC is NOT related to having the DRAC
   configured as shared vs. dedicated, as I suspected initially : I
   have servers where the DRAC is using the dedicated RJ45 port but
   outputs "bond0" in its routing table. On those, the GNU/Linux
   server has a bond0 configured...

Sorry for the long (and boring) email, I just hope this might help
others at some point. I also hope to find a workaround which would fix
the problem for me...

Matthias

-- 
Clean custom Red Hat Linux rpm packages : http://freshrpms.net/
Fedora release 9 (Sulphur) - Linux kernel 2.6.26.3-29.fc9.x86_64
Load : 0.06 0.13 0.20



More information about the Linux-PowerEdge mailing list