Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
On 09/07/2012 19:44, Alain Thivillon wrote: Le mot HLR a été prononcé en direct lors de la conférence de presse retransmise sur BFM et iTele, mais bon ... Je ne connais rien à la téléphonie et encore moins mobile, mais ce qui est déclaré dans la presse par un opérateur pour expliquer une panne majeure ne revêt pas grande crédibilité à mes yeux. Je ne dis pas que c'est le cas, mais je vois de toutes façons mal Stéphane Richard expliquer devant les caméras que des millions de personnes ont été bloquées parce que le système de billing ne pouvait plus vérifier leurs forfaits. En pareil cas j'ai la curieuse sensation qu'on aurait aussi pointé le HLR du doigt non ? De toutes façons la technique a bon dos, c'est jamais la faute de l'utilisateur qu'il s'appelle Mme Michu ou M. Richard. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
Le 8 juillet 2012 23:47, Guillaume Barrot guillaume.bar...@gmail.com a écrit : Diameter etant l'evolution de Radius, tous les gens ayant ici des architectures LNS/Radius/BDD ou LDAP s'etonneront de la faculté des operateurs mobiles a se planter quand il s'agit de coupler un terminateur de tunnel a un AAA, et qui plus est a faire ca sans acheter des Cray pour répondre aux requêtes. Combien de telco ont reussi a vautrer le control-plane sur les tests LTE depuis 2 ans ? ah un certain nombre quand meme ! Mais oui mais ma bonne dame, nombre de FAI deploie du LNS depuis des années, avec des Radius base open source, alors que les operateurs mobiles ont decouvert le paquet sur le tard (jusqu'a la 3G, le seul bon paquet pour un operateur mobile etait un Colissimo), donc ils decouvrent la joie du dimensionnement de plateformes de services fournies par des constructeurs, avec en plus que du soft propriétaire... C'est clair qu'une batterie de Radiator sur X86 avec du load-balancer en frontal, un peu d'anycast pour saupoudrer ca sur plusieurs sites, c'est compliqué. Combien de ces memes Telco ont ca sur leur infra fixe pour la collecte via un operateur tiers ??? Mais, pour le mobile, le constructeur n'ayant pas ca au catalogue on achete la boiboite bien opaque et on deploie ca en priant le sacro-saint contrat de maintenance, avec un PRA sur le site d'a coté, et une replication synchrone des bases de données (comme ca, quand on corrompt la base de droite, c'est instantannement que la base de gauche est corrompue aussi. Ca c'est de l'efficacité !) Quant au HLR, que penser d'un annuaire qu'on interroge encore en 2012, en SS7 ? Oui car quand on regarde de plus pret, ca ressemble vachement a un annuaire le HLR, avec un champ particulier qui decrit sur quelle BTS on est accroché. Euh je pensais que le HLR n'avait pas l'info BTS mais uniquement l'info LA (Location Area). André --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
On 07/08/2012 01:28 PM, Xavier Hinfray wrote: c est décentralisé. mais quand un bug logiciel fait planter un bout du hlr , celui ci passe sur un autre noeud. et l autre noeud plante à son tour un peu plus tard à cause du même bug bref, décentralisé ne change rien pour ce type de problème. Il y a un problème avec ce que vous dites, c'est que quand on lit des difficultés à envoyer des SMS dans la presse et qu'on connait un peu les réseaux, il suffit de trouver le call-flow d'un SMS pour voir où et quand le HLR intervient. http://en.wikipedia.org/wiki/Short_message_service_technical_realisation_%28GSM%29 Dans l'envoi du SMS le HLR n'intervient pas. Dans la réception seulement. Dans la presse, on n'a pas lu difficultés à recevoir, mais difficultés à envoyer. Le HLR ne peut donc pas être en cause dans les problèmes d'envoi d'un SMS. On peut refaire la même recherche pour la data: http://www.scribd.com/doc/57489605/GPRS-Call-Flow Donc dire que le HLR est la cause des difficultés d'envoi de SMS ou pour l'accès Internet est équivalent à dire que quand on obtient no route to host à la commande telnet 10.10.10.1, c'est de la faute au DNS qui ne marche pas. Je suis désolé de vous dire cela, mais ce sont les call-flow qui le disent, moi je ne fais que le remarquer. Le call-flow de wikipédia pour un sms-mo n'est pas complet, on peut le modifier dans le HLR pour interroger un billing. D’après cette page, France Telecom aurait cette plateforme: http://wwwen.zte.com.cn/en/solutions/vas/consumer/200912/t20091224_179017.html A partir des infos publiés dans la presse, le problème de vendredi ressemble beaucoup plus à une scène de ménage entre FranceTelecom et sa plateforme de billing ZTE plutôt qu'un problème de HLR. Le HLR, c'est plutôt le système sur lequel on se jette pour tenter de donner un peu d'oxygène à son billing en plein d’évanouissement et qu'on ne sait pas quoi faire d'autre. L'interview au Figaro donne lance une hypothèse, le passage en production sur le billing d'une nouvelle configuration, d'une nouvelle offre commerciales ... insuffisamment qualifiée et qui a d'abord fait trébuché le billing pour ensuite le planter. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
Avant de pouvoir envoyer un SMS, encore faut-il arriver à s'enregistrer sur le réseau. http://en.wikipedia.org/wiki/Network_switching_subsystem#Home_location_register_.28HLR.29 Vu que le role du HLR est de vérifier cette authentification, s'il tombe, tu pers l'accès au réseau. Donc plus de SMS, plus d'appels ... S'il est juste au taquet, tu peux avoir des requetes d'authentification qui échoue, et donc des déconnexions intempestives (ou plutot des non reconnexions), mais aléatoire. Encore une fois, il suffit de faire l'analogie (grossière) avec BOX / LNS / Radius / Base de donnée. Si la base de donnée, ou le Radius est au taquet, tes requetes d'authentification depuis le LNS échoue, et tu n'as pas de connexion. Si c'est au taquet, ça peut etre juste tres long, et/ou peu stable. Si tu veux vérifier dans quel callflow exacte, la panne éventuelle d'un HLR a pu poser problème : http://www.eventhelix.com/RealtimeMantra/Telecom/#GSM_Circuit_Switched_Call_Flows bon courage, c'est juste indigeste ... Le 9 juillet 2012 17:54, Stephane Le Men stephane.le...@anycast-networks.com a écrit : On 07/08/2012 01:28 PM, Xavier Hinfray wrote: c est décentralisé. mais quand un bug logiciel fait planter un bout du hlr , celui ci passe sur un autre noeud. et l autre noeud plante à son tour un peu plus tard à cause du même bug bref, décentralisé ne change rien pour ce type de problème. Il y a un problème avec ce que vous dites, c'est que quand on lit des difficultés à envoyer des SMS dans la presse et qu'on connait un peu les réseaux, il suffit de trouver le call-flow d'un SMS pour voir où et quand le HLR intervient. http://en.wikipedia.org/wiki/**Short_message_service_** technical_realisation_%28GSM%**29http://en.wikipedia.org/wiki/Short_message_service_technical_realisation_%28GSM%29 Dans l'envoi du SMS le HLR n'intervient pas. Dans la réception seulement. Dans la presse, on n'a pas lu difficultés à recevoir, mais difficultés à envoyer. Le HLR ne peut donc pas être en cause dans les problèmes d'envoi d'un SMS. On peut refaire la même recherche pour la data: http://www.scribd.com/doc/**57489605/GPRS-Call-Flowhttp://www.scribd.com/doc/57489605/GPRS-Call-Flow Donc dire que le HLR est la cause des difficultés d'envoi de SMS ou pour l'accès Internet est équivalent à dire que quand on obtient no route to host à la commande telnet 10.10.10.1, c'est de la faute au DNS qui ne marche pas. Je suis désolé de vous dire cela, mais ce sont les call-flow qui le disent, moi je ne fais que le remarquer. Le call-flow de wikipédia pour un sms-mo n'est pas complet, on peut le modifier dans le HLR pour interroger un billing. D’après cette page, France Telecom aurait cette plateforme: http://wwwen.zte.com.cn/en/**solutions/vas/consumer/200912/** t20091224_179017.htmlhttp://wwwen.zte.com.cn/en/solutions/vas/consumer/200912/t20091224_179017.html A partir des infos publiés dans la presse, le problème de vendredi ressemble beaucoup plus à une scène de ménage entre FranceTelecom et sa plateforme de billing ZTE plutôt qu'un problème de HLR. Le HLR, c'est plutôt le système sur lequel on se jette pour tenter de donner un peu d'oxygène à son billing en plein d’évanouissement et qu'on ne sait pas quoi faire d'autre. L'interview au Figaro donne lance une hypothèse, le passage en production sur le billing d'une nouvelle configuration, d'une nouvelle offre commerciales ... insuffisamment qualifiée et qui a d'abord fait trébuché le billing pour ensuite le planter. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
On 07/09/2012 06:21 PM, Guillaume Barrot wrote: Avant de pouvoir envoyer un SMS, encore faut-il arriver à s'enregistrer sur le réseau. http://en.wikipedia.org/wiki/Network_switching_subsystem#Home_location_register_.28HLR.29 A noter aussi qu'en France, au moins chez SFR et Orange en 2G, le réseau impose une réauthentification du mobile à chaque utilisation de ressource (SMS, Appel, ouverture d'un PDP= ou appel entrant (ce qui n'est pas obligatoire si l'on suit la norme). Ca évite quelques attaques. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
On 07/09/2012 06:33 PM, Alain Thivillon wrote: en 2G, le réseau impose une réauthentification du mobile à chaque utilisation de ressource en 2G, mais ce sont des utilisateurs 3G qui ont été impactés, et en plus grand nombre. La différence entre un échec authentification sur l'AuC et une demande de token de ressource non acquittée par le billing est parfaitement identifiable avec l'état du téléphone. L'information qui permet de trancher a été rapportée des clients dans la presse. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
Le 09/07/2012 19:21, Stephane Le Men a écrit : en 2G, mais ce sont des utilisateurs 3G qui ont été impactés, et en plus grand nombre. La différence entre un échec authentification sur l'AuC et une demande de token de ressource non acquittée par le billing est parfaitement identifiable avec l'état du téléphone. L'information qui permet de trancher a été rapportée des clients dans la presse. Bonjour, Ce n'est pas mon domaine, mais une question me vient à l'esprit suite aux différentes interventions sur la redondance etc : Je n'irai pas juger de la technologie et de la qualité de redondance, surtout qu'une base de données est toujours un élément sensible et ça me semblerait prétention de faire la morale sans connaître le sujet en détail. Mais comme on en est à parler de 3G, 2G, etc, est-ce qu'il n'est pas imaginable (en simplifiant l'explication) de dupliquer la base des comptes sur 2 plateformes bases relativement indépendantes et d'utiliser l'une pour la 3G et l'autre pour la 2G/autre ? Comme les 2 ont l'air de communiquer différemment avec leur base, ça me semblerait pas forcément déconnant. Admettons : - 2 bases avec les mêmes infos abonnés - une base pour gérer les coms/infos 3G - une base pour gérer les coms/infos 2G/etc - La factu et les checks se font en additionnant les 2 infos (plus complexe certes) - Si problème sur la base 3G, bascule de tout sur la 2G le temps de résoudre (ça rale mais ça passe en dégradé) - Si problème sur la 2G, ça râle mais on va dire qu'on limite la casse. Reste à mon avis juste le problème des forfaits bloqués si c'est géré automatiquement par les systèmes sans outil extérieur, mais à ce moment là pourquoi ne pas envisager une base séparée pour ces forfaits là, en estimant qu'ils sont moins critiques ? (j'imagine que ça concerne plus le jeune ado que le pro cette offre) Ou plus directement encore, avoir une plateforme dégradée sur laquelle basculer si problème, qui n'aurait à la base qu'un duplicat des éléments clés des abonnés pour leur permettre d'appeler/SMSer en tenant un journal des coms mais sans faire aucune vérification par rapport au forfait. En cas de problème, ça bascule, l'opérateur ne gagne pas d'argent sur les coms normalement facturées hors forfait sur ce délai et ne décompte pas le temps sur les forfaits mais la satisfaction des clients reste acceptable, l'image est meilleure et ça vaut bien une journée de coms offerte après préjudice. Je dirais basiquement de mon point de vue que le mal est moindre et qu'un utilisateur qui peut appeler/SMS avec son mobile, c'est un utilisateur déjà plus compréhensif qu'un mobile totalement non fonctionnel pendant 10h. Les réplications de bases c'est toujours pénible, quand ça se passe sur une masse de contraintes et d'infos énorme, c'est vite la cata quand ça tombe en marche. Peut-être aussi que les système en téléphonie n'ont aucune flexibilité à ce niveau là et ne permettent pas d'interagir facilement ? Ce serait surprenant quand même... Parce que là quand même à lire tout ce qui se dit, ça donne l'impression que tout est géré sur une énorme base unitaire qui fait limite le café aussi (j'ai pas insinué que c'était en java, pas taper) Frédéric --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
Mais comme on en est à parler de 3G, 2G, etc, est-ce qu'il n'est pas imaginable (en simplifiant l'explication) de dupliquer la base des comptes sur 2 plateformes bases relativement indépendantes et d'utiliser l'une pour la 3G et l'autre pour la 2G/autre ? Comme les 2 ont l'air de communiquer différemment avec leur base, ça me semblerait pas forcément déconnant. Tu perds le handover seamless entre 2G et 3G. Ta technique fonctionne si tes couvertures 2G et 3G sont strictement identiques, et que tu consideres que tu as deux types de forfaits différents : forfaits 2G et forfaits 3G. Ca revient a segmenter tes offres par la techno d'acces ... mais personne ne fait ca ... http://www.swisscom.ch/res/mobile/tarife/index.htm?languageId=fr#infinity aaaie caramba, encore raté ! --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
c est décentralisé. mais quand un bug logiciel fait planter un bout du hlr , celui ci passe sur un autre noeud. et l autre noeud plante à son tour un peu plus tard à cause du même bug bref, décentralisé ne change rien pour ce type de problème. -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. Jérôme Nicolle jer...@ceriz.fr a écrit : Le 7 juillet 2012 11:12, Alain Thivillon a...@rominet.net a écrit : ... Super résumé Alain, merci :) Pour le coup, j'aimerais juste émettre une hypothèse à la con : et si on décentralisait un peu ça ? Un peu comme ce qu'on fait en IP : un IGP pour localiser les NodeB et RNC, une négo d'annonce entre le terminal et son RNC, une validation distribuée façon RPKI ou ROVER, ça permetrait en théorie de propager et répliquer les données de provisionning en limitant l'impact de perte d'un noeud... Non ? -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
Plus d'explications ici : http://blogs.univ-poitiers.fr/f-launay/2012/07/08/diameter-la-panne-dorange/ Le 08/07/2012 13:28, Xavier Hinfray a écrit : c est décentralisé. mais quand un bug logiciel fait planter un bout du hlr , celui ci passe sur un autre noeud. et l autre noeud plante à son tour un peu plus tard à cause du même bug bref, décentralisé ne change rien pour ce type de problème. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
Diameter etant l'evolution de Radius, tous les gens ayant ici des architectures LNS/Radius/BDD ou LDAP s'etonneront de la faculté des operateurs mobiles a se planter quand il s'agit de coupler un terminateur de tunnel a un AAA, et qui plus est a faire ca sans acheter des Cray pour répondre aux requêtes. Combien de telco ont reussi a vautrer le control-plane sur les tests LTE depuis 2 ans ? ah un certain nombre quand meme ! Mais oui mais ma bonne dame, nombre de FAI deploie du LNS depuis des années, avec des Radius base open source, alors que les operateurs mobiles ont decouvert le paquet sur le tard (jusqu'a la 3G, le seul bon paquet pour un operateur mobile etait un Colissimo), donc ils decouvrent la joie du dimensionnement de plateformes de services fournies par des constructeurs, avec en plus que du soft propriétaire... C'est clair qu'une batterie de Radiator sur X86 avec du load-balancer en frontal, un peu d'anycast pour saupoudrer ca sur plusieurs sites, c'est compliqué. Combien de ces memes Telco ont ca sur leur infra fixe pour la collecte via un operateur tiers ??? Mais, pour le mobile, le constructeur n'ayant pas ca au catalogue on achete la boiboite bien opaque et on deploie ca en priant le sacro-saint contrat de maintenance, avec un PRA sur le site d'a coté, et une replication synchrone des bases de données (comme ca, quand on corrompt la base de droite, c'est instantannement que la base de gauche est corrompue aussi. Ca c'est de l'efficacité !) Quant au HLR, que penser d'un annuaire qu'on interroge encore en 2012, en SS7 ? Oui car quand on regarde de plus pret, ca ressemble vachement a un annuaire le HLR, avec un champ particulier qui decrit sur quelle BTS on est accroché. Alors bon, le HSS c'est pas mieux ... On reinvente le radius, mais avec un protocole de transport tout neuf, pour etre bien sur que personne ne le supporte et que ca tourne qu'en CPU (va faire du SCTP offload sur ta carte réseau tiens ...) Bon ca un interet faible, qui est de faire cramer les firewalls (qui n'aiment pas DU TOUT le SCTP), et la culture sur brûlis, y a que ca de vrai. Admettons que ce soit 1000 fois plus compliqué que ca, la base de ces equipements contenant des données clients est quand meme connue : qu'est ce qu'on fait quand on veut securiser une base de données ? On en fait plusieurs, et on ne fait surtout pas de synchrone. C'est connu. C'est pas comme si des vieilles bases de données avec des contraintes de temps réels et du PRA dans tous les sens n'existaient pas dans le monde, au hasard dans le domaine bancaire et assurance... Et il vaut mieux avoir une perte d'une heure de données que 10h de restauration de base corrompue. Bref, si vous voulez que les operateurs mobiles arretent de peter leur control plane, et bien arretez d'acheter des bases de données a des constructeurs de switchs ATM. Normalement ca devrait marcher mieux. Le 8 juillet 2012 20:57, Pierre `Sn4kY` DOLIDON sn...@sn4ky.net a écrit : Plus d'explications ici : http://blogs.univ-poitiers.fr/** f-launay/2012/07/08/diameter-**la-panne-dorange/http://blogs.univ-poitiers.fr/f-launay/2012/07/08/diameter-la-panne-dorange/ Le 08/07/2012 13:28, Xavier Hinfray a écrit : c est décentralisé. mais quand un bug logiciel fait planter un bout du hlr , celui ci passe sur un autre noeud. et l autre noeud plante à son tour un peu plus tard à cause du même bug bref, décentralisé ne change rien pour ce type de problème. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
Avec une durée d'incident de pratiquement 10h, je suis curieux de savoir qu'est-ce qui tombé en panne et pourquoi ils ont mis aussi longtemps à réparer ? François-Xavier Gary gary.delo...@ebsd.net a écrit : Merci à tous! ;-) Gaël mailto:gag...@gmail.com vendredi 6 juillet 2012 18:45 même question. --- Liste de diffusion du FRnOG http://www.frnog.org/ Gary mailto:gary.delo...@ebsd.net vendredi 6 juillet 2012 18:42 B'soir, Plus d'appels sur Orange/Free/Bouygues à priori depuis 20mins, qq'un à des infos? Cdt --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
On 07/07/2012 03:21 AM, François-xavier wrote: Avec une durée d'incident de pratiquement 10h, je suis curieux de savoir qu'est-ce qui tombé en panne et pourquoi ils ont mis aussi longtemps à réparer ? Dans un réseau mobile, il y a le réseau (BTS, MSC en 2G, NodeB, RNC en 3G, SGSN, GGSN, SMSC pour les deux) et puis il y a un instrument critique qui sait ou est l'utilisateur, ce qu'il a le droit de faire et comment l'authentifier : le HLR : Home Location Register. C'est une base de données accédée via les protocoles télécoms, avec comme clés d'index l'IMSI et le MSISDN de l'abonné. Comme toute base de donnés, ben quand ça foire c'est la grosse M..., meme avec tous les mécanismes de réplication et de failover du monde. S'il faut remonter des backups, ben c'est long, dangereux, etc... Si les HLR sont en panne, plus d'authentification, plus d'appels, plus de SMS, plus de data parce que le SGSN ne peut plus vérifier le provisionning de l'abonné, plus rien. Les mobiles enregistrés peuvent rester sur le réseau sans s'apercevoir de rien, mais dès qu'ils feront un appel, plouf. Apres quand le HLR revient il y a un rush de demandes depuis les mobiles pour se réenregistrer, un rush de demandes depuis les SMSC pour délivrer ce qui est en file, etc... D'ou probablement une remise en route partielle, par morceaux, d'abord 2G, etc ... Je ne travaille pas chez orange et je n'ai aucune idée de ce qui s'est passé, mais ils parlent d'un incident logiciel majeur, et le HLR est le seul composant qu'on ne peut pas remplacer par un autre en quelques minutes. A noter que Bouygues Telecom a eu une panne similaire en 2004 (octobre si je me rappelle bien) avec 10h de coupure aussi. Dans le même registre, le plantage régulier des super-supernodes de Skype provoque exactement les mêmes effets : quand on ne sait plus localiser l'abonné, c'est mort. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
Le 7 juillet 2012 11:12, Alain Thivillon a...@rominet.net a écrit : ... Super résumé Alain, merci :) Pour le coup, j'aimerais juste émettre une hypothèse à la con : et si on décentralisait un peu ça ? Un peu comme ce qu'on fait en IP : un IGP pour localiser les NodeB et RNC, une négo d'annonce entre le terminal et son RNC, une validation distribuée façon RPKI ou ROVER, ça permetrait en théorie de propager et répliquer les données de provisionning en limitant l'impact de perte d'un noeud... Non ? -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: RE : Re: [FRnOG] [MISC] Problème sur le réseau mobile?
oui, merci beaucoup ! Le 7 juillet 2012 13:35, Jérôme Nicolle jer...@ceriz.fr a écrit : Le 7 juillet 2012 11:12, Alain Thivillon a...@rominet.net a écrit : ... Super résumé Alain, merci :) Pour le coup, j'aimerais juste émettre une hypothèse à la con : et si on décentralisait un peu ça ? Un peu comme ce qu'on fait en IP : un IGP pour localiser les NodeB et RNC, une négo d'annonce entre le terminal et son RNC, une validation distribuée façon RPKI ou ROVER, ça permetrait en théorie de propager et répliquer les données de provisionning en limitant l'impact de perte d'un noeud... Non ? -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
