--- Begin Message ---
> On 23 May 2018, at 23:40, Toke Høiland-Jørgensen <[email protected]> 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
--- End Message ---
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
