[torpado]

dedicato,

ho un ticket incidente aperto da 14 ore senza intervento.

Ho verificato i contatti con il supporto e non trovo nessuna comunicazione in corso inerente la gestione dei vmac, mi indichi gentilmente dove hai aperto questo ticket? Grazie per la collaborazione

[irox]

No allora non devi generare il Mac address e non va inserito nella configurazione

bene, ma comunque non mi risolve la situazione.

[camaran]

No allora non devi generare il Mac address e non va inserito nella configurazione

[irox]

Ma stiamo parlando di server virtuali o del server dedicato?

dedicato,

ho un ticket incidente aperto da 14 ore senza intervento.

[camaran]

Ma stiamo parlando di server virtuali o del server dedicato?

[irox]

Accedi col kvm accessibile dal manager e sistemi la configurazione della rete, oppure anche in modalità rescue

Se invece hanno semplicemente bloccato l'IP accedi al manager lo sblocchi e poi sistemi

grazie camaran, l'ho fatto almeno 10 volte in modalità rescue , non inserendo mai il MAc Virtuale ... in quanto nel file orginale (quello che ha sempre funzionato) ifcfg-eth0 che avevo trovato nel server , la stringa HWADDR=MA:MAC:VI:RT:UEL:LE non era proprio presente.

Cambiavo di volta in volta solo tutte le combinazioni per:
IPADDR=IP.FAIL.OVER
GATEWAY=IP.DE.VOTREDEDIE.254

_____________________________

in ovh Manager -> Mac Virtuale non ho presente nessun MAc nella lista, ne l'avevo mai creato, pur avendo sempre il server correttamente connesso.

Nella creazione di un nuovo MAc Virtuale nel ovh Manger

Nome della Macchina Virtuale: puo essere un qualsiasi nome ?

Tipo del Mac Virtuale: OVH o VMWare che differenza c'è ?


_____________________________

grazie a chiunque abbia 2 minuti per delucidarmi.

[camaran]

Accedi col kvm accessibile dal manager e sistemi la configurazione della rete, oppure anche in modalità rescue

Se invece hanno semplicemente bloccato l'IP accedi al manager lo sblocchi e poi sistemi

[irox]

Lo generi alla voce Mac virtuali del manager

grazie, forse è questo il problema della mia configurazione,


non ho inserito HWADDR=MA:MAC:VI:RT:UEL:LE in ifcfg-eth0

però prima funzionava senza, dico io.

cmq ho aperto un incidente con OVH e mi tocca aspettare l'intervento. con server che sta da quasi 12 ore offline.

[camaran]

Lo generi alla voce Mac virtuali del manager

[irox]

/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
IPV6INIT=no
PEERDNS=yes
TYPE=Ethernet
NETMASK=255.255.255.255
IPADDR=IP.FAIL.OVER
GATEWAY=IP.DE.VOTREDEDIE.254
ARP=yes
HWADDR=MA:MAC:VI:RT:UEL:LE

/etc/sysconfig/network-scripts/route-eth0
IP.DE.VOTREDEDIE.254 dev eth0
default via IP.DE.VOTREDEDIE.254 dev eth0

/etc/resolv.conf
nameserver 213.186.33.99

__________________________________________________ __________

HWADDR=MA:MAC:VI:RT:UEL:LE


Qualcuno sa dove prendere il parametro HWADDR ?

[camaran]

ma qualcuno di voi ci è riuscito ? se si, puo dirci come ha fatt ? grazie

le guide sono giuste ma a volte con i mac address non si salvano correttamente

[irox]

ma qualcuno di voi ci è riuscito ? se si, puo dirci come ha fatt ? grazie

[irox]

Salve, ho seguito tutte le guide possibili, ma senza successo anche io ! la queste guide sono corrette ?

[torpado]

Salve, ho seguito tutte le guide possibili, ma senza successo.

Quali sono le configurazioni corrette per il seguente ambiente, lato host e lato guest?

Proxmox virtualizzazione kvm con guest debian.

ipfailover con mac address virtuale.

Grazie

Che tipo di modalità hai scelto di gestione della rete ?

Se hai scelto modalità "routing", questa è la guida per la configurazione :
http://guides.ovh.com/Proxmox

Se hai scelto modalità "bridged", questa è la guida per la configurazione :
http://guides.ovh.net/ProxmoxBridge

Se indichi nic-handle e parte del nome server posso fare ulteriori verifiche lato Ovh

[kr3atin4]

Salve, ho seguito tutte le guide possibili, ma senza successo.

Quali sono le configurazioni corrette per il seguente ambiente, lato host e lato guest?

Proxmox virtualizzazione kvm con guest debian.

ipfailover con mac address virtuale.

Grazie

[fumocamel]

ho seguito tutte le vostre istruzioni, sia le guide che quelle telefoniche,
ma continua a non funzionare...

[torpado]

niente da fare!
non funziona, provato di tutto...
secondo me il server ha qualche casino...

Ti ho risposto via email da supporto@ovh.it

[fumocamel]

si, il caso in cui ti trovi è il 2) :

IP del server host : 46.***.***.43 => gateway : 46.***.***.254

I Failover CON virtual mac su questo host: 46.***.***.43 dovranno utilizzare :

- 46.***.***.254 come gateway

- il mac assegnato come mac della virtual interface

- netmask : 255.255.255.255

niente da fare!
non funziona, provato di tutto...
secondo me il server ha qualche casino...

[torpado]

questo? ns222***.ovh.net (nel caso cancellare)

la mia casistica credo riguardi il seguente caso:

2) you use an failover ip WITH an virtual mac:

si, il caso in cui ti trovi è il 2) :

IP del server host : 46.***.***.43 => gateway : 46.***.***.254

I Failover CON virtual mac su questo host: 46.***.***.43 dovranno utilizzare :

- 46.***.***.254 come gateway

- il mac assegnato come mac della virtual interface

- netmask : 255.255.255.255

[fumocamel]

indica il nic-handle e parte del nome server in modo da poter verificare.

Inoltre ti chiedo di specificare in quale casistica rientri, tra le seguenti :

questo? ns222***.ovh.net (nel caso cancellare)

la mia casistica credo riguardi il seguente caso:

2) you use an failover ip WITH an virtual mac:

[torpado]

ho seguito tutte queste guide, ma niente
non riesco ad avere connettività
...

ma niente da fare
non va

indica il nic-handle e parte del nome server in modo da poter verificare.

Inoltre ti chiedo di specificare in quale casistica rientri, tra le seguenti :

1) You are using an failover ip WITHOUT an virtual mac as an simple ALIAS:

Use the good configuration for your Failover IP: http://guida.ovh.it/IpSupplementare
important is that you use the good netmask and the right broadcast !

1a) your IP's are an BLOC RIPE NOT SPLITTED:

use the netmask and broadcast that you have received in the email for the allocation of the bloc.


1b) if your IP's are issue from an bloc ripeand if the bloc ripe is SPLITTED and if you NOT use an virtual mac:

the rules are the same as for an normal failover ip !! ( see case 1 )

Notice
An simple failover has not to use an GATEWAY. The ip is routed over the physical IP.

2) you use an failover ip WITH an virtual mac:

so you must ensure that the GATEWAY for the IP is the REAL gateway of your server.
Example:
if the IP of your server is : 91.121.xxx.129 the gateway of your server is 91.121.xxx.254

An failover WITH virtual mac on this host: 91.121.xxx.129 must use:
- 91.121.xxx.254 as gateway
- the assigned mac as mac for the virtual interface


3) you use an failover WITHOUT an virtual mac ON an VIRTUAL MACHINE throught 'NAT'

So your IP must NOT use the default gateway of server ( ip.ser.ver.254 ) BUT the physical IP of your eth0 !!
So the gateway for an IP failover in mode NAT is ip.of.your.server

VRACK customers has not to use the explanations here. They have their OWN guides. http://guida.ovh.it/VRack !!
In vrack a lot of configurations and errors can be possible. This are too many cases for explain here but you always welcome to ask us !

[fumocamel]

ho seguito tutte queste guide, ma niente
non riesco ad avere connettività

tra l'altro su un altro server, sempre con vsphere 4.1, ho un vm con ipcop e funziona perfettamente, mi filtra in ingresso ed in uscita e la configurazione è la seguente:

eth0 Link encap:Ethernet HWaddr 00:0C:29:C5:70:44
inet addr:10.10.10.1 Bcast:10.10.10.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1141951398 errors:0 dropped:0 overruns:0 frame:0
TX packets:684906379 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:2096521077 (1999.3 MB) TX bytes:1239213299 (1181.8 MB)

eth1 Link encap:Ethernet HWaddr 00:50:56:09:xx
inet addr:94.xx.xx.168 Bcast:94.xx.xx.255 Mask:255.255.255.0
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:647249406 errors:0 dropped:0 overruns:0 frame:0
TX packets:1095365485 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:4187810214 (3993.8 MB) TX bytes:1713590818 (1634.2 MB)

e il route -n ritorna:

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.10.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
94.xx.xx.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
0.0.0.0 94.xx.xx.254 0.0.0.0 UG 0 0 0 eth1

e tutto ciò funziona
sul server nuovo
preso un ip di failover
assegnato un mac address per vmware

assegnato il mac address alla scheda di rete della vm
configurato la eth0 (di una ubuntu) come è scritto nella guida
sia con netmask 255.255.255.255 che con netmask 255.255.255.0

ma niente da fare
non va

[cristianoscarpa]

E' necessario sapere quale modalità di virtualizzazione è in uso, in questo caso su Proxmox.

Kvm e so ubuntu.
Inoltre mi sembra strano che riceva questo tipo di mail per la seconda volta,dopo aver riconfigurato,senza avere cambiato la configurazione.

[BiagioParuolo]

Qual'è la soluzione se il gateway dell'host è su una subnet diversa dell' ip-failover?
Ho ricevuto l'email del blocco di un IP failover, ma nel pannello di controllo risulta ancora con il pallino verde. Come è possibile?

[torpado]

Buonasera, ho ricevuto alcune settimane fa una mail riguardante il blocco dell'ip per errata configurazione, quella volta ho eseguito com sempre le procedure descritte nella guida per proxmox, non avendo apportato modifiche al server ieri ho ricevuto una mail che mi avvisa della configurazione errata e oggi mi è stato bloccato l'ip 188.165.119.141 questo ip appartiene ad un servizio che non ha un'importanza vitale, quindi lo lascio bloccato, vorrei sapere il perché di questo visto che ho ricevuto le mail per altri io tra cui 188.165.119.142 che avevo già riconfigurato a suo tempo.

E' necessario sapere quale modalità di virtualizzazione è in uso, in questo caso su Proxmox.

[cristianoscarpa]

Buonasera, ho ricevuto alcune settimane fa una mail riguardante il blocco dell'ip per errata configurazione, quella volta ho eseguito com sempre le procedure descritte nella guida per proxmox, non avendo apportato modifiche al server ieri ho ricevuto una mail che mi avvisa della configurazione errata e oggi mi è stato bloccato l'ip 188.165.119.141 questo ip appartiene ad un servizio che non ha un'importanza vitale, quindi lo lascio bloccato, vorrei sapere il perché di questo visto che ho ricevuto le mail per altri io tra cui 188.165.119.142 che avevo già riconfigurato a suo tempo.

[torpado]

Salve a tutti,
anch'io riscontro problemi sull'ipfailover. Ho una semplice gentoo configurata come da guida
/etc/conf.d/net

config_eth0=( "188.165.236.x netmask 255.255.255.0"
"94.23.71.y netmask 255.255.255.255 brd 94.23.71.y" )
routes_eth0=( "default gw 188.165.236.254" )

Al riavvio della scheda:

/etc/init.d/net.eth0 restart
* Starting eth0
* Bringing up eth0
* 188.165.236.x
* 94.23.71.y
* Adding routes
* default gw 188.165.236.254 ...
* Mounting network filesystems ...
* Starting sshd ...

Se pingo dal server tutto ok... sepingo da fuori niente.
Grazie a tutti

grazie di indicare il nic-handle

[albo]

Salve a tutti,
anch'io riscontro problemi sull'ipfailover. Ho una semplice gentoo configurata come da guida
/etc/conf.d/net

config_eth0=( "188.165.236.x netmask 255.255.255.0"
"94.23.71.y netmask 255.255.255.255 brd 94.23.71.y" )
routes_eth0=( "default gw 188.165.236.254" )

Al riavvio della scheda:

/etc/init.d/net.eth0 restart
* Starting eth0
* Bringing up eth0
* 188.165.236.x
* 94.23.71.y
* Adding routes
* default gw 188.165.236.254 ...
* Mounting network filesystems ...
* Starting sshd ...

Se pingo dal server tutto ok... sepingo da fuori niente.
Grazie a tutti

[tmit]

errore mio: tra gli enne file da modificare, la versione di plesk non aveva aggiunto l'ip.fail.over anche nel http.conf del sottodominio di prova!
una volta fatto a mano, tutto funziona!

Buon lavoro!

[bilardi]

errore mio: tra gli enne file da modificare, la versione di plesk non aveva aggiunto l'ip.fail.over anche nel http.conf del sottodominio di prova!
una volta fatto a mano, tutto funziona!

[bilardi]

Salve a tutti.
ho creato un IP fail-over e ho configurato il server centos come descritto in http://guida.ovh.it/IpSupplementare.
il risultato è che posso entrare via ssh e via ftp sia con l'ip del server sia con l'ip fail-over ma digitando http://ip.del.server e http://ip.fail.over ho due risultati differenti: nel primo vedo la pagina di default di plesk, nel secondo vedo la pagina di default di apache.
cosa devo configurare in modo da ottenere lo stesso risultato anche nella porta 80 (ovvero la pagina di default di plesk)?

Grazie a tutti,

[bilardi]

il routing tra i server A e B è eseguibile solo dal managerOVH o anche via API?

[bilardi]

allora mi è sfuggito qualche cosa. ma quando, in http://guida.ovh.it/IpFailover, si parla di server A e server B, il routing è soltanto manuale?

[tmit]

FailOverIP normale

Non è possibile configurare un FailOverIP non LoadBalancing su più server.

[bilardi]

FailOverIP normale

[tmit]

Ho intenzione di collegare all'IP failover due server dedicati centos 5.2

Ma... si tratta di un FailOverIP normale o di Load Balancing?

[bilardi]

Ciao a tutti,

son all'inizio della configurazione dell'IP failover. Ho intenzione di collegare all'IP failover due server dedicati centos 5.2. Ho ricevuto l'IP dell'IP failover (di seguito xxx.xxx.xxx.xxx). Stavo seguendo la procedura per centos consigliata quì: http://guida.ovh.it/IpSupplementare quando mi è venuto un dubbio.
E' consigliato di creare il file /etc/sysconfig/network-scripts/ifcfg-eth0:0 con la seguente configurazione:

DEVICE="eth0:0"
BOOTPROTO=static
IPADDR="IP.FAIL.OVER"
NETMASK="255.255.255.255"
BROADCAST="IP.FAIL.OVER.ICI"
ONBOOT=yes

Quel che comprendo è che debba creare il file /etc/sysconfig/network-scripts/ifcfg-eth0:0 nel seguente modo:

DEVICE="eth0:0"
BOOTPROTO=static
IPADDR="xxx.xxx.xxx.xxx"
NETMASK="255.255.255.255"
BROADCAST="xxx.xxx.xxx.xxx"
ONBOOT=yes

Sembra che l'IP del server (di seguito yyy.yyy.yyy.yyy) in cui stò creando il file non debba usarlo come non debba usare nemmeno una riga tipo

GATEWAY="xxx.xxx.xxx.254"

Le mie domande sono:
* la configurazione con "xxx.xxx.xxx.xxx" che ho scritto è corretta?
* se configuro solo un server, posso fare il test "ping xxx.xxx.xxx.xxx"?
* accederò comunque da ssh con l'IP yyy.yyy.yyy.yyy?

Grazie a tutti,

Biliards.

[Artemis]

per prima cosa ti ringrazio per l'interessamento al mio problema.
secondo questo è l'errore che ho praticamente il gateway non me lo fa inserire.

# route add default 94.xx.xx.254
route: writing to routing socket: Network is unreachable
add net default: gateway 94.xx.xx.254: Network is unreachable

L'ip faillover è su una subnet completamente differente dal'ip del nodo principale. può essere quello?

[andrew9496]

ciao,

anche io sto riscontrando lo stesso problema. ho inserito come gateway l'ip indicato nelle guide.. ossia l'ip del dedicato con finale 254. ma nonostante questo la VM che ho creato è irraggiungibile. facendo un ping dall'esterno tramite tcpdump vedo che il ping arriva alla macchina ma non avviene il viceversa. ho provato a contattare l'assistenza ma mi è stato gentilmente risposto che erano cavoli miei sulle configurazioni. qualcuno ha qualche suggerimento da darmi? grazie. la vm è un freebsd 8 virtualizzato con proxmox kvm.

Prova a controllare il routing degli IP Regole di routing inserite manualmente

[Artemis]

ciao,

anche io sto riscontrando lo stesso problema. ho inserito come gateway l'ip indicato nelle guide.. ossia l'ip del dedicato con finale 254. ma nonostante questo la VM che ho creato è irraggiungibile. facendo un ping dall'esterno tramite tcpdump vedo che il ping arriva alla macchina ma non avviene il viceversa. ho provato a contattare l'assistenza ma mi è stato gentilmente risposto che erano cavoli miei sulle configurazioni. qualcuno ha qualche suggerimento da darmi? grazie. la vm è un freebsd 8 virtualizzato con proxmox kvm.

[torpado]

problema ancora non risolto, presenti ancora segnalazioni di errore. (faccio presente che il tutto si verifica su un solo ip)

Apri un ticket incidente postando la configurazione realizzata per l'ip che riporta ancora l'alert

[ang3lx]

problema ancora non risolto, presenti ancora segnalazioni di errore. (faccio presente che il tutto si verifica su un solo ip)

[ang3lx]

salve,
anche con l'ultima configurazione questa mattina ho ricevuto un altra notifica di malconfigurazione e di avviso di blocco ip.

[ang3lx]

Verifica la configurazione della VM Debian che genera gli alerts secondo questa guida

sembra essere andato ora. testo e vedo se arrivano altre notifiche

grazie

[torpado]

Salve,
dopo aver parlato con un operatore molto cortese del supporto, mi è stato indicato che l'errore era nel gateway che doveva essere l'ip del main server esxi con .254 finale.
ho testato la cosa, ma il server non va online (non pinga l'esterno e non viene pingato dall'esterno)
di seguito le due configurazioni della eth0 con cui ho testato la cosa restituendomi al ping Network is unreachable
..

Verifica la configurazione della VM Debian che genera gli alerts secondo questa guida

[ang3lx]

Salve,
dopo aver parlato con un operatore molto cortese del supporto, mi è stato indicato che l'errore era nel gateway che doveva essere l'ip del main server esxi con .254 finale.
ho testato la cosa, ma il server non va online (non pinga l'esterno e non viene pingato dall'esterno)
di seguito le due configurazioni della eth0 con cui ho testato la cosa restituendomi al ping Network is unreachable

VERSIONE 1

auto eth0
iface eth0 inet static
address xxx.xxx.xxx.xxx (IP.FAIL.OVER)
netmask 255.255.255.0
broadcast xxx.xxx.xxx.255
network xxx.xxx.xxx.0
gateway IP.SERVER.ROOT.CON.254.FINALE

VERSIONE 2

auto eth0
iface eth0 inet static
address IP.FAIL.OVER
netmask 255.255.255.255
broadcast IP.FAIL.OVER
network IP.FAIL.OVER
gateway IP.SERVER.ROOT.CON.254.FINALE

per ora torno sulla versione funzionale e attendo sul dafare

auto eth0
iface eth0 inet static
address IP.FAIL.OVER
netmask 255.255.255.255
broadcast IP.FAIL.OVER
network IP.FAIL.OVER
gateway IP.FAIL.OVER

[Kekko]

Io ho aggiunto l'ip supplementare ad un vps ProxMox e non riesce a funzionaare.L'ip non risponde al ping e non riesco ad entrare in ssh. Posto la mia configurazione dell interfaces del vps proxmox.

# Auto generated lo interface
auto lo
iface lo inet loopback

# Auto generated venet0 interface
auto venet0
iface venet0 inet static
	address 127.0.0.1
	netmask 255.255.255.255
	broadcast 0.0.0.0
	up route add -net 192.0.2.1 netmask 255.255.255.255 dev venet0
	up route add default gw 192.0.2.1
auto venet0:0
iface venet0:0 inet static
	address 94.23.xx.xxx
	netmask 255.255.255.255
	broadcast 0.0.0.0

Questa e quella che ho aggiunto

auto venet0:1
iface venet0:1 inet static
	address 94.23.xx.xx
	netmask 255.255.255.255
	broadcast 0.0.0.0

Fatto /etc/init.d/networking restart, Quest ultimo ip non riesce a prenderlo.Se digito ifconfig l'ip e presente nella configurazione di rete.Ma come detto prima non risponde al ping e non riesco ad accedere tramite ssh .Come mai?

[ang3lx]

posto qui sperando che qualche anima pia mi risponda visto che il supporto email è stato poco cortese è per niente d'aiuto.

uso esxi con ip splitted e virtual mac.
ho su diversi vds ma solo su uno o due virtual ricevo segnalazioni (in verità attualmente il problema è su un unico virtual)

ho provato entrambe le configurazioni proposte sulle guide

VERSIONE 1

auto eth0
iface eth0 inet static
address xxx.xxx.xxx.xxx (IP.FAIL.OVER)
netmask 255.255.255.0
broadcast xxx.xxx.xxx.255
network xxx.xxx.xxx.0
gateway xxx.xxx.xxx.254

VERSIONE 2

auto eth0
iface eth0 inet static
address IP.FAIL.OVER
netmask 255.255.255.255
broadcast IP.FAIL.OVER
network IP.FAIL.OVER
gateway IP.FAIL.OVER

ma continuo a ricevere ancora quelle email di notifica configurazione errata..in più questa sera mi è stato anche bloccato l'ip creando così disservizio

ho sbagliato io? è il sistema che è impazzito?

ringrazio tutti per l'aiuto

[camaran]

plesk però è una distribuzione da voi supportata

[tmit]

si ma se uno mette l'ip nel plesk con relativa netmask ha la notifica comunque

Difatti la configurazione devi modificarla da riga di comando tramite SSH.

[camaran]

si ma se uno mette l'ip nel plesk con relativa netmask ha la notifica comunque

[tmit]

http://forum.ovh.co.uk/showthread.php?p=32080

[Angie]

Hi everybody.

Let me provide you a little bit more informations about our warning emails of IP's.

Why we send it ?
ARP flooding due of faulty configurations on server do too many 'NOISE' in the network.
So we try to advise everybody about the bad configurations.


You can find 3 cases of errors and here are the solutions:


1) You are using an failover ip WITHOUT an virtual mac as an simple ALIAS:

Use the good configuration for your Failover IP: http://guida.ovh.it/IpSupplementare
important is that you use the good netmask and the right broadcast !

1a) your IP's are an BLOC RIPE NOT SPLITTED:

use the netmask and broadcast that you have received in the email for the allocation of the bloc.


1b) if your IP's are issue from an bloc ripeand if the bloc ripe is SPLITTED and if you NOT use an virtual mac:

the rules are the same as for an normal failover ip !! ( see case 1 )

Notice
An simple failover has not to use an GATEWAY. The ip is routed over the physical IP.

2) you use an failover ip WITH an virtual mac:

so you must ensure that the GATEWAY for the IP is the REAL gateway of your server.
Example:
if the IP of your server is : 91.121.xxx.129 the gateway of your server is 91.121.xxx.254

An failover WITH virtual mac on this host: 91.121.xxx.129 must use:
- 91.121.xxx.254 as gateway
- the assigned mac as mac for the virtual interface


3) you use an failover WITHOUT an virtual mac ON an VIRTUAL MACHINE throught 'NAT'

So your IP must NOT use the default gateway of server ( ip.ser.ver.254 ) BUT the physical IP of your eth0 !!
So the gateway for an IP failover in mode NAT is ip.of.your.server

VRACK customers has not to use the explanations here. They have their OWN guides. http://guida.ovh.it/VRack !!
In vrack a lot of configurations and errors can be possible. This are too many cases for explain here but you always welcome to ask us !



---
Some FAQ:

Why I receive an alerte for bad configuration when my IP works. ?

An IP can work and can have bad configuration. The IP works but not in the CLEAN way.
server1.ovh.net: 2 failovers with bad configuration
server2.ovh.net: 2 failovers with bad configuration
Sometimes server1.ovh.net ( or one of his failovers ) try to talk with an failover on server2.ovh.net.
Bad configuration do that this not work ( error ARP becaus the router can not update his ARP table ) .
We have ARP who has in our SLA. This is not normal and so we sent an email.

5 minutes later the server1.ovh.net talk directly to server2.ovh.net and the ARP table is updated. Than the error ARP disappears. But not your bad configuration and than after I time, is happen again.
So is important to fix this errors.


How can I see wath is happen?

Using tcpdump and guides for each configuration can help.
First check if the configuration of your usage is as explained in the guide.
Then check in tcpdump what's wrong.



I hope my little message can help you to understand that we have a lot of possibility of errors and that we not can provide 1 solution for everybody.


Cheers,
Angie

[tmit]

Partendo dal presupposto che la configurazione da seguire
inerente l'installazione di una IP FailOver,
deve assolutamente seguire le linee guida citate ai link

http://guida.ovh.it/IpFailover
http://guida.ovh.it/IpSupplementare
http://guida.ovh.it/ClientBridge

ATTENZIONE:
Non dovete mai utilizzare l'IP principale del vostro server come gateway.

Inoltre non dovete in nessun caso utilizzare:

route add default gw dev eth0

in quanto rischiate di subire il taglio dell'IP del vostro server virtuale.



La procedura di disattivazione per il momento è stata sospesa.
La riattiveremo tra qualche giorno.

Abbiamo lasciato 48 ore tra ciascun alert,
le prime disattivazioni avranno luogo domani sera verso le 18h00.

Capisco che le email possono fare un pò paura !

Bisogna ricordare che il cliente può in qualsiasi momento sbloccare il suo IP
dal suo manager senza alcuna verifica da parte nostra.

E' quindi possibile riattivare il proprio IP molto facilmente.

In che modo:
Accedete nel vostro MANAGERv3 ( https://www.ovh.it/managerv3 )
* selezionate il server in questione
* sulla sinistra accedete all'area "Stato del server"
* nel Follow up, selezionate "Adresses IP Bloquées"
* ora in quest'area potete sbloccare gli IP che vi sono stati bloccati
a causa di questa configurazione errata

N.B.: Tale procedura deve essere eseguita solo ed esclusivamente se
siete certi che la configurazione apportata alla vostra FailOver sia corretta.