company:autonomous systems

cc @louca @severo

And SeenThis is in the hall of shame :-(

Comme on peut troller @seenthis à chaque fois qu’on parle d’hébergement défaillant (https disparu, IPv6 manquant, etc), je vais réexpliquer la situation : suite au crash majeur de la dedibox de départ, seenthis est actuellement hébergé avec trois ficelles et un bout de bois sur la machine de @rezo, qui n’est pas prévue pour ça.
On ne sortira pas de cette situation foireuse sans une décision (collective ?) de doter la communauté seenthis d’un hébergement propre, et des ressources (temps et compétences) pour s’en occuper.
Ce n’est pas un appel à l’“aide” car je n’ai même pas le temps de gérer une initiative qui ne serait pas à 90% autonome.
cc @archiloque

Avec les technos de tunneling, est ce que c’est grave de ne pas supporter ipv6 à l’heure actuelle (oui c’est pas optimal, mais est ce que c’est grave ?) ?

Bon alors il faut un vhost quelque part ? Ca consomme beaucoup un #Seenthis ?

J’ai bien lu que ce n’était pas un appel à l’aide. Mais. J’héberge déjà gratuitement des choses. Je peux mettre une VM Debian pré-configurée à disposition, avec IP dédiée. A moins que ça ne nécessite impérativement une machine physique avec 1To de disque ?

Là on atteint 330 000 messages en stock, et une centaine de personnes connectées à peu près en permanence :))

Si on installe l’indexation sphinx, et le système de cache qui va bien (memcached), le calcul d’une page ne consomme pas grand chose en général en temps machine (d’ailleurs, dans le cas contraire ce serait trop lent). Donc de ce côté, ça va. La charge du serveur de @rezo n’a pas sensiblement varié, on reste autour de 1 à 2 en général.

L’indexation permanente de tout par les bots, c’est plus chaud, car il commence à y avoir un nombre de pages assez conséquent — mais là j’ai une parade assez drastique qui consiste à jeter les robots dès lors que la charge du serveur est un tout petit peu élevée.

Par contre rien ne garantit que ça ne se mette pas à grossir subitement un jour prochain… autant prévoir aussi ce qui se passe si ça se présente. Le code n’est pas super propre mais il offre déjà des possibilités pour basculer des traitements en tâche de fond sur des machines différentes, de répartir différentes choses.

En tout cas #merci à toutes les personnes qui se cachent (ou pas) derrière les rouages de #seenthis !

Et donc?

I see the same thing. Probably, the leak was filtered out by Indosat’s upstream providers and received only by one BGPmon probe. ("Detected by #peers: 1" in the message I received from BGPmon.)

However, on the NANOG mailing list, there was also a testimony that it was also seen through RIS and that one Route-Views collector, 64.25.208.71 “has seen updates that contains large amount of prefixes at time 1396464452 (04 / 02 / 14 @ 6:47:32pm UTC) with path [20225, 6939, 4761]”

OK - thanks for the feedback.

Good analysis by Renesys ▻http://www.renesys.com/2014/04/indonesia-hijacks-world

Besides disrupting Akamai themselves, this routing leak completely took out Indosat in what amounted to a self-inflicted DDoS attack

:D

some instructive graphs in that article, and a valuable conclusion.

Enterprises also need to carefully police their own routing policies and understand how the world reaches them.

so true.