* shape traffic on tun interfaces
@ 2010-07-31 22:09 Franchoze Eric
2010-08-01 10:27 ` Alexander Clouter
2010-08-02 7:46 ` Franchoze Eric
0 siblings, 2 replies; 4+ messages in thread
From: Franchoze Eric @ 2010-07-31 22:09 UTC (permalink / raw)
To: lartc; +Cc: netdev
Do we have any interface to shape traffic per destination IP? The standrad HTB shapes it per device, which is not suitable for case if limitation required per destination IP. For example openvpn server which servers about 3000 clients and has 10 internal tun interfases (tun0-tun9). Of course it is possible to do it on application level (vpn), but I would prefer any system solution for this. iptables with --limit does not work in this case because it will simple drop packets. Did somebody work on such task?
Eric.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: shape traffic on tun interfaces
2010-07-31 22:09 shape traffic on tun interfaces Franchoze Eric
@ 2010-08-01 10:27 ` Alexander Clouter
2010-08-02 7:46 ` Franchoze Eric
1 sibling, 0 replies; 4+ messages in thread
From: Alexander Clouter @ 2010-08-01 10:27 UTC (permalink / raw)
To: netdev; +Cc: lartc
Franchoze Eric <franchoze@yandex•ru> wrote:
>
> Do we have any interface to shape traffic per destination IP? The
> standrad HTB shapes it per device, which is not suitable for case if
> limitation required per destination IP. For example openvpn server
> which servers about 3000 clients and has 10 internal tun interfases
> (tun0-tun9).
>
Do the QoS on your next hop router or on the interface all your
de-encapsulated VPN traffic flows over (ie. 'eth0') instead.
Cheers
--
Alexander Clouter
.sigmonster says: He who always plows a straight furrow is in a rut.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: shape traffic on tun interfaces
2010-07-31 22:09 shape traffic on tun interfaces Franchoze Eric
2010-08-01 10:27 ` Alexander Clouter
@ 2010-08-02 7:46 ` Franchoze Eric
2010-08-02 8:36 ` Changli Gao
1 sibling, 1 reply; 4+ messages in thread
From: Franchoze Eric @ 2010-08-02 7:46 UTC (permalink / raw)
To: alex; +Cc: lartc, netdev
>Do the QoS on your next hop router
There is no next router. And QoS should be on the same machine.
>or on the interface all your de-encapsulated VPN traffic flows over (ie. 'eth0') instead.
It is not a problem to find interface with de-encapsulated traffic. The problem is that tc rules should be written accoring to network device.
And it is really uncinvinient clone this rules which are differ only with destination IP.
For example look here. It's needed to create subclass for each destination IP.
#class
tc class add dev $DEV parent 1: classid 1:1 htb rate ${SPEED}kbit
#subclass
# high priority traffic (where we get money, http for example)
tc class add dev $DEV parent 1:1 classid 1:2 htb rate ${SPEED}kbit ceil ${SPEED}kbit prio 0
# low priority trafic - no adds - now money - low speed
tc class add dev $DEV parent 1:1 classid 1:3 htb rate ${SPEED}/2kbit ceil ${SPEED}kbit prio 1
#handle
tc qdisc add dev $DEV parent 1:2 handle 2: sfq perturb 10
tc qdisc add dev $DEV parent 1:3 handle 3: sfq perturb 10
#connect with
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 2 fw flowid 1:1001
tc filter add dev $DEV parent 1:0 prio 0 protocol ip handle 3 fw flowid 1:1002
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: shape traffic on tun interfaces
2010-08-02 7:46 ` Franchoze Eric
@ 2010-08-02 8:36 ` Changli Gao
0 siblings, 0 replies; 4+ messages in thread
From: Changli Gao @ 2010-08-02 8:36 UTC (permalink / raw)
To: Franchoze Eric; +Cc: alex, lartc, netdev
On Mon, Aug 2, 2010 at 3:46 PM, Franchoze Eric <franchoze@yandex•ru> wrote:
>>Do the QoS on your next hop router
> There is no next router. And QoS should be on the same machine.
>
>>or on the interface all your de-encapsulated VPN traffic flows over (ie. 'eth0') instead.
>
> It is not a problem to find interface with de-encapsulated traffic. The problem is that tc rules should be written accoring to network device.
try ifb:
config IFB
tristate "Intermediate Functional Block support"
depends on NET_CLS_ACT
---help---
This is an intermediate driver that allows sharing of
resources.
To compile this driver as a module, choose M here: the module
will be called ifb. If you want to use more than one ifb
device at a time, you need to compile this driver as a module.
Instead of 'ifb', the devices will then be called 'ifb0',
'ifb1' etc.
Look at the iproute2 documentation directory for usage etc
--
Regards,
Changli Gao(xiaosuo@gmail•com)
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2010-08-02 8:37 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-07-31 22:09 shape traffic on tun interfaces Franchoze Eric
2010-08-01 10:27 ` Alexander Clouter
2010-08-02 7:46 ` Franchoze Eric
2010-08-02 8:36 ` Changli Gao
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox