MIBS, SMMPv1, SMMPv2, SMMPv3 and management
1 post • Page 1 of 1
Hi, I have an issue with telnet credentials in LMS. We use ACS server with TACACS+ for authentication. I can seem to be able to find a detailed guideline how to configure the credentials so maybe I am doing something wrong. Please see the attached screenshot showing where I configured the telnet credentials. The other screenshot has results of config fetch jobs. What worries me a little bit is the fact that the job itself could not be executed in the first place? The wait time is 3 minutes. If I test the credentials in RME -> Devices -> Device Management -> Device Credentials Verification jobs the telnet shows as incorrect as well. EDIT: The telnet credentials are valid. I use them to access our devices. Hope it makes sense, Martin
You are configuring the credentials in the correct place. However, unless you login and are immediately enabled, you will need to enter an enable password as well in DCR. The first error points to a potential problem with ConfigMgmtServer. Most of the known bugs surrounding this are fixed in RME 4.3, but there is still one outstanding: CSCtg43962. Try restarting ConfigMgmtServer with the commands: pdterm ConfigMgmtServerpdexec ConfigMgmtServer Then try and archive the config again. If it still fails, start a packet capture filtering on all telnet traffic to the device, and run the job again. The sniffer trace should clearly show what is going on. If the DCR credentials are correct, another common problem with config archive is custom authentication prompts. If you have custom prompts configured on your AAA server, you will need to add them to NMSROOT/objects/cmf/data/TacacsPrompts.ini.
Hi Joe, The credentials I use do give you enable access straight away. About the service restart, I have restarted the whole server several times already mainly because of "Internal error in communication channel". We will probably have to raise a TAC request for a patch, which I believe you wrote, for multi-processor Windows servers. I will try to get a sniffer between those two servers and hopefully that will show us whats happening. What I don understand is why some devices show in our ACS log with "missing username" as a failure reason and others don show at all. We have device pooling every morning and thats when I see at least a reason for failure. If I manually set LMS to fetch the config there is nothing in ACS. The authentication prompts were never configured so they should be all default, but it is definitely something worth checking out. Thanks for the info Joe. If you can think of anything else what could cause these issues and shed some light on the inconclusive ACS reports that would be great.
LMS will establish an initial TCP socket to the device to determine supported protocols and for things like transferring vlan.dat, the local interface of the LMS server. This could result in a "missing username" error on ACS. Yes, I wrote a patch to fix a problem with DCR communication due to a timing issue on multi-processor Windows machines. TAC can provide you that patch.