BladeSystem - General
cancel
Showing results for 
Search instead for 
Did you mean: 

Flex-10 modules lose access to server profiles

A.W.R
Frequent Advisor

Flex-10 modules lose access to server profiles

Hi,

We have a c7000 Blade enclosure with 2 Flex-10 modules. On occasion both Flex-10 modules hang. We try re-seating the Flex-10 modules, powering off the chassis, etc. etc. nothing seems to work.

We then did a firmware upgrade from 3.15 to 3.17 and the Flex-10s worked again, and all the profiles were present.

I have been told it could be related to a DNS problem embedded in the Flex-10?

We are considering implementing a second c7000 to provide redundancy for the first one. The Blades are running the VMware virtualisation software. But if we lose the first c7000 enclosure will the virtual machines be able to failover to the second c7000 if the Flex-10 modules are down?

Any input would be appreciated.

Thanks
Andrew
4 REPLIES
cjb_1
Trusted Contributor

Re: Flex-10 modules lose access to server profiles

The dns 'fix' is in the 3.17 firmware which suggests this was your issue. You can check whether you had dns entries set by looking in the ebipa settings under the interconnects page.

Problem was with all vc enet interconnects with dns set, not just flex 10.
A.W.R
Frequent Advisor

Re: Flex-10 modules lose access to server profiles

I read the release notes about this fix, would it cause both modules to hang?

Regards
Andrew
cjb_1
Trusted Contributor

Re: Flex-10 modules lose access to server profiles

Yep.
Proliant VMS San Mgrs
Frequent Advisor

Re: Flex-10 modules lose access to server profiles

Hi Andy,

Did you assign 10.x.x.x IP addresses to your flex / VC modules? If so, this caused the problem.

What is frustrating is: it appears HP was aware of this problem. This is a bug, which translated 10. from ASCII to binary (ASCII 1 is 49, ASCII 0 is 48, ASCII . (period) is 46) giving a class C address in the 49.48.46.0 range. The bug was ignored, because that class C was not valid.

This Class C was allocated mid February. DNS queries to this (previously bogus) class C began to resolve, and returned errors. For instance, nslookup (for the 4 ASCII characters of 10.1) of 49.48.46.49 shows

mx-ll-49.48.46-49.dynamic.3bb.co.th

This was discovered (and reported on the SAN security mailing list) when outbound SSH connections to this Class C were observed by sites following best practice and monitoring outbound connection attempts

This caused a huge problem around the world. You could be affected if you were running any c class chassis with any virtual connect. The temporary fix was to erase the DNS server settings in the OnBoard admin under Enclosure Bay IP Addressing (for each tab). Sometimes that resulted in a complete reset of the V/C interconnect devices.

You can find several other ITRC threads on this topic, including the customer advisory; but now the firmware upgrade should fix it.

A powerful reminder: firmware is the new single point of failure. You could have 100 chassis, and every one of them might have failed at the same time if 10.x.x.x addresses were in use...
Problems Solved