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 <avache...@sisteer.com> 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 <http://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/
