Don't know but I have solved my problem using solarwinds.
I am getting solarwinds IP Address Mgmt to scan the network and get the SysName by SNMP. This then produces a db that is readable by MS Access. So I schedule an FTP to copy the file to my DNS server every so often(that I have installed MS Access on). I have built a query in Access that produces a format that is useable by DNS. Next I have a macro that automatically exports this query to DNS. So I now have a DNS server that automatically updates itself to include the details of all my cisco devices.
Thats a lot of work for something so simple. Here's something I found last night using LMS 3.0 and QPM 4.0. LMS will not resolve the device name when adding devices. I used QPM to add a device and it pulled the complete hostname with domain suffix. RouterA.domain.com.
SO how is it possible that this CiscoWOrks app can do it but the core LMS product can't?
Yes, this is the point. Why can't you just extract the simple info that other simple snmp applications can? Why do I need to set up a whole DNS infrastructure and maintain it? Why does CiscoWorks QPM accomplish this but LMS can't?
This has also been a point of contention as we try and synchronise our network management tools' inventories. Another product that Cisco's OEMing Opsware (now HP) NAS also grabs the device host name.
Why is this a useful bit of information for Ciscoworks ? Let me list it in one word: BUGS!
Since the DCR was introduced as the repository for all applications we've been fighting to keep it listing only a single instance per device.. sometimes its a loosing battle. Hostname is a pretty good flag to sort a list by (I know serial number is good too, but not all cisco devices can report that) to identify duplicates.
Maybe in a smaller shop with 50-100 devices this isn't a problem but when your on the scale of thousands of devices it really is. I'm at 5,600 devices and growing so I do feel this pain.
[toc:faq]The ProblemOn traditional switches whenever we have a trunk
interface we use the VLAN tag to demultiplex the VLANs. The switch needs
to determine which MAC Address table to look in for a forwarding
decision. To do this we require the switch to do...
[toc:faq]Introduction:Netdr is a tool available on a RSP720, Sup720 or
Sup32 that allows one to capture packets on the RP or SP inband. The
netdr command can be used to capture both Tx and Rx packets in the
software switching path. This is not a substitut...
IntroductionOSPF, being a link-state protocol, allows for every router
in the network to know of every link and OSPF speaker in the entire
network. From this picture each router independently runs the Shortest
Path First (SPF) algorithm to determine the b...