Version: OpenStack Liberty Neutron DVR
Phenomenon:
1, in the virtual machine inside constantly dhclient
2. Catch the packet on the physical network card of the compute node to which the virtual machine belongs, and discover the DHCP broadcast packet issued by the virtual machine
3. On the physical network card of the NAT node (the node where the QDHCP resides) where the virtual machine belongs, the DHCP broadcast packet issued by the virtual machine is also found, that is, the packet was caught on BOND1:
Bridge br-intfail_mode:secure Port"sg-297691c4-9f"tag:1Interface"sg-297691c4-9f"type:internal Port"tap8a1db903-07"tag:2Interface"tap8a1db903-07"type:internal Port BR-intInterface BR-inttype:internal Port"qr-8d397111-81"tag:1Interface"qr-8d397111-81"type:internal Portint-br-VLAN Interfaceint-br-VLAN Type:Patchoptions: {Peer=phy-br-VLAN} Port"tap15d024ee-23"tag:1Interface"tap15d024ee-23"type:internal Bridge BR-ex Port BR-ex Interface BR-ex type:internal Port"qg-ab607114-19"Interface"qg-ab607114-19"type:internal Bridge BR-VLAN Port BR-VLAN Interface BR-VLAN type:internal Port PHY-br-VLAN Interface PHY-br-VLAN Type:Patchoptions: {Peer=int-br-VLAN} Port"Bond1"Interface"Bond1"ovs_version:"2.4.0"
4, but in the QDHCP network card tap15d024ee-23 can't catch the DHCP broadcast packet, see each OvS Bridge flow table did not find any problem, it is strange
Reason:
Later, with the help of colleagues, it was found that the BOND1 was added to a Linux bridge:
brctl Showbridge name ID STP enabled interfacesbr0 8000. 1418774dd6a3 no em1br1 8000. 90e2ba8465f2 No bond1
Analysis:
The original bond1 was added to the Linux bridge, resulting in the appearance of being tied to Br-vlan, but it did not actually take effect, resulting in the upper Br-int not receiving the DHCP broadcast packet
Solve:
Unbind the Bond1 from the Linux bridge and rejoin the OvS bridge Br-vlan
OpenStack virtual machine DHCP gets no IP address to troubleshoot