Hi!
I am learning tcng without having experiance of tc and I am trying to
build something that shall schedule traffic dependent on the value in the
IPv4 packets ip_ttl field.
I have read the tcng reference manual and cannot find information about
forwarding. Is it possible to farward packets from ingress to egress
without sending them upwards in layers?
NIC---->ingress---->forward----->egress---->
In ingress I do some metering and in egress: classifying and Queuing.
Example (basic part of the source):
#includes
#defines
dev eth1 {
$P = bucket(rate 1Mbps, burst 2kB, mpu 64B);
ingress {
class (<>)
if ((ip_ttl & 0x81) == 0x81) &&
(conform $p && count $P);
drop if 1;
}
egress {
class (<$high>) if (((ip_ttl & 0x1E) >> 1) <= 0x0F)
&&
(((ip_ttl & 0x1E) >> 1) >= 0x0C);
class (<$mid>)....
class (<$low>)....
prio {
$high = class {fifo (limit 64kB);}
$mid = ...
$low = ...
}
}
}
If forwarding is not possible can I use hash table with tcindex to store
information at ingress, and use this information at egress?
Thanks!
/Johan. C
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Johan,
: I am learning tcng without having experiance of tc and I am trying to
: build something that shall schedule traffic dependent on the value in
: the IPv4 packets ip_ttl field.
:
: I have read the tcng reference manual and cannot find information about
: forwarding. Is it possible to farward packets from ingress to egress
: without sending them upwards in layers?
:
: NIC---->ingress---->forward----->egress---->
The reason you find no information about forwarding in the tcng manual, is
that forwarding doesn''t happen in the traffic control layer of the
Linux
IP stack. As far as I know, there''s no way to prevent a packet from
being
passed up to the kernel bridge or routing code. So, since you are
probably using this machine as a router, you''ll want to take a look at
the
KPTD at Stef''s site [0].
: In ingress I do some metering and in egress: classifying and Queuing.
Makes sense.
: dev eth1 {
: $P = bucket(rate 1Mbps, burst 2kB, mpu 64B);
: ingress {
: class (<>)
: if ((ip_ttl & 0x81) == 0x81) &&
: (conform $p && count $P);
Did you really mean to "confirm $p && count $P"? I''d
think that was meant
to be "conform $P && count $P".
: drop if 1;
: }
:
: egress {
: class (<$high>) if (((ip_ttl & 0x1E) >> 1) <= 0x0F)
&&
: (((ip_ttl & 0x1E) >> 1) >= 0x0C);
Neat bit math (here and above). I''m going to stick this one in my bag
of
tricks.
[ snip ]
: If forwarding is not possible can I use hash table with tcindex to store
: information at ingress, and use this information at egress?
I''m not completely certain what your intent is with this hash table,
but I
think the answer to your general question is yes. One of the points of
tcindex is that you don''t need to run through the same sets of tests on
ingress and egress; tcindex is designed to be reusable packet metadata
during a packet''s lifetime on a given host. You may find that Leonardo
Balliache''s DiffServ pages can help you with the Linux DiffServ
architecture, in particular, tcindex [1].
If this is not helpful, try the LARTC HOWTO [2] on DSMARK (and tcindex),
and then try a few of Werner''s papers [3].
Failing all of that, you might try asking this list again, or checking out
the (fairly inactive) Linux-DiffServ mailing list [4].
-Martin
[0] http://www.docum.org/stef.coene/qos/kptd/
[1] http://opalsoft.net/qos/DS.htm
http://opalsoft.net/qos/DS-210.htm
[2] http://lartc.org/howto/lartc.adv-qdisc.dsmark.html
[3] http://www.almesberger.net/cv/papers.html
http://www.almesberger.net/cv/papers/dsid-01.ps.gz
[4] http://diffserv.sourceforge.net/#list
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Fri, 5 Dec 2003, Martin A. Brown wrote: Hi Martin.> Johan, > : I have read the tcng reference manual and cannot find information about > : forwarding. Is it possible to farward packets from ingress to egress > : without sending them upwards in layers? > : > : NIC---->ingress---->forward----->egress----> > > The reason you find no information about forwarding in the tcng manual, is > that forwarding doesn''t happen in the traffic control layer of the Linux > IP stack.I realised this after I had done some research on forwarding on the Internet. :) Thanks!!> As far as I know, there''s no way to prevent a packet from being > passed up to the kernel bridge or routing code. So, since you are > probably using this machine as a router, you''ll want to take a look at the > KPTD at Stef''s site [0].Actually Im going to build a testplatform, where Im using a Wireless LAN, BSS-topology with a central station (AP) to controll downlink. Dependent on link quality, the AP is going to give access to the radio interface. Stations are using a network card driver that includes the link quality into the ttl_field. The ttl_field was availabla :) At ingress I want to filter packets that are giving information about the link quality. Value 0x81 is indicating that information about the link quality is available.> > Makes sense. > > : dev eth1 { > : $P = bucket(rate 1Mbps, burst 2kB, mpu 64B); > : ingress { > : class (<>) > : if ((ip_ttl & 0x81) == 0x81) && > : (conform $p && count $P); > > Did you really mean to "confirm $p && count $P"? I''d think that was meant > to be "conform $P && count $P".It was ment to be "conform $P && count $P".> : egress { > : class (<$high>) if (((ip_ttl & 0x1E) >> 1) <= 0x0F) && > : (((ip_ttl & 0x1E) >> 1) >= 0x0C); > > Neat bit math (here and above). I''m going to stick this one in my bag of > tricks.Thanks :)> > [ snip ] > > : If forwarding is not possible can I use hash table with tcindex to store > : information at ingress, and use this information at egress? > > I''m not completely certain what your intent is with this hash table, but I > think the answer to your general question is yes. One of the points of > tcindex is that you don''t need to run through the same sets of tests on > ingress and egress; tcindex is designed to be reusable packet metadata > during a packet''s lifetime on a given host. You may find that Leonardo > Balliache''s DiffServ pages can help you with the Linux DiffServ > architecture, in particular, tcindex [1].I need a table with information of available stations and their link quality for tests, where I am going to generate packets from AP to stations with good quality. I think I have to use tcindex.> > If this is not helpful, try the LARTC HOWTO [2] on DSMARK (and tcindex), > and then try a few of Werner''s papers [3]. > > Failing all of that, you might try asking this list again, or checking out > the (fairly inactive) Linux-DiffServ mailing list [4]. > > -Martin > > [0] http://www.docum.org/stef.coene/qos/kptd/ > [1] http://opalsoft.net/qos/DS.htm > http://opalsoft.net/qos/DS-210.htm > [2] http://lartc.org/howto/lartc.adv-qdisc.dsmark.html > [3] http://www.almesberger.net/cv/papers.html > http://www.almesberger.net/cv/papers/dsid-01.ps.gzThey have done a great job.> [4] http://diffserv.sourceforge.net/#list >Thank you Martin for this information. /Johan Cimen _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/