All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leonardo Balliache <leoball@opalsoft.net>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] kernel packet traveling diagram
Date: Sun, 30 Jun 2002 20:48:55 +0000	[thread overview]
Message-ID: <marc-lartc-102547036018250@msgid-missing> (raw)
In-Reply-To: <marc-lartc-102520121109677@msgid-missing>

Hi, Jan.

You wrote:

 > Are you sure? In the previous diagram, the PRDB was checked before the
 > packet hits the QOS Ingress. If the PRDB indeed is checked after QOS Ingress
 > (i.e. in INPUT ROUTING), which seems the logical way, is it possible (with a
 > patch???) to check the tc_index in "ip rule"? This would make it possible to
 > let the output of the QOS ingress participate in the policy routing.

As I understand:

After Julian observation I believe first diagram was wrong; after reading
again "IPROUTE2 Utility Suite Howto" as follows:

-----------
Rules in routing policy database controlling route selection algorithm.

Classic routing algorithms used in the Internet make routing decisions based
only on the destination address of packets and in theory, but not in practice,
on the TOS field. In some circumstances we want to route packets differently
depending not only on the destination addresses, but also on other packet
fields such as source address, IP protocol, transport protocol ports or even
packet payload. This task is called "policy routing".

To solve this task the conventional destination based routing table, ordered
according to the longest match rule, is replaced with the "routing policy
database" or RPDB, which selects the appropriate route through execution of
some set of rules. These rules may have many keys of different natures and
therefore they have no natural ordering excepting that which is imposed by the
network administrator. In Linux the RPDB is a linear list of rules ordered by
a numeric priority value. The RPDB explicitly allows matching packet source
address, packet destination address, TOS, incoming interface (which is packet
metadata, rather than a packet field), and using fwmark values for matching
IP protocols and transport ports.
-------------

ip rule is input routing (and has access to TOS field).

Reading from Almesberger.-

------------------------------
1) DSCP are the upper six bits of DS field.
2) DS field is the same as TOS field.
------------------------------

Reading ip rule code in iproute2 package from Kuznetsov.-

-----------------------------
1) ip rule use iprule_modify function to set rules.
2) iprule_modify use rtnetlink calls thru libnetlink. Structure rtmsg is
    used as a channel to interchange information.
3) One of the fields of rtmsg structure is rtm_tos.
4) You have access to check this octet thru ip rule "tos TOS" selector.
---------------------------------

Also from Differentiated Services on Linux (Almesberger) - 06/1999:

--------------------------------
       When using "sch_dsmark", the class number returned by the
       classifier is stored in skb->tc_index. This way, the result can be
       re-used during later processing steps.

       Nodes in multiple DS domains must also be able to distinguish
       packets by the inbound interface in order to translate the DSCP to
       the correct PHB. This can be done using the "route" classifier, in
       combination with the "ip rule" command interface subset.
-----------------------

I hope this can answer your question; any feedback from experience
people on the list is welcome.

 > FYI, there is a iptables patch out there, called mangle5hooks, so the mangle
 > table registers all 5 netfilter hooks. This implies that the mangle table
 > has 5 chains instead of 2, PREROUTING, INPUT, OUTPUT, FORWARD and
 > POSTROUTING.

I will try to update the diagram. These words from Julian scare me a little:

----------------
         It was JFYI. I\'m not sure whether we can find a place in the
diagram for all programs in the world that are using NF hooks :) Of course,
you can go further and to build a jumbo picture of the NF world :)
----------------

Best regards,

Leonardo Balliache


_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

  parent reply	other threads:[~2002-06-30 20:48 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-06-27 18:02 [LARTC] kernel packet traveling diagram Leonardo Balliache
2002-06-27 20:44 ` Julian Anastasov
2002-06-28  8:21 ` Stef Coene
2002-06-28 10:49 ` Jan Coppens
2002-06-30 20:48 ` Leonardo Balliache [this message]
2002-06-30 20:58 ` Leonardo Balliache
2002-09-10 22:35 ` [LARTC] Kernel Packet Traveling Diagram Ciprian Niculescu
2002-09-11 11:15 ` Leonardo Balliache
2002-09-11 18:11 ` Stef Coene
2007-07-02 10:11 ` Edouard Thuleau
2007-07-02 12:04 ` Edouard Thuleau
2007-07-02 12:11 ` nano bug
2007-07-02 12:25 ` Mark
2007-07-02 12:47 ` Frank Remetter
2007-07-02 15:08 ` nano bug
2007-07-03 11:41 ` Edouard Thuleau
2007-07-03 12:16 ` Edouard Thuleau
2007-07-04  0:51 ` Andy Furniss

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-102547036018250@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.