Mars Device Discovery with SSH

I am trying to add a device (switch) to the Mars appliance. When selecting access type as SSH, I get an error, 'not able to log in... username/password failed'. Using the same username and password, I change the access type to telnet. Mars discovers the switch with no trouble. The SSH error includes the string it uses to connect 'ssh -c 3des -l username 1.1.1.1' I can successfully access the switch with the same string from the Mars command line. I have retyped the username and password a dozen plus times with no success. Any ideas?

It look like bug to me, check this bug-id CSCsi03658.

Similar Messages

MARS - device inventory with double domain names

Hi folks.
I have a bunch of devices (mostly ASA's) in MARS where the domain name has been appended twice. For example, if my asa is corpfw1.midwest.company.com, mars shows it as corpfw1.midwest.company.com.midwest.company.com
Before I go start mucking around with deleting/reimporting, what's the best way to fix this?
TIA

We have seen this as well when doing the following.....
Adding new device and in the name field you put the fully qualified name. Then when you do the test connectivity, it appends the second domain naming structure on the end of it. We have gotten around it by entering just the dns name, not the fully qualified name, and then it is correct when it appends the fully qualified name after connecting to it.
It is a little different case, but same type of results. don't know if that helps or not, but you are not alone in seeing this type of activity.

Help with LMS 4.1 device discovery?

Hello,
I'm new to the LMS family and seem to be having an issue with device discovery. The discovery session launches, (I get an email telling me it launched) but the summary page tells me that while the devices are discovered, none of them are reachable.
I've checked the SNMP strings, and they match (and also worked under Whats Up). Is there a specific log I can look at to find out what's going on under the hood of LMS?
Thanks,
Cam Wynd

If you go into the processes and click on CSDiscovery then start, it will run the discovery. That's just a work around for now.

Device discovery does not work with Yosemite

After updating to Yosemite, my (13-inch late 2010) Macbook Air can no longer find the printer on my home network, although I can print by specifying the printer’s IP address. Furthermore, Airport Utility cannot find my Airport Extreme; it says Device Not Found while acknowledging that the Airport Extreme was previously part of my network. However, the same Mac has no difficulty connecting to the internet through the Airport Extreme. It seems that some device discovery protocol (Bonjour?) is no longer working on that Mac.
I updated our other Macbook Air (11-inch mid 2011) to Yosemite without any issues. It finds the printer on the network, and Airport Utility finds the Airport Extreme.
Any suggestions?

Hi, this is Detective Vdawg, and I came across a similar issue when I updated to Yosemite on my MacBook Pro (Retina, 15-inch, Early 2013). Here is what I did. First, turn off all bluetooth devices turn off your printer and your computer. Wait about 15-30 seconds, then press and hold these four buttons for five seconds: shift, control, option, and the power button. What that does is refresh the hardware components; your settings will remain the same as they were before. After the computer reboots, then everything should be working the way it normally does including your device discovery. If that helps, please let me know; also let me know if it does not resolve your issue for whatever reason. I will be searching for different ways to resolve this problem. If you come across any more issues along the way, I would be happy to help you if I can.

Device discovery failure in ANM

Anyone familiar with this error:
Device discovery failed: For input string:"1/0"
I am receiving it when attempting to import a new chassis into ANM. All of the credentials are correct.

Number one error with ANM 1.1 installs has been not having SSHv2 configured on the Supervisor (and the subinterfaces ANM may use to reach that module). Since ANM is managing the ACE, which in turn is often managing e-commerce applications with SSL and SSH connections, not having the control interfaces at the same level of security was undersirable.
ANM 1.2 is being updated to allow the operator to start off without SSHv2, though this will be strongly discouraged for production operations.
DK

How to create device IDs with same name

i am using SE 3310 and its creating different device ids for each node sharing it . since I will be building a RAC enviornment I need these IDs/name to be same .
for example on one node the lun id is /dev/rdsk/c3t0d0s6 but the same lun id on node 2 is /dev/rdsk/c2t0d0s6.
In past with an old storage array I fixed this issue by creating links in /dev/rdsk for c3t0d0s6 ---> c2t0d0s6.
my question is : is there a way in SE3310 that device ids get created with same name or do i still have to rely on creating these soft links ?
thanks
Note: since i need the answer to this quickly i will wait a while and then post this question in other forums and i will update the question here with the answer .

This could be a Solaris (I presumed) O.S. question rather than SE3310 or storage question.
The logical device (/dev/[r]dsk/*) is the work of the O.S. when it first configures the device, in this case the LUN from your SE3310.   I can go in depth on how the cX number happens (due to device probe order, driver differences, history of device discovery due to need of persistent device naming, etc...) but ... it's a really long story and is really quite irrelevant and most people should not be interested...
If you have COMPLETELY identical servers, i.e. identical hardware down to specific HBA in specific slot are the same,   and if you make sure that luns are presented to all servers exactly the same way, same order, and any changes are seen by all servers in the same sequence, in theory, all /dev/rdsk/* devices will be consistent across servers.
But that's still rather irrelevant.    Application that is designed to work in a redundant environment should not be dependent on logical devices like /dev/rdsk being the same.
So ... in effect this is also not a question for the Solaris forum, but rather a question for those familiar with RAC, how to configure such that device access is done "safely" through actually identifying the lun rather than assuming /dev/rdsk are consistent.

How to Fix Disappearing HP Printer Drivers -- Disable HP CUE Device Discovery Service

I have a new HP G60-530US laptop with Windows 7 installed (less than 2 months old). It is connected to an HP 7410 All-in-One Printer and a Brother laser printer.
Three times now, the HP 7410 printer has mysteriously disappeared from the installed printers. The Brother printer does not disappear.
To re-install the HP 7410 printer requires disabling the AVS using the Services,msc utility (not just shutting down the AVS (Panda in my case)). It takes 20 minutes or so to re-install the HP printer driver software.
HP tech support is clueless about the cause or cure for this.
The laptop people referred me to the printer support people and the printer support people referred me to the laptop support people. The last tech support guy suggested that I restore the system on the theory that if the problem persisted it would be a hardware problem and not a software problem. He seemed to miss the fact that the disappearing printer driver software only occured with HP printers.
HP technical support was worthless.
Some internet forums suggest that this occurs when HP machines are connected to different networks. I noticed my problem occur after I took the laptop on a business trip and connected to a different wireless network.
On Vista forums, I've discovered that the disappearing HP printer drivers has been a problem for some time over a wide range of HP printers.
The solution identified on those forums is to stop and disable the HP CUE Device Discovery Service. Apparently, this service is used to detect HP printers and add them to the HP Solutions Center software.
In my experience, the HP printer drivers disappeared when my laptop comes into range of a "foreign" HP printer with wireless capabilities. For example, my laptop dropped my configured HP wireless printer when I went to an office that had a different wireless HP printer installed. The HP CUE service trashes the existing printer driver even though you do not intend to install and use the "foreign" printer. That would also explain why the printer drivers disappear when visiting a hotel or other location where any HP wireless devices exist. It would also explain why non-HP drivers do not disappear.
I've disabled the CUE Device Detection Service (using the Services utility). I'll see if that works. From what I've read, the CUE Device Detection Service is not needed after you have installed your printer, but it remains in your computer's active memory just "in case" you want to connect to a new HP printer and install software for that printer. Said differently, after your printer is installed, it remains as useless HP software that clogs your machine's resources.
A patch from Microsoft or HP (e.g., a patch that disables the CUE service) would be a big help to users if the number of posts on this issue are any indication of how pervasive this problem is.

This seems to be a common problem that exists for many HP devices, varying computer moakes and models and different operating systems. So, the conclusion must be that it is a HP issue. WHY ARE THEY NOT FIXING IT?
Based on this I am quite happy to buy a different make of printer so how does HP justify the continuing lack of support?
I posted a message about my C7180 All-in-one which had been causing problems but I put it down to me making (unrelated) changes to my system then noticed it got worse when I connected a new Trust digital pad. However, even when the pad is not connected I get the problem of disappearing drivers with the printer still visible.
What seems to happen to my set-up is it works when it is first reloaded and used, but the next time I open the HP software it fails and no other software is able to print/scan on the device.
Can somebody explain what the CUE is? I'll give it a try but I don't know what it refers to.
Who'd have thought that in the 21st century, software/hardware engineeers still can't make a simpy process for a computer. Whatever happened to the promise of plug'n'play?
P.

LMS 3.1 Device Discovery

Hi, Having had a fully operational version of Ciscoworks on a very old server we were advised to move it to a virtual server, with a new IP address. Unfortunately since then the device discovery is not collecting data on all devices on our network, and showing them as unreachable. Even though I have replaced the IP address in the configs on the network switches.
The odd thing is that it is finding 6 devices but not all of them. Just wondered if this is something anyone out there has seen before that may be able to shed some light for me.
Thanks
Jo

Hi,
Kindly make sure all the device are snmp reachable with the new IP from the CiscoWorks Server. However more information will be found by enabling the debugging for Device Discovery and then try to run the Device Discovery again.
To enable the debug for Device Discovery , kindly to Common Services > Device & Credentials > Device Discovery > Discovery Logging Configuration > select the modules you are using for device discovery along with Data Collector, Discovery DeviceInfo , Discovery Framework, Discovery util and run the device discovery again and then send the ngdiscovery.log from CSCOpx\log location.
Also kindly make sure you have make the required changes on the Schedule discovery settings as well since Schedule discovery have its own settings for Device Discovery as compared with Ad hoc Discovery settings.
Here is the good doc link created by Sir Joseph Clarke to understand the Device Discovery and for troubleshooting purposes.
https://supportforums.cisco.com/docs/DOC-9005
Note :- ngdiscovery.log contain information about the IP address of your device in the network.
Thanks,
Gaganjeet

LMS 4.2 Device Discovery

I have used every version of LMS since 1.0 and I'm very familiar with the software. My problem is with the last few versions and the device discovery feature. It seems that in earlier versions, once the seed device was configured and devices had the appropriate community strings and cdp was enabled, the device was discovered. With these earlier versions, all of my devices were discovered. Any new device added to the network was also discovered. I never had to deal with devices that were "Unreachable" as all my devices were "Reachable". My network has not changed. I still have the same core switch ip address since version 1.0. My edge switches are still configured for the network as they always have. Same community strings. What has changed is the LMS discovery process. What's going on with these "modules"? I have 120 devices on my network and 117 will be "Unreachable". Even the core switch is unreachable. I have tried CDP, Global, seed device, DCR as seed. Still the devices are unreachable. There are no firewalls or access lists. The LMS server has complete access to all devices. Does anybody have any thoughts, comments??? Or am I just being too picky expecting the software to just work? TIA

Nothing has chnaged as considerable in discovery module since inception. Addition of new modules and algorithm has just made it stronger and smarter.
If all the devices are unknown there is certainly some issue with communication using snmp. I would request to modify and if you think multiple communities may be there try to configure all and keep the target *.*.*.*.
Following guide on LMS discovery stands from LMS old versions to till date similar on how it works :
https://supportforums.cisco.com/docs/DOC-9005
-Thanks

CiscoWorks LMS 4.0.1 / Device Discovery

Simple question, not so simple answer?
I have tried multipule times to do device discoveries, the same 26 devices come up unreachable. I have checked, double checked, and tripple checked the snmp community ro and rw strings on the switches and that snmp is enabled.. All seems configured correctly on the switches. I have tried arp, ip ping, cdp, just about all of the proper discovery protocols. I have tired using different seed devices, even already known reachable devices.... I'm stuck, no clue why I can't get this going! Please help. As a side note.. If imanually added unreachable devices as an snmp target in snmp setting windows during device discovery configuration it will "reach" and add the devices.

John...did you get this resolve? I am having the same issues. Several of my devices with subnet of 10.83.*.6 (seed switches) are unreachable in CW. I can telnet to many of the devices from the CW server and see that the community string (RO/RW) is the correct string in the configure however, still unreachable. Was you able to get this working? I do have a TAC case open for this. Still working through the issue. Write back...thanks in advance.

Device discovery in Cisco Prime LMS 4.1

Hi,
im using CISCO PRIME LMS 4.1 for manage my network, i ran a device discovery job using a ping sweep on the ip ranges of my network, ie 192.168.1.0/24, 192.168.2.0/24 and so on... the discovery found all my devices, but it discovered duplicate devices with illegal ip Addresses, ie
ip                                    device
192.168.1.255               S1
192.168.2.0                    S1
192.168.2.1                    S1 (the real address)
all in reachable status.
i dont undestad why the program adds that repeated illegal addresses.. someone can help me with that issue??
how can i run the device discovery to avoid this problem?
Many Thanks.

Julio,
Don't let LMS decide on what IP address it will manage the device.
For example, let LMS do a lookup of the sysname in DNS, then it will use the IP address coming back from the DNS as management IP.
This is what I do to avoid this.
But I also feel that LMS should be bright enough to never manage the same device twice. I think Campus DFM or RME will eventually figure out the 2 devices are the same, but they can't "fix" what is wrong in the DCR.
Cheers,
Michel

LMS 3.2 Device Discovery

Is there a document that gives a better technical explanation of the discovery process? The
documentation I've found so far is fairly superficial.
I'm testing discovery with a new LMS 3.2 installation and so far it seems like I will have to enter every IP subnet we have in a ping sweep, because devices just aren't getting discovered. I tried CDP alone with one seed - a router at the hub of our network. I tried discovery with that one seed router with both CDP and Routing Table - I would expect that to discover other devices via the subnets in the routing table. That's not what happened, so I'm wondering how the "Routing Table" module actually works.
If we don't have CDP everywhere, will devices without CDP be discovered?
Finally, I've seen a number of comments here that say not to use the DCR as a seed file. I must be missing something, because I would think that you'd want to do a discovery starting with what you already have to find out what's been added to it, without having to tell the app where to look. That seems to defeat the purpose of discovery.
Any assistance would be greatly appreciated!

Discovery requires that every device be reachable via SNMP using the SNMP credentials you configured in Discovery. Devices which are found by the various algorithms which are not reachable via SNMP will be marked as unreachable, and will not be added to DCR. So, while you may configure ping sweeps, and Discovery may be able to ping certain nodes, it does not mean that those nodes will be discovered.
Generally, users choose CDP and ping sweep. Routing Table is fine, but it can lead to SNMP CPU spikes on routers with large routing tables. The way the routing table module works is to poll the ipRouteTable via SNMP, then go through each ipRouteNextHop to find the next hops. Because polling this table can be CPU-intensive, it is often filtered out using an SNMP view.
If you only go with CDP, then devices which do not have CDP neighbors will not be found dynamically. Such devices would need to be manually added as seeds.
And I generally recommend people enable "Use DCR as seed". This can greatly cut down discovery time.

Device discovery failed in ANM

Hi,
I've got the following error message when I want to import a 6506 in 12.2(33)SXI2 with an ACE module.
I've tried in ANM 2.2 and 3.0 = same problem.
Can someone help me ?
Device discovery failed: Exception occured for model:VlanModel
Exception occured for model:InterfaceModel
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort
com.cisco.nm.dice.pkgs.features.interfaces.dm.L2Trunk cannot be cast to com.cisco.nm.dice.pkgs.features.interfaces.dm.RoutedPort.
Thanks,
Greg.

Hi Greg,
The error message you are seeing is likely triggered by some un-expected configuration on the cat6k.
It is likely your cat6k configuration has an interface defined as a switchport which has a subinterface defined on it.
This is usually not allowed on most sup versions that we have seen and hence is not modeled/ cannot be discovered in ANM.
We have bug id CSCtd94658 opened for this issue.
You could try to have your customer remove the subinterface indicated above and then try the import into ANM.
Also, they could maybe add back that interface if really required after the initial import.
Since Cat6k configs are not auto-sync'ed in ANM, they will be okay until they do a manual sync.
This workaround in also documented in the release notes of CSCtd94658.
Thanks
Sujatha
========

Device Discovery Error (Lenovo Toolbox)

Today when I went to run Lenovo Toolbox, it would not completely load and would complain that it had a Device Discovery error and to hit ok and restart the application. Has anyone else been running into this issue? When I log in as another user it works fine. Someone elsewhere had mentioned something about Firefox causing the problem, but if it works on one profile and not another I don't see how the two are related.

I have the same problem on my T42p. Installed toolbox version 5.1.5183.17, with Firefox 3.0.8, upgraded from 3.0.7 and problem persists. Have tried with toolbox allowed and not allowed to go online, but halfway through its initial screening, the error appears: Device Discovery Error Your system was busy performing other tasks when Lenovo System Toolbox attempted to collect information. Click OK and restart the application. If the error persists, restart the system.
Restarting does no good. Firefox can be on or off. Same problem.
p.

LMS 3.1 Device Discovery issue

Hello,
I have been getting myself familiar with LMS, but can't figure out why I am having issues seeing some devices. I can't find any solution to my problem on other posts.
I have a server farm connected to my core switch, both can see each other via CDP, and the SF can ping the LMS server. However, I have 'device unreachable' on device discovery and CiscoView. SNMP community strings are the same on each device, and are configured on LMS.
Any suggestions? Thanks in advance!

Hi,
LMS tries to contact each device directly via SNMP. If it can talk directly to the device, the device is added into DCR as Reachable. If it cannot talk directly to the device, the device is deemed as Unreachable and it is not added into DCR to be managed by LMS.
If LMS is unable to communicate it could be due to any number of things including timeout, incorrect community string, snmp-server view, firewall or access list.
A definitive way to determine the issue would be to perform a packet capture during discovery to see the SNMP transaction between LMS and an 'unreachable' device.
You can also try increasing the timeout value.
Thanks.

Mars Device Discovery with SSH

Similar Messages

Maybe you are looking for