RME3.4 Device attribute TACACS 'not supported'

[DRUK]

Hi All,

I've seen a few threads related to this problem a few times here and there but no obvious answer. I'm running RME 3.4 IDU 8 and have imported the devices from ANI server. Devices include 3550, 2950, 2924XL and 4500 switches plus 2600 and 1700 routers. All devices are accessable via telnet and ssh and all have correct TACACS+ aaa configs. Telnet and SSH to the boxes from the command line works a treat and there is no problem accessing them at all. When added to RME and setup, the SNMP checks out OK and works fine for both RO and RW but TACACS will only check out OK for the 3550's and 2924XL devices.

All other devices are shown as 'not supported' for TACACS. The IOS on all devices are fairly recent (last 3 months) and the 4500's are totally up to date. I've set the RME config to check SSH then TELNET but this made no difference.

Any help would be gratefully accepted

Regards

Rich

[minie]

Are other devices enable mode also require TACACS+? Did you enter both TACACS user/pass and TACACS enable user/pass(if required by devices) in RME? Get a sniffer trace to see what has been sent to the devices from RME.

[DRUK]

Thanks minie,

I actually tried using telnet and enable TACACS but had no difference from Telnet TACACS and local enable password. It actully appears to be saying that telnet is not supported on the switch - when it clearly is. I thought at first it was a prompt problem and have checked that the telnet prompt is described in tacacsprompts.ini correctly.

I'll try the packet sniffer - what exactly am I looking for in the string?

Cheers

Rich

[minie]

You can use "follow tcp stream" if use ethereal to see what credentials being sent by RME and what prompt sent from devices.

You mentioned you had IDU 8.0 installed. So it's not very likely but majority of TACACS/Telnet not supported issues are indeed the devices not supported. So also use snmp query tools to get device sysoid and compare it with online device support table.

http://www.cisco.com/en/US/customer/products/sw/cscowork/ps2073/products_device_support_tables_list.html

[DRUK]

Okay - I used Etherpeek - but anyway - it appears that CW2K is not actually making any attempt to contact the devices using telnet or SSH in anyway. It's all pure SNMP traffic - apart from a few pings which I assume are the availability checks.

It's weird because the same configuration is working fine for the 3550 and 2924XL switches but skipping all of my other kit. All of the configs are the same and to get this working i've even set the passwords to be the same. All devices work fine using normal command line utils and all devices are placed in the correct 'switch', 'router' etc groups in DFM so CW2K does know what they are.

I've checked a couple of the devices which aren't working and they are in the table you sent. This isn't bleeding edge kit here - 1720 router? 2950-48port switches etc. I'm not too sure where to look next.

I really am ever so grateful for the help - cheers - I'll be signing off soon (UK) so if you reply and I don't get back right away I'm not being rude ;)

Rich

[Martin Ermel]

have you tried to stop device synchronistation from ANI to RME, then delete the device in question from RME completely, restart LMS (net stop crmdmgtd, net start crmdmgtd) and add the device again through RME - administration- Inventory - add device

[DRUK]

Hi,

Thanks mermel, I've tried this action yesterday and again today when I receieved your reply. It didn't work I'm afraid. CW2K just identifies the device as a Generic SNMP device same as always. Like I said the software appears to work fine and uses telnet on the 3550's but just not the 2950's, 4500's or any router at all.

Cheers

Rich

[DRUK]

Additional - I actually removed all devices, purged the database, restarted the box, added the devices manually ... and it was exactly the same.

;(

Regards

Rich

[DRUK]

Just done a 'debug telnet' on one of the devices and it is not even contacted by CW2K to see if the device is 'not supported'. The only thing I can think of is that it (CW2K) first performs an SNMP query and then makes the decision if it is supported or not from the return strings - does that sound right?

[DRUK]

FIXED

Okay so this was a bit of a no brainer and for that I am deeply sorry. I actually re-applied the IDU 8 again and this time it worked. It may have been that I applied other updates after the IDU8 which knocked something over but either way applying the IDU 8 patch fixed the problem.

Thanks to everyone who helped 'or laughed' at this thread - and if anyone else has 'not support' devices I'd suggest they apply or re-apply the latest IDU pacth for RME.