La Fibre

Fournisseurs d'accès à Internet fixe en France métropolitaine => SFR / RED => SFR ADSL / VDSL => Discussion démarrée par: buddy le 31 janvier 2016 à 10:35:58

Titre: Panne IPV6
Posté par: buddy le 31 janvier 2016 à 10:35:58
Bonjour,

suis-je le seul à ne plus avoir d'ipv6 chez SFR ? (je viens de le voir car Lafibre.info m'affiche ipv4 en bas).
LA box a été rebootée plusieurs fois.

Le traceroute s'arrête sur un routeur sfr .. Donc çà ressemble plus à un soucis chez SFR sur son réseau.
Citer
traceroute to 2a01:6e00:10:410::2 (2a01:6e00:10:410::2), 30 hops max, 16 byte packets
 1  2a02-8400-0000-0002-0000-0000-0000-0015.rev.sfr.net (2a02:8400:0:2::15)  34.108 ms
 2  2a02-8400-0000-0003-0000-0000-0000-00ad.rev.sfr.net (2a02:8400:0:3::ad)  33.996 ms
 3  *
 4  *
 5  *
 6  *
 7  *
 8  *
Titre: Panne IPV6
Posté par: Nico le 31 janvier 2016 à 10:46:49
chezmoicamarche :).
Titre: Panne IPV6
Posté par: vivien le 31 janvier 2016 à 11:22:49
Du coup, je pense qu'il y a une latence avant d'afficher lafibre.info, vu qu'il tente en IPv6 avant de passer en IPv4 après expiation du time-out ?
Titre: Panne IPV6
Posté par: buddy le 31 janvier 2016 à 11:28:27
Je n'ai aucun site qui marche.
Même ipv6.lafibre.info
Ipv6.google.com

Tous les traceroutes s'arrête au même routeur.

C'est pour ça que je pense que c'est un truc chez SFR qui a planté..
Titre: Panne IPV6
Posté par: vivien le 31 janvier 2016 à 13:13:48
Je parlais des sites qui ont une double connectivité IPv4 et IPv6 comme https://lafibre.info

A la première connexion tu dois partir en IPv6 et a l’expiration du time-out, un essai est fait en IPv4 au lieu d'indiquer le site non disponible.
Titre: Panne IPV6
Posté par: buddy le 31 janvier 2016 à 13:17:20
Ha oui. C'est pour ça que je ne l'ai pas remarqué.

Je me demandais juste si j'étais seul ou pas à rencontré ce soucis chez SFR.
Titre: Panne IPV6
Posté par: corrector le 31 janvier 2016 à 14:34:20
Du coup, je pense qu'il y a une latence avant d'afficher lafibre.info, vu qu'il tente en IPv6 avant de passer en IPv4 après expiation du time-out ?
Joli. :D
Titre: Panne IPV6
Posté par: Nico le 31 janvier 2016 à 17:13:22
J'imagine que les équipements IPv6 sont nombreux (à minima "plusieurs") et que celui qui te sert habituellement a un soucis.
Titre: Panne IPV6
Posté par: buddy le 31 janvier 2016 à 17:16:02
Je pense aussi.
Je verrai si ça s'arrange sinon je tenterai twitter.
(J'ai des doutes que le SC au téléphone ne comprenne l'IPV6).
Titre: Panne IPV6
Posté par: Comancheiv le 31 janvier 2016 à 18:10:34
J'ai exactement le meme soucis que toi

Vers ipv6.google.com:
  1    <1 ms    <1 ms    <1 ms  box
  2    40 ms    40 ms    40 ms  2a02-8400-0000-0002-0000-0000-0000-0011.rev.sfr.net [2a02:8400:0:2::11]
  3    41 ms    40 ms    39 ms  2a02-8400-0000-0003-0000-0000-0000-008d.rev.sfr.net [2a02:8400:0:3::8d]
  4    41 ms    43 ms    43 ms  2a02-8400-0000-0003-0000-0000-0000-0eae.rev.sfr.net [2a02:8400:0:3::eae]
  5     *        *        *     Délai d'attente de la demande dépassé.
  6     *        *        *     Délai d'attente de la demande dépassé.
  7     *        *        *     Délai d'attente de la demande dépassé.
Titre: Panne IPV6
Posté par: buddy le 31 janvier 2016 à 18:47:01
 çà doit concerner le Sud-Est
Titre: Panne IPV6
Posté par: Marin le 31 janvier 2016 à 19:15:50
Aucun problème de mon côté aujourd'hui (je sors sur Paris en IPv6 même si à Lyon en IPv4).

Il serait peut-être intéressant de connaître l'adresse de votre LNS pour voir si le problème est effectivement localisé ? Voici une commande qui permet de l'obtenir sous Linux ou OS X :

$ wget -q4O- "http://wan.neufbox.sfr.net/wanservices2.xml?ip_ppp=&ip_dhcp=$(wget -q4O- icanhazip.com)&mac=E0A1D7000000&mac_ppp=E0A1D7000000&version=0&hw=N&sw=N" | grep lns
    <lns>109.3.60.159</lns>

Quelques traceroutes :

$ mtr -6rwc1 lafibre.info
Start: Sun Jan 31 19:05:31 2016
HOST: laptop                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- box                                                  0.0%     1    3.6   3.6   3.6   3.6   0.0
  2.|-- ???                                                 100.0     1    0.0   0.0   0.0   0.0   0.0
  3.|-- 2a02-8400-0000-0003-0000-0000-0000-0011.rev.sfr.net  0.0%     1   34.7  34.7  34.7  34.7   0.0
  4.|-- 2a02-8400-0000-0003-0000-0000-0000-117d.rev.sfr.net  0.0%     1   37.0  37.0  37.0  37.0   0.0
  5.|-- 2a02-8400-0000-0003-0000-0000-0000-1c2d.rev.sfr.net  0.0%     1   37.9  37.9  37.9  37.9   0.0
  6.|-- 2a02-8400-0000-0003-0000-0000-0000-1c29.rev.sfr.net  0.0%     1   37.5  37.5  37.5  37.5   0.0
  7.|-- 2a02-8400-0000-0003-0000-0000-0000-1082.rev.sfr.net  0.0%     1   36.3  36.3  36.3  36.3   0.0
  8.|-- adeli.equinix-ix.fr                                  0.0%     1   45.3  45.3  45.3  45.3   0.0
  9.|-- lafibre.info                                         0.0%     1   42.6  42.6  42.6  42.6   0.0

$ mtr -6rwc1 ipv6.google.com
Start: Sun Jan 31 19:07:39 2016
HOST: laptop                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- box                                                  0.0%     1    3.6   3.6   3.6   3.6   0.0
  2.|-- ???                                                 100.0     1    0.0   0.0   0.0   0.0   0.0
  3.|-- 2a02-8400-0000-0003-0000-0000-0000-0011.rev.sfr.net  0.0%     1   32.6  32.6  32.6  32.6   0.0
  4.|-- 2a02-8400-0000-0003-0000-0000-0000-11a5.rev.sfr.net  0.0%     1   38.2  38.2  38.2  38.2   0.0
  5.|-- 2001:4860:1:1:0:3cc5:0:1                             0.0%     1   34.2  34.2  34.2  34.2   0.0
  6.|-- 2001:4860::1:0:4a3a                                  0.0%     1   44.4  44.4  44.4  44.4   0.0
  7.|-- 2001:4860:0:1::7                                     0.0%     1   34.0  34.0  34.0  34.0   0.0
  8.|-- par10s21-in-x0e.1e100.net                            0.0%     1   35.1  35.1  35.1  35.1   0.0
Titre: Panne IPV6
Posté par: thenico le 31 janvier 2016 à 19:33:15
Du coup, je pense qu'il y a une latence avant d'afficher lafibre.info, vu qu'il tente en IPv6 avant de passer en IPv4 après expiation du time-out ?

Happy Eyeballs pallie ce problème sur les navigateurs récents: tentative en IPv6 et en IPv4 simultanèment et en se souvient de celle qui a réussi.
Titre: Panne IPV6
Posté par: buddy le 31 janvier 2016 à 19:46:31
Aucun problème de mon côté aujourd'hui (je sors sur Paris en IPv6 même si à Lyon en IPv4).

Il serait peut-être intéressant de connaître l'adresse de votre LNS pour voir si le problème est effectivement localisé ? Voici une commande qui permet de l'obtenir sous Linux ou OS X :

mon LNS est 109.3.58.221
Titre: Panne IPV6
Posté par: vivien le 31 janvier 2016 à 21:08:35
Happy Eyeballs pallie ce problème sur les navigateurs récents: tentative en IPv6 et en IPv4 simultanèment et en se souvient de celle qui a réussi.

Tu es sur de toi ?

Je devrais pouvoir trouver des traces de ça dans les logs, or je ne vois pas de requête identique la même seconde avec le même user agent en IPv4 et IPv6.

J'ai épluché les log "GET /index.php" depuis de toute la matinée, sans trouver de ligne en double.
Titre: Panne IPV6
Posté par: thenico le 31 janvier 2016 à 21:12:31
La connexion perdante est abandonné avant le ACK final. (http://www.bortzmeyer.org/6555.html)
Citation de: RFC 6555, section 6 (https://www.rfc-editor.org/rfc/rfc6555.txt)
   What follows is the algorithm implemented in Google Chrome and
   Mozilla Firefox.

   1.  Call getaddinfo(), which returns a list of IP addresses sorted by
       the host's address preference policy.

   2.  Initiate a connection attempt with the first address in that list
       (e.g., IPv6).

   3.  If that connection does not complete within a short period of
       time (Firefox and Chrome use 300 ms), initiate a connection
       attempt with the first address belonging to the other address
       family (e.g., IPv4).

   4.  The first connection that is established is used.  The other
       connection is discarded.

   If an algorithm were to cache connection success/failure, the caching
   would occur after step 4 determined which connection was successful.
Titre: Panne IPV6
Posté par: corrector le 01 février 2016 à 05:53:53
Happy Eyeballs pallie ce problème sur les navigateurs récents: tentative en IPv6 et en IPv4 simultanèment et en se souvient de celle qui a réussi.
De même dans le code de unbound, dans iterator/iter_utils.c :

/** filter out unsuitable targets
 * @param iter_env: iterator environment with ipv6-support flag.
 * @param env: module environment with infra cache.
 * @param name: zone name
 * @param namelen: length of name
 * @param qtype: query type (host order).
 * @param now: current time
 * @param a: address in delegation point we are examining.
 * @return an integer that signals the target suitability.
 * as follows:
 * -1: The address should be omitted from the list.
 *     Because:
 * o The address is bogus (DNSSEC validation failure).
 * o Listed as donotquery
 * o is ipv6 but no ipv6 support (in operating system).
 * o is ipv4 but no ipv4 support (in operating system).
 * o is lame
 * Otherwise, an rtt in milliseconds.
 * 0 .. USEFUL_SERVER_TOP_TIMEOUT-1
 * The roundtrip time timeout estimate. less than 2 minutes.
 * Note that util/rtt.c has a MIN_TIMEOUT of 50 msec, thus
 * values 0 .. 49 are not used, unless that is changed.
 * USEFUL_SERVER_TOP_TIMEOUT
 * This value exactly is given for unresponsive blacklisted.
 * USEFUL_SERVER_TOP_TIMEOUT+1
 * For non-blacklisted servers: huge timeout, but has traffic.
 * USEFUL_SERVER_TOP_TIMEOUT*1 ..
 * parent-side lame servers get this penalty. A dispreferential
 * server. (lame in delegpt).
 * USEFUL_SERVER_TOP_TIMEOUT*2 ..
 * dnsseclame servers get penalty
 * USEFUL_SERVER_TOP_TIMEOUT*3 ..
 * recursion lame servers get penalty
 * UNKNOWN_SERVER_NICENESS
 * If no information is known about the server, this is
 * returned. 376 msec or so.
 * +BLACKLIST_PENALTY (of USEFUL_TOP_TIMEOUT*4) for dnssec failed IPs.
 *
 * When a final value is chosen that is dnsseclame ; dnsseclameness checking
 * is turned off (so we do not discard the reply).
 * When a final value is chosen that is recursionlame; RD bit is set on query.
 * Because of the numbers this means recursionlame also have dnssec lameness
 * checking turned off.
 */
static int
iter_filter_unsuitable(struct iter_env* iter_env, struct module_env* env,
uint8_t* name, size_t namelen, uint16_t qtype, time_t now,
struct delegpt_addr* a)
{
int rtt, lame, reclame, dnsseclame;
if(a->bogus)
return -1; /* address of server is bogus */
if(donotq_lookup(iter_env->donotq, &a->addr, a->addrlen)) {
log_addr(VERB_ALGO, "skip addr on the donotquery list",
&a->addr, a->addrlen);
return -1; /* server is on the donotquery list */
}
if(!iter_env->supports_ipv6 && addr_is_ip6(&a->addr, a->addrlen)) {
return -1; /* there is no ip6 available */
}
if(!iter_env->supports_ipv4 && !addr_is_ip6(&a->addr, a->addrlen)) {
return -1; /* there is no ip4 available */
}
/* check lameness - need zone , class info */
if(infra_get_lame_rtt(env->infra_cache, &a->addr, a->addrlen,
name, namelen, qtype, &lame, &dnsseclame, &reclame,
&rtt, now)) {
log_addr(VERB_ALGO, "servselect", &a->addr, a->addrlen);
verbose(VERB_ALGO, "   rtt=%d%s%s%s%s", rtt,
lame?" LAME":"",
dnsseclame?" DNSSEC_LAME":"",
reclame?" REC_LAME":"",
a->lame?" ADDR_LAME":"");
if(lame)
return -1; /* server is lame */
else if(rtt >= USEFUL_SERVER_TOP_TIMEOUT)
/* server is unresponsive,
* we used to return TOP_TIMOUT, but fairly useless,
* because if == TOP_TIMEOUT is dropped because
* blacklisted later, instead, remove it here, so
* other choices (that are not blacklisted) can be
* tried */
return -1;
/* select remainder from worst to best */
else if(reclame)
return rtt+USEFUL_SERVER_TOP_TIMEOUT*3; /* nonpref */
else if(dnsseclame || a->dnsseclame)
return rtt+USEFUL_SERVER_TOP_TIMEOUT*2; /* nonpref */
else if(a->lame)
return rtt+USEFUL_SERVER_TOP_TIMEOUT+1; /* nonpref */
else return rtt;
}
/* no server information present */
if(a->dnsseclame)
return UNKNOWN_SERVER_NICENESS+USEFUL_SERVER_TOP_TIMEOUT*2; /* nonpref */
else if(a->lame)
return USEFUL_SERVER_TOP_TIMEOUT+1+UNKNOWN_SERVER_NICENESS; /* nonpref */
return UNKNOWN_SERVER_NICENESS;
}
Titre: Panne IPV6
Posté par: corrector le 01 février 2016 à 06:03:40
Tu es sur de toi ?

Je devrais pouvoir trouver des traces de ça dans les logs, or je ne vois pas de requête identique la même seconde avec le même user agent en IPv4 et IPv6.

J'ai épluché les log "GET /index.php" depuis de toute la matinée, sans trouver de ligne en double.
MDR, le navigateur qui récupère les objets HTTP deux fois!

Tu imagines la tronche du type qui paye chaque Mo!
Titre: Panne IPV6
Posté par: vivien le 01 février 2016 à 09:08:44
Il y a aussi l'attente de 300ms avant de lancer la connexion en IPv4.

Le serveur répond toujours rapidement (cela dépend du ping, mais même aux USA il y a un RTT < 300ms vers mon serveur)
Titre: Panne IPV6
Posté par: Comancheiv le 03 février 2016 à 17:47:24
Aujourd'hui ca fonctionne vers google et cloudflare mais pas vers lafibre et bien d'autres sites

Google:
Citer
  1    <1 ms     <1 ms     <1 ms  box
  2    40 ms    40 ms    40 ms  2a02-8400-0000-0002-0000-0000-0000-0011.rev.sfr.net [2a02:8400:0:2::11]
  3    40 ms    39 ms    39 ms  2a02-8400-0000-0003-0000-0000-0000-008d.rev.sfr.net [2a02:8400:0:3::8d]
  4     *        *        *     Délai d'attente de la demande dépassé.
  5     *        *        *     Délai d'attente de la demande dépassé.
  6     *        *        *     Délai d'attente de la demande dépassé.
  7    51 ms    49 ms    49 ms  2001:4860:1:1:0:3cc5:0:1
  8    50 ms    50 ms    50 ms  2001:4860::1:0:4a3a
  9    50 ms    50 ms    50 ms  2001:4860:0:1::7
 10    51 ms    51 ms    50 ms  par10s21-in-x0e.1e100.net [2a00:1450:4007:80d::200e]


Cloudflare:
Citer
1    < 1 ms    <1 ms     <1 ms  box
  2    40 ms    39 ms    40 ms  2a02-8400-0000-0002-0000-0000-0000-0011.rev.sfr.net [2a02:8400:0:2::11]
  3    40 ms    39 ms    40 ms  2a02-8400-0000-0003-0000-0000-0000-008d.rev.sfr.net [2a02:8400:0:3::8d]
  4    41 ms    42 ms    42 ms  2a02-8400-0000-0003-0000-0000-0000-0efa.rev.sfr.net [2a02:8400:0:3::efa]
  5    52 ms    51 ms    52 ms  cloudflare.mar.franceix.net [2001:7f8:54:5::29]
  6    51 ms    51 ms    51 ms  2400:cb00:2048:1::681b:8dd4


Lafibre:
Citer
  1    <1 ms    <1 ms    <1 ms  box
  2    40 ms    39 ms    40 ms  2a02-8400-0000-0002-0000-0000-0000-0011.rev.sfr.net [2a02:8400:0:2::11]
  3    40 ms    39 ms    39 ms  2a02-8400-0000-0003-0000-0000-0000-008d.rev.sfr.net [2a02:8400:0:3::8d]
  4    42 ms    43 ms    43 ms  2a02-8400-0000-0003-0000-0000-0000-0efa.rev.sfr.net [2a02:8400:0:3::efa]
  5    48 ms    47 ms    47 ms  2a02-8400-0000-0003-0000-0000-0000-1089.rev.sfr.net [2a02:8400:0:3::1089]
  6    45 ms    47 ms    47 ms  2a02-8400-0000-0003-0000-0000-0000-0f25.rev.sfr.net [2a02:8400:0:3::f25]
  7     *        *        *     Délai d'attente de la demande dépassé.
  8     *        *        *     Délai d'attente de la demande dépassé.
  9     *        *        *     Délai d'attente de la demande dépassé.
 10     *        *        *     Délai d'attente de la demande dépassé.
Titre: Panne IPV6
Posté par: buddy le 10 juin 2016 à 21:02:52
Bonsoir,

c'est réparé comme en atteste le traceroute

 
Citer
1   2a02-8400-0000-0002-0000-0000-0000-0015.rev.sfr.net (2a02:8400:0:2::15)   10.292 ms
2   2a02-8400-0000-0003-0000-0000-0000-00ad.rev.sfr.net (2a02:8400:0:3::ad)   11.785 ms
3   2a02-8400-0000-0003-0000-0000-0000-191e.rev.sfr.net (2a02:8400:0:3::191e)   47.983 ms
4   adeli.equinix-ix.fr (2001:7f8:43::4:3142:1)   24.582 ms
5   lafibre.info (2a01:6e00:10:410::2)   24.297 ms