date:20160212

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet gael_ajinn

Bonjour à tous,

Je reviens un petit peu sur les déboires d'OVH hier pour en comprendre. Pour 
cela j'avoue compter sur vos lumières :)

Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux saisir ce 
qu'il s'est passé.

J'ai pu lire ceci :

This leak has impacted some of our routers (6k) which could pass in TCAM 
exception. 
-> Je comprend que la mémoire TCAM était pleine et donc ça à vite posé un 
problème. Suis-je dans le vrai ?


J'ai également lu ceci :  
L'origine du problème vient d'un point de peering DECIX à Francfort où l'un des 
réseaux AS31500 nous a annoncé via le BGP "tout Internet". Conséquence, 75% de 
notre trafic a été aspiré par ce réseau, à travers Francfort.
-> Sur ce point, j'ai un peu plus de mal. Le principe même d'un routeur BGP 
n'est il pas d'annoncé l'ensemble des meilleurs routes qu'il connaient ? 
Charge, au routeur qui les reçoit de choisir ses best routes si il a plusieurs 
point de peering  Il y a forcement un point que je n'ai pas saisi.

Pourriez vous éclairer ma lanterne ?

Merci d'avance à celui qui prendra quelque minutes pour m'aider à comprendre.

Cordialement

G. A.

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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet David Ponzone

Oui.
Plus précisément, sur un point de peering comme le DECIX, tu échanges tes 
routes avec celles de ton peer.
Tes routes, c’est tes IP, et éventuellement celles de tes clients qui 
t’achètent du transit. Dans le jargon, on dit "les AS derrière toi".
Ton peer fait de même.
C’est un principe de réciprocité qui justifie la gratuité du peering, dans la 
plupart des cas. Quand les 2 peers sont disproportionnés, il est fréquent que 
le gros refuse le peering au petit, car le petit a plus à y gagner que le gros.
Il va alors souvent lui faire un devis si son métier est de vendre du transit 
(Orange, HE, etc…), soit lui dire de revenir plus tard quand il aura plus de 
trafic (Facebook, Microsoft, Akamai, …).
La seule fois où tu annonces tout internet à un peer, c’est donc justement si 
tu lui vends du transit.
Tu imagines bien que tu n’a pas envie qu’un autre gus passe par toi et tes 
transits, qui te coûtent de l’argent, gratuitement.

Dans le cas précis de l’AS 31500, il annonce en temps normal environ 117 routes 
sur un point de peering.
Et donc il s’est mis à annoncer peut-être tout Internet, donc 570 000 routes, à 
OVH.
2 problèmes possibles:
-le routeur d’OVH là-bas n’était pas capable de gérer un full-feed (inquiétant…)
et/ou
-si pour une raison X ou Y dans l’algo de sélection du best-path (un peu long à 
décrire ici, mais généralement, on met des poids forts sur les routes venant 
des peering pour les privilégier puisque pas chères), les routeurs d’OVH 
partout en France se sont mis
à envoyer une grosse partie du trafic vers le DECIX, peut-être que les liaisons 
vers Francfort n’étaient pas dimensionnées pour supporter ça (c’est même quasi 
sûr).


> Le 12 févr. 2016 à 10:19, Alexis VACHETTE  a écrit :
> 
> Bonjour,
> 
> Disons qu'en BGP il faut faire attention à ce que tu annonces.
> 
> Si tu annonces des routes que tu ne dois pas annoncer, forcément tu as un 
> risque que ça génère des choses incohérentes pour d'autres personnes.
> 
> Cordialement,
> *Alexis VACHETTE | Network and System Engineer
> * Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France
> Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90
> www.sisteer.com 
> On 12/02/2016 10:11, gael_aj...@yahoo.fr wrote:
>> Bonjour à tous,
>> 
>> Je reviens un petit peu sur les déboires d'OVH hier pour en comprendre. Pour 
>> cela j'avoue compter sur vos lumières :)
>> 
>> Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux saisir ce 
>> qu'il s'est passé.
>> 
>> J'ai pu lire ceci :
>> 
>> This leak has impacted some of our routers (6k) which could pass in TCAM 
>> exception.
>> -> Je comprend que la mémoire TCAM était pleine et donc ça à vite posé un 
>> problème. Suis-je dans le vrai ?
>> 
>> 
>> J'ai également lu ceci :
>> L'origine du problème vient d'un point de peering DECIX à Francfort où l'un 
>> des réseaux AS31500 nous a annoncé via le BGP "tout Internet". Conséquence, 
>> 75% de notre trafic a été aspiré par ce réseau, à travers Francfort.
>> -> Sur ce point, j'ai un peu plus de mal. Le principe même d'un routeur BGP 
>> n'est il pas d'annoncé l'ensemble des meilleurs routes qu'il connaient ? 
>> Charge, au routeur qui les reçoit de choisir ses best routes si il a 
>> plusieurs point de peering  Il y a forcement un point que je n'ai pas 
>> saisi.
>> 
>> Pourriez vous éclairer ma lanterne ?
>> 
>> Merci d'avance à celui qui prendra quelque minutes pour m'aider à comprendre.
>> 
>> Cordialement
>> 
>> G. A.
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet gael_ajinn

Merci beaucoup pour cette réponse très claire. J'ai compris. 
Effectivement, mon approche était plutôt celle du client à qui le transitaire 
vend du transit. Mais ce n'est pas le cas ici.

Encore merci.
Cordialement, G . A.

  De : David Ponzone 
 À : Alexis VACHETTE  
Cc : gael_aj...@yahoo.fr; "frnog-al...@frnog.org" 
 Envoyé le : Vendredi 12 février 2016 10h48
 Objet : Re: [FRnOG] [ALERT] réseau OVH en carafe ?

Oui.
Plus précisément, sur un point de peering comme le DECIX, tu échanges tes 
routes avec celles de ton peer.
Tes routes, c’est tes IP, et éventuellement celles de tes clients qui 
t’achètent du transit. Dans le jargon, on dit "les AS derrière toi".
Ton peer fait de même.
C’est un principe de réciprocité qui justifie la gratuité du peering, dans la 
plupart des cas. Quand les 2 peers sont disproportionnés, il est fréquent que 
le gros refuse le peering au petit, car le petit a plus à y gagner que le gros.
Il va alors souvent lui faire un devis si son métier est de vendre du transit 
(Orange, HE, etc…), soit lui dire de revenir plus tard quand il aura plus de 
trafic (Facebook, Microsoft, Akamai, …).
La seule fois où tu annonces tout internet à un peer, c’est donc justement si 
tu lui vends du transit.
Tu imagines bien que tu n’a pas envie qu’un autre gus passe par toi et tes 
transits, qui te coûtent de l’argent, gratuitement.

Dans le cas précis de l’AS 31500, il annonce en temps normal environ 117 routes 
sur un point de peering.
Et donc il s’est mis à annoncer peut-être tout Internet, donc 570 000 routes, à 
OVH.
2 problèmes possibles:
-le routeur d’OVH là-bas n’était pas capable de gérer un full-feed (inquiétant…)
et/ou
-si pour une raison X ou Y dans l’algo de sélection du best-path (un peu long à 
décrire ici, mais généralement, on met des poids forts sur les routes venant 
des peering pour les privilégier puisque pas chères), les routeurs d’OVH 
partout en France se sont mis
à envoyer une grosse partie du trafic vers le DECIX, peut-être que les liaisons 
vers Francfort n’étaient pas dimensionnées pour supporter ça (c’est même quasi 
sûr).

> Le 12 févr. 2016 à 10:19, Alexis VACHETTE  a écrit :
> 
> Bonjour,
> 
> Disons qu'en BGP il faut faire attention à ce que tu annonces.
> 
> Si tu annonces des routes que tu ne dois pas annoncer, forcément tu as un 
> risque que ça génère des choses incohérentes pour d'autres personnes.
> 
> Cordialement,
> *Alexis VACHETTE | Network and System Engineer
> * Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France
> Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90
> www.sisteer.com 
> On 12/02/2016 10:11, gael_aj...@yahoo.fr wrote:
>> Bonjour à tous,
>> 
>> Je reviens un petit peu sur les déboires d'OVH hier pour en comprendre. Pour 
>> cela j'avoue compter sur vos lumières :)
>> 
>> Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux saisir ce 
>> qu'il s'est passé.
>> 
>> J'ai pu lire ceci :
>> 
>> This leak has impacted some of our routers (6k) which could pass in TCAM 
>> exception.
>> -> Je comprend que la mémoire TCAM était pleine et donc ça à vite posé un 
>> problème. Suis-je dans le vrai ?
>> 
>> 
>> J'ai également lu ceci :
>> L'origine du problème vient d'un point de peering DECIX à Francfort où l'un 
>> des réseaux AS31500 nous a annoncé via le BGP "tout Internet". Conséquence, 
>> 75% de notre trafic a été aspiré par ce réseau, à travers Francfort.
>> -> Sur ce point, j'ai un peu plus de mal. Le principe même d'un routeur BGP 
>> n'est il pas d'annoncé l'ensemble des meilleurs routes qu'il connaient ? 
>> Charge, au routeur qui les reçoit de choisir ses best routes si il a 
>> plusieurs point de peering  Il y a forcement un point que je n'ai pas 
>> saisi.
>> 
>> Pourriez vous éclairer ma lanterne ?
>> 
>> Merci d'avance à celui qui prendra quelque minutes pour m'aider à comprendre.
>> 
>> Cordialement
>> 
>> G. A.
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet Edouard Chamillard

TCAM ça veut dire ternary content addressable memory.

les 'gros' routeurs l'utilisent pour faire la majorité des opérations
sur les routes parce qu'elle est bien meilleure pour ça que la combo
RAM+cache cpu classique. mais évidemment sa taille est limitée, et quand
y'a plus de place dedans, le routeur se retrouve a devoir choisir quoi
mettre dedans.

Le 12/02/2016 10:59, Alexis VACHETTE a écrit :
> David,
>
> Le full-feed j'ai l'impression mais attention je ne suis pas un expert
> BGP.
>
> Le TCAM exception d'OVH dans le task n'indique pas justement ce soucis ?
>
> J'avais cru voir que c'était une espace de stockage software sur le
> nainternet.
>
> Pour Francfort, je pense qu'il n'y a même pas de débat.
>
> Cordialement,
> **
> On 12/02/2016 10:48, David Ponzone wrote:
>> Oui.
>> Plus précisément, sur un point de peering comme le DECIX, tu échanges
>> tes routes avec celles de ton peer.
>> Tes routes, c’est tes IP, et éventuellement celles de tes clients qui
>> t’achètent du transit. Dans le jargon, on dit "les AS derrière toi".
>> Ton peer fait de même.
>> C’est un principe de réciprocité qui justifie la gratuité du peering,
>> dans la plupart des cas. Quand les 2 peers sont disproportionnés, il
>> est fréquent que le gros refuse le peering au petit, car le petit a
>> plus à y gagner que le gros.
>> Il va alors souvent lui faire un devis si son métier est de vendre du
>> transit (Orange, HE, etc…), soit lui dire de revenir plus tard quand
>> il aura plus de trafic (Facebook, Microsoft, Akamai, …).
>> La seule fois où tu annonces tout internet à un peer, c’est donc
>> justement si tu lui vends du transit.
>> Tu imagines bien que tu n’a pas envie qu’un autre gus passe par toi
>> et tes transits, qui te coûtent de l’argent, gratuitement.
>>
>> Dans le cas précis de l’AS 31500, il annonce en temps normal environ
>> 117 routes sur un point de peering.
>> Et donc il s’est mis à annoncer peut-être tout Internet, donc 570 000
>> routes, à OVH.
>> 2 problèmes possibles:
>> -le routeur d’OVH là-bas n’était pas capable de gérer un full-feed
>> (inquiétant…)
>> et/ou
>> -si pour une raison X ou Y dans l’algo de sélection du best-path (un
>> peu long à décrire ici, mais généralement, on met des poids forts sur
>> les routes venant des peering pour les privilégier puisque pas
>> chères), les routeurs d’OVH partout en France se sont mis
>> à envoyer une grosse partie du trafic vers le DECIX, peut-être que
>> les liaisons vers Francfort n’étaient pas dimensionnées pour
>> supporter ça (c’est même quasi sûr).
>>
>>
>>> Le 12 févr. 2016 à 10:19, Alexis VACHETTE  a
>>> écrit :
>>>
>>> Bonjour,
>>>
>>> Disons qu'en BGP il faut faire attention à ce que tu annonces.
>>>
>>> Si tu annonces des routes que tu ne dois pas annoncer, forcément tu
>>> as un risque que ça génère des choses incohérentes pour d'autres
>>> personnes.
>>>
>>> Cordialement,
>>> *Alexis VACHETTE | Network and System Engineer
>>> * Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France
>>> Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90
>>> www.sisteer.com 
>>> On 12/02/2016 10:11, gael_aj...@yahoo.fr wrote:
 Bonjour à tous,

 Je reviens un petit peu sur les déboires d'OVH hier pour en
 comprendre. Pour cela j'avoue compter sur vos lumières :)

 Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux
 saisir ce qu'il s'est passé.

 J'ai pu lire ceci :

 This leak has impacted some of our routers (6k) which could pass in
 TCAM exception.
 -> Je comprend que la mémoire TCAM était pleine et donc ça à vite
 posé un problème. Suis-je dans le vrai ?


 J'ai également lu ceci :
 L'origine du problème vient d'un point de peering DECIX à Francfort
 où l'un des réseaux AS31500 nous a annoncé via le BGP "tout
 Internet". Conséquence, 75% de notre trafic a été aspiré par ce
 réseau, à travers Francfort.
 -> Sur ce point, j'ai un peu plus de mal. Le principe même d'un
 routeur BGP n'est il pas d'annoncé l'ensemble des meilleurs routes
 qu'il connaient ? Charge, au routeur qui les reçoit de choisir ses
 best routes si il a plusieurs point de peering  Il y a
 forcement un point que je n'ai pas saisi.

 Pourriez vous éclairer ma lanterne ?

 Merci d'avance à celui qui prendra quelque minutes pour m'aider à
 comprendre.

 Cordialement

 G. A.

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




signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet Raphael Mazelier




Le 12/02/2016 11:11, Clement Cavadore a écrit :

Bon, on est dans les suppositions et l'hypothétique, mais j'imagine que:

D'une part, OVH possèderait plusieurs "catégories" de routeurs:
- Des routeurs fullview (type ASR), gérant la DFZ (570k routes)
- Des routeurs partial view (type 6k), en distribution, ayant les/des 
routes peerings + default (pour ce qui est transit)

D'autre part, j'imagine que suite au leak (et à l'absence de max-prefix
sur la session de peering), certains routeurs "partial view" se sont
retrouvés submergés de routes, car recevant la DFZ, alors que ce n'était
pas prévu. Du coup, dépassant leurs capacités hardware, ils sont passés
en routage software, et un redémarrage a été requis pour que la
situation se stabilise.

Bref, l'erreur aura été ici dans le cas d'OVH, d'oublier le max prefix.
Ce genre d'erreur peut arriver même aux meilleurs...

Il me semble d'ailleurs que le même genre d'incident est arrivé à Free
il y a quelques années, causé non pas par un max prefix, mais plutot par
l'ajout d'une communauté BGP erronée sur un lien de transit.




Ah zut tu m'as devancé, j'ai la même analyse :)

--
Raphael Mazelier


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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet Alexis VACHETTE


Bonjour,

Disons qu'en BGP il faut faire attention à ce que tu annonces.

Si tu annonces des routes que tu ne dois pas annoncer, forcément tu as 
un risque que ça génère des choses incohérentes pour d'autres personnes.


Cordialement,
*Alexis VACHETTE | Network and System Engineer
* Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France
Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90
www.sisteer.com 
On 12/02/2016 10:11, gael_aj...@yahoo.fr wrote:

Bonjour à tous,

Je reviens un petit peu sur les déboires d'OVH hier pour en comprendre. Pour 
cela j'avoue compter sur vos lumières :)

Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux saisir ce 
qu'il s'est passé.

J'ai pu lire ceci :

This leak has impacted some of our routers (6k) which could pass in TCAM 
exception.
-> Je comprend que la mémoire TCAM était pleine et donc ça à vite posé un 
problème. Suis-je dans le vrai ?


J'ai également lu ceci :
L'origine du problème vient d'un point de peering DECIX à Francfort où l'un des réseaux 
AS31500 nous a annoncé via le BGP "tout Internet". Conséquence, 75% de notre 
trafic a été aspiré par ce réseau, à travers Francfort.
-> Sur ce point, j'ai un peu plus de mal. Le principe même d'un routeur BGP 
n'est il pas d'annoncé l'ensemble des meilleurs routes qu'il connaient ? Charge, 
au routeur qui les reçoit de choisir ses best routes si il a plusieurs point de 
peering  Il y a forcement un point que je n'ai pas saisi.

Pourriez vous éclairer ma lanterne ?

Merci d'avance à celui qui prendra quelque minutes pour m'aider à comprendre.

Cordialement

G. A.

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



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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet Alexis VACHETTE


David,

Le full-feed j'ai l'impression mais attention je ne suis pas un expert BGP.

Le TCAM exception d'OVH dans le task n'indique pas justement ce soucis ?

J'avais cru voir que c'était une espace de stockage software sur le 
nainternet.


Pour Francfort, je pense qu'il n'y a même pas de débat.

Cordialement,
**
On 12/02/2016 10:48, David Ponzone wrote:

Oui.
Plus précisément, sur un point de peering comme le DECIX, tu échanges tes 
routes avec celles de ton peer.
Tes routes, c’est tes IP, et éventuellement celles de tes clients qui t’achètent du 
transit. Dans le jargon, on dit "les AS derrière toi".
Ton peer fait de même.
C’est un principe de réciprocité qui justifie la gratuité du peering, dans la 
plupart des cas. Quand les 2 peers sont disproportionnés, il est fréquent que 
le gros refuse le peering au petit, car le petit a plus à y gagner que le gros.
Il va alors souvent lui faire un devis si son métier est de vendre du transit 
(Orange, HE, etc…), soit lui dire de revenir plus tard quand il aura plus de 
trafic (Facebook, Microsoft, Akamai, …).
La seule fois où tu annonces tout internet à un peer, c’est donc justement si 
tu lui vends du transit.
Tu imagines bien que tu n’a pas envie qu’un autre gus passe par toi et tes 
transits, qui te coûtent de l’argent, gratuitement.

Dans le cas précis de l’AS 31500, il annonce en temps normal environ 117 routes 
sur un point de peering.
Et donc il s’est mis à annoncer peut-être tout Internet, donc 570 000 routes, à 
OVH.
2 problèmes possibles:
-le routeur d’OVH là-bas n’était pas capable de gérer un full-feed (inquiétant…)
et/ou
-si pour une raison X ou Y dans l’algo de sélection du best-path (un peu long à 
décrire ici, mais généralement, on met des poids forts sur les routes venant 
des peering pour les privilégier puisque pas chères), les routeurs d’OVH 
partout en France se sont mis
à envoyer une grosse partie du trafic vers le DECIX, peut-être que les liaisons 
vers Francfort n’étaient pas dimensionnées pour supporter ça (c’est même quasi 
sûr).



Le 12 févr. 2016 à 10:19, Alexis VACHETTE  a écrit :

Bonjour,

Disons qu'en BGP il faut faire attention à ce que tu annonces.

Si tu annonces des routes que tu ne dois pas annoncer, forcément tu as un 
risque que ça génère des choses incohérentes pour d'autres personnes.

Cordialement,
*Alexis VACHETTE | Network and System Engineer
* Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France
Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90
www.sisteer.com 
On 12/02/2016 10:11, gael_aj...@yahoo.fr wrote:

Bonjour à tous,

Je reviens un petit peu sur les déboires d'OVH hier pour en comprendre. Pour 
cela j'avoue compter sur vos lumières :)

Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux saisir ce 
qu'il s'est passé.

J'ai pu lire ceci :

This leak has impacted some of our routers (6k) which could pass in TCAM 
exception.
-> Je comprend que la mémoire TCAM était pleine et donc ça à vite posé un 
problème. Suis-je dans le vrai ?


J'ai également lu ceci :
L'origine du problème vient d'un point de peering DECIX à Francfort où l'un des réseaux 
AS31500 nous a annoncé via le BGP "tout Internet". Conséquence, 75% de notre 
trafic a été aspiré par ce réseau, à travers Francfort.
-> Sur ce point, j'ai un peu plus de mal. Le principe même d'un routeur BGP 
n'est il pas d'annoncé l'ensemble des meilleurs routes qu'il connaient ? Charge, 
au routeur qui les reçoit de choisir ses best routes si il a plusieurs point de 
peering  Il y a forcement un point que je n'ai pas saisi.

Pourriez vous éclairer ma lanterne ?

Merci d'avance à celui qui prendra quelque minutes pour m'aider à comprendre.

Cordialement

G. A.

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


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



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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet Raphael Mazelier




Le 12/02/2016 10:48, David Ponzone a écrit :


Dans le cas précis de l’AS 31500, il annonce en temps normal environ 117 routes 
sur un point de peering.
Et donc il s’est mis à annoncer peut-être tout Internet, donc 570 000 routes, à 
OVH.
2 problèmes possibles:
-le routeur d’OVH là-bas n’était pas capable de gérer un full-feed (inquiétant…)


Je ne pense pas que le routeur de peering d'ovh ou le DEC-IX est relié 
soient des 6K, en revanche si la politique de redistribution est de 
laisser passer toutes les routes provenant des peerings partout sur le 
backbone, kaboom sur les vieux equipements.



et/ou
-si pour une raison X ou Y dans l’algo de sélection du best-path (un peu long à 
décrire ici, mais généralement, on met des poids forts sur les routes venant 
des peering pour les privilégier puisque pas chères), les routeurs d’OVH 
partout en France se sont mis
à envoyer une grosse partie du trafic vers le DECIX, peut-être que les liaisons 
vers Francfort n’étaient pas dimensionnées pour supporter ça (c’est même quasi 
sûr).




Oui le classique peer qui devient transit :) (et Octave a clairement 
statué qu'il y avait eu boulette de pas mettre un max pref pour limiter 
la casse) Et oui en général la politique de sélection en sortie (en 
simplifié) est pni > peer > transit. Donc tout le trafic hors pni a été 
aspiré par le gentil peer russe, qui d'un coup a complétement saturé 
(logique).


--
Raphael Mazelier


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

RE: [FRnOG] [TECH] table mac-address en SNMP sur switch HP (comware)

2016-02-12 Par sujet Clément Guivy

Epilogue : la réponse est ici :
http://h20564.www2.hpe.com/hpsc/doc/public/display?sp4ts.oid=4174765=e
mr_na-c02602335=fr-fr=fr (pas forcément super bien indexé par les
moteurs de recherche depuis la réorganisation d'HP et de ses sites internet
!).

Donc la méthode de récupération a changé (les mac addresses sont dans les
OIDs SNMP et non plus dans les valeurs retournées) mais l'info est toujours
récupérable.

Merci à tous pour vos idées.

Clément


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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet Clement Cavadore

Bon, on est dans les suppositions et l'hypothétique, mais j'imagine que:

D'une part, OVH possèderait plusieurs "catégories" de routeurs: 
- Des routeurs fullview (type ASR), gérant la DFZ (570k routes)
- Des routeurs partial view (type 6k), en distribution, ayant les/des 
routes peerings + default (pour ce qui est transit)

D'autre part, j'imagine que suite au leak (et à l'absence de max-prefix
sur la session de peering), certains routeurs "partial view" se sont
retrouvés submergés de routes, car recevant la DFZ, alors que ce n'était
pas prévu. Du coup, dépassant leurs capacités hardware, ils sont passés
en routage software, et un redémarrage a été requis pour que la
situation se stabilise.

Bref, l'erreur aura été ici dans le cas d'OVH, d'oublier le max prefix.
Ce genre d'erreur peut arriver même aux meilleurs...

Il me semble d'ailleurs que le même genre d'incident est arrivé à Free
il y a quelques années, causé non pas par un max prefix, mais plutot par
l'ajout d'une communauté BGP erronée sur un lien de transit.


Bref, la vie des réseaux...


On Fri, 2016-02-12 at 10:48 +0100, David Ponzone wrote:
> Oui.
> Plus précisément, sur un point de peering comme le DECIX, tu échanges tes 
> routes avec celles de ton peer.
> Tes routes, c’est tes IP, et éventuellement celles de tes clients qui 
> t’achètent du transit. Dans le jargon, on dit "les AS derrière toi".
> Ton peer fait de même.
> C’est un principe de réciprocité qui justifie la gratuité du peering, dans la 
> plupart des cas. Quand les 2 peers sont disproportionnés, il est fréquent que 
> le gros refuse le peering au petit, car le petit a plus à y gagner que le 
> gros.
> Il va alors souvent lui faire un devis si son métier est de vendre du transit 
> (Orange, HE, etc…), soit lui dire de revenir plus tard quand il aura plus de 
> trafic (Facebook, Microsoft, Akamai, …).
> La seule fois où tu annonces tout internet à un peer, c’est donc justement si 
> tu lui vends du transit.
> Tu imagines bien que tu n’a pas envie qu’un autre gus passe par toi et tes 
> transits, qui te coûtent de l’argent, gratuitement.
> 
> Dans le cas précis de l’AS 31500, il annonce en temps normal environ 117 
> routes sur un point de peering.
> Et donc il s’est mis à annoncer peut-être tout Internet, donc 570 000 routes, 
> à OVH.
> 2 problèmes possibles:
> -le routeur d’OVH là-bas n’était pas capable de gérer un full-feed 
> (inquiétant…)
> et/ou
> -si pour une raison X ou Y dans l’algo de sélection du best-path (un peu long 
> à décrire ici, mais généralement, on met des poids forts sur les routes 
> venant des peering pour les privilégier puisque pas chères), les routeurs 
> d’OVH partout en France se sont mis
> à envoyer une grosse partie du trafic vers le DECIX, peut-être que les 
> liaisons vers Francfort n’étaient pas dimensionnées pour supporter ça (c’est 
> même quasi sûr).
> 
> 
> > Le 12 févr. 2016 à 10:19, Alexis VACHETTE  a écrit :
> > 
> > Bonjour,
> > 
> > Disons qu'en BGP il faut faire attention à ce que tu annonces.
> > 
> > Si tu annonces des routes que tu ne dois pas annoncer, forcément tu as un 
> > risque que ça génère des choses incohérentes pour d'autres personnes.
> > 
> > Cordialement,
> > *Alexis VACHETTE | Network and System Engineer
> > * Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France
> > Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90
> > www.sisteer.com 
> > On 12/02/2016 10:11, gael_aj...@yahoo.fr wrote:
> >> Bonjour à tous,
> >> 
> >> Je reviens un petit peu sur les déboires d'OVH hier pour en comprendre. 
> >> Pour cela j'avoue compter sur vos lumières :)
> >> 
> >> Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux saisir ce 
> >> qu'il s'est passé.
> >> 
> >> J'ai pu lire ceci :
> >> 
> >> This leak has impacted some of our routers (6k) which could pass in TCAM 
> >> exception.
> >> -> Je comprend que la mémoire TCAM était pleine et donc ça à vite posé un 
> >> problème. Suis-je dans le vrai ?
> >> 
> >> 
> >> J'ai également lu ceci :
> >> L'origine du problème vient d'un point de peering DECIX à Francfort où 
> >> l'un des réseaux AS31500 nous a annoncé via le BGP "tout Internet". 
> >> Conséquence, 75% de notre trafic a été aspiré par ce réseau, à travers 
> >> Francfort.
> >> -> Sur ce point, j'ai un peu plus de mal. Le principe même d'un routeur 
> >> BGP n'est il pas d'annoncé l'ensemble des meilleurs routes qu'il connaient 
> >> ? Charge, au routeur qui les reçoit de choisir ses best routes si il a 
> >> plusieurs point de peering  Il y a forcement un point que je n'ai pas 
> >> saisi.
> >> 
> >> Pourriez vous éclairer ma lanterne ?
> >> 
> >> Merci d'avance à celui qui prendra quelque minutes pour m'aider à 
> >> comprendre.
> >> 
> >> Cordialement
> >> 
> >> G. A.
> >> 
> >> ---
> >> Liste de diffusion du FRnOG
> >> http://www.frnog.org/
> > 
> > 
> > ---
> > Liste de diffusion du

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet Florent Rivoire

2016-02-12 11:16 GMT+01:00 Raphael Mazelier :
> Je ne pense pas que le routeur de peering d'ovh ou le DEC-IX est relié
> soient des 6K [...]

OVH communique indirectement sur l'architecture et les équipements
utilisés via la page de weathermap :
http://weathermap.ovh.net/#frankfurt

On voit qu'il y a actuellement :
- 2 ASR-9k : fra-1-a9 et fra-5-a9
- 2 Nexus 7k : fra-1-n7 et fra-5-n7

De plus, le schéma semble confirmer la configuration "router on a
stick" qui est décrite dans une tache "travaux" pour un autre POP
assez proche :
http://travaux.ovh.net/?do=details=13495

-- 
Florent


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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet Fabien VINCENT

Le 2016-02-12 11:11, Clement Cavadore a écrit :
Bon, on est dans les suppositions et l'hypothétique, mais j'imagine 
que:

D'une part, OVH possèderait plusieurs "catégories" de routeurs:
- Des routeurs fullview (type ASR), gérant la DFZ (570k routes)
- Des routeurs partial view (type 6k), en distribution, ayant les/des
routes peerings + default (pour ce qui est transit)

D'autre part, j'imagine que suite au leak (et à l'absence de max-prefix
sur la session de peering), certains routeurs "partial view" se sont
retrouvés submergés de routes, car recevant la DFZ, alors que ce 
n'était

pas prévu. Du coup, dépassant leurs capacités hardware, ils sont passés
en routage software, et un redémarrage a été requis pour que la
situation se stabilise.

Bref, l'erreur aura été ici dans le cas d'OVH, d'oublier le max prefix.
Ce genre d'erreur peut arriver même aux meilleurs...

Il me semble d'ailleurs que le même genre d'incident est arrivé à Free
il y a quelques années, causé non pas par un max prefix, mais plutot 
par

l'ajout d'une communauté BGP erronée sur un lien de transit.

Bref, la vie des réseaux...

Pas mieux, merci ;)

C'est pas le max-prefix pas configuré (il y était bien), mais une 
subtilité derrière qui a été répliquée par erreur.

Erreur + Erreur.

On Fri, 2016-02-12 at 10:48 +0100, David Ponzone wrote:

Oui.
Plus précisément, sur un point de peering comme le DECIX, tu échanges 
tes routes avec celles de ton peer.
Tes routes, c’est tes IP, et éventuellement celles de tes clients qui 
t’achètent du transit. Dans le jargon, on dit "les AS derrière toi".

Ton peer fait de même.
C’est un principe de réciprocité qui justifie la gratuité du peering, 
dans la plupart des cas. Quand les 2 peers sont disproportionnés, il 
est fréquent que le gros refuse le peering au petit, car le petit a 
plus à y gagner que le gros.
Il va alors souvent lui faire un devis si son métier est de vendre du 
transit (Orange, HE, etc…), soit lui dire de revenir plus tard quand 
il aura plus de trafic (Facebook, Microsoft, Akamai, …).
La seule fois où tu annonces tout internet à un peer, c’est donc 
justement si tu lui vends du transit.
Tu imagines bien que tu n’a pas envie qu’un autre gus passe par toi et 
tes transits, qui te coûtent de l’argent, gratuitement.

Dans le cas précis de l’AS 31500, il annonce en temps normal environ 
117 routes sur un point de peering.
Et donc il s’est mis à annoncer peut-être tout Internet, donc 570 000 
routes, à OVH.

2 problèmes possibles:
-le routeur d’OVH là-bas n’était pas capable de gérer un full-feed 
(inquiétant…)

et/ou
-si pour une raison X ou Y dans l’algo de sélection du best-path (un 
peu long à décrire ici, mais généralement, on met des poids forts sur 
les routes venant des peering pour les privilégier puisque pas 
chères), les routeurs d’OVH partout en France se sont mis
à envoyer une grosse partie du trafic vers le DECIX, peut-être que les 
liaisons vers Francfort n’étaient pas dimensionnées pour supporter ça 
(c’est même quasi sûr).

> Le 12 févr. 2016 à 10:19, Alexis VACHETTE  a écrit :
>
> Bonjour,
>
> Disons qu'en BGP il faut faire attention à ce que tu annonces.
>
> Si tu annonces des routes que tu ne dois pas annoncer, forcément tu as un 
risque que ça génère des choses incohérentes pour d'autres personnes.
>
> Cordialement,
> *Alexis VACHETTE | Network and System Engineer
> * Sisteer France: 43 rue Pierre Valette, 92240 Malakoff – France
> Direct line: +33 1 70 95 51 19 | Fax: +33 1 70 95 50 90
> www.sisteer.com 
> On 12/02/2016 10:11, gael_aj...@yahoo.fr wrote:
>> Bonjour à tous,
>>
>> Je reviens un petit peu sur les déboires d'OVH hier pour en comprendre. Pour 
cela j'avoue compter sur vos lumières :)
>>
>> Pour moi, le BGP c'est encore un peu nouveau, et j'aimerai mieux saisir ce 
qu'il s'est passé.
>>
>> J'ai pu lire ceci :
>>
>> This leak has impacted some of our routers (6k) which could pass in TCAM 
exception.
>> -> Je comprend que la mémoire TCAM était pleine et donc ça à vite posé un 
problème. Suis-je dans le vrai ?
>>
>>
>> J'ai également lu ceci :
>> L'origine du problème vient d'un point de peering DECIX à Francfort où l'un des 
réseaux AS31500 nous a annoncé via le BGP "tout Internet". Conséquence, 75% de notre 
trafic a été aspiré par ce réseau, à travers Francfort.
>> -> Sur ce point, j'ai un peu plus de mal. Le principe même d'un routeur BGP 
n'est il pas d'annoncé l'ensemble des meilleurs routes qu'il connaient ? Charge, au 
routeur qui les reçoit de choisir ses best routes si il a plusieurs point de peering 
 Il y a forcement un point que je n'ai pas saisi.
>>
>> Pourriez vous éclairer ma lanterne ?
>>
>> Merci d'avance à celui qui prendra quelque minutes pour m'aider à comprendre.
>>
>> Cordialement
>>
>> G. A.
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
>

[FRnOG] [MISC] Comment communiquer sur un incident ?

2016-02-12 Par sujet Jérôme Nicolle

Bonjour à tous, bon vendredi,

Une question me turlupine depuis que j'ai croisé un tweet de blogueur
pissant de l'essence sur un OVH brièvement en flamme.

Doit-on avertir tous nos clients de chaque incident, y compris ceux qui
ne se rendent compte de rien, que hypothétiquement leur service aurait
pu être légèrement impacté par un incident pas forcement grave ?

Doit-on, même en temps que low-coster, prendre la peine d'envoyer un
mail à 15M clients dès que l'infra est de nouveau capable de le faire,
histoire d'assurer au support technique une nuit blanche d'appels de
clients mécontents alors que pas impactés (ou en tout cas qui n'auraient
rien vu sans le mail) ?

Dans ce cas, quel est le délai acceptable de traitement des demandes de
remboursements et remises, et quels sont les bons montants ? Comment
comptabiliser les milliers d'heures de travail que ça peut représenter
en plus de la perte financière ?

Enfin, est-ce bien professionnel d'être déjà transparent et communiquer
en live le statut des interventions en cours, et de surtout préciser
l'adresse dans les docs de bienvenue que les clients ne lisent pas ?

Merci d'avance pour vos avis !

Bien cordialement,

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


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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet David Ponzone

Euh jamais fait de boulette à mettre par terre le plus gros hébergeur français 
:)
Après, on peut vérifier s’ils ont le même problème de max-pref sur les IX 
français, mais 2 dans la journée, ça va les fâcher, et y aura un licenciement 
ce coup-ci :)

> Le 12 févr. 2016 à 18:00, Michel Py  a 
> écrit :
> 
>> Clement Cavadore a écrit :
>> Bref, la vie des réseaux...
> 
> Oui, c'est pas la première fois que çà arrive, et probablement pas la 
> dernière. Bon, qui ici n'a jamais fait une boulette ?
> 
>> Fabien VINCENT a écrit :
>> C'est pas le max-prefix pas configuré (il y était bien), mais une subtilité 
>> derrière qui a été répliquée par erreur.
> 
> Tu as des détails ?
> 
> Du coté Russe, c'est clair que quelqu'un a foiré une route-map ou une 
> prefix-list, ou une communauté, ce genre do chose. Du coté OVH, je serais 
> curieux de savoir quelle est la config qui a permis d'accepter les préfixes 
> malgré la présence du max-prefix.
> 
> Michel.
> 


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

RE: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet Michel Py

> Clement Cavadore a écrit :
> Bref, la vie des réseaux...

Oui, c'est pas la première fois que çà arrive, et probablement pas la dernière. 
Bon, qui ici n'a jamais fait une boulette ?

> Fabien VINCENT a écrit :
> C'est pas le max-prefix pas configuré (il y était bien), mais une subtilité 
> derrière qui a été répliquée par erreur.

Tu as des détails ?

Du coté Russe, c'est clair que quelqu'un a foiré une route-map ou une 
prefix-list, ou une communauté, ce genre do chose. Du coté OVH, je serais 
curieux de savoir quelle est la config qui a permis d'accepter les préfixes 
malgré la présence du max-prefix.

Michel.


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

Re: [FRnOG] [MISC] Comment communiquer sur un incident ?

2016-02-12 Par sujet Jonathan Leroy

Le 12 février 2016 à 15:33, Jérôme Nicolle  a écrit :
> Bonjour à tous, bon vendredi,
>
> Une question me turlupine depuis que j'ai croisé un tweet de blogueur
> pissant de l'essence sur un OVH brièvement en flamme.

Des noms ! Des noms ! (où un lien)


> Doit-on avertir tous nos clients de chaque incident, y compris ceux qui
> ne se rendent compte de rien, que hypothétiquement leur service aurait
> pu être légèrement impacté par un incident pas forcement grave ?
>
> Doit-on, même en temps que low-coster, prendre la peine d'envoyer un
> mail à 15M clients dès que l'infra est de nouveau capable de le faire,
> histoire d'assurer au support technique une nuit blanche d'appels de
> clients mécontents alors que pas impactés (ou en tout cas qui n'auraient
> rien vu sans le mail) ?

Que ce soit en tant que client ou que prestataire, je préfère la
solution "passive" (un site status.* avec un flux RSS) à la solution
"active" (mail envoyé à toute la base au moindre problème).

En tant que client, je m'abonne aux flux RSS des services qui sont
critiques pour moi. Par exemple la section "Reseau Internet et Baies"
sur http://travaux.ovh.net/.
En tant que prestataire, je publie tout et libre à mes clients de
s'abonner à tel ou tel flux RSS concernant tel ou tel service.


> Dans ce cas, quel est le délai acceptable de traitement des demandes de
> remboursements et remises, et quels sont les bons montants ?

Ça dépend©. Déjà il faut prendre en compte le contrat auquel à
souscrit le client, la criticité du service, le SLA...

De manière générale, en dehors de tout SLA, c'est (tarif mensuel / 30
/ 24) * nombre d'heures d'indispo. Donc environ rien.
Sauf quand tu fais du cloud® et que tes concurrents, eux, sortent le
chéquier en cas de pépin. Dans ce cas pas le choix, faut t'aligner et
rembourser le mois.

> Comment
> comptabiliser les milliers d'heures de travail que ça peut représenter
> en plus de la perte financière ?

Pour quoi faire ?

> Enfin, est-ce bien professionnel d'être déjà transparent et communiquer
> en live le statut des interventions en cours, et de surtout préciser
> l'adresse dans les docs de bienvenue que les clients ne lisent pas ?

Oui.

-- 
Jonathan Leroy.


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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet Bensay 1

Bon c'est Trolldi,

À remettre à demain donc David ? ;)

Benjamin

> Le 12 févr. 2016 à 18:04, David Ponzone  a écrit :
> 
> Euh jamais fait de boulette à mettre par terre le plus gros hébergeur 
> français :)
> Après, on peut vérifier s’ils ont le même problème de max-pref sur les IX 
> français, mais 2 dans la journée, ça va les fâcher, et y aura un licenciement 
> ce coup-ci :)
> 
>>> Le 12 févr. 2016 à 18:00, Michel Py  a 
>>> écrit :
>>> 
>>> Clement Cavadore a écrit :
>>> Bref, la vie des réseaux...
>> 
>> Oui, c'est pas la première fois que çà arrive, et probablement pas la 
>> dernière. Bon, qui ici n'a jamais fait une boulette ?
>> 
>>> Fabien VINCENT a écrit :
>>> C'est pas le max-prefix pas configuré (il y était bien), mais une subtilité 
>>> derrière qui a été répliquée par erreur.
>> 
>> Tu as des détails ?
>> 
>> Du coté Russe, c'est clair que quelqu'un a foiré une route-map ou une 
>> prefix-list, ou une communauté, ce genre do chose. Du coté OVH, je serais 
>> curieux de savoir quelle est la config qui a permis d'accepter les préfixes 
>> malgré la présence du max-prefix.
>> 
>> Michel.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

2016-02-12 Par sujet David Ponzone

:)

Bon WE


> Le 12 févr. 2016 à 19:36, Bensay 1  a écrit :
> 
> Bon c'est Trolldi,
> 
> À remettre à demain donc David ? ;)
> 
> Benjamin
> 
>> Le 12 févr. 2016 à 18:04, David Ponzone  a écrit :
>> 
>> Euh jamais fait de boulette à mettre par terre le plus gros hébergeur 
>> français :)
>> Après, on peut vérifier s’ils ont le même problème de max-pref sur les IX 
>> français, mais 2 dans la journée, ça va les fâcher, et y aura un 
>> licenciement ce coup-ci :)
>> 
 Le 12 févr. 2016 à 18:00, Michel Py  a 
 écrit :
 
 Clement Cavadore a écrit :
 Bref, la vie des réseaux...
>>> 
>>> Oui, c'est pas la première fois que çà arrive, et probablement pas la 
>>> dernière. Bon, qui ici n'a jamais fait une boulette ?
>>> 
 Fabien VINCENT a écrit :
 C'est pas le max-prefix pas configuré (il y était bien), mais une 
 subtilité derrière qui a été répliquée par erreur.
>>> 
>>> Tu as des détails ?
>>> 
>>> Du coté Russe, c'est clair que quelqu'un a foiré une route-map ou une 
>>> prefix-list, ou une communauté, ce genre do chose. Du coté OVH, je serais 
>>> curieux de savoir quelle est la config qui a permis d'accepter les préfixes 
>>> malgré la présence du max-prefix.
>>> 
>>> Michel.
>> 
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/


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

[FRnOG] [TECH] Tarif PI vs PA

2016-02-12 Par sujet Eric ROLLAND

 
Bonsoir à toutes et tous,
En phase de croissance et acquisition, on sepose la question d'une
valorisation /24 en PI ou /22 PAsous-jacent à l’acquisition du LIR.
Hormis une réponse qui pointe vers un broker, est ce que certains ont
fait des acquisitions récemmentet dans quelles conditions pour un /22
minimum.
Merci d'avance pour vos retourset bon WE à toutes et tous.

PS: Post non tagué en [BIZ] par ce que c'est pas du business ;-)
Cordialement,
Eric ROLLAND
AS42929 - RE515-RIPE


*Artefact communication interactive* | Bat. Artechnopole - 3 rue des
Frères Goncourt - 19100 BRIVE | Tel 0555 17 29 29 | Fax 0957 33 00 33
SARL au capital de 50.000 Euros - RCS BRIVE 444 110 936 | NAF 7311Z |
TVA Intracom FR87444110936 | ORG-ARTE2-RIPE - PGPKEY-32DDEF07
Info réseau : @NocArtefact  - NOC
Artewan 

*artefact
*Communication Interactive
www.artefact.fr *artewan*
Opérateur de réseaux et de services
www.artewan.fr   *arteone*
Datacenter, Informatique & Services IT
www.arteone.fr 


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

Re: [FRnOG] [TECH] Tarif PI vs PA

2016-02-12 Par sujet David Ponzone

Il me semble que la valeur d’un /22 PA est environ à 6k€ en ce moment.
Il y a une discussion sur la liste des membres du RIPE en ce moment à propos de 
l’attribution de /22 supplémentaires à un LIR après la première allocation, et 
le sujet de la valeur d’un /22 est évidemment abordée.


> Le 12 févr. 2016 à 20:32, Eric ROLLAND  a écrit :
> 
> 
> Bonsoir à toutes et tous,
> En phase de croissance et acquisition, on sepose la question d'une
> valorisation /24 en PI ou /22 PAsous-jacent à l’acquisition du LIR.
> Hormis une réponse qui pointe vers un broker, est ce que certains ont
> fait des acquisitions récemmentet dans quelles conditions pour un /22
> minimum.
> Merci d'avance pour vos retourset bon WE à toutes et tous.
> 
> PS: Post non tagué en [BIZ] par ce que c'est pas du business ;-)
> Cordialement,
> Eric ROLLAND
> AS42929 - RE515-RIPE
> 
> 
> *Artefact communication interactive* | Bat. Artechnopole - 3 rue des
> Frères Goncourt - 19100 BRIVE | Tel 0555 17 29 29 | Fax 0957 33 00 33
> SARL au capital de 50.000 Euros - RCS BRIVE 444 110 936 | NAF 7311Z |
> TVA Intracom FR87444110936 | ORG-ARTE2-RIPE - PGPKEY-32DDEF07
> Info réseau : @NocArtefact  - NOC
> Artewan 
> 
> *artefact
> *Communication Interactive
> www.artefact.fr   *artewan*
> Opérateur de réseaux et de services
> www.artewan.fr *arteone*
> Datacenter, Informatique & Services IT
> www.arteone.fr 
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Tarif PI vs PA

2016-02-12 Par sujet Radu-Adrian Feurdean

On Fri, Feb 12, 2016, at 21:02, David Ponzone wrote:
> Il y a une discussion sur la liste des membres du RIPE en ce moment à
> propos de l’attribution de /22 supplémentaires à un LIR après la première

Vous estes bien gentils de regarder mais jamais contribuer (sur apwg).
Sur une dizaine de personnes qui m'ont dit orelement autour d'une biere
"Oui ! C'est genial vas-y !" je n'ai pas vu un seul s'exprimer sur la
liste.

Plus serieusement, sauf changement inattendu, faut oublier les /22
supplementaires. Le consensus semble etre "allez sur le marche" (qui
varie entre 4 et 12 EUR/IP, avec une volatilite assez extreme).

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

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

RE: [FRnOG] [TECH] table mac-address en SNMP sur switch HP (comware)

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

[FRnOG] [MISC] Comment communiquer sur un incident ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

RE: [FRnOG] [ALERT] réseau OVH en carafe ?

Re: [FRnOG] [MISC] Comment communiquer sur un incident ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

Re: [FRnOG] [ALERT] réseau OVH en carafe ?

[FRnOG] [TECH] Tarif PI vs PA

Re: [FRnOG] [TECH] Tarif PI vs PA

Re: [FRnOG] [TECH] Tarif PI vs PA

21 matches

Site Navigation

Mail list logo

Footer information