Fixed issue with no-way voice across QSIG E1 trunk and 2800 Series router

Very strange this one.

We have multiple customers running SP Services 12.4-15T12 and we appeared to hit an intermittent bug with a particular customer. This customer has a 2800 series router with 2x E1 links to a PBX using QSIG. The symptoms are that occasionally you get no-way voice across the trunk to the PBX, when the call originates from either direction. I've been running 12.4-24T3 for a few days now and the issue doesn't appear to have occurred again.

Here is the response from TAC:

It can happen on any gateway that is using c5510 DSPs (PVDM2-x where x=
8 or 16 or 32 or 64) using IOS 124-15T10 through 124-15T13 (dsp version
9.4.9 through 9.4.12).

My suggestion would be to keep an eye on it cause the bug does not happen *all* the time, it is a intermittent and random issue where you will start experiencing random one-way or no-way or complete dead air calls. You can open a TAC case at that point and get the DSP firmware from the fix.

So to clarify:
Once the issue is encountered and you want to stay on 124-15T train until 124-15T14 is released on CCO, you will have to:

load 1240-15T13 IOS image PLUS also contact TAC and get the DSP firmware version (which will eventually be bundled in 124-15T14). The bug id you can reference is CSCtf25886.

Fixed issue with ICMP packets not reaching OpManager probe

Came across a problem today and was fixed with help from Simon. A WAN CPE router was still reachable via SSH, but OpManager kept reporting it down due to polls failing. This turned out to be because a scheduled server backup was absorbing 100% of the 512k bandwidth.

A QoS policy existed already for voice, but attempts to match traffic that were heading to the SNMP server (IE the polls) using a class-map/access-list combo didn't calm the symptoms.

The main reason is that the ICMP packets are generated by the router so it's difficult to mark this traffic (unlike traffic that is passing through the router, like typical voice traffic).

Fixed the issue using ip local policy, with an access list and a Route Map:

----------------
ip local policy route-map set-dscp-icmp

ip access-list extended OPMANAGER
permit ip any host 10.1.1.1


route-map set-dscp-local permit 10

match ip address OPMANAGER

set ip precedence 5
set ip dscp ef
-----------------