Auteur Sujet: Agréger deux liens SDSL  (Lu 14464 fois)

0 Membres et 1 Invité sur ce sujet

corrector

  • Invité
Agréger deux liens SDSL
« Réponse #12 le: 28 juillet 2011 à 00:18:18 »
+ compression des entêtes possible, voir du flux complet si lien sans pertes
Un intérêt du VPN est aussi (à rajouter à la longue liste de corretor) de pouvoir compresser.

J'étais étonné quand j'ai fait un test IPERF chez un copain qui avait un VPN : 5 Mb/s en upload en ADSL ! (en même temps iperf rempli les paquets de 000000000000000000 donc facile à compresser)
C'était quel type de VPN?

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 4 184
Agréger deux liens SDSL
« Réponse #13 le: 28 juillet 2011 à 06:32:23 »
La Freebox n'est pas pont Ethernet.
Tu peux nous en dire plus, stp, corrector? (ou quelqu'un d'autre)
A quoi correspond ce mode bridge de la freebox?
Est-ce que ça change quelque chose à mon idée? Ne peut-on pas envoyer des paquets avec une autre IP du même sous-réseau en mode bridge?

Leon.

vivien

  • Administrateur
  • *
  • Messages: 29 358
    • Twitter LaFibre.info
Agréger deux liens SDSL
« Réponse #14 le: 28 juillet 2011 à 07:54:12 »
J'ai testé avec un Sagem F@st 800 le fait de prendre une autre IP du sous-réseau (inutilisée) et cela ne fonctionnait pas. Je ne sais pas si seulement le download ne fonctionnait pas ou le download + upload.

Si l'envoi fonctionne, alors le problème de ta solution est pour moi un risque de gigue très importante.

Si un modem buffurise plus qu'un autre (car il est utilisé en // pour une autre connexion ou a un débit plus faible) alors on peut avoir les paquets qui arrivent dans un désordre à l’arrivée.

Avec TCP, dés qu'un paquet arrive après le suivant, il y a une demande de ré-émission du paquet qui arrivera en retard (les DUP ACK). Donc on peut se retrouver dans une situation ou la moitié des paquets sont ré-émis.

corrector

  • Invité
Mode bridge : livrer de l'IP via Ethernet
« Réponse #15 le: 28 juillet 2011 à 08:10:09 »
A quoi correspond ce mode bridge de la freebox?
Définition du "mode bridge" : Le PC connecté à la Freebox reçoit l'IPv4 publique.
(il n'y a pas de "mode bridge" en IPv6, ou il n'y a que le "mode bridge" en IPv6, selon comment on voit les choses)

Il y a 3 façons de se connecter à la Freebox :
- USB (sauf Révolution et Optique) : la Freebox est un modem Ethernet USB générique (mais bizarrement sous Windows il faut installer un driver (fournit par Free))
- câble Ethernet
- Wifi

Dans tous les cas, c'est en fait (traité comme) de l'Ethernet. Donc le PC est toujours relié en Ethernet à la Freebox.

Le PC qui demande une IP par DHCP reçoit l'IP publique; le bail DHCP affiche une durée de validité qui n'a absolument aucun sens : tout autre PC qui demanderait une IP avec une autre adresse Ethernet avant l'expiration du bail DHCP recevrait la même IP. DHCP sert juste à indiquer quelle IP utiliser au PC, mais il n'y a aucun bail (au sens d'un "engagement contractuel" du serveur DHCP). Le PC qui obtient le bail DHCP n'a pas besoin de le renouveler, puisqu'en réalité il a une validité illimitée (dans le sens où l'IP est stable); et s'il le renouvelle cela ne sert à rien, puisqu'un autre PC qui arriverait juste après le renouvellement récupérerait l'IP, puisque le bail réel (l'engagement du serveur DHCP à fournir une certaine IP) a une durée de vie nulle. C'est du DHCP cosmétique.

D'ailleurs quand on connait son IP (qui est affichée sur la console de gestion si elle est fixe) on n'a plus besoin d'utiliser DHCP, on peut aussi bien fixer l'IP sur le PC.

Le but de la Freebox est d'être plug-and-play : on connecte un PC en Ethernet à la box, on paramètre l'interface Ethernet (par DHCP ou paramétrage statique, peu importe) et c'est tout. Pour cela il fallait que le trafic Internet soit livré en IP sur Ethernet natif, sans PPPotrucomachin ou autre joyeusetés. Du point de vue de l'abonné (y compris geek) (c'est à dire de mon point de vue ;) ) c'est très raisonnable : je suis client d'un FAInternet, je m'intéresse pas (sauf par curiosité) à l'empilement protocolaire de la boucle locale; je veux accéder simplement à Internet. Je veux de l'IP.

Mais les interfaces de livraison la Freebox sont en Ethernet. La solution de certains FAI à ces données du problème est qu'il faut transporter de l'Ethernet sur la boucle locale. Je trouve cela ridicule : le choix d'Ethernet est un choix de conception du modem ADSL utilisé, et la conception du modem ADSL est logiquement indépendante de l'architecture du réseau de collecte.

La solution de Free à ce problème est qu'il faut encapsuler l'IP dans de l'Ethernet entre la box et le PC. Comme sur tout réseau IP/Ethernet, il faut définir en plus de l'adresse IP :
- un préfixe de sous-réseau (de façon équivalente un masque de sous-réseau)
- l'IP d'une passerelle

Cela est la conséquence du fait de livrer les paquets dans de l'Ethernet, c'est tout (se brancher en USB à la Freebox pour se convaincre qu'Ethernet est un choix arbitraire).

Il faut se rappeler qu'une adresse IP d'une passerelle IP sur un réseau Ethernet est aussi un artifice, la seule chose qui importe est de connaitre l'adresse Ethernet de la passerelle IP. L'adresse IP de la passerelle IP sert à trouver son adresse Ethernet. À part ça elle n'est jamais utilisée par la pile réseau IP/Ethernet.

La Freebox définit donc :
- le préfixe en /24 (masque 255.255.255.0)
- la passerelle en .254

Les freenautes reçoivent des IP entre .1 et .253 (l'utilisation de la ressource IP est donc de seulement 253/256).

Comment ce sous-réseau se traduit en pratique? C'est simple, toute requête ARP renvoie l'adresse Ethernet de la Freebox (sauf l'adresse IP du freenaute évidemment).

Tout le trafic IP est envoyé sur l'adresse Ethernet de la Freebox, qui un peu comme un routeur IP ne prend que le paquet IP (vire l'en-tête Ethernet) et envoie où il faut le paquet IP. L'analogie avec un routeur IP s'arrête là, il n'y a pas de routage IP. Le paquet IP est envoyé tel quel sur le réseau de collecte (avec l'encapsulation qui convient, selon le type de boucle locale).

L'exercice classique pour un freenaute est : que se passe t-il si change l'adresse IP de passerelle IP pour autre chose que .254? (ne pas mettre l'IP de freenaute évidemment)

Réponse : Rien, tout fonctionne pareil.

Encore une fois, c'est la Freebox qui présente au freenaute le trafic Internet en le livrant de l'Ethernet, mais un autre modem pourrait ne pas faire cette traduction et envoyer de l'IP brut (il faudrait les bons drivers, etc.)

Il se trouve que quand on fait un traceroute, on voit en effet qu'on passe par l'adresse IP de la passerelle IP telle qu'annoncée par le DHCP. (Ce qui implique qu'aucun "DSLAM" Free (= routeur IP) n'a moins de 253 IP disponibles.)

corrector

  • Invité
TCP : arrivée de segments dans le désordre, DUP ACK, "fast retransmit"
« Réponse #16 le: 28 juillet 2011 à 09:11:42 »
Avec TCP, dés qu'un paquet arrive après le suivant, il y a une demande de ré-émission du paquet qui arrivera en retard (les DUP ACK). Donc on peut se retrouver dans une situation ou la moitié des paquets sont ré-émis.
Ce n'est pas ce que je comprends de la RFC 5681 - TCP Congestion Control (September 2009) :
Citer
3.2.  Fast Retransmit/Fast Recovery

   A TCP receiver SHOULD send an immediate duplicate ACK when an out-
   of-order segment arrives.
  The purpose of this ACK is to inform the
   sender that a segment was received out-of-order and which sequence
   number is expected.  From the sender's perspective, duplicate ACKs
   can be caused by a number of network problems.  First, they can be
   caused by dropped segments
.  In this case, all segments after the
   dropped segment will trigger duplicate ACKs until the loss is
   repaired.  Second, duplicate ACKs can be caused by the re-ordering of
   data segments by the network (not a rare event along some network
   paths
[Pax97]).  Finally, duplicate ACKs can be caused by replication
   of ACK or data segments by the network.  In addition, a TCP receiver
   SHOULD send an immediate ACK when the incoming segment fills in all
   or part of a gap in the sequence space.  This will generate more
   timely information for a sender recovering from a loss through a
   retransmission timeout, a fast retransmit, or an advanced loss
   recovery algorithm, as outlined in section 4.3.

   The TCP sender SHOULD use the "fast retransmit" algorithm to detect
   and repair loss, based on incoming duplicate ACKs.  The fast
   retransmit algorithm uses the arrival of 3 duplicate ACKs
(as defined
   in section 2, without any intervening ACKs which move SND.UNA) as an
   indication that a segment has been lost.  After receiving 3 duplicate
   ACKs, TCP performs a retransmission of what appears to be the missing
   segment
, without waiting for the retransmission timer to expire.

   After the fast retransmit algorithm sends what appears to be the
   missing segment, the "fast recovery" algorithm governs the
   transmission of new data until a non-duplicate ACK arrives.  The
   reason for not performing slow start is that the receipt of the
   duplicate ACKs not only indicates that a segment has been lost, but
   also that segments are most likely leaving the network
(although a
   massive segment duplication by the network can invalidate this
   conclusion).  In other words, since the receiver can only generate a
   duplicate ACK when a segment has arrived, that segment has left the
   network and is in the receiver's buffer, so we know it is no longer
   consuming network resources.  Furthermore, since the ACK "clock"
   [Jac88] is preserved, the TCP sender can continue to transmit new
   segments (although transmission must continue using a reduced cwnd,
   since loss is an indication of congestion).
Un DUP ACK n'est pas une demande de quoi que ce soit, c'est un signalement :
"je reçois des données dont je ne peux rien faire dans l'immédiat, parce qu'il me manque le début de l'histoire"

C'est l'èmetteur qui déduit qu'un paquet est vraisemblablement perdu, après quatre segments avec  ACK égaux. (Et tout ça ne tient pas compte de SACK.)

Donc si le récepteur voit arriver les segments (disjoints) n° :
1 3 2 5 4
il va envoyer le ACK correspondant au segment n°
1 1 3 3 5
le compteur de DUP ACK sera donc
0 1 0 1 0
et il n'y aura pas de retransmission (d'après ce que j'ai compris!)

vivien

  • Administrateur
  • *
  • Messages: 29 358
    • Twitter LaFibre.info
Agréger deux liens SDSL
« Réponse #17 le: 28 juillet 2011 à 09:19:35 »
Une certitude : des le premier paquet perdu il y a envoi d'un DUP ACK et ensuite à chaque paquet reçu il va envoyer un DUP ACK (alors que normalement TCP n'acquitte qu'un paquet sur deux)

Je vais vérifier si l'èmetteur ré-èmet immédiatement le paquet perdu (de mémoire c'est oui, mais je préfère vérifier)

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 4 184
Mode bridge : livrer de l'IP via Ethernet
« Réponse #18 le: 28 juillet 2011 à 21:10:39 »
Définition du "mode bridge" : [...]
Merci beaucoup corrector, pour cette description détaillée. C'est très clair.
C'est bien, on apprend des trucs ici.
Je ne savais pas, notamment, que la freebox en mode bridge "monopolisait" toutes les adresses IP du sous réseau (sauf l'adresse de la connexion).

Bon, j'ai fait quelques bidouilles ce soir entre ma connexion ADSL Free et un 2ieme PC derrière un modem 56k (on fait ce qu'on peut).
Bilan: même bien configuré en mode bridge, on ne peut pas faire sortir vers Internet des paquets IP ayant une IP source différente de sa propre connexion ADSL. Ca à la freebox, mais pas jusqu'au PC d'en face. Tant pis. Au moins, j'aurais essayé.

Leon.

corrector

  • Invité
Free : possibilité d'utiliser une autre IP source que la sienne?
« Réponse #19 le: 29 juillet 2011 à 18:35:54 »
Ne peut-on pas envoyer des paquets avec une autre IP du même sous-réseau en mode bridge?
Et si oui, est-ce que tu vas faire ce genre de choses?

Est-ce que tu utiliserais cette possibilité en ne sachant pas si c'est une fonctionnalité ou un bug susceptible d'être corrigé à la prochaine MàJ du FW?

Free supprime parfois des fonctionnalités documentées sans prévenir personne :
- passage de 8 à 2 flux multiposte (flux mutualisés)
- suppression du SIP vers l'étranger
- fin de la gratuité de la fonction transfert d'appel
- un abonné dégroupé ou transféré d'une position à une autre (suite à une panne p.ex.) change d'IP mais le DNS personnalisé et le rDNS ne suivent pas (ou parfois 9 mois après)
...alors une possibilité obscure non documentée et vraisemblablement même pas faite exprès?

corrector

  • Invité
Changer d'IP source?
« Réponse #20 le: 29 juillet 2011 à 19:09:04 »
Bon, j'ai fait quelques bidouilles ce soir entre ma connexion ADSL Free et un 2ieme PC derrière un modem 56k (on fait ce qu'on peut).
Bilan: même bien configuré en mode bridge, on ne peut pas faire sortir vers Internet des paquets IP ayant une IP source différente de sa propre connexion ADSL. Ca à la freebox, mais pas jusqu'au PC d'en face. Tant pis. Au moins, j'aurais essayé.
Petite objection : là on ne sait pas si la Freebox bloque ou si c'est après. (Moi je n'ai plus de simple modem ADSL, je ne peux pas tester sans la Freebox v5.)

Est-ce que d'autres FAI permettent cela?

Est-ce que d'autres FAI autorisent officiellement cela, de façon documentée?

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 4 184
Agréger deux liens SDSL
« Réponse #21 le: 31 juillet 2011 à 10:19:16 »
Avec TCP, dés qu'un paquet arrive après le suivant, il y a une demande de ré-émission du paquet qui arrivera en retard (les DUP ACK). Donc on peut se retrouver dans une situation ou la moitié des paquets sont ré-émis.
Je suis très surpris par ça. J'avais compris qu'un des principe même des protocoles d'Internet était d'être robuste à ce genre de choses. D'être robuste à des paquets qui empruntent des chemins différents. D'être robuste à des paquets reçus dans un ordre différent. Typiquement, si un opérateur fait du load-balancing entre 2 liaisons inter-continentales, qui elles-mêmes ont des délais légèrement différents, l'ordre des paquets n'est absolument pas garantit. Je me trompe?

Leon.

vivien

  • Administrateur
  • *
  • Messages: 29 358
    • Twitter LaFibre.info
Agréger deux liens SDSL
« Réponse #22 le: 31 juillet 2011 à 20:05:08 »
TCP est robuste (le trafic passe toujours quel que soit les problèmes rencontrés) mais en cas de problèmes, le débit diminue. Je pense que dans le cas décrit le débit va diminuer jusqu'à faire que la gigue soit suffisamment faible pour que les paquets soit dans l'ordre.

Les FAI utilisent à de très nombreux endroits l'agrégation de liens 10 Gb/s ou load-balancing. Chez Cisco cela s'apelle "Etherchannel", chez d'autres constructeurs c'est "trunk", sous linux pour agréger x liens 1 Gb/s comme un seul lien, c'est "Bondind". Plus généralement c'est IEEE 802.3ad

Le mécanisme de load-balancing est similaire à celui du mode Balance-XOR. Il est basé sur le principe qui consiste à affecter toujours le même chemin à la même machine en fonction du couple IP source / IP destination / port. La répartition du trafic se fait par un hash XOR (eXclusive OR ou OU exclusif) en fonction des arguments séléctionnables suivants :
- informations niveau 2 : les adresses MAC(source et ou destination)
- informations niveau 3 : les adresses IP (source et ou destination)
- informations niveau 4 : le port applicatif (destination)

A noter qu'un trafic non IP sera load-balancé uniquement sur ses informations niveau 2.
Une même connexion TCP prend donc toujours le même chemin, donc la gigue devrait être faible.

Sous linux voici un exemple du fichier /etc/modprobe.d/aliase-bond.conf pour équilibrer en fonction de l'IP source + IP destination + port destination :
alias bond0 bonding
options bonding mode=4 xmit_hash_policy=layer3+4 miimon=100 downdelay=200 updelay=200

Leon

  • Client SFR sur réseau Numericable
  • Modérateur
  • *
  • Messages: 4 184
Agréger deux liens SDSL
« Réponse #23 le: 31 juillet 2011 à 20:29:55 »
Une certitude : des le premier paquet perdu il y a envoi d'un DUP ACK et ensuite à chaque paquet reçu il va envoyer un DUP ACK (alors que normalement TCP n'acquitte qu'un paquet sur deux)

Je vais vérifier si l'èmetteur ré-èmet immédiatement le paquet perdu (de mémoire c'est oui, mais je préfère vérifier)
Vivien, en relisant ce que cite corrector, je comprend qu'il n'y a de répétition de paquet à priori perdu que si l'èmetteur reçoit 3 d-Ack qui lui font comprendre qu'au moins un paquet a été perdu. Donc OK pour le d-ack dès le premier paquet mal ordonné, mais pas OK pour la ré-émission immédiate.

TCP est robuste (le trafic passe toujours quel que soit les problèmes rencontrés) mais en cas de problèmes, le débit diminue. Je pense que dans le cas décrit le débit va diminuer jusqu'à faire que la gigue soit suffisamment faible pour que les paquets soit dans l'ordre.
Si c'est vraiment comme ça, c'est pas terrible, TCP-IP. Je pensais que c'était plus élaboré.

Leon.

 

Mobile View