Brett Mastbergen <[email protected]> wrote:
> This change allows map expressions on the left side of comparisons:
>
> nft add rule foo bar ip saddr map @map_a == 22 counter
>
> It also allows map expressions as the left side expression of other
> map expressions:
>
> nft add rule foo bar ip saddr map @map_a map @map_b == 22 counter
>
> To accomplish this, some additional context needs to be set during
> evaluation and delinearization. A tweak is also make to the parser
> logic to allow map expressions as the left hand expression to other
> map expressions.
>
> By allowing maps as left side comparison expressions one can map
> information in the packet to some arbitrary piece of data and use
> the equality (or inequality) to make some decision about the traffic,
> unlike today where the result of a map lookup is only usable as the
> right side of a statement (like dnat or snat) that actually uses the
> value as input.
Can you add a test case for this?
FWIW, this appears to work fine:
table inet filter {
map map_a {
type ipv4_addr : mark
elements = { 127.0.0.1 : 0x0000002a }
}
map map_b {
type mark : inet_service
elements = { 0x0000002a : 22 }
}
chain input {
type filter hook input priority filter; policy accept;
ip saddr map @map_a map @map_b 22 counter
}
}
inet filter input
[ meta load nfproto => reg 1 ]
[ cmp eq reg 1 0x00000002 ]
[ payload load 4b @ network header + 12 => reg 1 ]
[ lookup reg 1 set map_a dreg 1 ] # looks up ipv4 addr in map_a
[ lookup reg 1 set map_b dreg 1 ] # looks up mark in map_b
[ cmp eq reg 1 0x00001600 ] # cmp port number from map_b with 22
[ counter pkts 0 bytes 0 ]
... so this looks good to me.
Guess its time for me to work on typeof() keyword again
so we can have strings in named sets.
