beardhwc
asked on
HP ProCurve and tagging
I have a network of 400 users connected through a MPLS. Our two datacenters have switches and routers but the branch offices connected to the MPLS do not. Instead of routers at the branches our MPLS provider had us install their Overture bridges at each facility. The MPLS provider effectively handles the routing at their NOCs. Branch facilities have Layer-2 HP ProCurve switches of model 2520, 2530, and 2610 with the latter being the most common.
I want to tag both Voice (UDP/RTP) and Signaling (TCP) traffic for EF (46). Our MPLS provider categories everything into two planes: Normal and Priority. Packets with the EF tag get placed in the Priority plane. Right now, all packets (both Voice and Signaling) from the phone servers are tagged for EF, so that is being prioritized properly. Voice (UDP/RTP) coming from the phones is being marked EF but not Signaling (TCP). As a result, users are experiencing issues with phones continuing to ring after they have picked up the handset or simply just trying to get dial-tone. My MPLS provider says the cause of these issues is Signaling not being tagged as EF, so I need to get this implemented. I do have a Cisco Catalyst 2960 at the facility where the phone server is but this is only a Layer 2 switch.
Network Diagram
PC >> Phone >> ProCurve 2610 >> Bridge >> *** MPLS *** << Bridge << Router << Catalyst 2960 << Avaya Phone Server
I know not everyone marks there Signaling and Voice at the same priority but this what I need to accomplish to get it to work with our MPLS provider. For us, everything that isn't related to phone use is relegated to a lower priority, so in that sense I have only two priority levels I am concerned with: phone and everything else. I have two VLANs. 50 is for Data and 200 is for Voice. PCs piggybback on the phones, so almost all switch ports are untagged on 50 and tagged on 200. Voice VLAN 200 is also configured with the voice command.
The following is a portion of a typical (for us) ProCurve 2610 switch config. In this my goal is to mark all VLAN 200 traffic as EF but it still is not marking the Signaling (TCP) traffic.
I know the TCP and UDP ports this traffic sits on so I could instead try:
But if this works then I'll have other problems because any traffic on VLAN 50 for the PC connected to the phone that uses these TCP and UDP ports will be inappropriately prioritized in the Priority plane with Voice.
Finally, when reading up on QoS it seems that my branch switches that uplink to the bridge must have that port set to tagged or else the QoS marking will be stripped. My switch ports used for uplink to the bridge must be set to untagged. When I set them to tagged it stops all traffic between that bridge port and that switch port.
Kinda lost here as to what to do next. Any ideas?
I want to tag both Voice (UDP/RTP) and Signaling (TCP) traffic for EF (46). Our MPLS provider categories everything into two planes: Normal and Priority. Packets with the EF tag get placed in the Priority plane. Right now, all packets (both Voice and Signaling) from the phone servers are tagged for EF, so that is being prioritized properly. Voice (UDP/RTP) coming from the phones is being marked EF but not Signaling (TCP). As a result, users are experiencing issues with phones continuing to ring after they have picked up the handset or simply just trying to get dial-tone. My MPLS provider says the cause of these issues is Signaling not being tagged as EF, so I need to get this implemented. I do have a Cisco Catalyst 2960 at the facility where the phone server is but this is only a Layer 2 switch.
Network Diagram
PC >> Phone >> ProCurve 2610 >> Bridge >> *** MPLS *** << Bridge << Router << Catalyst 2960 << Avaya Phone Server
I know not everyone marks there Signaling and Voice at the same priority but this what I need to accomplish to get it to work with our MPLS provider. For us, everything that isn't related to phone use is relegated to a lower priority, so in that sense I have only two priority levels I am concerned with: phone and everything else. I have two VLANs. 50 is for Data and 200 is for Voice. PCs piggybback on the phones, so almost all switch ports are untagged on 50 and tagged on 200. Voice VLAN 200 is also configured with the voice command.
The following is a portion of a typical (for us) ProCurve 2610 switch config. In this my goal is to mark all VLAN 200 traffic as EF but it still is not marking the Signaling (TCP) traffic.
qos type-of-service diff-services
qos dscp-map 101110 priority 7
qos device-priority 172.20.2.120 dscp 101110
qos device-priority 10.1.200.2 dscp 101110
vlan 200 voice
vlan 200 qos dscp 101110
qos dscp-map 101110 priority 7
qos device-priority 172.20.2.120 dscp 101110
qos device-priority 10.1.200.2 dscp 101110
vlan 200 voice
vlan 200 qos dscp 101110
I know the TCP and UDP ports this traffic sits on so I could instead try:
qos type-of-service diff-services
qos dscp-map 101110 priority 7
qos tcp-port 1720 dscp 101110
qos udp-port range 49152 53246 dscp 101110
qos dscp-map 101110 priority 7
qos tcp-port 1720 dscp 101110
qos udp-port range 49152 53246 dscp 101110
But if this works then I'll have other problems because any traffic on VLAN 50 for the PC connected to the phone that uses these TCP and UDP ports will be inappropriately prioritized in the Priority plane with Voice.
Finally, when reading up on QoS it seems that my branch switches that uplink to the bridge must have that port set to tagged or else the QoS marking will be stripped. My switch ports used for uplink to the bridge must be set to untagged. When I set them to tagged it stops all traffic between that bridge port and that switch port.
Kinda lost here as to what to do next. Any ideas?
I am not really much into HP. But you should assign QoS markings to one of no-override values - not to already existing ones. Detailed explanation on subject - Quality of Service (QoS): Managing Bandwidth More Effectively on the Series 2600/2600-PWR and Series 2800 Switches
You need also to configure QoS on catalyst switch and instruct it trust cos and/or dscp markings otherwise it will overwrite dscp or cos values in packets. You need to mark ports as trusted ports.
You need also to configure QoS on catalyst switch and instruct it trust cos and/or dscp markings otherwise it will overwrite dscp or cos values in packets. You need to mark ports as trusted ports.
ASKER
After running some more packet captures this is what I see:
* Signaling packets are not being marked as EF (like i want) at the phone even though the Avaya server is configured to make both Voice and Signaling as EF.
* Voice AND Signaling packets are being marked as EF when I run a packet capture on the switch's uplink to the bridge. This means our switches are properly adding the DSCP value of EF where appropriate. (Again, our branches have managed Layer-2 switches but no on-site routers)
* My MPLS provider's packet captures show Signaling packets are not marked as EF.
This leaves me thinking either:
the DSCP value of EF on Signaling is being stripped from the packets in the uplink to the bridge OR
the DSCP value of EF on Signaling is being stripped somewhere else at our MPLS provider.
Our switch's uplink to the MIB must be untagged or else the connection is lost, leaving me to wonder if implementation of on-site routers is ultimately necessary.
Again, for better or worse, our MPLS provider wants both Voice and Signaling marked as EF. Particularly when we see high traffic on our circuits we have reports of phone issues related to signaling (phone continues ringing after being answered; dial-tone is slow to arrive)
* Signaling packets are not being marked as EF (like i want) at the phone even though the Avaya server is configured to make both Voice and Signaling as EF.
* Voice AND Signaling packets are being marked as EF when I run a packet capture on the switch's uplink to the bridge. This means our switches are properly adding the DSCP value of EF where appropriate. (Again, our branches have managed Layer-2 switches but no on-site routers)
* My MPLS provider's packet captures show Signaling packets are not marked as EF.
This leaves me thinking either:
the DSCP value of EF on Signaling is being stripped from the packets in the uplink to the bridge OR
the DSCP value of EF on Signaling is being stripped somewhere else at our MPLS provider.
Our switch's uplink to the MIB must be untagged or else the connection is lost, leaving me to wonder if implementation of on-site routers is ultimately necessary.
Again, for better or worse, our MPLS provider wants both Voice and Signaling marked as EF. Particularly when we see high traffic on our circuits we have reports of phone issues related to signaling (phone continues ringing after being answered; dial-tone is slow to arrive)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks for clarifying that DSCP is not 802.1P. I am definitely using DSCP to marked traffic as EF and my own packet captures confirm this. It is my MPLS provider that has had trouble seeing them although some packet captures they made this morning now show all traffic properly marked as EF. I am going to close this ticket now. Thanks so much for the input.
The mapping you mean is about the difference in priority systems and how to interpret. (Qos vs. Diffserv and how you want things to be handled)
The Signaling might not be EF, but will be an Lowlatency class so you may be able to map that low latency class mapped to the same priority a EF. Signaling is mostly CS3 (defaults on many systems), so if you can map that in the same priority as EF that may help.
Try to manage the phone first...