Re: Operation not supported when adding jump command

["Serguei Bezverkhi (sbezverk)" <sbezverk@cisco.com>]

Hello Phil,

Thanks a lot for your suggestions, I will refactor using approach.

Best regards
Serguei

On 2019-11-28, 8:08 AM, "n0-1@orbyte.nwl.cc on behalf of Phil Sutter" <n0-1@orbyte.nwl.cc on behalf of phil@nwl.cc> wrote:

    Hi Serguei,
    
    On Thu, Nov 28, 2019 at 01:22:17AM +0000, Serguei Bezverkhi (sbezverk) wrote:
    > Please see below the list of nftables rules the code generate to mimic only filter chain portion of kube proxy.
    > 
    > Here is the location of code programming these rules. 
    > https://github.com/sbezverk/nftableslib-samples/blob/master/proxy/mimic-filter/mimic-filter.go
    > 
    > Most of rules are static, will be programed  just once when proxy comes up, with the exception is 2 rules in k8s-filter-services chain. The reference to the list of ports can change. Ideally it would be great to express these two rules with a single rule and a vmap, where the key must be service's ip AND service port, as it is possible to have a single service IP that can be associated with several ports and some of these ports might have an endpoint and some do not. So far I could not figure it out. Appreciate your thought/suggestions/critics. If you could file an issue for anything you feel needs to be discussed, that would be great.
    
    What about something like this:
    
    | table ip t {
    | 	map m {
    | 		type ipv4_addr . inet_service : verdict
    | 		elements = { 192.168.80.104 . 8989 : goto do_reject }
    | 	}
    | 
    | 	chain c {
    | 		ip daddr . tcp dport vmap @m
    | 	}
    | 
    | 	chain do_reject {
    | 		reject with icmp type host-unreachable
    | 	}
    | }
    
    For unknown reasons reject statement can't be used directly in a verdict
    map, but the do_reject chain hack works.

This is exactly what I was looking for, it is just I never knew you could combine address and port in the key..
    
    > sudo nft list table ipv4table
    > table ip ipv4table {
    > 	set svc1-no-endpoints {
    > 		type inet_service
    > 		elements = { 8989 }
    > 	}
    > 
    > 	chain filter-input {
    > 		type filter hook input priority filter; policy accept;
    > 		ct state new jump k8s-filter-services
    > 		jump k8s-filter-firewall
    > 	}
    > 
    > 	chain filter-output {
    > 		type filter hook output priority filter; policy accept;
    > 		ct state new jump k8s-filter-services
    > 		jump k8s-filter-firewall
    > 	}
    
    Same ruleset for input and output? Seems weird given the daddr-based
    filtering in k8s-filter-services.
    
I will review one more time k8s filter input/output to confirm if I got something wrong.

    Cheers, Phil