1 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. The main difference with say a vannila 5ethernet switch is that you can use u32 classifier to select a 6flow to be mirrored. High end switches typically can select based 7on more than just a port (eg a 5 tuple classifier). They may also be 8capable of redirecting. 9 10Usage: 11 12mirred <DIRECTION> <ACTION> [index INDEX] <dev DEVICENAME> 13where: 14DIRECTION := <ingress | egress> 15ACTION := <mirror | redirect> 16INDEX is the specific policy instance id 17DEVICENAME is the devicename 18 19Direction: 20- Ingress is not supported at the moment. It will be in the 21future as well as mirror/redirecting to a socket. 22 23Action: 24- Mirror takes a copy of the packet and sends it to specified 25dev ("port" in ethernet switch/bridging terminology) 26- redirect 27steals the packet and redirects to specified destination dev. 28 29What NOT to do if you dont want your machine to crash: 30------------------------------------------------------ 31 32Do not create loops! 33Loops are not hard to create in the egress qdiscs. 34 35Here are simple rules to follow if you dont want to get 36hurt: 37A) Do not have the same packet go to same netdevice twice 38in a single graph of policies. Your machine will just hang! 39This is design intent _not a bug_ to teach you some lessons. 40 41In the future if there are easy ways to do this in the kernel 42without affecting other packets not interested in this feature 43I will add them. At the moment that is not clear. 44 45Some examples of bad things NOT to do: 461) redirecting eth0 to eth0 472) eth0->eth1-> eth0 483) eth0->lo-> eth1-> eth0 49 50B) Do not redirect from one IFB device to another. 51Remember that IFB is a very specialized case of packet redirecting 52device. Instead of redirecting it puts packets at the exact spot 53on the stack it found them from. 54Redirecting from ifbX->ifbY will actually not crash your machine but your 55packets will all be dropped (this is much simpler to detect 56and resolve and is only affecting users of ifb as opposed to the 57whole stack). 58 59In the case of A) the problem has to do with a recursive contention 60for the devices queue lock and in the second case for the transmit lock. 61 62Some examples: 63------------- 64 651) Mirror all packets arriving on eth0 to be sent out on eth1. 66You may have a sniffer or some accounting box hooked up on eth1. 67 68--- 69tc qdisc add dev eth0 ingress 70tc filter add dev eth0 parent ffff: protocol ip prio 10 u32 \ 71match u32 0 0 flowid 1:2 action mirred egress mirror dev eth1 72--- 73 74If you replace "mirror" with "redirect" then not a copy but rather 75the original packet is sent to eth1. 76 772) Host A is hooked up to us on eth0 78 79# redirect all packets arriving on ingress of lo to eth0 80--- 81tc qdisc add dev lo ingress 82tc filter add dev lo parent ffff: protocol ip prio 10 u32 \ 83match u32 0 0 flowid 1:2 action mirred egress redirect dev eth0 84--- 85 86On host A start a tcpdump on interface connecting to us. 87 88on our host ping -c 2 127.0.0.1 89 90Ping would fail since all packets are heading out eth0 91tcpudmp on host A would show them 92 93if you substitute the redirect with mirror above as in: 94tc filter add dev lo parent ffff: protocol ip prio 10 u32 \ 95match u32 0 0 flowid 1:2 action mirred egress mirror dev eth0 96 97Then you should see the packets on both host A and the local 98stack (i.e ping would work). 99 1003) Even more funky example: 101 102# 103#allow 1 out 10 packets on ingress of lo to randomly make it to the 104# host A (Randomness uses the netrand generator) 105# 106--- 107tc filter add dev lo parent ffff: protocol ip prio 10 u32 \ 108match u32 0 0 flowid 1:2 \ 109action drop random determ ok 10\ 110action mirred egress mirror dev eth0 111--- 112 1134) 114# for packets from 10.0.0.9 going out on eth0 (could be local 115# IP or something # we are forwarding) - 116# if exceeding a 100Kbps rate, then redirect to eth1 117# 118 119--- 120tc qdisc add dev eth0 handle 1:0 root prio 121tc filter add dev eth0 parent 1:0 protocol ip prio 6 u32 \ 122match ip src 10.0.0.9/32 flowid 1:16 \ 123action police rate 100kbit burst 90k ok \ 124action mirred egress mirror dev eth1 125--- 126 127A more interesting example is when you mirror flows to a dummy device 128so you could tcpdump them (dummy by defaults drops all packets it sees). 129This is a very useful debug feature. 130 131Lets say you are policing packets from alias 192.168.200.200/32 132you dont want those to exceed 100kbps going out. 133 134--- 135tc qdisc add dev eth0 handle 1:0 root prio 136tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \ 137match ip src 192.168.200.200/32 flowid 1:2 \ 138action police rate 100kbit burst 90k drop 139--- 140 141If you run tcpdump on eth0 you will see all packets going out 142with src 192.168.200.200/32 dropped or not (since tcpdump shows 143all packets being egressed). 144Extend the rule a little to see only the packets making it out. 145 146--- 147tc qdisc add dev eth0 handle 1:0 root prio 148tc filter add dev eth0 parent 1: protocol ip prio 10 u32 \ 149match ip src 192.168.200.200/32 flowid 1:2 \ 150action police rate 10kbit burst 90k drop \ 151action mirred egress mirror dev dummy0 152--- 153 154Now fire tcpdump on dummy0 to see only those packets .. 155tcpdump -n -i dummy0 -x -e -t 156 157Essentially a good debugging/logging interface (sort of like 158BSDs speacialized log device does without needing one). 159 160If you replace mirror with redirect, those packets will be 161blackholed and will never make it out. 162 163cheers, 164jamal 165