cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
492
Views
0
Helpful
7
Replies

AF31 Header Packet in / Packet stripped going out

cposti01
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

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.

View solution in original post

7 Replies 7

cposti01
Level 1
Level 1

Here are 2 screenshots of Wireshark captures

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

These are our captures out our Router before they go over our MPLS WAN link to the SRST location.

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

the SRST router?

And yes, all policys are in place on Both ends... It seem this is not being placed by the Call manager.

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: