Posted on March 11, 2020 5:37 pm
 |  Asked by Jeffrey Preston
 |  152 views
RESOLVED
0
0
Print Friendly, PDF & Email

I have some questions concerning QoS implementations on the Arista 7504N.   We are using line cards with Jericho chips (7500R’s).  I have rarely ever dealt with QoS configurations on any platform, and have toiled away creating MPLS circuits, and have been oblivious to QoS in general until now.   I have the concepts down for QoS, but when it comes to implementing them under EOS, I get lost quickly.

I would like to keep the QoS marking mechanism in the SVI (if possible), which I assume is the VLAN interface, which holds the Layer-3 gateway IP’s.   On the router we are retiring, it handles QoS with ACL’s only, and then you simply apply the ACL to the Layer-3 virtual interface in the configuration.   The ACL’s available in EOS do not have any QoS options available, so I am stuck.  The documentation is not helpful, as I need a more complete picture, using all the various elements put together, in order to come up with the correct configuration.

For example, if I have multiple VOICE and VIDEO VLAN’s, that I want to classify traffic on, what policy-map’s, class-map’s, or ACL’s would I need to give VOICE a COS of 5 and DSCP of 40, and VIDEO a COS of 4 and DSCP of 32?

vlan 1001

name VOIP_TOWN1

 

vlan 1003

name VOIP_TOWN2

 

vlan 1222

name IPTV_TOWN1

 

vlan 1224

name IPTV_TOWN2

 

interface vlan1001

description VOIP_TOWN1

vrf forwarding TABLE_ONE

ip ospf area 2

ip address 10.111.7.254/21

ip helper-address 10.250.1.1

 

interface vlan1003

description VOIP_TOWN1

vrf forwarding TABLE_ONE

ip ospf area 2

ip address 10.113.7.254/21

ip helper-address 10.250.1.1

 

interface vlan1222

description IPTV_TOWN1

vrf forwarding TABLE_ONE

ip address 10.150.7.254/21

ip helper-address 10.250.10.1

 

interface vlan1224

description IPTV_TOWN1

vrf forwarding TABLE_ONE

ip address 10.151.7.254/21

ip helper-address 10.250.10.1

 

I assume I need a policy-map to set the COS and DSCP values in, and then apply that policy to the SVI using the service-policy option.  For example…

 

policy-map type qos VOICE

class VOICE

set dscp 40

set traffic-class 5

policy-map type qos IPTV

class IPTV

set dscp 32

set traffic-class 4

 

interface vlan 1001

service-policy type qos input VOICE

interface vlan 1003

service-policy type qos input VOICE

interface vlan 1222

service-policy type qos input IPTV

interface vlan 1224

service-policy type qos input IPTV

 

Since that should take care of ingress traffic into the SVI’s, then all I should need is to mark it on egress on the trunk ports facing our optical transport network.   I know I can use the qos command on the physical interface to set the default value for COS or DSCP, as long as it is an access port.   But I am not sure how to handle a trunk port.

Am I on the right track here?   How do I handle egress marking for trunk ports?

Thank you for your advice.

 

0
Posted by Kenneth Finnegan
Answered on March 11, 2020 7:17 pm

Howdy Jeffrey,

I think you're close, so let's see if I can clear some things up for you!

You first need to create class maps to somehow match on the traffic you're interested in, so that's an ACL and class-map per traffic type:

ip access-list acl-voice
10 permit SOMEHOW_MATCH_ON_VOICE_TRAFFIC
!
ip access-list acl-video
10 permit SOMEHOW_MATCH_ON_VIDEO_TRAFFIC
!
class-map type qos match-any cmap-voice
match ip access-group acl-voice
!
class-map type qos match-any cmap-video
match ip access-group acl-video

Then you'll use those to form a policy-map to set dscp/cos/traffic-class based on those class maps:

policy-map type quality-of-service pmap-demo1
class cmap-voice
set dscp cs5
set traffic-class 5
!
class cmap-video
set dscp cs4
set traffic-class 4
!
class class-default
set dscp 0
set traffic-class 1

(Note that this example is a little over-simplified, since it doesn't put your network control traffic in CS6 above anything else, so high congestion might cause you some problems like your routing flapping)

For each of the class maps, remember that the traffic-class is local to this switch, so that specifies how it handles the packet on egress, cos is included on L2 trunks, so that specifies how other L2 switches in this segment handle the packets on their egress, and dscp can cross L3 boundaries, so that will follow the packet all the way through your network.

By assigning a traffic-class in the policy map on ingress, the switch then uses the traffic-class to tx-queue map on egress to decide which transmit queue to place the packets in. The default map is pretty sane, with tc0-7 being mapped to tx-queue 0-7:

SWITCH#show qos maps
[... SNIP ...]
Tc - tx-queue map:
tc: 0 1 2 3 4 5 6 7
---------------------------------
tx-queue: 0 1 2 3 4 5 6 7

Remarking on egress would use the tc-cos/tc-dscp maps, and would be for if you wanted to trust the cos/dscp on some ingress interface, then wanted to modify the packet on egress based on which traffic class that ingress map put them in, which I don't think is quite what you're looking for here.

The default tx-queue configuration is that each tx-queue has strict and unlimited priority over the queues below them, which may or may not be what you want, so you might want to reconfigure the tx-queue configuration on your egress interfaces. You can also collect the service-policy and tx-queue into a qos profile which you can then apply to every interface to prevent duplicating a lot of configuration per interface. This example sets tx-queues 0-3 to round-robin, and limits tx-queue 4 to 10% of the bandwidth and tx-queue 5 to 2%, because I'm making the assumption that if VoIP is using more than 2% of the bandwidth, something has gone wrong somewhere with my clafficiation. Your specifics will likely vary.

qos profile qprof-demo1
service-policy type qos input pmap-demo1
!
tx-queue 3
no priority
tx-queue 4
shape rate 10 percent
tx-queue 5
shape rate 2 percent

As for applying qos profiles on SVIs vs physical interfaces, I think there's some limitations on what you can do on SVIs, and you'll want to assign tx-queue config on the actual physical interfaces, and mixing the two can have some undefined behavior, so you might have more success applying all the qos policies per physical interface? Definitely depends on the specifics of your deployment.

To add to Kenneth's point on SVIs, that's true, we really want to stick to the physical interfaces. If this switch is your trust boundary, you would want to put your service-policy on all physical interfaces that could see this traffic. They can be switchports or routed ports, so don't worry about the SVI at all - however, you need to think about how to identify this traffic, is it the whole subnet? If so, then you would make an ACL for each network, however that may be a bit broad -- perhaps L4 port numbers? QoS service-policies are only allowed on ingress, as such there's no need to have an outbound policy. As Kenneth mentions, the traffic-class derives the behavior and is customized on each egress interface -- optionally made cleaner by use of the qos profile. One note here though, the tx-queue configuration is actually applied to the egress interface, and service-policy (doing the matching/marking/classification) is applied on the ingress interface. So if one were to use a qos profile for organization, we would probably use it only on the egress, while on the ingress just use the service-policy. I say that because because it's a one-liner, but could of course still be applied via a qos profile. Regards, John
(John Gill at March 13, 2020 4:54 am)

Post your Answer

You must be logged in to post an answer.