V6 customer lan IP change 1

[sto933]

Hi everybody
Have the same problem as in thread965-1693098.
Got Hipath V6 R2 duplex "clean" from factory, installed through portal got it up and running (with extensions and trunks) but customer asked to change customer LAN addresses. After i changed it in portal, nothing is accesible- no portal, no Assistant.
What to do? Reinstall SW?

 

[sbcsu]

There is a procedure for this, not easy but can be done.
Setup a spreadsheet with OLD IP / NEW IP and what the IP's are for.
Ping all the 'new' IP addresses to make sure that they are not already used.
Ensure that the system is functional including the remote shelves.


You start with remote shelves if you have them?
Then IP Cards that run phones and or Operator console or IP links to other systems.
Then you are left with the processors.
I have a PDF document which you can download HERE
Read it a few times to understand everything that is involved.

 

[sto933]

Thanks a lot, sbcsu!
Exactly like you mentioned - such a proedure requires very carefull preparation.
but it took 12 hours for me to restore working conditions playing with yast and firstinst script.

 

[donb01]

I can't see your file because heaven forbid we would actually be able to access something useful on an outside file sharing service from work....

I am in the process of rolling out V7 with the vendor. Unifiy/Siemens shipped the switch with default IP addresses, and the tech went in there and changed them, probably similar to what happened above. All of a sudden we went from having a system that was up and running to a system that would not start up the switch layer - same thing, duplex system.

The plan was to make them ship us a new set of drives with the right configuration on it, so the tech left the job and went back to the office. Having 10+ years of linux experience I figured I couldn't make it any worse, so I did a console login to each processor and looked at specific files that can cause problems if you mess with the IP addresses. I found that in the /etc/hosts file there were some inconsistencies between the two sides. One had the IP definitions for hp4k-a and hp4k-b that referred to itself and the other side, but the other one only had a definition for itself, and not the other side. Knowing better, but wanting to test the theory I added the missing definition for the other side.

Shut both sides down and powered it back up. Both of them came up, synced and loaded the switch layer just fine, and I was at a normal A/S condition with a running switch.

I suspect the fact the couldn't both see each other on LAN4 was the reason why they were not communicating and syncing up, as after I cleared of the missing link it was happy.

This leads me to believe that you must not change the processor IP addresses throught he portal, or webmin or whatever - there must be a script file somewhere that makes sure when you make a change the IP addresses are updated everywhere they need to be, and not just in one layer or at the hardware level.

We continuted on the path of replacing the drives because they were already ordered, and also because I know linux will edit those hosts files of its own accord, and if it did so based on some other file that was incorrect I was probably going to have problems later on, but it was a good exercise in getting to know how the switch flows, and how the things sync up.

 

[sbcsu]

Haven't upgraded any to V7 myself yet only V6 at the minute.
That file is on dropbox so accessible from everywhere (outside your work LAN?)
I did successfully change a V6 IP range and all went well (running system, changed at minimum use time)

 

[sto933]

I found that in the /etc/hosts file there were some inconsistencies between the two sides. One had the IP definitions for hp4k-a and hp4k-b that referred to itself and the other side, but the other one only had a definition for itself, and not the other side.

Right, donb01, been there. A complete mess in /etc/hosts files on both processors. Lines with the different addresses but all with the same host name...
What misguided me was a seeming simplicity of such a procedure described in Hipath's manual.

 

[donb01]

Part of what alerted me to look there was watching the boot stream when the system came up and seeing error messages about duplicate hostnames and things along that line. V7 is an interesting bird - built like a pyramid. The base is SUSE11, and on top of the SUSE11 runs a SUSE10 VM, and then finally on top of the SUSE 10 VM runs the HP4K application. The SUSE 11 does all the talking to the server hardware and peripherals, but takes its marching orders from the SUSE 10 VM that acts as an intermediary to the HP4K app that manages the telephony functions. (If I understand all that correctly). All of it must sing together in perfect harmony on that one host, and then if you run duplex all that has to mirror itself in perfect harmony to the second host of the exact same configuration.... When you use the assistant or portal app it makes changes to the active processor environment, and then that mirrors over to the standby side. If anything interrupts to that process things start displaying great big sad faces - it even has a cool little LED display where you can see all kinds of cool stats about how things are running, how much load is on the system, etc.... Fortunately the majority of the AMOs are the same, and most of the assistant stuff, and the assitant has a sportier new look without blowing up when you have Java 7 on the admin PC.