Posté par benoar .
En réponse au journal L'IPv6 et moi.
Évalué à 2.
Dernière modification le 14 octobre 2019 à 13:36.
Je reprend, je veux (quelque soit la méthode utilisée) créer un réseau L2 virtuel. L2 dans L3 si tu veux. Dans ce cadre je n'ai aucun outil ou appliance qui me permettent de dire que tel ou tel paquet multicast L2 virtualisé doit être routé de telle ou telle façon L3.
J'ai vraiment l'impression qu'on ne se comprend pas : ici, ton besoin (étendre un L2 où tu veux dans le monde) est issu de contraintes applicatives qui sont que certaines applis ou certains services qui sont sur ton réseau ont été conçues pour ne pas utiliser le routage (et marcher uniquement sur un segment L2), c'est à dire ne pas être IP au sens où il a été inventé (que ça soit v4 ou v6, hein). C'est triste, et c'est la réalité je l'admet, mais comme je dis depuis le début, c'est un problème applicatif de faire « transitionner » ces services vers IPv6, pas un problème réseau, car étendre un L2 à petaouchnok n'a pas de sens en IP à la base : c'est une bidouille, qui n'a effectivement à priori pas été reportée sur un certain nombre d'équipements pour IPv6. Parce que ça n'aurait strictement aucun intérêt de faire la même merde en v6 : qu'est-ce que ça va t'apporter de dire « j'étends mon L2 sur IPv6 » ? Tu ne te bases pas sur le routage, tu ne dépends pas du nombre d'adresse, etc. Reste en IPv4, ça marche très bien comme ça !
je m'en fous - je peux spanner mon L2 sur N sites non connectés par des circuits et faire mon taf.
Alors pourquoi fais-tu de l'IPv6 ? Tu es masochistes ?
Donc MPLS, eVPN, GRE et j'en passe n'ont pas de sens ? Virtualiser un L2, ou faire que tes agents qui sont en déplacement puissent travailler à distance comme si ils étaient sur place (pour de vrai hein, en full ethernet) ça n'a pas de sens ?
Oui, ça n'a pas de sens, car cela veut dire que tes services/applications sont incrustées dans ton medium Ethernet, que tu essayes péniblement de virtualiser. Ce n'est pas la manière dont Internet a été conçu, qui est basé sur le fait que les applications utilisent des IP (v4 ou v6) comme identifiant sur le réseau, avec éventuellement adresses de groupe multicast (qui semble être ton cas et qui est effectivement un peu plus complexe que l'unicast), et doivent être complètement indépendantes du medium sous-jacent. Si ton appli dépend d'Ethernet, elle n'est pas codée selon les principes d'Internet (bis repetita). IPv6 ne t'apportera absolument rien pour régler ça dans le réseau. Par contre, l'architecture d'Internet, basée sur des adresses routées globalement (ce qui est aujourd'hui impossible à appliquer en IPv4 vu la pénurie, même si le principe date bien d'IPv4), t'apporte une solution applicative. Et c'est ça qui bloque la transition IPv6 : les développeurs, les intégrateurs, les éditeurs ne s'y mettent pas. D'où le peu d'intérêt pour un réseau IPv6 derrière, selon moi.
OK comment je "route" simplement de la trame ethernet non IP ?
Ta question n'a pas de sens. Je pense réellement que tu ne sais pas ce qu'est le routage : décider de la direction de sortie d'un paquet au format IP, en regardant l'adresse de destination qu'il contient, selon une « table de routage » qui interconnecte des réseaux issus de mediums divers et variés. C'est une couche d'unification qui sert de base aux applications, et d'abstraction aux L2 existants.
Comment je load-balance ou que je mets en haute dispo un réseau complet avec tout ce qui transite dessus (y compris tout ce qui est non IP).
Si c'est non-IP, ça sera forcément une bidouille inhérente à la nature des paquets que tu manipules, qui ne tire donc aucun avantage d'IP, et qui n'a donc pas d'intérêt à être convertie en IPv6.
Comment je fais qu'un mec qui branche une caméra à Cannes puisse la multicaster sur 3 sites de production différents sans toucher un seul instant à la config d'un seul routeur ou switch ? (de toute façon il est cameraman et il a autre chose à faire).
Ah, enfin une demande applicative ! Si l'Internet multicasté public était disponible, ton mec aurait juste à rentrer les trois noms DNS des sites distants (ou quelqu'un l'aurait provisionné pour lui) et ça marcherait sans toucher un seul routeur ou switch, sur Internet tout court. Vu que ça n'est pas le cas, tu auras à monter toi un overlay IPv6 avec des routeurs gérant les abonnements et le routage multicast, avec un routage VPN IPv6 multisite « classique ». Pas de config spécifique à cette application dans un seul de tes routeurs/switchs, hein ! C'est ça « l'architecture Internet ». Si ta caméra est IPv4 seulement, c'est un peu triste et il va falloir attaquer les mécanismes de transition IPv4/IPv6 multicast, que je connais mal et que je croyaient aborder au début de cette discussion avec toi. Je pense que c'est faisable, en tous cas beaucoup plus que les bidouilles liées à Ethernet évoquées plus haut.
Pour conclure, je ne dis pas que tes bidouilles ne doivent pas être intégrées dans le « grand plan » de transition à IPv6, hein, juste qu'elles doivent rester dans le monde IPv4, qui sera converti/encapsulé/traduit selon les schémas classiques de transition IPv4/IPv6.
[^] # Re: Tout doucement alors
Posté par benoar . En réponse au journal L'IPv6 et moi. Évalué à 2. Dernière modification le 14 octobre 2019 à 13:36.
J'ai vraiment l'impression qu'on ne se comprend pas : ici, ton besoin (étendre un L2 où tu veux dans le monde) est issu de contraintes applicatives qui sont que certaines applis ou certains services qui sont sur ton réseau ont été conçues pour ne pas utiliser le routage (et marcher uniquement sur un segment L2), c'est à dire ne pas être IP au sens où il a été inventé (que ça soit v4 ou v6, hein). C'est triste, et c'est la réalité je l'admet, mais comme je dis depuis le début, c'est un problème applicatif de faire « transitionner » ces services vers IPv6, pas un problème réseau, car étendre un L2 à petaouchnok n'a pas de sens en IP à la base : c'est une bidouille, qui n'a effectivement à priori pas été reportée sur un certain nombre d'équipements pour IPv6. Parce que ça n'aurait strictement aucun intérêt de faire la même merde en v6 : qu'est-ce que ça va t'apporter de dire « j'étends mon L2 sur IPv6 » ? Tu ne te bases pas sur le routage, tu ne dépends pas du nombre d'adresse, etc. Reste en IPv4, ça marche très bien comme ça !
Alors pourquoi fais-tu de l'IPv6 ? Tu es masochistes ?
Oui, ça n'a pas de sens, car cela veut dire que tes services/applications sont incrustées dans ton medium Ethernet, que tu essayes péniblement de virtualiser. Ce n'est pas la manière dont Internet a été conçu, qui est basé sur le fait que les applications utilisent des IP (v4 ou v6) comme identifiant sur le réseau, avec éventuellement adresses de groupe multicast (qui semble être ton cas et qui est effectivement un peu plus complexe que l'unicast), et doivent être complètement indépendantes du medium sous-jacent. Si ton appli dépend d'Ethernet, elle n'est pas codée selon les principes d'Internet (bis repetita). IPv6 ne t'apportera absolument rien pour régler ça dans le réseau. Par contre, l'architecture d'Internet, basée sur des adresses routées globalement (ce qui est aujourd'hui impossible à appliquer en IPv4 vu la pénurie, même si le principe date bien d'IPv4), t'apporte une solution applicative. Et c'est ça qui bloque la transition IPv6 : les développeurs, les intégrateurs, les éditeurs ne s'y mettent pas. D'où le peu d'intérêt pour un réseau IPv6 derrière, selon moi.
Ta question n'a pas de sens. Je pense réellement que tu ne sais pas ce qu'est le routage : décider de la direction de sortie d'un paquet au format IP, en regardant l'adresse de destination qu'il contient, selon une « table de routage » qui interconnecte des réseaux issus de mediums divers et variés. C'est une couche d'unification qui sert de base aux applications, et d'abstraction aux L2 existants.
Si c'est non-IP, ça sera forcément une bidouille inhérente à la nature des paquets que tu manipules, qui ne tire donc aucun avantage d'IP, et qui n'a donc pas d'intérêt à être convertie en IPv6.
Ah, enfin une demande applicative ! Si l'Internet multicasté public était disponible, ton mec aurait juste à rentrer les trois noms DNS des sites distants (ou quelqu'un l'aurait provisionné pour lui) et ça marcherait sans toucher un seul routeur ou switch, sur Internet tout court. Vu que ça n'est pas le cas, tu auras à monter toi un overlay IPv6 avec des routeurs gérant les abonnements et le routage multicast, avec un routage VPN IPv6 multisite « classique ». Pas de config spécifique à cette application dans un seul de tes routeurs/switchs, hein ! C'est ça « l'architecture Internet ». Si ta caméra est IPv4 seulement, c'est un peu triste et il va falloir attaquer les mécanismes de transition IPv4/IPv6 multicast, que je connais mal et que je croyaient aborder au début de cette discussion avec toi. Je pense que c'est faisable, en tous cas beaucoup plus que les bidouilles liées à Ethernet évoquées plus haut.
Pour conclure, je ne dis pas que tes bidouilles ne doivent pas être intégrées dans le « grand plan » de transition à IPv6, hein, juste qu'elles doivent rester dans le monde IPv4, qui sera converti/encapsulé/traduit selon les schémas classiques de transition IPv4/IPv6.