[FRnOG] RFC 5963: IPv6 Deployment in Internet Exchange Points

[Stephane Bortzmeyer]

http://www.bortzmeyer.org/5963.html



Auteur(s) du RFC: R. Gagliano (Cisco)





Le fonctionnement de l'Internet aujourd'hui repose largement sur des 
points d'échange où les différents opérateurs se connectent pour 
échanger du trafic IP. Le point d'échange typique fournit un réseau 
Ethernet où chacun connecte son routeur, et alloue des adresses IP pour 
configurer ces dits routeurs, qui vont ensuite établir des liens BGP 
entre eux. La principale conclusion de ce nouveau RFC est que la très 
grande majorité des points d'échange fournissant un service de couche 
2, le fait d'utiliser IPv6 au lieu d'IPv4 ne change pas grand'chose à 
la gestion du point d'échange.

La section 1 résume l'état actuel du monde des points d'échange. 
Presque toujours, le service rendu est une connexion de niveau 2, 
quasiment uniquement en Ethernet. Le principal service de niveau 3 
rendu par les gérants du point d'échange est l'attribution d'adresses 
IP aux routeurs des opérateurs. Curieusement, ce service n'est pas 
mentionné dès la section 1, qui cite à la place des fonctions moins 
vitales comme le serveur de routes ou bien les statistiques 
(http://www.ams-ix.net/statistics/) (globales ou bien par protocole 
(http://www.ams-ix.net/sflow-stats/ipv6/)).

La section 2 du RFC passe ensuite aux questions liées à l'interface 
entre la couche de liaison et la couche réseau. IPv6 sur Ethernet doit 
se faire selon le RFC 2464. Le commutateur Ethernet lui-même, 
travaillant en couche 2, n'a rien de spécial à faire. On peut se poser 
la question de séparer les trafics v4 et v6. Cela peut se mettre en 
œuvre avec deux ports physiques sur le commutateur ou bien avec deux 
VLAN séparés. Mais cette séparation n'est pas indispensable. (Le faire 
avec des ports séparés consomme des ressources matérielles sur le 
routeur et le faire avec des VLAN impose aux routeurs de gérer 802.1Q.) 
Elle complique la configuration mais peut simplifier certaines 
fonctions comme les statistiques.

La section 3, plutôt descriptive que normative, décrit le mécanisme 
d'adressage à un point d'échange. Chaque RIR a sa politique 
(http://www.nro.net/documents/comp-pol.html#3-4-2) pour l'allocation 
d'adresses IPv6 aux points d'échange. Ce sont typiquement des préfixes 
de longueur /48 qui sont alloués. Ces adresses ont besoin d'être 
résolvables en nom par le DNS et de pouvoir être trouvées dans la base 
des RIR via whois. Donc, un point d'échange n'utilise pas les ULA du 
RFC 4193. (Voyez par exemple les adresses IP allouées sur FranceIX 
(http://france-ix.fr/wp-content/uploads/2009/11/Connected-partners-2010-
08-16.pdf).)

Par raport à un réseau local IPv6 typique, il faut aussi noter que 
l'autoconfiguration des adresses pa l'envoi de RA ("Router 
Advertisment") n'est typiquement pas utilisée. La configuration des 
routeurs est faite manuellement puisque, de toute façon, la 
configuration de BGP dépend de l'adresse. Puisqu'on n'utilise pas 
l'autoconfiguration, que mettre dans les 64 bits les plus à droite ? En 
IPv4, les routeurs à un point d'échange sont en général numérotés 
séquentiellement mais l'espace d'adressage bien plus grand d'IPv6 
permet des plans d'adressage plus informatifs. Il existe plusieurs 
mécanismes acceptables :
* Encoder le numéro d'AS en décimal dans les 64 bits. Ainsi, si le 
point d'échange utilise le préfixe 2001:db8:f00f::/64 et qu'un 
opérateur connecté a le numéro d'AS 64496, son adresse IP sera 
2001:db8:f00f::6:4496:1 (le 1 tout à fait à droite vient de la 
réservation des 16 derniers bits pour mettre plusieurs routeurs par 
opérateur connecté, si nécessaire).
* Certains préfèrent l'hexadécimal, moins lisible mais plus compact, 
donc ici 2001:db8:f00f::fbf0:1.
* Une autre méthode est de dériver l'adresse IPv6 de la v4. donc un 
routeur qui aurait 192.0.2.123 en v4 recevra 2001:db8:f00f::123 en v6 
(ce n'est qu'un exemple, le RFC en cite un autre, qui permet des points 
d'échange de plus de 256 routeurs, contrairement à mon choix de ne 
garder que le dernier octet).
* etc (d'autres méthodes sont possibles).
Ces adresses IP du point d'échange doivent-elles être routées 
globalement ? Le débat a toujours fait rage pour IPv4 et n'est pas 
différent ici. Les adresses routées globalement facilitent la 
configuration et le déboguage mais peuvent rendre le point d'échange 
plus vulnérable à certaines attaques. Si on ne route pas globalement 
ces adresses, les participants au point d'échange peuvent toujours le 
faire eux-même dans leur réseau, en prenant soin d'utiliser des 
méthodes comme la communauté no-export de BGP, pour éviter que les 
annonces des routes vers le point d'échange ne se propagent trop loin. 
Enfin, le point d'échange a aussi des services publics (pages Web, 
serveur DNS, serveurs NTP, etc) et ceux-ci doivent évidemment être 
installés sur des adresses routables, que ce soit dans le même préfixe 
que celles des routeurs des participants ou bien dans un pré

Re: [FRnOG] RFC 5963: IPv6 Deployment in Internet Exchange Points

[michel hostettler]

Bonjour Stéphane,

Merci beaucoup pour cet excellent résumé de la RFC 5963, qu'il me faut 
probablement relire une autre fois, avec plus d'acuité.


Je rebondis sur cette phrase extraite de son contexte :

"...La principale conclusion de ce nouveau RFC est que la très grande 
majorité des points d'échange fournissant un service de couche 2, le 
fait d'utiliser IPv6 au lieu d'IPv4 ne change pas grand'chose à la 
gestion du point d'échange...".


Est-ce à dire que si l'Internet se transforme en un immense réseau 
Ethernet opérateur, l'intérêt d'IPv6 est fortement réduit ? Ce réseau 
pourrait même ne transporter que des adresses privées IPv4.


Cordialement,
Michel Hostettler

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

[FRnOG] Incident majeur, WTF happened ?

[Jérôme Nicolle]

Bonjour,

On en a causé sur l'IRC, le sujet a été abordé sur NANOG, mais
bizarrement, on a rien vu passer ici.

Que c'est il passé vendredi 27 de 11h15 à 12h30 ?

Ce qu'on a vu :
- Free a été coupé du monde pendant 30 à 45 minutes
- On m'a rapporté la même chose sur OVH et Renater
- Un creux de 100Gbps a été constaté sur les stats de l'AMS-IX
(quelqu'un a le screenshot ?)

Ce qui s'en est dit :
- Le RIPE a testé des annonces particulières qui auraient levé un bug
dans certaines implémentations de BGP
- Les principaux routeurs touchés sont des cisco
- Le facteur déclenchant serait la présence de confédérations BGP
(mouais, pas tant que ça après lecture de l'explication officielle)




Plus en détail :

L'anomalie est la présence d'un attribut BGP expérimental (numéro 99).

D'après les explications du RIPE :

The experimental attribute was part of an experiment conducted in
collaboration with a group from Duke University. This involved
announcing a large (3000 bytes) optional transitive attribute, using a
modified version of Quagga. The attribute used type code 99. The data
consisted of zeros. We used the prefix 93.175.144.0/24 for this and
announced from AS 12654 on AMS-IX, NL-IX and GN-IX to all our peers.

Reports from affected ISPs showed that the length of the attribute in
the attribute header, as seen by their routers, was not correct. The
header stated 233 bytes and the actual data in their samples was 237
bytes. This caused some routers to drop the session with the peer that
announced the route.


La bonne pratique dans ce cas aurait été d'ignorer l'attribut en
question, ce qu'ont fait la plupart des implémentations, mais d'autres
ont préféré faire un shutdown de la session relayant cette annonce.



Du coup, ça crée quelques questions :

- Le RIPE peut foutre la merde, ça on savait. Mais visiblement, un peu
de poudre verte dans un paquet et tous les cisco du globe se mettent à
tousser. Vu l'impact d'une "petite expérimentation", est ce qu'on peut
faire confiance à des implémentations aussi fragiles ?

- Quelles implémentations ont été touchées, et s'agit il bien du même
bug partout ? Lesquelles se braquent (en shutdown direct), et lesquelles
ont des comportements plus "subtils" ?

- Question subsidiaire, pourquoi donc n'y a t il pas encore eu de thread
ici même ? Les retours de vacances ?

-- 
Jérôme Nicolle



signature.asc
Description: OpenPGP digital signature

Re: [FRnOG] Incident majeur, WTF happened ?

[e-t172]

On 31/08/2010 14:17, Jérôme Nicolle wrote:

Que c'est il passé vendredi 27 de 11h15 à 12h30 ?

Ce qu'on a vu :
- Free a été coupé du monde pendant 30 à 45 minutes
- On m'a rapporté la même chose sur OVH et Renater
- Un creux de 100Gbps a été constaté sur les stats de l'AMS-IX
(quelqu'un a le screenshot ?)

Ce qui s'en est dit :
- Le RIPE a testé des annonces particulières qui auraient levé un bug
dans certaines implémentations de BGP
- Les principaux routeurs touchés sont des cisco
- Le facteur déclenchant serait la présence de confédérations BGP
(mouais, pas tant que ça après lecture de l'explication officielle)


Renesys a écrit un billet là-dessus :

http://www.renesys.com/blog/2010/08/house-of-cards.shtml

--
Etienne Dechamps / e-t172 - AKE Group
Phone: +33 6 20 41 09 29



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [FRnOG] Incident majeur, WTF happened ?

[Raphael Maunier]

Hello,

Je n'ai pas poste sur twitter, mais de notre cote, on a juste pris plus de 
trafic car nous avons récupéré les flux vers nos clients qui sont sur l'Amsix 
ou autre.
A priori, tous les junos ne sont pas "résistant", mais comme Juniper l'indique, 
pas plus de 3 releases majeures de retard, comme on respecte ces pre-requis du 
constructeur, a priori pas de soucis.

Mon avis sur la question : Il y a l'école de ceux qui restent avec une release 
d'OS ( Cisco, Juniper ou Brocade) d'il y a 4 ans parce que pourquoi en changer  
(j'en connais plein) , ensuite l'école de ceux qui ne tourne pas forcement la 
dernière release beta a la mode, mais celle supportée par le constructeur.

Le soucis est plus sur un manque de mise a jour d'OS ou une mauvaise 
implémentation ( non respect des RFC) d'un constructeur (si par exemple les 
CRS-1 a jour se plante)

-- 
Raphaël Maunier
NEO TELECOMS
CTO / Responsable Ingénierie
AS8218




On Aug 31, 2010, at 2:17 PM, Jérôme Nicolle wrote:

> Bonjour,
> 
> On en a causé sur l'IRC, le sujet a été abordé sur NANOG, mais
> bizarrement, on a rien vu passer ici.
> 
> Que c'est il passé vendredi 27 de 11h15 à 12h30 ?
> 
> Ce qu'on a vu :
> - Free a été coupé du monde pendant 30 à 45 minutes
> - On m'a rapporté la même chose sur OVH et Renater
> - Un creux de 100Gbps a été constaté sur les stats de l'AMS-IX
> (quelqu'un a le screenshot ?)
> 
> Ce qui s'en est dit :
> - Le RIPE a testé des annonces particulières qui auraient levé un bug
> dans certaines implémentations de BGP
> - Les principaux routeurs touchés sont des cisco
> - Le facteur déclenchant serait la présence de confédérations BGP
> (mouais, pas tant que ça après lecture de l'explication officielle)
> 
> 
> 
> 
> Plus en détail :
> 
> L'anomalie est la présence d'un attribut BGP expérimental (numéro 99).
> 
> D'après les explications du RIPE :
> 
> The experimental attribute was part of an experiment conducted in
> collaboration with a group from Duke University. This involved
> announcing a large (3000 bytes) optional transitive attribute, using a
> modified version of Quagga. The attribute used type code 99. The data
> consisted of zeros. We used the prefix 93.175.144.0/24 for this and
> announced from AS 12654 on AMS-IX, NL-IX and GN-IX to all our peers.
> 
> Reports from affected ISPs showed that the length of the attribute in
> the attribute header, as seen by their routers, was not correct. The
> header stated 233 bytes and the actual data in their samples was 237
> bytes. This caused some routers to drop the session with the peer that
> announced the route.
> 
> 
> La bonne pratique dans ce cas aurait été d'ignorer l'attribut en
> question, ce qu'ont fait la plupart des implémentations, mais d'autres
> ont préféré faire un shutdown de la session relayant cette annonce.
> 
> 
> 
> Du coup, ça crée quelques questions :
> 
> - Le RIPE peut foutre la merde, ça on savait. Mais visiblement, un peu
> de poudre verte dans un paquet et tous les cisco du globe se mettent à
> tousser. Vu l'impact d'une "petite expérimentation", est ce qu'on peut
> faire confiance à des implémentations aussi fragiles ?
> 
> - Quelles implémentations ont été touchées, et s'agit il bien du même
> bug partout ? Lesquelles se braquent (en shutdown direct), et lesquelles
> ont des comportements plus "subtils" ?
> 
> - Question subsidiaire, pourquoi donc n'y a t il pas encore eu de thread
> ici même ? Les retours de vacances ?
> 
> -- 
> Jérôme Nicolle
> 


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

[FRnOG] Re: Incident majeur, WTF happened ?

[Stephane Bortzmeyer]

On Tue, Aug 31, 2010 at 02:17:54PM +0200,
 Jérôme Nicolle  wrote 
 a message of 94 lines which said:

> Que c'est il passé vendredi 27 de 11h15 à 12h30 ?

Comment peut-on se soucier de tels détails à l'heure où Facebook est
en panne ?
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: Incident majeur, WTF happened ?

[Raphael Maunier]

On Aug 31, 2010, at 2:34 PM, Stephane Bortzmeyer wrote:

> On Tue, Aug 31, 2010 at 02:17:54PM +0200,
> Jérôme Nicolle  wrote 
> a message of 94 lines which said:
> 
>> Que c'est il passé vendredi 27 de 11h15 à 12h30 ?
> 
> Comment peut-on se soucier de tels détails à l'heure où Facebook est
> en panne ?
L'autre version du site fonctionne encore :)

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


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

Re: [FRnOG] RFC 5963: IPv6 Deployment in Internet Exchange Points

[Julien Reveret]

>
> Est-ce à dire que si l'Internet se transforme en un immense réseau
> Ethernet opérateur, l'intérêt d'IPv6 est fortement réduit ? Ce réseau
> pourrait même ne transporter que des adresses privées IPv4.
>

Si Internet se transformait en un immense réseau Ethernet, alors je
n'imagine même pas la congestion des liens à cause des broadcasts ARP.

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

Re: [FRnOG] Incident majeur, WTF happened ?

[Youssef Bengelloun-Zahr]

Pour information :

http://ccie-in-3-months.blogspot.com/2010/08/decoding-ripe-experiment.html

Ah ! les joies de l'Internet !

Y.



Le 31 août 2010 14:25, e-t172  a écrit :

> On 31/08/2010 14:17, Jérôme Nicolle wrote:
>
>> Que c'est il passé vendredi 27 de 11h15 à 12h30 ?
>>
>> Ce qu'on a vu :
>> - Free a été coupé du monde pendant 30 à 45 minutes
>> - On m'a rapporté la même chose sur OVH et Renater
>> - Un creux de 100Gbps a été constaté sur les stats de l'AMS-IX
>> (quelqu'un a le screenshot ?)
>>
>> Ce qui s'en est dit :
>> - Le RIPE a testé des annonces particulières qui auraient levé un bug
>> dans certaines implémentations de BGP
>> - Les principaux routeurs touchés sont des cisco
>> - Le facteur déclenchant serait la présence de confédérations BGP
>> (mouais, pas tant que ça après lecture de l'explication officielle)
>>
>
> Renesys a écrit un billet là-dessus :
>
> http://www.renesys.com/blog/2010/08/house-of-cards.shtml
>
> --
> Etienne Dechamps / e-t172 - AKE Group
> Phone: +33 6 20 41 09 29
>
>


-- 
Youssef BENGELLOUN-ZAHR ……
Ingénieur Réseaux et Télécoms


Technopole de l'Aube  en Champagne - BP 601 - 10901 TROYES  Cedex 9
Agence Paris : 6, rue Charles Floquet - 92120 MONTROUGE
Tel +33 (0) 825 000 720
Tel. direct  +33 (0) 1 77 35 59 14
Tel. portable  +33 (0) 6 22 42 63 80
Emaily...@720.fr
…….www.720.fr

Re: [FRnOG] Incident majeur, WTF happened ?

[Christophe Baegert]

Le 31/08/2010 15:05, Youssef Bengelloun-Zahr a écrit :
> Pour information :
> 
> http://ccie-in-3-months.blogspot.com/2010/08/decoding-ripe-experiment.html
>

RIPE and Duke University decided to experiment with Quagga's BGP and
the result was to make some routers reset their BGP sessions, because
they were receiving malformed BGP update packets. Malformed packets
were generated by other routers in the middle, not by the Quagga BGP
daemon where the experiment started.

Trop gros, passera pas ;-)
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Incident majeur, WTF happened ?

[pcol]

Le RIPE vient de publier ça :
http://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment

-- 
Pierre




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

[FRnOG] Re: Incident majeur, WTF happened ?

[Stephane Bortzmeyer]

On Tue, Aug 31, 2010 at 02:34:41PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 11 lines which said:

> > Que c'est il passé vendredi 27 de 11h15 à 12h30 ?
> 
> Comment peut-on se soucier de tels détails à l'heure où Facebook est
> en panne ?

Voici le vrai accident majeur très grave trop horrible :

http://www.bortzmeyer.org/facebook-joue-bgp.html
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: Incident majeur, WTF happened ?

[pcol]

Stephane Bortzmeyer wrote:

>>> Que c'est il passé vendredi  27 de 11h15 à 12h30 ?


 > Voici le vrai accident majeur très grave trop horrible : 
> http://www.bortzmeyer.org/facebook-joue-bgp.html

  
 Merci à tous pour les infos, je vulgarise :  http://bit.ly/bugsBGP

-- 
Pierre



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

Re: [FRnOG] Incident majeur, WTF happened ?

[Jérôme Nicolle]

Le 31/08/10 15:32, p...@9online.fr a écrit :
> Le RIPE vient de publier ça :
> http://labs.ripe.net/Members/erik/ripe-ncc-and-duke-university-bgp-experiment
> 

Ok, là c'est bien clair.

Bon, qui relance les annonces la semaine prochaine pour vérifier que les
routeurs ont été mis à jour ?

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



signature.asc
Description: OpenPGP digital signature

[FRnOG] Re: Incident majeur, WTF happened ?

[Stephane Bortzmeyer]

On Tue, Aug 31, 2010 at 04:13:51PM +0200,
 p...@9online.fr  wrote 
 a message of 16 lines which said:

>  Merci à tous pour les infos, je vulgarise :  http://bit.ly/bugsBGP

Très mauvais, surtout le titre « Une expérimentation mal préparée » ou
la remarque facile « Espérons que la leçon aura été retenue, et que
les prochaines expérimentations de routage Internet seront mieux
maîtrisée ». Lire

montre tout le contraire. Pour la sécurité et la stabilité de
l'Internet, il FAUT continuer à tester. Si on engueule le messager
parce que le message nous déplait, plus personne ne fera de tests et
on ne découvrira les problèmes que le jour d'une vraie attaque !
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Incident majeur, WTF happened ?

[Pierre Francois]

Salut,

Jérôme Nicolle wrote:


- Un creux de 100Gbps a été constaté sur les stats de l'AMS-IX
(quelqu'un a le screenshot ?)



http://inl.info.ucl.ac.be/system/files/16all.png



- Les principaux routeurs touchés sont des cisco



http://www.cisco.com/warp/public/707/cisco-sa-20100827-bgp.shtml

Bonne lecture,

Pierre.



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

[FRnOG] Re: Incident majeur, WTF happened ?

[Pierre Col]

Oui il faut expérimenter, bien sur, mais en essayant de prévoir au maximum
les effets de bord : on a eu la preuve vendredi que ce n'était pas le cas,
et le RIPE lui-même dit qu'il va améliorer ses procédures d'expérimentation 
:

c'est bien qu'elles étaient insuffisantes !

--
Pierre


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

Re: [FRnOG] Re: Incident majeur, WTF happened ?

[Jean Baptiste FAVRE]

Bonsoir,

On 31/08/2010 19:53, Pierre Col wrote:
> Oui il faut expérimenter, bien sur, mais en essayant de prévoir au maximum
> les effets de bord : on a eu la preuve vendredi que ce n'était pas le cas,
Les effets de bord, par définition, sont imprévus et la plupart du temps
imprévisibles. Il est toujours facile de juger après coup. Mais sur le
moment, c'est vachement moins simple de tout prévoir, surtout avec le
nombre d'implémentation BGP disponibles.
De plus, comme indiqué au début du thread, le champ BGP responsable du
problème était considéré comme expérimental, donc censé être ignoré par
les implémentations.


> et le RIPE lui-même dit qu'il va améliorer ses procédures
> d'expérimentation :
> c'est bien qu'elles étaient insuffisantes !
Non, pas forcément compte tenu de l'expérience des équipes du RIPE avant
les tests.
Après les tests, et c'est la bonne approche, il faut comprendre d'où est
venu le problème et voir comment on peut l'éviter à l'avenir, si on peut.
Pour autant, ça ne signifie pas que les procédures étaient
intrinsèquement mauvaises ou insuffisantes.

Mes 2 cents,
JB
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] probleme sfinx depuis ce matin 6H45.

[Sébastien FOUTREL]

Bonjour, nous ne sommes pas client du sfinx mais nos traceroute vers
des ips colt s'arretent au sfinx.

Quand aux pings certains hosts arrivent a pinger les ips en question
d'autres pas dans le meme /24.

Constatez-vous un probleme similaire.

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

[FRnOG] Sfinx & Panap go boom?

[Leland Vandervort]

Salut TLM, 

On vient de voir plusieurs peers au Sfinx et Panap tomber... y'a eu une coupure 
qqpart en region parisienne a l'instant?


Leland Vandervort
Director, Technical Operations
Gandi SAS
15 Place de la Nation
75011 Paris, France

WWW: http://www.gandi.net/

T: +33 1 70 39 37 59
M: +33 6 31 15 15 07





smime.p7s
Description: S/MIME cryptographic signature

RE: [FRnOG] Sfinx & Panap go boom?

[Michael VILLAR]

Bonjour,
 
 Les peers sur le SFINX que nous avons perdu sont sur Interxion1 les reste à 
l'air bon.
 
Cordialement,
 

  
Michaël Villar
mailto:mvil...@veepee.com
tél : 01 73 03 85 84 ? port : 06 63 92 76 79
Visitez notre site web : www.veepee.com
 
VeePee est une société de SPIE Communications
 

> -Message d'origine-
> De : lel...@gandi.net [mailto:owner-fr...@frnog.org] De la part de Leland
> Vandervort
> Envoyé : mercredi 1 septembre 2010 08:13
> À : frnog@FRnOG.org
> Objet : [FRnOG] Sfinx & Panap go boom?
> 
> 
> Salut TLM,
> 
> On vient de voir plusieurs peers au Sfinx et Panap tomber... y'a eu une
> coupure qqpart en region parisienne a l'instant?
> 
> 
> Leland Vandervort
> Director, Technical Operations
> Gandi SAS
> 15 Place de la Nation
> 75011 Paris, France
> 
> WWW: http://www.gandi.net/
> 
> T: +33 1 70 39 37 59
> M: +33 6 31 15 15 07
> 
> 


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

[FRnOG] sfinx & panap = boom?

[Leland Vandervort]

Salut TLM, 

On vient de voir plusieurs peers au Sfinx et Panap tomber... y'a eu une coupure 
qqpart en region parisienne a l'instant?

Leland


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