IP Office Application Server R12.1 Dell R240 NEW - losses ip addressing after a few days

[JohnMccauley]

We recently installed a new R240 application server R12.1 to replace an older version and everything installed fine VMPro working no issues but after a week or so the VMPro stops working and can't even ping the server. keyboard, monitor and mouse. when login ifconfig shows nothing on etho & eth1. Opened ticket with avaya and they had me rebuild the server. I have done this 3 times now and same thing happens after a few days. anyone have this issue before?

​

 

[biv343]

There was this bulletin about IP addresses defaulting, which doesn't look exactly like what you're experiencing, but it wouldn't be the first time an an issue was slightly different. I haven't touched 12.0 or 12.1 yet as those releases seemed to be rushed to market, even more than previous releases.

Sign On

Details​

IP Office Server Edition R12.0 & 12.1

Problem Clarification​

Dell R240 ASP 110 Avaya Provided Server keep loosing its assigned IP and gets to the default 192.168.42.1 when the server is rebooted.

Cause​

In the Network Manager interface (nmtui in CLI), the eth0 connection did not have the "Automatically Connect" box checked. Due to this, whenever the server boots up, it creates a new eth0 connection with default IP (192.168.42.1) and activate that connection.

Solution​

Keep the "Automatically connect" box checked in the Network Manager Interface for the desired connection.
To do this follow the procedure below:

• Connect to the Server using Putty and gain root access.
• Type in the command 'nmtui'.
• Click on 'Edit a connection'.
• Select the desired connection (Either eth0 or eth1).
• Make sure the box 'Automatically connect' Checked for the connection.
• Click on 'Ok' in the bottom to save it.

 

[franciscomcorona]

re-build, and try to copy the network information, that way, when this happens again, you can rebuild the ifcfg-eth0; I'm just thinking you could re-enable the network interface this way, because obviously the MAC's still there.

Did you check for the ifcfg-eth0 files?

 

[JohnMccauley]

re-build, and try to copy the network information, that way, when this happens again, you can rebuild the ifcfg-eth0; I'm just thinking you could re-enable the network interface this way, because obviously the MAC's still there.

Did you check for the ifcfg-eth0 files?

I appreciate the help but I don't want to have to keep doing this, hoping there is a more permanent solution. I will check

 

[derfloh]

I recommend to follow the hints in the Avaya Solution.

Another hint… nmtui is a CLI based user interface to configure the Linux ‚Network Manager‘. As far as I know - correct me if I’m wrong - Network Manager doesn’t use the ifcfg-xyz files sonchangung them will probably not help.

 

[mhoxie]

The issue is that with with 12.1 this linux version will disable the network interface if the link goes down. The issue I experienced is when using both LAN 1 and LAN 2, and LAN2 is down, and you open Manager to make a change, you nearly brick the system because manager auto-populates with 192.168.43.1 and you make a save and now Manager has conflicting IP data with what's in the eth1 files on the linux. It's incredibly stupid that Avaya used a linix distro that completely disables interfaces automatically and there is no work around. If you have a "set it and forget it" phone system then maybe it would be ok. But for a high volume customer that has hundreds of users and makes changes every day, this is a serious issue.

 

[ChampTerps]

NetworkManager stores new network profiles in keyfile format in the
/etc/NetworkManager/system-connections/ directory.

Previously, NetworkManager stored network profiles in ifcfg format
in this directory (/etc/sysconfig/network-scripts/). However, the ifcfg
format is deprecated. By default, NetworkManager no longer creates
new profiles in this format.

Connection profiles in keyfile format have many benefits. For example,
this format is INI file-based and can easily be parsed and generated.

Each section in NetworkManager keyfiles corresponds to a NetworkManager
setting name as described in the nm-settings(5) and nm-settings-keyfile(5)
man pages. Each key-value-pair in a section is one of the properties
listed in the settings specification of the man page.

If you still use network profiles in ifcfg format, consider migrating
them to keyfile format. To migrate all profiles at once, enter:

# nmcli connection migrate

This command migrates all profiles from ifcfg format to keyfile
format and stores them in /etc/NetworkManager/system-connections/.

Alternatively, to migrate only a specific profile, enter:

# nmcli connection migrate <profile_name|UUID|D-Bus_path>

For further details, see:
* nm-settings-keyfile(5)
* nmcli(1)