Skip to main content
Start a Conversation

Unsolved

This post is more than 5 years old

staaleh

2 Posts

122915

November 21st, 2014 07:00

iDRAC7 ping and snmp issues

Hi,


We're currenting deploying a number of R620, and have started to integrate the iDRAC snmp features in to the monitoring system. However we're experiencing some oddities we suspect could be bugs:

Packet loss on ping
We regularily see packetloss when the the monitoring system pings the iDRAC. Not much or often, but enough to trigger alarms randomly. We've ruled out the network infrastructure as a source, as we get the same results connecting the iDRAC directly to the monitoring system using high-quality CAT6 cable(s). Also we don't get any packet loss to other equipment running Linux/Windows/embedded RTOS os'es using the same link and switches.  It's seem to be consistent to all iDRAC interfaces and version we're running (including  v 1.57.57).

After some diagnostic I've found a plausible cause; when two simultanous "ping-sessions" are initiated from the same host to a iDRAC interface, one of the sessions stop receiving replies after the first 5-10 packets:

ping 10.100.104.15
PING 10.100.104.15 (10.100.104.15) 56(84) bytes of data.
64 bytes from 10.100.104.15: icmp_seq=1 ttl=64 time=0.295 ms
64 bytes from 10.100.104.15: icmp_seq=2 ttl=64 time=0.341 ms
64 bytes from 10.100.104.15: icmp_seq=3 ttl=64 time=0.291 ms
64 bytes from 10.100.104.15: icmp_seq=4 ttl=64 time=0.342 ms
64 bytes from 10.100.104.15: icmp_seq=5 ttl=64 time=0.332 ms
64 bytes from 10.100.104.15: icmp_seq=6 ttl=64 time=0.352 ms
64 bytes from 10.100.104.15: icmp_seq=7 ttl=64 time=0.349 ms
64 bytes from 10.100.104.15: icmp_seq=8 ttl=64 time=0.341 ms
64 bytes from 10.100.104.15: icmp_seq=9 ttl=64 time=0.362 ms
64 bytes from 10.100.104.15: icmp_seq=10 ttl=64 time=0.344 ms
64 bytes from 10.100.104.15: icmp_seq=11 ttl=64 time=0.335 ms
^C
--- 10.100.104.15 ping statistics ---
11 packets transmitted, 11 received, 0% packet loss, time 9998ms
rtt min/avg/max/mdev = 0.291/0.334/0.362/0.032 ms

which is the ok one, but on the second session:

ping 10.100.104.15
PING 10.100.104.15 (10.100.104.15) 56(84) bytes of data.
64 bytes from 10.100.104.15: icmp_seq=1 ttl=64 time=0.395 ms
64 bytes from 10.100.104.15: icmp_seq=2 ttl=64 time=0.302 ms
64 bytes from 10.100.104.15: icmp_seq=3 ttl=64 time=0.312 ms
64 bytes from 10.100.104.15: icmp_seq=4 ttl=64 time=0.355 ms
64 bytes from 10.100.104.15: icmp_seq=5 ttl=64 time=0.318 ms
64 bytes from 10.100.104.15: icmp_seq=6 ttl=64 time=0.425 ms
64 bytes from 10.100.104.15: icmp_seq=7 ttl=64 time=0.297 ms
64 bytes from 10.100.104.15: icmp_seq=15 ttl=64 time=0.265 ms
64 bytes from 10.100.104.15: icmp_seq=16 ttl=64 time=0.264 ms
64 bytes from 10.100.104.15: icmp_seq=17 ttl=64 time=0.264 ms
^C
--- 10.100.104.15 ping statistics ---
17 packets transmitted, 10 received, 41% packet loss, time 15996ms
rtt min/avg/max/mdev = 0.264/0.319/0.425/0.057 ms

When stopping the "ok" ping session, the second "stalled" session recovers. For reference the TCPDump of the session:

15:25:33.574152 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 1, length 64
15:25:33.574531 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14532, seq 1, length 64
15:25:34.573153 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 2, length 64
15:25:34.573438 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14532, seq 2, length 64
15:25:35.572154 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 3, length 64
15:25:35.572449 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14532, seq 3, length 64
15:25:35.588938 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14533, seq 1, length 64
15:25:35.589219 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14533, seq 1, length 64
15:25:36.573325 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 4, length 64
15:25:36.573662 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14532, seq 4, length 64
15:25:36.588858 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14533, seq 2, length 64
15:25:36.589180 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14533, seq 2, length 64
15:25:37.572325 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 5, length 64
15:25:37.572626 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14532, seq 5, length 64
15:25:37.587857 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14533, seq 3, length 64
15:25:37.588131 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14533, seq 3, length 64
15:25:38.571329 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 6, length 64
15:25:38.571737 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14532, seq 6, length 64
15:25:38.587015 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14533, seq 4, length 64
15:25:38.587337 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14533, seq 4, length 64
15:25:39.570972 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 7, length 64
15:25:39.571250 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14532, seq 7, length 64
15:25:39.586984 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14533, seq 5, length 64
15:25:39.587297 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14533, seq 5, length 64
15:25:40.571005 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 8, length 64
15:25:40.586967 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14533, seq 6, length 64
15:25:40.587300 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14533, seq 6, length 64
15:25:41.571003 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 9, length 64
15:25:41.587007 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14533, seq 7, length 64
15:25:41.587336 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14533, seq 7, length 64
15:25:42.571002 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 10, length 64
15:25:42.587005 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14533, seq 8, length 64
15:25:42.587327 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14533, seq 8, length 64
15:25:43.571009 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 11, length 64
15:25:43.587009 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14533, seq 9, length 64
15:25:43.587351 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14533, seq 9, length 64
15:25:44.570981 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 12, length 64
15:25:44.586969 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14533, seq 10, length 64
15:25:44.587294 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14533, seq 10, length 64
15:25:45.571004 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 13, length 64
15:25:45.586996 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14533, seq 11, length 64
15:25:45.587312 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14533, seq 11, length 64
15:25:46.570971 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 14, length 64
15:25:47.570997 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 15, length 64
15:25:47.571242 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14532, seq 15, length 64
15:25:48.571005 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 16, length 64
15:25:48.571248 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14532, seq 16, length 64
15:25:49.571001 IP 10.100.104.254 > 10.100.104.15: ICMP echo request, id 14532, seq 17, length 64
15:25:49.571246 IP 10.100.104.15 > 10.100.104.254: ICMP echo reply, id 14532, seq 17, length 64

Do any other see similar behavoir?



Inconsistent SNMP replies between iDRACS:
Strangely, identical servers running the same version (1.57.57) and to my knowledge identical configuration, returns different SNMP replies. More precise, some interfaces does not respond to all OIDS, e.g.:

snmpwalk -v2c -c public -On 10.100.104.13 .1.3.6.1.4.1.674.10892.5.4.1100.30
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.1.1.1 = INTEGER: 1
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.2.1.1 = INTEGER: 1
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.3.1.1 = INTEGER: 0
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.4.1.1 = INTEGER: 2
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.5.1.1 = INTEGER: 3
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.7.1.1 = INTEGER: 3
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.8.1.1 = STRING: "Intel"
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.9.1.1 = INTEGER: 3
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.10.1.1 = INTEGER: 21
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.11.1.1 = INTEGER: 3600
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.12.1.1 = INTEGER: 2100
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.13.1.1 = INTEGER: 6400
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.14.1.1 = INTEGER: 1200
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.16.1.1 = STRING: "E5"
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.17.1.1 = INTEGER: 6
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.18.1.1 = INTEGER: 6
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.19.1.1 = INTEGER: 12
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.20.1.1 = INTEGER: 4
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.21.1.1 = INTEGER: 29
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.22.1.1 = INTEGER: 29
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.23.1.1 = STRING: "Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz"
.1.3.6.1.4.1.674.10892.5.4.1100.30.1.26.1.1 = STRING: "CPU.Socket.1"

and

snmpwalk -v2c -c public -On 10.100.104.15 .1.3.6.1.4.1.674.10892.5.4.1100.30
.1.3.6.1.4.1.674.10892.5.4.1100.30 = No Such Object available on this agent at this OID

On iDRACS which do not respond, we also miss some other information like the Bios version, but we do get information of voltages, fans, temperatures, disk status. Rebooting/resetting/disconnecting power does not seem to help.

Any thoughts on what might be wrong?


Thanks in advance

staale

Daniel My

10 Elder

 • 

6.2K Posts

November 21st, 2014 13:00

Hello Staale

I'm fairly certain that this is intended to prevent the iDRAC from being overwhelmed with requests. I would suggest that you reduce the polling interval on your monitoring software.

I am unable to find any information directly involving this functionality, but I will submit an information request on this to find out more about the functionality.

Thanks

staaleh

2 Posts

November 26th, 2014 00:00

Thank you Daniel, reducing the number of pings does in fact seem to have cured the issue.

It would however be nice to know which restrictions are imposed by the iDRAC interface. Please let us know when you get a respond from your request.

From testing it seems that the limit is somewhere below 5 pings per minute from the same host which do seem to be little aggressive considering that the interface usually will be in a reasonable controlled network enviroment and intended for monitoring/remote control.

Also, any thoughts on the SNMP issue?


Thanks again,

staale

Daniel My

10 Elder

 • 

6.2K Posts

November 26th, 2014 09:00

It would however be nice to know which restrictions are imposed by the iDRAC interface. Please let us know when you get a respond from your request.

I'll let you know when I hear back. The restrictions are only imposed on unauthenticated requests like SNMP and ICMP. They are in place to try to keep your out-of-band management from being knocked offline intentionally or unintentionally.

Also, any thoughts on the SNMP issue?

The first thing I would do is restart the iDRAC(racadm racreset). If the issue persists then make sure the system BIOS and lifecycle controller are up to date. I would also review their configuration to see if they are identical, mainly the processor.

Thanks

SunWolf_R

2 Posts

November 28th, 2014 09:00

I have same problem of packetdrop in ping, verify the RACADM command, the "eth1" Receiver is drop all packet.


/admin1-> racadm ifconfig
bond0 Link encap:Ethernet HWaddr 18:FB:7B:99:C7:D7
inet addr:XXX.XXX.190.25 Bcast:XXX.XXX.190.31 Mask:255.255.255.240
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:13517 errors:0 dropped:0 overruns:0 frame:0
TX packets:15086 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:0
RX bytes:2308770 (2.2 MiB) TX bytes:15111677 (14.4 MiB)

eth0 Link encap:Ethernet HWaddr 18:FB:7B:99:C7:D7
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:13517 errors:0 dropped:0 overruns:0 frame:0
TX packets:15086 errors:0 dropped:0 overruns:0 carrier:1
collisions:0 txqueuelen:1000
RX bytes:2308770 (2.2 MiB) TX bytes:15111677 (14.4 MiB)
Interrupt:59 DMA chan:ff

eth1 Link encap:Ethernet HWaddr 18:FB:7B:99:C7:D7
inet6 addr: fe80::1afb:7bff:fe99:c7d7/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:37294 overruns:0 frame:0
TX packets:37366 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:2242122 (2.1 MiB)
Interrupt:84 Base address:0x800 DMA chan:ff

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:3849 errors:0 dropped:0 overruns:0 frame:0
TX packets:3849 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:903495 (882.3 KiB) TX bytes:903495 (882.3 KiB)

/admin1-> racadm getsysinfo

RAC Information:
RAC Date/Time = Sat Nov 29 01:33:26 2014

Firmware Version = 1.57.57
Firmware Build = 04
Last Firmware Update = 01/01/1970 07:59:59
Hardware Version = 0.01
MAC Address = 18:FB:7B:99:C7:D7

SunWolf_R

2 Posts

November 28th, 2014 10:00

/admin1-> racadm racdump
===============================================================================
General System/RAC Information
===============================================================================

RAC Information:
RAC Date/Time = Sat Nov 29 01:56:58 2014

Firmware Version = 1.57.57
Firmware Build = 04
Last Firmware Update = 01/01/1970 07:59:59
Hardware Version = 0.01
MAC Address = 18:FB:7B:xx:xx:xx

Common settings:
Register DNS RAC Name = 0
DNS RAC Name = idrac-0000000
Current DNS Domain =
Domain Name from DHCP = Disabled

IPv4 settings:
Enabled = 1
Current IP Address = xxx.xxx.xxx.25
Current IP Gateway = xxx.xxx.xxx.17
Current IP Netmask = 255.255.255.240
DHCP Enabled = 0
Current DNS Server 1 = 8.8.8.8
Current DNS Server 2 = 8.8.4.4
DNS Servers from DHCP = Disabled

IPv6 settings:
Enabled = 0
Current IP Address 1 = ::
Current IP Gateway = ::
Autoconfig = 1
Link Local IP Address = ::
Current IP Address 2 = ::
Current IP Address 3 = ::
Current IP Address 4 = ::
Current IP Address 5 = ::
Current IP Address 6 = ::
Current IP Address 7 = ::
Current IP Address 8 = ::
Current IP Address 9 = ::
Current IP Address 10 = ::
Current IP Address 11 = ::
Current IP Address 12 = ::
Current IP Address 13 = ::
Current IP Address 14 = ::
Current IP Address 15 = ::
DNS Servers from DHCPv6 = Disabled
Current DNS Server 1 = ::
Current DNS Server 2 = ::

System Information:
System Model = PowerEdge R720
System Revision = I
System BIOS Version = 2.4.3
Service Tag = 0000000
Express Svc Code = 00000000000
Host Name =
OS Name =
OS Version =
Power Status = ON
Fresh Air Capable = Yes

Watchdog Information:
Recovery Action = None
Present countdown value = 15 seconds
Initial countdown value = 15 seconds

Embedded NIC MAC Addresses:
NIC.Integrated.1-3-1 Ethernet = 54:9F:35:xx:xx:xx
NIC.Integrated.1-4-1 Ethernet = 54:9F:35:xx:xx:xx
NIC.Integrated.1-1-1 Ethernet = 54:9F:35:xx:xx:xx
NIC.Integrated.1-2-1 Ethernet = 54:9F:35:xx:xx:xx


===============================================================================
Coredump Information
===============================================================================
Dec 31 18:00:09 (none) kernel: sh_eth_init
Dec 31 18:00:09 (none) kernel:
Dec 31 18:00:09 (none) kernel: Monolithic/DRB
Dec 31 18:00:11 (none) kernel: hid_init: Desc: Keyboard/Mouse Function
Dec 31 18:00:11 (none) kernel: hid_init: Name: g_kbdmouse
Dec 31 18:00:11 (none) kernel: hid_init: Version: 20120917
Dec 31 18:00:11 (none) kernel: hid_bind: Using Major Number 232
Dec 31 18:00:11 (none) kernel: hid_bind: using r8a66597_udc, Keyboard ep1 Mouse ep2
Dec 31 18:00:11 (none) kernel: hid_bind: Mouse REL ep3
Dec 31 18:00:15 (none) kernel:
Dec 31 18:00:15 (none) kernel: Generate the command process, the pid is 739!
Nov 28 10:13:28 (none) kernel: g_kbdmouse: high speed config #1 for Keyboard/Mouse
Nov 28 10:14:01 (none) kernel: g_kbdmouse: high speed config #1 for Keyboard/Mouse
Nov 28 10:15:17 (none) kernel: g_kbdmouse: high speed config #1 for Keyboard/Mouse
Nov 28 10:15:48 (none) kernel: g_kbdmouse: high speed config #1 for Keyboard/Mouse
Nov 28 10:16:14 (none) kernel: g_kbdmouse: high speed config #1 for Keyboard/Mouse


===============================================================================
Network Interface Statistics
===============================================================================
Kernel IPv6 routing table
Destination Next Hop Flags Metric Ref Use Iface
::1/128 :: U 0 3 1 lo
fe80::1afb:7bff:fe99:c7d7/128 :: U 0 0 1 lo
fe80::/64 :: U 256 0 0 eth1
ff00::/8 :: U 256 0 0 eth1


Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
xxx.xxx.xxx.16 0.0.0.0 255.255.255.240 U 0 0 0 bond0
0.0.0.0 xxx.xxx.xxx.17 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 xxx.xxx.xxx.25:22 xx.xxx.xx.244:61899 ESTABLISHED
tcp 0 0 127.0.0.1:48252 127.0.0.1:8195 ESTABLISHED
tcp 0 0 127.0.0.1:199 127.0.0.1:51401 ESTABLISHED
tcp 0 0 127.0.0.1:8195 127.0.0.1:48252 ESTABLISHED
tcp 0 0 127.0.0.1:48251 127.0.0.1:8195 ESTABLISHED
tcp 0 0 127.0.0.1:199 127.0.0.1:51400 ESTABLISHED
tcp 0 0 127.0.0.1:8195 127.0.0.1:48249 ESTABLISHED
tcp 0 0 127.0.0.1:48249 127.0.0.1:8195 ESTABLISHED
tcp 0 0 127.0.0.1:51400 127.0.0.1:199 ESTABLISHED
tcp 0 0 127.0.0.1:51401 127.0.0.1:199 ESTABLISHED
tcp 0 0 127.0.0.1:48250 127.0.0.1:8195 ESTABLISHED
tcp 0 0 127.0.0.1:8195 127.0.0.1:48251 ESTABLISHED
tcp 0 0 127.0.0.1:8195 127.0.0.1:48250 ESTABLISHED


===============================================================================
Session Information
===============================================================================
SSNID Type User IP Address Login Date/Time
---------------------------------------------------------------------------
4 SSH root xx.xxx.xx.244 11/29/2014 01:56:51

===============================================================================
Process Information
===============================================================================
PID USER VSZ STAT COMMAND
1 root 3040 S init
2 root 0 SW< [kthreadd]
3 root 0 SW< [ksoftirqd/0]
4 root 0 SW< [watchdog/0]
5 root 0 SW< [events/0]
6 root 0 SW< [khelper]
9 root 0 SW< [async/mgr]
70 root 0 SW< [kblockd/0]
81 root 0 SW< [khubd]
84 root 0 SW< [kmmcd]
144 root 0 SW [khungtaskd]
145 root 0 SW [pdflush]
146 root 0 SW [pdflush]
147 root 0 SW< [kswapd0]
148 root 0 SW< [aio/0]
149 root 0 SW< [nfsiod]
150 root 0 SW< [cifsoplockd]
152 root 0 SW< [crypto/0]
316 root 0 SW< [mtdblockd]
320 root 0 SW< [sh_spi.0]
356 root 0 SW< [kstriped]
371 root 0 SW< [rpciod/0]
376 root 0 SW< [mmcqd]
425 root 1172 S /etc/sysapps_script/watchdog_app_.sh start
436 root 0 SW< [kjournald]
438 root 0 SWN [jffs2_gcd_mtd7]
488 root 0 SW< [cryptodev_queue]
550 root 0 SW< [dell_fpdrv thre]
560 root 0 SW< [sh_pbi_wq]
599 root 2972 S /bin/sh /etc/sysapps_script/cfgscripts/cfgbkup.sh
678 root 0 SW< [MSD-0]
687 root 0 SW< [MSD1-0]
696 root 0 SW< [MSD2-0]
705 root 0 SW< [MSD4-0]
739 root 2828 S ifconfig eth1 up
779 root 0 SW< [loop6]
783 root 0 SW< [kdmflush]
793 root 0 SW< [kcryptd_io]
794 root 0 SW< [kcryptd]
817 root 4228 S /bin/dlogrotate 20
891 root 0 SW< [kjournald]
910 root 9456 S /sbin/aim
959 root 9940 S /avct/sbin/os
1398 root 4348 S /bin/ttymonitor
1407 root 7148 S tm
1462 root 35132 S ipmiSystemCallAgent
1467 root 42068 S {SoftTimer} /bin/fullfw
1504 root 0 SW< [ki2c6]
1507 root 0 SW< [ki2c3]
1509 root 0 DW< [ki2c2]
1510 root 0 SW< [ki2c1]
1512 root 2960 S getty -L ttyS3 57600 vt100 -H AVOCENT
1528 root 17944 S /sbin/avct_server
1538 root 7252 S /avct/sbin/pm
1542 root 4364 S /sbin/vfk
1555 root 2852 S /bin/jdaemon
1577 root 9148 S /usr/sbin/dsm_sa_snmpd
1604 root 8800 S /usr/sbin/dsm_sa_eventmgrd
1617 root 10740 S /usr/sbin/dsm_sa_datamgrd
1620 root 11536 S /usr/sbin/dsm_sa_popproc lclpop
1646 root 0 SW< [ki2c5]
1648 root 10504 S /usr/sbin/dsm_sa_popproc lmpop
1652 root 0 DW< [ki2c4]
1688 root 9300 S /avct/sbin/fmgr
1735 root 0 SW< [bond0]
1753 root 8056 S {START} /avct/sbin/osinet
1821 root 1816 S /sbin/syslogd -m 0 -f /flash/data0/etc/syslog.conf
1823 root 1332 S /sbin/klogd
1833 root 0 SW< [kjournald]
1842 root 0 SW< [kjournald]
2364 root 20560 S /usr/sbin/ipmiextd
2482 root 5996 S tm_ntpd_monitor
2498 root 4352 S /sbin/vkvm_pm
2503 root 3324 S ntpd -c /tmp/ntp.conf -g
2546 root 8128 S /bin/fb_source
2550 root 7412 S /bin/fb_vnc_server
2563 root 6644 S /bin/ipmi_gateway
2568 root 4672 S /usr/sbin/raclogd
2586 root 4264 S /usr/sbin/sfcbd -d
2599 root 7700 S /sbin/avct_wsman -r0
2600 root 9144 S /sbin/avct_wsman -r0
2636 root 4056 S /usr/sbin/sfcbd -d
2638 root 5780 S /usr/sbin/sfcbd -d
2643 root 1408 S /usr/sbin/ifplugd -i bond0 -afqI -u0 -d0 -miff
2693 root 5252 S /sbin/sshd -g 60
2697 root 21792 S /usr/local/bin/appweb --config ../../../../etc/appweb/appweb.conf
2699 root 23448 S /usr/local/bin/guiDataServer
2705 root 4212 S /usr/sbin/sfcbd -d
2707 root 4192 S /usr/sbin/sfcbd -d
2711 root 4476 S /usr/sbin/sfcbd -d
2745 root 2968 S {appweb_monitor.} /bin/sh /etc/sysapps_script/appweb_monitor.sh start
2752 root 6112 S /usr/local/bin/apwHdlrAgent
2768 root 3280 S /usr/sbin/mrcached
2794 root 13092 S /bin/maserserver
2801 root 1472 S /bin/AppMonitor
2835 root 7424 S /bin/mctpd
2846 root 15664 S /usr/sbin/dsm_sa_popproc iracpop
3035 root 14748 S /usr/sbin/dsm_sa_popproc ienvpop
3089 root 12940 S /usr/sbin/dsm_sa_popproc hwipop
3096 root 7160 S /usr/sbin/dsm_sa_popproc jcpop
3101 root 14488 S /usr/sbin/dsm_sa_popproc hiipop
3106 root 16656 S /usr/sbin/dsm_sa_popproc raidpop
3111 root 6228 S /usr/sbin/dsm_sa_popproc proxypop
3116 root 8540 S /usr/sbin/dsm_sa_popproc reutlpop
3176 root 2960 S /sbin/crond -b
3186 root 2960 S {S_mmc_track.sh} /bin/sh /etc/sysapps_script/S_mmc_track.sh
3188 root 2628 S /bin/memusage -t 10240
3203 root 2828 S sleep 86400
3237 root 3040 S init
3498 root 7132 S /sbin/snmpd -c /etc/snmp/snmpd.conf udp:161,udp6:161
8581 root 12408 S {sshd} sshd: racuser@pts/0
8601 root 2828 S sleep 30
8645 root 7836 S -clpd
8651 root 8596 S /usr/sbin/sfcbd -d
8679 root 24856 S /bin/racadm racdump
8702 root 2828 S sleep 5
8709 root 2960 S sh -c /bin/ps
8711 root 2968 R /bin/ps
16587 root 0 SW< [kjournald]
16600 root 0 SW< [loop0]


===============================================================================
RAC Firmware Build Log
===============================================================================
BLD_TAG=idracfw_bldtag_1.57.57_700101_0800_00
BLD_VERSION=1.57.57
BLD_NUMBER=70.01.01
BLD_DATE=built for sh7757-DRB system
BLD_TYPE=idrac
BLD_KERNEL=ZIMAGE

Daniel My

10 Elder

 • 

6.2K Posts

January 14th, 2015 10:00

Okay, I've been going back and forth with information requests on this for a while. We are not willing to provide exact details on the unauthenticated request configuration for the DRAC, but I should be able to provide enough information so that you can configure your monitoring tools to avoid timeouts.

You should configure all of your monitoring applications or anything that is performing ICMP/SNMP requests to the iDRAC so that the iDRAC is not receiving more than 2 per second. If the DRAC is receiving more than 2 per second you will likely receive timeouts. Even if you configure a longer delay in all of your monitoring applications you will still likely receive timeouts because occasionally they will probably send more than 2 per second even with a delay configured. To avoid this you should try to use a centralized monitoring station and avoid having several monitoring tools interacting directly with the iDRAC.

Thanks

vtloki

1 Rookie

 • 

8 Posts

August 16th, 2016 08:00

Any suggestions on the lack of SNMP oids being returned by some idracs vs others? We have 2 identical idrac 6 enterprise cards, both running 1.98 version of idrac, and one provides all the hardware data over snmp, and the other does not. We confirmed SNMP is enabled, and we do get some of the 10892 old information, just a very small amount. None of the real meaningful stuff on cpu, voltage, temp, status, etc. 

I was trying to see what the "minimum" version of idrac that was needed to provide the correct data we need for our monitoring solution, but when the exact same firmware delivers different results, that's hard. 

Was this post helpful?

View All

0 events found

No Events found!

Top