[Antennipasi]

venet will not work with the a virtual mac, you will need to remove the virtual mac for venet to work.

If you if you ping the VM and do a TCP Dump and see the requests going inside but not being sent then please open a ticket.

Although i don't need venet for anything, i tested again with IP which has not virtual-MAC assigned yet, it does not work. HN and CT can ping together, but outer world is unreachable, and no other VPS could not ping venet-testcontainer.

On host "tcpdump -i vmbr0 -nS host FAI.LOV.ER.IP." sees traffic from CT, and arp-requests from gateway, but nothing finds where to go. Host's venet0 sees traffic also.

This was tested with kernel 2.6.24-12-pve

[Neil]

Well, venet does not work, but i don't use it anyway...

venet will not work with the a virtual mac, you will need to remove the virtual mac for venet to work.

If you if you ping the VM and do a TCP Dump and see the requests going inside but not being sent then please open a ticket.

[Antennipasi]

With 2.6.18-4-pve everything works "

Well, venet does not work, but i don't use it anyway...

[Antennipasi]

Dunno if i should check if pve-kernel-2.6.18 or pve-kernel-2.6.24 works.

With 2.6.18-4-pve everything works
So i have to agree google-rumour "OpenVZ in pve-kernel-2.6.32 is buggy as hell"

[Antennipasi]

you could be banging your head against a brick wall for ever.

Feels like this

Triple-checked MAC's.
To get ping response to second IP it is enough to drop route and gateway from eth0 and add them to to eth1. After that, IP assigned to eth0 does not respond anymore.
Again, "tcpdump -i eth0" sees packets allright but reply does not go out. All this done inside container.

Same time KVM's with multiple interfaces works like charm. Dunno if i should check if pve-kernel-2.6.18 or pve-kernel-2.6.24 works.

Found also more weird stuff, although KVM-VPS in same node can ping both IPees, VZ-container in same node can't. Somewhere routing is mixed up.

[DigitalDaz]

You could really do with ruling out any issues with Virtual Macs otherwise you could be banging your head against a brick wall for ever.

Has this IP ever been able to successfully ping the gateway? I mean by this have you ever had it allocated to say another VM and working?

I would guess that until you can verify that this is the case it could be very difficult to diagnose.

I currently have an issue on one of my Proxmox boxes where the switch passes traffic to the correct virtual machine but will not pass it back through the switch.

[Thelen]

Make sure the MAC is set correctly for the extra IP. I forget the link to the OVH config page for this, but the router on OVH end will only talk if it has the correct MAC set.

[yonatan]

this sounds really odd.
how are you adding IP addresses?

[Antennipasi]

check
ip r l
inside the container and on the main server.
adjust your configuration according to the routing table you need.

venet should work out of the box, with no need to configure anything ( not even virtual mac)

do not use veth.

"ip r l" is showing exactly same in non-working vz-container and working KVM-vps.
venet does not work to/from outer world. HN can ping CT and vise versa, but no route anywhere nor ping response from outside. F, do i have to start converting those servers to KVM...

These VPS's are moving from other datacenter where they have lived couple years now. Veth has been good for us, no performance problems and much easier to firewall and route around. Until now, apparently.
Only difference in these locations is that in old place HN-IP was in same subnet than VPS's.

[yonatan]

argh, this is driving me nuts:

I have EG-AMD with Proxmox. Otherwise everything is working nice, but i can't get containers second fail-over address to response from outer world.
Fail-over block and servers main-IP are in different subnet, off course.

I am using veth (venet does not work at all, but haven't spend any time with it yet). I have already containers with single interface, and adding routes from inside container as described in http://help.ovh.com/BridgeClient network is working well. However, i need two IP:ees in some containers.

Funny thing is that interfaces are coming up right, container sees them and assigns IP:ees right. Other containers can ping both IP:ees, but from outer world only first one is responsive.

With tcpdump inside container i see traffic coming to non-resposive interface with right IP and all but no reply is going out.
This has to do something with routes, but i am about to give up and go out to get drunk.

Crazy thing is that i have also KVM-machines with multiple NICs and with pretty much identical network/interfaces-file they are working out-of-the-box...

check
ip r l
inside the container and on the main server.
adjust your configuration according to the routing table you need.

venet should work out of the box, with no need to configure anything ( not even virtual mac)

do not use veth.

[Antennipasi]

argh, this is driving me nuts:

I have EG-AMD with Proxmox. Otherwise everything is working nice, but i can't get containers second fail-over address to response from outer world.
Fail-over block and servers main-IP are in different subnet, off course.

I am using veth (venet does not work at all, but haven't spend any time with it yet). I have already containers with single interface, and adding routes from inside container as described in http://help.ovh.com/BridgeClient network is working well. However, i need two IP:ees in some containers.

Funny thing is that interfaces are coming up right, container sees them and assigns IP:ees right. Other containers can ping both IP:ees, but from outer world only first one is responsive.

With tcpdump inside container i see traffic coming to non-resposive interface with right IP and all but no reply is going out.
This has to do something with routes, but i am about to give up and go out to get drunk.

Crazy thing is that i have also KVM-machines with multiple NICs and with pretty much identical network/interfaces-file they are working out-of-the-box...