IPv6 Routeur Mikrotik Covage14

[bOLEMO]

Deux choses :

L'adresse IPv6 et la délégation étaient données sur l'ancienne interface. Étonnant qu'il ne la donnent pas sur appel ou par courriel 

Cela étant dit, il n'y a en principe pas besoin de les connaître. Le client DHCP de ton routeur envoie une demande en aveugle (SOLLICIT et 2 REQUESTs pour adresse et préfixe), et le serveur/relais envoie l'IP et le préfixe (REPLY) :

REPLY pour l'adresse : IA_NA address: 2a03:4980:xxxx:xxxx::1 pltime=600 vltime=900
REPLY pour le préfixe : IA_PD prefix: 2a03:4980:xxxx:xxxx::/56 pltime=600 vltime=900

C'est justement le principe du DHCP, ou le client par définition demande une adresse, donc n'a pas besoin de la connaître.

Bien sûr, ici, le serveur/relais te donnera toujours les mêmes adresse/préfixe, puisque K-Net t'en a attribués des fixes.

[bOLEMO]

Bon, on a fait des essais avec @Halfman.

1) Je vois passer le paquet de son DHCPv6 SOLLICIT, qui est donc émise correctement sur la boucle de collecte.
Le paquet semble conforme (DUID type 3), la MAC correspond bien, etc...
=> Aucune réponse du relais DHCPv6 Covage.

2) J'ai envoyé depuis mon client DHCPv6 un SOLLICIT avec le DUID de la MAC de @Halfman
=> Pas de réponse du relais Covage. Sa MAC n'est donc pas reconnu pour l'IPv6 
Je précise que mon client reçoit bien une réponse du relais Covage, puis les IP/délégation, etc... avec le DUID de ma MAC.

Son client DHCPv4 fonctionne donc l'ACL IPv4 est en place correctement chez Covage.
En revanche, il semble que l'ACL IPv6 soit mal configurée chez Covage.

Il y a probablement deux bases de données pour les ACL, une pour IPv4 (qui est ok), une pour IPv6 qui pour une raison inconnue ne semble pas avoir la MAC de @Halfman.

@Novelastre ou tout autre précieux employé de K-Net du forum, merci donc de remonter le problème à Covage Calvados.

En espérant une résolution rapide pour @Halfman 

[halesk2k]

Vous êtes sur le même arbre GPON? Car à mon avis l'ipv6 est routé depuis l'OLT pour optimiser le traffic.

[bOLEMO]

Vous êtes sur le même arbre GPON? Car à mon avis l'ipv6 est routé depuis l'OLT pour optimiser le traffic.

Je vois bien passer la requête de son client, donc sur le même arbre GPON, oui.
Je vois les requêtes et réponses DHCP v6 de tout l'arbre.
Enfin quand je ne bloque pas tout ça à l'entrée.

Même si mon DUID spoofing ne fonctionne pas, le SOLLICIT envoyé par son client semble correct et devrait au moins générer un ADVERTISEMENT du relais.
Car si je vois son paquet SOLLICIT, c'est non seulement que
1) son routeur envoie bien un paquet IPv6,
2) que son OLT le forward,
3) mais surtout que la passerelle / relais le reçoit, mais l'ignore.

Seule explication, le DUID n'est pas autorisé. Comme il est bien de type 3 (LL), c'est que la MAC pour l'IPv6 n'est pas correctement renseignée dans la base de donnée Covage.
Peut-être génèrent-ils une base de donnée des DUID autorisées à recevoir une réponse, et la moulinette qui la fabrique à partir des MACs autorisés a merdouillée. Quoi qu'il en soit, le relais DHCP ne donne pas de réponse quand le DUID du client est celle de @Halfman.

[Halfman]

Merci encore à bOLEMO pour son aide précieuse. Toujours rien de mon côté  , je vais essayer de recontacter K-Net

[bOLEMO]

Merci encore à bOLEMO pour son aide précieuse. Toujours rien de mon côté  , je vais essayer de recontacter K-Net

Oui, seul K-Net peut voir ce point avec Covage. D'autres clients K-Net dans le 14 ont récemment paramétré leur IPv6 avec succès. L'IPv6 fonctionne plutôt bien ici.

Si les employés K-Net du forum passent par ici, j'espère qu'ils seront aussi proactifs que d'habitude. 

[noe77]

https://forum.caps.services/index.php/topic,8530.0.html

[Novelastre]

Bon, on a fait des essais avec @Halfman.

1) Je vois passer le paquet de son DHCPv6 SOLLICIT, qui est donc émise correctement sur la boucle de collecte.
Le paquet semble conforme (DUID type 3), la MAC correspond bien, etc...
=> Aucune réponse du relais DHCPv6 Covage.

2) J'ai envoyé depuis mon client DHCPv6 un SOLLICIT avec le DUID de la MAC de @Halfman
=> Pas de réponse du relais Covage. Sa MAC n'est donc pas reconnu pour l'IPv6 
Je précise que mon client reçoit bien une réponse du relais Covage, puis les IP/délégation, etc... avec le DUID de ma MAC.

Son client DHCPv4 fonctionne donc l'ACL IPv4 est en place correctement chez Covage.
En revanche, il semble que l'ACL IPv6 soit mal configurée chez Covage.

Il y a probablement deux bases de données pour les ACL, une pour IPv4 (qui est ok), une pour IPv6 qui pour une raison inconnue ne semble pas avoir la MAC de @Halfman.

@Novelastre ou tout autre précieux employé de K-Net du forum, merci donc de remonter le problème à Covage Calvados.

En espérant une résolution rapide pour @Halfman 

Je suis loin d'être le mieux placé pour parler d'IPv6 je l'avoue, mais ces tests sont effectivement très instructifs.

Etant moi-même dans le Calvados, je m'amuserais également à tester divers paramètres dès que je serais raccordé dans quelques semaines.

Je garde ça sous la main pour transmettre à Covage à la prochaine réunion avec leurs services, voir si ils ont des infos à ce sujet. Je gage que ça va prendre un moment avant d'obtenir des réponses claires, et encore plus pour obtenir des actions de leur part. L'IPv6 n'est pas leur priorité de ce que j'en sait.

[bOLEMO]

Bon, on a fait des essais avec @Halfman.

1) Je vois passer le paquet de son DHCPv6 SOLLICIT, qui est donc émise correctement sur la boucle de collecte.
Le paquet semble conforme (DUID type 3), la MAC correspond bien, etc...
=> Aucune réponse du relais DHCPv6 Covage.

2) J'ai envoyé depuis mon client DHCPv6 un SOLLICIT avec le DUID de la MAC de @Halfman
=> Pas de réponse du relais Covage. Sa MAC n'est donc pas reconnu pour l'IPv6 
Je précise que mon client reçoit bien une réponse du relais Covage, puis les IP/délégation, etc... avec le DUID de ma MAC.

Son client DHCPv4 fonctionne donc l'ACL IPv4 est en place correctement chez Covage.
En revanche, il semble que l'ACL IPv6 soit mal configurée chez Covage.

Il y a probablement deux bases de données pour les ACL, une pour IPv4 (qui est ok), une pour IPv6 qui pour une raison inconnue ne semble pas avoir la MAC de @Halfman.

@Novelastre ou tout autre précieux employé de K-Net du forum, merci donc de remonter le problème à Covage Calvados.

En espérant une résolution rapide pour @Halfman 

Je suis loin d'être le mieux placé pour parler d'IPv6 je l'avoue, mais ces tests sont effectivement très instructifs.

Etant moi-même dans le Calvados, je m'amuserais également à tester divers paramètres dès que je serais raccordé dans quelques semaines.

Super ! 

Je garde ça sous la main pour transmettre à Covage à la prochaine réunion avec leurs services, voir si ils ont des infos à ce sujet. Je gage que ça va prendre un moment avant d'obtenir des réponses claires, et encore plus pour obtenir des actions de leur part. L'IPv6 n'est pas leur priorité de ce que j'en sait.

Certes, mais l'infrastructure IPv6 de Covage Calvados est fonctionnelle (le relais DHCPv6 répond bien pour moi, @noe77 et de nombreux autres clients K-Net du 14 [je vois bien passer de nombreux paquets SOLLICIT et REQUESTS sur le GPON 14 qui sont fructueux]), donc le problème semble être plutôt un oubli ou une erreur dans leur base de donnée ACL IPv6.

Il faudrait simplement qu'ils vérifient déjà que la MAC (ou DUID-LL) de @Halfman est bien enregistrée : ça prend même pas une minute. Je pense que le problème ne va pas plus loin que ça.

Après, je ne blâme pas automatiquement Covage, je ne sais pas comment leur bases de données ACLs sont créées ni comment les MAC autorisées sont transmises entre K-Net et Covage.

Je pense à une chose : avez-vous déjà vérifié côté K-Net que @Halfman s'est bien vu réservé une IPv6 K-Net et une délégation /56, et que cela a bien été transmis à Covage ?
Comme le service client ne lui a pas encore indiqué quelles étaient ces adresses, peut-être, même si c'est moins probable, que le problème vient simplement de là.

En tous cas, merci @Novelastre, et cool d'avoir un tech K-Net chez nous dans le 14 

[halesk2k]

Après, je ne blâme pas automatiquement Covage, je ne sais pas comment leur bases de données ACLs sont créées ni comment les MAC autorisées sont transmises entre K-Net et Covage.

Facile, via un fichier Excel et une macro en VBscript qui alimente une base Access pour afficher en gros l'arrivé d'un nouveau client sur un écran 22". Un technicien recopie ensuite à la main l'adresse MAC dans le Windows DHCP server. 

[Novelastre]

Il faudrait simplement qu'ils vérifient déjà que la MAC (ou DUID-LL) de @Halfman est bien enregistrée : ça prend même pas une minute. Je pense que le problème ne va pas plus loin que ça.

Je pense aussi, mais le problème n'est pas tant de le signaler à Covage que de réussir à avoir quelqu'un chez eux qui puisse traiter le problème ^^'

[bOLEMO]

Il faudrait simplement qu'ils vérifient déjà que la MAC (ou DUID-LL) de @Halfman est bien enregistrée : ça prend même pas une minute. Je pense que le problème ne va pas plus loin que ça.

Je pense aussi, mais le problème n'est pas tant de le signaler à Covage que de réussir à avoir quelqu'un chez eux qui puisse traiter le problème ^^'

Pour nous, simples clients FAI, contacter un tech Covage est tout simplement impossible. J'avais envoyé un mail un jour pour les informer de la pollution présente sur leur boucle, et je n'ai jamais eu de réponse, ni même d'accusé de réception.

Mais s'ils ne répondent pas sérieusement quand un de leur clients FAI en offre activée leur signale un problème, c'est inquiétant 
Vous n'avez pas de ligne directe avec leur service technique ?

C'est quand même un de vos clients qui a un service limité par leur faute, et vous les payez pour leur service OI, donc rappelez leur cela pendant la réunion (gentiment évidemment), et on leur a facilité la tâche quand même :
- en amont, de votre côté, en vérifiant que vous leur avez bien transmis toute les informations, MAC, IPs...
- en aval, du côté client, avec les tests techniques que nous avons effectués sur leur boucle GPON.

Rappelez-leur que les clients FAI deviennent très sensibles et informés sur les OI, les interventions, les coupures causées par certains sous-traitants, les délais de remise en service, et le rôle des collectivités locales qui peuvent faire payer des pénalités (cf la discussion sur le syndicat Essone numérique). Demandez-leur de passer par ici et sur lafibre.info, ils verront par eux-mêmes.

Personnellement, je comprends que les choses ne sont pas forcément facile chez Covage. Les employés sont probablement fatigués de ne pas savoir à quelle sauce ils seront mangés avec les rachats en cascade... et la peur de perdre leur emploi car SFR et bientôt Altitude peuvent vouloir utiliser leurs propres employés, faire des économies en réduisant les effectifs, etc...
Mais cela étant dit, rien ne les excuse de ne pas être capable de vérifier qu'une entrée est correctement renseignée dans une de leur base de données !

Quelle différence avec K-Net, qui malgré un sous effectif assez évident côté service client, se démène. Vous passez par ici, vous lisez les posts et cherchez les solutions. Bravo K-Net.

[Novelastre]

Nous avons bien entendu des contacts avec leurs services techniques, mais ce problème est assez singulier, je doute que leur support N1/N2 soit autorisé à manipuler la DB des relations MAC/IPv6 manuellement.

En tout cas on va faire confirmer par notre NOC si cette hypothèse est plausible, et voir à qui s'adresser côté Covage pour faire avancer le problème.

[bOLEMO]

Nous avons bien entendu des contacts avec leurs services techniques, mais ce problème est assez singulier, je doute que leur support N1/N2 soit autorisé à manipuler la DB des relations MAC/IPv6 manuellement.

En tout cas on va faire confirmer par notre NOC si cette hypothèse est plausible, et voir à qui s'adresser côté Covage pour faire avancer le problème.

Merci pour @Halfman. Je ne doute pas un instant que le problème est pris sérieusement par K-Net et que vous ferez votre possible de votre côté 

Peut-être que les tech Covage N1/N2 ont les permissions pour consulter/vérifier (en lecture seule) la BDD MAC/DUID/IPv6...
Après, pour modifier la BDD, ils n'ont en effet probablement pas la main.

En tous cas, vous faites ce qu'il faut ; merci @Novelastre pour votre sérieux et implication pour résoudre les problèmes exprimés dans ce forum. Sachez que c'est apprécié (en tous cas certainement par moi, et je pense par de nombreux autres clients ici).

[Steph]

En tous cas, vous faites ce qu'il faut ; merci @Novelastre pour votre sérieux et implication pour résoudre les problèmes exprimés dans ce forum. Sachez que c'est apprécié (en tous cas certainement par moi, et je pense par de nombreux autres clients ici).

+1 

En 74, tout marche bien sauf l'IPv6.