Bonjour à toutes et à tous,
1). comme je viens de découvrir traceroute, je l'ai essayé sur mon serveur :
# traceroute google.com
traceroute to google.com (216.58.211.206), 30 hops max, 60 byte packets
send: Opération non permise
Chain OUTPUT (policy DROP 2077 packets, 274K bytes)
â¦
1357K 108M ACCEPT udp -- * * 0.0.0.0/0 0.0.0 .0/0 udp dpt:53
39257 2984K ACCEPT udp -- * * 0.0.0.0/0 0.0.0 .0/0 udp dpt:123
Où ai-je merdé dans ma configuration iptables ?
2). Ci-dessus, je vois que mon serveur est à 5 sauts de Cloudflare, mais à 9 sauts de
Google. C'est par ailleurs marrant quand je compare avec Google VF :
# traceroute -I google.fr
traceroute to google.fr (216.58.211.195), 30 hops max, 60 byte packets
1 vss-9b-6k.fr.eu (5.135.191.252) 0.650 ms 0.925 ms 0.974 ms
2 rbx-g1-a9.fr.eu (178.33.100.207) 0.936 ms 0.955 ms 0.966 ms
3 th2-1-a9.fr.eu (213.251.130.53) 4.044 ms 4.073 ms 4.088 ms
4 * * *
5 72.14.238.234 (72.14.238.234) 7.014 ms 7.028 ms 7.040 ms
6 209.85.245.83 (209.85.245.83) 4.815 ms 13.509 ms 13.451 ms
7 209.85.245.236 (209.85.245.236) 20.128 ms 20.187 ms 20.139 ms
8 216.239.50.135 (216.239.50.135) 19.718 ms 19.463 ms 19.586 ms
9 mad01s25-in-f195.1e100.net (216.58.211.195) 20.023 ms 20.036 ms 19 .944 ms
Ãa veut dire que google.{com | fr } est au même endroit (Mounta in View
?) ;-)
Existe-t-il un outil qui permette de choisir ses routes en fonction d'un algorithme lambda,
afin que je rapproche mon serveur de Google par exemple ?
Bonjour à toutes et à tous,
1). comme je viens de découvrir traceroute, je l'ai essayé sur mon serveur :
# traceroute google.com
traceroute to google.com (216.58.211.206), 30 hops max, 60 byte packets
send: Opération non permise
Chain OUTPUT (policy DROP 2077 packets, 274K bytes)
â¦
1357K 108M ACCEPT udp -- * * 0.0.0.0/0 0.0.0 .0/0 udp dpt:53
39257 2984K ACCEPT udp -- * * 0.0.0.0/0 0.0.0 .0/0 udp dpt:123
Où ai-je merdé dans ma configuration iptables ?
2). Ci-dessus, je vois que mon serveur est à 5 sauts de Cloudflare, mais à 9 sauts de
Google. C'est par ailleurs marrant quand je compare avec Google VF :
# traceroute -I google.fr
traceroute to google.fr (216.58.211.195), 30 hops max, 60 byte packets
1 vss-9b-6k.fr.eu (5.135.191.252) 0.650 ms 0.925 ms 0.974 ms
2 rbx-g1-a9.fr.eu (178.33.100.207) 0.936 ms 0.955 ms 0.966 ms
3 th2-1-a9.fr.eu (213.251.130.53) 4.044 ms 4.073 ms 4.088 ms
4 * * *
5 72.14.238.234 (72.14.238.234) 7.014 ms 7.028 ms 7.040 ms
6 209.85.245.83 (209.85.245.83) 4.815 ms 13.509 ms 13.451 ms
7 209.85.245.236 (209.85.245.236) 20.128 ms 20.187 ms 20.139 ms
8 216.239.50.135 (216.239.50.135) 19.718 ms 19.463 ms 19.586 ms
9 mad01s25-in-f195.1e100.net (216.58.211.195) 20.023 ms 20.036 ms 19 .944 ms
Ãa veut dire que google.{com | fr } est au même endroit (Mounta in View
?) ;-)
Existe-t-il un outil qui permette de choisir ses routes en fonction d'un algorithme lambda,
afin que je rapproche mon serveur de Google par exemple ?
Bonjour à toutes et à tous,
1). comme je viens de découvrir traceroute, je l'ai essayé sur mon serveur :
# traceroute google.com
traceroute to google.com (216.58.211.206), 30 hops max, 60 byte packets
send: Opération non permise
Chain OUTPUT (policy DROP 2077 packets, 274K bytes)
â¦
1357K 108M ACCEPT udp -- * * 0.0.0.0/0 0.0.0 .0/0 udp dpt:53
39257 2984K ACCEPT udp -- * * 0.0.0.0/0 0.0.0 .0/0 udp dpt:123
Où ai-je merdé dans ma configuration iptables ?
2). Ci-dessus, je vois que mon serveur est à 5 sauts de Cloudflare, mais à 9 sauts de
Google. C'est par ailleurs marrant quand je compare avec Google VF :
# traceroute -I google.fr
traceroute to google.fr (216.58.211.195), 30 hops max, 60 byte packets
1 vss-9b-6k.fr.eu (5.135.191.252) 0.650 ms 0.925 ms 0.974 ms
2 rbx-g1-a9.fr.eu (178.33.100.207) 0.936 ms 0.955 ms 0.966 ms
3 th2-1-a9.fr.eu (213.251.130.53) 4.044 ms 4.073 ms 4.088 ms
4 * * *
5 72.14.238.234 (72.14.238.234) 7.014 ms 7.028 ms 7.040 ms
6 209.85.245.83 (209.85.245.83) 4.815 ms 13.509 ms 13.451 ms
7 209.85.245.236 (209.85.245.236) 20.128 ms 20.187 ms 20.139 ms
8 216.239.50.135 (216.239.50.135) 19.718 ms 19.463 ms 19.586 ms
9 mad01s25-in-f195.1e100.net (216.58.211.195) 20.023 ms 20.036 ms 19 .944 ms
Ãa veut dire que google.{com | fr } est au même endroit (Mounta in View
?) ;-)
Existe-t-il un outil qui permette de choisir ses routes en fonction d'un algorithme lambda,
afin que je rapproche mon serveur de Google par exemple ?
Le 16756ième jour après Epoch,
Philippe Gras écrivait:
[...]Où ai-je merdé dans ma configuration iptables ?
Merdé n'est pas vraiment le mot. Tu n'autorise que 2 ports UDP en
sortie, et traceroute va par défaut incrémenter les ports UDP à chaque
test. Donc en général ça n'a pas le droit de sortir du coup.
Essaye avec -U ou -UL pour forcer en UDP port 53
Existe-t-il un outil qui permette de choisir ses routes en fonction d'un algorithme lambda,
afin que je rapproche mon serveur de Google par exemple ?
À moins de tirer assez fort le câble RJ45 pour rapprocher google de chez
toi, les routes sont choisies à chaque noeud, selon pas mal de critères
comme la charge machine, l'encombrement de ligne, etc
Tu ne peux en général pas forcer une route particulière.
Le 16756ième jour après Epoch,
Philippe Gras écrivait:
[...]
Où ai-je merdé dans ma configuration iptables ?
Merdé n'est pas vraiment le mot. Tu n'autorise que 2 ports UDP en
sortie, et traceroute va par défaut incrémenter les ports UDP à chaque
test. Donc en général ça n'a pas le droit de sortir du coup.
Essaye avec -U ou -UL pour forcer en UDP port 53
Existe-t-il un outil qui permette de choisir ses routes en fonction d'un algorithme lambda,
afin que je rapproche mon serveur de Google par exemple ?
À moins de tirer assez fort le câble RJ45 pour rapprocher google de chez
toi, les routes sont choisies à chaque noeud, selon pas mal de critères
comme la charge machine, l'encombrement de ligne, etc
Tu ne peux en général pas forcer une route particulière.
Le 16756ième jour après Epoch,
Philippe Gras écrivait:
[...]Où ai-je merdé dans ma configuration iptables ?
Merdé n'est pas vraiment le mot. Tu n'autorise que 2 ports UDP en
sortie, et traceroute va par défaut incrémenter les ports UDP à chaque
test. Donc en général ça n'a pas le droit de sortir du coup.
Essaye avec -U ou -UL pour forcer en UDP port 53
Existe-t-il un outil qui permette de choisir ses routes en fonction d'un algorithme lambda,
afin que je rapproche mon serveur de Google par exemple ?
À moins de tirer assez fort le câble RJ45 pour rapprocher google de chez
toi, les routes sont choisies à chaque noeud, selon pas mal de critères
comme la charge machine, l'encombrement de ligne, etc
Tu ne peux en général pas forcer une route particulière.
Par contre, je n'ai pas compris pourquoi ça ne pouvait pas sortir.
Pourquoi utiliser un port différent pour chacun des 9 (ou X) tests ?
Sinon, pas besoin dans mon cas de tirer le câble assez fort, il suff irait que OVH
demande gentiment à Bing, Google, Yahoo, Yandex (J'en oublie⠦) de venir se
brancher chez lui :-)
Par contre, je n'ai pas compris pourquoi ça ne pouvait pas sortir.
Pourquoi utiliser un port différent pour chacun des 9 (ou X) tests ?
Sinon, pas besoin dans mon cas de tirer le câble assez fort, il suff irait que OVH
demande gentiment à Bing, Google, Yahoo, Yandex (J'en oublie⠦) de venir se
brancher chez lui :-)
Par contre, je n'ai pas compris pourquoi ça ne pouvait pas sortir.
Pourquoi utiliser un port différent pour chacun des 9 (ou X) tests ?
Sinon, pas besoin dans mon cas de tirer le câble assez fort, il suff irait que OVH
demande gentiment à Bing, Google, Yahoo, Yandex (J'en oublie⠦) de venir se
brancher chez lui :-)
traceroute -a v6host.remote.com
traceroute -a v6host.remote.com
traceroute -a v6host.remote.com
Tu ne peux en général pas forcer une route particulière.
Tu ne peux en général pas forcer une route particulière.
Tu ne peux en général pas forcer une route particulière.
Le Tue, 17 Nov 2015 19:43:55 +0100,
Philippe Gras a écrit :traceroute -a v6host.remote.com
bonjour,
serait il possible de vérifier les versionsde traceroute installées ?
rmadison traceroute -a amd64
traceroute | 1:2.0.15-1 | oldoldstable | amd64
traceroute | 1:2.0.18-3 | oldstable | amd64
traceroute | 1:2.0.20-2+b1 | stable | amd64
traceroute | 1:2.0.21-1 | testing | amd64
traceroute | 1:2.0.21-1 | unstable | amd64
rmadison traceroute -a i386
traceroute | 1:2.0.15-1 | oldoldstable | i386
traceroute | 1:2.0.18-3 | oldstable | i386
traceroute | 1:2.0.20-2+b1 | stable | i386
traceroute | 1:2.0.21-1 | testing | i386
traceroute | 1:2.0.21-1 | unstable | i386
que donne : apt-cache policy traceroute
traceroute:
Installé : 1:2.0.21-1
Candidat : 1:2.0.21-1
Table de version :
*** 1:2.0.21-1 100
100 /var/lib/dpkg/status
1:2.0.20-2+b1 500
500 http://ftp.fr.debian.org/debian jessie/main i386 Packages
dpkg -l |awk /traceroute/ {print $2 " "$3}'
attention (l'option -a n'est plus acceptée) :
traceroute -a -I google.com
Bad option `-a' (argc 1)
autrement, traceroute est passé de man(8) à man(1) avec les changements
documentation :
http://www.linuxcertif.com/man/1/traceroute/
http://linux.die.net/man/8/traceroute
slt
bernard
Le Tue, 17 Nov 2015 19:43:55 +0100,
Philippe Gras <ph.gras@worldonline.fr> a écrit :
traceroute -a v6host.remote.com
bonjour,
serait il possible de vérifier les versionsde traceroute installées ?
rmadison traceroute -a amd64
traceroute | 1:2.0.15-1 | oldoldstable | amd64
traceroute | 1:2.0.18-3 | oldstable | amd64
traceroute | 1:2.0.20-2+b1 | stable | amd64
traceroute | 1:2.0.21-1 | testing | amd64
traceroute | 1:2.0.21-1 | unstable | amd64
rmadison traceroute -a i386
traceroute | 1:2.0.15-1 | oldoldstable | i386
traceroute | 1:2.0.18-3 | oldstable | i386
traceroute | 1:2.0.20-2+b1 | stable | i386
traceroute | 1:2.0.21-1 | testing | i386
traceroute | 1:2.0.21-1 | unstable | i386
que donne : apt-cache policy traceroute
traceroute:
Installé : 1:2.0.21-1
Candidat : 1:2.0.21-1
Table de version :
*** 1:2.0.21-1 100
100 /var/lib/dpkg/status
1:2.0.20-2+b1 500
500 http://ftp.fr.debian.org/debian jessie/main i386 Packages
dpkg -l |awk /traceroute/ {print $2 " "$3}'
attention (l'option -a n'est plus acceptée) :
traceroute -a -I google.com
Bad option `-a' (argc 1)
autrement, traceroute est passé de man(8) à man(1) avec les changements
documentation :
http://www.linuxcertif.com/man/1/traceroute/
http://linux.die.net/man/8/traceroute
slt
bernard
Le Tue, 17 Nov 2015 19:43:55 +0100,
Philippe Gras a écrit :traceroute -a v6host.remote.com
bonjour,
serait il possible de vérifier les versionsde traceroute installées ?
rmadison traceroute -a amd64
traceroute | 1:2.0.15-1 | oldoldstable | amd64
traceroute | 1:2.0.18-3 | oldstable | amd64
traceroute | 1:2.0.20-2+b1 | stable | amd64
traceroute | 1:2.0.21-1 | testing | amd64
traceroute | 1:2.0.21-1 | unstable | amd64
rmadison traceroute -a i386
traceroute | 1:2.0.15-1 | oldoldstable | i386
traceroute | 1:2.0.18-3 | oldstable | i386
traceroute | 1:2.0.20-2+b1 | stable | i386
traceroute | 1:2.0.21-1 | testing | i386
traceroute | 1:2.0.21-1 | unstable | i386
que donne : apt-cache policy traceroute
traceroute:
Installé : 1:2.0.21-1
Candidat : 1:2.0.21-1
Table de version :
*** 1:2.0.21-1 100
100 /var/lib/dpkg/status
1:2.0.20-2+b1 500
500 http://ftp.fr.debian.org/debian jessie/main i386 Packages
dpkg -l |awk /traceroute/ {print $2 " "$3}'
attention (l'option -a n'est plus acceptée) :
traceroute -a -I google.com
Bad option `-a' (argc 1)
autrement, traceroute est passé de man(8) à man(1) avec les changements
documentation :
http://www.linuxcertif.com/man/1/traceroute/
http://linux.die.net/man/8/traceroute
slt
bernard
Le 17 nov. 2015 à 23:16, Bernard Schoenacker
a écrit :
> Le Tue, 17 Nov 2015 19:43:55 +0100,
> Philippe Gras a écrit :
>
>> traceroute -a v6host.remote.com
>
> bonjour,
>
> serait il possible de vérifier les versionsde traceroute
> installées ?
>
> rmadison traceroute -a amd64
> traceroute | 1:2.0.15-1 | oldoldstable | amd64
> traceroute | 1:2.0.18-3 | oldstable | amd64
> traceroute | 1:2.0.20-2+b1 | stable | amd64
> traceroute | 1:2.0.21-1 | testing | amd64
> traceroute | 1:2.0.21-1 | unstable | amd64
>
> rmadison traceroute -a i386
> traceroute | 1:2.0.15-1 | oldoldstable | i386
> traceroute | 1:2.0.18-3 | oldstable | i386
> traceroute | 1:2.0.20-2+b1 | stable | i386
> traceroute | 1:2.0.21-1 | testing | i386
> traceroute | 1:2.0.21-1 | unstable | i386
>
>
> que donne : apt-cache policy traceroute
>
> traceroute:
> Installé : 1:2.0.21-1
> Candidat : 1:2.0.21-1
> Table de version :
> *** 1:2.0.21-1 100
> 100 /var/lib/dpkg/status
> 1:2.0.20-2+b1 500
> 500 http://ftp.fr.debian.org/debian jessie/main i386
> Packages
# apt-cache policy traceroute
traceroute:
Installé : 1:2.0.18-3
Candidat : 1:2.0.18-3
Table de version :
*** 1:2.0.18-3 0
500 http://debian.mirrors.ovh.net/debian/ wheezy/main amd64
Packages 100 /var/lib/dpkg/status
>
>
> dpkg -l |awk /traceroute/ {print $2 " "$3}'
>
> attention (l'option -a n'est plus acceptée) :
>
> traceroute -a -I google.com
> Bad option `-a' (argc 1)
Usage:
traceroute [ -46dFITnreAUV ] [ -f first_ttl ] [ -g gate,... ] [ -i
device ] [ -m max_ttl ] [ -N squeries ] [ -p port ] [ -t tos ] [ -l
flow_label ] [ -w waittime ] [ -q nqueries ] [ -s src_addr ] [ -z
sendwait ] [ --fwmark=num ] host [ packetlen ]
Quand j'ai relu l'article, je me suis aperçu que j'avais zappé des
infos, notamment en ce qui concerne l'ipv6, auquel je n'ai pas touché
sur mon serveur :
http://docs.oracle.com/cd/E37927_01/html/E36455/ipv6-admintasks-72.html
Par contre, ça fonctionne bien chez moi et ça donne juste les infos
sur les AS : $ traceroute -a -I google.com
traceroute: Warning: google.com has multiple addresses; using
74.125.133.138 traceroute to google.com (74.125.133.138), 64 hops
max, 72 byte packets 1 [AS0]
net1lo3.bsput151.puteaux.francetelecom.net (193.253.171.8) 21.279
ms 20.290 ms 18.497 ms 2 [AS0] 10.123.183.78 (10.123.183.78)
17.939 ms 17.067 ms 17.973 ms 3 [AS0]
ae20-0.ncidf104.paris.francetelecom.net (193.253.80.122) 16.968 ms
22.634 ms 17.476 ms 4 [AS0]
ae44-0.niaub102.aubervilliers.francetelecom.net (193.252.159.46)
16.959 ms 18.593 ms 17.556 ms 5 [AS0] 81.253.184.122
(81.253.184.122) 30.076 ms 30.269 ms 27.852 ms 6 [AS5511]
tengige0-11-0-8.lontr4.london.opentransit.net (193.251.131.203)
28.546 ms 28.653 ms 31.546 ms 7 [AS15169] 72.14.210.106
(72.14.210.106) 28.538 ms 28.062 ms 28.553 ms 8 [AS15169]
72.14.237.59 (72.14.237.59) 55.942 ms 29.774 ms 28.569 ms 9
[AS15169] 209.85.250.140 (209.85.250.140) 29.546 ms 29.554 ms
29.542 ms 10 [AS15169] 209.85.253.108 (209.85.253.108) 30.528 ms
29.376 ms 29.778 ms 11 [AS15169] 209.85.249.14 (209.85.249.14)
29.069 ms * 29.549 ms 12 * * * 13 [AS15169] wo-in-f138.1e100.net
(74.125.133.138) 28.522 ms 29.302 ms 28.229 ms
$ traceroute
Version 1.4a12+Darwin
Usage: traceroute [-adDeFInrSvx] [-A as_server] [-f first_ttl] [-g
gateway] [-i iface] [-M first_ttl] [-m max_ttl] [-p port] [-P proto]
[-q nqueries] [-s src_addr] [-t tos] [-w waittime] [-z pausemsecs]
host [packetlen]
Bon, j'ai regardé à qui ça correspondait sur un site :
http://bgp.he.net/AS5511
Alors, c'est très intéressant parce qu'on voit qui est connecté avec
qui et on peut en déduire un peu comment tout ça fonctionne
commercialement.
Pour le fond de ma question, en fait tout cela m'amène au protocole
BGP (cf. le nom du site).
regarde si l'un n'utiliserai pas : paris-traceroute
Je suppose que non, mais ça a l'air intéressant :
http://www.paris-traceroute.net
>
>
> autrement, traceroute est passé de man(8) à man(1) avec les
> changements
>
> documentation :
>
> http://www.linuxcertif.com/man/1/traceroute/
>
> http://linux.die.net/man/8/traceroute
>
>
> slt
> bernard
>
Le 17 nov. 2015 à 23:16, Bernard Schoenacker
<bernard.schoenacker@free.fr> a écrit :
> Le Tue, 17 Nov 2015 19:43:55 +0100,
> Philippe Gras <ph.gras@worldonline.fr> a écrit :
>
>> traceroute -a v6host.remote.com
>
> bonjour,
>
> serait il possible de vérifier les versionsde traceroute
> installées ?
>
> rmadison traceroute -a amd64
> traceroute | 1:2.0.15-1 | oldoldstable | amd64
> traceroute | 1:2.0.18-3 | oldstable | amd64
> traceroute | 1:2.0.20-2+b1 | stable | amd64
> traceroute | 1:2.0.21-1 | testing | amd64
> traceroute | 1:2.0.21-1 | unstable | amd64
>
> rmadison traceroute -a i386
> traceroute | 1:2.0.15-1 | oldoldstable | i386
> traceroute | 1:2.0.18-3 | oldstable | i386
> traceroute | 1:2.0.20-2+b1 | stable | i386
> traceroute | 1:2.0.21-1 | testing | i386
> traceroute | 1:2.0.21-1 | unstable | i386
>
>
> que donne : apt-cache policy traceroute
>
> traceroute:
> Installé : 1:2.0.21-1
> Candidat : 1:2.0.21-1
> Table de version :
> *** 1:2.0.21-1 100
> 100 /var/lib/dpkg/status
> 1:2.0.20-2+b1 500
> 500 http://ftp.fr.debian.org/debian jessie/main i386
> Packages
# apt-cache policy traceroute
traceroute:
Installé : 1:2.0.18-3
Candidat : 1:2.0.18-3
Table de version :
*** 1:2.0.18-3 0
500 http://debian.mirrors.ovh.net/debian/ wheezy/main amd64
Packages 100 /var/lib/dpkg/status
>
>
> dpkg -l |awk /traceroute/ {print $2 " "$3}'
>
> attention (l'option -a n'est plus acceptée) :
>
> traceroute -a -I google.com
> Bad option `-a' (argc 1)
Usage:
traceroute [ -46dFITnreAUV ] [ -f first_ttl ] [ -g gate,... ] [ -i
device ] [ -m max_ttl ] [ -N squeries ] [ -p port ] [ -t tos ] [ -l
flow_label ] [ -w waittime ] [ -q nqueries ] [ -s src_addr ] [ -z
sendwait ] [ --fwmark=num ] host [ packetlen ]
Quand j'ai relu l'article, je me suis aperçu que j'avais zappé des
infos, notamment en ce qui concerne l'ipv6, auquel je n'ai pas touché
sur mon serveur :
http://docs.oracle.com/cd/E37927_01/html/E36455/ipv6-admintasks-72.html
Par contre, ça fonctionne bien chez moi et ça donne juste les infos
sur les AS : $ traceroute -a -I google.com
traceroute: Warning: google.com has multiple addresses; using
74.125.133.138 traceroute to google.com (74.125.133.138), 64 hops
max, 72 byte packets 1 [AS0]
net1lo3.bsput151.puteaux.francetelecom.net (193.253.171.8) 21.279
ms 20.290 ms 18.497 ms 2 [AS0] 10.123.183.78 (10.123.183.78)
17.939 ms 17.067 ms 17.973 ms 3 [AS0]
ae20-0.ncidf104.paris.francetelecom.net (193.253.80.122) 16.968 ms
22.634 ms 17.476 ms 4 [AS0]
ae44-0.niaub102.aubervilliers.francetelecom.net (193.252.159.46)
16.959 ms 18.593 ms 17.556 ms 5 [AS0] 81.253.184.122
(81.253.184.122) 30.076 ms 30.269 ms 27.852 ms 6 [AS5511]
tengige0-11-0-8.lontr4.london.opentransit.net (193.251.131.203)
28.546 ms 28.653 ms 31.546 ms 7 [AS15169] 72.14.210.106
(72.14.210.106) 28.538 ms 28.062 ms 28.553 ms 8 [AS15169]
72.14.237.59 (72.14.237.59) 55.942 ms 29.774 ms 28.569 ms 9
[AS15169] 209.85.250.140 (209.85.250.140) 29.546 ms 29.554 ms
29.542 ms 10 [AS15169] 209.85.253.108 (209.85.253.108) 30.528 ms
29.376 ms 29.778 ms 11 [AS15169] 209.85.249.14 (209.85.249.14)
29.069 ms * 29.549 ms 12 * * * 13 [AS15169] wo-in-f138.1e100.net
(74.125.133.138) 28.522 ms 29.302 ms 28.229 ms
$ traceroute
Version 1.4a12+Darwin
Usage: traceroute [-adDeFInrSvx] [-A as_server] [-f first_ttl] [-g
gateway] [-i iface] [-M first_ttl] [-m max_ttl] [-p port] [-P proto]
[-q nqueries] [-s src_addr] [-t tos] [-w waittime] [-z pausemsecs]
host [packetlen]
Bon, j'ai regardé à qui ça correspondait sur un site :
http://bgp.he.net/AS5511
Alors, c'est très intéressant parce qu'on voit qui est connecté avec
qui et on peut en déduire un peu comment tout ça fonctionne
commercialement.
Pour le fond de ma question, en fait tout cela m'amène au protocole
BGP (cf. le nom du site).
regarde si l'un n'utiliserai pas : paris-traceroute
Je suppose que non, mais ça a l'air intéressant :
http://www.paris-traceroute.net
>
>
> autrement, traceroute est passé de man(8) à man(1) avec les
> changements
>
> documentation :
>
> http://www.linuxcertif.com/man/1/traceroute/
>
> http://linux.die.net/man/8/traceroute
>
>
> slt
> bernard
>
Le 17 nov. 2015 à 23:16, Bernard Schoenacker
a écrit :
> Le Tue, 17 Nov 2015 19:43:55 +0100,
> Philippe Gras a écrit :
>
>> traceroute -a v6host.remote.com
>
> bonjour,
>
> serait il possible de vérifier les versionsde traceroute
> installées ?
>
> rmadison traceroute -a amd64
> traceroute | 1:2.0.15-1 | oldoldstable | amd64
> traceroute | 1:2.0.18-3 | oldstable | amd64
> traceroute | 1:2.0.20-2+b1 | stable | amd64
> traceroute | 1:2.0.21-1 | testing | amd64
> traceroute | 1:2.0.21-1 | unstable | amd64
>
> rmadison traceroute -a i386
> traceroute | 1:2.0.15-1 | oldoldstable | i386
> traceroute | 1:2.0.18-3 | oldstable | i386
> traceroute | 1:2.0.20-2+b1 | stable | i386
> traceroute | 1:2.0.21-1 | testing | i386
> traceroute | 1:2.0.21-1 | unstable | i386
>
>
> que donne : apt-cache policy traceroute
>
> traceroute:
> Installé : 1:2.0.21-1
> Candidat : 1:2.0.21-1
> Table de version :
> *** 1:2.0.21-1 100
> 100 /var/lib/dpkg/status
> 1:2.0.20-2+b1 500
> 500 http://ftp.fr.debian.org/debian jessie/main i386
> Packages
# apt-cache policy traceroute
traceroute:
Installé : 1:2.0.18-3
Candidat : 1:2.0.18-3
Table de version :
*** 1:2.0.18-3 0
500 http://debian.mirrors.ovh.net/debian/ wheezy/main amd64
Packages 100 /var/lib/dpkg/status
>
>
> dpkg -l |awk /traceroute/ {print $2 " "$3}'
>
> attention (l'option -a n'est plus acceptée) :
>
> traceroute -a -I google.com
> Bad option `-a' (argc 1)
Usage:
traceroute [ -46dFITnreAUV ] [ -f first_ttl ] [ -g gate,... ] [ -i
device ] [ -m max_ttl ] [ -N squeries ] [ -p port ] [ -t tos ] [ -l
flow_label ] [ -w waittime ] [ -q nqueries ] [ -s src_addr ] [ -z
sendwait ] [ --fwmark=num ] host [ packetlen ]
Quand j'ai relu l'article, je me suis aperçu que j'avais zappé des
infos, notamment en ce qui concerne l'ipv6, auquel je n'ai pas touché
sur mon serveur :
http://docs.oracle.com/cd/E37927_01/html/E36455/ipv6-admintasks-72.html
Par contre, ça fonctionne bien chez moi et ça donne juste les infos
sur les AS : $ traceroute -a -I google.com
traceroute: Warning: google.com has multiple addresses; using
74.125.133.138 traceroute to google.com (74.125.133.138), 64 hops
max, 72 byte packets 1 [AS0]
net1lo3.bsput151.puteaux.francetelecom.net (193.253.171.8) 21.279
ms 20.290 ms 18.497 ms 2 [AS0] 10.123.183.78 (10.123.183.78)
17.939 ms 17.067 ms 17.973 ms 3 [AS0]
ae20-0.ncidf104.paris.francetelecom.net (193.253.80.122) 16.968 ms
22.634 ms 17.476 ms 4 [AS0]
ae44-0.niaub102.aubervilliers.francetelecom.net (193.252.159.46)
16.959 ms 18.593 ms 17.556 ms 5 [AS0] 81.253.184.122
(81.253.184.122) 30.076 ms 30.269 ms 27.852 ms 6 [AS5511]
tengige0-11-0-8.lontr4.london.opentransit.net (193.251.131.203)
28.546 ms 28.653 ms 31.546 ms 7 [AS15169] 72.14.210.106
(72.14.210.106) 28.538 ms 28.062 ms 28.553 ms 8 [AS15169]
72.14.237.59 (72.14.237.59) 55.942 ms 29.774 ms 28.569 ms 9
[AS15169] 209.85.250.140 (209.85.250.140) 29.546 ms 29.554 ms
29.542 ms 10 [AS15169] 209.85.253.108 (209.85.253.108) 30.528 ms
29.376 ms 29.778 ms 11 [AS15169] 209.85.249.14 (209.85.249.14)
29.069 ms * 29.549 ms 12 * * * 13 [AS15169] wo-in-f138.1e100.net
(74.125.133.138) 28.522 ms 29.302 ms 28.229 ms
$ traceroute
Version 1.4a12+Darwin
Usage: traceroute [-adDeFInrSvx] [-A as_server] [-f first_ttl] [-g
gateway] [-i iface] [-M first_ttl] [-m max_ttl] [-p port] [-P proto]
[-q nqueries] [-s src_addr] [-t tos] [-w waittime] [-z pausemsecs]
host [packetlen]
Bon, j'ai regardé à qui ça correspondait sur un site :
http://bgp.he.net/AS5511
Alors, c'est très intéressant parce qu'on voit qui est connecté avec
qui et on peut en déduire un peu comment tout ça fonctionne
commercialement.
Pour le fond de ma question, en fait tout cela m'amène au protocole
BGP (cf. le nom du site).
regarde si l'un n'utiliserai pas : paris-traceroute
Je suppose que non, mais ça a l'air intéressant :
http://www.paris-traceroute.net
>
>
> autrement, traceroute est passé de man(8) à man(1) avec les
> changements
>
> documentation :
>
> http://www.linuxcertif.com/man/1/traceroute/
>
> http://linux.die.net/man/8/traceroute
>
>
> slt
> bernard
>
Tu ne peux en général pas forcer une route particulière.
louer un serveur virtuel à Montain View? => https://cloud.google.com/
Tu ne peux en général pas forcer une route particulière.
louer un serveur virtuel à Montain View? => https://cloud.google.com/
Tu ne peux en général pas forcer une route particulière.
louer un serveur virtuel à Montain View? => https://cloud.google.com/
Le 16756ième jour après Epoch,
Philippe Gras écrivait:Par contre, je n'ai pas compris pourquoi ça ne pouvait pas sortir.
Pourquoi utiliser un port différent pour chacun des 9 (ou X) tests ?
traceroute est fait de telle sorte que par défaut, il va utiliser des
ports UDP différents à chaque fois. C'est un choix de construction.
Ton firewall n'autorise en sortie que le port 53 et le port xxx (je me
souviens plus), donc ça bloque. C'est la raison.
Sinon, pas besoin dans mon cas de tirer le câble assez fort, il suffirait que OVH
demande gentiment à Bing, Google, Yahoo, Yandex (J'en oublie ) de venir se
brancher chez lui :-)
Ben voilà, t'as qu'a leur demander ;) ... Bon courage.
D'un autre côté, au vu de tes temps de réponse, tu dois être en fibre
avec des accès gravement rapides, donc tu risques de gagner une ou deux
millisecondes de temps de réponse, tu vas pas trop le sentir.
Le 16756ième jour après Epoch,
Philippe Gras écrivait:
Par contre, je n'ai pas compris pourquoi ça ne pouvait pas sortir.
Pourquoi utiliser un port différent pour chacun des 9 (ou X) tests ?
traceroute est fait de telle sorte que par défaut, il va utiliser des
ports UDP différents à chaque fois. C'est un choix de construction.
Ton firewall n'autorise en sortie que le port 53 et le port xxx (je me
souviens plus), donc ça bloque. C'est la raison.
Sinon, pas besoin dans mon cas de tirer le câble assez fort, il suffirait que OVH
demande gentiment à Bing, Google, Yahoo, Yandex (J'en oublie ) de venir se
brancher chez lui :-)
Ben voilà, t'as qu'a leur demander ;) ... Bon courage.
D'un autre côté, au vu de tes temps de réponse, tu dois être en fibre
avec des accès gravement rapides, donc tu risques de gagner une ou deux
millisecondes de temps de réponse, tu vas pas trop le sentir.
Le 16756ième jour après Epoch,
Philippe Gras écrivait:Par contre, je n'ai pas compris pourquoi ça ne pouvait pas sortir.
Pourquoi utiliser un port différent pour chacun des 9 (ou X) tests ?
traceroute est fait de telle sorte que par défaut, il va utiliser des
ports UDP différents à chaque fois. C'est un choix de construction.
Ton firewall n'autorise en sortie que le port 53 et le port xxx (je me
souviens plus), donc ça bloque. C'est la raison.
Sinon, pas besoin dans mon cas de tirer le câble assez fort, il suffirait que OVH
demande gentiment à Bing, Google, Yahoo, Yandex (J'en oublie ) de venir se
brancher chez lui :-)
Ben voilà, t'as qu'a leur demander ;) ... Bon courage.
D'un autre côté, au vu de tes temps de réponse, tu dois être en fibre
avec des accès gravement rapides, donc tu risques de gagner une ou deux
millisecondes de temps de réponse, tu vas pas trop le sentir.