Re: [FRnOG] Re: [MISC] Message du RIPE concernant le 128.0.0.0/16

2011-12-15 Par sujet Rémi Bouhl

(attention, passage sur frnog-misc)

Le 14/12/2011 23:24, Jérôme Nicolle a écrit :


Le 14/12/2011 22:26, Stephane Bortzmeyer a écrit :

On Wed, Dec 14, 2011 at 06:18:52PM +0100,
  Fabien VINCENTfabvinc...@gmail.com  wrote
  a message of 85 lines which said:


Merci à Jérôme Nicolle pour son aide, plus de martians chez OBS en AS 3215


Réparé chez Gandi et Free également. Rien de tel qu'une bonne
gueulante sur Frnog :-)


Comme quoi on peut se plaindre des trolls, mais dire que FRnOG ne marche
plus, c'est de l'excès de mauvaise foi.




Dommage que ça ne fonctionne pas quand on rapporte et démontre des 
atteintes avérées et volontaires à la neutralité du réseau.


Rémi.


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] Message du RIPE concernant le 128.0.0.0/16

2011-12-15 Par sujet Olivier MELWIG
Bonjour,

A savoir pour ceux qui auraient zappé le bulletin d'info de Juniper suite à
la mise à jour de la liste Special Use IPv4 Addresses RFC:5735 :
Junos Software, and its documentation refer to these as martian IP
address blocks. Network operators have recently begun receiving address
assignments from address blocks that were previously, but are no longer,
reserved. Therefore, these addresses need to be removed from the list of
Junos martian address blocks.

En attendant une release Junos qui supprime des default martian routes,
Juniper recommande à ses clients de retirer les groupes d'adresses suivants
des Junos martian IP address blocks:

128.0.0.0/16
191.255.0.0/16
223.255.255.0/24
Pour cela voici les commandes à ajouter:

set routing-options martians 128.0.0.0/16 orlonger allow
set routing-options martians 191.255.0.0/16 orlonger allow
set routing-options martians 223.255.255.0/24 orlonger allow

Ces lignes doivent être incluses dans toutes les sections routing-instance.
Pour cela il vaut mieux créer un apply-group pour faciliter la répétition
de configuration:

set groups rfc-5735 routing-instances * routing-options martians
128.0.0.0/16 orlonger allow
set groups rfc-5735 routing-instances * routing-options martians
191.255.0.0/16 orlonger allow
set groups rfc-5735 routing-instances * routing-options martians
223.255.255.0/24 orlonger allow
set apply-groups rfc-5735



 Solution Junos software is being modified to remove these IP address
blocks from the martian IP address blocks. This PSN will be updated once
the detailed information of the software is available. In the mean time,
please implement the above configuration to allow these address blocks.


Cdlt,
O.


Le 14 décembre 2011 16:54, sola...@ultrawaves.net a écrit :

 On Wed, 14 Dec 2011 16:39:54 +0100, Fabien VINCENT wrote:

  En revanche, rien chez OBS.

 Eux me disent : c'est bon il est routé chez nous, le problème c'est qu'ils
 ne l'annoncent pas aux CE (toutes les autres routes que ce réseau sont
 correctement récupérées depuis le PE).

 Réponse d'OBS : faut ajouter une route statique vers le PE  Moué moué
  moi qui croyait que Completel c'était des boulets 

 *Fabien VINCENT*


 Comme l'a dit Jérome ça passe par la route par défaut.
 Du coup c'est pas annoncé, mais c'est pas bloqué non plus.
 __**__**
 __

 Business_Office_OBSping 128.0.0.1 81.80.99.xxx

 Type escape sequence to abort.
 Sending 5 100-byte ICMP echos to 128.0.0.1 from 81.80.99.xxx, timeout is 3
 seconds:
 !
 Success rate is 100 percent (5/5), round-trip min/avg/max = 23/25/27 ms

 Business_Office_OBStraceroute 128.0.0.1 81.80.99.xxx

 Type escape sequence to abort
 Tracing the route to 128.0.0.1 from 81.80.99.xxx
  1   90.81.130.121  8 ms 5 ms 8 ms
  2   81.52.2.110 11 ms 16 ms 9 ms
  3   193.253.14.29  5 ms 8 ms 5 ms
  4   193.253.82.242  7 ms 8 ms 47 ms
  5   81.253.180.30  53 ms 69 ms 13 ms
  6   81.253.180.162  22 ms 10 ms 13 ms
  7   193.251.132.25  7 ms 9 ms 11 ms
  8   193.251.254.22  15 ms 19 ms 20 ms
  9   89.149.186.245  21 ms 27 ms 72 ms
  10   77.67.72.110  21 ms 27 ms 26 ms
  11   128.0.0.1 23 ms 27 ms 27 ms
 Business_Office_OBS

 __**__**
 __

 Le mieux serait effectivement de l'annoncer au niveau des PE en BGP, à
 défaut c'est quand même routé et ça fonctionne en statique.

 Solarus



 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] Re: [MISC] Message du RIPE concernant le 128.0.0.0/16

2011-12-15 Par sujet solarus

On Thu, 15 Dec 2011 09:56:07 +0100, Rémi Bouhl wrote:

(attention, passage sur frnog-misc)

Le 14/12/2011 23:24, Jérôme Nicolle a écrit :


Le 14/12/2011 22:26, Stephane Bortzmeyer a écrit :



Réparé chez Gandi et Free également. Rien de tel qu'une bonne
gueulante sur Frnog :-)


Comme quoi on peut se plaindre des trolls, mais dire que FRnOG ne 
marche

plus, c'est de l'excès de mauvaise foi.




Dommage que ça ne fonctionne pas quand on rapporte et démontre des
atteintes avérées et volontaires à la neutralité du réseau.

Rémi.



Contrairement au débogonnage des 3 nouveau préfixes dont il a été 
question, aucune RFC, norme ou Loi n'empêche un opérateur de réseau 
d'attenter à la neutralité.
Les techniciens obéissent aux normes, à défaut, ils obéissent à leur 
direction.


Ecrit une RFC là dessus, envoie la à l'IETF et advienne que pourra. ;)


Solarus.


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] Re: [MISC] Message du RIPE concernant le 128.0.0.0/16

2011-12-15 Par sujet Martin Lathoud
Le 15 décembre 2011 12:26,  sola...@ultrawaves.net a écrit :
 Contrairement au débogonnage des 3 nouveau préfixes dont il a été question,
 aucune RFC, norme ou Loi n'empêche un opérateur de réseau d'attenter à la
 neutralité.

Quid d'une Loi qui les oblige à un peu de transparence sur le sujet?
Chez Free, ping OK vers youtube, mais débit KO. Il faudrait une RFC
qui empêche la priorisation d'ICMP histoire que ping serve encore à
quelque chose.


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] Re: [MISC] Message du RIPE concernant le 128.0.0.0/16

2011-12-15 Par sujet Solarus

On Thu, 15 Dec 2011 15:02:46 +0100, Martin Lathoud wrote:

Le 15 décembre 2011 12:26,  sola...@ultrawaves.net a écrit :
Contrairement au débogonnage des 3 nouveau préfixes dont il a été 
question,
aucune RFC, norme ou Loi n'empêche un opérateur de réseau d'attenter 
à la

neutralité.


Quid d'une Loi qui les oblige à un peu de transparence sur le sujet?
Chez Free, ping OK vers youtube, mais débit KO. Il faudrait une RFC
qui empêche la priorisation d'ICMP histoire que ping serve encore à
quelque chose.


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Tu es à coté de la plaque.

Sur la plupart des réseaux, le ping fait partie des flux dé-priorisés 
vu sa faible utilité pour l'utilisateur final, les flux priorisés étant 
plutôt le SIP et le TSE.
Surtout sur le réseau de Free où certains points droppent entre 10 et 
20% des pings. (fais un test avec mtr tu vas vite te rendre compte)


De plus, si le ping mesure la latence, il ne peut pas mesurer de façon 
fiable la qualité de transport d'une charge utile.
Enfin comme Raphaël Meunier l'a déjà dit,le chemin pour attaquer le 
frontal de Youtube n'est pas le même chemin qui distribuera les vidéos 
depuis le CDN.


Bref, si tu veux proposer une RFC pour un protocole de mesure de débit 
fiable en point à point à travers des réseaux dynamiques et asymétriques 
en BGP, surtout n'hésite pas.


Bon courage...

--
Solarus

Ultrawaves.net
Les propos tenus dans ce mail n'engagent en aucune façon mon employeur


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] Re: [MISC] Message du RIPE concernant le 128.0.0.0/16

2011-12-15 Par sujet Jérôme Nicolle
Ohla ça s'enflamme :D

Le 15 décembre 2011 15:26, Solarus sola...@ultrawaves.net a écrit :
 Tu es à coté de la plaque.

Je l'aurais pas dit comme ça...

 Sur la plupart des réseaux, le ping fait partie des flux dé-priorisés vu sa
 faible utilité pour l'utilisateur final, les flux priorisés étant plutôt le
 SIP et le TSE.

C'est pas forcement une question de priorité. Il n'y a pas de règle en
la matière, mais globalement, pour éviter les flood ICMP, c'est plutot
un rate-limite (en policer, pas en shaper) qui est employé.

 Surtout sur le réseau de Free où certains points droppent entre 10 et 20%
 des pings. (fais un test avec mtr tu vas vite te rendre compte)

c'est plutôt un delta entre mtr et l4t qui aurait du sens. Le résultat
sera variable en fonction des niveau de saturation, aussi bien sur la
bande ICMP policée que sur la globalité des liens.

 De plus, si le ping mesure la latence, il ne peut pas mesurer de façon
 fiable la qualité de transport d'une charge utile.

Surtout si le réseau différencie les flux par leurs tailles de
payload, c'était assez courant (car simple) pour que le DNS et les
requettes aillent plus vite que les transferts lourds. Mais ce n'est
plus applicable à cause de DNSSEC.

 Enfin comme Raphaël Meunier l'a déjà dit,le chemin pour attaquer le frontal
 de Youtube n'est pas le même chemin qui distribuera les vidéos depuis le
 CDN.

Ce n'est pas le chemin qui change mais bien la destination du paquet,
et donc le chemin aussi ! Une route ne change pas en fonction du type
de contenu, faut pas pousser...

 Bref, si tu veux proposer une RFC pour un protocole de mesure de débit
 fiable en point à point à travers des réseaux dynamiques et asymétriques en
 BGP, surtout n'hésite pas.

 Bon courage...

Et à base d'une heuristique issue des collectes d'inférences d'une
tempête de bits quantiques ?

-- 
Jérôme Nicolle
06 19 31 27 14


---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] Re: [MISC] Message du RIPE concernant le 128.0.0.0/16

2011-12-15 Par sujet Solarus

On Thu, 15 Dec 2011 15:54:20 +0100, Martin Lathoud wrote:

L'idée n'est pas de mesurer le débit mais la congestion, qui est
actuellement masquée par de la QoS chez Free.


Nous connaissons tous le problème. Free a de gros problème de peering 
et de trafic vers Youtube.
Preuve technique ou non, si il n'investissent pas dans du peering ou du 
trafic, la sanction sera inévitable et ils perdront des clients.Business 
is business.



On Thu, 15 Dec 2011 15:45:19 +0100, Jérôme Nicolle wrote:

Ohla ça s'enflamme :D


Désolé c'est vendredi avant l'heure. ;)

J'en profite pour changer d'adresse et poster dorénavant avec mon vrai 
nom. Internet is serious business.



--
Solarus

Ultrawaves.net
Les propos tenus dans ce mail n'engagent en aucune façon mon employeur


---
Liste de diffusion du FRnOG
http://www.frnog.org/


[MISC] Re: [FRnOG] Enfin un noeud AS112 à un point d'échange en France

2011-12-15 Par sujet Clement Cavadore
Bonjour,

Juste un petit mail pour vous annoncer que le noeud anycast parisien de
l'AS112 est désormais disponible sur l'Equinix Paris. Merci à eux pour
le raccordement !

Les routes seront disponibles via leurs route-server.

Petite nouveauté par rapport au premier raccordement d'IX: 
IPv6 y est (à priori) disponible. Nous avons en effet un sombre bug
concernant IPv6 sur notre routeur, nous empêchant pour l'instant de
faire de l'IPv6 de manière satisfaisante au FranceIX. On espère que
l'Equinix sera mieux loti de ce côté là !

Si vous souhaitez peerer avec l'AS112 (voir lien en quote pour plus
d'informations sur les services rendus par cet AS anycasté), n'hésitez
pas, c'est open-bar (en plus d'être utile): 
peering-as112 at hivane.net :-)

-- 
Clément Cavadore

On Fri, 2011-11-18 at 08:55 +0100, Stephane Bortzmeyer wrote: 
 On est vendredi, donc un message opérationnel, concret et utile : la
 France a désormais un noeud AS112 connecté à un point d'échange (il
 existe depuis des années mais n'avait qu'une faible connectivité).
 
 https://www.franceix.net/page.php?MP=franceixST=membres
 
 AS112 AS112   193.105.232.37  2001:7f8:54::37 Telecity-Courbevoie
 100M  non peering-as112 at hivane.net
 
 En plus, ce sont des gens sympas.
 
 Si vous voulez vous instruire sur l'AS112 :
 
 http://www.bortzmeyer.org/6304.html
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
 





---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [MISC] Re: Y a du débit chez FREE ?

2011-12-15 Par sujet Jérôme Benoit
On Mon, 12 Dec 2011 12:48:07 +
Raphael MAUNIER rmaun...@neotelecoms.com wrote:

 Les sites de streaming ou plutot direct download sont des gros CDN.
 
 Ce que tu vois au niveau réseau ( et en plus dans un seul sens )
 n'indique pas la réalité des flux dans la plupart des cas. Ensuite
 des algo qui merdent, ça arrive tout le temps :)

Sur, et juste pour un ISP pendant des mois. C'est fou quand même ce
qu'on peut mettre sur le dos d'un algo qui merde. Et dire qu'on dit
que je trolle ...  Mais je peux aussi être très factuel sur cette
histoire, mais la nécessité d'aller bosser va couper mon élan. 

a +.

-- 
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D


signature.asc
Description: PGP signature


Re: [FRnOG] Re: [MISC] Message du RIPE concernant le 128.0.0.0/16

2011-12-15 Par sujet Radu-Adrian Feurdean

On Thu, 15 Dec 2011 12:26:01 +0100, sola...@ultrawaves.net said:

 Les techniciens obéissent aux normes, à défaut, ils obéissent à leur 
 direction.

Merci de corriger:
Les techniciens obeissent a leur direction, et a defaut de consignes aux
normes.
 enfin pour la plupart 
En tout cas, un RFC ne paie pas le salaire


---
Liste de diffusion du FRnOG
http://www.frnog.org/


[FRnOG] [TECH] Message du RIPE concernant le 128.0.0.0/16

2011-12-15 Par sujet Michel Py
Essayant de dé-troller ce fil

 Jérôme Nicolle a écrit:
 Ce n'est pas le chemin qui change mais bien la destination du
 paquet, et donc le chemin aussi ! Une route ne change pas en
 fonction du type de contenu, faut pas pousser...

Je suis d'accord. Quand on fait du TE (Traffic Engineering, en angliche dans le 
texte) ce qu'on change c'est généralement le NEXT-HOP (*). La route elle-même 
ne change pas, ce qui change c'est qu'on a une route-map (**) qui, 
possiblement, suivant le type de contenu et la config, envoie le paquet sur une 
interface (un pair) (*) différent que celui qui aurait reçu le paquet si la 
config par défaut n'avait pas été changée.

Cette pratique est très mal vue quand on est Tier-1 (supposément, on est tous 
des pairs égaux, on n'achète pas le transit donc on n'est pas supposé (un 
anglicisme Québecois) altérer le routage egress méthode la patate chaude.

troll
Comme l'aurait dit Michel Coluche, tous les pairs BGP sont égaux, mais certains 
sont plus égaux que d'autres.
/troll

Par contre, quand on n'est pas Tier-1 et que l'on achète du transit IP à plus 
d'un fournisseur, la pratique est à la fois bien vue et mal vue, dépendant du 
fournisseur: il est évident que quand on commence à bidouiller le NEXT-HOP, 
c'est avec le but avoué de se débarrasser de la patate chaude sur les genoux du 
transit qui coûte le moins cher, à l'opposé de s'en débarrasser sur les genoux 
du fournisseur qui a l'AS-PATH le plus court.

Ce qui conduit aux situations financièrement avantageuses et techniquement 
débiles qui font que le paquet d'un même immeuble parisien avec 2 FAI 
différents va transiter par Londres et parfois par New-York.
 

(*) Au sens BGP du terme.

(**) Au sens Cisco du terme. Quelqu'un qui parle JuNOS mieux que moi merci de 
traduire route-map d'IOS en JunOS.

Michel.


---
Liste de diffusion du FRnOG
http://www.frnog.org/