On 10/30/2012 03:48 AM, Simon Hobson wrote:
> Tom Eastep wrote:
>
>>   > Am I right in thinking that this would translate to the following in
>>   > tcclasses ?
>>   > ...
>>
>> Yes.
>
>
> Champion.€
>
>
>
>
>> Yes, assuming that you can classify incoming traffic based on packets as
>> they look on the wire.
>
>
> I'm currently using loads of tc filters like this :
> run_tc filter add dev ethint parent 100:0 protocol ip prio 1
>     u32 match ip dst a.b.c.x/32 flowid 100:117
> run_tc filter add dev ethext parent 1:0 protocol ip prio 1
>     u32 match ip src a.b.c.x/32 flowid 1:17
> run_tc filter add dev ethint parent 100:0 protocol ip prio 1
>     u32 match ip dst a.b.c.x/32 match ip dport 25 0xffff flowid 100:118
> run_tc filter add dev ethext parent 1:0 protocol ip prio 1
>     u32 match ip src a.b.c.x/32 match ip dport 25 0xffff flowid 1:18
>
>
> It's not too bad where there's a separate bandwidth allocation for a
> single customer or device, but in some cases there are multiple
> customers/devices sharing one allocation - so it's gets somewhat
> repetitive and I suspect inefficient.
>
> I still haven't fully got my head around
> http://shorewall.net/traffic_shaping.htm€, but as I read it, I should
> be able to do something like this :
>
> #MARK    SOURCE   DESTINATION PROTOCOL PORT(S)  CLIENT  USER/ TEST
> #                                               PORT(S) GROUP
>
> # If the connection already has a mark, use it and skip the rest of the rules
> RESTORE  0.0.0.0/0  0.0.0.0/0  all     -        -       -     0
> CONTINUE 0.0.0.0/0  0.0.0.0/0  all     -        -       -     !0
>
>
> # Customer/group A
> 12       a.b.c.x/32 0.0.0.0/0  all     -        -       -     !0
> 12       a.b.c.y/32 0.0.0.0/0  all     -        -       -     !0
> 12       a.b.c.z/32 0.0.0.0/0  all     -        -       -     !0
> 11       0.0.0.0/0  0.0.0.0/0  icmp    echo-request -   -     12
> 11       0.0.0.0/0  0.0.0.0/0  icmp    echo-reply   -   -     12
> 13       0.0.0.0/0  0.0.0.0/0  tcp     110      -       -     12
> 13       0.0.0.0/0  0.0.0.0/0  tcp     -        110     -     12
>
> 13       0.0.0.0/0  0.0.0.0/0  tcp     143      -       -     12
> 13       0.0.0.0/0  0.0.0.0/0  tcp     -        143     -     12
>
> 14       0.0.0.0/0  0.0.0.0/0  tcp     25       -       -     12
> 14       0.0.0.0/0  0.0.0.0/0  tcp     -        25      -     12
>
>
> # Repeat above for each group of hosts ...
>
> # Assuming we've marked the packet, now save the mark to the connection
> SAVE     0.0.0.0/0  0.0.0.0/0  all     -        -       -     !0
>
> One aspect I'm unclear about ...
>   From the above page, I see these two bits of information :
>
>> classify
>> If specified, classification of traffic into the various classes is
>> done by CLASSIFY entries in /etc/shorewall/tcrules or by entries in
>> /etc/shorewall/tcfilters. No MARK value will be associated with
>> classes on this interface.
>
>> IFB devices automatically get the classify option.
>
> €So as I read that, because I'm using an IFB device, I can't use the
> packet marks as above. So would this work to then 'convert' marks to
> flows :
>
> 1:11     0.0.0.0/0  0.0.0.0/0  all     -        -       -     11
> CONTINUE 0.0.0.0/0  0.0.0.0/0  all     -        -       -     11
>
> 1:12     0.0.0.0/0  0.0.0.0/0  all     -        -       -     12
> CONTINUE 0.0.0.0/0  0.0.0.0/0  all     -        -       -     12
>
> 1:13     0.0.0.0/0  0.0.0.0/0  all     -        -       -     13
> CONTINUE 0.0.0.0/0  0.0.0.0/0  all     -        -       -     13
>
> 1:14     0.0.0.0/0  0.0.0.0/0  all     -        -       -     14
> CONTINUE 0.0.0.0/0  0.0.0.0/0  all     -        -       -     14
>
>
> Or is there a more efficient way of doing things ?

When you use an IFB, you must use filters (/etc/shorewall/tcfilters) to 
do the classification of inbound traffic. There is no Netfilter hook 
prior to the traffic being passed to the IFB, so tcrules in any form 
won't work.

For outbound traffic, your tcrules approach works fine. It also works 
fine if you continue to do the shaping on your internal interface rather 
than on an IFB.

>
> NB - I'm hoping to script at least part of this - at least tcclasses,
> and possibly the host matching rules of tcrules. This is because I
> have three systems to keep in sync :
> two routers (active and standby), both firewall rules and data
> collection scripts
> data collection and graphing (rrd) on third machine
>
> The idea is to have a text file with a list of class groups with
> their traffic rates, and a list of hosts and the class group they
> should be in. Then a script can build part of the config for both
> routers and the graphing from these lists.
>
>
> PS - while I'm struggling to get my head round the user end of this,
> I am in awe that you can keep track of how this works behind the
> scenes !
>

I struggle to keep this traffic shaping stuff straight in my head as well.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
Shorewall-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Reply via email to