I setup an Havana OpenStack with openvswitch plugin in all-in-one environment, and successfully created the vlan network and the instances, and from controller node I can ping through all the instances, such as ip "10.0.1.5"
[root@red-controller ~]# nova list
+--------------------------------------+-----------+--------+------------+-------------+--------------------------------+
| ID | Name | Status | Task State | Power State | Networks |
+--------------------------------------+-----------+--------+------------+-------------+--------------------------------+
| b0e6b51a-a88f-4705-aee8-23191365f825 | test-l3-3 | ACTIVE | None | Running | network1=10.0.1.3, 192.168.1.3 |
| 16ad5616-e133-41a1-9d6c-bbaab8f944df | test-l3-4 | ACTIVE | None | Running | network2=10.0.2.3 |
| 906d9c1d-25b1-4cdd-85ea-6ffd47f7bbab | test-l3-5 | ACTIVE | None | Running | network1=10.0.1.4 |
| ee7c6172-f0af-4f44-aabc-0fe4b801a5c3 | test-l3-6 | ACTIVE | None | Running | network1=10.0.1.5 |
+--------------------------------------+-----------+--------+------------+-------------+--------------------------------+
But when I check the iptables, it confused me
[root@red-controller ~]# iptables -S|grep 0d00e75f
-N neutron-openvswi-i0d00e75f-d
-N neutron-openvswi-o0d00e75f-d
-A neutron-openvswi-FORWARD -m physdev --physdev-out tap0d00e75f-d5 --physdev-is-bridged -j neutron-openvswi-sg-chain
-A neutron-openvswi-FORWARD -m physdev --physdev-in tap0d00e75f-d5 --physdev-is-bridged -j neutron-openvswi-sg-chain
-A neutron-openvswi-INPUT -m physdev --physdev-in tap0d00e75f-d5 --physdev-is-bridged -j neutron-openvswi-o0d00e75f-d
-A neutron-openvswi-i0d00e75f-d -m state --state INVALID -j DROP
-A neutron-openvswi-i0d00e75f-d -m state --state RELATED,ESTABLISHED -j RETURN
-A neutron-openvswi-i0d00e75f-d -p tcp -m tcp --dport 80 -j RETURN
-A neutron-openvswi-i0d00e75f-d -s 10.0.1.2/32 -p udp -m udp --sport 67 --dport 68 -j RETURN
-A neutron-openvswi-i0d00e75f-d -j neutron-openvswi-sg-fallback
-A neutron-openvswi-o0d00e75f-d -m mac ! --mac-source FA:16:3E:C7:2C:D8 -j DROP
-A neutron-openvswi-o0d00e75f-d -p udp -m udp --sport 68 --dport 67 -j RETURN
-A neutron-openvswi-o0d00e75f-d ! -s 10.0.1.5/32 -j DROP
-A neutron-openvswi-o0d00e75f-d -p udp -m udp --sport 67 --dport 68 -j DROP
-A neutron-openvswi-o0d00e75f-d -m state --state INVALID -j DROP
-A neutron-openvswi-o0d00e75f-d -m state --state RELATED,ESTABLISHED -j RETURN
-A neutron-openvswi-o0d00e75f-d -j RETURN
-A neutron-openvswi-o0d00e75f-d -j neutron-openvswi-sg-fallback
-A neutron-openvswi-sg-chain -m physdev --physdev-out tap0d00e75f-d5 --physdev-is-bridged -j neutron-openvswi-i0d00e75f-d
-A neutron-openvswi-sg-chain -m physdev --physdev-in tap0d00e75f-d5 --physdev-is-bridged -j neutron-openvswi-o0d00e75f-d
Since the ping package's source is 10.0.1.2 rather than 10.0.1.5, I thought it should be dropped since it match the rule "-A neutron-openvswi-o0d00e75f-d ! -s 10.0.1.5/32 -j DROP". How iptables works when ping instance from controller in all-in-one environment?