[BigDook]

Opps, sorry nevermind. I just re-read the warning email it was for another VM i have on the same box, that WAS mis-configured.

Apologises for confusion.

[BigDook]

Hi

What is the output of route -n ?

Neil, i'm guessing your meaning from my VM guest, and not the host.

It's =

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
91.121.112.254 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
0.0.0.0 91.121.112.254 0.0.0.0 UG 0 0 0 eth0



Is my mask incorrect?

[Neil]

I just received a warning email too today.

I run VMWare ESXi 4.1 I have setup the VirtualMAC to my fail over IP's correctly, and on one the only real VM i have running, it's running Ubuntu and has the following IP config

auto lo eth0
iface lo inet loopback
iface eth0 inet static
address 94.23.147.126 (failover IP)
netmask 255.255.255.255
broadcast 94.23.147.126 (failover IP)
post-up route add 91.121.112.254 dev eth0 (dedicated IP ending in .254)
post-up route add default gw 91.121.112.254 (dedicated IP ending in .254)
post-down route del 91.121.112.254 dev eth0 (dedicated IP ending in .254)
post-down route del default gw 91.121.112.254 (dedicated IP ending in .254)

My resolv.cfg is set to "nameserver 213.186.33.99"


I've followed the doco as per http://help.ovh.co.uk/BridgeClient but i'm still getting a warning?

What am i doing wrong?

Hi

What is the output of route -n ?

[Neil]

Please respond, having multiple servers with multiple VPSes on em but the IPs are still being blocked. Re-enabling/unblocking them from the manager doesn't even work. Need to request a staff manager to re-run the ACL switch which takes at least 24 hours...
Maybe it's time to hire some more people??

Anyhow, please respond ASAP.

Once again:
I need to know the configuration for a server installed with VMware EXSi. I have created several Windows VPSes, using Virtual MAC addresses.
Please let me know what the network settings should be like!

Your gateway is wrong, you need to use your servers gateway. Which would be your servers ip address, but ending in .254.

[RichardWnl]

Hello all,

Some information:
VMware ESXi 4.1
Assigned Virtual MAC addresses to the Failover IPs
Created 3 Windows VPSes

Network configuration:
ip: 178.32.81.32
netmask: 255.255.255.255
gateway: 178.32.81.254

Please let me know why I am receiving those e-mails
and the IPs are being blocked.
Did I made a mistake somewhere?

Thanks in advance!

Please respond, having multiple servers with multiple VPSes on em but the IPs are still being blocked. Re-enabling/unblocking them from the manager doesn't even work. Need to request a staff manager to re-run the ACL switch which takes at least 24 hours...
Maybe it's time to hire some more people??

Anyhow, please respond ASAP.

Once again:
I need to know the configuration for a server installed with VMware EXSi. I have created several Windows VPSes, using Virtual MAC addresses.
Please let me know what the network settings should be like!

[BigDook]

I just received a warning email too today.

I run VMWare ESXi 4.1 I have setup the VirtualMAC to my fail over IP's correctly, and on one the only real VM i have running, it's running Ubuntu and has the following IP config

auto lo eth0
iface lo inet loopback
iface eth0 inet static
address 94.23.147.126 (failover IP)
netmask 255.255.255.255
broadcast 94.23.147.126 (failover IP)
post-up route add 91.121.112.254 dev eth0 (dedicated IP ending in .254)
post-up route add default gw 91.121.112.254 (dedicated IP ending in .254)
post-down route del 91.121.112.254 dev eth0 (dedicated IP ending in .254)
post-down route del default gw 91.121.112.254 (dedicated IP ending in .254)

My resolv.cfg is set to "nameserver 213.186.33.99"


I've followed the doco as per http://help.ovh.co.uk/BridgeClient but i'm still getting a warning?

What am i doing wrong?

[RichardWnl]

Hello all,

Some information:
VMware ESXi 4.1
Assigned Virtual MAC addresses to the Failover IPs
Created 3 Windows VPSes

Network configuration:
ip: 178.32.81.32
netmask: 255.255.255.255
gateway: 178.32.81.254

Please let me know why I am receiving those e-mails
and the IPs are being blocked.
Did I made a mistake somewhere?

Thanks in advance!

[DigitalDaz]

I just got the second letter from OVH saying they were going to block my IP so I thought, double check.

Anyway I did and noticed that I had put the wrong gateway:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
188.195.165.254 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 188.195.165.254 0.0.0.0 UG 0 0 0 eth0

It should have been:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
188.165.195.254 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 188.165.195.254 0.0.0.0 UG 0 0 0 eth0

Crazy thing is it worked perfectly Hopefully all is well now.

[LawsHosting]

For me it was the Broadcast IP, some of my failovers were set as eg. 87.255.255.255.

Setting it as the failover IP fixes it. So, to fix it, set future failover IP's Broadcast IP to the failover IP.

eg.
IP: 1.2.3.4
Broadcast IP: 1.2.3.4 or 1.2.3.255

But I dont use any VM's, so I'm sure ppl that do will guide you, if the way to fix it is different from this.

[DigitalDaz]

All,

I had the letter this morning about misconfiguration and arp, it was the first centos based VM I have.

The config was OK with the OVH bridging guide, the only thing that differed is that the guide doesn't have a broadcast statement which meant it defaulted to its own IP rather than the .255

Would this cause the problem?

I can't make head or tail of it anyway

------- EXTRACT OF REQUESTS -------

Thu Sep 16 22:37:42 2010 : arp who-has 188.195.165.254 tell 178.33.134.102 Fri Sep 17 01:07:40 2010 : arp who-has 188.195.165.254 tell 178.33.134.102 Fri Sep 17 01:32:37 2010 : arp who-has 188.195.165.254 tell 178.33.134.102 Fri Sep 17 01:45:39 2010 : arp who-has 188.195.165.254 tell 178.33.134.102 Fri Sep 17 01:51:04 2010 : arp who-has 188.195.165.254 tell 178.33.134.102 Fri Sep 17 02:16:46 2010 : arp who-has 188.195.165.254 tell 178.33.134.102 Fri Sep 17 02:38:09 2010 : arp who-has 188.195.165.254 tell 178.33.134.102 Fri Sep 17 03:04:45 2010 : arp who-has 188.195.165.254 tell 178.33.134.102 Fri Sep 17 03:32:42 2010 : arp who-has 188.195.165.254 tell 178.33.134.102 Fri Sep 17 03:51:33 2010 : arp who-has 188.195.165.254 tell 178.33.134.102

------- END OF EXTRACT -------

I assumed the box would need to arp for that gateway occasionally?

TIA

Daz

[Myatu]

It takes the gateway from "eth0". But the broadcast should indeed be .255 rather than XX.255.255.255

[LawsHosting]

Guys sorry for re-openning a dead thread. I've just received one of these emails for a 3yr old server but I'm a bit confused.

I dont use any BridgeClent/VM/etc

What I did find is that I've no gateways for my failover ip's, which I can see on many posts here, but on http://help.ovh.co.uk/IpAlias I see no instructions to add gateways to these IPs.

My /etc/network/interfaces has

auto eth0:0
iface eth0:0 inet static
address 87.98.xxx.xxx
netmask 255.255.255.255

etc

No gateway...... Is this the problem or? If so, they need to update their help docs

TIA

Edit:

My broadcast is set as 87.255.255.255, I guess this is wrong? Should be .255?

[BenB]

The one last thing missing is the route, BenB.

Have a look here: http://help.ovh.co.uk/BridgeClient at what needs to be added to the file /etc/sysconfig/network-scripts/route-eth0. Hope this helps!

Cheers mate all working good now, must have not seen it .

[Myatu]

The one last thing missing is the route, BenB.

Have a look here: http://help.ovh.co.uk/BridgeClient at what needs to be added to the file /etc/sysconfig/network-scripts/route-eth0. Hope this helps!

[BenB]

I cant seam to get my vps's running with that configuration, i'm running citrix xenserver :

DEVICE=eth0
BOOTPROTO=static
ONBOOT=yes
IPV6INIT=no
HWADDR=02:00:00:E9:37:70
IPADDR=94.23.111.58 (failoverip)
NETMASK=255.255.255.255
GATEWAY=188.165.111.254 (node ip)

When ive set this it produces error's like this, with no connection :

martian source from , on dev eth0
ll header:


Cheers,

[svan]

Hi
how i can set netmask in windows server 2003 to 255.255.255.255
we have recive warning about misconfiguration... and my ips has been blocked !
i do this step

Then, select Internet Protocol (TCP/IP) :



Finally, you will need your ip Failover in the field "IP Address", the mask subnet 255.255.0.0, the gateway to your physical machine as default gateway and ip 213.186.33.99 as the preferred DNS server.



For the second step, via the Start menu, click Run, then type regedit.
Once in the application, you should find your ip-failover (Edit Search).
Once the IP found, double-click the parameter SubnetMask? "and change 255.255.0.0 to 255.255.255.255, then you validate.
Close the registry editor

Finally, to validate the changes, you must restart the network interface (Start> Control Panel> Network Connections> Connection
LAN> right click, then Disable)
Wait a few seconds and re-enable the network connection
*****************

sorry to bring this problem back , but i have same problem and i did same steps on win2003 and there is still 255.255.255.0 mask how can i modify it to 255.255.255.255? because the windows wont accept such mask any ideea?

[Myatu]

EDIT: Deleted that route with that command and completely borked the whole connection. Working to get it back right now..

Whoops, I didn't mean right off the bat as I had assumed you didn't have issues (though you did receive an e-mail later).

You need a route to 91.xxx.xxx.254 first with "route add 91.xxx.xxx.254 mask 255.255.255.255 0.0.0.0". With that command, it should automatically select the interface that has internet (WAN) access. However, if you have to, you can manually specify the interface by appending "if XX" where XX is the interface number (as shown with "route print").

Now, upon further reflection on this, it seems like a very tedious process on Windows. For example, with Debian/Ubuntu you can simply use a "post-up" and "post-down" to add the route automatically. But I don't know if the same can be done with Windows automatically, except for perhaps a batch script (I'm slowly moving away from it...).

However, that would explain why you have a 0.0.0.0 gateway (Windows probably added this automatically, as it couldn't find a way to reach 91.xxx.xxx.254 otherwise).

[brgroup]

But it seems that the Windows VM has been running fine for the last 2 days, on the 3rd attempt at resetting the IP and firing up the VM.

Haven't received a warning notice in as many days, where usually it would arrive within the hour of reactivating the blocked IP.

I guess I spoke too soon..Just received a warning email on the Windows VM above, lol!

Hey, I was frustrated before and I apologize to all you guys in the forum..Now it's sorta laughable.

Otherwise, I would definitely consider that 0.0.0.0 gateway as an issue ("route delete 0.0.0.0" would remove it and leave the 2nd one, using 91.xxx.xxx.254).

EDIT: Deleted that route with that command and completely borked the whole connection. Working to get it back right now..

[HugeServer]

well i have a windows xp vm running on a proxmox host and the gateway in the windows machine is set as the host ip not ending in 254, not a single email from ovh and it has been running for the past 30 days without problem

Yes, You are right, but it shouldnt be the main server ip address It is the setting that OVH said

[Myatu]

Haven't received a warning notice in as many days, where usually it would arrive within the hour of reactivating the blocked IP.

TBH, I'm not familiar with Windows route tables and how to streamline or flush them of erroneous entries.

Well, if OVH isn't complaining, then "don't change it if it isn't broken" applies Otherwise, I would definitely consider that 0.0.0.0 gateway as an issue ("route delete 0.0.0.0" would remove it and leave the 2nd one, using 91.xxx.xxx.254).

[makno]

NO

It should be Main IP Address that ends to 254. For example, Server IP is 1.1.1.1 so default gateway is 1.1.1.254

well i have a windows xp vm running on a proxmox host and the gateway in the windows machine is set as the host ip not ending in 254, not a single email from ovh and it has been running for the past 30 days without problem

[brgroup]

Yeah I had noticed that too..

But it seems that the Windows VM has been running fine for the last 2 days, on the 3rd attempt at resetting the IP and firing up the VM.

Haven't received a warning notice in as many days, where usually it would arrive within the hour of reactivating the blocked IP.

For posterity, here's the route print:


TBH, I'm not familiar with Windows route tables and how to streamline or flush them of erroneous entries.

[Myatu]

Look at the "Default Gateway" -- both 0.0.0.0 and 91.121.xxx.254? What does your IPv4 route table look like ("route print")?

Also, if you're running Windows inside a VM and the host machine is a Linux machine, you can type "tcpdump -ni eth0 arp" on the host machine (linux) to see all the ARP messages being sent from your server (and stop it with CTRL+C). There should be few and far between, and only for local IPs.

[HugeServer]

the default gateway should be your host machine

NO

It should be Main IP Address that ends to 254. For example, Server IP is 1.1.1.1 so default gateway is 1.1.1.254

[makno]

the default gateway should be your host machine

[brgroup]

IPCONFIG /ALL:


REGISTRY SETTINGS:


if you need my full IP address, please refer to Support Ticket#488586

[fozl]

Yeah, personally I've unblocked my IP and retried the configuration for the 2nd time from the BridgeClient guide..Which was the only suggestion I received from OVH tech support when I opened the ticket I mentioned above.

Searching the Failover IP in Regedit and making sure the netmask is set to 255.255.255.255 - Resetting the adapter AND restarting the VM...I received a warning email within 1 hour of reactivating. I'm running Windows 2008 R2.

It will be blocked again for sure if I leave the VM running overnight. Even though I could unblock the IPs, I'll have to stop the VM until we could get some serious clarification on what works for Windows.

Linux, no issues with netmask 255.255.255.255.

So far.

Could you send us the result of ipconfig /ALL, so we can see your setup.

[brgroup]

Yeah, personally I've unblocked my IP and retried the configuration for the 2nd time from the BridgeClient guide..Which was the only suggestion I received from OVH tech support when I opened the ticket I mentioned above.

Searching the Failover IP in Regedit and making sure the netmask is set to 255.255.255.255 - Resetting the adapter AND restarting the VM...I received a warning email within 1 hour of reactivating. I'm running Windows 2008 R2.

It will be blocked again for sure if I leave the VM running overnight. Even though I could unblock the IPs, I'll have to stop the VM until we could get some serious clarification on what works for Windows.

Linux, no issues with netmask 255.255.255.255.

So far.

[HugeServer]

which windows server version do you use?
2003 or 2008?

He allready wrote that he is using windows 2003.

Hi
how i can set netmask in windows server 2003 to 255.255.255.255
we have recive warning about misconfiguration... and my ips has been blocked !
i do this step

So now you have to unblock your ips from the manager : ServerName - Server Status - IP Addresses Block...

[zydron]

which windows server version do you use?

2003 or 2008?

[zitanix]

Hi
how i can set netmask in windows server 2003 to 255.255.255.255
we have recive warning about misconfiguration... and my ips has been blocked !
i do this step

Then, select Internet Protocol (TCP/IP) :



Finally, you will need your ip Failover in the field "IP Address", the mask subnet 255.255.0.0, the gateway to your physical machine as default gateway and ip 213.186.33.99 as the preferred DNS server.



For the second step, via the Start menu, click Run, then type regedit.
Once in the application, you should find your ip-failover (Edit Search).
Once the IP found, double-click the parameter SubnetMask? "and change 255.255.0.0 to 255.255.255.255, then you validate.
Close the registry editor

Finally, to validate the changes, you must restart the network interface (Start> Control Panel> Network Connections> Connection
LAN> right click, then Disable)
Wait a few seconds and re-enable the network connection

[Andy]

Great Thanks.

[Neil]

Scrub the above, it's working now. For some reason I had to remove adaptor and re-add it.

However I'm now using

IP: 94.23.121.44
Netmask: 255.255.255.255
Gateway: 94.23.233.254

Is this correct? Can marks/kro/neil verify please?

Thanks.

That is now correct, the gateway is now correct.

[Andy]

Sorry Neil, I posted before refreshing.

I think a better guide should be created to show these changes. The one on the help pages is NOT helpful in any way at all.

[Andy]

Scrub the above, it's working now. For some reason I had to remove adaptor and re-add it.

However I'm now using

IP: 94.23.121.44
Netmask: 255.255.255.255
Gateway: 94.23.233.254

Is this correct? Can marks/kro/neil verify please?

Thanks.

[Neil]

I've just had one of my VM's blocked. I've unblocked it in the Manager and now I'm trying to get it back online.

I am using the following configuration:

Oracle Virtual Box
Ubuntu
eth1
address: 94.23.121.44 (vm IP)
netmask: 255.255.255.255
gateway: 94.23.233.10 (main server IP)

Yet I get no connection, to OR from the server. It worked fine on the previous configuration but you changed your rules and now it doesn't work.

Help please.

Hi Andy

It is the gateway, it should be 94.23.233.254, see http://forum.ovh.co.uk/showthread.php?p=32080 and section 2

[Andy]

I've just had one of my VM's blocked. I've unblocked it in the Manager and now I'm trying to get it back online.

I am using the following configuration:

Oracle Virtual Box
Ubuntu
eth1
address: 94.23.121.44 (vm IP)
netmask: 255.255.255.255
gateway: 94.23.233.10 (main server IP)

Yet I get no connection, to OR from the server. It worked fine on the previous configuration but you changed your rules and now it doesn't work.

Help please.

[maksis]

yesterday i got an email that they have banned an ip of a virtual machine which hasn't been even running on this month... that's very confusing

[brgroup]

Well if you are still receiving requests then it is something else wrong with the configuration, without the server address and ip address we cannot help.

Neil, submitted a ticket with that info #488586

BEWARE: The config I'm using matches that of Marks helpful tips from above as well as the Windows section of this guide OVH BridgeClient Config

Obviously Windows VM's and Linux VM's don't have the same configuration rules, so while I'm waiting..Anybody else running a Virtual Mac Failover IP in a Windows VM and can share their configuration tips so this server can get back online.

[Neil]

Actually Marks, you're WRONG..the above is the perfect example of of a configuration that will get your IP BANNED! On Windows 2008 at least. That's what happened to me when I got one of your famous emails for a Windows VM and changed the netmask to 255.255.255.255
Here's the shot:

And here's the BANNED email:

Funny how I did change the netmask from 255.255.255.0 to 255.255.255.255 and still got banned..Make me so ANGRY

"So please, we are kindly asking you" to get your CRAP together on this issue, and show us what needs to be done with Windows 2008 machines so we can continue on with our lives.
thx so much

Well if you are still receiving requests then it is something else wrong with the configuration, without the server address and ip address we cannot help.

[brgroup]

That's a perfect example of a wrong configuration

It should be:

address 178.32.xx.xx
netmask 255.255.255.255
gateway MAIN.HOST.IP.254

Actually Marks, you're WRONG..the above is the perfect example of of a configuration that will get your IP BANNED! On Windows 2008 at least. That's what happened to me when I got one of your famous emails for a Windows VM and changed the netmask to 255.255.255.255
Here's the shot:

And here's the BANNED email:

Hello,

We have detected that your server ns202xxx.ovh.net unnecessarily sending a large number of requests over the network via its IP failover 188.165.xxx.16 This is due to a misconfiguration.

We've asked you several times to reconfigure your IP failover and we still see no change.

Thus, we have acted and blocked your IP failover 188.165.xxx.16.

We ask you kindly to reconfigure the IP failover.
Once done, you will be able to unblock it in your manager, section "Dedicated Servers"> "ns202xxx.ovh.net"> "Server Status"> "Blocked IP Addresses"

You can use the following guide to help you with the reconfiguration:

Funny how I did change the netmask from 255.255.255.0 to 255.255.255.255 and still got banned..Make me so ANGRY

"So please, we are kindly asking you" to get your CRAP together on this issue, and show us what needs to be done with Windows 2008 machines so we can continue on with our lives.
thx so much

[makno]

what's the network 192.168.1.0/24 doing here? is this configuration in the Virtual Machine? or the host? tell us more info and we'll be happy to help you on that

sorry for the late reply,
that network is a virtual network within virtualmachines hosted on the same cluster. basically i'm using the virtualmachine with the associated virtualmac as a router to provide connectivity to other machines on a virtual lan

[marks]

More detailed information about this issue in a new thread:

http://forum.ovh.co.uk/showthread.php?t=4255

[marks]

Marks, in future, there should be:
You probably would have ended up with fewer extra gray hairs

I agree on that

There are communication methods that are not sufficient for some customers. OVH has been working with the unmanaged servers in mind and considering our customers all IT professionals very experimented (no mean to offend anyone, the least you, Myatu ).

What I'm trying to say with this is that, as a unmanaged service, an active involvement is expected from the customer in managing his own server as well as the understanding of these issues.

Said so, I agree on those points, and I'll use your feedback to show these points to the headoffice. Your comments are always appreciated and taken into account (this time, the blockage of IPs has been delayed because of the feedback received).

Thanks

[Myatu]

Marks, in future, there should be:

1) Clearly states that the e-mail was auto generated (ie. "This is an automated e-mail -- Do not respond directly to this e-mail. For inquiries, please contact our support at blah blah").

2) a little more warning that such changes will be implemented, so that those unfamiliar with the requirements have some time to ask the appropriate questions / research the topic / hire an admin.

3) A better guide. The e-mail pointed to the Irish (???) site, with info about "ipalias" - clearly that was not enough for those who use VMs on their systems as this requires additional routing commands for the bridge.

Also, how you can diagnose this problem yourself ("tcpdump -ni arp"). This way people can check for themselves whether the excessive ARP who-has requests have stopped, vs. relying on a follow-up e-mail from the automated system that it's not fixed yet...

You probably would have ended up with fewer extra gray hairs

[marks]

Last but not least, the actual blockage of the IPs has been delayed to give some more time to all customers.

In any case, the de-blockage can be done by yourself in the manager at:

OVH Manager >> your RPS >> Server State >> IP Address blocked

In any case, make sure that the problem is sorted ASAP anyway. You'll receive more warning emails if it hasn't been fixed before blockage of the IP.

[marks]

And lastly my default setups for the VPS's - Virtual Mac assigned to vmbr0 in ProxMox and configured in each VM, using the Gnome Network like so:
/etc/network/interfaces

address 178.32.xx.xx
netmask 255.255.255.0
gateway 178.32.xx.xx

BRGROUP

That's a perfect example of a wrong configuration

It should be:

address 178.32.xx.xx
netmask 255.255.255.255
gateway MAIN.HOST.IP.254

[marks]

well this is going great i think.
After i replied to the email saying that the system had been working fine for the past month and that i'm willing to check if something is wrong i got this reply......

If the system was working fine in the past, that doesn't mean the configuration was the right one. Using network mask different from 255.255.255.255 forces the server to use broadcast ARP, which works when it comes to connectivity, but it has problem of overflowing our network with packets. That's all.

This change will make the network work better for everyone

[marks]

For all my single failover IPs I am using the netmask of 255.255.255.255. For my RIPE IP blocks I use the netmask of 255.255.255.248 for those that are /29.

netmask always 255.255.255.255. Otherwise, the ARP broadcast will be sent anyway.

[marks]

by the way the problem persists:

root@s1:~ # ip route
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
94.xx.xx.0/24 dev eth1 proto kernel scope link src 94.xx.xx.xx (failover ip)
default via 94.xx.xx.254 dev eth1
root@s1:~ # ifconfig eth1 netmask 255.255.255.255

now there is no connectivity, if i reset the netmask to 255.255.255.0 it comes back online

what's the network 192.168.1.0/24 doing here? is this configuration in the Virtual Machine? or the host? tell us more info and we'll be happy to help you on that

[marks]

sorry for the delay on getting back to you.

The change:
nothing has change in the network, only this new . We've introduced this system because these IP failover (whatever the use) configured wrongly were overflowing the network with unnecessary ARP traffic. This is something we could cope with so far, but our network engineers have decided to fix the issue to improve the overall performance.

So far, with all the cases we've seen in the support about this configuration, the issues are reduced to:

Netmask for the Failover or RIPE IP configuration: 255.255.255.255 <= that's always, no exceptions

Broadcast address: IP.FAIL.OVER.255

When the IP is used in bridge mode in a VM:
Gateway: MAIN.HOST.IP.254

That's fixed all the issues we've dealt with so far in the support.

[brgroup]

Guys, for my part, thanks for the help on this..I changed allo of my Linux VM gateways to SER.VER.IP.254 and I haven't received any further emails, so I'm assuming OVH is happy..

We'll see what they come up with next

[Myatu]

The gateway is always the failover/ripe IP itself rather than the host server or the gateway of the host server.

That's not correct. It's the gateway that the host server uses.

root@s1:~ # ip route
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
94.xx.xx.0/24 dev eth1 proto kernel scope link src 94.xx.xx.xx (failover ip)
default via 94.xx.xx.254 dev eth1
root@s1:~ # ifconfig eth1 netmask 255.255.255.255

now there is no connectivity, if i reset the netmask to 255.255.255.0 it comes back online

Let's try to explain the above. Before you use the netmask 255.255.255.255, you have the following possible routes:

1. Traffic destined to 192.168.1.0-255 (mask 255.255.255.0) goes through ETH0
2. Traffic destined to 94.xx.xx.0-255 (mask 255.255.255.0) goes through ETH1
3. Any other traffic needs to go through 94.xx.xx.254 and it can be reached via ETH1

So let's say you want to go to do something at IP 123.4.5.6. It's not within the 192.168.1.0 through 192.168.1.255 range, so rule number 1 doesn't apply. Rule number 2 is similar, but for the 94.xx.xx.0 through 94.xx.xx.255 range. So now we arrive at rule number 3, and it basically says "Let 94.xx.xx.254 take care of the routing to this IP" -- 94.xx.xx.254 is within the range of rule number 2, so it gets sent through ETH1.

Let's see what happens when you change the netmask to 255.255.255.255 for the IP ranges in rule number 2, as you were trying to do. Now the rule says:

2. Traffic destined to 94.xx.xx.xx (mask 255.255.255.255) goes through ETH1

Okay, so there's only one IP that it can route to now: 94.xx.xx.xx (the failover IP). So if we arrive to rule number 3 as before -- where it used to go back to rule number 2 -- it can no longer route to 94.xx.xx.254 as, well, there's no route to it. Panic!!

That's why I explained in this post earlier, that you need to create a static route to 94.xx.xx.254. This is done with "route add 94.xx.xx.254 dev eth1" in your case, which adds a 4th rule to the ones above:

4. Traffic destined to 94.xx.xx.254 (mask 255.255.255.255) goes through ETH1.

Now rule number 3 can work again

On that same note: By using the proper gateway, it will be the gateway doing all the ARP who-has requests, not your server. All that your server really has to request through ARP is "Where's 94.xx.xx.254?" so it knows where to route the packets (the ones that are at a lower level than IP - the raw pieces just before it becomes a bunch of 0's and 1's over a copper/fiber wire).

The reason why OVH is trying to get on top of this, is that millions unneeded of ARP requests can cause the routers to run out of space in the ARP tables (sort of a cache for the answers). This can cause routers to have trouble routing traffic (ie., it increases the router's CPU load) and can also cause it to cascade to other routers who are taking up the slack.

Another thing is that it can also be a source for "ARP poisoning" -- I could potentially have my server tell my neighbors "Hey, the gateway is at *my* server" and do some sniffing on all the traffic that comes my way... Not sure if that's something you'd like!

[makno]

by the way the problem persists:

root@s1:~ # ip route
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.1
94.xx.xx.0/24 dev eth1 proto kernel scope link src 94.xx.xx.xx (failover ip)
default via 94.xx.xx.254 dev eth1
root@s1:~ # ifconfig eth1 netmask 255.255.255.255

now there is no connectivity, if i reset the netmask to 255.255.255.0 it comes back online

[IainK]

For all my single failover IPs I am using the netmask of 255.255.255.255. For my RIPE IP blocks I use the netmask of 255.255.255.248 for those that are /29.

The gateway is always the failover/ripe IP itself rather than the host server or the gateway of the host server. I have never got the failover IP to work by using the host servers router as a gateway.

Will try out some commands in the host to double check these settings there too.

[Myatu]

Triple check the netmask and gateway. I had the same issue on one of my VMs, and it was due to this. If you're sure you're entering the the right stuff, double check with tcpdump on the host (already mentioned how) and check the routes with "route -n" or "ip route". The latter will show "default via .254 dev ethX". "ifconfig ethX" should show a mask of 255.255.255.255 for failover IPs, 255.255.255.0 for static IPs (unless you have a larger RIPE block assigned to you).

[IainK]

I am not pleased about this at all. I cannot sacrifice my production VPS IP addresses and this is happening to all of them.

As far as I know I'm using proper bridged networking setup so I think that OVH didn't consider the effects of this system on VPS hosts using Virtual MAC.

The fact that they linked makno to a guide, that he followed, and the problem exists there clearly demonstrates that.

[makno]

well this is going great i think.
After i replied to the email saying that the system had been working fine for the past month and that i'm willing to check if something is wrong i got this reply:

Dear customer,

This is a new system for checking bad ARP requests on our network. Check this guide for the use of bridging in proxmox: http://help.ovh.co.uk/ProxmoxBridge.

Now, that is how i've set the vps and that is probably why it's been working fine since i created it. What about this new system?

[mattb37]

Hey Matt, I share your sentiments...I've actually been glad to have several production VPS's running clean for the past few months so I didn't have to deal with support...If in your wanderings you find another service that offers a virtual Mac type setup, without having to resort to firewall rules and forwarding, please let me know..I may be interested inn picking one up too!

Sorry but I don't think I will be able to help you there. I am buying my own equipment and putting it in a local data centre so I don't have to wait hours to fix anything. You can get away from using vMacs if you assign IP addresses directly to a dedicated server, this will probably work better and eliminate another potential problem. If you only have a small number of VPS's give RapidSwitch a try or consider getting a dedicated server with another provider. I can't help but think of the following every time I do anything on OVH and I am glad I now have an alternative. The mentality part gets me; they take your money and have the arrogance to make a statement like that.

RapidSpeeds a écrit:
>
> I don't want to go on about this, so i'll be quick and straight to the
> point.
>
> FS Range.
>
> Unlimited bandwidth for French customers.
> Capped to 3TB with UK customers.
>
> Explain how that works when we are using same equipment and same
> network?

differents costs of the network + mentality

network:
FR network: I haven't put 1Euro more for 4 years. no more bandwidth.
it's a stable network. +40% customers each year with +0Euro ...
EU network costs us lot of money but I think it will be stable in 3-4
years.

mentality:
the customers FR use less bandwidth that the rest of customers not FR.
you can read "unlimited", FR likes to read it and not to use. never.
and they use it, more that 3TB they know they can't ... it's "french"
.... if you aren't french you can't understand ...

for the rest of the europe we have to write what we propose in fact.
because you aren't french, are you ?

In any event if you haven't got a fix for your CentOS VM's, have you tried the setup under Redhat on this page?
http://http://help.ovh.com/BridgeClient

That is how I setup my IP addresses on the HyperV machine.

[brgroup]

I have the same problem and will be leaving OVH when my current rental period is finished. I received an email from them about IP addresses and don't know how to reconfigure my interfaces on a HyperV CentOS server so they work.

When I got my first email I replied to it within minutes asking for how I should configure my interfaces. I have received no reply from the usual snail pace support and only got a final warning threatening to cut my IP addresses off. The OVH support is terrible and issues like this prove it. I will be moving my server business away from OVH for better support if and when it is needed.

I guess at the end of the day you get what you pay for and the attitude to go with it.

Hey Matt, I share your sentiments in many ways..Thank Goodness this forum is here and the good guys keep checking it to help people.....I've actually been glad to have several production VPS's running clean for the past few months so I didn't have to deal with support...But, If in your wanderings you find another service that offers a Virtual Mac type setup, without having to resort to firewall rules and forwarding, please let me know..I may be interested in picking one up too! Competition is good, and for better or worse, the Virtual mac script is a life saver in many ways..

In any event, if you haven't got a fix for your CentOS VM's, have you tried the setup under Redhat on this page?
http://http://help.ovh.com/BridgeClient

[mattb37]

I have the same problem and will be leaving OVH when my current rental period is finished. I received an email from them about IP addresses and don't know how to reconfigure my interfaces on a HyperV CentOS server so they work.

When I got my first email I replied to it within minutes asking for how I should configure my interfaces. I have received no reply from the usual snail pace support and only got a final warning threatening to cut my IP addresses off. The OVH support is terrible and issues like this prove it. I will be moving my server business away from OVH for better support if and when it is needed.

I guess at the end of the day you get what you pay for and the attitude to go with it.

[makno]

i'm having a look on where to find the interfaces file on ipcop as that's the machine that is giving me problems

[Myatu]

well i tried aswell with serverip.254 (proxmox cluster) and again network fails. also tried using the cluster ip as gateway but no luck. the only way i can get the network to work is using as gateway the failover ip assigned to the vps

Try this in /etc/network/interfaces:

auto eth0
iface eth0 inet static
    address FA.IL.OV.ER
    netmask 255.255.255.255
    broadcast FA.IL.OV.ER
    post-up route add HOST.IP.ENDING.254 dev eth0
    post-up route add default gw MAIN.HOST.IP.254
    post-down route del HOST.IP.ENDING.254 dev eth0
    post-down route del default gw HOST.IP.ENDING.254

So if the host has IP 91.12.34.56, use 91.12.34.254 as "HOST.IP.ENDING.254".

[makno]

well i tried aswell with serverip.254 (proxmox cluster) and again network fails. also tried using the cluster ip as gateway but no luck. the only way i can get the network to work is using as gateway the failover ip assigned to the vps

[Myatu]

It's very important to get the gateway and netmask right. As blop mentioned, only use .254 as the gateway inside VMs.

To check if this has fixed the issue, from the host type "tcpdump -ni eth0 arp" (or substitute "eth0" for "vmbr0" on Proxmox) and watch for "who-has". It should be very little and for local IPs only.

[blop]

According to the guide, this should be .254, NOT .254

(the dedicated IP is the "main" IP that is assigned to the dedicated server)

But as you say these warnings from OVH are probably something new because a lot of people received them without having changed anything. I suspect a slight ****-up in the OVH anti-hack script...

ok little problem:
assuming my failover ip is 1.2.3.4 according to the guide i should set the gateway as 1.2.3.254 but fdoing so the network becomes unavailable. setting the gateway to 1.2.3.4 it works without any problems. :\

i'm beginning to think that something has been changed these days by the ovh team and everyone is getting emails by the automated system :\

[makno]

ok little problem:
assuming my failover ip is 1.2.3.4 according to the guide i should set the gateway as 1.2.3.254 but fdoing so the network becomes unavailable. setting the gateway to 1.2.3.4 it works without any problems. :\

i'm beginning to think that something has been changed these days by the ovh team and everyone is getting emails by the automated system :\

[makno]

i've had the same emails yesterday and today and i'm too using proxmox, strange thing is the machines have been running with this configuration for the past month without problems and now here come the warning.
i will try to change the gateway and cross fingers as one of the achines is hosting some services my users won't be happy to have down :\

[brgroup]

Ahhh, we're back to the old "Failover IP vs Server IP +.254 for the gateway" issue!


I've seen in a few other posts that a few people got the same emails..I ignored it already as well since I don't use aliasing. I thought that it was an issue with their routers..but then I got the above final warning, and like most others, this is a production server and I can't afford to have any IP's blocked..Sorry OVH! Wi


Thanks so much Blop for the info..I'll try the above on one of the VPS's and see if it comes through...

Hopefully Neil and/or Marks a or anybody who knows can weigh in on this issue

[blop]

Hi,

I have received the same emails as you, twice actually: once 2 days ago and again just 2 hours ago threatening with an imminent block of my IPs...

I had this IP configuration for the VMs:

address: failover IP
netmask: 255.255.255.255
gateway: failover IP

But according to this guide: http://help.ovh.com/BridgeClient the gateway should be .254

So I've changed my VMs to:

address: failover IP
netmask: 255.255.255.255
gateway: .254

I hope this will be enough to prevent the IPs to be blocked... Because if/when your server goes into "hack" mode it's a nightmare to get it back up (http://forum.ovh.co.uk/showthread.php?t=4078)

[brgroup]

Hey guys, need some help as I'm a newbie with networking..

I'm running a standard OVH Proxmox 1.5 installation with my 3 Failover Ip's and an extra block of 8 IPs..Most of which are assigned to uBuntu KVM slices on the server by using OVH Virtual Macs assigned through the oVH manager.

Most of the VPS's have been running continuously without incident for close to sixty days..I mention this because the following has been sent even though I haven't made any changes.

I just received warning emails like following for 6 of my 11 IP's and VPS's:

Hello,

We have detected that your server ns202456.ovh.net unnecessarily sending a large number of requests over the network via its IP failover 178.32.xx.xx This is due to a misconfiguration.

We asked you in an prior email to kindly reconfigure the IP failover, noting that the problem persists, we now reiterate that request.

If the problem is not resolved promptly, we will be forced to block your IP.

THIS IS THE LAST WARNING BEFORE THE BLOCKING OF YOUR IP !!!

You can use the following guide to help you with the reconfiguration:

http://help.ovh.ie/IpAlias


You will find below a sample of queries sent by your server:

------- EXTRACT OF REQUESTS -------

18:48:54.955164 arp who-has 64.237.xxx.xxx tell 178.32.xx.xx
18:49:07.958726 arp who-has 75.108.xxx.xxx tell 178.32.xx.xx
18:49:11.954987 arp who-has 68.63.xxx.xx tell 178.32.xx.xx
18:49:11.954997 arp who-has 88.73.xxx.xx tell 178.32.xx.xx
18:49:13.963451 arp who-has 69.126.xxx.xx tell 178.32.xx.xx
18:49:28.959512 arp who-has 82.169.xx.xx tell 178.32.xx.xx
18:51:14.134845 arp who-has 98.160.xxx.xxx tell 178.32.xx.xx
18:51:59.083035 arp who-has 75.134.xxx.xxx tell 178.32.xx.xx
18:55:35.147487 arp who-has 98.160.xxx.xxx tell 178.32.xx.xx
18:59:32.536065 arp who-has 201.240.xxx.xx tell 178.32.xx.xx

------- END OF EXTRACT -------

Problem is, because I'm running ProxMox and utilizing the VirtualMacs, I'm not using IP Aliasing as far as I know, as the OVH Virtual macs eliminate the need for any Aliasing to happen..When we use the virtual Macs, we are in bridge mode right?

Could my Virtual Mac addresses that have been running so consistently have failed?

Anyway here's my main servers configuration:

/etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# for Routing
auto vmbr1
iface vmbr1 inet manual
        post-up /etc/pve/kvm-networking.sh
        bridge_ports dummy0
        bridge_stp off
        bridge_fd 0


# vmbr0: Bridging. Make sure to use only MAC adresses that were assigned to you.
auto vmbr0
iface vmbr0 inet static
        address 91.121.xxx.xx
        netmask 255.255.255.0
        network 91.121.xxx.0
        broadcast 91.121.xxx.255
        gateway 91.121.xxx.254
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0

/etc/resolv.conf

search xxxx-xxx.net
nameserver 8.8.8.8
nameserver 213.186.33.99
nameserver 8.8.4.4

And lastly my default setups for the VPS's - Virtual Mac assigned to vmbr0 in ProxMox and configured in each VM, using the Gnome Network like so:
/etc/network/interfaces

address 178.32.xx.xx
netmask 255.255.255.0
gateway 178.32.xx.xx

etc/resolv.conf

search 127.0.0.1
search xxxx-xxx.net
nameserver 8.8.8.8
nameserver 8.8.4.4

Any ideas? Again these machines have been running great until OVH sent these notices a couple days ago. Thanks for any help as I'm willing to try and conform to what they want, but I don't know enough about the eroor to make the changes..

BRGROUP