[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lartc
Subject:    Re: IFB ingress traffic shaping with NAT
From:       Benjamin Kiessling <mittagessen () l ! unchti ! me>
Date:       2013-04-22 19:26:48
Message-ID: 20130422192648.GA31971 () spatula ! westnetz ! org
[Download RAW message or body]

Hi,

On 04/22, Mike Schmidt wrote:
> Can anyone provide a short example as to how using connmarks would
> work, given that we need to support 2000+ clients (with potentially
> different tc classes each).
> Or is there a better way to get set up ifb after inbound NAT?

What we are doing is using a single ifb device and redirecting traffic
from the "downlink" ports to the ifb, i.e. uplink is eth0.1999,
customers are attached to eth0.2000, eth0.2001.... On the customer
interfaces we attach a PRIO qdisc which queues everything into the same
queu and a filter which redirects egress traffic to the ifb device:

tc qdisc add dev eth0.2128 root handle 1: prio priomap 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
tc filter add dev eth0.2128 parent 1:0 protocol ip priority 10 u32 match u32 0 \
                0 flowid 1: action mirred egress redirect dev ifb0

The PRIO is there because a filters can only be attached to classful
qdiscs, so we simulate a simple pfifo and attach the filter to the
single queue that actually holds packets.

On ifb0 the usual class structure is added. A filter redirects the
un-NATed packets to its respective class:

tc filter add dev ifb0 parent 1:0 protocol ip u32 match ip dst 172.19.128.0/24 \
                flowid 1:2128

Regards,
Ben

PS: At [0] there's the whole script.

[0] https://github.com/westnetz/qos-script/blob/master/qos-hfsc-sfq.sh

[Attachment #3 (application/pgp-signature)]
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[prev in list] [next in list] [prev in thread] [next in thread]