|
Hello list members, Finaly I'm here after a week of trying to subscribe to this list... pfew... Anyway... I have a rather strange problem with tc. I am trying to police the ingress traffic into my network using the iptables MARK feature (in mangle table, PREROUTING) but it seems that tc filters ignore this marks and they don't work at all for me. Let me explain a bit more in detail: I have a server behind my linux-firewall box (firewall is with 2.6.10 kernel custom build, iproute2-2.6.11, iptables-1.3.1, gcc-3.4.3), for which server I want to limit the incoming traffic to certain limits (I choose for test 100kbit rate, 100kbit burst, mtu 1500). The server IP address behind the firewall is 192.168.1.218 attached to eth0 interface. Interface eth1 on the firewall faces the incoming traffic from the outside world: eth0 eth1 Server|----------|linux|----------|outside 192.168.1.0/24 192.168.2.0/24 .218 .99 .100 Now, I've created an iptables rule like this: iptables -t mangle -I PREROUTING -i eth1 -p tcp -d 192.168.1.218 --dport 22 -j MARK --set-mark 1 After this, I added the ingress qdisc and then the filter with tc: tc qdisc add dev eth1 handle ffff: ingress tc filter add dev eth1 parent ffff: \ protocol ip prio 50 handle 1 fw \ police rate 100kbit burst 100kbit mtu 1500 drop \ flowid :1 I was trying to simulate from outside some traffic towards the server using sftp transfer (I try to limit port 22 access). The total available bandwidth without filters is arround 1Mbit/sec. The file to transfer is quite large (11 MBytes). The results from tc -d -s filter show dev eth1 parent ffff: are showing that no packet was dropped (the output is bellow) filter protocol ip pref 50 fw filter protocol ip pref 50 fw handle 0x1 classid :1 police 0x6 rate 100000bit burst 12799b mtu 1500b action drop ref 1 bind 1 Sent 0 bytes 0 pkts (dropped 0, overlimits 0) qdisc pfifo_fast 0: bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1 Sent 6823868 bytes 112558 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 qdisc ingress ffff: ---------------- Sent 4451034 bytes 9297 pkt (dropped 0, overlimits 0 requeues 0) rate 0bit 0pps backlog 0b 0p requeues 0 although the packets are marked by iptables (the packet and traffic counters are incremented for that specific MARK rule) What puzzled me is that using u32 classifiers with tc (match by IP, port, protocol) for the same kind of traffic everything works just perfect, the available incoming bandwidth to the server is limited to what I want to be and I can see that the filter is dropping the packets. Obviously the logical thing is to use the u32 classifiers instead of iptables marks, but I want to keep the classification to be done by iptables as I also do there some decisions for which traffic is allowed (is more that I have customised a start-up script for iptables to match my needs using different switches and predefined variables for ports and Ip addresses). I also have another reason not to use u32 classifiers, I cannot get the logic behind the pattern/mask for selecting a certain port range for tcp/udp traffic (I've tried to match my traffic using u32 pattern/mask rules for a port-range after reading some documentation and I still can't make it work, I doing something wrong for sure - this is just me, so ignore it, I'll get it right after more reading). Any chance I could get some help for my problem (iptables marking the packets and tc filtering by these marks)? BTW, I have tried older versions of iproute2 with different versions of iptables and kernel 2.6.x and 2.4.x as well, but still no luck. Also I have followed the thread at: http://mailman.ds9a.nl/pipermail/lartc/2005q1/014673.html posted by Catalin, which looks great but still no match by fwmark. Should I suspect an iptables wrong behavior? Or it's just my stupid brain that tricks me again? Any help is much appreciated. Kind regards, Adrian |
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
