Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
New Member

VoIP Latency when in-line on 4255

We are experiencing an issue with latency when we place our remote office traffic in-line using a 4255.  The latency is impacting our VoIP traffic and causing voice quality issues.  The problem goes away if the 4255 is (physically) bypassed.

From looking at packet captures, the traffic through the interface pairs does not seem excessive and is well below the 600Mbs the appliance is rated for.

Are there any settings on the the device or signatures that I should look at tuning to help reduce the latency?

Thanks in advance.



Re: VoIP Latency when in-line on 4255

Hi David,

   The first thing I would suggest doing is browsing  through the recent events from the sensor for any which may have been  triggered by traffic coming from addresses in use by your VoIP system.   In the absence of any relevant events, you can create an Event Action  Override for Risk Rating 0-100 to add the Produce Alert action, setup a  few more calls and then check the event store again.  The EAO will cause  all signatures, even those without the Produce Alert action configured  by default, to log events to the event store. When you're done testing,  disable the EAO to prevent wasting resources on the sensor.

If you still don't see any events, it's possible that  the sensor is oversubscribed despite the fact that your capture may  appear to be well under the 600Mb documented for that model.  The 600Mb  metric is measured using a sensor with completely default signature sets  and transfering "media rich" traffic (i.e. a lower number of higher  volume streams), while in promiscuous mode.  The "transactional" rating  is 500Mb, under the same conditions.  Voice is generally considered  "transactional" traffic.  When deploying a sensor inline, a very rough  estimate is to shave 20% off the expected performance, so you'd end up  with 400Mb in this case.  This would be the theoretical maximum of the  aggregate traffic in both directions.  If you start altering the default  signatures that Cisco provides the performance can begin to drop off  rapidly depending on the complexity and number of signatures you tune..

If,  after double check in the signatures firing, defaulting the signature  set and checking the traffic rate (which should be monitored at peak  times, or at least those during which you are consistently experiencing  the problem) you are still unable to explain the degredation, it may be  worth it to open a TAC case.

Best Regards,

CreatePlease to create content