Re: kernel packet traveling diagram

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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/

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux