David,
Thanks I thought I stated #1 clearly the first time, but as usual with
e-mail it can be interrupted differently from person to person
sometimes.
here is some FYI info for Dell units:
Dell does a in parallel kind of thing It is two nic's tied to one
physical port (Series 9 have it split across both nic's now somehow).
But for series 8 and 9 servers the BMC is the last Mac address in the
series. So for eth0 it would be aa:bb:cc:dd:ee:ff, eth1 would be eth0
mac+1, and BMC is eth0 mac+2. They are distinct interfaces and need to
be assigned different IP's and in fact can be different vlans and
subnets.
You are correct a local machine can't talk to it's Lan version of
itself.
#4 agree totally, that is the one way to screw things up royally.
________________________________
From: David A. Ranch [mailto:[EMAIL PROTECTED]
Sent: Monday, December 03, 2007 12:49 PM
To: Federico Tomassini
Cc: Fred Skrotzki; ipmitool-devel@lists.sourceforge.net
Subject: Re: [Ipmitool-devel] lan problems on hp
There are three key things to consider when using the IPMI "lan"
interface:
1. Usually, you need to use an external machine to poll the desired IPMI
device. The same machine with the IPMI interface usually cannot poll
itself via the LAN interface
2. If the IPMI BMC is on a card that has a Ethernet port on it, you
*must* use that Ethernet port for IPMI traffic. Sometimes this Ethernet
port can also be used by the host but not always. Is the BMC shares an
on-motherboard Ethernet port, you *must* use eth0 on the motherboard for
IPMI communications. the lowest MAC address is usually the one IPMI
uses.
3. Many IPMI implementations that share an Ethernet port with the system
itself reuse the same MAC. They work by trapping the IPMI packets from
going to the host interface and send it to the BMC instead. These IPMI
configurations usually don't support the ability to ping the IPMI
address. I've found on some implementations, this IPMI packet trapping
is not very reliable and can require packet filters on the host's
interface to ignore any leaked IPMI packets going to the host interface.
4. Don't mess around with manually setting ARPs, etc. Just make sure
you set up the IPMI interface via the "kcs" local interface with the IP,
netmask, default gateway, and sometimes, you have you hard-code the DGW
MAC.
--
IPMI commands: lan print 1
Set in Progress : Set Complete
Auth Type Support : NONE MD2 MD5 PASSWORD
Auth Type Enable : Callback : MD2 MD5 PASSWORD
: User : MD2 MD5 PASSWORD
: Operator : MD2 MD5 PASSWORD
: Admin : MD2 MD5 PASSWORD
: OEM : MD2 MD5 PASSWORD
IP Address Source : Static Address
IP Address : 10.159.4.230
Subnet Mask : 255.255.248.0
MAC Address : 00:30:48:8c:ca:59
SNMP Community String : lab
IP Header : TTL=0x40 Flags=0x40 Precedence=0x00 TOS=0x10
BMC ARP Control : ARP Responses Enabled, Gratuitous ARP Enabled
Gratituous ARP Intrvl : 2.0 seconds
Default Gateway IP : 10.159.4.1
Default Gateway MAC : 00:10:db:ff:20:c0
Backup Gateway IP : 0.0.0.0
Backup Gateway MAC : 00:00:00:00:00:00
802.1q VLAN ID : Disabled
802.1q VLAN Priority : 0
RMCP+ Cipher Suites : 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14
Cipher Suite Priv Max : Xaaaaaaaaaaaaaa
: X=Cipher Suite Unused
: c=CALLBACK
: u=USER
: o=OPERATOR
: a=ADMIN
: O=OEM
--
--David
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fred Skrotzki wrote:
You've not said who's hardware you are using so it is
hard to
determine
if you are doing something right or wrong as some have
quirks that
others do not.
The OS settings and ethernet interface used on the
machine have
nothing
to do with the BMC's settings (and should not if you
think about it).
It should be a totally separate system so that you can
place it in out
of band if needed. In the lan print 2 statement you
provided you can
see that the default gateway IP is not on the same
subnet, it needs to
be. Depending on implementation it is possible it
considers this a
huge
error and will not configure the port properly until it
if fixed. We
have several systems here where if it is not defined
right it just
does
not work.
Also in most systems (not all but 90% ish) you can not
use the
machine's
network interface to get to the same machines BMC
external IP if they
use the same physical port. If they are using different
ports then
yes.
Dell for example uses the first eth port for both the
BMC and OS level
eth. They are stacked on each other and there is not a
small buildin
switch connecting them. So the OS Nic's transmit pair
is directly
connected to the BMC's Transmit pair and wired out so
one can't hear
the
other. You can't go out that interface to come back in,
it just does
not work.
Excuse me Fred, I don't want to be boring, but I'm going to be
crazy :/
After a lot of trials, without luck, I try to explain the
situation, so
that it will be possible, and I hope easy, to give some advice.
The machine where I have a BMC controller has two NICs:
eth0:
ip -> A.B.C.D
MAC -> 00:15:60:ED:DA:CE
eth1:
ip -> 10.0.2.245
MAC -> 00:15:60:ED:DA:CF
the eth1 iface is the NIC that I want to connect to, but I tried
to use
also the eth0 iface.
When I run bmclanconf, the MAC address is always setted to
00:15:60:ed:dd:62.
Now, I tried each possible configuration (on eth0 and eth1).
* I tried to set the lan channel with the same ip of my NICs.
* I tried to set the lan channel with a third ip. In this case,
I tried
also to force the arp table of the client, where I try to run
`ipmitool -I lan...`:
arp -s 10.0.2.13 00:15:60:ed:dd:62 -i eth1
or, when using eth0:
arp -s A.B.C.E 00:15:60:ed:dd:62 -i eth0
Multiple gateway addresses has been tested with each
configuration.
The result is always the same: connection is not established.
Both ipmitool and ipmiping are failing.
The machine is a HP DL 140, and `dmesg` shows:
[ 0.420783] IPMI System Interface driver.
[ 0.420839] ipmi_si: Trying SMBIOS-specified KCS state
machine at
memory address 0xca2, slave address 0x20, irq 0
[ 0.420909] Could not set up I/O space
[ 0.864879] ipmi: Found new BMC (man_id: 0x000f85, prod_id:
0x0000,
dev_id: 0x00)
[ 0.864983] IPMI KCS interface initialized
[ 0.865034] ipmi_si: Found default KCS state machine at I/O
address
0xca2
[ 0.865089] Copyright (C) 2004 MontaVista Software - IPMI
Powerdown
via sys_reboot.
[ 0.886055] IPMI poweroff: Found a chassis style poweroff
function
I'm thinking to buy some hardware switch, with a web interface
to
control my remote machine, but I'm wondering if, failing
ipmitool, also
the hardware switch will fail.
For now, thanks a lot for your helps
br
- --
efphe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHU+yQi7obm7aBjHcRAkCHAJ0Rde7SC9HUM8BEgoJcy123ia8UkACfalz3
crpLLb0GIWN50HBgZtWRvbc=
=o1X7
-----END PGP SIGNATURE-----
------------------------------------------------------------------------
-
SF.Net email is sponsored by: The Future of Linux Business White
Paper
from Novell. From the desktop to the data center, Linux is
going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
-------------------------------------------------------------------------
SF.Net email is sponsored by: The Future of Linux Business White Paper
from Novell. From the desktop to the data center, Linux is going
mainstream. Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
