02-28-2007 03:20 AM - edited 03-14-2019 08:15 PM
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?
02-28-2007 07:53 AM
Since, in MGCP, the D-channel is controlled by CallManager, I'd verify that your IP connectivity between the gateway and CallManager is not an issue. Perform a couple 10,000 PING sweeps and see if you're dropping any.
02-28-2007 12:53 PM
Thanks for the advice but the PING sweeps came back clean as a whistle.
Regards
02-28-2007 01:00 PM
If you have mgcp bind commands in the configuration, try removing them.
Brandon
02-28-2007 05:40 PM
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.
02-28-2007 10:11 PM
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
03-01-2007 05:53 PM
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
service-policy MARK-ROUTING-PROTOCOLS
class class-default
bandwidth remaining percent 60
random-detect
set ip dscp default
ip access-list extended VOIP_acl
remark the address range reserved for VoIP
deny tcp 10.x.0.0 0.3.255.255 10.x.0.0 0.3.255.255 eq 137
deny tcp 10.x.0.0 0.3.255.255 10.x.0.0 0.3.255.255 eq 138
deny tcp 10.x.0.0 0.3.255.255 10.x.0.0 0.3.255.255 eq 139
deny tcp 10.x.0.0 0.3.255.255 10.x.0.0 0.3.255.255 eq 445
deny udp 10.x.0.0 0.3.255.255 10.x.0.0 0.3.255.255 eq netbios-ns
deny udp 10.x.0.0 0.3.255.255 10.x.0.0 0.3.255.255 eq netbios-dgm
deny udp 10.x.0.0 0.3.255.255 10.x.0.0 0.3.255.255 eq netbios-ss
deny udp 10.x.0.0 0.3.255.255 10.x.0.0 0.3.255.255 eq 445
deny udp 10.x.0.0 0.3.255.255 10.x.0.0 0.3.255.255 eq tftp
permit ip 10.x.0.0 0.3.255.255 10.x.0.0 0.3.255.255
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
Queueing
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
(Truncated)
Class-map: class-default (match-any)
3639816 packets, 694952111 bytes
5 minute offered rate 22000 bps, drop rate 0 bps
Match: any
Queueing
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
03-04-2007 12:47 PM
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 :-
Serial0/0/0
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
Queueing
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
Queueing
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 ?
03-04-2007 02:05 PM
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?
03-04-2007 02:34 PM
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.
03-04-2007 09:25 PM
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.
Example:
policy-map voip
class signalling
bandwidth 32
queue-limit 256 (default is 64 packets)
HTH, Erick
03-05-2007 07:22 AM
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,
Paul.
03-09-2007 06:29 PM
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?
03-09-2007 08:57 PM
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.
Brandon
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide