On 10/12/2011 05:25 PM, David Stevens wrote:
Stefan Berger<stefanb@linux.vnet.ibm.com> wrote on 10/12/2011 02:02:59 PM:
The problem we're having at the moment is that it's not possible to evaluate fields of packets that may have more than one possible value. This is the general problem, the specific one being allowing multiple MAC or IP addresses.
Stefan, Yes, this is why for this patchset I've added "RETURN" and made the address checks be "if match return" and a default drop at the end. This code already supports multiple IP addresses for DHCP snooping, static IP addresses (new to this version) and a combination of the two (if both "IP" is set and "ip_learning=dhcp". Sample output using multiple static addresses below. The same model can be applied to user-generated filters with:
<do a series of checks using RETURN for acceptable packets> -j DROP
If the user filter does "RETURN", it'll apply other tests as well. If it does "ACCEPT"/"DROP", it'll accept or drop despite any other conditions. I'm not sure I see any need for other tables here, though-- can you elaborate? +-DLS
Basically I would like to get away from having a hardcoded representation of the names of filters inside the code. We now have 4 such filters, arp, rarp, ipv4 and ipv6 and you are adding 2 more arpmac and arpip. For ipv6 we would again need to add more. I think the names of the filters should be picked up from the XML and then in some way sorted and have them generate the rules -j I-vnet0-mac -p IPv4 -j I-vnet0-ipv4 -p ARP -j I-vnet0-arpmac -p ARP -j I-vnet0-arpip -p 0x8035 -j I-vnet0-rarp in the right order. i.e., ipv4 before ipv6 before arpmac before arpip before rapr and 'arp' somewhere in between. This and later on an introduction of an action 'jump' or 'goto' with a target would then provide more flexibility for the user to build even more complex filters. I'll look into getting rid of the bit fields that I have been using so far and try to collect the names of filters. I guess they would have to be given an implicit 'priority' so they are ordered in that way above -- so maybe some of the filters are known to the system and have an implicit priority while others will have to be given a priority. Comments? Stefan
lab1.dls 226 # ebtables -t nat -L Bridge table: nat
Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j libvirt-I-vnet0
Bridge chain: OUTPUT, entries: 0, policy: ACCEPT
Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT -o vnet0 -j libvirt-O-vnet0
Bridge chain: libvirt-I-vnet0, entries: 9, policy: ACCEPT -j I-vnet0-mac -p IPv4 -j I-vnet0-ipv4 -p ARP -j I-vnet0-arpmac -p ARP -j I-vnet0-arpip -p 0x8035 -j I-vnet0-rarp -p 0x835 -j ACCEPT -p IPv4 -j ACCEPT -p ARP -j ACCEPT -j DROP
Bridge chain: libvirt-O-vnet0, entries: 5, policy: ACCEPT -p IPv4 -j O-vnet0-ipv4 -p 0x8035 -j O-vnet0-rarp -p IPv4 -j ACCEPT -p ARP -j ACCEPT -j DROP
Bridge chain: I-vnet0-mac, entries: 1, policy: DROP -s 54:0:0:0:0:1 -j RETURN
Bridge chain: I-vnet0-ipv4, entries: 5, policy: DROP -p IPv4 --ip-src 10.0.0.1 -j RETURN -p IPv4 --ip-src 0.0.0.0 --ip-proto udp --ip-sport 68 -j RETURN -p IPv4 --ip-src 11.0.0.0/24 -j RETURN -p IPv4 --ip-src 10.0.0.3 -j RETURN -p IPv4 --ip-src 10.0.0.4 -j RETURN
Bridge chain: O-vnet0-ipv4, entries: 1, policy: DROP -j ACCEPT
Bridge chain: I-vnet0-arpmac, entries: 1, policy: DROP -p ARP --arp-mac-src 54:0:0:0:0:1 -j RETURN
Bridge chain: I-vnet0-arpip, entries: 5, policy: DROP -p ARP --arp-ip-src 10.0.0.1 -j RETURN -p ARP --arp-ip-src 0.0.0.0 -j RETURN -p ARP --arp-ip-src 11.0.0.0/24 -j RETURN -p ARP --arp-ip-src 10.0.0.3 -j RETURN -p ARP --arp-ip-src 10.0.0.4 -j RETURN
Bridge chain: I-vnet0-rarp, entries: 1, policy: DROP -p 0x8035 -s 54:0:0:0:0:1 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 54:0:0:0:0:1 --arp-mac-dst 54:0:0:0:0:1 -j ACCEPT
Bridge chain: O-vnet0-rarp, entries: 1, policy: DROP -p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 54:0:0:0:0:1 --arp-mac-dst 54:0:0:0:0:1 -j ACCEPT