11-04-2008 01:39 PM - edited 03-15-2019 02:21 PM
I am having outgoing packets to a SRST gateway not labeled with AF31 header bytes. I am recieveing the packets with the header just fine. This is causing qos issues and call control dropping during high utilization.
Solved! Go to Solution.
11-04-2008 02:33 PM
The reason for the packets being re-written will be primarily because either the trust has not been configured on the appropriate ingress ports. Or if you are classifying based on ACLS, then possibly your ACLs are not matching correctly? Run 'show policy-map interface x/y' and see if packets are being matched for your signalling class?
From the packet capture it is traffic with the source address 172.22.32.16 which does not have the correct marking?
Therefore you will need to verify your QoS settings for the network path between where this endpoint is connected and where the packet capture was taken. Between these points the control traffic was obviously remarked.
If this host is your CallManager? then ensure the switchport is configured to trust DSCP as mentioned in a previous post and nothing else.
HTH
Allan.
11-04-2008 01:44 PM
11-04-2008 02:04 PM
Are your trust bundries set up properly? Are you trusting DSCP values on the GW link, as well as the WAN router link? Do you use policy-map on the router egress?
What's the WAN connection, if MPLS ensure the provider does not override these packets.
HTH,
Chris
11-04-2008 02:10 PM
These are our captures out our Router before they go over our MPLS WAN link to the SRST location.
11-04-2008 02:13 PM
Are these taken at the main site?
Are you trusting DSCP values on the CM uplink, with the follwoing command:
"mlq qos trust dscp"
Chris
11-04-2008 02:30 PM
the SRST router?
11-04-2008 02:26 PM
And yes, all policys are in place on Both ends... It seem this is not being placed by the Call manager.
11-04-2008 02:33 PM
The reason for the packets being re-written will be primarily because either the trust has not been configured on the appropriate ingress ports. Or if you are classifying based on ACLS, then possibly your ACLs are not matching correctly? Run 'show policy-map interface x/y' and see if packets are being matched for your signalling class?
From the packet capture it is traffic with the source address 172.22.32.16 which does not have the correct marking?
Therefore you will need to verify your QoS settings for the network path between where this endpoint is connected and where the packet capture was taken. Between these points the control traffic was obviously remarked.
If this host is your CallManager? then ensure the switchport is configured to trust DSCP as mentioned in a previous post and nothing else.
HTH
Allan.
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