Bonjour,
n'ayant pas encore de réponse concrète du service client j’essaie de trouver une solution ici. Merci d'avance à tous ceux qui essayerons de m'aider!
Voici la description de mon cas:
if1 (orange/huawei) est reconnu normalement par l’OTB l’adresse IP de sortie est bien celle d’OVH
if2 (telma/Dlink dwr-921) reste toujours OFFLINE, mais après plusieurs tests, on constate que l’agrégation fonctionne.
Si le lien Telma tombe, le failover fonctionne en restant connecté sur IF1. Et quand il revient, l’agrégation refonctionne.
Mais si le lien orange tombe, TOUT TOMBE. Et au redémarrage du lien orange, l’AGREGATION NE FONCTIONNE PLUS !
Seul un reboot manuel par l’interface de l’OTB lance tout comme au début.
Cela ne vient pas du routeur Dlink, car sans réponse de chez OVH, j'ai testé sur un autre routeur et une clé Huawei.
Je suis à l’écoute de toutes vos proposition et une fois de plus merci d'avance.
Richard
Pourquoi écrire aussi GROS ?
As-tu peur que nous soyons myopes ? ? ? 
Ce n'était pas voulu, c'est simplement en voulant ajouter la barre horizontale(icône à côté du smiley) pour séparer chaque point que ça a fait cette police.
As-tu fait beaucoup de "tentatives" avant d'obtenir ta configuration actuelle ?
Par expérience, supprimer une connexion depuis l'interface OTB, ne supprime pas proprement cette connexion, certains résidus peuvent polluer ta configuration actuelle.
Si c'est possible, je t'invite à faire une réinitialisation d'usine de ton OTB (méthode USB : https://www.ovh.com/fr/g2243.retablir_la_configuration_dusine) et à reconfigurer tes connexions en prenant soin de ne pas faire d'erreurs.
J'en profite pour signaler à OVH que lorsqu'on supprime une interface de l'aggrégation (if1…if4), les paramétrages liés à l'interface supprimée ne sont pas supprimés dans la configuration du MWAN. On peut le faire à la main depuis l'IHM, mais c'est fastidieux et source d'erreurs.
Bonjour julien,
j'ai réinitialisé plusieurs fois l'otb pour chaque fois repartir sur des bases propres. Peut-être 4 fois, avec la méthode à partir de l'interface OTB en chargeant une image préalablement télécharger avec le lien OVH. J'imagine que c'est la même chose, mais faites d'une manière différente?
Aujourd'hui j'ai encore retenté mais toujours le même résultat; Seule constatation supplémentaire, après avoir simulé qu'if1 soit tombé. L'agrégation ne fonctionne plus mais en cliquant sur connecter depuis l'interface OVH, l'agrégation se relance mais toujours sans que la connexion passe en On-line et sans le failover.
Par contre, avez vous eu de bonnes expériences avec le service client d'OVH?
Car moi j'ai eu une personne très à l'écoute, et sympathique au tél. Mais il a rien changé à mon problème à part de le trouver bizarre… 
Me disant que si l'agrégation marché c'était déjà bien mais si j'ai pris ce service aussi et surtout pour le failover car je suis à Madagascar. Nous avons des débits correctes mais beaucoup de coupures.
Soit disant il vont suivre les logs pour revenir vers moi mais plus de nouvelles depuis mon appels.
En tout cas j'attends avec impatience leur retour.
Je viens de relire ton post. Pour savoir si un lien (if1…if4) est connecté, l'OTB appelle deux adresses IP successivement (51.254.49.133 et 51.254.49.132).
Si tu ne peux pas faire un ping de ces IP depuis ta ligne TELMA, alors l'OTB considère que ton lien est coupé, et donc il ne l'intègre pas dans l'aggrégation.
Je regarderais de ce côté pour tenter de résoudre le pb.
Tu peux regarder dans Status > System Log pour voir les tentatives d'accès.
Voici un extrait d'une OTB que je gère, qui est en attente de sa seconde ligne ADSL (if2) :
Mon Nov 7 18:56:24 2016 user.debug track: if2.check: 51.254.49.133 failed was 1000 1000 1000
Mon Nov 7 18:56:24 2016 user.debug track: if1.check: 51.254.49.133 OK 50.998784ms was 52.816896 52.222976 52.857344 (50.96064 min)
Mon Nov 7 18:56:24 2016 user.debug track: if1.check: 51.254.49.132 OK 56.601856ms was 50.998784 52.816896 52.222976 (50.96064 min)
On retrouve ces IP dans Network > Load Balancing > Configuration > Interfaces
Peut-être en réglant un timeout plus long ?
Bonsoir, Julien,
je ne suis plus au bureau pour avoir accès à l’otb. Mais j’ai pu tester déjà la connexion Telma qui est avec moi avec les deux IP que tu m’as donnés. J’ai entre 3 et 7 % de perte de paquet, est-ce que c’est assez pour mettre en défaut cette connexion ?
Demain, je creuserais du côté de OTB pour voir ce qu’elle fait. Les IP testaient par l’otb sont-elle toujours les mêmes ?
Merci pour ta piste.
Bonjour Julien,
Pour commencer un grand MERCI!!! En seulement 2 posts, tu as réussi à m’aiguiller vers la solution, alors que l’assistance d’OVH m’avait laissé de côté.
Je précise la solution pour ceux qui auraient un problème similaire:
Seule, ma connexion 4G pinguait correctement vers les deux IP indiquaient (51.254.49.133 et 51.254.49.132).
Par contre , relier à l’OTB, plus aucun ping ne passait.
J’ai commencé par mettre le timeout à 4 secondes et l’intervalle des tests à 10 s, toujours rien.
J’ai remis les paramètres par défaut et puis changer le Ping count de 1 à 5, Interface down
de 3 à 10 et Interface up de 3 à 1 dans la logique d’avoir un maximum de test ping et un minimum de bon pour que la connexion soit déclarée active. Et la de retour sur l’overview, grande satisfaction, car IF3 est sur online, mais par contre mon FAI n’est toujours pas reconnu ni son adresse IP. Mais tout marche déjà.
Dans l’envie d’aller plus loin, je remets tout par défaut et décide de tester les différentes « Tracking method ». Par défaut c’est sur UDP, je mets sur TCP toujours rien ne marche et enfin je mets sur ICMP.
Et, boum ! Tout est là dans l’overwview pour la connexion telma:
Les deux connexions orange sont Offline, car elles sont en prod et je ne pouvais pas les mettre sur l’OTB. Petit truc marrant, il marque ADSL, mais je suis en 4G.
Dernière question, que cela change-t-il d’un point de vue technique le changement que j’ai fait sur « Tracking method » ?
Pour conclure, avec de super bonnes pistes (encore merci, Julien) on y arrive si on met les mains dans le cambouis. 
Bonne journée à tous !
Content que tu aies résolu ton problème
Je suis surpris de lire que tes trackings étaient sur UDP, chez moi, ils sont en DNS par défaut sur les interfaces (if1…if4).
Je ne connais pas l'impact des "tracking methods", probablement le type d'appel vers les adresses IP : ICMP c'est probablement un bête ping, DNS probablement une requête des noms de domaine attachés aux IP…
Je dirais qu'un ICMP répondra plus facilement qu'un DNS : si les serveurs DNS ne sont pas mis à jour régulièrement, ils peuvent ne pas retourner d'infos, mais c'est une pure supposition.
Essaie de modifier les DNS de ton routeur TELMA pour des DNS standards (DNS de Google : 8.8.8.8 et 8.8.4.4) et repasse en "tracking method" DNS si tu souhaites confirmer le problème.
Bonjour Julien,
Merci pour ces infos ! J’ai mis en stand-by l’otb, car une fois que cela marché (tous les voyants en verts) le faillover et la Qos ne marchaient pas. Du coup on a pris du retard sur la production. Donc je l’ai de nouveau sortie de mon réseau afin de travailler correctement.
Je vais faire ce que tu m’avais indiqué dans ton premier message, tous remettre par défaut installé mes connexions correctement du premier coup pour voir ou ça coince. Mais hors horaire de travail.
Et ouvrir une nouvelle discussion sur les problèmes que j’aurais cernés.
Merci !!!