La Fibre
Télécom => Télécom => 
Veille technologique => Discussion démarrée par: Leon le 12 août 2016 à 12:56:59
-
Voilà une réflexion qui me taraude depuis quelques temps.
Dans la joyeuse encapsulation de protocoles que nous utilisons au quotidien (TCP/UDP over IP over Ethernet), je ne comprends pas l'omniprésence de l'Ethernet. OK, Ethernet est hyper pratique pour les réseaux locaux, les réseaux WiFi locaux.
Mais pourquoi l'Ethernet est-il utilisé sur les liaisons longues distances, qui sont des liaisons "point à point"?
Je sais qu'on fait de l'Ethernet courament sur des liaisons opérateur:
* sur du 10 ou 100Gb/s longue distance
* sur des liaisons OTN
* sur des faisceaux hertziens
Pour du point à point, l'Ethernet rajoute un overhead qui me semble inutile, ou en tout cas beaucoup trop gros.
On se paye systématiquement l'overhead de 20 octets pour chaque trame Ethernet. Or, si on considère que la moyenne des paquets transportés sur Internet fait ~500octets, ça fait un overhead de 4%, ce qui est loin d'être négligeable. (Et je ne parle pas des petits paquets type VoIP).
Sur une liaison longue distance, rajouter 4% de débit en plus, ça doit représenter quelque chose de non négligeable en terme de gain économique.
Savez-vous quel protocole est utilisé sur les grosses liaisons longues distances (plusieurs milliers de km, plusieurs centaines de Gb/s)? Est-ce que c'est aussi de l'Ethernet avec ce gaspillage de 20 octets par trame?
Y a-t-il des technique pour faire croire qu'on fait de l'Ethernet, mais en supprimant/compressant l'en-tête ethernet ?
Leon.
-
Sur l'infrastructure mobile est utilisé pdcp qui implèmente RoHC pour justement traiter cette problématique sur l'interface air. Ils sont généralement pingres en bit sur cette interface ;D
https://en.m.wikipedia.org/wiki/PDCP
-
Juste une supposition sans fondement précis : peut-être que la perte de 4% est négligeable dans tous les cas présentés, par rapport aux alternatives ?
Et en particulier, la sortie de ces liens est directement utilisable par des équipements réseaux "standards" et "courants".
Il arrive aussi qu'une technologie soit si courante qu'elle en devient très peu chère en frais connexes: maintenance, profils de salaires, équipements et disponibilités d'équipements de remplacement. Et du coup qu'elle supplante largement les alternatives "un peu plus efficaces" mais trop chères en comparaison.
Enfin, cette perte de 4% n'est problématique que si on sature le lien. Mais je suppose que ça n'arrive jamais pour des raisons de marges de dimensionnement ?
-
Sur l'infrastructure mobile est utilisé pdcp qui implèmente RoHC pour justement traiter cette problématique sur l'interface air. Ils sont généralement pingres en bit sur cette interface ;D
https://en.m.wikipedia.org/wiki/PDCP
Voilà, ça montre que l'on se préoccupe bien de l'overhead dans les liaisons 3G/4G, mais pas dans les liaisons backbone classique, et c'est ça que j'ai du mal à comprendre. Ici, pour le RoHC que tu nous montre, on ne parle pas du tout de l'overhead Ethernet, on ne l'utilise naturellement pas, et en plus on compresse les en-tête IP.
Et en particulier, la sortie de ces liens est directement utilisable par des équipements réseaux "standards" et "courants".
OK, mais pour les gros équipements de coeur de réseau (routeurs, et surtout équipements optiques longue distance), c'est du matériel archi spécifique. Donc je comprends que l'interface "utilisateur" de ces équipements doit être standardisée (et Ethernet le fait très bien), mais je ne vois pas de raison d'utiliser Ethernet côté "interface longue distance", vu que c'est systématiquement du "point à point".
Enfin, cette perte de 4% n'est problématique que si on sature le lien. Mais je suppose que ça n'arrive jamais pour des raisons de marges de dimensionnement ?
Pour moi, tu prends le problème à l'envers. Dans tous les cas, il faut se fixer des limites. Par exemple si un opérateur longue distance (fournisseur de transit tier 1) décide de remplir ses liens à 80% maxi, alors il faudra qu'il sur-dimensionne de 4% ses liens avec l'overhead Ethernet. Ou alors dans l'autre sens, sur un même lien, il pourra utiliser 4% de débit en plus sans l'overhead Ethernet.
Juste une supposition sans fondement précis : peut-être que la perte de 4% est négligeable dans tous les cas présentés, par rapport aux alternatives ?
[...]
Il arrive aussi qu'une technologie soit si courante qu'elle en devient très peu chère en frais connexes: maintenance, profils de salaires, équipements et disponibilités d'équipements de remplacement. Et du coup qu'elle supplante largement les alternatives "un peu plus efficaces" mais trop chères en comparaison.
Quand on parle de liens longue distance, je pense qu'il faut commencer à compter. Les liens qui relient les grandes villes, les capitales, les liaisons sous-marines, ce sont des investissements gigantesques qu'il faut rentabiliser. Pareil pour certains faisceaux hertziens qui restent encore très utilisés dans le monde, et qui dans les pays pauvres sont à l'origine des saturations.
Le plus étrange, c'est qu'avec les techno d'il y a 15 ou 20 ans (SONET), l'overhead était apparemment très regardé. J'ai l'impression qu'aujourd'hui, c'est juste "on se fait plaisir".
Imaginez l'overhead sur des paquets VoIP, c'est juste du délire. Il y a 4 fois plus d'informations liées au protocole, que de vraie donnée utile (voix compressée). Et je ne vous parle pas de l'IPv6 qui gaspille encore plus de bande passante.
Leon.
-
Mais les liaisons dont tu parles, elles ont une MTU bien superieure à 1500 octets si je me souviens bien, donc ton calcul me parait bancal.
-
Mais les liaisons dont tu parles, elles ont une MTU bien superieure à 1500 octets si je me souviens bien, donc ton calcul me parait bancal.
Le MTU c'est la taille maximale. Pas la taille réellement utilisée.
Sur une liaison internationale qui transporte principalement (mais pas uniquement) de "l'internet", la taille moyenne des paquets est proche de 500 octets. Dans tous les cas, sur Internet, tu ne pourras pas profiter d'une MTU élevée sur une liaison, tu seras limité à 1500 voire moins dans la très grande majorité des cas.
Chaque paquet IP se retrouve dans une trame Ethernet différente.
Donc si ton téléphone IP à Lyon veut envoyer un paquet UDP de 60 octets (c'est l'ordre de grandeur moyen en VoIP) vers les US, alors ce paquet sera encapsulé tout seul dans une trame Ethernet rien que pour lui, avec un overhead de 20 octets rien que pour lui.
Leon.
-
Chaque paquet IP se retrouve dans une trame Ethernet différente.
ça ne serait pas possible d'encapsuler les petits paquets dans un gros paquet et de le désencapsuler à la sortie du lien ? ça me semble pas illogique.
-
Il y a des routeurs qui font de l’agrégation de paquet sans aucun problème :)
-
Il y a des routeurs qui font de l’agrégation de paquet sans aucun problème :)
C'est quoi "l'agrégation de paquets"? Je n'en n'ai jamais entendu parler.
Tu as des liens à nous donner? Ou juste des termes techniques pour nous mettre sur une piste?
Leon.
-
C'est quoi "l'agrégation de paquets"? Je n'en n'ai jamais entendu parler.
Tu as des liens à nous donner? Ou juste des termes techniques pour nous mettre sur une piste?
Leon.
Yep.
http://wiki.mikrotik.com/wiki/Manual:IP/Packing
Après perso, jamais utilisé car pas d'utilité.
-
Le lien point à point d'un jour est autre chose le lendemain
De plus, ethernet est présent
Ethernet existe
Ethernet est ce qui se fait de mieux en matière de stabilité et de fiabilité, de robustesse, mais également d'interopérabilité et de flexibilité
Je ne vois aucune alternative, et n'est d'ailleurs pas particulierement convaincu de la problématique
Comme tu dit, un lien > 80% est un lien qui sature
Ce 80% n'est pas une valeure importante, 80%, 85%, 84%, c'est pareil, c'est la "barre haute", le "on va upgrade ce lien"
Je partage donc l'avis de David:
la perte de 4% est négligeable dans tous les cas présentés, par rapport aux alternatives
-
Bon, je crois que je suis en train de trouver ma réponse.
Les équipements longue distance savent visiblement transporter plein de choses : de l'IP, de l'Ethernet, du MPLS, etc...
Donc les gros réseaux internet longue distance sont certainement transportés directement au niveau IP.
C'est exactement pareil pour les gros faisceaux hertizens : les grosses liaisons de backbone savent travailler en IP.
Donc sur un MAN même à l'échelle de le France, je comprends parfaitement ce que tu décris, jack, mais je pense que ça ne s'applique plus dès qu'on parle de longue distance, de plusieurs milliers de km. Sur ces liens longue distance, qui coutent une fortune, chaque optimisation compte.
Leon.
-
Que je sache, MPLS se base sur IP pour le controle, et sur un protocole de niveau 2 pour les data
Ceci dit, en théorie tu as raison
Sur plusieurs de mes constructeurs, j'ai des fonctionnalités pour "supprimer" le switching sur un port
En théorie donc, et si ce port possède une IP "point à point", il peut deviner l'IP de son copain, et donc se passer complétement de mac / arp / ndp
En pratique, je ne sais pas si ce comportement existe
-
A noter que http/2 va faire monter sensiblement la taille moyenne des paquets pour le surf en agrégeant les différent GET dans un même paquet et en enchaînant les réponses dans des paquets de talle max et en réduisant le nombre de requêtes DNS (vu que en http/2 il est conseillé de tout mettre sur le même domaine alors que pour une page en clair en http 1.1 c'est le conseil inverse pour optimiser le temps de chargement.
-
Que je sache, MPLS se base sur IP pour le controle, et sur un protocole de niveau 2 pour les data
Oui, mais le MPLS, quand il encapsule des paquets IP, c'est très peu d'overhead en comparaison d'Ethernet.
* Ethernet : 20 octets
* MPLS : 4 octets
A noter que http/2 va faire monter sensiblement la taille moyenne des paquets pour le surf en agrégeant les différent GET dans un même paquet et en enchaînant les réponses dans des paquets de talle max et en réduisant le nombre de requêtes DNS (vu que en http/2 il est conseillé de tout mettre sur le même domaine alors que pour une page en clair en http 1.1 c'est le conseil inverse pour optimiser le temps de chargement.
Ah, ça c'est une bonne nouvelle. C'est vrai qu'en regardant des captures réseau de surf web, on voit que c'est loin d'être optimisé, et qu'il y a une foultitude de petits paquets. Des gros paquets, ça allège la charge des routeurs, ça prend moins de place, etc... Ca devrait accélérer le surf pour les liaisons lentes.
Ca compensera peut-être un peu l'overhead monstrueux d'IPv6 (40 octets au lieu de 20). ;)
Leon.
-
Oui, mais le MPLS, quand il encapsule des paquets IP, c'est très peu d'overhead en comparaison d'Ethernet.
* Ethernet : 20 octets
* MPLS : 4 octets
Je me permets de te reprendre
MPLS, tu as :
- le contrôle (c'est à dire, la gestion du protocole), qui fonctionne sur IP (et peut-être autre chose)
- les données, qui fonctionnent sur un autre protocole de niveau 2 (en théorie, n'importe lequel, c'est le M de MPLS : "Multi Protocol Label Switching")
Ca compensera peut-être un peu l'overhead monstrueux d'IPv6 (40 octets au lieu de 20). ;)
Au moins 40 octets pour l'IPv6, puisque ce dernier possède des headers supplèmentaires optionnels : https://en.wikipedia.org/wiki/IPv6_packet#Extension_headers
D'un point de vue bande passante, l'IPv6 est une catastrophe (nécessaire et, in fine, non importante)
D'un point de vue routeur, l'IPv6 est en revanche une bénédiction :)
-
Je n'ai pas compris où tu voulais me reprendre
MPLS, tu as :
[...]
- les données, qui fonctionnent sur un autre protocole de niveau 2 (en théorie, n'importe lequel, c'est le M de MPLS : "Multi Protocol Label Switching")
De ce que j'ai compris, on peut encapsuler de l'IP over MPLS, de l'Ethernet over MPLS, etc...
Et l'IP over MPLS, ça ne fait que 4 octets d'overhead.
IP over ethernet over MPLS, ça en fait beaucoup plus, mais ça n'est pas ça dont je parle.
Leon.
-
IP over ethernet over MPLS over ethernet, si tu préfères
Ou ethernet over MPLS over ATM
Bref
-
Oui, mais non. Les équipements longue distance, ils savent directement transporter du MPLS. Pas besoin de "MPLS over ethernet", pour ces liens longue distance.
Leon.
-
Le but d'utiliser MPLS en longue distance c'est aussi pour des problématiques fonctionnelles de continuité d'un backbone à un autre. Le gain vis-à-vis des headers du protocole, bof.
Je rejoins ce qu'a dit Jack: Ethernet est archi-standard, connu, maitrisé. Aucun protocole n'a atteint un tel niveau d'optimisation au niveau hardware et/ou ne nécessite de matériel exotique. Il n'y a qu'à regarder le catalogue de Cisco, Ethernet est omni-présent à tous les niveaux de gamme.
J'ai du mal à lui voir un remplaçant/concurrent.
-
Les équipements longue distance, ils savent directement transporter du MPLS
Source ?
-
Juste une supposition sans fondement précis : peut-être que la perte de 4% est négligeable dans tous les cas présentés, par rapport aux alternatives ?
Et en particulier, la sortie de ces liens est directement utilisable par des équipements réseaux "standards" et "courants".
Pardon mais là tu mélanges vraiment tout, et d'ailleurs la question leon est incompréhensible (tout comme les réponses d'ailleurs) : est-ce qu'il veut parler d'Ethernet présentation logicielle de trames, ou de Ethernet II, format de trames codées, ou de IEEE 802.2 LLC SAP/SNAP?
Pourquoi mentionner Wifi qui n'est pas du tout de l'Ethernet, qui ne fonctionne pas comme de l'Ethernet, n'a aucun rapport avec Ethernet II et qui des trames plus petites?
N'importe quoi est "directement utilisable" comme n'importe quoi d'autre une fois que tu as appliqué la conversion adéquate.
Donc pourquoi transporter le formalisme d'Ethernet, avec :
- adresse Ethernet source (6 octets)
- adresse Ethernet destination (6 octets)
- numéro Ethernet de protocole encapsulé (ARP, IPv4, IPv6...) (2 octets)
soit en tout 14 octets. Je ne sais pas d'où tu sors 20 octets!
La question n'a vraiment aucun sens.
Enfin la Freebox xDSL ne transporte pas de l'Ethernet, même en mode SOI-DISANT bridge.
Finalement Ethernet est une bannière derrière laquelle tout le monde se range, point.
-
Je rejoins ce qu'a dit Jack: Ethernet est archi-standard, connu, maitrisé. Aucun protocole n'a atteint un tel niveau d'optimisation au niveau hardware et/ou ne nécessite de matériel exotique. Il n'y a qu'à regarder le catalogue de Cisco, Ethernet est omni-présent à tous les niveaux de gamme.
J'ai du mal à lui voir un remplaçant/concurrent.
Voilà, tu recraches un gloubi-boulga techno-commercial infâme et honteux.
Ce qui tu fais semblant de raconter n'a aucun sens. Quel est donc ce soi-disant "Ethernet" standardisé? Il est décrit où?
Je call ton bluff.
-
Voilà, ça montre que l'on se préoccupe bien de l'overhead dans les liaisons 3G/4G, mais pas dans les liaisons backbone classique, et c'est ça que j'ai du mal à comprendre. Ici, pour le RoHC que tu nous montre, on ne parle pas du tout de l'overhead Ethernet, on ne l'utilise naturellement pas, et en plus on compresse les en-tête IP.
OK, mais pour les gros équipements de coeur de réseau (routeurs, et surtout équipements optiques longue distance), c'est du matériel archi spécifique. Donc je comprends que l'interface "utilisateur" de ces équipements doit être standardisée (et Ethernet le fait très bien), mais je ne vois pas de raison d'utiliser Ethernet côté "interface longue distance", vu que c'est systématiquement du "point à point".
Le plus étrange, c'est qu'avec les techno d'il y a 15 ou 20 ans (SONET), l'overhead était apparemment très regardé. J'ai l'impression qu'aujourd'hui, c'est juste "on se fait plaisir".
Imaginez l'overhead sur des paquets VoIP, c'est juste du délire. Il y a 4 fois plus d'informations liées au protocole, que de vraie donnée utile (voix compressée). Et je ne vous parle pas de l'IPv6 qui gaspille encore plus de bande passante.
Pour moi la désinvolture en matière de surcharge protocolaire est bien plus importante sur une liaison ADSL où on impose une couche ATM qui ne sert strictement à rien mais qui a entête de 5 octets, plus 8 octets pour la "convergence" ALL5, soit 32% de surcharge dans le cas optimal, bien loin des 4% de l'Ethernet!
Et "personne" n'a gueulé!
-
A noter que http/2 va faire monter sensiblement la taille moyenne des paquets pour le surf en agrégeant les différent GET dans un même paquet et en enchaînant les réponses dans des paquets de talle max et en réduisant le nombre de requêtes DNS (vu que en http/2 il est conseillé de tout mettre sur le même domaine alors que pour une page en clair en http 1.1 c'est le conseil inverse pour optimiser le temps de chargement.
En HTTP 1.1 il y avait déjà le HTTP pipelining, mais il est en désactivé par défaut dans les browsers à cause de problèmes de compatibilité avec certains proxies et serveurs.
En HTTP 2, on est sûr de ne pas avoir de vieux serveur en face, et le multiplexage est plus flexible (https://http2.github.io/faq/#what-are-the-key-differences-to-http1x).
-
ça ne serait pas possible d'encapsuler les petits paquets dans un gros paquet et de le désencapsuler à la sortie du lien ? ça me semble pas illogique.
Tu peux imaginer plein de choses. Tu pourrais même aller plus loin :
- tampon avec shaping précis pour éliminer les paquets arrivant trop vite
- assembler tous les paquets en éliminant toute redondance (notamment les codes de détection d'erreur) et avec une compression simple et sans état, formant un flot continu
- segmenter et rajouter des codes correcteurs d'erreurs
Après il y a des erreurs que tu ne sais pas forcèment corriger...
-
[...]et d'ailleurs la question leon est incompréhensible (tout comme les réponses d'ailleurs) :
[...]
La question n'a vraiment aucun sens.
Voilà, tu recraches un gloubi-boulga techno-commercial infâme et honteux.
Merci corrector. ;) Ca faisait longtemps.
Donc pourquoi transporter le formalisme d'Ethernet, avec :
- adresse Ethernet source (6 octets)
- adresse Ethernet destination (6 octets)
- numéro Ethernet de protocole encapsulé (ARP, IPv4, IPv6...) (2 octets)
soit en tout 14 octets. Je ne sais pas d'où tu sors 20 octets!
J'ai arrondi à 20 dans ma tête (désolé, je ne recommencerai pas, il ne faut pas taper :-[) , mais je voulais dire 18 : il faut aussi compter le CRC de l'Ethernet, qui fait 4 octets.
Pour moi la désinvolture en matière de surcharge protocolaire est bien plus importante sur une liaison ADSL où on impose une couche ATM qui ne sert strictement à rien mais qui a entête de 5 octets, plus 8 octets pour la "convergence" ALL5, soit 32% de surcharge dans le cas optimal, bien loin des 4% de l'Ethernet!
Tu es sur de ton calcul? J'avais compris que les 8 octets de l'AAL 5 (et pas ALL5, attention aux termes, il faut être précis, corrector ;)) n'étaient attendus que dans la dernière trame ATM contenant le paquet (IP) segmenté; et pas sur chaque trame ATM. Du coup, pour un paquet IP de 500octets, on se retrouve avec un overhead de ~16%, ce qui est déjà énorme, je te l'accorde. C'est surtout énorme à cause du bourrage nécessaire pour faire des trames de taille fixe.
Leon.
-
Je pensais pas avoir parlé de wifi...
-
Je pensais pas avoir parlé de wifi...
C'est moi qui ait parlé de WiFi dans mon premier message pour introduire le sujet.
Mais il ne faut pas se formaliser sur les remarques acerbes de ce cher corrector. ::)
Leon.
-
Bon pour "AAL5" j'étais un peu énervé (même très énervé) parce qu'à la base il y a une excellente question : est-ce qu'on fait des choses (comme utiliser un protocole, un formalisme, un outil ou une représentation) par nécessité, par simplicité, pour l'uniformité, ou juste par habitude? ... choix qu'on explique ensuite par des arguments bidons.
Par exemple : j'ai fait un (non) choix par simplicité, et ensuite je raconte que ça apporte une fonctionnalité en plus alors que c'est du flan (je sais très bien que cette fonctionnalité n'a aucune utilité pratique pour le moment et que si quelqu'un voulait en disposer il la mettrait en place facilement, donc qu'en fait j'ai fait payer le surtout à 99% des utilisateurs qui s'en fichent)
La fameuse phrase sur les "optimisations prématurées" veut juste dire qu'il faut faire les choix techniques les plus simples si on n'a pas de données précises montrant qu'un autre choix améliorerait les performances. Cela ne veut évidemment pas dire qu'il faut commencer par les choix d'implèmentations qu'on pense les plus inefficaces ou les plus débiles, comme certains font mine de l'entendre. Cela ne veut pas dire qu'on n'a pas le droit de penser, mais c'est la thèse que certains idiots propagent.
-
Bon pour "AAL5" j'étais un peu énervé (même très énervé) parce qu'à la base il y a une excellente question : est-ce qu'on fait des choses (comme utiliser un protocole, un formalisme, un outil ou une représentation) par nécessité, par simplicité, pour l'uniformité, ou juste par habitude? ... choix qu'on explique ensuite par des arguments bidons.
Voilà, c'était exactement l'objet de ma question initiale!
Et j'avoue que je n'ai toujours pas d'avis tranché en ce qui concerne l'utilisation massive d'Ethernet au niveau 2, là où on pourrait utiliser un protocole plus simple et moins gourmand dans beaucoup de cas.
Leon.
-
Disons que les unixoïdes (y compris linux et Windows) ont standardisé le trame Ethernet comme représentation logicielle, ce qui permet d'uniformiser les config (sauf lien point à point); la couche logicielle du périphérique doit gérer ce format. Cela n'impose pas du tout que la couche logicielle spécifique utilise en interne ce format, mais elle doit donner l'illusion.
Ton calcul d'overhead est donc complètement faux.
-
Ton calcul d'overhead est donc complètement faux.
Ah, je n'ai pas compris pourquoi. Peux-tu stp expliquer un peu plus? L'overhead de 18 octets n'est-il pas le minimum repris sur chaque implèmentation "physique" d'Ethernet? (en plus d'être utilisés dans la représentation logicielle d'une trame Ethernet).
Y a-t-il des implèmentations "d'Ethernet over xxx" qui suppriment/compressent une partie de l'overhead inutile?
Autre chose que je n'aurais pas assimilé?
Leon.
-
Il y a Ethernet et "Ethernet". Est-ce que le Wifi est de l'Ethernet? Pour le routage linux, totalement. Physiquement, pas du tout.
Comme tu sembles considérer que l'usage d'Ethernet est légitime en Wifi, tu as l'air d'admettre que le Wifi est de l'Ethernet, ce qui fait que du coup ta question n'a plus aucun sens. Il eut fallu que tu commences par écarter le Wifi!
-
Il y a Ethernet et "Ethernet". Est-ce que le Wifi est de l'Ethernet? Pour le routage linux, totalement. Physiquement, pas du tout.
Comme tu sembles considérer que l'usage d'Ethernet est légitime en Wifi, tu as l'air d'admettre que le Wifi est de l'Ethernet, ce qui fait que du coup ta question n'a plus aucun sens. Il eut fallu que tu commences par écarter le Wifi!
Oui, pour le WiFi, je suis d'accord avec toi, c'était une erreur de ma part.
Mais pour l'Ethernet utilisé dans les liaisons longues distances, ça semble bel et bien être des trames Ethernet.
Leon.
-
A noter que l'overhead d'environ 15% en ADSL est bien plus faible en VDSL.
-
On se demande bien pourquoi ce qui marche en xDSL ne marche pas en yDSL.
-
Tu parles de datagram ethernet, corrector, du coup je viens d'aller revoir sur wikipedia : https://en.wikipedia.org/wiki/Ethernet_frame
Si je compte bien, cela fait 38B minimum d'overhead par paquet (+4 si utilisation de vlan)
-
Tu comptes au niveau 1 ou 2 ? C'est toujours l'éternel débat, un peu comme la taille minimale de 64 octets.
-
La question portait sur le SUR-coût lié à l'Ethernet. On compte ce que le choix de Ethernet ajoute. Si le préfixe sert éviter des collisions, et que le padding permet de garantir qu'on les détecte, et qu'il faut détecter les collisions, on ne le compte pas puisqu'il faudra bien éviter/détecter les collisions d'une façon ou d'une autre.
Très, très élèmentaire.
-
La question portait sur le SUR-coût lié à l'Ethernet. On compte ce que le choix de Ethernet ajoute. Si le préfixe sert éviter des collisions, et que le padding permet de garantir qu'on les détecte, et qu'il faut détecter les collisions, on ne le compte pas puisqu'il faudra bien éviter/détecter les collisions d'une façon ou d'une autre.
Collisions qui ne sont plus jamais rencontrées sur les réseaux ethernet modernes, vu que toutes les liaisons sont en full-duplex, et qu'on a au minimum des switches.
Par contre, même si les équipements ethernet longue distance transportent bel et bien les en-tête Ethernet qui sont inutile dans 99% des cas (vu que c'est du point à point et routé au niveau L3 juste après), ils ne transportent bien évidemment pas les "inter-packet" et autres joyeusetés totalement inutiles.
Leon.
-
Oui, pour le WiFi, je suis d'accord avec toi, c'était une erreur de ma part.
Mais pour l'Ethernet utilisé dans les liaisons longues distances, ça semble bel et bien être des trames Ethernet.
Mais ce qui rentre et sort d'un périphérique wlan sur linux/Windows, c'est bel et bien de l'Ethernet; le comportement d'un wlan qui est configuré en point d'accès Wifi est celui d'un périphérique Ethernet, c'est pour ça qu'on peut le mettre dans un pont Ethernet.
C'est ce qui permet d'avoir un réseau intérieur "plat" : j'accède localement aux PC connectés en filaire comme à ceux connectés en Wifi. Le plan d'adressage n'a pas besoin de faire la différence.
Donc la compatibilité n'est pas assurée par le fait de recopier le structure d'un message avec "L'overhead de 18 octets" "minimum", elle est assurée parce qu'on transmet, d'une façon ou d'une autre, ces trois informations :
Donc pourquoi transporter le formalisme d'Ethernet, avec :
- adresse Ethernet source (6 octets)
- adresse Ethernet destination (6 octets)
- numéro Ethernet de protocole encapsulé (ARP, IPv4, IPv6...) (2 octets)
soit en tout 14 octets.
-
Mais ce qui rentre et sort d'un périphérique wlan sur linux/Windows, c'est bel et bien de l'Ethernet; le comportement d'un wlan qui est configuré en point d'accès Wifi est celui d'un périphérique Ethernet, c'est pour ça qu'on peut le mettre dans un pont Ethernet.
Le WiFi comme réseau Ethernet est un cas d'une abstraction qui explose quand on la regarde d'un peu trop prés (WDS pour la 4ième MAC qui manque ...).
-
Mais du coté AP ça marche bien. Après il faut passer 4addr.
-
Juste une supposition sans fondement précis : peut-être que la perte de 4% est négligeable dans tous les cas présentés, par rapport aux alternatives ?
Et en particulier, la sortie de ces liens est directement utilisable par des équipements réseaux "standards" et "courants".
Il arrive aussi qu'une technologie soit si courante qu'elle en devient très peu chère en frais connexes: maintenance, profils de salaires, équipements et disponibilités d'équipements de remplacement. Et du coup qu'elle supplante largement les alternatives "un peu plus efficaces" mais trop chères en comparaison.
N'importe quoi, de quelle techno tu parles?
Il y a plus de technos Ethernet que de supports possibles, et il y a beaucoup de supports pour Ethernet :
support partagés (collisions) :
- coaxial "gros" 10BASE5
- coaxial "fin" 10BASE2
- 1 paire torsadé
support dédié :
- 2 paires torsadées
- 4 paires torsadées (Gigabit Ethernet)
- 2 fibres optiques, 1 longueur d'onde (différents types de fibres)
- 1 fibre optique, 2 longueurs d'ondes
support partagé (temps partagé) :
- EPON : 1 fibre optique, 2 longueurs d'ondes
-
Ah, je n'ai pas compris pourquoi. Peux-tu stp expliquer un peu plus? L'overhead de 18 octets n'est-il pas le minimum repris sur chaque implèmentation "physique" d'Ethernet? (en plus d'être utilisés dans la représentation logicielle d'une trame Ethernet).
Y a-t-il des implèmentations "d'Ethernet over xxx" qui suppriment/compressent une partie de l'overhead inutile?
Autre chose que je n'aurais pas assimilé?
Déjà est-ce qu'une implèmentation d'Ethernet doit considérer le checksum comme une donnée arbitraire? Autrement dit, doit-elle prendre en charge des trames dont le checksum est faux?
Si non, alors les mécanismes existants de détection d'erreur d'une couche inférieure peuvent remplacer le checksum Ethernet. C'est ça qui m'a fait tiquer sur ton "l'overhead est de 18 octets".
Je pense que le checksum est un moyen de détection des corruptions et qu'il ne fait pas parti de l'abstraction présentée. Donc surcharge protocolaire = addr source, dest, proto; c'est tout!
-
Intel livre ses modules photoniques : « Intel intégrera progressivement les communications optiques dans ses puces »,. Cela signifie que les communications utiliseront la lumière pour circuler à l'intérieur des ordinateurs.
[...]
La technologie sera basée sur le protocole Ethernet très courant, mais les serveurs auront besoin de commutateurs spéciaux pour supporter la vitesse des composants photoniques sur silicium. source : Le Monde Informatique (http://www.lemondeinformatique.fr/actualites/lire-transfert-de-donnees-intel-livre-ses-modules-photoniques-65673.html)
-
Les premiers modules photoniques sur silicium d'Intel assurant les transferts entre serveurs sont disponibles.
Révolution, c'est une cage SFP + un patch de fibre ?
Je n'ai pas compris
-
Révolution, c'est une cage SFP + un patch de fibre ?
Je n'ai pas compris
Pour l'instant, c'est du QSFP, donc du "connu", mais Intel envisagerai de faire de l'optique à l'intérieur d'un serveur. Je n'en vois pas trop l'intérêt.
On trouve des présentation, mais difficile de savoir si c'est seulement du pipeau marketing ou plus que ça.
http://www.intel.com/content/dam/www/public/us/en/documents/presentation/cobo-cfc-silicon-photonics-robert-blum-presentation.pdf
Leon.
-
Intel livre ses modules photoniques : « Intel intégrera progressivement les communications optiques dans ses puces »,. Cela signifie que les communications utiliseront la lumière pour circuler à l'intérieur des ordinateurs.
[...]
La technologie sera basée sur le protocole Ethernet très courant, mais les serveurs auront besoin de commutateurs spéciaux pour supporter la vitesse des composants photoniques sur silicium. source : Le Monde Informatique (http://www.lemondeinformatique.fr/actualites/lire-transfert-de-donnees-intel-livre-ses-modules-photoniques-65673.html)
Et donc, on va avoir des interconnexions 100 % optiques dans les NRO? ::)
-
Pour l'instant, c'est du QSFP, donc du "connu", mais Intel envisagerai de faire de l'optique à l'intérieur d'un serveur. Je n'en vois pas trop l'intérêt.
Ça pourra peut-être augmenter le débit possible pour le stockage, par exemple.
-
Montée en débit plus facile ? Meilleure résistance aux interférences ?
-
Dans la joyeuse encapsulation de protocoles que nous utilisons au quotidien (TCP/UDP over IP over Ethernet), je ne comprends pas l'omniprésence de l'Ethernet. OK, Ethernet est hyper pratique pour les réseaux locaux, les réseaux WiFi locaux.
Mais pourquoi l'Ethernet est-il utilisé sur les liaisons longues distances, qui sont des liaisons "point à point"?
Simplicite. Uniformisation des interfaces. Reduction des cout / capitalisation sur une technologie bien maitrisee.
Bref, on peut avoir a peu pres les memes quipements ou presque pour faire du HPC ou du backbone operateur.
Pour du point à point, l'Ethernet rajoute un overhead qui me semble inutile, ou en tout cas beaucoup trop gros.
On se paye systématiquement l'overhead de 20 octets pour chaque trame Ethernet. Or, si on considère que la moyenne des paquets transportés sur Internet fait ~500octets, ça fait un overhead de 4%, ce qui est loin d'être négligeable. (Et je ne parle pas des petits paquets type VoIP).
Sur une liaison longue distance, rajouter 4% de débit en plus, ça doit représenter quelque chose de non négligeable en terme de gain économique.
4% est generalement negligeable. C'est pas a 4% pres qu'on declanche un upgrade. Trop couteux de depnser du temps energie et argent sur une alternative qui fait gagner seulement 4%.
Savez-vous quel protocole est utilisé sur les grosses liaisons longues distances (plusieurs milliers de km, plusieurs centaines de Gb/s)? Est-ce que c'est aussi de l'Ethernet avec ce gaspillage de 20 octets par trame?
Tres souvent, oui. On multiplexe (activement ou passivement) des canaux Ethernet 1/10/40/100 Gbps. Plus rarement c'est du POS ((IP) packet over SONET).
Y a-t-il des technique pour faire croire qu'on fait de l'Ethernet, mais en supprimant/compressant l'en-tête ethernet ?
En partant sur le principe "on touche pas a ce qu'on transporte", non. Pour rappel la "TCP/IP Header compression" est aussi morte depuis un bon bout de temps.
-
4% est generalement negligeable. C'est pas a 4% pres qu'on declanche un upgrade. Trop couteux de depnser du temps energie et argent sur une alternative qui fait gagner seulement 4%.
4%, c'est négligeable?? C'est très étrange comme point de vue.
Tu connais beaucoup d'entreprises qui sont prêtes à cracher sur 4% de leur chiffre d'affaire? Juste pour info : de nombreuses entreprises ne font même pas 4% de marge!!!
Imagine qu'un gros tier-1 se mette d'un seul cout à proposer 4% de débit en plus, ou qu'il réduise de 4% ses tarifs par rapport à ses concurrents. Tu penses vraiment que ça ne changerai rien?
Je me permet une analogie. On va comparer un gros transporteur maritime international (CMA-CGM) avec ses portes-containers géants, et une gros opérateur international tier-1, qui construit lui même ses liaisons internationales très longues distances, à la fois terrestre et sous marines.
Donc selon toi, sur un porte container géant, on n'est pas à 4% près de taux de remplissage, et il est facile de rajouter un nouveau porte container géant, sans s'embêter avec les 4% de place qui sont difficile à remplir dans les porte-container existants.
Je te laisse remplacer "porte container" par "liaison optique longue distance internationale". Dans les 2 cas on parle d'investissements monstrueux avec plein de zéros (centaines de millions d'euros).
Comme je l'ai déjà dit plus haut : je pense qu'on ne gère pas de la mème façon un MAN à l'échelle de la France, et un WAN à l'échelle de la planète.
Tres souvent, oui. On multiplexe (activement ou passivement) des canaux Ethernet 1/10/40/100 Gbps. Plus rarement c'est du POS ((IP) packet over SONET).
IP over Sonet? C'est obsolète comme techno, non? Je ne vois même pas pourquoi tu m'en parles.
En partant sur le principe "on touche pas a ce qu'on transporte", non. Pour rappel la "TCP/IP Header compression" est aussi morte depuis un bon bout de temps.
Je n'ai pas compris. Quand tu connectes 2 routeurs entre eux par une liaison ethernet longue distance "point à point", l'en tête ethernet est construit/rajouté par le routeur; l'en tête ethernet ne fait pas partie des choses "utiles à transporter", ça ne fait pas partie de ce que le client confie à l'opérateur, et en plus il est évident à "deviner".
Leon.
-
4%, c'est négligeable?? C'est très étrange comme point de vue.
Comme en ethernet la capa physique c'est 10, 100, 1000, 10000, 40000, 100000, et qu'a 50% d'utilisation on pense a un upgrade (histoire d'etre pret bien avant d'arriver a 75%), ..... oui, c'est negligeable.
Tu connais beaucoup d'entreprises qui sont prêtes à cracher sur 4% de leur chiffre d'affaire? Juste pour info : de nombreuses entreprises ne font même pas 4% de marge!!!
Non, mais je sais que s'ils n'ont pas de marge d'erreur bien plus haute que 4%, ils sont presque sur d'avoir des problemes.....
Imagine qu'un gros tier-1 se mette d'un seul cout à proposer 4% de débit en plus, ou qu'il réduise de 4% ses tarifs par rapport à ses concurrents. Tu penses vraiment que ça ne changerai rien?
Non. Rien. Pour 4% je ne bouge pas. J'ai parfois du mal a convaincre mes superieurs pour plus de 10%, alors 4% ......
Je me permet une analogie. On va comparer un gros transporteur maritime international (CMA-CGM) avec ses portes-containers géants, et une gros opérateur international tier-1, qui construit lui même ses liaisons internationales très longues distances, à la fois terrestre et sous marines.
Donc selon toi, sur un porte container géant, on n'est pas à 4% près de taux de remplissage, et il est facile de rajouter un nouveau porte container géant, sans s'embêter avec les 4% de place qui sont difficile à remplir dans les porte-container existants.
Je te laisse remplacer "porte container" par "liaison optique longue distance internationale". Dans les 2 cas on parle d'investissements monstrueux avec plein de zéros (centaines de millions d'euros).
Dans les reseaux, si tu es a 96% d'utilisation, c'est le moment de paniquer.
Generalement à partir de 90% tu peux(dois) paniquer.
Entre 80% et 90% tu as peur.
Entre 70 et 80% tu es juste angoisse.
Entre 60% et 70% tu te dis qu'il faut VRAIMENT se mettre travailler sur l'upgrade sur lequel tu as deja commence a travailler depuis 50%.
Comme je l'ai déjà dit plus haut : je pense qu'on ne gère pas de la mème façon un MAN à l'échelle de la France, et un WAN à l'échelle de la planète.
C'est vrais, mais je ne vois pas le lien.
IP over Sonet? C'est obsolète comme techno, non? Je ne vois même pas pourquoi tu m'en parles.
Oui et non. Tu serais etonne d'aprendre que ca existe encore mais ca ne se voit pas.
Je n'ai pas compris. Quand tu connectes 2 routeurs entre eux par une liaison ethernet longue distance "point à point", l'en tête ethernet est construit/rajouté par le routeur; l'en tête ethernet ne fait pas partie des choses "utiles à transporter", ça ne fait pas partie de ce que le client confie à l'opérateur, et en plus il est évident à "deviner".
Si deux routeurs se parlent entre eux directement, il y a des raisons pour lesquels ils se parlent en Ethernet. Si on parle d'equipements de transport optique (muxponders), l'ethernet est seulement du payload; et on est plus sur un reseau a comutation de paquet - d'ailleurs on est plus sur un reseau a commutation point.
Concernant tes 4%, c'est aussi ce qui est perdu dans les cas ou il faut utiliser WAN-PHY (Ethernet over SONET)a la place de LAN-PHY. La encore, personne ne se plaint de ca.
Si tu veux economiser presque 3%, il y a PPP :P
-
Savez-vous quel protocole est utilisé sur les grosses liaisons longues distances (plusieurs milliers de km, plusieurs centaines de Gb/s)? Est-ce que c'est aussi de l'Ethernet avec ce gaspillage de 20 octets par trame?
C'est pas du OTN/G.709 avec au dessus de l'IP, ATM, Ethernet, etc tout melangés et en meme temps en fonction des besoins/demandes ?
L'avantage du G.709 est de permettre un bitrate différent pour chaque lambda.
(https://snag.gy/1fnbTP.jpg)
enfin il me semble mais j'ai pas de certitude. Ca n''est que ce que j'avais compris.
Utiliser des trames Ethernet ca permet d'avoir un format de colis (paquet) connu et maîtrisé. Le client met ce qu'il veut dedans, le transporteur se content de déplacer les trames Ethernet.
Bref ca permet une séparation entre intervenants/domaine de responsabilité. Ca permet le raccord facilité : on sort en Ethernet de toute façon a un moment...
Apres avec "le tout IP" de maintenant , quelqu'un qui gere de bout en bout sa liaison transatlantique va surement mettre directement de l'IP dans le payload. Encore que apres y'a le probleme du MTU , latence ..etc (je transporte un paquet d'un ping tout seul dans un gros payload?)
Un provider de tiers va faire de l'Ethernet (ou ATM plus MPLS).
Ca dépend du niveau de service , de ce qui est a la charge du transporteur et ce qui est a la charge de son client.
Certains clients veulent du LAN to LAN par exemple , le provider ne doit pas "voir" et gérer les IP (ou autre protocol de niveau 3 d'ailleurs c'est pas forcement de l'IP). Si le lien n'est pas dédié au client faut bien transporter de l'Ethernet (usuellement avec MPLS au dessus).
D'autres délèguent complement le routage au provider.
A cela s'ajoute le multi-tiers ou l'un est client de l'autre client d'un troisième, etc.
lambda dédiée:
client final: IP
provider 1: G.709
lambda partagée:
client final: IP
provider 1: Ethernet (avec 1 VLAN par client)
provider 1: G.709
lambda partagée multi-tiers
client final: IP
provider 2: MPLS
provider 1: ATM ou Ethernet
provider 1: G.709
ou je dis des conneries ? il est tard :p
-
Dans les reseaux, si tu es a 96% d'utilisation, c'est le moment de paniquer.
Generalement à partir de 90% tu peux(dois) paniquer.
Entre 80% et 90% tu as peur.
Entre 70 et 80% tu es juste angoisse.
Entre 60% et 70% tu te dis qu'il faut VRAIMENT se mettre travailler sur l'upgrade sur lequel tu as deja commence a travailler depuis 50%.
Ne me fais pas dire ce que je n'ai pas dit. Je n'ai jamais dit qu'il fallait attendre qu'un lien soit rempli à 100% avant de l'upgrader... Est-ce que tu as bien compris mon raisonnement? Visiblement, non.
Si un gros opérateur décide d'upgrader réellement ses liens longue distance (100Gbps) quand ils sont remplis à 75%, alors pour un même débit brut permis par la liaison physique, tu gagneras toujours 4% sans l'overhead Ethernet! C'est pourtant simple à comprendre, non?
Oui et non. Tu serais etonne d'aprendre que ca existe encore mais ca ne se voit pas.
[...]
Si deux routeurs se parlent entre eux directement, il y a des raisons pour lesquels ils se parlent en Ethernet. Si on parle d'equipements de transport optique (muxponders), l'ethernet est seulement du payload; et on est plus sur un reseau a comutation de paquet - d'ailleurs on est plus sur un reseau a commutation point.
Peux-tu stp faire des réponses claires et précises?
Parce que avec
* "tu serais étonné d'apprendre que ça existe mais ça ne se voit pas"
* "il y a des raisons pour lesquelles ils se parlent en ethernet"
C'est quand même archi vague, et ça n'apporte pas grand chose au débat.
C'est pas du OTN/G.709 avec au dessus de l'IP, ATM, Ethernet, etc tout melangés et en meme temps en fonction des besoins/demandes ?
L'avantage du G.709 est de permettre un bitrate différent pour chaque lambda.
C'est effectivement la piste que j'explorais. Si on peut directement transporter de l'IP over G.709 (OTN), alors ça répond totalement à ma question!
C'est ce qu'on appellerai "IPoDWDM".
Ca voudrait dire qu'il existe bel et bien des technos longues distances qui se passent totalement de cette couche Ethernet.
Mais je n'ai jamais réussi à trouver de littérature à la fois accessible, et qui confirmerai ça explicitement.
Sinon, oui, je suis parfaitement d'accord qu'il faut faire cohabiter plusieurs protocoles différents sur une même liaison "longue distance", pour optimiser tout ça. Mais tout ce qui est de l'Internet pur n'a aucun besoin de la couche Ethernet (à moins que Raf nous explique clairement le contraire).
Leon.
-
"IPoDWDM" n'existe pas et ne peut pas exister : il manque un protocole L2 à IP. Et là, tu peux utiliser n'importe quoi : PPP, HDLC, ATM, etc...
Pourquoi tout le monde utilise Ethernet ? Parce que les interfaces des routeurs permettant d'atteindre des débits de 40 ou 100G le sont. Il sera toujours plus efficace d'avoir 2x 100G que 20x 10G ou Nx YGb avec des interfaces permettant d'économiser les 4% de l'overhead.
Comme dit avant, Ethernet est tellement standard que plus personne ne se pose la question de le remplacer tellement il est connu et maitrisé (hardware, software, formation des équipes de support, etc).
Dans ton analogie avec la CMA-CGM, tu as oublié un détail : les conteneurs ne sont pas pleins. Ils peuvent l'être, mais ce n'est pas le problème de la CMA mais du client. Ben là c'est pareil.
-
@Badmax
Je ne te comprends pas.
Tu veux dire que l'IP over G.709 ça n'existe pas? Pourtant de nombreux docs semblent dire que ça existe bel et bien.
Leon.
-
C'est décrit en effet mais je n'arrive pas à trouver d'exemple concret d'implèmentation (au delà d'un POC avec mise en prod et tout le tralala)
Pour avoir joué avec OTN avec du Ciena, Ethernet était quand même l'interface la plus documentée et pratique à utiliser.
-
Dans les reseaux, si tu es a 96% d'utilisation, c'est le moment de paniquer.
Generalement à partir de 90% tu peux(dois) paniquer.
Entre 80% et 90% tu as peur.
Entre 70 et 80% tu es juste angoisse.
Entre 60% et 70% tu te dis qu'il faut VRAIMENT se mettre travailler sur l'upgrade sur lequel tu as deja commence a travailler depuis 50%.
Plus le lien est gros, plus il est possible de pousser le remplissage du lien, car le trafic est lissé par les nombreuses connexions.
Concrètement sur un lien 10 Gb/s, je pense qu'il est possible de monter jusqu'à 93% sans avoir d'impact client (pas d'augmentation de la latence ni perte de paquets). Les 93% est le trafic moyen calculé sur une période de 5minutes. Si on relevé le trafic toutes les 10 secondes (certains le font) alors on peut monter plus haut.
Là où il faut faire attention, c'est que de nombreux outils de mesure du débit moyennent le débit quand on regarde sur une période plus importante.
Il faut impérativement regarder le trafic max pour le dimensionnement et faire le nécessaire pour qu'il ne dépasse jamais les 93% sur 5minutes :
(https://lafibre.info/images/peering/201609_france-ix_trafic.png)
-
Le 5 minutes c'est arbitraire ou ça fait partie des bonnes pratiques?
-
Si un gros opérateur décide d'upgrader réellement ses liens longue distance (100Gbps) quand ils sont remplis à 75%, alors pour un même débit brut permis par la liaison physique, tu gagneras toujours 4% sans l'overhead Ethernet! C'est pourtant simple à comprendre, non?
Ça ne change rien
71% = 75%
85% = 89%
Dans les deux cas, soit tu ne fais rien, soit tu upgrades
Les 4% ne sont jamais significatifs
-
Le 5 minutes c'est arbitraire ou ça fait partie des bonnes pratiques?
Je pense ne pas me tromper en disant que plus de 99% des opérateurs mesurent sur 5 minutes, donc c'est un standard et la valeur par défaut des logiciels.
-
J'ajouterai que la règle des 5min est complètement valable sur du Wan. En LAN, ça peut s'avérer très insuffisant en raison de la probabilité plus forte de saturer.
-
Le 5 minutes c'est arbitraire ou ça fait partie des bonnes pratiques?
C'est un standard auto-proclame choisi a base d'arbitraire (~50%) et tres bonne compatibilite avec le cerveau humain (~50%).
C'est aussi ce qui est communement utilise pour la facturation au 95 percentile.
Le polling a 1 minute, voir plus souvent, donne des mesures plus precises, mais il y a des cas ou ce n'est pas possible (coucou Redback + Observium) ou souhaitable (histoire que le CPU ne passe pas son temps a repondre a X queries pour Y interfaces).
D'ailleurs, comme deja precise par vivien, plus on reduit l'interval des mesures, plus on peut trouver des differences entre le "maximum reel" et la moyenne 5 minutes.
En ce qui concerne les liens 10G ou plus, ca depend du type de traffic. Quelques clients avec des liens 1G, ayant le traffic aggrege sur un lien 10G, ca peut aller vite. Des client SDSL 4M sur un lien 1G, il y a un peu de marge.
-
Cacti n'aime pas non plus changer son polling à une autre valeur que 5 minutes (pas supporté mais possible en modifiant tous les paramètres).
-
Cacti n'aime pas non plus changer son polling à une autre valeur que 5 minutes (pas supporté mais possible en modifiant tous les paramètres).
Si, mais il y a un peu de travail à faire au prealable - modifier les RRA et quelques templates - avant de commencer effectivement à faire du polling 1 minute. Il faut aussi utiliser spine, non pas le poller PHP.
Pour moins d'un minute, faut aussi trouver un autre moyen de lancer le poller, mais ca reste possible.
Pas tout a fait "pas supporte".
Peut-etre un jour je vais me remettre a le re-faire du zero juste pour pouvoir sortir un tutoriel.
-
Justement, c'est ce que j'ai dit : techniquement faisable mais non supporté en raison des effets de bord et des actions nécessaires pour les corriger.
Le plus problématique restant le nombre de requètes à traiter : il faut que ça passe en moins d'une minute et parfois même Spine peut avoir du mal (bcp d'interfaces / équipement, équipement lent en SNMP et/ou distant, CPU équipement chargée, etc).
-
Bonsoir,
De belles questions ont été posées sur Ethernet.
Pour progresser, il faut nécessairement travailler le vocabulaire. Même moi, à cette heure tardive je risque de fourcher ma langue.
Une confusion commune est de ne pas dissocier couche Ethernet et architecture Ethernet.
La couche Ethernet de niveau 2 (ou MAC 802.3) est spécifiée dans l'IEEE 802.3 et 802.1Q.
Une architecture Ethernet s'étend sur plusieurs niveaux. Elle doit au moins inclure la couche Ethernet.
L'IEEE 802.3 spécifie autre chose que la couche MAC 802.3.
Aujourd'hui, les couches 2 s'encapsulent les unes dans les autres.
Par exemple, l'architecture Ethernet de type : ETH > G.709 est spécifiée par l'UIT-T (ETH est une couche cliente de G.709). G.709 spécifie des couches 2 spécifiques et des couches physiques qui aboutissent à CDWM et DWDM.
De nombreux autres exemples existent.
Tout protocole a besoin de champs d'en-tête et, parfois, de suffixe, pour permettre l'exploitation, l'administration et la maintenance des équipements qui engendrent le protocole.
L'histoire est sans faim, comme le vice du même nom (celui d'Archimède).
Cordialement,
Et bonnes vacances,
Michel