Qos

[Jerome C.]

Hello

I would like to have your support. Currently, my company has a different location and  we are a subsidiary of a group. The group provide our WAN with OperatorA and we have in my company an OperatorB for telephony system (a SIP provided by OperatorB).

Currently, our QoS is based on dcsp tag and all voice communication is taggued as EF.

The group changes their QoS and ask me that my voice traffic must be new tagged as AF31. 

Is it possible, and how, I can do this type of approch :

- All traffic from my company TOIP network (10.10.10.0/24)  to OperatorB through the SIP gateway network (192.168.1.0/28), I change the dscp value from AF31 to EF (to apply the tag configured by OperatorB as the voice priority)

- All traffic from OperatorB through the SIP gateway network (192.168.1.0/28) to my ToIP network (10.10.10.0/24), I change the dscp value from EF (tag configured by OperatorB) to AF31 to be compliant with the QoS group for the Voice communication ?

Thank's for your support

BR

[mwood000111]

What hardware will this be set up on?  Also, what is the justification of downgrading the priority of this traffic?  Just did this for Webex to classify traffic to AF41 and move to priority queue.

1-Enable auto qos global compact

2-Create extended ACL for 10.x.x.x to 192.x.x.x

3-Create class-map that matches ACL

4-Create policy-map that matches class-map and then set dscp af31

5-At the source interface for the VoIP, add auto qos trust dscp

6-Run sh policy-map int x/x/x- First entry is for the service-policy input.  Youll have to remove that with no service-policy input (name of that policy, AutoQos-ppm-Trust-Dscp-Input-Policy)

7-Add to that interface service-policy input (name of your policy map)

That will then tag all your traffic, specified in that ACL, as  AF31 and you can confirm with a packet capture on the interface.  Throughout network, youll have to add auto qos trust dscp to each ingress/egress point, trunks mainly.  Last piece is at the edge when traffic is coming back in.  You can do something similar with the ACL but it will have to be the inverse, 192.x.x.x to 10.x.xx. so it will be tagged properly coming back in to network and then it will retain the correct tag to destination.  

[Joseph W. Doherty]

Logically at your demarcation point(s) between the two networks you can usually use QoS features to retag traffic. In your case, depending on direction, you remark EF to AF31 or the converse. Of course this assumes that all traffic with the EF or AF31 marking truly should be remarked to the other marking. If not, you could add additional analysis to insure the traffic with the EF or AF31 tag is the traffic you expect (i.e. VoIP packets). If not, you could not remark the packet or remark it to something else.

How to accomplish this physically depends on device.