Thank you for all the responses so far. Sadly, none of them directly address my problem, that of shaping traffic inbound on a WAN based on the local (de-NATted address). It turns out that for both directions, based on the network path shown in http://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg, the ingress and egress qdiscs are outside of the NAT actions, so on a WAN port, neither qdiscs can shape traffic based on the local (before NAT) addresses. This was easily handled by IMQ, since there we could use iptables to redirect traffic to IMQ at whatever point in the network traversal we wanted. This is not the case with ifb, which has no netfilter hooks. So far, I'm not entirely confident with CONNMARKs, since I need to be able to handle thousands of clients dynamically, so assigning and saving/restoring CONNMARKs kust seems to be a lot of work and potentially error prone. Since in our case we use a bridge device br0 to merge local traffic from several sources, I decided to attach my ingress and egress qdiscs to br0 and a few other vlan interfaces. Here, the ifb devices serve two purposes: 1. On the server's inbound side (viewed as br0/vlan1...egress) to merge the traffic through a single ifb1 device 2. On the server's outbound side (viewed as br0/vlan1... ingress) to use full tc traffic shaping through a single ifb0 device Here is a little picture of the network situation we have (before ifb) VLANx.. <-> some clients. WAN <NAT>(eth1) <-> BR0 <-> some other clients ETHy... <-> some more clients I don't know how this will affect the traffic flowing through eth1 (the WAN device) to the local clients, whether there will be buffering or other problems. As soon as I have a running model, I will report back as to the results. -- Mike SCHMIDT CTO Intello Technologies Inc. mike.schmidt@xxxxxxxxxxx Canada: 1-888-404-6261 x320 USA: 1-888-404-6268 x320 Mobile: 514-409-6898 www.intello.com -- To unsubscribe from this list: send the line "unsubscribe lartc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
