Re: [PATCH 3/9] add DHCP snooping support to nwfilter

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Stefan Berger/Watson/IBM wrote on 05/11/2011 12:20:49 PM:
>
> The mac chain is there for supporting multiple MAC addresses per
> interface. What is the use case for having

> multiple MAC address on an interface and how do I set this up in a
> Linux guest for example?


I don't know if Linux guests support it now, but I wanted to
eliminate the unnecessary requirement from nwfilter. Most real NICs
support multiple MAC addresses; failover mechanisms can make use of
it (e.g., by moving a MAC address from one device to another one that
already has one).
But the feature in nwfilter is more generally useful since it
allows a host administrator to assign a set of legal MAC addresses
to a VM and the VM user can choose/use any one of them at run time.
Of course, VM users may have other reasons for wanting multiple
MAC addresses on the same interface; the real point is that there's
no technical reason to restrict it within nwfilter.

> 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 ?


I renamed it to make it clearer what fields specifically each is
checking for ARP. If you're concerned about compatibility with existing
filters, we could either leave "arp" as an empty stub, or put one or the
other of arpip or arpmac under that name. But this, as with the "drop"
policy change, I think comes down to my belief that administrators have
to revisit existing custom filters if we make any change whatsoever to
the set in examples. So, I made that set self-consistent, but any filters
that rely on changing any of them need to be reworked for any change.
Independent custom filters aren't affected, of course.

>
> Can you run a VM and do a 'ebtables -t nat -L' and post the output.
> I'd be curious how

> the chains look like now with the 'clean-traffic' filter without
> having to apply the

> patches and test them.

<two stages -- before DHCP ACK and after below>

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: 1, policy: DROP
-p IPv4 --ip-src 0.0.0.0 --ip-proto udp --ip-sport 68 -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: 1, policy: DROP
-p ARP --arp-ip-src 0.0.0.0 -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

[after DHCP ACK]
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: 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


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: 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


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

thanks,
+-DLS

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]