Auteur Sujet: Panne IPV6  (Lu 5757 fois)

0 Membres et 1 Invité sur ce sujet

thenico

  • Expert.
  • Client Orange Fibre
  • *
  • Messages: 788
  • FTTH >500 Mb/s et FTTLA 100 Mb/s (13)
Panne IPV6
« Réponse #12 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.

buddy

  • Expert
  • Client Bbox fibre FTTH
  • *
  • Messages: 8 125
  • Mougins (06)
Panne IPV6
« Réponse #13 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

vivien

  • Administrateur
  • *
  • Messages: 29 556
    • Twitter LaFibre.info
Panne IPV6
« Réponse #14 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.

thenico

  • Expert.
  • Client Orange Fibre
  • *
  • Messages: 788
  • FTTH >500 Mb/s et FTTLA 100 Mb/s (13)
Panne IPV6
« Réponse #15 le: 31 janvier 2016 à 21:12:31 »
La connexion perdante est abandonné avant le ACK final.
Citation de: RFC 6555, section 6
   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.

corrector

  • Invité
Panne IPV6
« Réponse #16 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;
}
« Modifié: 01 février 2016 à 07:03:03 par corrector »

corrector

  • Invité
Panne IPV6
« Réponse #17 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!

vivien

  • Administrateur
  • *
  • Messages: 29 556
    • Twitter LaFibre.info
Panne IPV6
« Réponse #18 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)

Comancheiv

  • Client SFR adsl
  • *
  • Messages: 189
  • Sausset-les-Pins (13)
Panne IPV6
« Réponse #19 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é.

buddy

  • Expert
  • Client Bbox fibre FTTH
  • *
  • Messages: 8 125
  • Mougins (06)
Panne IPV6
« Réponse #20 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

 

Mobile View