Hide Forgot
Description of problem: With setting <filterref filter='disallow-dhcp'/> on domain xml and create network-filter disallow dhcp, for rhel5u6 guest, it still can get ip when it started. #virsh nwfilter-dumpxml disallow-dhcp <filter name='disallow-dhcp' chain='ipv4'> <uuid>fb4811c8-2489-e38e-f49f-622428ca3091</uuid> <rule action='drop' direction='inout' priority='500'> <ip protocol='udp' srcportstart='67' dstportstart='68'/> </rule> </filter> on guest, dhclient is up when start the domain #ps aux |grep dhclient root 1742 0.0 0.1 6764 852 ? Ss 01:20 0:00 /sbin/dhclient -1 -q -lf /var/lib/dhclient/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid eth0 Version-Release number of selected component (if applicable): libvirt-0.8.7-16.el6.x86_64 How reproducible: always Steps to Reproduce: 1. prepare a rhel5u6 guest 2. virsh nwfilter-define disallow-dhcp.xml cat disallow-dhcp.xml <filter name='disallow-dhcp' chain='ipv4'> <rule action='drop' direction='inout' priority='500'> <ip protocol='udp' srcportstart='67' dstportstart='68'/> </rule> </filter> 3. add <filterref filter='disallow-dhcp'/> inside of interface section 4. start the guest Actual results: guest still can get ip Expected results: guest can not get ip Additional info:
Is the guest connected to the network via a host bridge, or via a virtual network? Please include the domain XML.
Investigation by the author of the nwfilter code revealed a problem with filtering on interfaces of type "direct" (ie macvtap). Please inform us if your interface is using this type so we can determine if your problem is something different.
(In reply to comment #3) > Investigation by the author of the nwfilter code revealed a problem with > filtering on interfaces of type "direct" (ie macvtap). Please inform us if your > interface is using this type so we can determine if your problem is something > different. No, it is just normal network ... <interface type='network'> <mac address='52:54:00:af:05:e0'/> <source network='default'/> <target dev='vnet0'/> <model type='rtl8139'/> <filterref filter='disallow-dhcp'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> ...
I have tried this with a RHEL5 guest on a RHEL6.1 host, and see that the traffic is properly blocked. How are you judging that the traffic is allowed? I think your method may be invalid. If you are just checking to see if the guest's interface has an IP address after it is finished booting, this is inadequate. Even if dhclient on the guest is unsuccessful in contacting a DHCP server, after several tries it will look for the file /var/lib/dhclient/dhclient-eth0.leases (the name changes slightly in RHEL6) and if the lease it describes is not yet expired, dhclient will just use the address given in that file. So even though DHCP traffic is being blocked, the guest will "get" an IP address. The real test is one of the following: 1) remove /var/lib/dhclient/dhclient-eth0.leases on the guest, reboot, and again check for an IP address assigned to eth0. 2) start the guest, then immediately run "tcpdump -i vnetX -n port bootpc" on the host (where "vnetX" is the tap interface just created for the guest - it will be the newest interface with that type of name to show up in the output of "ifconfig" - eg "vnet0" if there are no other guests on the host. While the guest is booting, watch the output of tcpdump to see if any packets show up *from* the bootps port *to* the bootpc port (you will definitely see packets in the other direction). If there are no packets from bootps-->bootpc, then the traffic is being properly blocked. 3) watch /var/log/messages on the host while the guest is booting. If the dhcp traffic is being allowed, you will see messages like this: dnsmasq-dhcp[2480]: DHCPDISCOVER(virbr0) 192.168.122.140 52:54:00:dc:77:14 dnsmasq-dhcp[2480]: DHCPOFFER(virbr0) 192.168.122.140 52:54:00:dc:77:14 dnsmasq-dhcp[2480]: DHCPREQUEST(virbr0) 192.168.122.140 52:54:00:dc:77:14 dnsmasq-dhcp[2480]: DHCPACK(virbr0) 192.168.122.140 52:54:00:dc:77:14 If dhcp is being blocked, you will not see any such messages. (In all 3 cases, there will be a rather long pause during the boot process on the guest, as it repeatedly sends queries to the DHCP server, then waits for a reply that never comes). Please check for dhcp traffic blockage using one of these methods, and report back the results.
Hi Laine, Thanks for your detail explanation. I test the case with 1st method and find that after remove /var/lib/dhclient/dhclient-eth0.leases and restart guest, the guest can not get ip any more. I report it because on rhel6 guest it really can not get ip after first boot. I think I need to update test steps. Please help to close it as not a bug. Sorry for troubling.
Closed per Comment 6. Thanks for the followup, weizhang!