On 10/12/2011 05:25 PM, David Stevens wrote:
Stefan Berger<stef...@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
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
