[chibisuke]

ich hatte dieses etwas unlustige problem auch schon, allerdings mit einem instabilen switch bei OVH, der so alle 2 oder 3 tage von selbst rebootet ist, und seine config weg geschmissen hat.

Die VMs auf dem host waren dann insgesammt effektiv 3 wochen down, weil OVH es nicht auf die reihe bekommen hat. Ich meine... mal 2 oder 3 IPs zu löschen und neue VMacs anzulegen ist ja noch ok, aber bei diesem schwachsinnigen künstlichen 5 minuten delay dass die vmac einstellungen haben, ist das bei 10+ VMs einfach nicht mehr tragbar, weil das sind einfach mal 2 stunden arbeitszeit die dafür drauf gehen.

[Leo84]

ist zwar schon ein alter Thread aber vill hat ja noch jemand das selbe Problem wie ich Heute. War am verzweifeln aber dann kam mir der einfall Virtuelle Mac

Wenn Virtuelle Mac zugewiesen sind hier die Lösung.

- Virtuelle Mac löschen
- 5 Minuten warten
- Neue Virtuelle Mac erstellen
- 5 Minuten warten

und es geht wieder

[at0m]

Laut OVH sollte man allerdings eher ein Störungsticket erstellen als den normalen Support anzufragen. Hab ich zwar auch zuerst nicht gemacht, aber jetzt weiß ich es .

mfg

[kikei]

Du hast mir grade "bewiesen" das es nicht an mir liegt. Habe das gleiche Problem. Habe einen 4 Block Ripe IP's aufgeteilt. Danach haben die bereits vorher verwendeten IP's nicht mehr funktioniert. Nun habe ich testweiße eine IP genutzt, welche ich noch nicht verwendet hatte und diese funktioniert.

Habe grade den normalen E-Mail Support angeschrieben.

PS:

1    <1 ms    <1 ms    <1 ms  192.168.1.1
 2    21 ms    20 ms    21 ms  217.0.116.180
 3    34 ms    24 ms    30 ms  87.186.198.202
 4    44 ms    30 ms    39 ms  217.239.40.242
 5    31 ms     *       31 ms  fra-1-6k.de.eu [94.23.122.153]
 6    47 ms     *       76 ms  fra-5-6k.de.eu [94.23.122.222]
 7    41 ms     *       39 ms  th2-5-6k.fr.eu [213.251.128.2]
 8    40 ms     *       40 ms  gsw-1-6k.fr.eu [213.186.32.210]
 9    39 ms    39 ms    43 ms  rf-1-a1.fr.eu [91.121.131.234]
10     *        *        *     Zeitüberschreitung der Anforderung.
11     *        *        *     Zeitüberschreitung der Anforderung.
12     *        *        *     Zeitüberschreitung der Anforderung.
13     *        *        *     Zeitüberschreitung der Anforderung.

Mein Hostserver ist im 176.31.248.0 Netz und die RIPE IP's im 176.31.66.0 Netz.

[at0m]

Naja wenn ich 16 IPs habe, ist der Block wohl auch 16 IPs "groß" (/28).

Und warum ich Sie habe aufteilen lassen? Es ist wohl so, dass ich Zukunft eventuell einzelne IPs auf einen anderen Root umziehen muss (von OVH). Das dient also zur Vorsorge.

Konfiguriert ist immer noch alles nach dem Schema (auf den VMs):

http://hilfe.ovh.de/BridgeClient#link4

Die virtuellen MAC Addressen sind den IPs auch alle richtig zugewiesen.

Virtuell hängen alle VMs an einem vSwitch der natürlich nach draußen führt, hier hab ich auch nichts geändert. Das Routing aller IPs zeigt auf die vSphere Host IP (war auch noch nie anders).

mfg

P.S.

Gesperrt sind auch keine IPs.
Und noch was: Der Root steht in Roubaix-4 falls uns das weiterbringt..

edit:

Hier mal ein tracert zu einer Failover IP einer meiner VMs:

Routenverfolgung zu DOMAIN [FAILOVERIP] über maximal 30 Abschni
tte:

  1    <1 ms    <1 ms    <1 ms  ROUTER [INTERNEROUTERIP]
  2    41 ms    40 ms    40 ms  87.186.224.194
  3    41 ms    40 ms    40 ms  87.186.255.246
  4    50 ms    50 ms    49 ms  f-ee4-i.F.DE.NET.DTAG.DE [62.154.14.246]
  5    50 ms    49 ms     *     fra-1-6k.de.eu [94.23.122.153]
  6    49 ms    50 ms     *     fra-5-6k.de.eu [94.23.122.222]
  7    57 ms    58 ms     *     th2-5-6k.fr.eu [213.251.128.2]
  8    60 ms     *       59 ms  gsw-1-6k.fr.eu [213.186.32.210]
  9    59 ms    60 ms    58 ms  rf-1-a1.fr.eu [91.121.131.234]
 10     *        *        *     Zeitüberschreitung der Anforderung.
 11     *        *        *     Zeitüberschreitung der Anforderung.
 12     *        *        *     Zeitüberschreitung der Anforderung.
 13     *        *        *     Zeitüberschreitung der Anforderung.
 14     *        *        *     Zeitüberschreitung der Anforderung.
 15     *        *        *     Zeitüberschreitung der Anforderung.
 16     *        *        *     Zeitüberschreitung der Anforderung.
 17     *        *        *     Zeitüberschreitung der Anforderung.
 18     *        *        *     Zeitüberschreitung der Anforderung.
 19     *        *        *     Zeitüberschreitung der Anforderung.
 20     *     ^C

Update:

Also das muss definitiv ein Problem von OVH sein, weil ich hab jetzt mal eine Failover IP auf einen anderen Root geroutet und dann mit den gleichen Settings wieder zurück gestellt. Jetzt ist zumindest schon mal eine Failover IP wieder erreichbar.

Update:

So nach dem ewigen Umziehen der ganzen IPs auf einen anderen Root und das wieder "zurückumziehen" der IPs funktionieren sie nun wieder. Komisch, sonst habe ich absolut nichts umgestellt.

[strex]

Warum hast du den denn aufteilen lassen? Wie groß ist der IP Block? Traceroutes..
Wie sieht das network setup aus, mit so wenig Angaben kann man natürlich alles vermuten.

Das Aufteilen sowie Umrouten geht innerhalb von 15 Minuten.

[at0m]

Hallo,

Ich habe ein ziemliches Problem .

Ich habe ja einen Isgenug 24G mit einem RIPE Failover IP Block am laufen. Auf dem Isgenug läuft ein VMware vsphere esxi mit 14 VMs.

Soweit hat das auch alles funktioniert, alle VMs waren immer erreichbar. Nun habe ich gestern meinen RIPE Block aufteilen lassen. Nun funktioniert garnichts mehr(IPs nicht mehr pingbar trotz restarts usw.). Der ovh Support hat auch noch nicht geantwortet. Dauert das einige Zeit oder muss ich für bzw. bei den VMs jetzt irgendwo etwas umstellen?

Ein bisschen widersprüchlich finde ich ja die Aussagen im Manager:

In der Übersicht steht, es seien 16 Failover IPs aktiviert, unter Dienstleistungen -> Failover IPs steht das mein Server über keine Verfügt und davon auch keine in Benutzung wären. Darunter ist jedoch eine Liste meiner IPs mit den korrekten Routingeinstellungen.

Was kann ich jetzt also tun?

MfG