Open Stack

Dear All,
My problem is that my VMs on different compute nodes are not communicating with each other (no ICMP/TCP/UDP connectivity). VMs on the same compute node can reach each other. The arp packets is flooded across the data path network but no reply is generated from the destination VM.
I have a multi-node openstack havana deployment as follows:Controller (eth1=172.17.25.x) & (eth2 = no ip with promiscuous mode on for data traffic)Compute (eth1=172.17.25.x) & (eth2 = no ip with promiscuous mode on for data traffic)Compute (eth1=172.17.25.x) & (eth2 = no ip with promiscuous mode on for data traffic)Compute (eth1=172.17.25.x) & (eth2 = no ip with promiscuous mode on for data traffic)
I have configured two networks:External (172.17.25.x)Internal (192.168.1.x)
I have a router which connects these two networks:Port 1 on external network with ip=172.17.25.xPort 2 on internal network with ip=192.168.1.1
I have multiple virtual machines running on all the 3 compute nodes on 192.168.1.x network.Here is what i have done so far to debug the issue: 1. I have verified the bridging information on control and compute nodesPackets leave the eth2 interface of the source VM's compute node and enter into the eth2 interface of the destination VM's compute node.The packets are being received by the br-compute and the vlans are also being translatedbr-int is not receiving the packets from br-compute and thus VM doesnt reply to the ARP packet.I have also dumped flows and checked the rules on the bridges and found 1 rule on br-compute which is translating the vlans but no rule on the br-int to re-translate the vlans back. I have added the rule myself but of no avail.Both the VMs are on the same vlan & physical switch is configured to allow all VLAN traffic on all interfaces
Compute Bridging info:--> br-int = vm taps + int-br-compute--> br-compute = eth2 + phy-br-compute
If anyone can help me out with this then that would be great. Thanks.
Moiz Arif 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/community/attachments/20140522/d71ec7d9/attachment-0001.html>