Re: Delivery Status Notification (Failure)

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Mike Schmidt wrote:
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.

I am not sure about your exact setup - but the only time that imq beats ifb is if the box you are doing the shaping on generates traffic its self which is nated to an IP shared with forwarded traffic.

If the only traffic that needs shaping is forwarded then you should be able to do it with ifb.

To get round the wan egress case of ifb hooking after snat just mark the traffic with netfilter according to local addresses and match the marks.

--
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




[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux