La Fibre
Fournisseurs d'accès à Internet fixe en France métropolitaine => SFR / RED => ADSL / VDSL => Discussion démarrée 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.
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 *
-
chezmoicamarche :).
-
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 ?
-
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é..
-
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.
-
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.
-
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
-
J'imagine que les équipements IPv6 sont nombreux (à minima "plusieurs") et que celui qui te sert habituellement a un soucis.
-
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).
-
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é.
-
çà doit concerner le Sud-Est
-
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
-
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.
-
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
-
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.
-
La connexion perdante est abandonné avant le ACK final. (http://www.bortzmeyer.org/6555.html)
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.
-
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;
}
-
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!
-
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)
-
Aujourd'hui ca fonctionne vers google et cloudflare mais pas vers lafibre et bien d'autres sites
Google:
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:
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:
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é.
-
Bonsoir,
c'est réparé comme en atteste le traceroute
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