On 07/16/2011 04:58 PM, Trey Dockendorf wrote:
If both the VM's and the server are on the same bridge and they can't talk to each other, I would from both the server and VM end, ping the opposite end and check the arp table to see if arp entries are getting resolved, then I would run tcpdump on each respective end and send packets from the other end and see if they are getting through. If not, then their is either a problem with either the VM's config file or the networking/bridge config on the server. (Of course if you have any kind of ipfilter access lists, then I would check those). Once you've got the above working, I would attempt to perform similar tests to the outside. If you happen to have a login on another host on the same subnet, you can ping your VM and check the arp table to see if there is arp resolution. (Also check that you don't have duplicate ip address assignments). If there is arp resolution, then run tcp dump on the vm (or the physical interface of the server) and see if you can see the packets from outside. Checking the reverse direction is harder if you don't have root access on the remote end. If your going through gateways, then run traceroute to see how far your getting. As I thought about it more, it's unclear weather your VM's are on a seperate bridge from your server's external interface or they are bridged directly onto it. If the VM's are on a bridge that also has an external interface on it, then you don't use NAT. NAT would be if you wanted your server to act as a router/firewall for the VM's in which case the VM's would be on a separate bridge and the server would have another external interface and would act as a router between the bridge network and the external network. This should be a start anyway. Nataraj |
_______________________________________________ CentOS-virt mailing list CentOS-virt@xxxxxxxxxx http://lists.centos.org/mailman/listinfo/centos-virt
