[FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

2016-07-22 Par sujet gael_ajinn 
Normalement, les LB et les backend ne sont pas sur les memes serveurs, ca evite 
bien des soucis.

Il existe cependant une ruse pour mettre les LB et les backend sur les mêmes 
serveurs, mais c'est une ruse que personnellement j’évite d'utiliser.Elle fait 
appel a des scripts et a de la réécriture d'adresse IP via iptables, je trouve 
ça moyennement propre. Sans cette ruse, le risque est d'avoir des boucles ...


Le site qui présente la ruse : http://gcharriere.com/blog/?p=339

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

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 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/