CCM 4.2(3) with MGCP G/W Serial Interface Flapping

Unanswered Question
Feb 28th, 2007

CCM 4.2(3) --- 2821 MGCP --- Fragmented E1.

ISDN status keeps dropping from Multiple Frame Established to TEI-Assigned. There are no errors on the controller or D-channel. When configured for H.323 the line stays solid!!

Any thoughts?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
dezoconnor Wed, 02/28/2007 - 12:53

Thanks for the advice but the PING sweeps came back clean as a whistle.


Jeff Garner Wed, 02/28/2007 - 17:40

We have this issue with 4 sites CCM 4.23 and CCM 4.13 all on 2851 routers.

I'm leaning towards an IOS bug. but TAC keeps pinning it on our WAN provider?

When we bind MGCP control to the interface that marks its packets for QOS EF, we start dropping packets in the QOS bucket.

All other QOS packets (media and phone control) are fine). As soon as I bind MGCP to another interface and thus no longer mark its packets for EF,

The MGCP gateways will stop bouncing between CCM publisher and CCM subscriber and thus Layer 2 will come up..

Another avenue Im going to look into is why we are shoving all voice into EF.

Erick Bergquist Wed, 02/28/2007 - 22:11

Can you post your QoS config?

You need to find out why MGCP control is being marked EF and if thats the way they want it, adjust the policy so it's got the bandwidth.

One thing to pay attention is the QoS policy queue-depth setting. The default is 64 packets and I had a client with a similar issue where the control class did not have enough bandwidth and queue depth was default and on the initial registration of MGCP endpoints, there was not enough bandwidth for all the packets so they did not register. But once the endpoints were registered (removed qos, changed mgcp interface, etc) it worked fine because mgcp traffic was less then.

Hope this helps, Erick

Jeff Garner Thu, 03/01/2007 - 17:53

Thanks for the help...

The sites have a 1.45m link (and one with a 4m link) All sites have a 256K CIR

The company has a set config we are supposed to use.

class-map match-all RealTime

description class used for VoIP

match access-group name VOIP_acl

class-map match-all BurstyLo

description **For Future use ONLY**

match ip dscp af21

class-map match-any BurstyHi

description Multicast and other [UDP]

approved applications

match access-group name IPWAN_MULTICAST_ACL

match access-group name VTC-Codecs_acl

class-map match-any ROUTING-PROTOCOLS

description prepare to separate BGP & EIGRP in BurstyHi

match protocol bgp

match protocol eigrp

policy-map IPWAN-COS

description RT bw assigned legacy from VTC

class RealTime

priority 204

set ip dscp ef

class BurstyHi

bandwidth remaining percent 40

set ip dscp af31


class class-default

bandwidth remaining percent 60


set ip dscp default

ip access-list extended VOIP_acl

remark the address range reserved for VoIP

deny tcp 10.x.0.0 10.x.0.0 eq 137

deny tcp 10.x.0.0 10.x.0.0 eq 138

deny tcp 10.x.0.0 10.x.0.0 eq 139

deny tcp 10.x.0.0 10.x.0.0 eq 445

deny udp 10.x.0.0 10.x.0.0 eq netbios-ns

deny udp 10.x.0.0 10.x.0.0 eq netbios-dgm

deny udp 10.x.0.0 10.x.0.0 eq netbios-ss

deny udp 10.x.0.0 10.x.0.0 eq 445

deny udp 10.x.0.0 10.x.0.0 eq tftp

permit ip 10.x.0.0 10.x.0.0

So basically all phones, gateways (via MGCP BIND) and CCMs Unity go into the 10.x.0.0 IP range.

Here is a show policy map int... When we bind MGCP to the 10.x.x.x interface I start seeing drops

Class-map: RealTime (match-all)

500816 packets, 27359555 bytes

5 minute offered rate 1000 bps, drop rate 0 bps

Match: access-group name VOIP_acl


Strict Priority

Output Queue: Conversation 264

Bandwidth 204 (kbps) Burst 5100 (Bytes)

(pkts matched/bytes matched) 22712/1212472

(total drops/bytes drops) 0/0

QoS Set

dscp ef

Packets marked 500816


Class-map: class-default (match-any)

3639816 packets, 694952111 bytes

5 minute offered rate 22000 bps, drop rate 0 bps

Match: any


Output Queue: Conversation 266

Bandwidth remaining 60 (%)

(pkts matched/bytes matched) 330399/143581213

(depth/total drops/no-buffer drops) 0/160/0

exponential weight: 9

mean queue depth: 0

Where do you set the Queue Depth

pcobley Sun, 03/04/2007 - 12:47

We temporarily resolved this issue by removing the QoS policy from the interface.

However, altough we reserved a generous 100kbps for signalling - the interface shows a 5min offered rate of 17kbps but still we dropped around a third of mgcp packets.

Our QoS policy is this :-

policy-map CE-Egress-Edge

class Voice-Bearer

priority 550

class Voice-Signalling

priority 100

set ip dscp ef

And this is the effect on the interface :-


Service-policy output: CE-Egress-Edge

Class-map: voice-stream (match-all)

3021046 packets, 192581215 bytes

5 minute offered rate 0 bps, drop rate 0 bps

Match: access-group name voip-stream


Strict Priority

Output Queue: Conversation 264

Bandwidth 550 (kbps) Burst 13750 (Bytes)

(pkts matched/bytes matched) 647798/46781113

(total drops/bytes drops) 0/0

Class-map: voip-signal (match-any)

466351 packets, 77541961 bytes

5 minute offered rate 17000 bps, drop rate 5000 bps

Match: access-group name voip-signal

466351 packets, 77541961 bytes

5 minute rate 17000 bps


Strict Priority

Output Queue: Conversation 264

Bandwidth 100 (kbps) Burst 2500 (Bytes)

(pkts matched/bytes matched) 98206/38652500

(total drops/bytes drops) 25373/18446591

QoS Set

dscp ef

Packets marked 466351

Class-map: class-default (match-any)

34948573 packets, 21772951146 bytes

5 minute offered rate 447000 bps, drop rate 0 bps

Match: any

So, given the 100kbps for signalling why are we dropping packets ?

Jeff Garner Sun, 03/04/2007 - 14:05

pcobley What router are you using and what IOS version?

We are giving 256k for both voice and signaling and we are dropping even when there is NO voice traffic on the line. I'd be curious if you gave your full 550K and tested when there was no voice traffic if it would still drop.

I have another site with a 384K CIR and a 3845 router that does not drop..

Perhaps this is a bug with the 2800 IOS

Its good to know Im not along? I was beginning to think it was me?

pcobley Sun, 03/04/2007 - 14:34

We're using 12.4(12) on an 1841.

The customer has 650k for priority traffic on their MPLS backbone, so as per SRND we just mark signalling to ef and send it to the wire along with voice bearer.

You will notice from the service policy counters that we are dropping signalling packets even though we are not sending any bearer - same as you.

Erick Bergquist Sun, 03/04/2007 - 21:25

Why are you marking signaling as ef? Also, the control class is set as priority in your config.

I have also found it helpful sometimes, to do a NBAR like match instead of on DSCP values. Like, match protocol rtp audio, etc where you don't have control of traffic end to end and aren't 100% sure something else isn't ef, etc.

Bottom line is your dropping on that class, and what I was trying to explain earlier when MGCP first registers the endpoints and comes up, etc there is lots of traffic. After MGCP and the endpoints are registered, etc the amount of traffic will die down but it depends on amount of calls, MGCP activity. I have had to use the queue-limit command under the policy-map class configuration at some sites with lots of endpoints due to this to get them to register and stay stable. The default queue depth is 64 packets. You can have all the bandwidth in the world, but if you have more then 64 packets packets will start dropping by default.


policy-map voip

class signalling

bandwidth 32

queue-limit 256 (default is 64 packets)

HTH, Erick

pcobley Mon, 03/05/2007 - 07:22

Thanks Erick.

We mark signalling as EF because we only have 2 classes on the MPLS - best effort & class 1. The telco matches dscp=EF for class 1.

Since we have 650k class 1 we put signalling in with the voice - we break it back out to cs3 on ingress.

This is a 2Mb tail so I don't see the problem with having 2 x priority queues with a combined bandwidth of 650k (it's around the 33% max recommended in the SRND).

I will try the queue-limit comand though.

Thanks for your help,


Jeff Garner Fri, 03/09/2007 - 18:29

FYI I made a change to mark MGCP Control traffic as AF31 instead of marking it EF and without increasing the queue limit. The packets no longer dropped and everything seems to be fine now?

Brandon Buffin Fri, 03/09/2007 - 20:57

One thing to be aware of is that the standard for control traffic is now CS3 instead of AF31. Cisco is moving to CS3 on all of its voice products. For example, Callmanger 4 and above marks signaling traffic as CS3. Not all products have been migrated, but that is the direction they're heading.



This Discussion