[LARTC] Help please with tc and iptables mark

[LARTC] Help please with tc and iptables mark

[Adrian Turcu]

[-- Attachment #1.1: Type: text/plain, Size: 4016 bytes --]

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


[-- Attachment #1.2: Type: text/html, Size: 10317 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Help please with tc and iptables mark

[Andy Furniss]

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.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Help please with tc and iptables mark

[Adrian Turcu]

>
> 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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Help please with tc and iptables mark

[james jones]

> 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 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. 

James
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Help please with tc and iptables mark

[Adrian Turcu]

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.
>
> James

Hi 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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Help please with tc and iptables mark

[Adrian Turcu]

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

Re: [LARTC] Help please with tc and iptables mark

[Adrian Turcu]

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
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Help please with tc and iptables mark

[Alexander Samad]

[-- Attachment #1.1: Type: text/plain, Size: 534 bytes --]

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
> 

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] Help please with tc and iptables mark

[Andy Furniss]

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.

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc