[pve-devel] nftables 0.4 and kernel 3.19, still problem with physdevin|out

[Alexandre DERUMIER]

>>Yes I think you can match almost everything in pretty much every table. 
>>Provided they have implemented it ;-) so we'll have to wait for ct to 
>>land in bridge tables before considering switching to nft. 
Yes, we should wait.
Currently I'm just testing it, time to time, to see how it's evolving.)

>>Or does nft provide any other advantage already that would be worth the 
>>effort? 
The vmap feature is really the big change for me. 
(No need to test each tap chain, that make a big difference with a lot of vms)


Also, I'm not sure that all nat/masquerade features are already implemented.




Here a working test : (don't known why, but if need to user oifname && iifname, obriport && ibriport not working)


nft list ruleset
nft flush table bridge filter
nft add table bridge filter
nft add chain bridge filter forward { type filter hook forward priority 200 \; }
nft add chain bridge filter input { type filter hook input priority 200 \; } 
nft add chain bridge filter output { type filter hook output priority 200 \; }  
nft add chain bridge filter tap150i0-OUT
nft add chain bridge filter tap150i1-OUT
nft add chain bridge filter tap150i0-IN
nft add chain bridge filter tap150i1-IN
nft add rule bridge filter forward meta oifname vmap { tap150i0: jump tap150i0-OUT,  tap150i1: jump tap150i1-OUT }
nft add rule bridge filter forward meta iifname vmap { tap150i0: jump tap150i0-IN,  tap150i1: jump tap150i1-IN }
nft add rule bridge filter tap150i0-OUT log prefix \"tap150i0-OUT: \" accept
nft add rule bridge filter tap150i0-IN log prefix \"tap150i0-IN: \" accept
nft add rule bridge filter tap150i1-OUT log prefix \"tap150i1-OUT: \" accept
nft add rule bridge filter tap150i1-IN log prefix \"tap150i1-IN: \" accept
nft add rule bridge filter tap150i0-IN ether type ip tcp dport 80 drop



----- Mail original -----
De: "Wolfgang Bumiller" <w.bumiller at proxmox.com>
À: "aderumier" <aderumier at odiso.com>
Cc: "pve-devel" <pve-devel at pve.proxmox.com>
Envoyé: Lundi 27 Juillet 2015 15:11:18
Objet: Re: [pve-devel] nftables 0.4 and kernel 3.19, still problem with physdevin|out

On Mon, Jul 27, 2015 at 03:01:30PM +0200, Alexandre DERUMIER wrote: 
> Oh, I speak too fast, 
> seem that for tcp traffic in bridge chain, I can see PROTO and port. 
> 
> forward: IN=tap150i0 OUT=fwln150i0 MAC=00:08:7c:bd:ae:40:76:ef:e9:ed:9d:41:08:00 SRC=10.3.95.240 DST=192.168.100.76 LEN=108 TOS=0x00 PREC=0x00 TTL=64 ID=42868 DF PROTO=TCP SPT=22 DPT=49876 WINDOW=291 RES=0x00 ACK PSH URGP=0 MARK=0x7b 
> 
> So, it's really only missing conntrack here. 

Yes I think you can match almost everything in pretty much every table. 
Provided they have implemented it ;-) so we'll have to wait for ct to 
land in bridge tables before considering switching to nft. 
Or does nft provide any other advantage already that would be worth the 
effort?