> They don't. If you accept in inet and drop in bridge then > bridged packet will be dropped as its not passed up to network layer. > > Also, packets that arrive on a bridge will only make it to > ipv4/ipv6/inet input if they are delivered to local machine rather than > bridged. > > ipv4/ipv6/inet families are network layer, bridge family is link layer, > netdev ingress is right after ingress qdisc. > > arp is also at network layer, but only for arp packets. > > An incoming packet will go through 3 types: > ingress -> prerouting -> input > > ingress is only supported by netdev family. > prerouting is supported by bridge, ipv4, ipv6 and inet family. > same for input. > > A packet will never pass through both ipv4 and ipv6 families > (or arp for that matter). > > A packet can pass through bridge (linklayer) and ipv4/ipv6/inet/arp > (network layer) if its locally delivered, or if it is sent from local > machine (in this case, it is ipv4/ipv6/inet local -> postrouting > bridge output -> bridge postrouting. > > Also see: > https://en.wikipedia.org/wiki/Netfilter#/media/File:Netfilter-packet-flow.svg Thank you. That illustration helps a lot with the visualization. I have been tinkering around with |netdev| and a global ingress drop policy in order stop packets early on but that is stopping all outbound traffic too (not reaching the network layer). And it would also prevent packets to reach NAT apparently. So it seems not the appropriate place for a global drop policy. With "netdev ingress being right after ingress qdisc" it appears though to be including |bridge check| as well because with a global |netdev| drop policy in place and |bridge| accept policies such bridge traffic is not being dropped by |netdev|. Suppose that has been confusing me a bit and is not so clear from the nft wiki. And makes me wonder about "This location is ideal to drop packets that result from DDOS attacks given this is very early in the packet path". To my understanding one would have to be first aware of the packet type used in an DDOS attack and then stipulate a |netdev| drop policy for such particular packet types. The other practical use of |netdev| appears to be load balancing but that is way beyond my realm. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
