08-20-2008 12:59 AM
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
Solved! Go to Solution.
09-02-2008 02:38 PM
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.
08-20-2008 07:19 AM
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
08-21-2008 10:36 PM
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?
08-22-2008 07:41 AM
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?
08-25-2008 10:43 PM
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.
08-25-2008 11:35 PM
Try creating a new job. The old job may have the IP address information cached.
08-26-2008 07:13 AM
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?
08-26-2008 09:16 AM
Go to RME > Config Mgmt > Archive Mgmt > Sync Archive. Select the problem device, and run the job.
08-27-2008 05:28 AM
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?
08-27-2008 09:04 AM
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.
08-29-2008 01:10 AM
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.
08-29-2008 06:27 AM
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"?
08-29-2008 08:40 AM
I think I know what's happening here, but I'd like to see a screenshot of everywhere you see this wrong IP address.
09-01-2008 01:24 AM
09-01-2008 02:29 AM
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.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide