Using TC to simulate network latency and packet loss __linux under Linux

1 Introduction to Analog delay transmission

Netem and Tc:netem are a network emulation module provided by the Linux kernel version 2.6 and above. This 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 Linux that use the Linux 2.6 (or above) version of the kernel feature the kernel, such as Fedora, Ubuntu, Redhat, OpenSuse, CentOS, Debian, and so on. TC is a tool in a Linux system with the full name traffic control (flow-controlled). TC can be used to control the working mode of Netem, that is to say, if you want to use Netem, you need at least two conditions, one is that the Netem function in the kernel is included, and the other is TC.

Note: The flow control introduced in this paper can only control the contract behavior, can not control the packet action, at the same time, it directly to the physical interface, if the control of physical eth0, 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 adapters in a virtual machine can be considered as multiple physical network adapters in a virtual machine.)

# TC Qdisc Add dev eth0 root netem delay 100ms

This command sets the transmission of the ETH0 network card to delay 100 milliseconds of sending. Yeepay Payment Co., Ltd.

In a more real case, the delay is not so accurate, there will be some fluctuations, we can use the following conditions to simulate

Delay value with volatility:

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

This command sets the transport of the Eth0 network card to be sent by delaying 100ms±10ms (any value between the M-ms).

The randomness of this volatility can also be further enhanced:

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

This command sets the transmission of the ETH0 network card to 100ms, while approximately 30% of the packets delay ±10ms sending. Example: Now ping the 216 machine:

Yeepay Payment Co., Ltd.

You can see the obvious volatility of the data.

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

This command sets the transmission of the ETH0 network card to a random drop of 1% packets. Example: Executing on 216

#tc qdisc add dev eth0 root netem loss 10%

displaying 16 packages only 13 have 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 network card to a random drop of 1% packets, with a success rate of 30%.

4. Remove the related configuration above the network card: Change the previous command to Del to remove the configuration:

# tc Qdisc del Dev eth0 xxxxxxxxxxx (its own configuration) This command deletes the associated transport configuration of the Eth0 network card

At this point, we can simulate a certain network latency and packet loss by TC in the test environment. Here are more about TC applications and introductions

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

This command sets the transmission of the ETH0 network card to a randomly generated duplicate packet of 1%. 6 Analog packet Corruption:

# TC Qdisc Add dev eth0 root netem corrupt 0.2%

This command sets the transmission of the ETH0 network card to a corrupted packet that randomly generates 0.2%. (kernel version needs to be 2.6.16 or more)

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

This command sets the transmission of the ETH0 network card to: 25% packets (50% related) are sent immediately, and the others are delayed by 10 seconds.

In the new version, the order can also be disrupted to some extent: # TC Qdisc add dev eth0 root netem delay 100ms 10ms

8 View already configured network conditions: # TC Qdisc Show Dev eth0

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

TC is a flow control tool, the following is a post about TC flow control. TC Introduction

In Linux, there are two ways to control TC CBQ and HTB. HTB is designed to replace CBQ. It is a layered filtering framework.

The TC consists of three basic constituent blocks:

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

Queues in TC (queueing discipline):
To achieve the control of the network to send and receive speed. Through queues, Linux can cache network packets, and then according to the user's

Set up to smooth network traffic as far as possible without interrupting connections (such as TCP). It is important to note that the Linux control of the receiving queue is not good enough, so we generally only use the send queue, that is, "the control is not charged." It encapsulates the other two main TC components (classes and classifiers). If the kernel needs to send packets through a network interface, it will need to queue the packets according to the Qdisc (queuing rules) configured for the interface. The kernel then takes as many packets from the Qdisc as possible and hands them to the network adapter driver module.

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

Class classes in TC
Class is used to represent a control policy. Obviously, many times, we are likely to implement different traffic control strategies for different IPs, at which point we have to use different class to represent different control strategies.

Filter rules in TC
Filter is used to delimit a user into a specific control policy (that is, in a different Class). For example, now we want to implement a different control strategy for XXA,XXB two IP (a,b), at which point we can use filter to XXA to control Strategy A, and XXB to control strategy. The b,filter can be realized by u32 marking function or iptables set-mark (most use iptables to mark).
Currently, the TC can use the filter has: Fwmark classifier, u32 classifier, based on the routing classifier and RSVP classifier (respectively for IPV6, IPV4), etc., where 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 headers. It should be noted that the filter (filter) is inside the qdisc, and they cannot be the main body.

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

>TC (Queue)

Application

Assume that the eth0 bit is the external network interface of the server. Before you start, clear all queue rules for eth0

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

TC Qdisc Add dev eth0 root handle 1:htb default 2 yi Bao Payment Co., ltd

2 to define the first level of the 1:1 categories (speed) would have been to define the second layer of leaf category, but for now, this application can be.

TC class Add dev eth0 parent 1:1 classid 1:2 HTB rate 98mbit ceil
100mbit prio 2 tc class add dev eth0 parent 1:1 clas Sid 1:3 HtB
rate 1mbit ceil 2mbit prio 2

Note: The above is our control output server speed, one for 98M, one for 2M.
Rate: is a class-guaranteed bandwidth value. If you have more than one class, make sure that the sum of all subclasses is less than or equal to the parent. Prio: Used to indicate the competitiveness of borrowing bandwidth, prio smaller, higher priority, more competitive.
Ceil:ceil is the maximum available bandwidth value for a class.

Also, to not allow a session to be permanently occupied with bandwidth, add a SFQ to the fair queue.
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
The filter can use its own u32 or it can use Iptables to mark
Specifies that in root 1:0, the filter for 192..168.0.2, using the 1:2 rule, gives him a speed of 98M, written as follows

TC Filter Add dev eth0 protocol IP parent 1:0 u32 match ip src
192.168.0.2 flowid 1:2 tc Filter Add dev eth0 protocol IP parent
1:0 u32 match ip src 192.168.0.1 flowid 1:3

If it's all IP notation, like
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 you need to mark it with the help of the iptables command below.

TC Filter Add dev eth0 parent 1:protocol IP prio 1 handle 2 FW
FLOWID 1:2 TC Filter Add dev eth0 parent 1:protocol i P Prio 1
handle 2 FW flowid 1:3

Iptables, just mark it.

Iptables-t mangle-a postrouting-d 192.168.0.2-j Mark--set-Mark Iptables-t mangle-a postrouting-d
.3-j MARK
--set-mark 20

The control of TC to the most high speed
Rate Ceiling Rate Limit
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 that are being serviced even if other users do not request a service. (ISPS very much want users to pay more money to get better service), note that the root class is not allowed to be borrowed, so did not specify Ceil

Yeepay Payment Co., Ltd.

Note: The Ceil value should be at least as high as the class it is in, meaning that the ceil should be at least as high as any of its subclasses

Burst Burst
Network hardware can only send a package at one 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 the rate and ceil are not an instant metric but a mean of sending packets in a single time. The actual situation is how to make a class with very little traffic available at the maximum rate to other classes at a time class. The burst and Cburst parameters control how much data can be sent effortlessly to other classes as required by the hardware's maximum speed.
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 you need bursts. Because it can be easily raised to the speed of a very crowded link on the road. For example, the WWW traffic is abrupt. You visit the homepage. Sudden acquisition and reading. In the idle time burst will again "charge" once.
Note: Burst and cburst must be 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

Delete TC Rule
TC Qdisc del Dev eth0 root

Instance
Using TC downloads to limit the speed control of a single IP

TC Qdisc Add dev eth0 root handle 1:htb r2q 1 TC class add dev
eth0 parent 1:classid 1:1 HTB rate 30mbit ceil 60mbit TC  filter
add dev eth0 parent 1:protocol IP prio u32 match IP dst
192.168.1.2  flowid 1:1

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

Speed control of whole segment IP using TC
TC Qdisc Add dev eth0 root handle 1:htb r2q 1 TC class Add dev

Yeepay Payment Co., Ltd.

Eth0 Parent 1:classid 1:1 HTB rate 50mbit ceil 1000mbit TC filter
add dev eth0 parent 1:protocol IP prio u32 H IP DST
192.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, the 200k bandwidth is shared by all machines in this network segment.
You can also add a SFQ (random fair queue)

TC Qdisc Add dev eth0 root handle 1:htb r2q 1 TC class add dev
eth0 parent 1:classid 1:1 HTB rate 3000kbit Burst 10k TC Qdisc
Add dev eth0 parent 1:1 handle 10:SFQ perturb TC filter Add
dev eth0 parent 1:protocol IP prio u Match IP DST
192.168.111.168 flowid 1:1

SFQ, he can prevent one IP in a segment from taking up the entire bandwidth. Use TC to control the server's external speed of 10M

For example, I want to manage a server that can only send out 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: 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 2  20.181.xxx.xx/32 This runs the default, mainly to allow this IP connection to come in and not be controlled tcfilter add dev eth0 protocol IP parent 1:prio match IP u32 Flowid 1:10 # By default let all traffic flow from this through

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