IPMI not dependable with and LACP (LAG)

[cronsloth]

I'm not entirely sure if this is a known issue or just me not knowing all the underpinnings of how IPMI functions. But Here is my issue if anyone has any insight.


I have a SuperMicro Server w/IPMI:
Product Name: X9DRL-3F/iF

I also have 'LAGG' configured to port bond my two NIC's on the server. So IPMI is sharing the same NIC(s) with the LAGG.
Everything was working fine until I needed to reboot our server. Since the reboot, IPMI isn't pingable, or available via HTTP or HTTPS. However, within the FreeNAS terminal, IPMITool shows it is setup and running properly.

I'm wondering if, due to the LAGG setup or the way IPMI chooses a NIC it may have gotten confused or something and disallowed access to itself.

I attached some output but I can do other commands if someone has a suggestion.
If it helps, nMAP scan results in showing HTTP and HTTPS as 'filtered'....yes, nmap returns a result when PING doesn't....sounds software based to me in that it is blocking connections but I could be wrong, and don't know how to change it using 'IPMITOOL' or 'IPMICFG'

Thanks in advance....
(ps I changed the values of my MAC address, IP, etc. but they are correctly setup in real life)

Code:

[root@freenas ~]# ipmitool chassis status
System Power		 : on
Power Overload	   : false
Power Interlock	  : inactive
Main Power Fault	 : false
Power Control Fault  : false
Power Restore Policy : always-off
Last Power Event	 :
Chassis Intrusion	: inactive
Front-Panel Lockout  : inactive
Drive Fault		  : false
Cooling/Fan Fault	: false
[root@freenas ~]# ipmitool lan print 1
Set in Progress		 : Set Complete
Auth Type Support	   : NONE MD2 MD5 PASSWORD
Auth Type Enable		: Callback : MD2 MD5
						: User	 : MD2 MD5
						: Operator : MD2 MD5
						: Admin	: MD2 MD5
						: OEM	  : MD2 MD5 PASSWORD
IP Address Source	   : Static Address
IP Address			  : 10.10.0.101
Subnet Mask			 : 255.255.255.0
MAC Address			 : 00:25:90:ff:ff:ff
SNMP Community String   : public
IP Header			   : TTL=0x00 Flags=0x00 Precedence=0x00 TOS=0x00
BMC ARP Control		 : ARP Responses Enabled, Gratuitous ARP Disabled
Default Gateway IP	  : 10.10.0.1
Default Gateway MAC	 : 00:00:00:00:00:00
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	 : 1,2,3,6,7,8,11,12
Cipher Suite Priv Max   : aaaaXXaaaXXaaXX
						:	 X=Cipher Suite Unused
						:	 c=CALLBACK
						:	 u=USER
						:	 o=OPERATOR
						:	 a=ADMIN
						:	 O=OEM
Bad Password Threshold  : Not Available

 

[cyberjock]

This is fairly common behavior from what I've seen. In particular, is that if you use the "shared" network ports for IPMI, but the shared port is in a lagg, than all sorts of fun stuff happens.

My advice would be to switch to the dedicated IPMI port and use that. It also has the advantage of letting you power on/off the server remotely, whereas the shared will let you power the server off, but you cannot power it back on because the shared NIC won't have power.

To change this behavior, you'll have to consult your motherboard manual. Often plugging in the network cable and power cycling the IPMI (by resetting it with ipmitool or power cycling the entire chassis) will switch it to dedicated mode. For others, there is a BIOS setting.

As a general rule, I never recommend the "shared" network options on IPMI because it can quickly become quirky, and inevitably it gets quirky when you *really* need IPMI. :P

 

[cronsloth]

Thanks for the reply, That was my same thinking, and it is definitely the most sane approach to avoid a later headache ;)