What are your network management pain points?

[mroyle]

Within Cisco’s Network Management area, we continually develop and refine our management solutions for unified communications.  While we like to think we have covered everything, we realize the importance of soliciting frequent feedback and input from unified communications customers, even those that do not use our products.  In this vein, we would like to hear your perspective and experiences with regard to network management. 

Specifically, what are the top three network management challenges, or pains, you are experiencing?

Thanks,

Mark

Solution Marketing Manager

Cisco Systems

[degriffin]

We currently have 7,000 IP devices on our enterprise network; this deployment is on a gigabit backbone that ollows the Cisco 3-tier design for a high-availability campus deployment spread across 45 buildings, 120 access layer switches and 8 CallManagers (v5.1(3) with dedicated Publisher and dedicated tftp server). We do have Operations Manager and Service Manager deployed on a limited basis (not in full time production) but our 3 biggest management pain points are:

- How can we check a server process to ensure that it is working as designed - For exampple how to check the tftp process is working->we know what firmware phones should be at; but knowing what like devices are not at the same firmware level. We often find that IP phones do not get updated firmware or local config changes due to a 'hung' tftp process and knowing out of sync devices would be a quick indicator of this symtom.

- Managing or adding SNMP to a IP phone: We have a lot of user complaints about computers with poor performance when plugged into an IP phone. Usually our 1st tier support will remove the PC connection from the phone access port and give the user a new switch port; meaning that a user now has a switchport for their phone and a switchport or their computer. When switchports are at a premium, usually our 2nd tier support gets involved and we find that the phone has 1000's of errors on the access port due to a damaged UTP cable and once replaced, errors go away and user complaint is resolved. If SNMP was enabled on a phone, these type of errors could be captured in a NW management system.

- Ability to quickly capture  statistics of specific phones  or modeling of capabilities real-time on our network. Using Operations Manager with Service Manager and 1040 sensors we can do sampling of our network and capture general information; but we always seem to have individual users with voice quality problems. To deploy sniffers or sensors to capture rtp streams for specific phones is time consuming and often fustrating to the end-user while these tools are put into place. If there was a capture utility within OpsManager would be sweet...

My 3 wishes and thanks, Doug

[mroyle]

Hi Doug.  Thanks for your input.  Since you have Operations Manager and Service Monitor, there's a few ideas I can pass along to you which should help.

Regarding checking server process status, if a process is stopped, Operations Manager will immediately alarm you. If a process is still running but hung or not functional,  there are some further diagnostic tests within Operations Manager that can help with in-process status. For example, you can setup a tftp download test to run every minute or so and if tftp download fails, then an alert would be generated.  This is a quick-and-dirty way to catch hung processes.

For your second point, Operations Manager can manage phones via http. Those port tx/rcv error statistics are also displayed in the phone web page which are launchable from the Operations Manager phone report.  Phone Load Report is where phone load information under is attained under phone reports. Note that, by default, phone load information is not shown in the phone report but this can be achieved by modifying (add) the fields “Load ID” under All IP Phones/Lines Report.

Regarding voice quality, you don't mention if you're using CVTQ. CVTQ within Service Monitor can provide MOS for every call.  This is captured at the end of the call but you don't need to deploy any hardware for those statistics.

Let me know if this helps some.

Take care and thanks again for your input,

Mark.