All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonardo Balliache <leoball@opalsoft.net>
To: lartc@vger.kernel.org
Subject: [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?)
Date: Thu, 20 Jun 2002 00:19:00 +0000	[thread overview]
Message-ID: <marc-lartc-102453256224218@msgid-missing> (raw)
In-Reply-To: <marc-lartc-102439647716068@msgid-missing>

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/

  reply	other threads:[~2002-06-20  0:19 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-18 10:34 [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Julian Anastasov
2002-06-20  0:19 ` Leonardo Balliache [this message]
2002-06-20  8:35 ` Julian Anastasov
2002-06-20 20:32 ` [LARTC] Re: iptables diagram (ex: ipchains + mark in output King Yung Tong
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-lartc-102453256224218@msgid-missing \
    --to=leoball@opalsoft.net \
    --cc=lartc@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.