OVH Community, your new community space.

CentOS 6.2 with OpenVZ


Myatu
23-02-2012, 19:07
Thanks for letting us know what it was Definitely one for the books! Would be pulling my hair on that one!

ServerCide
23-02-2012, 19:01
Myatu and Felix,
Thank you both very much for assisting with this and we have now resolved it by changing net.ipv4.conf.all.rp_filter = 1 to net.ipv4.conf.all.rp_filter = 2 hope this helps somebody else in the future.

Myatu
23-02-2012, 17:57
Is that the actual tcpdump output? I don't see any ARP replies. You should be something akin to:

Code:
16:43:57.007530 ARP, Request who-has 192.168.2.1 tell 192.168.2.101, length 28
16:43:57.009353 ARP, Reply 192.168.2.1 is-at 00:1f:1f:72:61:a0, length 28
16:44:17.112792 ARP, Request who-has 192.168.2.101 tell 192.168.2.1, length 28
16:44:17.112814 ARP, Reply 192.168.2.101 is-at 00:1a:73:d1:9e:7f, length 28
16:44:46.287531 ARP, Request who-has 192.168.2.1 tell 192.168.2.101, length 28
16:44:46.288950 ARP, Reply 192.168.2.1 is-at 00:1f:1f:72:61:a0, length 28
16:44:56.440239 ARP, Request who-has 192.168.2.101 tell 192.168.2.1, length 28
Did you verify that the subnet mask is correct for the IP you're using? And do you have a route set on eth0 to the gateway, if the gateway is different from the subnet?

Felix
23-02-2012, 16:50
ServerCide wrote:
> correctly. Are you able to shed any more light on the situation please?


My crystal ball has come to its limit here - But what Myatu suggests (tcpdump)
might bring some clarity!

ServerCide
22-02-2012, 23:38
Hello Myatu,
cat /proc/sys/net/ipv4/conf/all/proxy_arp returns 1.


It appears to be remaining at 1.

As for tcpdump -n arp:

23:35:46.455724 ARP, Request who-has tell , length 46
23:35:46.801094 ARP, Request who-has tell , length 46
23:35:48.192883 ARP, Request who-has tell , length 46
23:35:50.174117 ARP, Request who-has tell , length 46
23:35:51.753211 ARP, Request who-has tell , length 46
23:35:51.766433 ARP, Request who-has tell , length 46
23:35:51.775041 ARP, Request who-has tell , length 46

Myatu
22-02-2012, 22:14
ARP doesn't reset to 0 again, does it? (check with "cat /proc/sys/net/ipv4/conf/all/proxy_arp"). Simply try with "echo 1 > /proc/sys/net/ipv4/conf/all/proxy_arp" otherwise, and track ARP who-has messages with tcpdump (-n arp).

ServerCide
22-02-2012, 11:58
Just to add I have also attempted to add the following line to the sysctl.conf:

net.ipv4.conf.eth0/XXXX.proxy_arp = 1 (where XXXX is our vRack number).

There was no luck with this either.

ServerCide
22-02-2012, 11:46
Hello Felix,
Thanks for the response we did suspect it could be related to something like that however we was unable to find any information in the OVH documentation to help us with setting up the arp correctly. Are you able to shed any more light on the situation please? Would be much appreciated.

Here is our current sysctl.conf:

net.ipv4.ip_forward = 1
net.ipv4.ip_forward = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.all.forwarding = 1
net.ipv4.conf.default.proxy_arp = 1
net.ipv4.conf.all.rp_filter = 1
kernel.sysrq = 1
net.ipv4.conf.default.send_redirects = 1
net.ipv4.conf.all.send_redirects = 0




We have also tried setting net.ipv4.conf.default.proxy_arp = 1 to 0 as well and no luck.

We didn't have any of these problems with CentOS 5.x so I am guessing this is a CentOS 6 feature?

Thanks in advance, the help is much appreciated!

Felix
22-02-2012, 11:32
ServerCide wrote:
> problems however when using an IPv4 from the vRack the container appears
> to be unable to ping outside of the node, if an IPv6 address from the


Sounds like a ARP problem. Since in a vRack you don't have the OVH-assigned
vMAC addresses, you have to make sure the switch knows where to sends the
packets to. This could for example be done with some arping or proxy_arp magic.

ServerCide
21-02-2012, 23:54
Hello Felix,
Thanks for the response however we didn't really want to have proxmox.

We're installing CentOS 6.2 (as offered by OVH) with OpenVZ and placing the node in our vRack. We already have centOS 5 nodes in the vrack without any problems however we are having trouble with the CentOS 6 node. If a container on the node has one of the server's failover IPv4 addresses assigned to it, then it can ping the outside world without any problems however when using an IPv4 from the vRack the container appears to be unable to ping outside of the node, if an IPv6 address from the vRack is assigned to the container it can ping6 without any problems so the only issue is with regards to IPv4 from the vRack (I confirm IPv6 from the vRack and the servers IPv4 failover addresses work without any issues).

We reinstalled the same node with CentOS 5.7 just for testing purposes and we was able to get this successfully set up with IPv4 from the vRack working correctly on containers, we have reinstalled the node with CentOS 6 again and are back to having the same problems as previously described.

Has anybody else experienced this or know of a fix for this?

Felix
21-02-2012, 18:10
ServerCide wrote:
> the network cards used on these servers. If you do have these servers
> with CentOS 6.2 and OpenVZ running on it what kernel do you use and have
> you experienced any issues or had to implement any fixes?


You could use Proxmox
(http://www.ovh.co.uk/dedicated_serve....xml?sort=virt),
it comes with a OpenVZ kernel and is fully tested on our server range.

(also available at Reinstall: Proxmox 2, but it's still in Beta)

ServerCide
20-02-2012, 18:55
Hello,
Was just wondering if anybody has this server http://www.ovh.co.uk/dedicated_servers/eg_amd.xml and if so do you have CentOS 6 and OpenVZ running on it? I notice there have been quite a few bugs in the latest CentOS 5 and CentOS 6 vzkernels with regards to some of the hardware on these servers such as networking issues related to the network cards used on these servers. If you do have these servers with CentOS 6.2 and OpenVZ running on it what kernel do you use and have you experienced any issues or had to implement any fixes?

Thanks in advance.