Proxmox ip failover problème reseau vers orange
... / Proxmox ip failover probl...
< Question précédente   -   Question suivante >
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
question

Proxmox ip failover problème reseau vers orange

L
Par
LyesB2
Créé le 2020-11-30 19:21:39 (edited on 2024-09-04 12:41:38) dans Serveurs Dédiés-old

Bonjour,
J'ai installé proxmox sur une machine dédié GAME-02, j'ai installé une VM Debian 10.6, j'ai bien mis l'IP FO, le masque en /32 ainsi que la gateway en .254. J'arrive bien à ping, de la machine hôte, depuis le client, depuis mon PC, sans soucis, aucune perte de paquet, latence stable et faible.

Mais un problème persiste, si je me connecte à un service web, un serveur de jeux hébergé dessus ou tout simplement sur le ssh, sa fonctionne une fois toute les 5 - 16 secondes. Par exemple, je lance putty, je mes l'ip de la VM, sa ne fonctionne pas, je retente 3 secondes après, sa ne fonctionne pas, j'attend encore 5 secondes, sa fonctionne... C'est incompréhensible. Si vous avez besoin de plus d'informations n'hésitez surtout pas !

Merci d'avance ! :)
Avis positifs (0)
5756 Vues
4 réponses ( Latest reply on 2020-12-23 21:35:54 Par
BillyD
)
L



Utile (0)
L

Et mes collègues de chez orange n'arrivent pas a ping l'ip ...
Utile (0)
L

Je confirme, même en 4G Sosh il y a des problèmes, la connexion ssh fonctionne 1 fois sur 10
Utile (0)
L

Utile (0)
J

Bonjour,

c'est normale les 2 IPs différente entre votre config proxmox et le traceroute ?
132.125.23.41 (Pas OVH) != 135.125.23.41 (OVH)

Sinon vous avez bien généré et mis la MAC virtuel sur la VM ?

En tout cas là on rentre dans le réseau OVH puis blackout comme si l'IP FailOver était non routé vers le serveur.

Cordialement, janus57
Utile (0)
L

Bonjour,

Ah effectivement, faute de frappe, l'ip exacte est : 135.125.23.41 ^^

Oui j'ai bien mis la mac virtuel sur les paramètres réseau sur proxmox, la vm ping très bien tout les sites internets connu, youtube, google etc ...

La configuration de la VM m'a l'air correct.
Utile (0)
L

Détermination de l’itinéraire vers ip41.ip-135-125-23.eu [135.125.23.41]
avec un maximum de 30 sauts :

1 1 ms 2 ms 2 ms livebox.home [192.168.1.1]
2 3 ms 3 ms 2 ms 80.10.234.17
3 7 ms 6 ms 8 ms lag-118.nclil201.1dascq.francetelecom.netdascq.francetelecom.net [193.253.88.190]
4 21 ms 5 ms 19 ms ae42-0.nrlil101.1dascq.francetelecom.netdascq.francetelecom.net [193.252.160.197]
5 7 ms 42 ms 34 ms 10.nrlil102.Lille.francetelecom.net0.nrlil102.Lille.francetelecom.net [193.252.160.238]
6 5 ms 8 ms 4 ms 11.nolil602.Lille.francetelecom.net1.nolil602.Lille.francetelecom.net [193.252.100.82]
7 10 ms 8 ms 9 ms be102.1a72.fr.eua72.fr.eu [94.23.122.225]
8 52 ms 11 ms 11 ms be106.1nc5.fr.eunc5.fr.eu [94.23.122.238]
9 * * * Délai d’attente de la demande dépassé.
10 15 ms 16 ms 39 ms vl1251.1a75.fr.eua75.fr.eu [37.187.232.29]
11 15 ms 16 ms 15 ms be50-7.1a9.fr.eua9.fr.eu [188.165.9.72]
12 14 ms 16 ms 15 ms ip41.ip-135-125-23.eu [135.125.23.41]
Utile (0)
J

Bonjour,

cela ne touche pas que le réseau Orange :
Depuis un serveur OVH sur RBX3 :
[code]
:~# traceroute 135.125.23.41
traceroute to 135.125.23.41 (135.125.23.41), 30 hops max, 60 byte packets
1 16k.fr.eu6k.fr.eu (188.165.225.252) 9.648 ms 9.698 ms 9.746 ms
2 10.95.69.6 (10.95.69.6) 0.149 ms 0.186 ms 0.171 ms
3 10.95.66.56 (10.95.66.56) 0.155 ms 10.95.66.48 (10.95.66.48) 0.138 ms 10.95.66.56 (10.95.66.56) 0.151 ms
4 vl1250.1a75.fr.eua75.fr.eu (37.187.232.27) 9.153 ms 9.154 ms vl1251.1a75.fr.eua75.fr.eu (37.187.232.29) 9.130 ms
5 be50-7.1a9.fr.eua9.fr.eu (188.165.9.72) 9.979 ms be50-5.1a9.fr.eua9.fr.eu (188.165.9.70) 11.476 ms be50-5.1a9.fr.eua9.fr.eu (188.165.9.74) 10.566 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[/code]

Depuis un serveur OVH sur RBX4 :
[code]
:~# traceroute 135.125.23.41
traceroute to 135.125.23.41 (135.125.23.41), 30 hops max, 60 byte packets
1 16k.fr.eu6k.fr.eu (37.59.40.252) 0.463 ms 0.453 ms 0.577 ms
2 10.95.69.202 (10.95.69.202) 0.267 ms 0.204 ms 0.267 ms
3 10.95.66.30 (10.95.66.30) 0.178 ms 10.95.66.46 (10.95.66.46) 0.357 ms 0.317 ms
4 vl1251.1a75.fr.eua75.fr.eu (37.187.232.29) 9.228 ms vl1250.1a75.fr.eua75.fr.eu (37.187.232.27) 9.227 ms 9.383 ms
5 be50-5.1a9.fr.eua9.fr.eu (188.165.9.70) 10.128 ms 11.678 ms be50-7.1a9.fr.eua9.fr.eu (188.165.9.72) 9.985 ms
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[/code]

Depuis un serveur OVH sur GRA1 :
[code]
:~# traceroute 135.125.23.41
traceroute to 135.125.23.41 (135.125.23.41), 30 hops max, 60 byte packets
1 37.187.7.252 (37.187.7.252) 0.285 ms * *
2 10.17.134.6 (10.17.134.6) 0.801 ms 0.787 ms 1.026 ms
3 10.73.0.182 (10.73.0.182) 0.304 ms 0.284 ms 10.73.0.20 (10.73.0.20) 0.247 ms
4 vl1248.1a75.fr.eua75.fr.eu (37.187.231.252) 1.951 ms vl1247.1a75.fr.eua75.fr.eu (37.187.231.234) 1.891 ms vl1248.1a75.fr.eua75.fr.eu (37.187.231.252) 1.896 ms
5 vl1250.1a75.fr.eua75.fr.eu (37.187.232.27) 10.861 ms 10.869 ms vl1251.1a75.fr.eua75.fr.eu (37.187.232.29) 10.847 ms
6 be50-5.1a9.fr.eua9.fr.eu (188.165.9.74) 11.472 ms be50-5.1a9.fr.eua9.fr.eu (188.165.9.70) 11.635 ms 11.555 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
[/code]

Que donne un traceroute depuis la VM vers l'extérieur ?

Cordialement, janus57
Utile (0)
L

De la VM vers ip youtube :

root@debian:~# traceroute 172.217.18.206
traceroute to 172.217.18.206 (172.217.18.206), 30 hops max, 60 byte packets
1 151.80.230.253 (151.80.230.253) 2.698 ms 2.841 ms 0.766 ms
2 be116.1a75.fr.eua75.fr.eu (188.165.9.75) 0.200 ms be116.1a75.fr.eua75.fr.eu (188.165.9.77) 0.261 ms 0.192 ms
3 10.95.48.10 (10.95.48.10) 1.326 ms 1.328 ms 1.283 ms
4 be105.fra-fr5-sbb2-nc5.de.eu (91.121.215.197) 3.167 ms 3.222 ms 3.181 ms
5 10.200.0.2 (10.200.0.2) 5.456 ms 10.200.0.6 (10.200.0.6) 3.388 ms 10.200.0.2 (10.200.0.2) 3.246 ms
6 * * *
7 108.170.252.18 (108.170.252.18) 3.306 ms 108.170.251.209 (108.170.251.209) 3.819 ms 108.170.252.19 (108.170.252.19) 3.768 ms
8 108.170.228.9 (108.170.228.9) 3.679 ms 108.170.226.3 (108.170.226.3) 3.746 ms 209.85.252.214 (209.85.252.214) 4.053 ms
9 209.85.252.149 (209.85.252.149) 9.492 ms 209.85.253.185 (209.85.253.185) 10.011 ms *
10 72.14.238.52 (72.14.238.52) 9.406 ms 9.426 ms 209.85.251.58 (209.85.251.58) 10.036 ms
11 108.170.244.225 (108.170.244.225) 10.110 ms 10.102 ms 108.170.244.161 (108.170.244.161) 9.231 ms
12 66.249.94.83 (66.249.94.83) 10.152 ms 10.213 ms 10.258 ms
13 1f14.1e100.netf14.1e100.net (172.217.18.206) 9.282 ms 9.070 ms 9.058 ms




De la VM vers ip OVH :

root@debian:~# traceroute 164.132.233.101
traceroute to 164.132.233.101 (164.132.233.101), 30 hops max, 60 byte packets
1 151.80.230.253 (151.80.230.253) 2.266 ms 2.192 ms 2.417 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
Utile (0)
L

Bonjour,

Voici le résultat d'un traceroute depuis mon école vers l'ip FO :

C:\Users\******>tracert 135.125.23.41

Détermination de l’itinéraire vers ip41.ip-135-125-23.eu [135.125.23.41]
avec un maximum de 30 sauts :

1 <1 ms <1 ms <1 ms Srv-Pfsense.localdomain [192.168.20.254]
2 * * * Délai d’attente de la demande dépassé.
3 * 7 ms * 10.152.0.33
4 6 ms * 4 ms 185.218.248.4
5 * 6 ms 5 ms 13.edge6.Paris1.Level3.net3.edge6.Paris1.Level3.net [213.242.126.49]
6 * * * Délai d’attente de la demande dépassé.
7 * * * Délai d’attente de la demande dépassé.
8 11 ms 10 ms * be101.1nc5.fr.eunc5.fr.eu [94.23.122.215]
9 * * * Délai d’attente de la demande dépassé.
10 8 ms 8 ms 10 ms be101.1nc5.fr.eunc5.fr.eu [94.23.122.215]
11 16 ms 19 ms 19 ms be102.1nc5.fr.eunc5.fr.eu [91.121.215.218]
12 * * * Délai d’attente de la demande dépassé.
13 18 ms 17 ms 16 ms be50-7.1a9.fr.eua9.fr.eu [188.165.9.76]
14 14 ms 15 ms * ip41.ip-135-125-23.eu [135.125.23.41]
15 * 14 ms 14 ms ip41.ip-135-125-23.eu [135.125.23.41]

Itinéraire déterminé.


Je précise que depuis mon école, je n'ai aucun soucis de ping / connexion ssh etc.. Tout fonctionne à merveille !
Utile (0)
L

Voici un screen du résultat d'un ping de la VM vers orange.fr et du pc de mon école vers orange.fr




Résultat traceroute de la vm vers orange.fr :
> root@debian:~# traceroute orange.fr
> traceroute to orange.fr (193.252.133.34), 30 hops max, 60 byte packets
> 1 151.80.230.253 (151.80.230.253) 1.171 ms 0.964 ms 1.203 ms
> 2 be116.sbg-d2-a75.fr.eu (188.165.9.77) 0.227 ms 0.243 ms 0.236 ms
> 3 10.95.48.10 (10.95.48.10) 1.381 ms 1.381 ms *
> 4 be103.par-th2-sbb1-nc5.fr.eu (94.23.122.139) 6.486 ms 6.479 ms 6.480 ms
> 5 * 10.200.2.73 (10.200.2.73) 69.236 ms *
> 6 * * *
> 7 * * *
> 8 193.252.137.9 (193.252.137.9) 6.583 ms 6.552 ms 6.552 ms
> 9 ae45-0.noidf001.Paris3eArrondissement.francetelecom.net (193.252.98.114) 7.192 ms * 7.203 ms
> 10 193.252.227.154 (193.252.227.154) 6.582 ms 6.670 ms *
> 11 * * fw-bae02-v2999.orion.net.m1.fti.net (81.52.143.168) 6.558 ms
> 12 * * *
> 13 * * *
> 14 * * *
> 15 * * *
> 16 * * *
> 17 * * *
> 18 * * *
> 19 * * *
> 20 * * *
> 21 * * *
> 22 * * *
> 23 * * *
> 24 * * *
> 25 * * *
> 26 * * *
> 27 * * *
> 28 * * *
> 29 * * *
> 30 * * *


J'ai peut-être une hypothèse, celle d'avoir une IP blacklist Orange ? Est-ce possible ?
Utile (0)
L

Et bien voila, comme beaucoup de personne ayant un problème similaire, le problème c'est résolu tout seul, presque une semaine d'utilisation de service perdu, mais bon, sa fonctionne.

Je laisse le sujet ouvert pour l'instant, je le fermerais ce week-end si le problème réapparait.

Je remercie @janus57 pour avoir tenté de m'aider ! :)
Utile (0)
L

Bonjour, le problème est revenu, c'était trop beau pour être vrai
Utile (0)
N

Bonjour,

J'ai eu le même souci : https://community.ovhcloud.com/community/fr/proxmox-et-ips-failover-sur-plusieurs-conteneurs-lxc?id=community_question&sys_id=16c13940f5d246d02d4c5f7a9ab36106

Visiblement, il y avait systématiquement une ou plusieurs adresses parmi celles que j'avais qui ne fonctionnaient pas. C'était aléatoire dans le sens où ça n'était jamais les mêmes. Mais en fait, seules les premières étaient activées...

C'était un problème de configuration du routeur/switch chez OVH. Je précise qu'en mode rescue cela fonctionnait lorsque je n'avais qu'une seule adresse aussi la réponse "standard" du support ne suffit pas à régler le problème. J'ai passé plusieurs mois à me creuser la tête ne voulant pas 'déranger' le support pour une c... que j'aurais fait dans la configuration. Pour mon malheur, ça fonctionnait en mode rescue...

Je n'ai eu la certitude d'un problème que lorsque ayant acheté d'autres IP FO j'ai eu 1 adresse sur 2 qui fonctionnaient, puis 1/3 et enfin 2/4... Et c'est seulement quand j'en ai eu 4 que le problème est apparu sous rescue ...et que le support a enfin pris mon problème au sérieux. Ça a pris pas loin d'un mois à être réglé une fois le support contacté.

Je te conseille d'ouvrir un ticket immédiatement. De tester en mode rescue. Et de réfléchir si acheté 4 adresses FO est un investissement intéressant pour passer la phase du "si ça marche en rescue, c'est que le problème vient de votre configuration" !

Cordialement,
Utile (0)
L

Bonjour,
Merci de votre réponse.
Effectivement je sèche, je ne pense pas que cela vient de moi.
J'ai ouvert un ticket il y a plus de 48h sans réponse...

Je test le mode rescue ce soir, en espérant que cela m'aide a comprendre le problème .

Cordialement
Utile (0)
JRA

Hello,

Il manquerait pas un bout de configuration à ta vm
Lorsque tu configures une ip toute seule, il faut indiquer le réseau de sortie pour que le routage se fasse:

> post-up route add GATEWAY_IP dev eth0
> post-up route add default gw GATEWAY_IP
> pre-down route del GATEWAY_IP dev eth0
> pre-down route del default gw GATEWAY_IP

GATEWAY_IP représente la gateway du proxmox.

Pour éviter ces configurations, le mieux c'est d'utiliser le vrack avec une plage d'adresse assez grande.
Dans ce cas la tu peux utiliser la gateway de ta plage d'adresse, soit la derniere ip de la plage hors broadcast.

Bon courage
https://www.captainadmin.com
Utile (0)
L

Bonsoir,

Justement, j'ai vu que la configuration réseau de debian 10 était trés incertaine sur les tutoriels.
Donc pour être sur, j'ai essayé avec ubuntu 20.04 et le problème est exactement le même ...




Sinon j'avais déjà essayé de rajouté les lignes que vous avez indiqué sur la vm debian 10, mais malheureusement, le problème est le même que ce soit avec l'ip x.x.x.41-42-44

Cordialement
Utile (0)
JRA

Pour etre sur:
Si on se dit que l'ip du proxmox c'est xx.xx.xx.xx
et celle failover de ta vm, yy.yy.yy.yy
Ta conf debian 10 dans /etc/network/interfaces

> auto eth0
> iface eth0 inet static
> address yy.yy.yy.yy
> netmask 255.255.255.255
> broadcast yy.yy.yy.yy
> post-up route add xx.xx.xx.254 dev eth0
> post-up route add default gw xx.xx.xx.254
> pre-down route del xx.xx.xx.254 dev eth0
> pre-down route del default gw xx.xx.xx.254

Ensuite je testerai d'abord le ping proxmox, puis de sa gateway puis du web genre 8.8.8.8
Si ca bug encore, alors tu as sans doute un soucis de table ARP, pour ca il faut forcer la mise à jour en générant du trafic.
Un ping flow vers une de tes machines devrait aider à résoudre le probleme
Utile (0)
L

Merci beaucoup pour l'aide apporté !
le "auto ens18" empêche le restart du service network





Du coup j'ai enlevé auto ens18 et j'ai procédé à des tests depuis la VM :



Pour le ping flow, je ne vois pas du tout ce que c'est ...
Utile (0)
JRA

Enlève la ligne gateway 149.202.223.254
Elle fait doublon avec le reste de la conf.

A force de relance d'interface, il arrive que la vm se perdent, je te conseille un petit reboot une fois que tu es sur de la conf.

Ensuite est-ce que la conf réseau est fonctionnelle ?

Le ping flow c'est comme un ping mais tu envoies un nombre énorme de ping en parallèle.
Attention, ca peut etre considéré comme une attaque donc fait le vers des services qui t'appartiennent
il faut simplement ajouter l'option -f
Utile (0)
L

Quand j'enlève la gateway, je ne peux plus ping.
Du coup j'ai remis la gateway, remis auto ens18 et j'ai reboot.
Le service networking ne voulait pas démarré du coup j'ai reenlever auto ens18, et je reviens au même point ^^

Je vais essayé des ping flow voir ce que sa donne ! :)
Utile (0)
JRA

Tu aurais pas une partie de la conf réseau dans systemd ?
Ca ressemble à un conflit de configuration quelque part.

Pour éloigner les doutes, tu peux configurer un lxc plutot qu'une vm ?
Perso, j'utilise beaucoup proxmox et les containers marchent super bien, j'essaie de tout migrer dessus autant que possible.
Si tu as la possibilité de le faire, vas y aussi.
Pour la conf réseau, il te suffit de mettre l'ip failover et la gateway comme je te l'ai indiqué.

Sinon dans les tests ping, tu peux voir s'il n'y a pas un problème de taille de paquet dans le réseau avec:
ping -s 1400 @ip de ton infra
si le ping passe pas, il y a peut-etre un probleme de mtu dans le réseau
Utile (0)
L

Il n'y avait aucune conf reseau présent dans systemd.

Je suis entrain de mettre une template officiel debian 10 sur un lxc.
Je ne connais pas trop mais sa a l'air sympathique :)
Utile (0)
L

Voila la conf du container, alors toujours pareil j'ai des perturbations depuis mon pc chez orange / 4g sosh aussi pour ce connecter au ssh.
Le CT ne peut pas ping orange.fr ... Sacré histoire



Je n'ai pas touché au fichier de conf network
J'ai fais un ping -f du CT jusqu'à la machine proxmox et inversement. J'ai un point qui s'affiche et disparait assez fréquemment. Screen :
Utile (0)
N


Pour éviter ces configurations, le mieux c'est d'utiliser le vrack avec une plage d'adresse assez grande.



GAME-02 => SYS = PAS DE VRACK
Utile (0)
L

Mais du coup je me pose une question, est-ce qu'il y a une configuration à faire depuis le serveur principal / proxmox ?
Utile (0)
N

À part générer la MAC Virtuelle pour ton IP FO et https://pve.proxmox.com/wiki/OVH#IPv4 configurer l'adresse IP FO sur ton container LXC rien d'autre normalement.
Utile (0)
D

J'ai le même souci une vm avec ipfailover d'une ligne ADLS Orange c'etatit down depuis plusieurs semaines. Depuis une ligne 3/4G orange c'est toujours DOWN.

Depuis une autre box ou tel free / sfr pas de souci
j'ai ouvert un ticket
################
Réponse du support
Je vous prie de nous excuser pour le délai de la réponse.
Aucune maintenance n'a été effectué sur le host.
Actuellement le serveur est démarré sur disque et les services son démarrés :

PORT STATE SERVICE
22/tcp open ssh
80/tcp open http

N'hésitez pas à nous recontacter en cas de souci.
#############
Je n'ai jamais dit que les services sont KO, j'ai dit que le serveur et souvent inaccessible depuis certaine connexion Orange que ce soit en ADSL ou en 4G merci de prendre connaissance du traceroute, c'est bien chez vous qu'il y a un souci

J'attend....

C'est clairement un problème de routage
Utile (0)
L

Bonjour,
Je suis rassuré, sa fait plus de 72H que mon ticket est sans réponse
Utile (0)
D

Il faut attendre plusieurs jours
Utile (0)
L

Aie, pensez-vous qu'un geste commercial pourra être négocié si c'est vraiment un problème de chez ovh ?
Utile (0)
D

Avant de demander un geste commercial il faut être sur que le souci n'ai pas de la conf du serveur
Utile (0)
L

3 distrib différente , une réinstallation de proxmox, 9 ip essayé ...
Si c'est moi qui fait une mauvaise manipulation je ne comprend pas
Utile (0)
N

Pour moi c'était clairement un souci chez OVH, confirmé par le support.

Je ne sais pas si j'ai eu un geste commercial, je ne me souviens plus de la réponse du support (mon ticket a disparu...) mais en juin et juillet on m'a fait grâce de la TVA. Vu le temps que j'ai passé à cerner le problème pour eux, je m'attendais à mieux... mais comme visiblement ils n'ont pas définitivement réglé le problème, ont-ils seulement pris la mesure du problème ?

À savoir que mon problème a trainé longtemps en ticket et qu'il a connu un boost lorsque j'ai appelé et que j'ai eu la chance de tomber apparemment sur le support Québec(?, à l'accentomètre). D'ailleurs un grand merci à la personne que j'ai eu qui a su, quand il a vu que je savais un minimum de quoi je parlais, ne pas me faire perdre un peu plus mon temps.

Le _sentiment_ que j'ai eu c'est que le support "ticket" a passé plus de temps à me balader dans leur procédure à deux balles qu'à réfléchir au problème que j'avais documenté très clairement dans mon ticket.
Utile (0)
D

Perso je pense certain comme Orange 4G sont en FULL IPV6, pour le test j'ai activer l'ipv6 sur le serveur, configuration d'un domaine et le ping6 répond .... haha voilà une piste
Utile (0)
L

Oui comme d'habitude, le support c'est énormément de blabla, il faut toujours forcé pour arrivé a ce que l'on veut ...

Je relance le ticket tout les 2 jours mais bon sa n'a pas l'air de bouger.
Utile (0)
L

Je me suis penché sur sa il y a quelques jours, je pense que je vais retenter d'activer l'ipv6. J'ai juste du mal car les gens ont une longue adresse ipv6 et moi j'ai que le préfixe ^^
Utile (0)
L

J'ai remis l'ipv6, je peux bien ping mais toujours des perturbations lorsqu'on est chez orange ...
Utile (0)
N

Oui j'ai pensé à ça mais je me disais IP FO... c'est en v4.
Utile (0)
B

Bonjour, je ne sais pas si le problème est identique chez nous mais ça y ressemble.
Nous avons pris un serveur dédié Game pour héberger plusieurs services dont notre serveur de jeu évidemment mais aussi notre site internet.
Certains joueurs n'arrivent pas à se connecter et ont des timeout (ça représente environ 1 joueur sur 4). Côté site internet, nous avons des soucis par exemple pour ping "discord.com" (je prends cet exemple car nous fournissons une authentification OAuth avec Discord), certaines adresses répondent d'autres non. Nous avons des timeout irréguliers (test avec un ping continue vers le domaine ``ping -c 2 discord.com``) :


Depuis OVH :


Discord utilisent Cloudflare, il semblerait que certaines IP ping depuis OVH mais d'autres non. Alors que depuis chez moi, aucun soucis :


À savoir que nous possédons un bloc RIPE, que nos IP Failover sont bien configurées et fonctionnent correctement (accès à internet, routage ok, administration distante ok...).
Au départ, je pensais que ça venait du pare-feu, mais même en mettant toutes les autorisations côté OVH et de notre côté, ça ne fonctionne pas.
J'ai fais des captures réseau et il semble que certains paquets passent en retransmission :


Dans ce cas là par exemple, notre serveur interroge discord.com pour l'OAuth :


J'ai trouvé un post de 2019 auquel j'ai répondu tout à l'heure mais je ne pense pas que ça avance vu l'ancienneté du post :
https://community.ovhcloud.com/community/fr/connect-game-server?id=community_question&sys_id=c3a23d80b55a0ad0f078da7e5576c935

J'ai également ouvert un ticket au support OVH qui est resté sans réponse depuis 2 jours...
En espérant que quelqu'un trouve une solution et que l'on puisse faire concorder nos problèmes.
Utile (0)
B

Après confirmation de notre communauté, il semblerait que tous ceux qui sont chez Orange ont du mal à se connecter à nos serveurs OVH.
Utile (0)
L

Nous avons le même soucis, sur fivem ou garry's mod, les personnes chez Orange ont des soucis ...
Utile (0)
B

Déjà, c'est rassurant, ça fait 3 jours que je cherche le problème sur notre pare-feu pfSense, mais du coup, ça vient d'ailleurs...
Utile (0)
D

Une VPS ip FO aucune restriction sauf SSH
Un client 4G c'est down
activation de l'ipv6 il a une page apache.
Utile (0)
B

Tu as activé l'ipv6 sur une vm ou directement sur le host ?
Utile (0)
L

Moi c'était sur la vm uniquement
Utile (0)
B

D'accord. Donc juste en activant l'IPv6 vous avez diminué vos problèmes ?
Pas d'attribution d'adresse IPv6 sur la VM, juste l'activation du protocole a suffit ?
Utile (0)
D

@BillyD j'ai écrit VM Aafff

Pas sur la VM directement sur le VPS

Demain je vais voir avec mon boss qui à un tel orange
lors des test pour l'instant ça répond très bien a partir de free et d'un Orange box

a partir de curl ipv6 -v
Utile (0)
B

Ok oui, du coup il s'agit d'un VPS. Je ne sais pas trop où chercher pour attribuer de l'IPv6 publique sur un dédié qui plus est, avec des VM sur ESXi...
Utile (0)
D

J'ai suivi la doc https://docs.ovh.com/fr/vps/configurer-ipv6/ https://docs.ovh.com/fr/vps/configurer-ipv6/

après je suis pas encore sur à 100% que cela règle le problème avec la 4G Orange
Utile (0)
B

J'ai bien suivi la doc OVH mais rien d'explicite pour la partie ESX.
Par contre, je suis tombé sur ce topic :
https://community.ovhcloud.com/community/fr/determiner-gateway-ipv6?id=community_question&sys_id=f25eed88e51286d02d4c0165b3e766a8

Grâce à ça, j'ai réussi à configurer une IPv6 sur l'host ESX. C'est déjà bien. Maintenant que j'ai compris le principe, je vais essayer du côté de pfSense et des VM.
Utile (0)
D

Je ne connais pas ESX, je n'ai q'un petit VPS
Utile (0)
B

Ok 😄
À priori ce n'est pas un soucis IPv6. Chez Free, l'IPv6 est obligatoire et chez quelqu'un en full IPv6 il n'y a pas de soucis pour se connecter à nos serveurs.
Je désespère. Il faut croiser les doigts pour qu'OVH s'intéressent au problème dès demain... 🤞
Utile (0)
D

ça marche toujours pas depuis Orange 4G je me fais insulter par mes clients
Utile (0)
D

Ah bon il arrive pas a me contacter pourtant j'ai la double authentification pour mon compte
Donc mon numéro et bien valide !!!!!

je vais déjà faire ce qu'il demande .....

Bonjour M. M,

Je me permets de vous contacter concernant la problématique que vous rencontrez.

J'ai essayé à plusieurs reprises de vous contacter par appel mais le numéro que vous avez renseigné sur votre profil n'est pas attribué.

Pouvez-vous s'il vous plaît le mettre à jour?

Concernant votre service qui est inaccessible, pouvez-vous s'il vous plaît nous envoyer les résultats d'un MTR ou d'un TRACEROUTE dans les deux sens (en rescue si possible) depuis une connexion qui pose problème mais aussi depuis une connexion qui fonctionne.

Une fois ces informations reçues, je pourrai alors faire une remontée auprès des administrateurs qui pourront vérifier d'où provient le dysfonctionnement.

Lien du guide pour mettre votre vps en mode rescue:
https://docs.ovh.com/fr/vps/mode-rescue-vps/

Merci de votre compréhension.

Je reste à votre disposition pour toute demande complémentaire.
Utile (0)
D

Il on quand même réussi a me joindre, on avance

il faut que je trouve un tel Orange 4G pour faire les test
Utile (0)
CDU

Bonjour,
Ne comptez pas trop sur le support, j'ai un ticket ouvert depuis le 23 Septembre pour un problème similaire et la réponse reste la même :
> Après une nouvelle vérification, aucun défaut, ni dysfonctionnement ne sont constatés sur votre serveur.
> Nous vous invitions à effectuer une nouvelle vérification au niveau de votre configuration.

https://community.ovhcloud.com/community/fr/ip-failover-sur-vm-bridgee-qui-ne-fonctionne-pas?id=community_question&sys_id=0742f5c8f15e42d01e11e7bb9bf10333
Utile (0)
L

Je commence vraiment à me dire que j'ai investi dans un serveurs pour rien ... quel perte
Utile (0)
B

Ne m'en parle pas, on s'est engagé sur 12 mois...
De notre côté, toujours des soucis aussi.
Utile (0)
B

J'ai appelé le support par téléphone. Même constat, on doit passer sur le mode rescue pour faire un essai.
Je vais essayer de planifier ça demain matin mais c'est compliqué lorsque l'on a du monde derrière... Je vous tiens au courant ici.
Utile (0)
L

Pareil, engagement de 12 mois ...
Par contre je ne comprends strictement rien au rescue. Comment tester l ip en rescue ?
Utile (0)
B

J'ai utilisé le système rescue d'OVH il y a plusieurs années donc, je ne sais plus 🤣
Je fais ça demain matin et je te tiens au courant. Je vais essayer de faire des captures d'écran 😉
Utile (0)
CDU

Le mode rescue leur permet d'avoir un OS connu avec un paramétrage défini.
Par contre s'ils parlent de faire un test du type :
ip link add name testrescue link eth0 type macvlan
ip link set dev testrescue address xx:xx:xx:xx:xx:xx
ip link set testrescue up
ip addr add [IP addtionnelle] dev testrescue
Le mode bridge et le mode macvlan sont deux choses très différentes :
https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking/
Libre à chacun de se faire son opinion
Utile (0)
N

Bonjour,

Vous me confirmerez mais a priori ça ne devrait toucher que IPv4 puisque ça ne concerne que les IP FO ?

Le coup du Rescue Mode **POUR CE PROBLÈME PARTICULIER**, ça n'est pas significatif (voir plus bas). Je répète que dans mon cas le problème qui existait bel et bien sous PROXMOX n'apparaissait pas sous Rescue Mode !.. jusqu'à ce que je dispose de plus d'une IP FO et là le problème peut-être mis en évidence aussi sous Rescue Mode ! J'y serais encore si je n'avais pas décidé d'acheter deux autres adresses en me disant que c'était peut-être les adresses qui étaient problématiques (oui dans le désespoir on se tourne vers n'importe quel espoir...).

Une fois que j'avais mes adresses (4 pour ceux qui veulent tenter le coup), sous Rescue Mode, dès que 2 étaient activées c'était fini pour les 2 autres. Et fini de chez fini ! Démonter les 2 premières adresses ne permettait pas de remonter les 2 autres ! Ça passait forcément par un Reboot ! Bien sûr j'ai testé toutes les combinaisons possibles et c'était bien stables : les deux premières OK, les suivantes c'est mort.

Pour tester, il faut monter les adresses sous Rescue Mode en https://developers.redhat.com/blog/2018/10/22/introduction-to-linux-interfaces-for-virtual-networking/#macvlan macvlan. Dans un premier temps toutes d'une seule traite, si les 4 fonctionnent alors ça ne vient pas de ça. Sinon, si c'est bien ce problème une ou deux ne devrait pas fonctionner...

Mon analyse au doigt mouillé, c'est qu'il y a un mécanisme qui fait qu'on ne peut activer que n-2 adresses IP FO où n est le nombre d'IP FO dont on dispose... possiblement parce que si on prend une plage IP alors il y a l'adresse de diffusion et l'adresse de réseau(?). Et que malheureusement si on prend ces adresses à l'unité... n-2 < 0 pendant un moment...

Un moyen de cerner si ça a bien un rapport avec ça c'est de savoir si vous qui avez le problème vous avez ou non des plages d'IP FO ?

Autre point d'analyse, le problème ne se pose pas avec le Rescue Mode car la procédure préconisée fait qu'on monte les IP FO/MAC virtuelle directement sur l'interface en macvlan. Or sous PROXMOX, la IP FO/MAC virtuelle est configurée sur la machine virtuelle ou le conteneur. Je crois me souvenir qu'on peut forcer la détection de l'IP FO/MAC virtuelle sous proxmox en montant d'abord l'adresse en macvlan mais si je me souviens c'est galère car il y a aussi le bridge à mettre et on ne peut pas avoir les deux donc il y a beaucoup de manipulations...

J’espère que ça aidera à régler le problème...définitivement !
Utile (0)
N

LOL. je répondais justement à ça !

Pour compléter faites un `ip l` sur le host PROXMOX vous verrez que vos MAC virtuelle ne sont pas là. Elles sont dans les machines virtuelles / conteneurs.

Si vous faites la même manipulation qu'on vous demande de faire en Rescue Mode sous PROXMOX ça marche aussi ...enfin le ping... pour le reste ça n'est pas fonctionnel.
Utile (0)
B

Bonjour, à tous. Nous avons réalisé les essais demandés par OVH et le problème s'est bien représenté avec l'IP FO. Les informations ont été transmises au support.

@LyesB2 voici les informations qu'OVH m'a transmis et que j'ai adapté bien sûr à mon environnement. Pour information, l'@IP principale du serveur dédiée est déjà configurée (logique) sur le mode rescue. Vous n'avez qu'à configurer le reste des IP FO comme décrit ci-dessous :

root@rescue:~# ip link add name fo0 link eth0 type macvlan
root@rescue:~# ip link set dev fo0 address 00:50:xx:xx:xx:xx(correspond à la MAC de votre IP FO)
root@rescue:~# ip link set fo0 up
root@rescue:~# ip addr add 135.xxx.xxx.xxx(correspond à votre IP FO) dev fo0

Ensuite, pour faire un ping par exemple depuis cette adresse IP FailOver :

root@rescue:~# ping -c4 -I fo0 discord.com

Depuis votre IP principale :

root@rescue:~# ping -c4 -I eth0 discord.com

Pour un traceroute depuis votre IP FO :

root@rescue:~# traceroute -s 135.xxx.xxx.xxx(votre IP FO) discord.com

Bref, mes tests montrent que certaines IP ne répondent pas depuis les IP FO alors que je n'ai aucun soucis avec les mêmes essais de chez moi.
Utile (0)
L

Bonjour,
Merci beaucoup pour ce petit tutoriel.
Je ferais la manip quand ils seront décidé à répondre.

Cordialement.
Utile (0)
B

Bonjour, un petit coup de fil m'a aidé a accélérer les choses. Je n'ai encore pas eu de retour suite à tout ça mais au moins ils m'ont dit qu'ils transféraient mes informations au service concerné. C'est déjà ça.
En attendant, nous avons toujours les mêmes soucis...
Utile (0)
N

J'ajouterais : **Faire les tests _sérieusement_ et conserver les logs des manipulations (commandes et sorties), mettre tout ça dans le ticket ouvert, puis appel téléphonique**. Comme ça la personne qui te répondra pourra voir tout ça en direct et réagir sans tarder !

De mémoire ça a pris qq jours à être réglé, une fois l'appel téléphonique. N'attendez pas le retour, testez de temps en temps ; ça peut être réglé avant le retour sur ticket !

----------

Je ne sais pas dans quelle mesure c'est possible mais maintenant que ce problème est bien documenté il serait bien d'épingler ça ici quelque part. Ça éviterait aux impactés de perdre du temps à chercher des solutions et leur permettraient d'accélérer le support en mettant tout de suite un test significatif dans leur ticket. Au passage, ça ferait gagner du temps au support ...d'avoir de suite les tests, non ?
Utile (0)
B

Ouep, c'est exactement ce que j'ai fait 😆
Utile (0)
N

Salut,

Justement, le problème se posait-il avec une seule IP FO ? (i.e. pas de réponse en mode rescue)
Ou a t-il fallu que tu aies plusieurs adresses pour mettre le problème en évidence ?
Utile (0)
D

J'ai fait les tests demander depuis un abo ADSL Orange en mode normal le serveur ne répond pas il s’arrête là:
11 be102.1nc5.fr.eunc5.fr.eu (94.23.122.138) 86.681 ms 35.650 ms be102.1nc5.fr.eunc5.fr.eu (91.121.215.218) 36.297 ms
12 * * *
13 * * *

en mode rescue ça répond correctement. On dirait que c'est un souci aléatoire ...

la semaine dernière le traceroute avec la même ligne marcher bien
Utile (0)
D

Je précise que les test sont effectuer directement sur l'IP principale pas sur les ip FO
Utile (0)
B

Pour ma part, le problème se pose avec toutes les IP FO.
Utile (0)
L

Pareil pour moi, toutes les ips FO sont défectueuses depuis orange
Utile (0)
B

Je trouve ça hallucinant que personne de chez OVH ne réponde. Aucune activité sur mon ticket depuis 3 jours. Je viens d'envoyer un Tweet à Octave Klaba même si je n'attends pas de réponse de sa part. Comment peuvent-ils justifier cela ? Surtout que ça touche plusieurs personnes. Même si admettons que ça ne vienne pas d'OVH mais du réseau Orange, en tant que fournisseur, eux même devraient faire le nécessaire... Nous n'avons aucun moyen de recours pour une dégradation de service. Et en plus de tout ça, ils ont tous les éléments que nous avons transmis... Nous sommes vendredi, le problème va probablement durer au minimum jusqu'à lundi.
Utile (0)
L

J'ai appelé pour un tout autre problème sur un autre serveur, c'était pour une ip alias pas trop fonctionnel, réponse assez rapide, je vais lui dire de faire un détours sur notre problème commun
Utile (0)
CDU

Salut,
Quant à mettre les infos dans l'incident chez eux, j'en ai mis tellement que chacun des tech que j'ai eu en ligne sur la bonne douzaine d'appels que j'ai passé à demandé quelques heures pour reprendre tous les éléments et faire le point sur le problème ...
Nième réponse Lundi du support qui reste cramponné sur ses positions quand à un problème de conf.
Pour ceux que ca intéresse, j'ai mis pas mal d'éléments descriptifs sur mon problème ici :
https://community.ovhcloud.com/community/fr/ip-failover-sur-vm-bridgee-qui-ne-fonctionne-pas?id=community_question&sys_id=0742f5c8f15e42d01e11e7bb9bf10333
Car là pour eux ils parlent de fermer mon incident car il est "résolu" selon leur point de vue (car le problème serait dans ma conf).
Le support m'invitant à me tourner vers la communauté, chaque avis sera très précieux pour faire avancer les choses et savoir si selon vous j'ai loupé quelque chose dans ma conf ou non.
D'avance merci
Cordialement
Utile (0)
L

J'ai du nouveau, après 4 échanges téléphonique avec des Américains.
L'un d'eux a été contraint d'appeler un spécialiste en France car on ne voulait pas lacher l'affaire, visiblement le problème est récurrent, ils sont au courant.

Ils m'ont demandé de faire des test, MBR (mytraceroute) de ma box orange vers la vm et vice versa.
En attente de leur retour
Utile (0)
D

Voilà le résultat du traceroute directement sur le VPS en mode normal déjà a la base ça ne marche pas. donc je pense pas que c'est vos conf's. Ou alors faudra me dire comment faire plus simple


#conf d'origine interface
`# The loopback network interface`
auto lo
iface lo inet loopback

`# The normal eth0`
allow-hotplug eth0
iface eth0 inet dhcp

`# Additional interfaces, just in case we're using`
`# multiple networks`
allow-hotplug eth1
iface eth1 inet dhcp

allow-hotplug eth2
iface eth2 inet dhcp


#traceroute depuis FREE OK
traceroute to vpsYYYYYY.ovh.net (YY.YY.YY.YYY), 64 hops max
1 192.168.1.1 (_gateway) 0,542ms 0,395ms 0,428ms
2 194.149.169.61 (194.149.169.61) 14,117ms 14,040ms 14,323ms
3 194.149.166.62 (194.149.166.62) 14,727ms 14,117ms 14,015ms
4 54.36.50.110 (1a9.fr.eua9.fr.eu) 87,134ms 14,985ms 14,671ms
5 * * *
6 * * *
7 * * *
8 94.23.122.138 (be102.1nc5.fr.eunc5.fr.eu) 20,331ms 21,339ms 21,154ms
9 * * *
10 * * *
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 YY.YY.YY.YYY (YYY.ip-YY-YY-YY.eu) 20,277ms 19,593ms 19,917ms
root@debian:/




# traceroute depuis Orange KO
traceroute to vpsYYYYYY.ovh.net (YY.YY.YY.YYY), 30 hops max, 60 byte packets
1 _gateway (192.168.1.254) 2.723 ms 2.784 ms 2.846 ms
2 80.10.126.137 (80.10.126.137) 21.645 ms 21.698 ms 21.702 ms
3 * * *
4 10.nrstr202.Strasbourg.francetelecom.net0.nrstr202.Strasbourg.francetelecom.net (193.252.160.154) 27.869 ms 27.867 ms 10.nrstr201.Schiltigheim.francetelecom.net0.nrstr201.Schiltigheim.francetelecom.net (193.252.160.150) 27.807 ms
5 10.nridf302.Paris13eArrondissement.francetelecom.net0.nridf302.Paris13eArrondissement.francetelecom.net (193.251.126.22) 37.620 ms 10.nridf301.Paris15eArrondissement.francetelecom.net0.nridf301.Paris15eArrondissement.francetelecom.net (193.251.126.18) 35.784 ms 10.nridf302.Paris13eArrondissement.francetelecom.net0.nridf302.Paris13eArrondissement.francetelecom.net (193.251.126.22) 40.130 ms
6 10.noidf002.Aubervilliers.francetelecom.net0.noidf002.Aubervilliers.francetelecom.net (193.252.99.106) 40.120 ms 10.noidf001.Paris3eArrondissement.francetelecom.net0.noidf001.Paris3eArrondissement.francetelecom.net (193.252.99.102) 67.758 ms 37.704 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 be102.1nc5.fr.eunc5.fr.eu (94.23.122.138) 34.059 ms 33.988 ms 33.849 ms
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
root@debian:/
Utile (0)
L

Nous avons presque les mêmes résultats, c'est fou.
https://prnt.sc/w0s1nd
Utile (0)
N


Bref, mes tests montrent que certaines IP ne répondent pas depuis les IP FO alors que je n'ai aucun soucis avec les mêmes essais de chez moi.



Pour ma part, le problème se pose avec toutes les IP FO.


Ça me semble contradictoire.

Peux-tu nous dire combien tu as d'IP FO ?
Combien fonctionnent simultanément ?
As-tu essayé de les tester une par une ?
Sont-elles issues de blocs indépendants ou sont-elles issues d'un même bloc ? (si y'a un mix, peux-tu détailler, avec des a.b.c.d ça ira).

Si certains ont le même problème avec des blocs d'IP, ça m'intéresserait de le savoir. J'ai l'impression que là le problème ne se pose pas (on élimine tout de suite les IP BRD et NET qui ne fonctionnent pas)
Utile (0)
L

Pour moi toutes les ips a problème commencent pas 135.125.x.x
Utile (0)
B

Non, ce n'est pas contradictoire... Les IP de destination répondent de mon domicile mais pas depuis les IP FO de mon serveur dédié (ping KO depuis OVH, ping OK depuis chez moi).
8 IP FO du même bloc. Les tests ont été effectués depuis chaque IP FO indépendamment.
Utile (0)
B

Idem...
Utile (0)

Je ne suis pas concerné par ce problème mais vous suis avec intérêt.
Le délai de réaction OVH commence quand même à devenir inquiétant si c'est bel et bien un problème réseaux.
Et j'ai envie de dire, même si c'est un problème de config ce serai bien qu'un sysadmin OVH se penche sur le sujet et puisse donner une solution.
Utile (0)
L

2 semaines que le ticket est ouvert. Hier ils ont dit avoir transmis le problème au spécialiste, mais pas de nouvelle aujourd'hui, une perte de temps et d'argent .
Utile (0)
N


Les IP de destination répondent de mon domicile mais pas depuis les IP FO de mon serveur dédié (ping KO depuis OVH, ping OK depuis chez moi).


Aaah ok ! Je comprends mieux maintenant. Pour moi c'était forcément les IP FO les ip destinataires 🙃


8 IP FO du même bloc. Les tests ont été effectués depuis chaque IP FO indépendamment.


Dans ce cas là, il semble quand même que l'IP du réseaux et son broadcast ne sont pas attribuables de toute façon (j'avoue que je ne vois pas pourquoi ça devrait être comme ça mais bon...). D'ailleurs si tu arrives à leur attribuer une MAC Virtuelle...


Les tests ont été effectués depuis chaque IP FO indépendamment.


Et aucune ne fonctionne seule ? Ça c'est chaud.
Utile (0)
N


2 semaines que le ticket est ouvert. Hier ils ont dit avoir transmis le problème au spécialiste, mais pas de nouvelle aujourd'hui, une perte de temps et d'argent .



D'autant plus que le problème est connu et se règle rapidement apparemment !
En tout cas une fois que le correspondant au téléphone m'a dit transmettre à son collègue, ça n'a pas pris trop de temps. Pas une semaine en tout cas.

À fond le cloud, on dirait...
Utile (0)
B

Je pense qu'on s'était mal compris 😂
L'adresse de broadcast et de réseau sont bien utilisables dans le cas d'une utilisation en IP FO (en tous cas sur du dédié).
En effet, toutes les IP FO que j'ai sur le range 135.125.x.x ne passent pas.

Ca m'embête grandement, car ça leur donne raison une fois de plus, mais j'ai commandé un deuxième range d'IP FO /29. Comme par hasard, avec ces IP, aucun soucis... Mais cette affaire me coûte encore près de 20 € supplémentaires. Quand ils auront réglé les soucis sur les autres, je les rendrais. En attendant, ça me débloque. Pour info, cet autre range est sur du 37.59.x.x. Donc le problème semble bien provenir de certains ranges IP.

Tu as des infos sur le "problème connu qui se règle" ? C'est par rapport à l'autre post en ajoutant la MAC manuellement ?
Utile (0)
D

@BillyD
C'est toujours KO d'une box Orange alors que d'un box Free c'est ok
Range du VPS 51.91.X.X KO
IP FO
Range 5.196.x.x KO
Range 87.98.x.x KO
Range 92.222.x.x KO
Utile (0)
B

Coup de bol pour moi alors 😐
Utile (0)
D

ya 2 semaines c’était pas le cas
Utile (0)
B

Après avoir pousser sur Twitter, voici leur réponse :



On tourne en rond... Ils cherchent de notre côté alors que le problème vient d'eux... Tous les éléments que j'ai déjà transmis permettent de le prouver. Encore plus avec les essais depuis un autre bloc IP FO qui lui n'a aucun soucis comme je disais plus haut.
Utile (0)
N

Bonjour,


L'adresse de broadcast et de réseau sont bien utilisables dans le cas d'une utilisation en IP FO (en tous cas sur du dédié).


Ah ! ça me rassures. J'avais lu ça quelque part ici, et je ne comprenais pas pourquoi.
Tu confirmes donc que sur un /29 tu peux héberger 8 conteneurs/VM chacun avec son IP/MAC virtuelle ?


Tu as des infos sur le "problème connu qui se règle" ? C'est par rapport à l'autre post en ajoutant la MAC manuellement ?


Je précise que mon problème concernait des IP FO /32. Mes IP FO sont toutes de blocs différents et ce n'étaient pas les IP ou les MAC qui dysfonctionnaient car quand j'en avais 2 seule la 1ère activée fonctionnait, les 2 premières quand j'en ai eu 3 puis toujours les 2 premières quand j'en ai eu 4.
Ensuite le problème a été réglé sans rien changer à la configuration du serveur (même IP même MAC).

Une fois que j'ai pu mettre en évidence le problème sous rescue mode, ET téléphoné ça a été pris en compte et réglé assez rapidement. De mémoire (le ticket a disparu...) ils m'ont expliqué qu'il s'agissait d'un problème de configuration dans leur infrastructure (sur un switch il me semble).
Utile (0)
L

Bonsoir,
Je reviens après cette longue absence, le problème est toujours en cours concernant Orange en mode bridge sur une VM.
MAIS ! J'ai une autre machine ou j'avais besoin d'une ip failover en "alias" et non en bridge, je configure l'ip, déjà sa ne fonctionne pas, ovh passe 3 jours sur notre serveur et trouve le problème aujourd'hui, ils nous disent, "vous pouvez maintenant repasser en boot sur le disque et configurer l'ip failover", ce que je fais.
Sauf que l'ip que j'ai pris fait parti du même bloc "135.125.X.X", je me suis dit "aller c'est un autre serveur dédié, le problème avec orange ne sera pas présent" et bah bingo, sur 2 dédié les ips ont le même problème, grosse perturbation avec Orange.
Utile (0)
L

J'ai pris une ip en belgique, 164.132.X.X , sa fonctionne, voila la solution
Utile (0)
B

Salut, oui j'ai fait la même chose. J'ai pris un bloc en Allemagne ça a réglé le soucis mais j'attends toujours qu'OVH me répondent et règle le soucis pour tout le monde...
J'ai gardé le range défectueux pour le moment (si jamais on doit encore leur prouver que le défaut vient d'eux...).
C'est de plus en plus abusé. Ils n'ont toujours pas résolu le problème de manière globale. Ticket ouvert le 4 décembre tout de même. Certains ont le même problème avec des tickets ouverts depuis encore plus longtemps à priori...
Utile (0)
B


Tu confirmes donc que sur un /29 tu peux héberger 8 conteneurs/VM chacun avec son IP/MAC virtuelle ?


En tous cas sur du dédié oui.


Une fois que j'ai pu mettre en évidence le problème sous rescue mode, ET téléphoné ça a été pris en compte et réglé assez rapidement. De mémoire (le ticket a disparu...) ils m'ont expliqué qu'il s'agissait d'un problème de configuration dans leur infrastructure (sur un switch il me semble).


Tu as eu de la chance...
Utile (0)
D

```text Hello,

Il commence a me gaver.. le support a voulu fermer mon ticket sous prétexte que je ne peux pas faire les tests avec un tel 4G Orange.

Es q'une bonne âme pourrai me rendre service ??? et poster le résultat dans le cas d'un KO ou l'envoyer en message privé :

mtr -o 'J M X LSR NA B W V' -wzbc 50 vps792393.ovh.net
mtr -r google.com
traceroute vps792393.ovh.net

Merci ```
Utile (0)
B

Bonjour, malheureusement pour ma part je n'ai pas accès à une ligne Orange. Je vais demander à ma communauté mais ça risque d'être compliqué ^^
Utile (0)
P

Bonjour,

Voici le résultat depuis une ligne ORANGE (fibre business) :

> # mtr -o 'J M X LSR NA B W V' -wzbc 50 vps792393.ovh.net
> Start: 2020-12-16T12:37:08+0100
> Jttr Javg Jmax Loss% Snt Rcv Last Avg Best Wrst StDev
> 1. AS??? 172.16.51.2 0.1 0.1 0.3 0.0% 50 50 0.4 0.4 0.2 0.6 0.1
> 2. AS??? 192.168.0.253 0.7 0.2 0.7 0.0% 50 50 0.7 0.9 0.5 1.4 0.2
> 3. AS??? 81.55.122.65 0.0 1.4 15.0 0.0% 50 50 3.7 4.2 3.3 18.3 2.3
> 4. AS??? lag-43.1ig5.poitiers.transitip.raei.francetelecom.netig5.poitiers.transitip.raei.francetelecom.net (81.52.79.246) 0.2 1.0 8.0 0.0% 50 50 6.8 7.4 6.6 14.8 1.6
> 5. AS??? lag-43.1ig5.poitiers.transitip.raei.francetelecom.netig5.poitiers.transitip.raei.francetelecom.net (81.52.79.246) 0.3 0.6 8.6 0.0% 50 50 6.7 6.7 6.3 15.1 1.2
> 6. AS??? 193.252.137.213 0.0 0.2 2.1 0.0% 50 50 6.5 6.6 6.2 8.6 0.3
> 7. AS??? 193.249.215.214 0.1 0.7 10.0 0.0% 50 50 6.8 7.1 6.5 16.8 1.5
> 8. AS??? 10.nrpoi101.Poitiers.francetelecom.net0.nrpoi101.Poitiers.francetelecom.net (193.252.100.42) 1.1 2.4 21.8 0.0% 50 50 7.7 7.9 6.6 28.4 4.1
> 9. AS??? 10.nridf101.Paris3eArrondissement.francetelecom.net0.nridf101.Paris3eArrondissement.francetelecom.net (193.251.126.10) 6.3 3.0 11.8 0.0% 50 50 19.6 13.0 10.4 22.5 3.3
> 10. AS??? 10.noidf001.Paris3eArrondissement.francetelecom.net0.noidf001.Paris3eArrondissement.francetelecom.net (193.252.98.102) 0.3 1.6 12.5 0.0% 50 50 10.5 11.7 10.5 23.2 2.2
> 11. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
> 12. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
> 13. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
> 14. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
> 15. AS16276 be102.1nc5.fr.eunc5.fr.eu (91.121.215.218) 0.6 8.0 124. 0.0% 50 50 20.9 25.5 18.7 144.1 22.5
> 16. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
> 17. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
> 18. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
> 19. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
> 20. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
> 21. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
> 22. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
> 23. AS16276 139.ip-51-91-79.eu (51.91.79.139) 0.1 0.7 5.3 0.0% 50 50 18.2 18.6 18.1 23.4 1.0


> # mtr -r google.com
> Start: 2020-12-16T12:37:30+0100
> Loss% Snt Last Avg Best Wrst StDev
> 1.|-- 172.16.51.2 0.0% 10 0.4 0.4 0.3 0.6 0.1
> 2.|-- 192.168.0.253 0.0% 10 0.5 0.9 0.5 1.1 0.2
> 3.|-- 81.55.122.65 0.0% 10 3.8 3.6 3.5 3.8 0.1
> 4.|-- lag-44.poi2-ig5.poitiers. 0.0% 10 7.1 7.1 6.7 8.0 0.4
> 5.|-- lag-44.poi2-ig5.poitiers. 0.0% 10 6.5 6.6 6.5 6.9 0.1
> 6.|-- 193.252.137.217 0.0% 10 6.4 6.6 6.4 7.1 0.2
> 7.|-- 193.249.215.218 0.0% 10 6.7 7.5 6.6 10.9 1.6
> 8.|-- 81.253.130.6 0.0% 10 6.6 6.8 6.6 7.2 0.2
> 9.|-- 193.252.137.14 10.0% 10 13.8 14.1 13.8 14.4 0.2
> 10.|-- google-46.gw.opentransit. 0.0% 10 12.2 12.5 12.2 13.1 0.3
> 11.|-- 216.239.41.97 0.0% 10 12.3 12.4 12.1 12.5 0.1
> 12.|-- 108.170.232.125 0.0% 10 13.8 14.2 13.8 16.1 0.7
> 13.|-- par10s27-in-f206.1e100.ne 0.0% 10 12.2 12.4 12.2 12.7 0.2


> # traceroute vps792393.ovh.net
> traceroute to vps792393.ovh.net (51.91.79.139), 30 hops max, 60 byte packets
> 1 172.16.51.2 (172.16.51.2) 0.232 ms 0.227 ms 0.217 ms
> 2 192.168.0.253 (192.168.0.253) 1.191 ms 1.171 ms 1.149 ms
> 3 81.55.122.65 (81.55.122.65) 3.992 ms 3.957 ms 3.876 ms
> 4 lag-43.1ig5.poitiers.transitip.raei.francetelecom.netig5.poitiers.transitip.raei.francetelecom.net (81.52.79.246) 6.934 ms 7.084 ms lag-44.1ig5.poitiers.transitip.raei.francetelecom.netig5.poitiers.transitip.raei.francetelecom.net (81.52.84.2) 7.222 ms
> 5 lag-43.1ig5.poitiers.transitip.raei.francetelecom.netig5.poitiers.transitip.raei.francetelecom.net (81.52.79.246) 6.715 ms lag-44.1ig5.poitiers.transitip.raei.francetelecom.netig5.poitiers.transitip.raei.francetelecom.net (81.52.84.2) 7.147 ms lag-43.1ig5.poitiers.transitip.raei.francetelecom.netig5.poitiers.transitip.raei.francetelecom.net (81.52.79.246) 6.962 ms
> 6 193.252.137.217 (193.252.137.217) 7.546 ms 6.699 ms 6.683 ms
> 7 193.249.215.218 (193.249.215.218) 7.095 ms 193.249.215.214 (193.249.215.214) 7.023 ms 16.632 ms
> 8 10.nrpoi102.Poitiers.francetelecom.net0.nrpoi102.Poitiers.francetelecom.net (193.252.100.46) 6.966 ms 7.009 ms 6.986 ms
> 9 10.nridf101.Paris3eArrondissement.francetelecom.net0.nridf101.Paris3eArrondissement.francetelecom.net (193.251.126.10) 10.828 ms 10.nridf102.Aubervilliers.francetelecom.net0.nridf102.Aubervilliers.francetelecom.net (193.251.126.14) 14.340 ms 13.828 ms
> 10 10.noidf002.Aubervilliers.francetelecom.net0.noidf002.Aubervilliers.francetelecom.net (193.252.98.106) 13.753 ms 13.712 ms 13.676 ms
> 11 * * *
> 12 * * *
> 13 * * *
> 14 * * *
> 15 be102.1nc5.fr.eunc5.fr.eu (94.23.122.138) 20.432 ms 24.418 ms be102.1nc5.fr.eunc5.fr.eu (91.121.215.218) 102.099 ms
> 16 * * *
> 17 * * *
> 18 * * *
> 19 * * *
> 20 * * *
> 21 * * *
> 22 * * *
> 23 139.ip-51-91-79.eu (51.91.79.139) 19.475 ms 19.468 ms 19.419 ms
Utile (0)
D

Merci @Puma pour ton retour... du coup chez toi il répond correctement.
Utile (0)
P

Peut-être à noter une différence entre orange grand Public et Business ? je sais que leur infra des pros et des particuliers est séparé.
Utile (0)
B

Possible la différence oui. Pour ma part, le problème n'était pas présent pour tous les clients Orange. La plupart oui, mais pas tous.
Utile (0)
D

Hello un copain Patrick ma partager la connexion Orange de 4G voilà le résultat

david@david-macminilinux:~/Téléchargements$ mtr -o 'J M X LSR NA B W V' -wzbc 50 vps792393.ovh.net
Start: 2020-12-16T20:00:17+0100
HOST: david-macminilinux Jttr Javg Jmax Loss% Snt Rcv Last Avg Best Wrst StDev
1. AS??? _gateway (192.168.43.1) 0.6 5.0 49.1 26.0% 50 37 3.6 5.3 2.0 51.8 8.9
2. AS??? 10.216.3.64 2.4 23.7 96.6 26.0% 50 37 31.4 42.8 23.1 125.1 25.4
3. AS??? 10.216.2.49 6.2 27.5 113. 26.0% 50 37 48.2 45.1 15.3 130.5 27.4
4. AS??? 10.216.2.54 9.8 20.5 99.9 26.0% 50 37 27.1 39.6 17.3 129.2 23.7
5. AS??? 10.216.2.62 89.3 15.5 89.3 26.0% 50 37 120.8 35.3 16.8 120.8 21.2
6. AS??? 10.216.2.65 68.8 34.6 114. 26.0% 50 37 94.9 43.6 18.0 142.3 33.1
7. AS??? 81.253.184.201 26.2 26.1 114. 26.0% 50 37 55.9 39.5 16.7 131.6 27.7
8. AS??? 193.252.162.6 13.7 19.3 63.2 26.0% 50 37 32.7 36.1 16.8 93.2 18.6
9. AS??? 10.nrstr201.Schiltigheim.francetelecom.net0.nrstr201.Schiltigheim.francetelecom.net (193.252.160.150) 1.3 10.9 37.1 28.0% 50 36 33.8 31.1 18.2 63.9 10.9
10. AS??? 10.nridf301.Paris15eArrondissement.francetelecom.net0.nridf301.Paris15eArrondissement.francetelecom.net (193.251.126.18) 1.2 15.4 104. 28.0% 50 36 35.5 38.8 22.0 134.6 19.5
11. AS??? 10.noidf001.Paris3eArrondissement.francetelecom.net0.noidf001.Paris3eArrondissement.francetelecom.net (193.252.99.102) 4.9 21.8 155. 28.0% 50 36 28.7 45.0 25.3 180.8 33.6
12. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
13. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
14. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
15. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
16. AS16276 be102.1nc5.fr.eunc5.fr.eu (94.23.122.138) 130. 25.3 130. 26.0% 50 37 170.7 75.0 34.8 172.3 44.0
AS16276 be102.1nc5.fr.eunc5.fr.eu (91.121.215.218)
17. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
david@david-macminilinux:~/Téléchargements$ mtr -r google.com
Start: 2020-12-16T20:01:33+0100
HOST: david-macminilinux Loss% Snt Last Avg Best Wrst StDev
1.|-- _gateway 0.0% 10 2.7 4.9 2.7 17.2 4.4
2.|-- 10.216.3.64 0.0% 10 28.3 42.6 26.8 123.9 29.0
3.|-- 10.216.2.49 0.0% 10 29.4 35.8 20.5 83.6 17.7
4.|-- 10.216.2.54 0.0% 10 28.3 42.2 26.1 121.5 28.1
5.|-- 10.216.2.62 0.0% 10 35.0 39.7 25.9 114.6 26.5
6.|-- 10.216.2.65 0.0% 10 30.4 40.5 20.0 78.7 18.7
7.|-- 81.253.184.205 0.0% 10 37.3 43.6 22.6 126.2 29.7
8.|-- 193.252.162.10 0.0% 10 32.9 57.1 18.9 145.1 40.8
9.|-- ae43-0.nistr202.Strasbour 0.0% 10 29.4 42.6 29.4 98.2 21.2
10.|-- 81.253.180.117 0.0% 10 30.1 43.7 28.7 110.9 24.9
11.|-- 193.252.137.82 0.0% 10 42.1 45.9 22.2 105.9 23.3
12.|-- 72.14.214.52 0.0% 10 22.9 50.6 22.9 159.7 40.2
13.|-- 216.239.62.45 0.0% 10 35.9 49.1 27.2 111.0 30.0
14.|-- 108.170.251.208 0.0% 10 33.3 42.8 26.2 101.8 21.4
15.|-- 209.85.241.231 60.0% 10 33.2 40.4 32.8 56.7 11.2
16.|-- 209.85.252.149 20.0% 10 38.6 49.7 34.0 103.3 22.7
17.|-- 72.14.238.52 0.0% 10 36.3 51.2 29.6 97.0 19.0
18.|-- 108.170.244.161 0.0% 10 38.5 40.5 30.4 51.1 6.9
19.|-- 216.239.48.27 0.0% 10 52.1 41.4 29.9 52.1 7.0
20.|-- 1f14.1e100.netf14.1e100.net 0.0% 10 38.6 40.1 33.0 51.6 6.7
david@david-macminilinux:~/Téléchargements$ traceroute vps792393.ovh.net
traceroute to vps792393.ovh.net (51.91.79.13david@david-macminilinux:~/Téléchargements$ mtr -o 'J M X LSR NA B W V' -wzbc 50 vps792393.ovh.net
Start: 2020-12-16T20:00:17+0100
HOST: david-macminilinux Jttr Javg Jmax Loss% Snt Rcv Last Avg Best Wrst StDev
1. AS??? _gateway (192.168.43.1) 0.6 5.0 49.1 26.0% 50 37 3.6 5.3 2.0 51.8 8.9
2. AS??? 10.216.3.64 2.4 23.7 96.6 26.0% 50 37 31.4 42.8 23.1 125.1 25.4
3. AS??? 10.216.2.49 6.2 27.5 113. 26.0% 50 37 48.2 45.1 15.3 130.5 27.4
4. AS??? 10.216.2.54 9.8 20.5 99.9 26.0% 50 37 27.1 39.6 17.3 129.2 23.7
5. AS??? 10.216.2.62 89.3 15.5 89.3 26.0% 50 37 120.8 35.3 16.8 120.8 21.2
6. AS??? 10.216.2.65 68.8 34.6 114. 26.0% 50 37 94.9 43.6 18.0 142.3 33.1
7. AS??? 81.253.184.201 26.2 26.1 114. 26.0% 50 37 55.9 39.5 16.7 131.6 27.7
8. AS??? 193.252.162.6 13.7 19.3 63.2 26.0% 50 37 32.7 36.1 16.8 93.2 18.6
9. AS??? 10.nrstr201.Schiltigheim.francetelecom.net0.nrstr201.Schiltigheim.francetelecom.net (193.252.160.150) 1.3 10.9 37.1 28.0% 50 36 33.8 31.1 18.2 63.9 10.9
10. AS??? 10.nridf301.Paris15eArrondissement.francetelecom.net0.nridf301.Paris15eArrondissement.francetelecom.net (193.251.126.18) 1.2 15.4 104. 28.0% 50 36 35.5 38.8 22.0 134.6 19.5
11. AS??? 10.noidf001.Paris3eArrondissement.francetelecom.net0.noidf001.Paris3eArrondissement.francetelecom.net (193.252.99.102) 4.9 21.8 155. 28.0% 50 36 28.7 45.0 25.3 180.8 33.6
12. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
13. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
14. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
15. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
16. AS16276 be102.1nc5.fr.eunc5.fr.eu (94.23.122.138) 130. 25.3 130. 26.0% 50 37 170.7 75.0 34.8 172.3 44.0
AS16276 be102.1nc5.fr.eunc5.fr.eu (91.121.215.218)
17. AS??? ??? 0.0 0.0 0.0 100.0 50 0 0.0 0.0 0.0 0.0 0.0
david@david-macminilinux:~/Téléchargements$ mtr -r google.com
Start: 2020-12-16T20:01:33+0100
HOST: david-macminilinux Loss% Snt Last Avg Best Wrst StDev
1.|-- _gateway 0.0% 10 2.7 4.9 2.7 17.2 4.4
2.|-- 10.216.3.64 0.0% 10 28.3 42.6 26.8 123.9 29.0
3.|-- 10.216.2.49 0.0% 10 29.4 35.8 20.5 83.6 17.7
4.|-- 10.216.2.54 0.0% 10 28.3 42.2 26.1 121.5 28.1
5.|-- 10.216.2.62 0.0% 10 35.0 39.7 25.9 114.6 26.5
6.|-- 10.216.2.65 0.0% 10 30.4 40.5 20.0 78.7 18.7
7.|-- 81.253.184.205 0.0% 10 37.3 43.6 22.6 126.2 29.7
8.|-- 193.252.162.10 0.0% 10 32.9 57.1 18.9 145.1 40.8
9.|-- ae43-0.nistr202.Strasbour 0.0% 10 29.4 42.6 29.4 98.2 21.2
10.|-- 81.253.180.117 0.0% 10 30.1 43.7 28.7 110.9 24.9
11.|-- 193.252.137.82 0.0% 10 42.1 45.9 22.2 105.9 23.3
12.|-- 72.14.214.52 0.0% 10 22.9 50.6 22.9 159.7 40.2
13.|-- 216.239.62.45 0.0% 10 35.9 49.1 27.2 111.0 30.0
14.|-- 108.170.251.208 0.0% 10 33.3 42.8 26.2 101.8 21.4
15.|-- 209.85.241.231 60.0% 10 33.2 40.4 32.8 56.7 11.2
16.|-- 209.85.252.149 20.0% 10 38.6 49.7 34.0 103.3 22.7
17.|-- 72.14.238.52 0.0% 10 36.3 51.2 29.6 97.0 19.0
18.|-- 108.170.244.161 0.0% 10 38.5 40.5 30.4 51.1 6.9
19.|-- 216.239.48.27 0.0% 10 52.1 41.4 29.9 52.1 7.0
20.|-- 1f14.1e100.netf14.1e100.net 0.0% 10 38.6 40.1 33.0 51.6 6.7
david@david-macminilinux:~/Téléchargements$ traceroute vps792393.ovh.net
traceroute to vps792393.ovh.net (51.91.79.139), 64 hops max
1 192.168.43.1 2,829ms 2,768ms 2,191ms
2 10.216.3.64 30,895ms 35,054ms 24,965ms
3 10.216.2.62 23,748ms 33,845ms 25,074ms
4 10.216.2.65 21,527ms 33,854ms 24,856ms
5 81.253.184.205 19,841ms 35,004ms 26,196ms
6 193.252.162.10 20,481ms 32,827ms 25,873ms
7 193.252.160.154 28,071ms 26,141ms 23,616ms
8 193.251.126.22 44,340ms 37,115ms 132,406ms
9 193.252.99.106 45,918ms 44,151ms 34,522ms
10 * * *
11 * * *
12 * * *
13 * * *
14 94.23.122.138 71,989ms 40,839ms 41,279ms
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *
31 * * *
32 * * *
33 * * *
34 * * *
35 * * *
36 * * *
37 * * *
38 * * *
39 * * *
40 * * *
41 * * *
42 * * *
43 * * *
44 * * *
45 * * *
46 * * *
Utile (0)
D

Reste plus qu'a attendre la réponse du support
Utile (0)
J

Bonjour,

pour info : http://travaux.ovh.com/?do=details&id=48193

Cordialement, janus57
Utile (0)
B


Reste plus qu'a attendre la réponse du support



Bonjour,

pour info : http://travaux.ovh.com/?do=details&id=48193

Cordialement, janus57


Bonjour, j'ai reçu une réponse du support. Je n'ai pas encore effectué les tests mais ils m'ont répondu que le problème devrait être réglé.
Si vous pouvez faire les tests aussi de votre côté 😉
Je vais vérifier ce soir.
Utile (0)
B

Bonjour, je vous apporte des nouvelles des tests demandés par OVH.
Rien n'y fait. Les soit disant actions qu'ils auraient menées n'ont rien changé au problème.
Le soucis est toujours présent depuis l'autre range d'IP défectueuses.
Utile (0)
L

http://travaux.ovh.net/?do=details&id=48193

Hop, sa fonctionne
Utile (0)
B

Pour moi le problème est toujours présent pour des réseaux protégés par Cloudflare.

Par exemple, un test avec Discord.com :
https://pastebin.com/UKxJ9M6X

Sachant que les mêmes IP fonctionnent très bien depuis une autre adresse FO dans un autre range et que ça ping correctement depuis chez moi. Et j'ajoute également que toutes les adresses du même range posent problème.
Utile (0)
B

Bon, ça m'a fatigué... Je vais fermer le ticket.
Ils me demandent encore de repasser en rescue pour analyser le problème par leurs techs. J'ai renvoyé une nouvelle fois des tests que j'ai fait dans tous les sens mais ça ne semble jamais leur suffire. Sachant qu'ils mettent 2 à 3 jours à répondre entre chaque message, ça ne sert à rien que je continue. Notre autre range IP fonctionne, j'ai résilié celui qui ne fonctionne pas. Courage à vous et à ceux qui aurons des problèmes similaires...
A+
Utile (0)

Sujets apparentés

Rejoindre la discussion