From mboxrd@z Thu Jan 1 00:00:00 1970 From: Leonardo Balliache Date: Thu, 20 Jun 2002 00:19:00 +0000 Subject: [LARTC] Re: iptables diagram (ex: ipchains + mark in output chain ?) Message-Id: List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lartc@vger.kernel.org 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/