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:
pgp4it0Z47VDv.pgp
Description: PGP signature
