DRAC 6 web access fails but IPMI CLI succeeds

Hello,

The R300 used the DRAC 5. The DRAC 6 came with the next generation server, the 11th Gen. At this point in time, the DRAC was a single add-in card. If that card is not present, you would not have DRAC capabilities. It sounds like the card is no present. You can confirm by removing the server cover and checking for the card. I'll link to the user guide. The DRAC is item 10 on page 158.

https://downloads.dell.com/manuals/all-products/esuprt_ser_stor_net/esuprt_poweredge/poweredge-r300_owner%27s%20manual_en-us.pdf

In the servers after this, more and more components were moved to the board itself and the DRAC became the iDRAC, the "i" meaning "integrated."

Hello Dylan,

thank you for your quick help and the documentation!

I checked the server and indeed i have the controller installed, but not the optional dedicated RAC-port. Therefore i dedicated the NIC1 and configured it as "shared", assigning it an IP in the BIOS, but did not configure it in the OS.

Pinging works well and ipmictl as well.

And the HTTPS-connection to the configured IP address also - somewhat at least: the server seems to refuse the connection.

As i am aware of the fact that this server is to be considered "legacy" at least, it wouldn't surprise me that it needs 128bit encryption and SSL <3, which modern browsers would refuse to negotiate to.
But shouldn't that drop in Firefox 24 i also tested still feature all these protocols and thus succeed?

All our younger DELL Poweredges run their iDRAC on 443, that's why i assumed this also for that old version...

Surprisingly: if i boot off the DELL Support Live Image (2.2), the OSA utility on it has full access to the DRAC over port 1311...

So all together it feels like i'am pretty close to it...

using what port? shared

on mine I have 4 NIC ports, and 1 dedicated Drac 6,  (R710 and R410)

I HAVE  NIC PORTS 3 AND 4 DISALBLE

and 1 and 2 are active.  I use port 1

the drac IP is not the same as the shared port IP. ( sorry if you know all this).

you  must use only the drac IP, (reserved is best sure)

my firefox v65 works perfectly on DRAC6 ,  and see the index page easy, using the raw IP.

my guess here is using the wrong  IP.

or drac6 is not supported on older gen? (hard to here , a post loves to build real URL;s)

http://

10,10,1,171

here is my drac 7 IP,  (ends up as https://10  .10.1   .1  7 1/   login.html

I have host file set to DRAC2 (this ip)( and have it book marked)  2 = server #

hope this helps you.

to see the 1st DRAC page the server does not need to be turned on, so the OS is not a concern here.

you can turn the server on in DRAC first page. (after login)

I also flashed bios, then drac then h700 last. so they are newest firmware. ask how.

did you first set up drac using the rom hot key seen as you boot the server, it prompts for many hot keys.

one is control +E

do to full setup;  using service monitor at either VGA ports.  I'm sure you did but this is really first.

my cisco router has built in IP scanner, that tells me all IP and mac; and I can see the normal IP for the server and the DRAC IP  when scanned. (ping sure)

or use any IP scanner, I have one called demon scanner, that even does ports. (love this tool)

The DRAC 5 does use a 128bit encryption, and I would expect that dropping back to an older browser would help accommodate that, and other security needs for the older hardware. I located the DRAC 5 user guide as well, so if you don't have it already, that should definitely be of value. Pages 27 and 28 list the network ports the DRAC5 uses.

https://downloads.dell.com/manuals/all-products/esuprt_electronics/esuprt_software/esuprt_remote_ent_sys_mgmt/dell-remote-access-cntrllr-5-v1.60_user%27s%20guide_en-us.pdf

Is there any chance that this is an R310, as opposed to an R300? I ask because at that point in time, we only had one option, that being a DRAC, or not to buy a DRAC. The card at that time had a dedicated port on it.

The reason I ask is because I think there may be some confusion in DRAC usage in 10G and older systems, compared to 11G and up, when the Express or Enterprise option was first present. I think the BMC in the system may also be a contributing factor to that, because I would expect the BMC to provide some response to pings or IPMI commands.

 What might put some of this to bed, would be to take a couple of pictures of the DRAC in the system. If you can locate any stickers on what you believe to be the DRAC, those would make for good picture candidates, too. I say that because if we can capture the PPID, I can pull a part number from that and see exactly what we're working with. This will help me, because I only show one DRAC option for the R300, and it had an onboard NIC port. 

That having been said, here are all the things I do when working with a DRAC/iDRAC that is giving me problems.

1) racadm racreset, to restart the iDRAC. Racadm racresetcfg will reset the configuration. Sometimes reapplying settings can help. Using racadm commands also help to confirm whether or not the DRAC is responsive. Racadm getsysinfo would be a command to display some system information and change nothing, so is a command I use a lot for troubleshooting. Racadm commands do require either OpenManage or ractools to be installed in the OS, though.

2) If using a shared port, trying to access the DRAC from the same server can be problematic from having traffic coming in and out the same port. There may well be some settings to help this make a more stable connection, but I've not encountered a config where this worked with reliability.

3) Testing multiple web browsers can be helpful, as well as clearing any and all browser cache. If you have an older version of Internet Explorer, that might make for a good test candidate. I've been trying to locate supported browser versions, but not finding much. The manual I linked to does say " Internet Explorer version 6 SP2 or version 7," so you might want an older version of Firefox. I looked at release dates and IE 7 came out in 2006 and FF 24 came out in 2013. Looking at the history of FF, release 2 or 3 would be the candidates I would test with, because they release between 2006 and 2009. The R300 should have released around that time.

4) Java shouldn't come into play until a virtual console loads, so I wouldn't focus on Java too much. Not right now, anyway. If you run into problems once the web GUI loads, then it may be worth looking into.

Hello Savvy2, hello Dylan,

many thanks for your heads up!

I start feeling guilty since this is such an old device...

As you Dylan proposed to nail the exact specs of the controller, i tried the following:

If this is not sufficient and a photo would definitely help better, i'll catch up on this.
But it's a bit difficult to maintain, as the system is already productive...

My DRAC configuration via "CTRL+E" does not feature the "dedicated" option (as i don't have that dedicated port, it's place is empty and covered by a black plastic cover),
but it allows to assign an IP-address, which belongs into our management network.
Instead i use the "shared" option offered, and assume that this will refer to the NIC 1 (and not NIC2).

There is actually no explicit mapping as i realised now, am i right?
Both are the only built in NICs the devices shipped with, and the NIC 2 is used by the hosted OS.

The IP address configured via CTRL+E is not used in the OS, and the NIC "1" is also not configured in the OS hosted on that machine.

That IP address answers to pings and ipmitool-queries (both locally and from remote), e.g.:

ipmitool -I lan -U root -H 10.10.0.10 chassis status

But https still fails:

Firewalls are switched off for this, although this should not be affected by the hosted operating system anyways, if i understand all of this right.

@ "If using a shared port, trying to access the DRAC from the same server can be problematic from having traffic coming in and out the same port."

Good to know!
In order to exclude this and any influence from the intermediate network, i also repeated the tests via a direct crosslink to that shared NIC1, configured with that reserved IP address.

But unfortunately nothing changed.

I inched back to using Firefox 10, which also should be 32bit, but that also did not change the situation.

The configuration in the BIOS related to the serial redirection is not possibly interfering here?
Because it also mentions "Remote access".

I left it switched on, but not configured to redirect to COM1 or COM2.

As said at the beginning: this is an old device.

But still it starts bugging me because i also would like to understand what's going on ;-)

I'll start to study the guide Dylan sent me the link of, maybe there is still some implicit configuration i overlooked or misunderstood.

Best regards and many thank again for your help!

The output you're sharing with me is leading me to believe one of two things. The first being that the DRAC isn't installed, that having been said there is another plausible explanation. It could be the case that the DRAC isn't responsive. With modern iDRACs, we perform a power drain when they stop responding. It forces the iDRAC to restart. To accomplish the same thing here, I would probably look at shutting the server off, removing the DRAC card, powering the server up with it removed, then shutting down and reinstalling it. The idea here would be to try to get the system to acknowledge the hardware change and to full power down the DRAC, perhaps bringing the card back online.

Hello Dylan,

thank you for your proposal. My guts feeling also tells me that this must be s.th. of that category, as all other measures applied so far should at least fundamentally have failed in a more telling manner, providing some serious indicators. I can't apply your proposal immediately, but soon, and will feedback the outcome here.

Many thanks again for the help of all of you!

Best