Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Openview vs Cisco Works
- Thread starter sifiguy
- Start date
Ive used both. My company just recently converted to Cisco Information Center, and of the two, I like CIC. The problem I had with Openview is that it took too long to run the initial discovery when you invoke the GUI. Openview keeps an object database where Cisco does not.Cisco also does not poll devices, but you can definitely write a mod that will do it for you.
___________________________________
[morse]--... ...--[/morse], Eric.
___________________________________
[morse]--... ...--[/morse], Eric.
Here's my experience with Cisco Works 2000(CW2K).
At a former company, we bought a BUNCH of new Cisco switches. Our sales rep threw in a free copy of Cisco Works 2000 on the order. My boss said, "make it work." So I got to implement it.
Now, {disclaimer} this was 3+ years ago. So the current product may be better ( I would hope so
).{/disclaimer}
In short, it was painful and not very beneficial.
Our environment included ~20 Cisco routers and ~50 Cisco 6500-series switches. I had been using expect(1) scripts to push all my configuration changes.
CW2K had a database back end that was temperamental. It took a lot of my time to keep it up and running.
The thing that looked to be of help was that it would report when any device's configuration changed. You could also schedule a push of a configuration change to happen when you're at home sipping a cold one. The process of setting up a config change was not very intuitive and I never got it to do what I think it should have been doing.
I still prefer expect(1) scripts to do my config changes.
I've since written a perl script that will check the "NVRAM config last updated" string, compares it with a stored value for that device, and if different, kicks off a scarfconf.pl process to download the newest config version. (scarfconf.pl comes with the current distribution of MRTG under the contrib/cisco_tftp directory.)
The only other feature of CW2K that I didn't have was the Response Time Reporting (RTR now called SAA) tool. This provided the ability to see and report the delay between RTR-enabled devices. But this was before Tobi had smokeping fully developed. (see
In the end, I convinced my boss that we weren't getting much return on the amount of effort we had to invest to keep it running. It became shelf-ware.
HTH,
Patrick
Patrick Bartkus, CCNP, CNX, SCM, RHCT Sr. Network Engineer
GA Dept of Labor IT Network Services
If truth were not absolute, how could there be justice?
At a former company, we bought a BUNCH of new Cisco switches. Our sales rep threw in a free copy of Cisco Works 2000 on the order. My boss said, "make it work." So I got to implement it.
Now, {disclaimer} this was 3+ years ago. So the current product may be better ( I would hope so
).{/disclaimer} In short, it was painful and not very beneficial.
Our environment included ~20 Cisco routers and ~50 Cisco 6500-series switches. I had been using expect(1) scripts to push all my configuration changes.
CW2K had a database back end that was temperamental. It took a lot of my time to keep it up and running.
The thing that looked to be of help was that it would report when any device's configuration changed. You could also schedule a push of a configuration change to happen when you're at home sipping a cold one. The process of setting up a config change was not very intuitive and I never got it to do what I think it should have been doing.
I still prefer expect(1) scripts to do my config changes.
I've since written a perl script that will check the "NVRAM config last updated" string, compares it with a stored value for that device, and if different, kicks off a scarfconf.pl process to download the newest config version. (scarfconf.pl comes with the current distribution of MRTG under the contrib/cisco_tftp directory.)
The only other feature of CW2K that I didn't have was the Response Time Reporting (RTR now called SAA) tool. This provided the ability to see and report the delay between RTR-enabled devices. But this was before Tobi had smokeping fully developed. (see
In the end, I convinced my boss that we weren't getting much return on the amount of effort we had to invest to keep it running. It became shelf-ware.
HTH,
Patrick
Patrick Bartkus, CCNP, CNX, SCM, RHCT Sr. Network Engineer
GA Dept of Labor IT Network Services
If truth were not absolute, how could there be justice?
You should be able to do this with any product.....its in the Cisco MIB. As for the NVRAM last updated, that should be in the MIB too, I would try and see if I couldnt do an snmpwalk on that device to grab it instead of writing a script using Expect. While I have a lot of respect for it, if it can be done easier with SNMP, then I will do it that way.
___________________________________
[morse]--... ...--[/morse], Eric.
Eric,
I totally agree. Quering a MIB sometimes can be much simpler than the way I'm doing it. I did do an snmpwalk and never saw the dates.
But, one of the problems with Cisco MIBs is that they have a tendancy to change where they store things based upon on the equipment on which it resides. I found that a simple thing like switch port link speed and duplex can be in different places in the MIB depending upon the switch model.
So rather than fool with having to code different MIB values for NVRAM last updated, I always know where I can find it in a "show run" output. Besides expect(1), the perl module Net::Telnet is my 2nd best friend. B-)
Patrick
I totally agree. Quering a MIB sometimes can be much simpler than the way I'm doing it. I did do an snmpwalk and never saw the dates.
But, one of the problems with Cisco MIBs is that they have a tendancy to change where they store things based upon on the equipment on which it resides. I found that a simple thing like switch port link speed and duplex can be in different places in the MIB depending upon the switch model.
So rather than fool with having to code different MIB values for NVRAM last updated, I always know where I can find it in a "show run" output. Besides expect(1), the perl module Net::Telnet is my 2nd best friend. B-)
Patrick
- Status