> On 23 May 2018, at 23:40, Toke Høiland-Jørgensen <t...@toke.dk> wrote: > <snip> > > Hmm, and we still have an issue with ingress filtering (where cake is > running on an ifb interface). That runs pre-NAT in the conntrack case, > and we can't do the RX trick. Here we do the lookup manually in > conntrack (and this part is actually what brings in most of the > dependencies). Any neat tricks up your sleeve for this case? :)
I wonder here if our terminology with ‘ingress’ is causing confusion. For avoidance of doubt: Typical use case of cake on LAN/WAN router requires two instances. One instance (the egress) is on the WAN interface itself. It is post conntrack and hence uses skb->nfct to work out the real pre-nat source address of the LAN hosts. Since we cannot apply this qdisc to the ingress of our WAN interface we use an IFB to mirror the ingress packets, and then use a cake instance on the ifb interface on its egress path to in essence control the ingress traffic. Cake has two modes, the normal ‘egress’ mode which is designed to be used when controlling egress traffic output, and shapes post any dropped packets. ‘ingress’ mode is designed to be used on the egress of our ingress IFB, where the shaper counts all packets used (well they got here!) even if we decide to drop them a bit later. The ifb positioned cake has the additional fun factor that the conntrack field hasn’t yet been filled in, so the qdisc has to go looking in the conntrack tables itself to see if any NATting has taken place and balance LAN host fairness based on that. As far as I understand it, the flow dissector doesn’t obviously help with working out the pre-NAT addressing as the flow has already been mangled in the egress case, and is awaiting mangling on the ingress case. Kevin
signature.asc
Description: Message signed with OpenPGP
