OK, I had to respond to that misconception wrt e1000 & BMCs. :-)
The real reason that a separate MAC (sometimes a separate NIC) was
provided for BMC traffic on some new Intel motherboards was that there
are more features being put onto the management NIC than just port 623
can handle (HTTP, SMTP, KVM, TELNET, etc.), so sharing the MAC was not
feasible for those additional features.
Do note that some newer NIC chips do require e1000 driver updates, as is
normal when new devices are introduced.
Andy
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Thomas Adam Nabarro
Sent: Thursday, January 25, 2007 5:17 PM
To: ipmitool-devel@lists.sourceforge.net
Subject: RE: Re: [Ipmitool-devel] Lead developer still busy, extra
project
In response to David:
I'm not sure if this will offer any help but the new intel bmc's have
dedicated MAC's for ipmi traffic and seperate MAC's for OS. Therefore it
might be that the e1000 driver is not providing a multiplexor type
operation correctly for discriminating between OS and IPMI traffic.
Intel provided a dedicated MAC for the BMC for the reason that IPMI
communication was not always reliable if MAC was shared, and problems
were encountered such as you are seeing + bandwidth issues.
I hope this helps, but as supermicro tools: ipmiview and ipmicli work
reliably, i am unsure if the issues you are experiencing are related to
the information i have given you. It may be that these tools provide
different authentication steps to ipmitool, which enable them to work
more reliably with the e1000 driver.
If you give more detail (-vvvv), the data may give more insight.
Thanks
Tom Nabarro
------------------------------
>Message: 4
>Date: Thu, 25 Jan 2007 10:08:07 -0800
>From: "David A. Ranch" <[EMAIL PROTECTED]>
>Subject: Re: [Ipmitool-devel] Lead developer still busy, extra project
> admin appointed
>To: ipmitool-devel@lists.sourceforge.net
>Message-ID: <[EMAIL PROTECTED]>
>Content-Type: text/plain; charset=ISO-8859-2; format=flowed
>
>
>I'm seeing a issue here with both 1.8.8 and this
>ipmitool/ipmitool-1.8.8.90 build (on CENTOS 4.4). When communicating
to
>a SuperMicro BMC connected via Intel MACs (which share the same
Ethernet
>MAC and IP address with the OS itself), the IPMI communications are not
>reliable. 70% of the time things work, 30% the time, it seems the
>communication is reported to be garbled. This is using the
non-standard
>Centos 3.3 Intel e1000 driver version 7.3.20 as the stock version
>doesn't work at all (all communications fail with that e1000 driver).
>
>What's strange to me is that:
>
>1. If the machine (Supermicro H8QC8 (4x Opteron 244) is not running
>Linux (say it's in DOS, waiting the BIOS configuration area, etc.),
>ipmitool works fine. It's only when Linux is loaded do these issues
>appear. But..
>
>2. If I use Supermicro's "ipmiview" or "ipmicli" tool for Windows or
>Linux, everything works fine regardless of the loaded OS on the
machine:
>ftp://ftp.supermicro.com/CDR-0010_2.03_for_IPMI_Server_Managment/Rev2.1
0_Beta/IPMI_Solution/
>
>Thoughts?
>
>
>Ps. I've notice that wireshark v. IPMI decodes are rather incomplete.
>Does anyone have a recommended way to work with that community to get
>this tightened up?
>
>
>--David
>
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Ipmitool-devel mailing list
Ipmitool-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
