similar to: Action 4 device ifb0 ifindex 7

Hi all, I''m having a hell of a time getting tc and IFBs to co-operate. I''ve copied the following from http://linux-net.osdl.org/index.php/IFB: -- export TC="/sbin/tc" $TC qdisc add dev ifb0 root handle 1: prio $TC qdisc add dev ifb0 parent 1:1 handle 10: sfq $TC qdisc add dev ifb0 parent 1:2 handle 20: tbf rate 20kbit buffer 1600 limit 3000 $TC qdisc add dev ifb0

Hello What I''m looking for is how to configure the Linux QoS module to do global rate limitation for two (or more) 802.1q pseudo network devices. I naturally suppose there is a possibility with IFB. I don''t want to use IMQ because it''s not integrated to my kernel v2.6.21.1 and I didn''t find IMQ patches for it nor for the iptables package I use (v1.3.7).

Hello Tom! After i read and analyze some docs about IFB i decide that for implement this feature in Shorewall not need more efforts (of course i may be wrong). If we have 'ifb0' device then we must activate ingress discipline on real device (f.e. eth2) and redirect 'egress' from it to 'ifb0'. tc qdisc add dev eth2 ingress tc filter add dev eth2 parent ffff: protocol ip

I''ve network with NATed hosts. I want to catch only all traffic going from my server, but I don''t want catch NATed traffic from LAN. I need only traffic going from/to my server (traffic from INPUT, OUTPUT chain in iptables) (like SSH, postfix, WWW or proxy). This is throw all traffic from my LAN to IFB: $TC qdisc add dev $iface_lan handle ffff: ingress $TC qdisc add dev

Hello! My goal is to setup an ingress traffic shaping on my PPPOE DSL line with ifb. My old imq stuff used iptables marks (like ''iptables -t mangle -A PREROUTING -p tcp --sport 22 -m length --length :500 -j MARK --set-mark 31'') to classify the traffic and since i am lazy, i tried to to reuse them with ifb. But no luck: iptables marks the packets well, but tc

I have two boxes for the purpose of testing traffic control and my knowledge thereof (which is at the inkling stage). The boxes are connected by 100Mbit ethernet cards via a switch. For egress traffic via eth0 I achieve a throughput that is close to the specified CEILing, particularly for values above 1mbit. Ingress traffic does not seem so well behaved. Above about 1mbit rates achieved are

I''m trying to set up a traffic control on ingress attaching a egress qdisc to the ifb device. The idea is to use a RED algorithm instead of policing the incoming traffic. After trying with tc-red and not obtaining the expected results, I decided to try with something easier, and use htb as bottleneck: ifconfig ifb0 up tc qdisc del dev $dev ingress tc qdisc del dev ifb0 root tc qdisc add

On 2017?08?30? 11:11, Willem de Bruijn wrote: > On Tue, Aug 29, 2017 at 9:45 PM, Jason Wang <jasowang at redhat.com> wrote: >> >> On 2017?08?30? 03:35, Willem de Bruijn wrote: >>> On Fri, Aug 25, 2017 at 9:03 PM, Willem de Bruijn >>> <willemdebruijn.kernel at gmail.com> wrote: >>>> On Fri, Aug 25, 2017 at 7:32 PM, Michael S. Tsirkin <mst

On 2017?08?30? 11:11, Willem de Bruijn wrote: > On Tue, Aug 29, 2017 at 9:45 PM, Jason Wang <jasowang at redhat.com> wrote: >> >> On 2017?08?30? 03:35, Willem de Bruijn wrote: >>> On Fri, Aug 25, 2017 at 9:03 PM, Willem de Bruijn >>> <willemdebruijn.kernel at gmail.com> wrote: >>>> On Fri, Aug 25, 2017 at 7:32 PM, Michael S. Tsirkin <mst

Hi all, I''m having a hell of a time getting my IFB to work. I know I''ve done this before, so I''m missing something stupid. Can anybody tell me what it might be? Configs as follows: -------- #!/bin/sh modprobe ifb numifbs=1000 modprobe act_mirred modprobe 8021q brctl addbr br0 brctl setfd br0 0 brctl stp br0 off brctl addif br0 eth1 brctl addif br0 eth2 ifconfig eth1

Hi all. I''m using Jamal''s ifb virtual interface from new kernel. Redirecting incoming traffic from external interface like that: # tc [blahbla] match u32 0 0 flowid 1:0 action mirred egress redirect dev ifb0 to ifb to shape it. The problem is that I''m using MASQUERADE by netfilter also. That redirected traffic coming from internet gets to ifb _before_ DNAT is done.

I''ve made some tests... eth2 is my internal interface, LAN is connected here. Before I had IMQ device in AB mode... PREROUTING [A]fter NAT, POSTROUTING [B]efore NAT. I want the same situation on ifb. I do this in this way: --- # incoming traffic here from LAN is before NAT tc qdisc add dev eth2 handle ffff: ingress # outcoming traffic here from WAN is after NAT tc qdisc add dev eth2

From: Willem de Bruijn <willemb at google.com> Vhost-net has a hard limit on the number of zerocopy skbs in flight. When reached, transmission stalls. Stalls cause latency, as well as head-of-line blocking of other flows that do not use zerocopy. Instead of stalling, revert to copy-based transmission. Tested by sending two udp flows from guest to host, one with payload of

From: Willem de Bruijn <willemb at google.com> Vhost-net has a hard limit on the number of zerocopy skbs in flight. When reached, transmission stalls. Stalls cause latency, as well as head-of-line blocking of other flows that do not use zerocopy. Instead of stalling, revert to copy-based transmission. Tested by sending two udp flows from guest to host, one with payload of

On Tue, 22 Feb 2011 11:15:39 +0100 "PIOTREK H." <komarekmz@tlen.pl> wrote: > Welcome > > I have a problem with the new iproute "iproute2-2.6.37.tar.bz2 07-Jan-2011 9:18 (the problem from version 2010 to 2011). > Three problems: > a) with filters for UDP traffic > problem affects only the queuing traffic to the machine on which you work qos > In the case

On Thu, Aug 31, 2017 at 11:25 PM, Jason Wang <jasowang at redhat.com> wrote: > > > On 2017?08?31? 22:30, Willem de Bruijn wrote: >>> >>> Incomplete results at this stage, but I do see this correlation between >>> flows. It occurs even while not running out of zerocopy descriptors, >>> which I cannot yet explain. >>> >>> Running

On 2017?09?28? 08:25, Willem de Bruijn wrote: > From: Willem de Bruijn <willemb at google.com> > > Vhost-net has a hard limit on the number of zerocopy skbs in flight. > When reached, transmission stalls. Stalls cause latency, as well as > head-of-line blocking of other flows that do not use zerocopy. > > Instead of stalling, revert to copy-based transmission. > >

On Wed, Sep 27, 2017 at 08:25:56PM -0400, Willem de Bruijn wrote: > From: Willem de Bruijn <willemb at google.com> > > Vhost-net has a hard limit on the number of zerocopy skbs in flight. > When reached, transmission stalls. Stalls cause latency, as well as > head-of-line blocking of other flows that do not use zerocopy. > > Instead of stalling, revert to copy-based

On Fri, Sep 29, 2017 at 3:38 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Wed, Sep 27, 2017 at 08:25:56PM -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn <willemb at google.com> >> >> Vhost-net has a hard limit on the number of zerocopy skbs in flight. >> When reached, transmission stalls. Stalls cause latency, as well as >>

On Fri, Sep 29, 2017 at 3:38 PM, Michael S. Tsirkin <mst at redhat.com> wrote: > On Wed, Sep 27, 2017 at 08:25:56PM -0400, Willem de Bruijn wrote: >> From: Willem de Bruijn <willemb at google.com> >> >> Vhost-net has a hard limit on the number of zerocopy skbs in flight. >> When reached, transmission stalls. Stalls cause latency, as well as >>