[LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?)

[Julian Anastasov <ja@ssi.bg>]

	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/