Leonardo Balliache
2002-Jun-20 00:19 UTC
Re: iptables diagram (ex: ipchains + mark in output chain ?)
Sorry, Julian, I can''t follow the list every day, it goes too
fast for my schedule.
You wrote,
> Basicly, 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
OK, I understand.
> 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? :)
This phrase from you is very important:
** Which ones do you think if routing _decision_ is not performed? **
Now I understand; LOCAL_OUT (mangle, nat & filter) must have a destination
address to work with and this must be written before by "Output
Routing".
> 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.
I''m not very clear here. Can I suppose you are talking about mangle
and nat OUTPUT and you call it "Output Rerouting"?
> Note also that after FORWARD there is no routing decision :)))
Ok, but in FORWARD itself?
I read this in an article from Saravanan Radhakrishnan; the ** are mine.
"The basic principle involved in the implementation of QoS in linux is
shown in Figure 1. This figure shows how the kernel processes incoming
packets, and how it generates packets to be sent to the network. The
input de-multiplexer examines the incoming packets to determine if the
packets are destined for the local node. If so, they are sent to the
higher layer for further processing. If not, it sends the packets to the
forwarding block. ** The forwarding block, which may also received locally
generated packets from the higher layer **, looks up the routing table and
determines the next hop for the packet. After this, it queues the packets
to be transmitted on the output interface. It is at this point that the
linux traffic control comes into play. Linux traffic control can be used
to build a complex combination of queuing disciplines, classes and
filters that control the packets that are sent on the output interface."
+---------------+
+---->| TCP, UDP, ... |
| +---------------+
| | TRAFFIC CONTROL
| v |
+---------------------+ +------------+ +----------------+
-->|Input de-multiplexing|-->| Forwarding |-->| Output queuing |-->
+---------------------+ +------------+ +----------------+
Figure 1
An another article from Werner Almesberger, Jamal Hadi Salim and
Alexey Kuznetsov says:
""Forwarding" includes the selection of the output interface, the
selection
of the next hop, encapsulation, etc. Once all this is done, packets are
queued on the respective output interface. This is the point where traffic
control comes into play. Traffic control can, among other things, decide
if packets are queued or if they are dropped (e.g. if the queue has reached
some length limit, or if the traffic exceeds some rate limit), it can decide
in which order packets are sent (e.g. to give priority to certain flows),
it can delay the sending of packets (e.g. to limit the rate of outbound
traffic), etc."
With all this info I''m trying an improved diagram:
Network
-----------+-----------
|
+-------+------+
| mangle |
| PREROUTING | <- MARK REWRITE
+-------+------+
|
+-------+------+ Policy rule database
| PRDB | <- controlled by ip rule
+-------+------+
|
+-------+------+
| nat |
| PREROUTING | <- DEST REWRITE
+-------+------+
|
packet is for +-------+------+ packet is for
this address | INPUT | another address
+--------------+ ROUTING +---------------+
| +--------------+ |
+-------+------+ |
| filter | |
| INPUT | |
+-------+------+ |
| |
+-------+------+ |
| Local | |
| Process | |
+-------+------+ |
| |
+-------+------+ |
| OUTPUT | +-------+-------+
| ROUTING | | filter |
+-------+------+ | FORWARD |
| +-------+-------+
+-------+------+ |
| mangle | |
| OUTPUT | MARK REWRITE |
+-------+------+ |
| |
+-------+------+ |
| nat | |
| OUTPUT | DEST REWRITE |
+-------+------+ |
| |
+-------+------+ |
| filter | |
| OUTPUT | |
+-------+------+ |
| |
| |
+----------------+ +--------------------+
| |
| |
+--+-------+---+
| | selection of the output
interface,
| FORWARDING | selection of the next hop,
+-------+------+ encapsulation, etc.
|
|
+-------+------+
| nat |
| POSTROUTING | SOURCE REWRITE
+-------+------+
|
|
+-------+------+
| TRAFFIC |
| QUEUE | <- controlled by tc
+-------+------+
|
|
-----------+-----------
Network
What''s your opinion?
> I''ll not iterate this issue anymore. We already disturb
> the LARTC subscribers :)
Honestly I don''t think this kind of discussion disturbs the list;
instead
avoid the list to become itself in a "cookbook" list.
I use these tools: iproute2, iptables, cipe, lvs and tc. It would be very
pedagogyc to have a diagram showing how a packet transverse the kernel and
which tool controls each block of the diagram.
Thanks a lot for your explanation; also excuse because I''m bother you.
Best regards,
Leonardo Balliache
Julian Anastasov
2002-Jun-20 11:34 UTC
Re: iptables diagram (ex: ipchains + mark in output chain ?)
Hello, On Wed, 19 Jun 2002, Leonardo Balliache wrote:> > 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. > > I''m not very clear here. Can I suppose you are talking about mangle > and nat OUTPUT and you call it "Output Rerouting"?Yes, mangle can reroute.> > Note also that after FORWARD there is no routing decision :))) > > Ok, but in FORWARD itself? > > I read this in an article from Saravanan Radhakrishnan; the ** are mine. > > "The basic principle involved in the implementation of QoS in linux is > shown in Figure 1. This figure shows how the kernel processes incoming > packets, and how it generates packets to be sent to the network. The > input de-multiplexer examines the incoming packets to determine if the > packets are destined for the local node. If so, they are sent to the > higher layer for further processing. If not, it sends the packets to the > forwarding block. ** The forwarding block, which may also received locally > generated packets from the higher layer **, looks up the routing table and > determines the next hop for the packet. After this, it queues the packetsHere the input and the output routing are mixed. The input routing determines local/forward. The output routing is performed from "higher layer". Note that the routing, the forwarding are called as functions from specific place in the code. nexthop/outdev are determined both from the input and the output routing. The Forwarding process is after routing and does not perform nexthop/outdev selection. Of course, sometimes the word Forwarding is used for the routing and forwarding :)> to be transmitted on the output interface. It is at this point that the > linux traffic control comes into play. Linux traffic control can be used > to build a complex combination of queuing disciplines, classes and > filters that control the packets that are sent on the output interface." > > +---------------+ > +---->| TCP, UDP, ... | > | +---------------+ > | | TRAFFIC CONTROL > | v | > +---------------------+ +------------+ +----------------+ > -->|Input de-multiplexing|-->| Forwarding |-->| Output queuing |--> > +---------------------+ +------------+ +----------------+Looks good, except that TCP, UDP do not go to Forwarding but to Output_Routing->LOCAL_OUT(including mangle rerouting)->POST_ROUTING At least, as Forwarding I assume the process of receiving and sending the same packet but in the context of all these hooks the code that sends ICMP redirects (demanded from input routing), decs the IP TTL, performs dumb NAT and calls the filter chain. This code is used only for forwarded packets.> Figure 1 > > An another article from Werner Almesberger, Jamal Hadi Salim and > Alexey Kuznetsov says: > > ""Forwarding" includes the selection of the output interface, the selection > of the next hop, encapsulation, etc. Once all this is done, packets areWhat I can say against the authors :) They said Forwarding with big ''F'' :) They simply want to say that QoS egress is when the packet reaches the output device, after post_routing in NF terms.> queued on the respective output interface. This is the point where traffic > control comes into play. Traffic control can, among other things, decide > if packets are queued or if they are dropped (e.g. if the queue has reached > some length limit, or if the traffic exceeds some rate limit), it can decide > in which order packets are sent (e.g. to give priority to certain flows), > it can delay the sending of packets (e.g. to limit the rate of outbound > traffic), etc." > > With all this info I''m trying an improved diagram: > > > Network > -----------+----------- > | > +-------+------+ > | mangle | > | PREROUTING | <- MARK REWRITE > +-------+------+ > |ip rule is input routing, more correctly, part of the routing, not before nat PREROUTING> +-------+------+ Policy rule database > | PRDB | <- controlled by ip rule > +-------+------+ > | > +-------+------+ > | nat | > | PREROUTING | <- DEST REWRITE > +-------+------+ > |You can add here ipchains FILTER and QoS Ingress :)> packet is for +-------+------+ packet is for > this address | INPUT | another address > +--------------+ ROUTING +---------------+ > | +--------------+ | > +-------+------+ | > | filter | | > | INPUT | | > +-------+------+ | > | | > +-------+------+ | > | Local | | > | Process | | > +-------+------+ | > | | > +-------+------+ | > | OUTPUT | +-------+-------+ > | ROUTING | | filter | > +-------+------+ | FORWARD | > | +-------+-------+ > +-------+------+ | > | mangle | | > | OUTPUT | MARK REWRITE | > +-------+------+ | > | | > +-------+------+ | > | nat | | > | OUTPUT | DEST REWRITE | > +-------+------+ | > | | > +-------+------+ | > > | filter | | > | OUTPUT | | > +-------+------+ | > | | > | | > +----------------+ +--------------------+ > | |Remove the forwarding from here, the both clones already performed selection of next hop (routing). Filter FORWARD was in the forwarding.> | | > +--+-------+---+ > | | selection of the output > interface, > | FORWARDING | selection of the next hop, > +-------+------+ encapsulation, etc. > |Place for ipchains FILTER> | > +-------+------+ > | nat | > | POSTROUTING | SOURCE REWRITE > +-------+------+ > | > | > +-------+------+ > | TRAFFIC | > | QUEUE | <- controlled by tc > +-------+------+ > | > | > -----------+----------- > Network > > What''s your opinion? > > > I''ll not iterate this issue anymore. We already disturb > > the LARTC subscribers :) > > Honestly I don''t think this kind of discussion disturbs the list; instead > avoid the list to become itself in a "cookbook" list. > > I use these tools: iproute2, iptables, cipe, lvs and tc. It would be very > pedagogyc to have a diagram showing how a packet transverse the kernel and > which tool controls each block of the diagram.http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-19.html#ss19.21 after the 2.2 net diagram there are the places used from LVS. Of course, this info does not include the recent MANGLE extensions that work in all chains.> Best regards, > > Leonardo BalliacheRegards -- Julian Anastasov <ja@ssi.bg>
King Yung Tong
2002-Jun-20 20:32 UTC
Re: Re: iptables diagram (ex: ipchains + mark in output chain ?)
Hello all, I am working for similar structure recently. In my cases, I am working on IPSEC freeS/WAN. I just wonder, does anyone knows how IPSEC NAT working on which hooks/filter/chain. Based on the testing I made, I believe it is on NAT output. One more question is when I use IPSEC, I guess all the packet will go to "local process" (network layer) to encrypt and pass to outgoing interface. If it is, is that means INPUT ROUTING is unless since all the packet (no matter the destination is) will be go to the user sapce instead of forwading chain. Patrick> > > > Network > > -----------+----------- > > | > > +-------+------+ > > | mangle | > > | PREROUTING | <- MARK REWRITE > > +-------+------+ > > | > > ip rule is input routing, more correctly, part of the routing, > not before nat PREROUTING > > > > +-------+------+ Policy rule database > > | PRDB | <- controlled by ip rule > > +-------+------+ > > | > > +-------+------+ > > | nat | > > | PREROUTING | <- DEST REWRITE > > +-------+------+ > > | > > You can add here ipchains FILTER and QoS Ingress :) > > > > packet is for +-------+------+ packet is for > > this address | INPUT | another address > > +--------------+ ROUTING +---------------+ > > | +--------------+ | > > +-------+------+ | > > | filter | | > > | INPUT | | > > +-------+------+ | > > | | > > +-------+------+ | > > | Local | | > > | Process | | > > +-------+------+ | > > | | > > +-------+------+ | > > | OUTPUT | +-------+-------+ > > | ROUTING | | filter | > > +-------+------+ | FORWARD | > > | +-------+-------+ > > +-------+------+ | > > | mangle | | > > | OUTPUT | MARK REWRITE | > > +-------+------+ | > > | | > > +-------+------+ | > > | nat | | > > | OUTPUT | DEST REWRITE | > > +-------+------+ | > > | | > > +-------+------+ | > > > > | filter | | > > | OUTPUT | | > > +-------+------+ | > > | | > > | | > > +----------------+ +--------------------+ > > | | > > Remove the forwarding from here, the both clones already > performed selection of next hop (routing). Filter FORWARD was in the > forwarding. > > > > | | > > +--+-------+---+ > > | | selection of the output > > interface, > > | FORWARDING | selection of the next hop, > > +-------+------+ encapsulation, etc. > > | > > Place for ipchains FILTER > > > > | > > +-------+------+ > > | nat | > > | POSTROUTING | SOURCE REWRITE > > +-------+------+ > > | > > | > > +-------+------+ > > | TRAFFIC | > > | QUEUE | <- controlled by tc > > +-------+------+ > > | > > | > > -----------+----------- > > Network > > > > What''s your opinion? > > > > > I''ll not iterate this issue anymore. We already disturb > > > the LARTC subscribers :) > > > > Honestly I don''t think this kind of discussion disturbs the list; instead > > avoid the list to become itself in a "cookbook" list. > > > > I use these tools: iproute2, iptables, cipe, lvs and tc. It would be very > > pedagogyc to have a diagram showing how a packet transverse the kernel and > > which tool controls each block of the diagram. > > http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-19.html#ss19.21 > > after the 2.2 net diagram there are the places used from LVS. Of > course, this info does not include the recent MANGLE extensions > that work in all chains. > > > Best regards, > > > > Leonardo Balliache > > Regards > > -- > Julian Anastasov <ja@ssi.bg> > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >
Jan Coppens
2002-Jun-25 14:34 UTC
Re: Re: iptables diagram (ex: ipchains + mark in output chain ?)
Hi all, Is it possible to mark packets (fwmark in mangle table of some sort) after ingress policing and before Input routing? I need the ingress policer (ingress queue), to filter and classify packets first, then the firewall has to filter them again and set the fwmark. All this has to be done before the packet reaches its "routing table".> > > > > > Network > > > -----------+----------- > > > | > > > +-------+------+ > > > | mangle | > > > | PREROUTING | <- MARK REWRITE > > > +-------+------+ > > > | > > > > ip rule is input routing, more correctly, part of the routing, > > not before nat PREROUTING > > > > > > > +-------+------+ Policy ruledatabase> > > | PRDB | <- controlled by iprule> > > +-------+------+ > > > |At this point I should need another mangle table->> > > +-------+------+ > > > | nat | > > > | PREROUTING | <- DEST REWRITE > > > +-------+------+ > > > | > > > > You can add here ipchains FILTER and QoS Ingress :) > > > > > > > packet is for +-------+------+ packet is for > > > this address | INPUT | another address > > > +--------------+ ROUTING +---------------+ > > > | +--------------+ | > > > +-------+------+ | > > > | filter | | > > > | INPUT | | > > > +-------+------+ | > > > | | > > > +-------+------+ | > > > | Local | | > > > | Process | | > > > +-------+------+ | > > > | | > > > +-------+------+ | > > > | OUTPUT |+-------+-------+> > > | ROUTING | | filter|> > > +-------+------+ | FORWARD|> > > |+-------+-------+> > > +-------+------+ | > > > | mangle | | > > > | OUTPUT | MARK REWRITE | > > > +-------+------+ | > > > | | > > > +-------+------+ | > > > | nat | | > > > | OUTPUT | DEST REWRITE | > > > +-------+------+ | > > > | | > > > +-------+------+ | > > > > > > | filter | | > > > | OUTPUT | | > > > +-------+------+ | > > > | | > > > | | > > > +----------------+ +--------------------+ > > > | | > > > > Remove the forwarding from here, the both clones already > > performed selection of next hop (routing). Filter FORWARD was in the > > forwarding. > > > > > > > | | > > > +--+-------+---+ > > > | | selection of the output > > > interface, > > > | FORWARDING | selection of the nexthop,> > > +-------+------+ encapsulation, etc. > > > | > > > > Place for ipchains FILTER > > > > > > > | > > > +-------+------+ > > > | nat | > > > | POSTROUTING | SOURCE REWRITE > > > +-------+------+ > > > | > > > | > > > +-------+------+ > > > | TRAFFIC | > > > | QUEUE | <- controlled by tc > > > +-------+------+ > > > | > > > | > > > -----------+----------- > > > Network > > > > > > What''s your opinion? > > > > > > > I''ll not iterate this issue anymore. We already disturb > > > > the LARTC subscribers :) > > > > > > Honestly I don''t think this kind of discussion disturbs the list;instead> > > avoid the list to become itself in a "cookbook" list. > > > > > > I use these tools: iproute2, iptables, cipe, lvs and tc. It would bevery> > > pedagogyc to have a diagram showing how a packet transverse the kerneland> > > which tool controls each block of the diagram. > > > >http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-19.html#ss19.2 1> > > > after the 2.2 net diagram there are the places used from LVS. Of > > course, this info does not include the recent MANGLE extensions > > that work in all chains. > > > > > Best regards, > > > > > > Leonardo Balliache > > > > Regards > >Cheers, Jan
John Telford
2002-Jun-25 15:47 UTC
Re: Re: iptables diagram (ex: ipchains + mark in output chain ?)
I''d very much like to see this diagram again with all the updates. Thanks ...John On Tue, Jun 25, 2002 at 04:34:16PM +0200, Jan Coppens wrote:> Hi all, > > Is it possible to mark packets (fwmark in mangle table of some sort) after > ingress policing and before Input routing? I need the ingress policer > (ingress queue), to filter and classify packets first, then the firewall has > to filter them again and set the fwmark. All this has to be done before the > packet reaches its "routing table". > > > > > > > > > Network > > > > -----------+----------- > > > > | > > > > +-------+------+ > > > > | mangle | > > > > | PREROUTING | <- MARK REWRITE > > > > +-------+------+ > > > > | > > > > > > ip rule is input routing, more correctly, part of the routing, > > > not before nat PREROUTING > > > > > > > > > > +-------+------+ Policy rule > database > > > > | PRDB | <- controlled by ip > rule > > > > +-------+------+ > > > > | > > At this point I should need another mangle table-> > > > > > +-------+------+ > > > > | nat | > > > > | PREROUTING | <- DEST REWRITE > > > > +-------+------+ > > > > | > > > > > > You can add here ipchains FILTER and QoS Ingress :) > > > > > > > > > > packet is for +-------+------+ packet is for > > > > this address | INPUT | another address > > > > +--------------+ ROUTING +---------------+ > > > > | +--------------+ | > > > > +-------+------+ | > > > > | filter | | > > > > | INPUT | | > > > > +-------+------+ | > > > > | | > > > > +-------+------+ | > > > > | Local | | > > > > | Process | | > > > > +-------+------+ | > > > > | | > > > > +-------+------+ | > > > > | OUTPUT | > +-------+-------+ > > > > | ROUTING | | filter > | > > > > +-------+------+ | FORWARD > | > > > > | > +-------+-------+ > > > > +-------+------+ | > > > > | mangle | | > > > > | OUTPUT | MARK REWRITE | > > > > +-------+------+ | > > > > | | > > > > +-------+------+ | > > > > | nat | | > > > > | OUTPUT | DEST REWRITE | > > > > +-------+------+ | > > > > | | > > > > +-------+------+ | > > > > > > > > | filter | | > > > > | OUTPUT | | > > > > +-------+------+ | > > > > | | > > > > | | > > > > +----------------+ +--------------------+ > > > > | | > > > > > > Remove the forwarding from here, the both clones already > > > performed selection of next hop (routing). Filter FORWARD was in the > > > forwarding. > > > > > > > > > > | | > > > > +--+-------+---+ > > > > | | selection of the output > > > > interface, > > > > | FORWARDING | selection of the next > hop, > > > > +-------+------+ encapsulation, etc. > > > > | > > > > > > Place for ipchains FILTER > > > > > > > > > > | > > > > +-------+------+ > > > > | nat | > > > > | POSTROUTING | SOURCE REWRITE > > > > +-------+------+ > > > > | > > > > | > > > > +-------+------+ > > > > | TRAFFIC | > > > > | QUEUE | <- controlled by tc > > > > +-------+------+ > > > > | > > > > | > > > > -----------+----------- > > > > Network > > > > > > > > What''s your opinion? > > > > > > > > > I''ll not iterate this issue anymore. We already disturb > > > > > the LARTC subscribers :) > > > > > > > > Honestly I don''t think this kind of discussion disturbs the list; > instead > > > > avoid the list to become itself in a "cookbook" list. > > > > > > > > I use these tools: iproute2, iptables, cipe, lvs and tc. It would be > very > > > > pedagogyc to have a diagram showing how a packet transverse the kernel > and > > > > which tool controls each block of the diagram. > > > > > > > http://www.linuxvirtualserver.org/Joseph.Mack/HOWTO/LVS-HOWTO-19.html#ss19.2 > 1 > > > > > > after the 2.2 net diagram there are the places used from LVS. Of > > > course, this info does not include the recent MANGLE extensions > > > that work in all chains. > > > > > > > Best regards, > > > > > > > > Leonardo Balliache > > > > > > Regards > > > > > Cheers, > > Jan > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ >-- John Telford - Owner JohnTelford.com LLC 503-292-6865 - fax:503-292-3094 john@johntelford.com - www.johntelford.com
Michael T. Babcock
2002-Jun-25 18:16 UTC
Re: Re: iptables diagram (ex: ipchains + mark in output chain ?)
John Telford wrote:>I''d very much like to see this diagram again with all the updates. >I''d be willing to draw it in Dia afterward ... :
Stef Coene
2002-Jun-25 18:47 UTC
Re: Re: iptables diagram (ex: ipchains + mark in output chain ?)
On Tuesday 25 June 2002 20:16, Michael T. Babcock wrote:> John Telford wrote: > >I''d very much like to see this diagram again with all the updates. > > I''d be willing to draw it in Dia afterward ... :And I was waiting for the final picture to put it on www.docum.org :) Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net