Packet classification at the access level
I will try to continue the topic of the methodology and algorithm for the functioning of QoS in Cisco that I started. This article will describe what principles can be used to divide and label traffic at 2-3 levels of the OSI model in step-by-step examples. Who is interested in this question, please under the cat.
In the previous article, I described the Modular QoS CLI and cited as an example the block diagram of the functioning of the Cisco QoS algorithm, at the end of the article we will return to this block diagram. In order to be effective, QoS must be implemented across the entire network. It is best to classify traffic according to the principle “the sooner the better”, i.e. in our case at the access level. Frames and packages should be labeled using the following principles:
- Level 2 (CoS)
- Level 3 (IP Precedence / Differentiated Services Code Point)
CoS - sets priorities from 0 to 7. If the boundary device (IP phone or application) is able to set bits, then the network scheduler must decide whether to trust this device or not.
')
The default switch action is:
Do not trust the boundary device, on all frames that hit the switch, priorities will be reset to 0.
If the boundary device is allowed to be trusted, then the switch must be “warned” about the inviolability of this bit.
Depending on the switch model, you may first need to enable QoS - this is done with the mls qos command. Next on the interface indicates the trust for CoS, and the policy applied to the package, if it came without a corresponding bit. As a result, we obtain:
Also, if we want the switch to ignore the present CoS bit in the packet, we need to use the following combination of commands, as a result, the default QoS will be used:
It is not always possible to recognize the value of the CoS packet, since the devices are not always directly connected to the access level switch, it often happens that the client is plugged into the simplest uncontrolled switch that does not know the concept of priorities, unfortunately we will not be able to use IP ACL, because . we are not sure of the constancy of the client's IP address, here we will have to use the MAC ACL, it will look something like this.
We define the traffic flow, the class-map is used to define the traffic flow as a service class, in this case we called the service class ipphone:
We can check what we have created using the command: show class-map
Continuing to configure our rule, the next step is to define the QoS functions in the policy by assigning the DSCP value to the existing class:
We can check the results with the command: show policy-map
Below I want to give a summary table comparing the values ​​of our "magic field" for different types of determinants.
At this stage, the last action is to apply the policy to the interface in our case, we will apply this policy to all ports of our switch simultaneously:
And as usual, we check our result, for example, on the first port: show mls qos interface fa 0/1
As always, we summarize our actions at the end; if you paid attention to my previous article, you could not forget about the block diagram of links in the QoS policies, you can follow the commands below using this block diagram.
Now consider a slightly different version of the use of such classifiers for packages. This view is based on the definition of the protocol at the third level, but not without the help of the same ACL.
Consider an example of preventing the download channel FTP traffic, in your case - it can be anything, even the range of ports. We will label packets with a zero value, which will turn these packets into packets with the lowest priority, using both IP precedence and DSCP.
In this case, it will look something like this;
We approve a pre-planned traffic policy per group of interfaces:
We define the QoS functions in the policy, in this case it will be to add the value 0 to the dscp, ip cell of the packet.
Determine the traffic flow:
And the last condition necessary for the execution of all the above:
At the end of the article I want to remind once again about the block diagram that was shown in the previous article, if you write QoS policies, then keep it before your eyes, it will help you to navigate very easily and never get confused when drawing up the rules.
Thanks for attention.
PS On the advice of IlyaPodkopaev add some information about the concepts of trust and dscp-mutation
qos trust - In the context of interface configuration, this command is used to enable the trusted state of each port.
qos dscp-mutation — Applies the DSCP change map for the trusted DSCP port of the system (always overwrites the DSCP for this port).
Most often, the last command is used if the two domains have different dscp values, but we need some kind of mechanism to convert one DSCP to another. We specify the so-called mutations below by the specified commands:
Next should apply this "mutation" on the interface. Well, as always, after the work done, check with the command: show mls qos maps dscp-mutation.
In the previous article, I described the Modular QoS CLI and cited as an example the block diagram of the functioning of the Cisco QoS algorithm, at the end of the article we will return to this block diagram. In order to be effective, QoS must be implemented across the entire network. It is best to classify traffic according to the principle “the sooner the better”, i.e. in our case at the access level. Frames and packages should be labeled using the following principles:
- Level 2 (CoS)
- Level 3 (IP Precedence / Differentiated Services Code Point)
CoS - sets priorities from 0 to 7. If the boundary device (IP phone or application) is able to set bits, then the network scheduler must decide whether to trust this device or not.
')
The default switch action is:
Do not trust the boundary device, on all frames that hit the switch, priorities will be reset to 0.
If the boundary device is allowed to be trusted, then the switch must be “warned” about the inviolability of this bit.
Depending on the switch model, you may first need to enable QoS - this is done with the mls qos command. Next on the interface indicates the trust for CoS, and the policy applied to the package, if it came without a corresponding bit. As a result, we obtain:
switch(config)# mls qos
switch(config-if)# mls qos trust cos
switch(config-if)# mls qos cos default-cos
Also, if we want the switch to ignore the present CoS bit in the packet, we need to use the following combination of commands, as a result, the default QoS will be used:
switch(config)# mls qos
switch(config-if)# mls qos cos override
switch(config-if)# mls qos cos default-cosIt is not always possible to recognize the value of the CoS packet, since the devices are not always directly connected to the access level switch, it often happens that the client is plugged into the simplest uncontrolled switch that does not know the concept of priorities, unfortunately we will not be able to use IP ACL, because . we are not sure of the constancy of the client's IP address, here we will have to use the MAC ACL, it will look something like this.
We define the traffic flow, the class-map is used to define the traffic flow as a service class, in this case we called the service class ipphone:
switch(config)# class-map match-all ipphone
switch(config-cmap)# match access-group name officephone
:
switch(config)# mac access-list extended officephone
switch(config-ext-macl)# permit host 000.0a00.0111 anyWe can check what we have created using the command: show class-map
Continuing to configure our rule, the next step is to define the QoS functions in the policy by assigning the DSCP value to the existing class:
switch(config)# policy-map inbound-accesslayer
switch(config-pmap)# class ipphone
switch(config-pmap-c)# set ip dscp 40We can check the results with the command: show policy-map
Below I want to give a summary table comparing the values ​​of our "magic field" for different types of determinants.
At this stage, the last action is to apply the policy to the interface in our case, we will apply this policy to all ports of our switch simultaneously:
switch(config)# interface range fa 0/1-24
switch(config-if-range)# service-policy input inbound-accesslayer
And as usual, we check our result, for example, on the first port: show mls qos interface fa 0/1
As always, we summarize our actions at the end; if you paid attention to my previous article, you could not forget about the block diagram of links in the QoS policies, you can follow the commands below using this block diagram.
switch(config)# interface range fa 0/1-24
switch(config-if-range)# service-policy input inbound-accesslayer
switch(config)# policy-map inbound-accesslayer
switch(config-pmap)# class ipphone
switch(config-pmap-c)# set ip dscp 40
switch(config)# class-map match-all ipphone
switch(config-cmap)# match access-group name officephone
switch(config)# mac access-list extended officephone
switch(config-ext-macl)# permit host 000.0a00.0111 any
Now consider a slightly different version of the use of such classifiers for packages. This view is based on the definition of the protocol at the third level, but not without the help of the same ACL.
Consider an example of preventing the download channel FTP traffic, in your case - it can be anything, even the range of ports. We will label packets with a zero value, which will turn these packets into packets with the lowest priority, using both IP precedence and DSCP.
In this case, it will look something like this;
We approve a pre-planned traffic policy per group of interfaces:
switch(config)#interface range fa 0/1-24
switch (config-if-range)# service-policy input inbound-accesslayerWe define the QoS functions in the policy, in this case it will be to add the value 0 to the dscp, ip cell of the packet.
switch(config)#policy-map inbound-accesslayer
switch(config-pmap)# class reduceservice
switch(config-pmap-c)#set ip dscp 0
Determine the traffic flow:
switch(config)#class-map reduceservice
switch(config-cmap)# match acces-group 100And the last condition necessary for the execution of all the above:
switch(config)#ip access-list extended 100
switch(config-ext-nacl)# permit tcp any any eq ftpAt the end of the article I want to remind once again about the block diagram that was shown in the previous article, if you write QoS policies, then keep it before your eyes, it will help you to navigate very easily and never get confused when drawing up the rules.
Thanks for attention.
PS On the advice of IlyaPodkopaev add some information about the concepts of trust and dscp-mutation
qos trust - In the context of interface configuration, this command is used to enable the trusted state of each port.
qos dscp-mutation — Applies the DSCP change map for the trusted DSCP port of the system (always overwrites the DSCP for this port).
Most often, the last command is used if the two domains have different dscp values, but we need some kind of mechanism to convert one DSCP to another. We specify the so-called mutations below by the specified commands:
mls qos map dscp-mutation mutation1 1 2 3 4 5 6 7 to 0
mls qos map dscp-mutation mutation1 8 9 10 11 12 13 to 10
mls qos map dscp-mutation mutation1 20 21 22 to 20
mls qos map dscp-mutation mutation1 30 31 32 33 34 to 30Next should apply this "mutation" on the interface. Well, as always, after the work done, check with the command: show mls qos maps dscp-mutation.
Source: https://habr.com/ru/post/125746/
All Articles