10-04-2011 10:43 PM
We've got a few DCX-4S's for a while now running FOS 641b, they are running fine except for on issue.
Every once in a while the eth port on the active CP blade becomes inoperable, meaning our network guys tell us the port is coming up and immediatly goes down again. This repeats itself multiple times a minute and happend on three different DCX's.
The only workaround we have for now is to hafailover the active CP.
Unfortunatly this has to be done onsite as the command is only available on the active CP which, by then, is only manageable using the rs232 connection.
My questions has anyone seen this beheaviour before and more importantly does anyone know how to fix this permantantly.
Thanks in advance
10-08-2011 04:58 AM
Can you say which Ethernet switches do you have in use for your DCX?
How long are the switches up and running without reboot?
I have currently not seen this issues in my infrastructure but I will asks the network guys if they see any flapping ports on the DCX switches.
If you can login as root into the standby CP card you should be able to open a telnet session to the internal IP 10.0.0.x of the active CP (backplane IP). Provide a username and password and then you should be able to run hafailover.
This had worked for me serveral times without the need to go onsite.
This will not fix your flapping port issue but help a bit to get back the control of the DCX.
I hope this helps,
10-09-2011 06:13 AM
DCX are up for 3/4 yearm connected to Cisco 6500.
I've tried to gain access over the backplane, but didn't succeed before while logged on as admin.
I haven't tried root though and will try that tommorrow.
10-10-2011 01:17 AM
Connecting trough backplane ip didn't work.
No telnet, ssh or ping responses.
Tried it on a normal functioning DCX same results.
Think I have no other choice but to go to the DC for a hafailover.
10-10-2011 01:35 AM
--->>>No telnet, ssh or ping responses.
I would try follow:
Remove first the Standby CP wait One Minutes, and Re-Insert now, wait till the CP is coming Up and Running.
Then Remove Active CP wait One Minutes, and Re-Insert now.
if the result is the same, you can try with hafailover command.
My opinion is follow:
The problem will continued to persist, and you have to replace the CP.
Message was edited by: TechHelp24
10-10-2011 03:51 AM
You are right on DCX this is currently not working.On 48000 directors this procedure still works in FOS 6.4.1b.
Unbelivable that this backdoor is not open anylonger. This is really a serious issue. Sorry for the wrong information.
10-10-2011 04:43 AM
I worked it out.
The adresses on the backplane:
Backplane IP address of CP0 : 10.0.0.5
Backplane IP address of CP1 : 10.0.0.6
Did not work , no ssh, telnet and ping response
But both CP's must still be communicating with each other as hashow still reports synchronized
Then i went to netstat to look for anything intresting, as I didn't try this in my first attempt.
And there i found ipadresses like
tcp 0 0 127.1.1.5:2003 127.1.1.6:41867 ESTABLISHED
tcp 0 0 127.1.1.5:27246 127.1.1.6:56966 ESTABLISHED
tcp 0 0 127.1.1.5:8001 127.1.1.6:56986 ESTABLISHED
tcp 0 0 127.1.1.5:27247 127.1.1.6:36115 ESTABLISHED
An ssh to cp0 (.5) works, I can manage my DCX again, haven't done a hafailover yet as the eth port on the 6500 is shut.
As to why the interface starts bouncing I do not know, but now we're getting somewhere.
10-10-2011 07:45 AM
They're indeed fixed adresses, but it looks like (our 4 DCX's (HP OEM) at least) use the 127.1.1. range for internal communication.
I don't know how why or when, but i know the 10.0.0. range doesn't work for me and the 127.1.1 range does.
12-10-2015 07:29 AM
I know this is an ancient post, but we have recently put in the sn8000b director switches and have the same problem, i cant believe they didnt change the HA failover to realise when its network port is down to failover. I've been told by HP support I will have to re-seat the active CP, did you do this to resolve you issue? if so did this cause any issues on any of the SAN ports?