<html>
    <head>
      <base href="https://bugzilla.netfilter.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - nftables - dynamic update for verdict map from the packet path"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1736#c16">Comment # 16</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - nftables - dynamic update for verdict map from the packet path"
   href="https://bugzilla.netfilter.org/show_bug.cgi?id=1736">bug 1736</a>
              from <span class="vcard"><a class="email" href="mailto:dinhtrason@gmail.com" title="dinhtrason@gmail.com">dinhtrason@gmail.com</a>
</span></b>
        <pre>Jumping always to chain 'candidate-endpoint-x' prior to looking up the affinity
map seems to be a trick that helps update the timeout of the cached source IPs.
It looks a bit unusual, but seems to work fine.

There are two options suggested so far:

1/ Use two maps with 'ct mark' to lookup the target endpoint 

table ip loadbalancer {
        map affinityMapToEP {
                type ipv4_addr : mark
                size 65535
                flags dynamic,timeout
                timeout 4m
                elements = { 192.168.0.156 timeout 4m expires 3m58s644ms :
0x00000002 }
        }

        map affinityGotoChain {
                type mark : verdict
                flags dynamic
                elements = { 0x00000001 : goto endpoint-1, 0x00000002 : goto
endpoint-2 }
        }

        chain endpoint-1 {
                update @affinityMapToEP { ip saddr : 0x00000001 }
                meta l4proto tcp dnat to 11.0.2.1:5001
        }

        chain endpoint-2 {
                update @affinityMapToEP { ip saddr : 0x00000002 }
                meta l4proto tcp dnat to 11.0.2.2:5001
        }

        chain service-ABC {
                ct mark set ip saddr map @affinityMapToEP
                ct mark vmap @affinityGotoChain
                numgen random mod 2 vmap { 0 : goto endpoint-1, 1 : goto
endpoint-2 }
        }

        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
                tcp dport 32001 goto service-ABC
        }
}

2/ Use one map only and DNAT directly to endpoint address

table ip loadbalancer {
        map affinity-mappings {
                type ipv4_addr : ipv4_addr
                size 65535
                flags dynamic,timeout
                timeout 4m
                elements = { 192.168.0.156 timeout 4m expires 3m58s702ms :
11.0.2.1 }
        }

        chain endpoint-1 {
                update @affinity-mappings { ip saddr : 11.0.2.1 }
        }

        chain endpoint-2 {
                update @affinity-mappings { ip saddr : 11.0.2.2 }
        }

        chain service-ABC {
                numgen random mod 2 vmap { 0 : jump endpoint-1, 1 : jump
endpoint-2 }
                meta l4proto tcp dnat to ip saddr map @affinity-mappings:5001
        }

        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
                tcp dport 32001 goto service-ABC
        }
}

I verified both options. They work for my case with some PROS and CONS. I will
need to tailor and promote one of them to k8s community.

Thanks again for your support with the detailed examples.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are watching all bug changes.</li>
      </ul>
    </body>
</html>