All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] I can control traffic based on IP ADDRESS but not on PROTOCOL
@ 2000-10-23 22:31 Peter
  2000-10-24 11:41 ` bert
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: Peter @ 2000-10-23 22:31 UTC (permalink / raw)
  To: lartc

<PRE>I have spent a tremendous amount of time on this one, and I can reproduce
it.

I set up all of my classes and queues.
Now is time for the filters.

Let's say that I have a flowid 1:100 which is the handle of a queue with a
very small bounded isolated bandwidth allocation of 25Kbit.

If I use the following filter:

tc filter add dev eth1 parent 1:0 protocol ip prio 25 u32 match ip src
216.79.164.46 flowid 1:100

I get the correct throughtput of 25Kbit.

However, if I attempt to filter by protocol instead, it does not work.
I will disregard the fact that this filter will manipulate both TCP and UDP
sessions destined to the specific port.
I am attaching to a server on port 8080 (0x1f90).

tc filter add dev eth1 parent 1:0 protocol ip prio 25 u32 match tcp src
0x1f90 0xffff flowid 1:100

A connection to the above port will yield the default bandwidth of 10Mbit.
Not the desired effect.

I have used many examples copied strainght out of the sources, in all of
them, the IP address matching works, but the TCP matching never does.

Any help is greatly appreciated.

Peter Frischknecht
Empowering Solutions, Inc.
<A HREF="http://www.empoweringsolutions.com">http://www.empoweringsolutions.com</A>
(864)654.6544 x103 Phone
(864)654.0022      Fax



</PRE>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [LARTC] I can control traffic based on IP ADDRESS but not on PROTOCOL
  2000-10-23 22:31 [LARTC] I can control traffic based on IP ADDRESS but not on PROTOCOL Peter
@ 2000-10-24 11:41 ` bert
  2000-10-24 16:35 ` Peter
  2000-10-26 18:30 ` [LARTC] I can control traffic based on IP ADDRESS but not on Suhail
  2 siblings, 0 replies; 4+ messages in thread
From: bert @ 2000-10-24 11:41 UTC (permalink / raw)
  To: lartc

<PRE>On Mon, Oct 23, 2000 at 06:31:30PM -0400, Peter Frischknecht wrote:

&gt;<i> However, if I attempt to filter by protocol instead, it does not work.
</I>&gt;<i> I will disregard the fact that this filter will manipulate both TCP and UDP
</I>&gt;<i> sessions destined to the specific port.
</I>&gt;<i> I am attaching to a server on port 8080 (0x1f90).
</I>&gt;<i> 
</I>&gt;<i> tc filter add dev eth1 parent 1:0 protocol ip prio 25 u32 match tcp src
</I>&gt;<i> 0x1f90 0xffff flowid 1:100
</I>
Well, I don't really see what's wrong with this command. Try verifying your
assumptions, are there really packets GOING OUT on eth1 with source port
8080?

&gt;<i> A connection to the above port will yield the default bandwidth of 10Mbit.
</I>&gt;<i> Not the desired effect.
</I>
You might be able to use ipchains or iptables to mark your packets (fwmark),
and try to filter on the mark.

&gt;<i> I have used many examples copied strainght out of the sources, in all of
</I>&gt;<i> them, the IP address matching works, but the TCP matching never does.
</I>
Otherwise ask Jamal Hadi, his address is in the HOWTO. Please forward his
answer to this list (with his permission). Would be good for the archive.

Regards,

bert hubert

-- 
PowerDNS                     Versatile DNS Services  
Trilab                       The Technology People   
'SYN! .. SYN|ACK! .. ACK!' - the mating call of the internet


</PRE>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [LARTC] I can control traffic based on IP ADDRESS but not on PROTOCOL
  2000-10-23 22:31 [LARTC] I can control traffic based on IP ADDRESS but not on PROTOCOL Peter
  2000-10-24 11:41 ` bert
@ 2000-10-24 16:35 ` Peter
  2000-10-26 18:30 ` [LARTC] I can control traffic based on IP ADDRESS but not on Suhail
  2 siblings, 0 replies; 4+ messages in thread
From: Peter @ 2000-10-24 16:35 UTC (permalink / raw)
  To: lartc

<PRE>I will contact Jamal Hadi, thank you for the info.

Is anyone out there currently controlling bandwidth on a protocol basis?



</PRE>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [LARTC] I can control traffic based on IP ADDRESS but not on
  2000-10-23 22:31 [LARTC] I can control traffic based on IP ADDRESS but not on PROTOCOL Peter
  2000-10-24 11:41 ` bert
  2000-10-24 16:35 ` Peter
@ 2000-10-26 18:30 ` Suhail
  2 siblings, 0 replies; 4+ messages in thread
From: Suhail @ 2000-10-26 18:30 UTC (permalink / raw)
  To: lartc

<PRE>Hi Peter,
I was working on this problem and came up with a solution...
 Instead of using
tc filter add dev eth1 parent 1:0 protocol ip prio 25 u32 match tcp src
0x1f90 0xffff flowid 1:100

use :
tc filter add dev eth1 parent 1:0 protocol ip prio 25 u32 match ip dport 0x1f90
0xffff flowid 1:100

This works, because I think the mechanism of  u32 is like :
when it comes across 'match tcp' it  maps this to nexthdr+ 0 ( you can see it with
&quot; tc filter show dev eth1&quot; )
but when it comes across 'match ip &lt;dport&gt;' It maps to offset byte directly so when
you do a tc filter show dev eth1 you see
  match  PATTERN/MASK at 20( or whatever offset you specify, but note that it
doesnt specify nexthdr+...)
This works..
So I presume that there is something wrong with the implementation of nexthdr
..Maybe Jamal or Werner should look into it.

Hope you get along.Feel free to ask for further clarifications.
Suhail
COMET GROUP <A HREF="http://www.comet.columbia.edu">http://www.comet.columbia.edu</A>
Columbia University
New York

Peter Frischknecht wrote:

&gt;<i> I have spent a tremendous amount of time on this one, and I can reproduce
</I>&gt;<i> it.
</I>&gt;<i>
</I>&gt;<i> I set up all of my classes and queues.
</I>&gt;<i> Now is time for the filters.
</I>&gt;<i>
</I>&gt;<i> Let's say that I have a flowid 1:100 which is the handle of a queue with a
</I>&gt;<i> very small bounded isolated bandwidth allocation of 25Kbit.
</I>&gt;<i>
</I>&gt;<i> If I use the following filter:
</I>&gt;<i>
</I>&gt;<i> tc filter add dev eth1 parent 1:0 protocol ip prio 25 u32 match ip src
</I>&gt;<i> 216.79.164.46 flowid 1:100
</I>&gt;<i>
</I>&gt;<i> I get the correct throughtput of 25Kbit.
</I>&gt;<i>
</I>&gt;<i> However, if I attempt to filter by protocol instead, it does not work.
</I>&gt;<i> I will disregard the fact that this filter will manipulate both TCP and UDP
</I>&gt;<i> sessions destined to the specific port.
</I>&gt;<i> I am attaching to a server on port 8080 (0x1f90).
</I>&gt;<i>
</I>&gt;<i> tc filter add dev eth1 parent 1:0 protocol ip prio 25 u32 match tcp src
</I>&gt;<i> 0x1f90 0xffff flowid 1:100
</I>&gt;<i>
</I>&gt;<i> A connection to the above port will yield the default bandwidth of 10Mbit.
</I>&gt;<i> Not the desired effect.
</I>&gt;<i>
</I>&gt;<i> I have used many examples copied strainght out of the sources, in all of
</I>&gt;<i> them, the IP address matching works, but the TCP matching never does.
</I>&gt;<i>
</I>&gt;<i> Any help is greatly appreciated.
</I>&gt;<i>
</I>&gt;<i> Peter Frischknecht
</I>&gt;<i> Empowering Solutions, Inc.
</I>&gt;<i> <A HREF="http://www.empoweringsolutions.com">http://www.empoweringsolutions.com</A>
</I>&gt;<i> (864)654.6544 x103 Phone
</I>&gt;<i> (864)654.0022      Fax
</I>&gt;<i>
</I>&gt;<i> _______________________________________________
</I>&gt;<i> LARTC mailing list / <A HREF="mailto:LARTC@mailman.ds9a.nl">LARTC@mailman.ds9a.nl</A>
</I>&gt;<i> <A HREF="http://mailman.ds9a.nl/mailman/listinfo/lartc">http://mailman.ds9a.nl/mailman/listinfo/lartc</A> HOWTO: <A HREF="http://ds9a.nl/2.4Routing/">http://ds9a.nl/2.4Routing/</A>
</I>


</PRE>

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2000-10-26 18:30 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-10-23 22:31 [LARTC] I can control traffic based on IP ADDRESS but not on PROTOCOL Peter
2000-10-24 11:41 ` bert
2000-10-24 16:35 ` Peter
2000-10-26 18:30 ` [LARTC] I can control traffic based on IP ADDRESS but not on Suhail

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.