<html><body> <tt>Stefan Berger/Watson/IBM wrote on 05/11/2011 12:20:49 PM:</tt> <tt>> > The mac chain is there for supporting multiple MAC addresses per > interface. What is the use case for having</tt> <tt>> multiple MAC address on an interface and how do I set this up in a > Linux guest for example?</tt> <tt> I don't know if Linux guests support it now, but I wanted to</tt> <tt>eliminate the unnecessary requirement from nwfilter. Most real NICs</tt> <tt>support multiple MAC addresses; failover mechanisms can make use of</tt> <tt>it (e.g., by moving a MAC address from one device to another one that</tt> <tt>already has one).</tt> <tt> But the feature in nwfilter is more generally useful since it</tt> <tt>allows a host administrator to assign a set of legal MAC addresses</tt> <tt>to a VM and the VM user can choose/use any one of them at run time.</tt> <tt> Of course, VM users may have other reasons for wanting multiple</tt> <tt>MAC addresses on the same interface; the real point is that there's</tt> <tt>no technical reason to restrict it within nwfilter.</tt> <tt> > I am not sure whether we should remove a chain, i.e., the 'arp' > chain here. Adding is ok. Maybe the existing chain 'arp' could be > doing one part and 'arpmac' the other ?</tt> <tt> I renamed it to make it clearer what fields specifically each is</tt> <tt>checking for ARP. If you're concerned about compatibility with existing</tt> <tt>filters, we could either leave "arp" as an empty stub, or put one or the</tt> <tt>other of arpip or arpmac under that name. But this, as with the "drop"</tt> <tt>policy change, I think comes down to my belief that administrators have</tt> <tt>to revisit existing custom filters if we make any change whatsoever to</tt> <tt>the set in examples. So, I made that set self-consistent, but any filters</tt> <tt>that rely on changing any of them need to be reworked for any change.</tt> <tt>Independent custom filters aren't affected, of course.</tt> <tt>> > Can you run a VM and do a 'ebtables -t nat -L' and post the output. > I'd be curious how</tt> <tt>> the chains look like now with the 'clean-traffic' filter without > having to apply the</tt> <tt>> patches and test them.</tt> <tt><two stages -- before DHCP ACK and after below></tt> <tt> </tt> <tt>Bridge table: nat</tt> <tt>Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j libvirt-I-vnet0</tt> <tt>Bridge chain: OUTPUT, entries: 0, policy: ACCEPT</tt> <tt>Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT -o vnet0 -j libvirt-O-vnet0</tt> <tt>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 </tt> <tt>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 </tt> <tt>Bridge chain: I-vnet0-mac, entries: 1, policy: DROP -s 54:0:0:0:0:1 -j RETURN </tt> <tt>Bridge chain: I-vnet0-ipv4, entries: 1, policy: DROP -p IPv4 --ip-src 0.0.0.0 --ip-proto udp --ip-sport 68 -j RETURN </tt> <tt>Bridge chain: O-vnet0-ipv4, entries: 1, policy: DROP -j ACCEPT </tt> <tt>Bridge chain: I-vnet0-arpmac, entries: 1, policy: DROP -p ARP --arp-mac-src 54:0:0:0:0:1 -j RETURN </tt> <tt>Bridge chain: I-vnet0-arpip, entries: 1, policy: DROP -p ARP --arp-ip-src 0.0.0.0 -j RETURN </tt> <tt>Bridge chain: I-vnet0-rarp, entries: 1, policy: DROP -p 0x8035 -s 54:0:0:0:0:1 -d Broadcast --arp-op Request_Reverse </tt> <tt> --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 54:0:0:0:0:1</tt> <tt> --arp-mac-dst 54:0:0:0:0:1 -j ACCEPT </tt> <tt>Bridge chain: O-vnet0-rarp, entries: 1, policy: DROP -p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0 </tt> <tt> --arp-ip-dst 0.0.0.0 --arp-mac-src 54:0:0:0:0:1 </tt> <tt> --arp-mac-dst 54:0:0:0:0:1 -j ACCEPT </tt> <tt>[after DHCP ACK]</tt> <tt>Bridge table: nat</tt> <tt>Bridge chain: PREROUTING, entries: 1, policy: ACCEPT -i vnet0 -j libvirt-I-vnet0</tt> <tt>Bridge chain: OUTPUT, entries: 0, policy: ACCEPT</tt> <tt>Bridge chain: POSTROUTING, entries: 1, policy: ACCEPT -o vnet0 -j libvirt-O-vnet0</tt> <tt>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 </tt> <tt>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 </tt> <tt>Bridge chain: I-vnet0-mac, entries: 1, policy: DROP -s 54:0:0:0:0:1 -j RETURN </tt> <tt>Bridge chain: I-vnet0-ipv4, entries: 2, policy: DROP -p IPv4 --ip-src 0.0.0.0 --ip-proto udp --ip-sport 68 -j RETURN -p IPv4 --ip-src 10.0.0.1 -j RETURN </tt> <tt>Bridge chain: O-vnet0-ipv4, entries: 1, policy: DROP -j ACCEPT </tt> <tt>Bridge chain: I-vnet0-arpmac, entries: 1, policy: DROP -p ARP --arp-mac-src 54:0:0:0:0:1 -j RETURN </tt> <tt>Bridge chain: I-vnet0-arpip, entries: 2, policy: DROP -p ARP --arp-ip-src 0.0.0.0 -j RETURN -p ARP --arp-ip-src 10.0.0.1 -j RETURN </tt> <tt>Bridge chain: I-vnet0-rarp, entries: 1, policy: DROP -p 0x8035 -s 54:0:0:0:0:1 -d Broadcast --arp-op Request_Reverse</tt> <tt> --arp-ip-src 0.0.0.0 --arp-ip-dst 0.0.0.0 --arp-mac-src 54:0:0:0:0:1</tt> <tt> --arp-mac-dst 54:0:0:0:0:1 -j ACCEPT </tt> <tt>Bridge chain: O-vnet0-rarp, entries: 1, policy: DROP -p 0x8035 -d Broadcast --arp-op Request_Reverse --arp-ip-src 0.0.0.0</tt> <tt> --arp-ip-dst 0.0.0.0 --arp-mac-src 54:0:0:0:0:1</tt> <tt> --arp-mac-dst 54:0:0:0:0:1 -j ACCEPT </tt> <tt>thanks,</tt> <tt> +-DLS</tt> </body></html>