blob: 03ea9d027c734230e979f0975a0de0f41577bae2 [file] [log] [blame]
net[shemminger]!shemminger00fa8482004-12-08 20:13:56 +00001
2Very funky action. I do plan to add to a few more things to it
3This is the basic stuff. Idea borrowed from the way ethernet switches
4mirror and redirect packets.
5
6Usage:
7
8mirred <DIRECTION> <ACTION> [index INDEX] <dev DEVICENAME>
9where:
10DIRECTION := <ingress | egress>
11ACTION := <mirror | redirect>
12INDEX is the specific policy instance id
13DEVICENAME is the devicename
14
jamalf649f592006-07-18 08:56:40 -040015Direction Ingress is not supported at the moment. It will be in the
16future as well as mirror/redirecting to a socket.
net[shemminger]!shemminger00fa8482004-12-08 20:13:56 +000017
18Mirroring essentially takes a copy of the packet whereas redirecting
19steals the packet and redirects to specified destination.
20
jamalf649f592006-07-18 08:56:40 -040021What NOT to do if you dont want your machine to crash:
22------------------------------------------------------
23
24Do not create loops!
25Loops are not hard to create in the egress qdiscs.
26
27Here are simple rules to follow if you dont want to get
28hurt:
29A) Do not have the same packet go to same netdevice twice
30in a single graph of policies. Your machine will just hang!
31This is design intent _not a bug_ to teach you some lessons.
32
33In the future if there are easy ways to do this in the kernel
34without affecting other packets not interested in this feature
35I will add them. At the moment that is not clear.
36
37Some examples of bad things to do:
381) redirecting eth0 to eth0
392) eth0->eth1-> eth0
403) eth0->lo-> eth1-> eth0
41
42B) Do not redirect from one IFB device to another.
43Remember that IFB is a very specialized case of packet redirecting
44device. Instead of redirecting it puts packets at the exact spot
45on the stack it found them from.
46This bad policy will actually not crash your machine but your
47packets will all be dropped (this is much simpler to detect
48and resolve and is only affecting users of ifb as opposed to the
49whole stack).
50
51In the case of A) the problem has to do with a recursive contention
52for the devices queue lock and in the second case for the transmit lock.
53
net[shemminger]!shemminger00fa8482004-12-08 20:13:56 +000054Some examples:
jamalf649f592006-07-18 08:56:40 -040055------------
56
571) Mirror all packets arriving on eth0 to be sent out on eth1.
58You may have a sniffer or some accounting box hooked up on eth1.
59
60tc qdisc add dev lo eth0
61tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \
62match u32 0 0 flowid 1:2 action mirred egress mirror dev eth1
63
64If you replace "mirror" with "redirect" then not a copy but rather
65the original packet is sent to eth1.
66
672) Host A is hooked up to us on eth0
net[shemminger]!shemminger00fa8482004-12-08 20:13:56 +000068
69tc qdisc add dev lo ingress
70# redirect all packets arriving on ingress of lo to eth0
71tc filter add dev lo parent ffff: protocol ip prio 10 u32 \
72match u32 0 0 flowid 1:2 action mirred egress redirect dev eth0
73
74On host A start a tcpdump on interface connecting to us.
75
76on our host ping -c 2 127.0.0.1
77
jamalf649f592006-07-18 08:56:40 -040078Ping would fail since all packets are heading out eth0
net[shemminger]!shemminger00fa8482004-12-08 20:13:56 +000079tcpudmp on host A would show them
80
81if you substitute the redirect with mirror above as in:
82tc filter add dev lo parent ffff: protocol ip prio 10 u32 \
83match u32 0 0 flowid 1:2 action mirred egress mirror dev eth0
84
85Then you should see the packets on both host A and the local
86stack (i.e ping would work).
87
jamalf649f592006-07-18 08:56:40 -0400883) Even more funky example:
net[shemminger]!shemminger00fa8482004-12-08 20:13:56 +000089
90#
91#allow 1 out 10 packets to randomly make it to the
92# host A (Randomness uses the netrand generator)
93#
94tc filter add dev lo parent ffff: protocol ip prio 10 u32 \
95match u32 0 0 flowid 1:2 \
96action drop random determ ok 10\
97action mirred egress mirror dev eth0
98
jamalf649f592006-07-18 08:56:40 -0400994)
net[shemminger]!shemminger00fa8482004-12-08 20:13:56 +0000100# for packets coming from 10.0.0.9:
jamalf649f592006-07-18 08:56:40 -0400101#Redirect packets on egress, if exceeding a 100Kbps rate,
102# to eth1
net[shemminger]!shemminger00fa8482004-12-08 20:13:56 +0000103#
104
105tc qdisc add dev eth0 handle 1:0 root prio
106
107tc filter add dev eth0 parent 1:0 protocol ip prio 6 u32 \
108match ip src 10.0.0.9/32 flowid 1:16 \
109action police rate 100kbit burst 90k ok \
110action mirred egress mirror dev eth1
111
112---
113
114A more interesting example is when you mirror flows to a dummy device
shemminger47836e12006-01-03 18:29:19 +0000115so you could tcpdump them (dummy by defaults drops all packets it sees).
net[shemminger]!shemminger00fa8482004-12-08 20:13:56 +0000116This is a very useful debug feature.
117
jamalf649f592006-07-18 08:56:40 -0400118Lets say you are policing packets from alias 192.168.200.200/32
119you dont want those to exceed 100kbps going out.
120
121tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \
122match ip src 192.168.200.200/32 flowid 1:2 \
123action police rate 100kbit burst 90k drop
124
125If you run tcpdump on eth0 you will see all packets going out
126with src 192.168.200.200/32 dropped or not
127Extend the rule a little to see only the ones that made it out:
128
129tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \
130match ip src 192.168.200.200/32 flowid 1:2 \
131action police rate 10kbit burst 90k drop \
132action mirred egress mirror dev dummy0
133
134Now fire tcpdump on dummy0 to see only those packets ..
135tcpdump -n -i dummy0 -x -e -t
136
137Essentially a good debugging/logging interface (sort of like
138BSDs speacialized log device does without needing one).
139
140If you replace mirror with redirect, those packets will be
141blackholed and will never make it out. This redirect behavior
142changes with new patch (but not the mirror).
143
144cheers,
145jamal