Using TC to simulate network delay and packet loss (RPM) under Linux

1 Introduction to Analog delay transfer

Netem and Tc:netem are a network emulation function module provided by Linux 2.6 and above kernel versions. The function module can be used to simulate complex Internet transmission performance in a well-performing LAN, such as low bandwidth, transmission delay, packet loss and so on. Many distributions of Linux with Linux 2.6 (or more) versions of the kernel feature the kernel, such as Fedora, Ubuntu, Redhat, OpenSuse, CentOS, Debian, and more. TC is a tool in a Linux system with the full name traffic control (flow controls). TC can be used to control the operating mode of the Netem, that is, if you want to use Netem, you need at least two conditions, one is the kernel Netem function is included, the other is to have TC.

Note: This article describes the flow control can only control the package action, can not control the packet, and it directly to the physical interface, if the physical eth0 control, then the logical network card (such as Eth0:1) will also be affected, conversely, if you do control on the logical network card, the control may be invalid. (Note: Multiple network cards in a virtual machine can be considered as multiple physical network cards in a virtual machine.)

# TC Qdisc Add dev eth0 root netem delay 100ms

This command sets the transmission of the eth0 NIC to a delay of 100 milliseconds to send. EPRO Payment Co., Ltd.

In a more realistic situation, the delay value will not be so accurate, there will be some fluctuations, we can use the following conditions to simulate the

Delay value with volatility:

# TC Qdisc Add dev eth0 root netem delay 100ms 10ms

This command sets the transmission of the ETH0 network card to a delay of 100ms±10ms (any value between a maximum of $ ms).

The randomness of this fluctuation can also be further enhanced:

# TC Qdisc Add dev eth0 root netem delay 100ms 10ms 30%

This command sets the transmission of the eth0 NIC to 100ms, and approximately 30% of the packets delay the ±10MS send. Example: Now ping the 216 machine:

EPRO Payment Co., Ltd.

The obvious volatility of the data can be seen.

3 Analog network packet loss:
# TC Qdisc Add dev eth0 root netem loss 1%

This command sets the transmission of the eth0 NIC to randomly discard 1% of packets. Example: Executing on 216

#tc qdisc add dev eth0 root netem loss 10%

Show 16 packages only 13 received. You can also set the success rate of packet loss:

# TC Qdisc Add dev eth0 root netem loss 1% 30%

This command sets the transmission of the eth0 NIC to randomly discard 1% of packets, with a success rate of 30%.

4. Delete the relevant configuration on the NIC: Change the Add from the previous command to Del to delete the configuration:

# tc Qdisc del dev eth0 xxxxxxxxxxx (self-added configuration) This command will remove the associated transport configuration for the eth0 NIC

At this point, we have been able to simulate a certain network delay and packet loss through TC in the test environment. Here are more applications and introductions to TC

5 Simulation Package Duplication:
# TC Qdisc Add dev eth0 root netem duplicate 1%

This command sets the transmission of the eth0 NIC to randomly generate 1% of duplicate packets. 6 Analog packet Corruption:

# TC Qdisc Add dev eth0 root netem corrupt 0.2%

This command sets the transmission of the eth0 NIC to a randomly generated 0.2% corrupted packet. (kernel version is required at 2.6.16 or more)

7 Analog Packet Scrambling:
# TC Qdisc Change dev eth0 root netem delay 10ms reorder 25% 50%

This command sets the transmission of the eth0 NIC to: 25% of the packets (50% related) are sent immediately, and the other is delayed by 10 seconds.

In the new version, the following command will also disrupt the order of the packages to some extent: # TC Qdisc add dev eth0 root netem delay 100ms 10ms

8 Viewing the network conditions that have been configured: # TC Qdisc Show Dev eth0

This command will view and display the relevant transport configuration for the Eth0 NIC 9 Appendix: TC Flow Control

TC is a flow control tool, and the following is an article about TC flow control. TC Introduction

In Linux, TC has two kinds of control methods CBQ and HTB. HTB is designed to replace the CBQ. It is a hierarchical filtering framework.

The TC consists of three basic constituent blocks:

Queue rules Qdisc (queueing discipline), Class (classes), and classifiers (classifiers)

Queue in TC (queueing discipline):
It is used to control the transmission speed of the network. Through the queue, Linux can cache network packets and then according to the user's

Set to smooth network traffic without interrupting connectivity (such as TCP). It is important to note that Linux does not control the receiving queue well enough, so we generally only use the Send queue, which is "control not controlled". It encapsulates the other two main TC components (classes and classifiers). If the kernel needs to send packets through a network interface, it needs to queue the packets according to the Qdisc (queuing rules) configured for that interface. The kernel then extracts the packets from the Qdisc as much as possible, handing them over to the network adapter driver module.

The simplest qdisc is PFIFO it does not do any processing of incoming packets, and the packets are queued in first-in, first-out way. However, it saves packets that the network interface cannot handle for a while.
The queue rules include FIFO (first-in, pre-out), RED (random early detection), SFQ (random fair queue) and Token bucket (tokens bucket), class-base queue (CBQ), CBQ is a super queue, that is, it can contain other queues (and even other CBQ).

Class classes in TC
Class is used to represent a control strategy. Obviously, many times, we will probably have to implement different traffic control strategies for different IPs, when we have to use different classes to represent different control strategies.

Filter rule in TC
Filter is used to draw the user into a specific control strategy (that is, a different class). For example, now we want to implement a different control strategy (A/b) for the XXA,XXB two IP, when we can use the filter to xxa into control policy A, XXB into the control strategy The flag bits of the B,filter can be implemented using U32 marking functions or iptables Set-mark (mostly marked with iptables).
Currently, the TC can be used by the filter has: Fwmark classifier, u32 classifier, based on the routing of the Classifier and RSVP classifier (for IPV6, IPV4), etc., wherein the fwmark classifier allows us to use the Linux netfilter code to select traffic, and U32 The classifier allows us to select the traffic based on any header. It should be noted that filter (filter) is inside qdisc and they cannot be used as the main body.

Application flow of TC
Packet->iptables (when passing iptables, iptables sets a different mark based on different IP)->TC (Class)-

>TC (Queue)

Application

Assume that the eth0 bit is the server's extranet network interface. Before you begin, clear the Eth0 all queue rules first

TC Qdisc del dev eth0 root 2>/dev/null >/dev/null1) define the topmost (root) queue rule and specify the default category number

TC Qdisc Add dev eth0 root handle 1:htb default 2 easy Treasure Payment Limited

2) Defining the 1:1 category (speed) of the first layer is supposed to define a second-level leaf category, but for the moment, this application is available.

TC class Add dev eth0 parent 1:1 classid 1:2 HTB rate 98mbit ceil100mbit prio 2 tc class add dev eth0 parent 1:1 ClassID 1 : 3 htbrate 1mbit ceil 2mbit prio 2

Note: The above is our control output server speed, one for 98M, one for 2M.
Rate: is the bandwidth value guaranteed by a class. If there is more than one class, ensure that the sum of all subclasses is less than or equal to the parent class. Prio: Used to indicate the competitiveness of borrowing bandwidth, the smaller the prio, the higher the priority, the stronger the competitiveness.
Ceil:ceil is the maximum bandwidth value a class can get.

At the same time, in order not to cause a session to occupy bandwidth, add the fair queue Sfq immediately.
TC Qdisc Add dev eth0 parent 1:2 handle 2:SFQ perturb ten TC Qdisc

Add dev eth0 parent 1:3 handle 3:SFQ perturb 10

3) Set Filter
Filters can use their own u32 can also use Iptables to mark
Specify that in the root class 1:0, the filter for 192..168.0.2, using the 1:2 rule, to give him 98M speed, the writing is as follows

TC Filter Add dev eth0 protocol IP parent 1:0 u32 match IP src192.168.0.2 flowid 1:2 TC Filter Add dev eth0 protocol IP pa rent1:0 u32 match ip src 192.168.0.1 flowid 1:3

If all IP is written as
TC Filter Add dev eth0 protocol IP parent 1:prio u32 match IP

DST 0.0.0.0/0 Flowid 1:10 use Iptables to match filters

You can also use this method, but the following iptables commands are required to mark the

TC Filter Add dev eth0 parent 1:protocol IP prio 1 handle 2 Fwflowid 1:2 TC Filter Add dev eth0 parent 1:protocol ip pri o 1handle 2 FW flowid 1:3

Iptables just tick the mark.

Iptables-t mangle-a postrouting-d 192.168.0.2-j MARK--set-mark iptables-t mangle-a postrouting-d 192.168.0.3-j Mark--set-mark 20

TC control of the most high speed
Rate Ceiling speed limit
The parameter ceil specifies the maximum bandwidth that a class can use to limit how much bandwidth a class can borrow. The default ceil is the same as the rate
This feature is useful for ISPs because they generally limit the total number of users being serviced even if other users do not request services. (ISPS very much want the user to pay more money to get better service), note Root class is not allowed to be borrowed, so there is no designation Ceil

EPRO Payment Co., Ltd.

Note: The value of ceil should be at least as high as the rate at which it resides, meaning that ceil should be at least as high as any one of its subclasses

Burst Burst
Network hardware can only send one package at a time this depends only on the rate of one hardware. Link sharing software can take advantage of this ability to dynamically generate multiple connections running at different speeds. So rates and ceil are not an immediate measure but a mean of sending packets in a single time. The real situation is how to make a class with a very small amount of traffic available to other classes at the maximum rate for a certain time class. The burst and Cburst parameters control how much data can be sent effortlessly to other classes of need at the maximum speed of the hardware.
If the Cburst is less than a theoretical packet, the burst does not exceed the ceil rate, and the same method TBF the highest rate.
You may ask why bursts is needed. Because it can be easily raised to the speed on a very congested link. For example, WWW traffic is burst. You visit the homepage. Sudden acquisition and reading. Burst will be "charge" once in idle time.
Note: Burst and cburst are at least as large as the values of their subclasses.

TC command format:

Join

TC Qdisc [Add | change | replace | link] Dev dev [parent Qdisc-id | root] [handle Qdisc-id] qdisc[Qdisc specific PA Rameters]
TC class [Add | change | replace] Dev dev parent qdisc-id [classid Class-id] qdisc [Qdisc specificparameters]

TC Filter [Add | change | replace] Dev dev [parent Qdisc-id | root] Protocol protocol Prio Priorityfiltertype [filter Type specific parameters] Flowid Flow-id

Show

TC [-S |-d] qdisc show [Dev Dev]
TC [-S |-d] class show Dev dev tc filter show Dev Dev

View the status of TC
Tc-s-D qdisc Show Dev Eth0tc-s-D class show Dev eth0

Remove TC Rule
TC Qdisc del Dev eth0 root

Instance
Limit the speed control of a single IP using TC download

TC Qdisc Add dev eth0 root handle 1:htb r2q 1 TC class Add Deveth0 Parent 1:classid 1:1 HTB rate 30mbit ceil 60mbit tc
   filteradd Dev eth0 parent 1:protocol IP prio u32 match IP dst192.168.1.2  flowid 1:1

You can limit the download speed of 192.168.1.2 to 30Mbit up to 60Mbit, where r2q refers to the root without default, so that the bandwidth of the entire network is unlimited

Speed control of entire IP with TC
TC Qdisc Add dev eth0 root handle 1:htb r2q 1 TC class Add dev

EPRO Payment Co., Ltd.

Eth0 Parent 1:classid 1:1 HTB rate 50mbit ceil 1000mbit tc Filteradd Dev eth0 parent 1:protocol IP prio u32 match IP DST192.168.111.0/24 Flowid 1:1

can limit 192.168.111.0 to 255 of the bandwidth of 3000k, the actual download speed of about 200k. In this case, all the machines in this segment share the 200k bandwidth.
You can also add a SFQ (random fair queue)

TC Qdisc Add dev eth0 root handle 1:htb r2q 1 TC class Add Deveth0 Parent 1:classid 1:1 HTB rate 3000kbit Burst 10k TC Q Discadd Dev eth0 Parent 1:1 handle 10:SFQ perturb TC Filter Adddev eth0 parent 1:protocol IP prio u32 match IP DST 192.168.111.168 Flowid 1:1

SFQ, he can prevent an IP in a segment from taking up the entire bandwidth. Using the TC to control the server external speed is 10M

As below, I want to manage a server, only outgoing 10M of data

TC Qdisc del dev eth0 root tc qdisc add dev eth0 root handle 1:HTB TC class add dev eth0 parent 1:classid 1:1 HTB rate 10 0mbitceil 100mbit TC class Add dev eth0 parent 1:1 classid 1:10 htbrate 10mbit ceil 10mbit tc Qdisc Add dev eth0 parent 1: Ten sfqperturb TC Filter Add dev eth0 protocol IP parent 1:prio 2u32 match IP DST 220.181.xxx.xx/32flowid 1:1 # above this one, let 220.181.xxx.xx/32 this run the default, mainly to let this IP connection come in not controlled tcfilter add dev eth0 protocol IP parent 1:prio 5 0 u32 Match IP dst0.0.0.0/0 flowid 1:10 # default allows all traffic to pass from this

Transferred from: http://blog.csdn.net/weiweicao0429/article/details/17578011

Using TC to simulate network delay and packet loss (RPM) under Linux