Bonjour
Je vais utiliser ce post là pour reprendre un peu le contenu de tous les échanges.
Principe général
Une LB, c'est BIEN, si vous ne vous en tirez pas, ressortez vos LB
Ce qui suit ne concerne QUE le OneP internet Only.
Pour tout ce qui est 3P (Internet + VoIP + TV) j'ai vu des tentatives de bidouilles mais mon conseil reste : ressortez vos LB dans ce cas ...
Il existe plein de mécanismes dans la LB pour assurer une qualité maximale. Chose que je ne vois pas dans vos confs ... ni dans les capacités de vos routeurs => ressortez vos LB (Ok, promis, c'est la dernière fois que je le mets)
Ce qui est exposé ici est une clarification d'un nombre certain de choses que vous aviez déjà trouvés en reverse analyse de la conf Orange.
On pose des clarifications pour plusieurs raisons:
- La communauté de lafibre est compétente et motivée, donc vous y arriverez c'est juste une question de temps
- Vos erreurs de confs sont riches d'enseignement pour nous dans nos analyses. Vous êtes inventifs aussi
- Vous êtes des techs, et on aime bien les techs ...
- Entre temps, cela ne perturbera pas les analyses des cas tordus "légitimes"
Principe d'évolution courante du réseau :On finalise le changement de mode de fonctionnement du réseau Orange (passage du PPP à du vrai DualStack). Cela sur le long chemin du IPv6 prioritaire avec du partage d'IPv4 qui arrivera quelque part dans le futur (CGN)
Cette finalisation passe par un changement de fonctionnement de l'accroche au réseau avec une consolidation du comportement des 2 stacks IPv4 IPv6 (principe de fonctionnement d'un BNG où on gère un contexte client indépendamment de sa connectivité IPv4 IPv6 ou CGN)
Cela passe donc pour vous par une mise aux normes de vos connexions DHCPv4 et DHCPv6 pour que les deux soient cohérentes entre elles.
En cas d'incohérence, le comportement du réseau est de déconnecter le client et toutes ses connexions.
A noter que le PPPoE reste en activité, il n'y a aucune date de suppression à ce jour. Mais le DHCPv4v6, c'est mieux pour tout un tas de raisons.
Indicateur pour savoir si vous avez été migré :Comme on commence les migrations en nombre, il n'est pas évident de savoir si vous avez été migré ou pas.
Les marqueurs sont les suivants :
- en DHCPv4, si vous recevez une IP en 172.16.x.y avec un code retour option 125 (voir plus bas) vous donnant une erreur c'est que vous avez probablement migré et que vous avez une erreur. Attention, l'ancien système donne déjà certain code d'erreur, donc ce n'est pas un marqueur absolu
- en DHCPv6, si vous recevez une option 17, c'est que vous avez migré (même si le code retour (voir plus bas) est OK). Cette option 17 n'est PAS présente dans l'ancien système
- en DHCPv6, si vous recevez un préfix avec une lease de 231 jours une option 17 avec un code erreur (voir plus bas) , c'est que vous avez migré et que vous avez une erreur.
Les modes supportés :- IPv4 Only est supporté
- IPv6 Only est supporté, il manque les DNS pour le moment qui ne sont pas donnés par le DHCPv6 (cela devrait changer dans le futur moyen proche), à vous de trouver un DNS IPv6 qui répond
- IPv4 + IPv6 est supporté et là la cohérence entre les deux stacks est importante. Pour la résolution DNS, IPv4 Only est suffisant pour le moment
Attention cependant, IPv4 only c'est pas le "futur' et de plus en plus d'accès deviennent meilleurs en réseau en IPv6 au niveau inter opérateurs . . .
le DHCP et l'IPv4 Fixe est supporté.
Traitement des erreurs : le parcage :Un des grands principes mis en place, c'est que en cas d'erreur, on ne laisse pas le device boucler et charger pour rien le réseau.
On lui donne un bail v4 et v6, mais avec des adresse/prefix qui sont non routable / non routé.
Et cela s'accompagne d'un message dans la trame DHCP retour qui donne la cause de ce parcage
Ce parcage est 100% dynamique.
En cas d'erreur de config, un simple reboot (après correction ...) suffit à vous sortir du parcage
Dans les cas ou le code retour vous signal un blacklistage de ligne ou fermeture de compte, là, vous ressortez vos LB avant d'appeler le service client.
Le blacklistage de ligne peut se produire si vous pilonner le réseau n'importe comment ...
Le "Deep inside"
Les messages DHCP4/6 supportés :Se limiter aux messages
- IPv4 : DORA + RENEW / REBIND + RELEASE
- IPv6 : SARR + RENEW / REBIND + RELEASE
Respecter les cycle de vie définis dans les RFC idoines et relancer depuis le DORA / SARR en cas de perte de la connectivité montante (à tester avec ARP et ICMPv6 NS/NA) comme le fait la LiveBox
Si le fait que l'on ne donne pas de DNS en DHCP6 ne plait pas à votre stack, faire attention à ne pas flooder le réseau avec des DHCP6 INFORM ou autre
Attention: l'option DHCPv6 "Rapid Commit" n'est PAS supportée
Les DNS :Actuellement, le DNS est donné dans le DHCPv4 seulement
Cela changera dans un futur plus ou moins proche pour être donné en DHCPv4 et DHCPv6
La préco ici est qu'à partir du moment où cela sera donné en DHCPv6, il faudra utiliser en priorité les DNS IPv6.
Pour le moment il est tout à fait fonctionnel d'utiliser un DNSv4 pour la résolution des AAAA, donc cela marche très bien.
Si vous souhaitez mettre en place des conf IPv6 Only dès à présent, à vous de trouver un DNS IPv6 qui répond à vos requêtes.
Attention, pour la TV et la VoIP (voir la remarque de début sur le 3P et les LB) il FAUT utiliser les DNS resolver Orange qui sont donnés dans le DHCP de Orange.
L'encodage des information d'authentification :Le gros morceau. Chez Orange on a choisi de gérer une identification client "in line". L'objectif n'est pas ici de discuter de la pertinence de ce choix, mais de vous aider à faire marcher cela.
Cette identification / authentification se loge dans les options DHCPv4 90 et DHCPv6 11.
C'est fondamentalement un CHAP ou le challenge est choisi par vous.
Comme il manque 2 PKts au CHAP, le IDENTIFIER et le CHALLENGE sont à choisir par vous
Concernant le CHAP challenge et idéalement le changer à chaque cycle complet DHCP quand on change le TransactionID DHCP4/6 (voir RFC)
Ici vous trouverez un bon générateur issu du long thread de reverse engenering de ces options
https://jsfiddle.net/kgersen/3mnsc6wy/Le canal retour :Dans la réponse DHCP il y a un canal de retour du réseau.
C'est l'option 125 en DHCPv4, l'option 17 en DHCPv6
Le contenu (attention, les entêtes des options sont différentes, voir les RFC) est le même et dans le format suivant avec en rouge 2 octets de code d'information : 000100
0000ffffffffff
Les grandes classes de réponses sont :
- 00xx : OK vu du réseau Orange et tout doit fonctionner. Si ce n'est pas le cas le problème vient de chez vous.
- 01xx : Le modèle de box, le firmware ou votre ligne est bloquée (0102 ce qui peut arriver si le comportement de votre routeur est trop agressif ...) 0199 en cas de mauvaise COS sur le DHCP
- 02xx : erreur de Login ou de Mot de passe ou d'encodage
- 03xx : compte ou service probablement résilié
- 04xx : problème de règlement de la facture avec de possibles limitation de débit ou blocage.
La mystérieuse COS6 ... :La COS6 sert à prioriser les pkts DHCP(4/6), ARP et ICMP NS/NA entre la boxe et la BNG (premier routeur qui gère les IPs) qui gère le contexte client.
Normalement, une COS0 sur ces paquets ne devrait pas marcher, mais un bug de certain équipement le permet.
Comme vous ne pouvez pas savoir sur quel équipement vous êtes ni si vous allez rester dessus (upgrade / changement / réaménagement) je conseille fortement de passer la conf en COS6
La COS6 ne va pas plus loin que le BNG et est remplacé par une COS0 à ce point, il ne sert donc à rien de taguer tous vos paquets en COS6. De plus le trafic en COS6 est fortement limité en débit, donc là aussi, si vous pouvez limiter proprement uniquement aux paquets ci dessus, c'est nettement mieux.
La COS6 jusqu'au BNG sert à protéger le trafic d'établissement et de maintient de la connexion en cas de surcharge sur le segment client <-> BNG. Plein de cas possible.
La COS6 (et idéalement le pendant dscp) doit être appliqué :
- Au DHCPv4v6 issu de la boxe
- Au ARP issu de la boxe
- A l'ICMPv6 code NS/NA issu de la boxe et à destination de l'ipv6 fe80::ba0:bab
- A l'ICMPv6 code RS issu de la boxe et à destination de l'ipv6 multicast idoine (c'est ba0bab qui répond)
- Rien d'autre ...
Le BNG peut avoir utilité à avoir un marquage DSCP en plus de la COS.
Cependant très peu de chance que ce BNG soit à saturation, ni sur les cartes d'interface, ni en coeur.
Je maintiens donc : DSCP cohérent avec la COS, c'est mieux. Mais dans > 99% des cas cela se passera bien même sans le DSCP en ligne avec la COS
Adrese MAC et DUID :Les informations de MAC et de DUID sont obligatoires.
En DHCPv4, l'option 61 devient obligatoire
En DHCPv6, la DUID est aussi impératif
Les options ClientID sont les MAC en HEXA, SANS les ":" entre les bloc ...
DHCPv4 :
Option: (61) Client identifier
Length: 7
Hardware type: Ethernet (0x01)
Client MAC address: 44d454XXXXXX
l'encodage Hexa de ce qui est ci dessus : 3d 07 01 44 d4 54 XX XX XX
DHCPv6:
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 0003000144d454XXXXXX
DUID: 0003000144d454XXXXXX
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: 44:d4:54:XX:XX:XX
l'encodage Hexa de ce qui est ci dessus : 00 01 00 0a 00 03 00 01 44 d4 54 XX XX XX
Comme indiqué dans l'encodage des RFC
DUID et MAC : Principe général : éviter de jouer avec pour en changer trop vite ... On a des fonctions dans le réseau qui limitent le nbe de DUID / MAC derrière un même accès. Mais cela vous le saviez déjà.
Avec une temporisation de clear "d 'un certain temps" ..
Eteindre ou débrancher l'ONT, je ne suis pas certain que cela nettoie à 100% de chance ton contexte dans le OLT/DSLAM face à ta ligne, je vais vérifier ce point, mais je ne pense pas.
Attention quand vous faites vos tests, les baux sont à 3 jours et vont être allongés (en fin de migration, donc pas tout de suite )
Toujours pour protection, certains équipements n'autorisent que qq baux en parallèle sur une ligne, donc :
- faire un RELEASE (v4 et V6) avant de jouer avec votre DUID
- ne pas changer de DUID pour le fun à la volé ...
Si tous les contextes sont pris sur l'équipement, il faut attendre la fin du plus vieux des baux pour pouvoir vous relancer ... (cela peut donc durer .... 3 jours ....)
Dernier principe général : quand vous perdez la connectivité, faire un RELEASE v4 et V6 (un truc propre quoi .. comme fait une box nativement
)
Un conseil: choisissez une MAC (celle de votre LB est une bonne candidate) et garder la. Y'a pas de contrainte sur la MAC, mais évitez d'en changer à la volé ou n'importe comment.
De l'importance des tests de vie :La cnx de la LB peut être interrompue sur plusieurs segments entre la LB et le BNG.
Si vous ne testez pas la cnx montante, vous allez vous retrouver hors séquence et donc vous faire blaster régulièrement.
Cela doit être fait sur LES DEUX stacks Ipv4 et IPv6
Une capture minimal de ce que fait la LB vous permettra de comprendre la puissance de ces deux algos ....
Et quand vous détectez une fin de vie sur un stack, vous relancez celui ci (cycle DORA ou SARR suivant le stack) proprement
Faite un RELEASE (du bon stack) AVANT de relancer le cycle ....
Durant votre capture, vous verrez que le BNG fait de même dans l'autre sens ... d'où l'importance de bien répondre à ces message avec la bonne COS6
Exemple de trames :En IPv6 le ClientID (DHCPv6 option 1) est obligatoire. Nettement mieux si c'est cohérent avec l'adresse LLA et là MAC du Pkt IPv6
En IPv4 il te faut :
Dynamic Host Configuration Protocol (Discover)
Message type: Boot Request (1)
Hardware type: Ethernet (0x01)
Hardware address length: 6
Hops: 0
Transaction ID: 0x6ac82ac7
Seconds elapsed: 1
Bootp flags: 0x8000, Broadcast flag (Broadcast)
Client IP address: 0.0.0.0
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Client MAC address: 44:d4:54:XX:XX:XX
Client hardware address padding: 00000000000000000000
Server host name not given
Boot file name not given
Magic cookie: DHCP
Option: (53) DHCP Message Type (Discover)
Option: (55) Parameter Request List
Length: 12
Parameter Request List Item: (1) Subnet Mask
Parameter Request List Item: (3) Router
Parameter Request List Item: (6) Domain Name Server
Parameter Request List Item: (15) Domain Name
Parameter Request List Item: (28) Broadcast Address
Parameter Request List Item: (51) IP Address Lease Time
Parameter Request List Item: (58) Renewal Time Value
Parameter Request List Item: (59) Rebinding Time Value
Parameter Request List Item: (90) Authentication
Parameter Request List Item: (119) Domain Search
Parameter Request List Item: (120) SIP Servers
Parameter Request List Item: (125) V-I Vendor-specific Information
Option: (60) Vendor class identifier
Option: (61) Client identifier
Option: (77) User Class Information
Option: (90) Authentication
Option: (255) End
En DHCPv6
DHCPv6
Message type: Solicit (1)
Transaction ID: 0x1eace9
Client Identifier
Option: Client Identifier (1)
Length: 10
Value: 0003000144d454XXXXXX
DUID: 0003000144d454XXXXXX
DUID Type: link-layer address (3)
Hardware type: Ethernet (1)
Link-layer address: 44:d4:54:XX:XX:XX
Elapsed time
Option: Elapsed time (8)
Length: 2
Value: 0000
Elapsed time: 0ms
Option Request
Option: Option Request (6)
Length: 8
Value: 000b001100170018
Requested Option code: Authentication (11)
Requested Option code: Vendor-specific Information (17)
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Identity Association for Prefix Delegation
Authentication
Option: Authentication (11)
Length: 70
Value: 00000000000000000000001a0900000558010341010dXXXX…
Protocol: 0
Algorithm: 0
RDM: 0
Replay Detection: 0000000000000000
Authentication Information: 1a0900000558010341010dXXXX…
User Class
Option: User Class (15)
Length: 45
Value: 002b46535644534c5f6c697665626f782e496e7465726e65…
Vendor Class
Option: Vendor Class (16)
Length: 11
Value: 0000040e0005736167656d
Enterprise ID: SAGEMCOM SAS (1038)
vendor-class-data: sagem
LeVieux
Remplacer la LiveBox par un routeur