BladeSystem - General
1753634 Members
5607 Online
108798 Solutions
New Discussion юеВ

Re: Unbearabily slow OA and iLo (firmware 1.30)

 
Frank Ng
Advisor

Unbearabily slow OA and iLo (firmware 1.30)

We just got our test c7000 enclosure with the following ...

2 x OA
2 x 460
2 x 465

The OA is connected to our management network and all the iLo IPs are in the same network as the OA. When accessing the OA, it's slow but we'll learned to deal with that. But we noticed that when me and one other person is trying to work on two different machines via two different iLos, the refresh rate on the remote console is slow (either java or active x version). As soon as one of us log off our iLo remote console session, the other iLo will be fast again.

We've have a big deployment of p-class blades, but we don't see the same problem there. All 16 p-class blades share the same 1 management nic in the iLo enclosure with no problems.

But the c-class demo we have, it's unbearabily slow. Shouldn't all 16 iLos be independent of each other, if one is working on one iLo, it should not affect another person working off another iLo in the same enclosure.

Anyone seen this behavior in their deployment?
13 REPLIES 13
David Claypool
Honored Contributor

Re: Unbearabily slow OA and iLo (firmware 1.30)

Sounds like you have a network problem, which your other post on PXE/DHCP would seem to further indicate. Check your network setup, including DNS, both forward and reverse lookups.
Frank Ng
Advisor

Re: Unbearabily slow OA and iLo (firmware 1.30)

The other post was due to VC, we still have to figure that out. We took all VC modules out of the enclosure and replaced them with Ciscos and we have no problem getting the dhcp address. Plus, it's on two different networks. OA and iLos are on the management network, the pxe pieces are on the access network.

This enclosure was added to an existing management network. We do not see the same issue anywhere else. Even with the large p-class deployment we have.
David Claypool
Honored Contributor

Re: Unbearabily slow OA and iLo (firmware 1.30)

Did you check forward and reverse DNS lookup entries for the OAs and the iLOs?
Frank Ng
Advisor

Re: Unbearabily slow OA and iLo (firmware 1.30)

Yes, first thing. But it didn't seem to have helped at all. Which makes me wonder, why it would need reverse lookup for a webapp, especially for management purposes.

But this is driving me nuts. Like I mentioned before, we have a large deployment of Proliants DLs and p-class BLs running iLo 1 and the speed is amazing compared to this.

No one else is seeing this issue?
HEM_2
Honored Contributor

Re: Unbearabily slow OA and iLo (firmware 1.30)

duplex mismatch? ILO's should have speed/duplex set to Auto...switchport where the OA/ILO connects should be set to Auto

any errors on the switch port that the OA/ILO port is connecting to?
Frank Ng
Advisor

Re: Unbearabily slow OA and iLo (firmware 1.30)

They are set to auto on both sides.

No errors on the switch port.

This problem disappears if I connect directly to the management network where the OA is connected to. As soon as the traffic crosses a router, it's unbearably slow. It couldn't be a network issue as we have all the iLo 1s sitting on that same management network and we see no problem there.

It looks like the OA was build for corp and not for a production environment. It assumes you are on the same network. You can tell as it is not very friendly if you start to route traffic through a ssh tunnels and port forward the traffic. It assumes you are on local port 443. iLo 1 does not have this issue. But that's a whole other issue.
Oleg Koroz
Honored Contributor

Re: Unbearabily slow OA and iLo (firmware 1.30)

Frank Ng
Advisor

Re: Unbearabily slow OA and iLo (firmware 1.30)

Don't know if that applies, if you are talking about the remote consoling via iLo, we are using IE and the integrated remote console (active x) for console.
Darrenn
Frequent Visitor

Re: Unbearabily slow OA and iLo (firmware 1.30)

Are you going via a proxy server ?

I had a similar problem, took the proxy out of the loops and it all worked fine.