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@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Adrian Turcu wrote:> 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:There is alot of work going on with tc at the moment - There are/will be lots more matches and the ability to run iptables commands from filters.> > I have a server behind my linux-firewall box (firewall is with 2.6.10 kernel > custom build,I think with 2.6.10 you can still get the behaviour you want if you don''t select packet action in Qos and/or fair queuing of config - you get to select a different policer then. CONFIG_NET_CLS_POLICE is the one you want if the other doesn''t disappear de select it aswell. Andy.
> > There is alot of work going on with tc at the moment - There are/will be > lots more matches and the ability to run iptables commands from filters. >... Like matching the tc flows with iptables chains? that will be nice. I''ve seen some similar options in the kernel, but not sure how they work (i.e. CONFIG_NET_ACT_IPT); I couldn''t find any doc (howto)...> > I think with 2.6.10 you can still get the behaviour you want if you > don''t select packet action in Qos and/or fair queuing of config - you > get to select a different policer then. > > CONFIG_NET_CLS_POLICE is the one you want if the other doesn''t disappear > de select it aswell.I don''t have CONFIG_NET_CLS_POLICE, but CONFIG_NET_CLS_ACT enabled and CONFIG_NET_ACT_POLICE as a module. If I disable CONFIG_NET_CLS_ACT there are few more that disappear. I''ll try this right now (have to rebuild the kernel).> > Andy.Thanks a lot, Adrian
> Message: 1 > Date: Mon, 4 Apr 2005 12:06:35 +0100 > From: Adrian Turcu <adrian.turcu@gmvinteractive.com> > Subject: [LARTC] Help please with tc and iptables mark > To: lartc@mailman.ds9a.nl > Message-ID: <200504041206.35593.adrian.turcu@gmvinteractive.com> > Content-Type: text/plain; charset="us-ascii" > > 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 1I''m most likely wrong but try this: trade -I PREROUTING for -A FORWARD and see what happens...>From http://iptables-tutorial.frozentux.net/iptables-tutorial.html7.2.10. PREROUTING chain of the nat table Caution The PREROUTING chain should not be used for any filtering since, among other things, this chain is only traversed by the first packet in a stream. The PREROUTING chain should be used for network address translation only, unless you really know what you are doing. James
On Mon 04 Apr 2005 15:31, james jones wrote:> > 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 > > I''m most likely wrong but try this: > trade -I PREROUTING for -A FORWARD and see what happens... > > >From http://iptables-tutorial.frozentux.net/iptables-tutorial.html > > 7.2.10. PREROUTING chain of the nat table > > Caution > > The PREROUTING chain should not be used for any filtering since, > among other things, this chain is only traversed by the first packet > in a stream. The PREROUTING chain should be used for network address > translation only, unless you really know what you are doing. > > JamesHi James, I''m using PREROUTING in the mangle table not in nat table, it should make a difference. But just for the sake of it, I have tried FORWARD chain in the mangle table and still nothing. The mangle table should take precedence to nat table (this is how I remember - I could be wrong so please advise), and if so then the packets should be marked prior to any routing decision, that''s the whole catch for policing ingress traffic. And just for the peace of mind I''m not doing more then marking in that mangle table (PREROUTING chain). Thanks anyway for the tip, Adrian
Yippee! It worked :) I have tried on both kernels 2.6.10 and 2.6.11.6 and it''s really sweet to see it works... BTW, in 2.6.11.6 when sch_ingress is loaded this message "Ingress scheduler: Classifier actions preferred over netfilter" appears in the log, which in 2.6.10 it''s just silent, the feature is the same. I have tried with different marks for different kind of inbound traffic and the tests looked good. Man, I''m happy now :) For the future search on this subject, bellow is my kernel config for "QoS and/or fair queueing" section (maybe there are lots to be removed): # # QoS and/or fair queueing # CONFIG_NET_SCHED=y # CONFIG_NET_SCH_CLK_JIFFIES is not set # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set CONFIG_NET_SCH_CLK_CPU=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m CONFIG_NET_CLS_ROUTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U32=m CONFIG_CLS_U32_PERF=y # CONFIG_NET_CLS_IND is not set CONFIG_CLS_U32_MARK=y CONFIG_NET_CLS_RSVP=m CONFIG_NET_CLS_RSVP6=m # CONFIG_NET_CLS_ACT is not set CONFIG_NET_CLS_POLICE=y and just to recap the versions used: iproute2-ss050318 iptables v1.3.1 gcc-3.4.3 kernel custom built as per above versions Thanks guys, Adrian> > There is alot of work going on with tc at the moment - There are/will be > > lots more matches and the ability to run iptables commands from filters. > > ... Like matching the tc flows with iptables chains? that will be nice. > I''ve seen some similar options in the kernel, but not sure how they work > (i.e. CONFIG_NET_ACT_IPT); I couldn''t find any doc (howto)... > > > I think with 2.6.10 you can still get the behaviour you want if you > > don''t select packet action in Qos and/or fair queuing of config - you > > get to select a different policer then. > > > > CONFIG_NET_CLS_POLICE is the one you want if the other doesn''t disappear > > de select it aswell. > > I don''t have CONFIG_NET_CLS_POLICE, but CONFIG_NET_CLS_ACT enabled and > CONFIG_NET_ACT_POLICE as a module. If I disable CONFIG_NET_CLS_ACT there > are few more that disappear. I''ll try this right now (have to rebuild the > kernel). > > > Andy.
Last one for today, I promise... Just tested with u32 classifier match by fwmark and works as well. My tc rules (for test) shows like this: tc qdisc add dev eth1 handle ffff: ingress # for cls_fw tc filter add dev eth1 parent ffff: \ protocol ip prio 50 handle 100 fw \ police rate 100kbit burst 100kbit mtu 1500 drop \ flowid :1 # and the equivalent for cls_u32 (it can be more extendend) tc filter add dev eth1 parent ffff: \ protocol ip prio 50 \ u32 match mark 100 0xffff \ police rate 100kbit burst 100kbit mtu 1500 drop \ flowid :1 # packets are market with iptables in mangle/PREROUTING, i.e. iptables -t mangle -I PREROUTING \ -p tcp -d 192.168.1.218 --dport 22 \ -j MARK --set-mark 100 Cheers, Adrian On Mon 04 Apr 2005 17:24, Adrian Turcu wrote:> Yippee! It worked :) > I have tried on both kernels 2.6.10 and 2.6.11.6 and it''s really sweet to > see it works... BTW, in 2.6.11.6 when sch_ingress is loaded this message > "Ingress scheduler: Classifier actions preferred over netfilter" appears in > the log, which in 2.6.10 it''s just silent, the feature is the same. I have > tried with different marks for different kind of inbound traffic and the > tests looked good. Man, I''m happy now :) > > For the future search on this subject, bellow is my kernel config for "QoS > and/or fair queueing" section (maybe there are lots to be removed): > > # > # QoS and/or fair queueing > # > CONFIG_NET_SCHED=y > # CONFIG_NET_SCH_CLK_JIFFIES is not set > # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set > CONFIG_NET_SCH_CLK_CPU=y > CONFIG_NET_SCH_CBQ=m > CONFIG_NET_SCH_HTB=m > CONFIG_NET_SCH_HFSC=m > CONFIG_NET_SCH_PRIO=m > CONFIG_NET_SCH_RED=m > CONFIG_NET_SCH_SFQ=m > CONFIG_NET_SCH_TEQL=m > CONFIG_NET_SCH_TBF=m > CONFIG_NET_SCH_GRED=m > CONFIG_NET_SCH_DSMARK=m > CONFIG_NET_SCH_NETEM=m > CONFIG_NET_SCH_INGRESS=m > CONFIG_NET_QOS=y > CONFIG_NET_ESTIMATOR=y > CONFIG_NET_CLS=y > CONFIG_NET_CLS_TCINDEX=m > CONFIG_NET_CLS_ROUTE4=m > CONFIG_NET_CLS_ROUTE=y > CONFIG_NET_CLS_FW=m > CONFIG_NET_CLS_U32=m > CONFIG_CLS_U32_PERF=y > # CONFIG_NET_CLS_IND is not set > CONFIG_CLS_U32_MARK=y > CONFIG_NET_CLS_RSVP=m > CONFIG_NET_CLS_RSVP6=m > # CONFIG_NET_CLS_ACT is not set > CONFIG_NET_CLS_POLICE=y > > and just to recap the versions used: > iproute2-ss050318 > iptables v1.3.1 > gcc-3.4.3 > kernel custom built as per above versions > > > Thanks guys, > Adrian > > > > There is alot of work going on with tc at the moment - There are/will > > > be lots more matches and the ability to run iptables commands from > > > filters. > > > > ... Like matching the tc flows with iptables chains? that will be nice. > > I''ve seen some similar options in the kernel, but not sure how they work > > (i.e. CONFIG_NET_ACT_IPT); I couldn''t find any doc (howto)... > > > > > I think with 2.6.10 you can still get the behaviour you want if you > > > don''t select packet action in Qos and/or fair queuing of config - you > > > get to select a different policer then. > > > > > > CONFIG_NET_CLS_POLICE is the one you want if the other doesn''t > > > disappear de select it aswell. > > > > I don''t have CONFIG_NET_CLS_POLICE, but CONFIG_NET_CLS_ACT enabled and > > CONFIG_NET_ACT_POLICE as a module. If I disable CONFIG_NET_CLS_ACT there > > are few more that disappear. I''ll try this right now (have to rebuild the > > kernel). > > > > > Andy. > > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
On Mon, Apr 04, 2005 at 02:31:52PM +0100, Andy Furniss wrote:> Adrian Turcu wrote: > >Hello list members, > > There is alot of work going on with tc at the moment - There are/will be > lots more matches and the ability to run iptables commands from filters.Is there any doco on this functionality ? Any body thought of running a wiki ?> > > > > Andy. > _______________________________________________ > LARTC mailing list > LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc >_______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
Alexander Samad wrote:> On Mon, Apr 04, 2005 at 02:31:52PM +0100, Andy Furniss wrote: > >>Adrian Turcu wrote: >> >>>Hello list members, >> >>There is alot of work going on with tc at the moment - There are/will be >>lots more matches and the ability to run iptables commands from filters. > > > Is there any doco on this functionality ? Any body thought of running a > wiki ?Not much yet the ematch has examples in kernel config help and actions are here. http://www.cyberus.ca/~hadi/patches/action/README Andy.