cancel
Showing results for 
Search instead for 
Did you mean: 

QOS for telephony in a HiPath controller to controller network

QOS for telephony in a HiPath controller to controller network

BigRic
New Contributor III

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).

06f1f0f69d8e4bf09867f91ebe95afbd_0e5df0e5-2e2e-4401-85bc-3ddb519097a3.png

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

2 REPLIES 2

Holger_Gmerek
New Contributor III

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

  • Configure the qosprofile in which a particular port or VLAN will be handled on ingress if the traffic is not set to ingress with a value already set.
    • configure ports <PORT_LIST> qosprofile <QOSPROFILE>
    • configure vlan <VLAN_NAME> qosprofile <QOSPROFILE>

BigRic
New Contributor III

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

GTM-P2G8KFN