Hello, i have done as requested.
I have also done the same for VPS102, and its the same as VPS101 - Communicates with the host and vice versa, but not the internet.
[[email]root@cl-t091-040cl[/email] ~]# ping 64.233.167.99
PING 64.233.167.99 (64.233.167.99) 56(84) bytes of data.
64 bytes from 64.233.167.99: icmp_seq=2 ttl=244 time=25.0 ms
64 bytes from 64.233.167.99: icmp_seq=6 ttl=244 time=24.9 ms
64 bytes from 64.233.167.99: icmp_seq=7 ttl=244 time=25.1 ms
64 bytes from 64.233.167.99: icmp_seq=8 ttl=244 time=24.8 ms
64 bytes from 64.233.167.99: icmp_seq=9 ttl=244 time=49.6 ms
[[email]root@cl-t091-040cl[/email] ~]# iptables -t filter -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
[[email]root@cl-t091-040cl[/email] ~]# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
And finally, the tcpdump
[[email]root@cl-t091-040cl[/email] ~]# tcpdump -n -i venet0
tcpdump: WARNING: arptype 65535 not supported by libpcap - falling back to cooked socket
tcpdump: WARNING: venet0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on venet0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
11:40:10.282116 IP 72.55.180.209 > 64.233.167.99: ICMP echo request, id 15214, seq 93, length 64
11:40:11.281370 IP 72.55.180.209 > 64.233.167.99: ICMP echo request, id 15214, seq 94, length 64
11:40:12.281660 IP 72.55.180.209 > 64.233.167.99: ICMP echo request, id 15214, seq 95, length 64
11:40:13.281932 IP 72.55.180.209 > 64.233.167.99: ICMP echo request, id 15214, seq 96, length 64
11:40:14.281182 IP 72.55.180.209 > 64.233.167.99: ICMP echo request, id 15214, seq 97, length 64
11:40:15.281471 IP 72.55.180.209 > 64.233.167.99: ICMP echo request, id 15214, seq 98, length 64
11:40:16.281745 IP 72.55.180.209 > 64.233.167.99: ICMP echo request, id 15214, seq 99, length 64
11:40:17.280992 IP 72.55.180.209 > 64.233.167.99: ICMP echo request, id 15214, seq 100, length 64
11:40:18.281287 IP 72.55.180.209 > 64.233.167.99: ICMP echo request, id 15214, seq 101, length 64
11:40:19.281555 IP 72.55.180.209 > 64.233.167.99: ICMP echo request, id 15214, seq 102, length 64
| Quote: |
Unless you have those virtual interfaces on your host node for some valid reason (I'm guessing not)... you need to remove them all.
You don't have to do any special NIC configuration on the hn to create NICs for your VPSes... vzctl does it all for you... and those virtual interfaces are blocking your VPSes from getting the packets.
Regarding name resolution, as was mentioned, you need to do a:
vzctl set {VEID} --nameserver {a.b.c.d} --save
I think if you wipe the slate clean with your network configuration (only have the hn set to it's own IP address and that's it) you'll be in business.
Nowhere in the OpenVZ quick install guide, wiki, manuals, etc... does it ever say you need to pre-configure the host node with virtual interfaces... and you are the second person I've run into who has done this.
|
I didnt set up the virtual alias. They where set up by my server provider.
I have now removed them, and the only interfaces are eth0, lo and venet0.
I have setup the --nameserver, pointing the address to my host node which has BindDNS installed.
[Updated on: Wed, 03 October 2007 15:48]
Report message to a moderator
OpenVZ Forum
Members
Search
Help
Register
Login
Home
