Hi ! I''m marking packets to classify them with ipchains. For example, to mark packets which will go to the internet (ppp0) I do: /sbin/ipchains -A input -i eth0 -s 192.168.0.0/16 -d ! 192.168.0.0/16 -b -m 100 Can I do mark them on the output chain (ipchains -A output -i ppp0 -m 100) and still have QoS working properly ? In other words, what does the kernel: - packet -> input(mark) -> forward -> output(mark) -> qos/egress - or packet -> input -> forward -> qos/egress -> output(mark) ? TIA, -- Ludovic DROLEZ Free&ALter Soft 152, rue de Grigy - Technopole Metz 2000 57070 METZ tel : 03 87 75 55 21 fax : 03 87 75 19 26
On Wednesday 12 June 2002 16:32, Ludovic Drolez wrote:> Hi ! > > I''m marking packets to classify them with ipchains. > For example, to mark packets which will go to the internet (ppp0) > I do: > > /sbin/ipchains -A input -i eth0 -s 192.168.0.0/16 -d ! 192.168.0.0/16 -b > -m 100 > > Can I do mark them on the output chain (ipchains -A output -i ppp0 -m > 100) and still have QoS working properly ?Yes you can.> In other words, what does the kernel: > - packet -> input(mark) -> forward -> output(mark) -> qos/egressYep> - or packet -> input -> forward -> qos/egress -> output(mark) ?Nop Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net
On Wed, 12 Jun 2002 16:48:22 +0200 Stef Coene, answering to Ludovic Drolez
wrote:
>> Can I do mark them on the output chain (ipchains -A output -i ppp0 -m
>> 100) and still have QoS working properly ?
> Yes you can.
>> In other words, what does the kernel:
>> - packet -> input(mark) -> forward -> output(mark) ->
qos/egress
> Yep
Nop again. I understand what Stef is trying to say but it could be confused
because you are using input(mark) to refer to prerouting.
Really does not exist such a path input -> forward -> output -> qos
thru
the kernel.
Exists the path prerouting -> forward -> postrouting.
I have seen people in the list trying to use Linux as a router and applying
iptables over the INPUT and OUTPUT chains when those are not transversed by
packets when the box is a router; just use FORWARD.
If you are trying to say that input(mark) is the chain for marking packets
before entering the kernel use instead PREROUTING to keep things clear for
all of us.
This diagram, subject to discusion and improvement for more experimented
people in the list to be depurated, can help to clarify things:
Network
-----------+-----------
|
+-------+------+
| mangle |
| PREROUTING |
+-------+------+
|
+-------+------+ Policy rule database
| PRDB | <- controlled by ip rule
+-------+------+
|
+-------+------+
| nat |
| PREROUTING |
+-------+------+
|
packet is for +-------+------+ packet is for
this address | ROUTING | another address
+--------------+ DECISION ? +---------------+
| +--------------+ |
+-------+------+ |
| filter | |
| INPUT | |
+-------+------+ |
| |
+-------+------+ |
| Local | |
| Process | |
+-------+------+ |
| |
+-------+------+ +------+------+
| mangle | | filter |
| OUTPUT | | FORWARD |
+-------+------+ +------+------+
| |
+-------+------+ |
| nat | |
| OUTPUT | |
+-------+------+ |
| |
+-------+------+ |
| filter | |
| OUTPUT | |
+-------+------+ |
| +--------------+ |
+--------------+ ROUTING +---------------+
| DECISION ? | <- controlled by ip route
+-------+------+
|
+-------+------+
| nat |
| POSTROUTING |
+-------+------+
|
+-------+------+
| TRAFFIC |
| QUEUE | <- controlled by tc
+-------+------+
|
-----------+-----------
Network
After all of us agree the diagram could be published at Stef site (with his
permission, of course) to be have as a reference to people using the list.
Also, Ludovic, I really recommend you to migrate from ipchains to iptables.
Last is a lot better code, well designed and clearer to understand than
ipchains. Really try to do it.
Best regards,
Leonardo Balliache
leoball@opalsoft.net
Hello, On Mon, 17 Jun 2002, Leonardo Balliache wrote:> This diagram, subject to discusion and improvement for more experimented > people in the list to be depurated, can help to clarify things: > > > Network > -----------+----------- > | > +-------+------+ > | mangle | > | PREROUTING | > +-------+------+ > | > +-------+------+ Policy rule database > | PRDB | <- controlled by ip rule > +-------+------+ > | > +-------+------+ > | nat | > | PREROUTING | > +-------+------+ > | > packet is for +-------+------+ packet is for > this address | ROUTING | another address > +--------------+ DECISION ? +---------------+ > | +--------------+ | > +-------+------+ | > | filter | | > | INPUT | | > +-------+------+ | > | | > +-------+------+ | > | Local | | > | Process | | > +-------+------+ |ROUTING> | | > +-------+------+ +------+------+ > | mangle | | filter | > | OUTPUT | | FORWARD | > +-------+------+ +------+------+ > | | > +-------+------+ | > | nat | | > | OUTPUT | | > +-------+------+ | > | | > +-------+------+ | > | filter | | > | OUTPUT | | > +-------+------+ | > | +--------------+ | > +--------------+ ROUTING +---------------+ > | DECISION ? | <- controlled by ip route > +-------+------+ > | > +-------+------+ > | nat | > | POSTROUTING | > +-------+------+ > | > +-------+------+ > | TRAFFIC | > | QUEUE | <- controlled by tc > +-------+------+ > | > -----------+----------- > Network > > > After all of us agree the diagram could be published at Stef site (with his > permission, of course) to be have as a reference to people using the list.Where is the routing decision of the local process, before OUTPUT? Or only I see it :) Also, there is a big difference between input and output routing decision, may be this diagram can show it :)> Best regards, > > Leonardo Balliache > leoball@opalsoft.netRegards -- Julian Anastasov <ja@ssi.bg>
but the diagram is for iptables ipchains, do for ex a pachet that traverse the router: net -> input chain -> routing -> forward chain -> output chain if i remember well and for the iptables see a great picture :-) at : http://people.unix-fu.org/andreasson/iptables-tutorial/images/tables_traverse.jpg C Julian Anastasov wrote:> Hello, > > On Mon, 17 Jun 2002, Leonardo Balliache wrote: > > >>This diagram, subject to discusion and improvement for more experimented >>people in the list to be depurated, can help to clarify things: >> >> >> Network >> -----------+----------- >> | >> +-------+------+ >> | mangle | >> | PREROUTING | >> +-------+------+ >> | >> +-------+------+ Policy rule database >> | PRDB | <- controlled by ip rule >> +-------+------+ >> | >> +-------+------+ >> | nat | >> | PREROUTING | >> +-------+------+ >> | >> packet is for +-------+------+ packet is for >> this address | ROUTING | another address >> +--------------+ DECISION ? +---------------+ >> | +--------------+ | >> +-------+------+ | >> | filter | | >> | INPUT | | >> +-------+------+ | >> | | >> +-------+------+ | >> | Local | | >> | Process | | >> +-------+------+ | >> > > > ROUTING > > > >> | | >> +-------+------+ +------+------+ >> | mangle | | filter | >> | OUTPUT | | FORWARD | >> +-------+------+ +------+------+ >> | | >> +-------+------+ | >> | nat | | >> | OUTPUT | | >> +-------+------+ | >> | | >> +-------+------+ | >> | filter | | >> | OUTPUT | | >> +-------+------+ | >> | +--------------+ | >> +--------------+ ROUTING +---------------+ >> | DECISION ? | <- controlled by ip route >> +-------+------+ >> | >> +-------+------+ >> | nat | >> | POSTROUTING | >> +-------+------+ >> | >> +-------+------+ >> | TRAFFIC | >> | QUEUE | <- controlled by tc >> +-------+------+ >> | >> -----------+----------- >> Network >> >> >>After all of us agree the diagram could be published at Stef site (with his >>permission, of course) to be have as a reference to people using the list. >> > > Where is the routing decision of the local process, before > OUTPUT? Or only I see it :) Also, there is a big difference between > input and output routing decision, may be this diagram can show it :) > > >>Best regards, >> >>Leonardo Balliache >>leoball@opalsoft.net >> > > Regards > > -- > Julian Anastasov <ja@ssi.bg> > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >
Hello, On Mon, 17 Jun 2002, Ciprian Niculescu wrote:> but the diagram is for iptablesYes, I know.> and for the iptables see a great picture :-) at : > http://people.unix-fu.org/andreasson/iptables-tutorial/images/tables_traverse.jpgAnother wrong picture for iptables Regards -- Julian Anastasov <ja@ssi.bg>
Julian Anastasov wrote:> Hello, > > On Mon, 17 Jun 2002, Ciprian Niculescu wrote: > >>but the diagram is for iptables > > Yes, I know.aa ok, so why the subject is ipchains? :-)> >>and for the iptables see a great picture :-) at : >>http://people.unix-fu.org/andreasson/iptables-tutorial/images/tables_traverse.jpg >> > Another wrong picture for iptableswhy??? C
Hello, On Mon, 17 Jun 2002, Ciprian Niculescu wrote:> aa ok, so why the subject is ipchains? :-)I''m just replying to the proposed iptables diagram.> >>http://people.unix-fu.org/andreasson/iptables-tutorial/images/tables_traverse.jpg > >> > > Another wrong picture for iptables > > > why???Read my posting again. The routing decision is before OUTPUT not after OUTPUT. It should be looking something like: local process -> output routing -> OUTPUT+output_rerouting(s) -> ... Another problem: to what routing decision refers the diagram after forward? The forwarding should be: prerouting -> input routing -> forward -> post_routing Another bug, this time in the netfilter sources (iptable_mangle.c): output_rerouting called from INPUT> CRegards -- Julian Anastasov <ja@ssi.bg>
Ciprian Niculescu
2002-Jun-18 07:13 UTC
iptables diagram (ex: ipchains + mark in output chain ?)
so you say that are 3 routing decision: - after nat prerouting - after local_process, and before mangle output - before nat postrouting what is the use of the routing decision after local process??? C Julian Anastasov wrote:> Hello, > > On Mon, 17 Jun 2002, Ciprian Niculescu wrote: > > >>aa ok, so why the subject is ipchains? :-) >> > > I''m just replying to the proposed iptables diagram. > > >>>>http://people.unix-fu.org/andreasson/iptables-tutorial/images/tables_traverse.jpg >>>> >>>> >>> Another wrong picture for iptables >>> >> >>why??? >> > > Read my posting again. The routing decision is before > OUTPUT not after OUTPUT. It should be looking something like: > > local process -> output routing -> OUTPUT+output_rerouting(s) -> ... > > Another problem: to what routing decision refers the diagram > after forward? > > The forwarding should be: > > prerouting -> input routing -> forward -> post_routing > > Another bug, this time in the netfilter sources (iptable_mangle.c): > > output_rerouting called from INPUT > > >>C >> > > Regards > > -- > Julian Anastasov <ja@ssi.bg> >
Julian Anastasov
2002-Jun-18 10:34 UTC
Re: iptables diagram (ex: ipchains + mark in output chain ?)
Hello, On Tue, 18 Jun 2002, Ciprian Niculescu wrote:> so you say that are 3 routing decision: > - after nat prerouting > - after local_process, and before mangle output > - before nat postroutingBasicly, there are 2 routing decisions, for the others I like the name rerouting: 1. Input Routing: after prerouting, kernel performs source validation and nexthop decision, result: local_deliver/forwarding 2. Output Routing: local_process selects source address, creates connected route or selects route for each packet. The resolved route is attached to the packet and is used later. The Netfilter''s LOCAL_OUT chain detects complete packet which is obviously loaded with some addresses. Which ones do you think if routing _decision_ is not performed? :) 3. Output Rerouting: netfilter at LOCAL_OUT changes the already selected output route if any of the routing keys are changed: addresses, tos, nfmark, etc. The intention is the packet to change its attached route and probably to go in another direction. The connected sockets do not notice this change, they remain connected to the initial route.> what is the use of the routing decision after local process???see 2. Note also that after FORWARD there is no routing decision :))) I''ll not iterate this issue anymore. We already disturb the LARTC subscribers :) Regards -- Julian Anastasov <ja@ssi.bg>