cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
223
Views
0
Helpful
2
Replies

Initial Thoughts on TB Trial Feedback

mawachi
Cisco Employee
Cisco Employee

The product was very easy to install and the setup was very straight forward.  It has done a good job of discovering many of the networking devices, both Cisco Small Business as well as other networking devices that I've had on my network.  Having used the product now for a couple of weeks here is some constructive feedback for the team:

Some of the Bandwidth Errors are being caused by Jitter thresholds that are set too low in my opinion.   Max thresholds seem to be less than 250ms round trip (so 220ms seems to be right from my Nortel days), 150ms max for Latency is what the ITU suggests and less than 100ms for jitter.

I don’t believe it is productive to turn this into a debate around what the defaults should be.  My comment here is that some of defaults seem kind of low.  My suggestion would be to have the CA teams and support centers comment on what the defaults values for Bandwidth, Latency, Jitter, etc are – since they will be the ones potentially taking calls from partners on this.  Having too low a value could increase support calls to the center and/or create perceived product quality issues that me be a result of network activity or the ISP.

Another suggestion that I would make is to consider having part of the device setup process be to confirm with the VAR what the default thresholds are and/or allowing them to load a custom monitoring configuration so that device does not seem to be “crying wolf” all of the time.

A future road map item for the device that will require information either from the router or live in the router- is the correlate the Band Mon alerts with actual WAN network activity, so that from a CA and/or VAR support perspective we are not trouble shooting device problems that may actually be WAN network related or have to do with business traffic patterns.

Another future road map items would be to setup some kind of scheduling of when the alerts could be disabled, even cooler if we could tie it to a master scheduling function in the portal. So for example if we have Mozy enabled on our NAS, and we are scheduling an offsite data backup, I would assume that the WAN network could be impacted negatively, it would be nice if we could take into account this type of activity.  Likewise if a IP video camera detects and event and starts capturing and streaming video, that could also impact the network and create additional trouble shooting headaches for the VAR/CA teams to explain the alerts TB is sending out.

Last suggestion is that it would be more helpful to see more trending reports over time around latency, jitter, bandwidth than a particular alert.  This would help to eliminate false alarms if there is momentary network disruption, vs a service outage.

All in all it I think the work the team has done is really good and it impressive.

2 Replies 2

Michael Holloway
Cisco Employee
Cisco Employee

Thanks for the feedback Marty. I completely agree on the raising the default jitter threshold, and that we eventually need to offer some sort of template for the VAR to adjust default thresholds across all of their customers and monitors. The current bandwidth default thresholds are quite arbitrary, honestly I was just waiting to see who complained. IIRC,125ms is the upper threshold of tolerable jitter during voice calls. I'll raise the defaults from 10ms warning and 20ms critical up to 80ms and 100ms so that we don't cry wolf on this monitor. This bandwidth test really needs to be converted to IP-SLA in the future anyway, or at least have options for setting ToS/DSCP bits so that any QoS at the location can be applied to the packets to better simulate them as voice or data.

I also like the idea of scheduling outages or service-affecting windows to prevent unnecessary notifications from being sent. I'm sure that the marketing folks are taking note of this feature request.

One other suggestion for the team to consider - to help our CA team as well as our partners to help make sense of the telemetry and alerts that we are providing, I would suggest the we divide the alarms from WAN centric alarms vs LAN centric alarms.  If CA and the partner can emilimate the problem causing the alert is from the WAN, not the the LAN, then we can eliminate our products as the source of the problem and eliminate unnecessary calls to the TAC.  So we probably need to have a heart/beat monitor between the TB device and the local gateway, as well as the current heart/beat monitor between TB and PSP data center.  We should be able to then do some math to figure out the Jitter and Latency from the LAN side as well as the WAN side.