* [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?)
2002-06-18 10:34 [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Julian Anastasov
@ 2002-06-20 0:19 ` Leonardo Balliache
2002-06-20 8:35 ` Julian Anastasov
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Leonardo Balliache @ 2002-06-20 0:19 UTC (permalink / raw)
To: lartc
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
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread* [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?)
2002-06-18 10:34 [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Julian Anastasov
2002-06-20 0:19 ` Leonardo Balliache
@ 2002-06-20 8:35 ` Julian Anastasov
2002-06-20 20:32 ` [LARTC] Re: iptables diagram (ex: ipchains + mark in output King Yung Tong
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Julian Anastasov @ 2002-06-20 8:35 UTC (permalink / raw)
To: lartc
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 packets
Here 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 are
What 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 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/
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Re: iptables diagram (ex: ipchains + mark in output
2002-06-18 10:34 [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Julian Anastasov
2002-06-20 0:19 ` Leonardo Balliache
2002-06-20 8:35 ` Julian Anastasov
@ 2002-06-20 20:32 ` King Yung Tong
2002-06-25 14:34 ` [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Jan Coppens
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: King Yung Tong @ 2002-06-20 20:32 UTC (permalink / raw)
To: lartc
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/
>
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?)
2002-06-18 10:34 [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Julian Anastasov
` (2 preceding siblings ...)
2002-06-20 20:32 ` [LARTC] Re: iptables diagram (ex: ipchains + mark in output King Yung Tong
@ 2002-06-25 14:34 ` Jan Coppens
2002-06-25 15:47 ` John Telford
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: Jan Coppens @ 2002-06-25 14:34 UTC (permalink / raw)
To: lartc
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/
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?)
2002-06-18 10:34 [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Julian Anastasov
` (3 preceding siblings ...)
2002-06-25 14:34 ` [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Jan Coppens
@ 2002-06-25 15:47 ` John Telford
2002-06-25 18:16 ` [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain Michael T. Babcock
2002-06-25 18:47 ` [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Stef Coene
6 siblings, 0 replies; 8+ messages in thread
From: John Telford @ 2002-06-25 15:47 UTC (permalink / raw)
To: lartc
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
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain
2002-06-18 10:34 [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Julian Anastasov
` (4 preceding siblings ...)
2002-06-25 15:47 ` John Telford
@ 2002-06-25 18:16 ` Michael T. Babcock
2002-06-25 18:47 ` [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Stef Coene
6 siblings, 0 replies; 8+ messages in thread
From: Michael T. Babcock @ 2002-06-25 18:16 UTC (permalink / raw)
To: lartc
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 ... :
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?)
2002-06-18 10:34 [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Julian Anastasov
` (5 preceding siblings ...)
2002-06-25 18:16 ` [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain Michael T. Babcock
@ 2002-06-25 18:47 ` Stef Coene
6 siblings, 0 replies; 8+ messages in thread
From: Stef Coene @ 2002-06-25 18:47 UTC (permalink / raw)
To: lartc
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
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 8+ messages in thread