Hello everyone,
This post will introduce the QoS problem.
Topic
1. What are the causes of erratic display and asynchronous voice and image between the headquarters and branches?
2. Now in order to ensure the communication quality between the headquarters and branches, QoS needs to be deployed. Which device should be deployed on (you only need to write the device name)? How to deploy QoS? Need to specify detailed configuration parameter information.
3. The branch is now accessing the external network, and the bandwidth used under normal conditions is 100M, and the bandwidth is guaranteed to be 50M in the case of link congestion. How to implement it? (Explain the specific reason)
What are the causes of erratic display and asynchronous voice and image between the headquarters and branches?
Due to network delay, jitter, congestion, and packet loss.
On which device is QoS deployed? How to deploy QoS?
In theory, the differentiated service model needs to be deployed end-to-end according to the division of DS domains. Considering the deployment of GRE tunnels, assuming that AR2.AR3 does not have the ability to be managed by enterprise administrators, QoS needs to be deployed on AR1 and AR4. Use ACL to perform complex traffic classification technology on the internal network interface side of headquarters AR1 connection, classify FTP, video, and voice services, and perform classification configuration through MQC command lines, and use traffic behavior commands to transfer FTP, video, and voice service packets Perform re-marking, configure a flow policy to bind traffic classification and traffic behavior, and apply it in the inbound direction of the internal network side interface to complete the re-marking of service traffic. Assume that voice traffic is marked as ef, video traffic is marked as af41, and FTP traffic is marked as af31.
After service packets are classified and re-marked, the GRE protocol performs tunnel encapsulation and generates a new IP header. During GRE encapsulation, the DSCP value of the new IP header inherits the DSCP value of the inner IP packet by default. Therefore, the DSCP value of the outer IP packet header can be used to implement a simple traffic classification of service packets. That is, the DSCP value of voice traffic is re-marked as EF. After GRE encapsulation is performed, the DSCP value of the outer IP packet header is still EF.
Run the MQC-based traffic classification command on AR1 to perform simple traffic classification based on the DSCP value in the outer IP header of GRE packets. That is, EF classifies traffic as voice traffic, AF41 classifies traffic as video traffic, and AF31 classifies traffic as FTP traffic.
Use CBQ queues, assign EF traffic to EF queues/LLQ queues through the classifier behavior command, and configure sufficiently and supervised bandwidth values. Refer to the command queue ef bandwidth to allocate video traffic to the AF queue and allocate bandwidth, and allocate FTP traffic to the second AF queue and allocate bandwidth. Put other unclassified traffic into the default class and use WFQ queue scheduling, and finally use the flow policy to associate the flow classification and traffic behavior, and apply it to the physical interface on the external network side of AR1 or the outbound direction of the GRE tunnel port. The difference lies in the physical port targeting Both GRE traffic and non-GRE traffic execute CBQ queues. The GRE tunnel port only executes CBQ queues for GRE traffic. The key is the reasonableness of bandwidth parameter configuration to ensure the QoS effect.
On AR4, the DSCP value of the inner IP packet header after decapsulation of GRE packets remains unchanged. Simple traffic classification is performed based on the DSCP value, and voice traffic, video traffic, and FTP traffic can still be classified. Configure CBQ queues to be the same as those on AR1 in the outbound direction of AR4's internal network-layer interface.
You can also use the same configuration roadmap to configure reverse traffic.
The branch is now accessing the external network, and the bandwidth used under normal conditions is 100M, and the bandwidth is guaranteed to be 50M in the case of link congestion. How to implement it?
It can be achieved by using rate limiting technology and CBQ in the outbound direction of the interface of the branch router AR4 connected to the external network.
Speed limit, configure outbound traffic shaping or traffic policing on the interface of the AR4 link to the external network, that is, configure the maximum bandwidth in the interface view to limit the maximum bandwidth to 100M, refer to the command qos car outbound or qos gts.
Through the MQC command line of CBQ, classify the traffic of the branch accessing the external network in the traffic classification (use ACL to match the traffic); allocate this part of the traffic to the AF queue in the traffic behavior, and allocate 50M bandwidth for the AF queue, That is, queue af bandwidth 51200 in the traffic behavior view, and set the minimum bandwidth used in congestion to 50M. The traffic classification and traffic behavior associated with the traffic policy are applied in the outbound direction of the external network interface. Features of AF queues: Each AF queue corresponds to a type of packet, and the user can set the bandwidth occupied by each type of packet. When the system schedules message out of the queue, the messages are sent out of the queue according to the bandwidth set by the user for all types of messages, so that fair scheduling of various types of queues can be realized. When the interface has the remaining bandwidth, the AF queue shares the remaining bandwidth according to the weight.
That is all I want to share with you! Thank you!
