Solved: RME uses wrong IP addresses for telnet - LMS 2.5

netzeatkw · ‎08-20-2008

Hello,

RME 4.0 used wrong IP addresses for telnet connections. I changed the addresses in common services and tested the correct funtion in RME - Device Management - check device credentials.

The telnet connection was working well.

The next morning, the configuration save had failed with error:

TELNET: Failed to establish TELNET connection to 172.23.x.x - Cause: TELNET: Failed to establish TELNET connection to 172.23.x.x

and the IP address had changed to the wrong value.

Even deleting of the device and adding in common services did not help.

Where does RME get the wrong IP addresses which it should not use for telnet connections and how can I prevent it from doing so?

Thank you in advance for your help

Joe Clarke · ‎09-02-2008

I occurred to me that by router ID, you most likely mean loopback addresses. This, then, is almost certainly Campus Manager Discovery which is changing your IP address. You should try excluding these devices from Discovery under Campus Manager > Admin > Device Discovery.

View solution in original post

Joe Clarke · ‎08-20-2008

RME gets device address information from DCR. If you do not have the IP address configured in DCR, but rather just the hostname, then there is a bug where LMS daemons cache the successful lookup of that hostname indefinitely. This would require you to either enter the IP in DCR, or restart dmgtd every time you change the DNS record for a device. The bug is CSCse85033, and this was fixed in LMS 3.0

netzeatkw · ‎08-21-2008

I changed the fields 'host name' and 'IP-address' under common services ... device properties to the correct IP address but it did not help. Where do I have to change it? Is it necessary to restart dmgtd when I change these fields?

Joe Clarke · ‎08-22-2008

That is the location where you would need to change the IP address and hostname. When you changed those values, did you schedule a new job, or did you allow an existing job to run again?

netzeatkw · ‎08-25-2008

After changing the values I did a dmgtd stop / start.

I did not schedule a new job but the existing archive update job ran afterwards and showed failed devices due to the wrong IP addresses.

Joe Clarke · ‎08-25-2008

Try creating a new job. The old job may have the IP address information cached.

netzeatkw · ‎08-26-2008

I only know how to schedule the globel Config Collection under RME -> Admin -> Config Mgmt -> Archive Mgmt -> Collection Settings. How can I Create a Test Config Collection for the changed devices?

Joe Clarke · ‎08-26-2008

Go to RME > Config Mgmt > Archive Mgmt > Sync Archive. Select the problem device, and run the job.

netzeatkw · ‎08-27-2008

That job was this time successful. What do I have to do that the daily RME Archive Mgmt Collection uses the correct values of hostname and IP address?

Joe Clarke · ‎08-27-2008

Disable the system polling and collection jobs, and apply those changes. Once the jobs are disabled, return to the Collection Settings interface, and re-enable them. You should get new job IDs, and the problem should go away.

netzeatkw · ‎08-29-2008

I got new job IDs but the problem still remains the same. The scheduled archive poller and update jobs fail and the device properties are changed to the wrong IP addresses after running the job.

yjdabear · ‎08-29-2008

Do you mean the "wrong IP addresses" are populated into the device properties in DCR, after running the jobs? Is it one single "wrong" IP address, or multiple "wrong IP addresses"?

Joe Clarke · ‎08-29-2008

I think I know what's happening here, but I'd like to see a screenshot of everywhere you see this wrong IP address.

netzeatkw · ‎09-01-2008

There are multiple "wrong IP addresses" that are populated into the device properties in DCR, after running the jobs. Here are screenshots of the failing RME archive job and the changed CS device Properties.

Joe Clarke · ‎09-01-2008

I don't see the problem. The IP address in DCR is the same that is showing up in RME. If the .123 address is wrong, change it in DCR.