03-10-2020 07:55 PM
We typically deploy our switches with LLDP MED configured to advertise DSCP 46 markings as the suggested value to network connected phones, etc. We follow the design example set in one of the old reference architectures and it seems to work pretty well (we set QP5, disable DOT1P, add DSCP 46 marked items to the priority queue, etc.).
We are not “voice guys” per se… Today, a voice engineer for whom we’re deploying a transit vlan between two campuses (1gb handoff in each campus routed via their respective switches into a 10gb fiber trunk between). With the bandwidth at our disposal, I don’t expect to run into an issue but I am curious as to the proper setup. The engineer wanted us to protect the signaling traffic between voice controllers/switches against being policied by the class of service inspection being done. The LLDP MED stuff does not apply, as these are not phones but the switch shelves themselves communicating between one another (not SIP, HiPath-specific as I understand it).
He’d mentioned putting higher priority on this signaling traffic and I’m wondering what the best way to do this is? It sounds like we can identify specific ports on the source/destination so is it as easy as classifying this traffic with a lower DSCP value manually based on those ports and dumping them into a slightly higher priority queue?
The example he shared was using AF1/CS3 (Cisco nomenclature) which appears to just be a lower DSCP value of 26 for the signaling traffic. In our case it would then be to classify signaling in a higher priority queue, voice traffic in a slightly less priority queue and management in the normal priority queue).
To summarize: detect and apply DSCP marking to packets based on source/dest port and prioritize higher than voice. Prioritize voice using DSCP already marked by voice switch (or detect and apply as well), and let all other traffic pass without modification… Any sample / suggested configs you wouldn’t mind sharing?
The stations are all digital, minus a couple of SIP trunks they route internally over their own network to a couple of integrated devices (situational awareness, etc.).
Thanks in advance!
Eric
03-13-2020 09:45 PM
As per this Artikel GTAC QoS, just configure the profile and add the Ports or Vlan of the PBX
e.g. DSCP 46 → QP5; DSCP 24 → QP4
03-10-2020 11:14 PM
My research so far seems to show the following:
We need an ACL policy like this:
signaling_q.pol
entry QP6-ports {
if {
source-port xxx; or destination port yyyy
}
then
{
Qosprofile qp6;
replace-dscp;
}
We would apply this using “configure access-list signaling_q port xxx (where xxx is a HiPath port)
I’m thinking this will add the DSCP values to the control signaling traffic. I’m assuming that it won’t remove or overwrite other packets that already have been marked (like voice traffic)? Is it that straightforward? Do I need to implement any specific rate shaping or scheduling?
Thanks in advance!
Eric