> On 8 Apr 2019, at 23:39, Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote:
>
> Hi Kevin,
>
> On Sun, Mar 24, 2019 at 02:23:45PM +0000, Kevin 'ldir' Darbyshire-Bryant wrote:
>> savedscp is a method of storing the DSCP of an ip packet into conntrack
>> mark. In combination with a suitable tc filter action (conndscp but may
>> end up being integrated into connmark) DSCP values are able to be stored
>> on egress and restored on ingress across links that otherwise alter or
>> bleach DSCP.
>>
>> This is useful for qdiscs such as CAKE which are able to shape according
>> to policies based on DSCP.
>>
>> Ingress classification is traditionally a challenging task since
>> iptables rules haven't yet run and tc filter/eBPF programs are pre-NAT
>> lookups, hence are unable to see internal IPv4 addresses as used on the
>> typical home masquerading gateway.
>>
>> The ingress problem is solved by the tc filter, but the tc people didn't
>> like the idea of tc setting conntrack mark values, though they are ok
>> with reading conntrack values and hence restoring DSCP from conntrack
>> marks.
>>
>> x_tables CONNMARK with the new savedscp action solves the problem of
>> storing the DSCP to the conntrack mark.
>>
>> It accepts 2 parameters. The mark is a 32bit value with usually one
>> bit set. This bit is set when savedscp saves the DSCP to the mark.
>> This is useful to implement a 'one shot'
>> iptables based classification where the 'complicated' iptables rules are
>> only run once to classify the connection on initial (egress) packet and
>> subsequent packets are all marked/restored with the same DSCP. A mark
>> of zero disables the setting of a status bit/s.
>>
>> The mask is a 32bit value of at least 6 contiguous bits and represents
>> the area where the DSCP will be stored.
>>
>> e.g.
>>
>> iptables -A QOS_MARK_eth0 -t mangle -j CONNMARK --savedscp-mark 0x01000000/0xfc000000
>>
>> Would store the DSCP in the top 6 bits of the 32bit mark field, and use
>> the LSB of the top byte as the 'DSCP has been stored' marker.
>
> I'd prefer we explore how to express this in nftables, I think the
> main problem here is that we do not support for datatype compatibility
> / casting yet, hence dscp cannot be assign to the mark. But we only
> need to update userspace code to achieve this.
>
> Thanks.
Hi Pablo,
Thanks for getting back to me. I know nothing of nftables so this will be
‘interesting’. I have a v2 of the patch with a very minor tweak that I will
send tomorrow and I also have a userspace ‘iptables’ patch that shows the
user side of things if it will help.
For avoidance of doubt, the two values passed by —savedscp-mark are both
32 bit bit masks. One must be a contiguous 6 bit field and specifies where
in the connmark field to store that packet’s DSCP value. It does not specify
the DSCP value itself.
The second value is again (usually) a single bit mask and specifies a bit in
the connmark field that is SET by the —savedscp-mark action.
nftables userspace must already have a method of passing 32bit bitmasks?
e.g. a ‘dscpmask’ of 0xfc000000 specifies to store the packet’s dscp field in
the top 6 bits of the conntrack connmark:
———0xFC—————————0000000-—
|TOP 6 bits | ~~~~~~~~~~~~~
———————————————————
^
| shifted as required
————
|
-diffserv field -
| 6 bits DSCP |
-----------------
Hopefully I have not misunderstood your points?!
Cheers,
Kevin D-B
gpg: 012C ACB2 28C6 C53E 9775 9123 B3A2 389B 9DE2 334A
