Re: [FRnOG] De la gestion des fichiers de configuration

[eberkut]

Le 11 oct. 2009 à 20:30, Francois Tigeot a écrit :


Youssef Ghorbal wrote:

Nous souhaitons mettre en place un mecanisme qui permet de versionner
les fichiers de configuration tout en gardant la trace de qui a  
modifie

quoi et quand.


Ca a l'air de ressembler comme deux gouttes d'eau à ce que fait RCS.  
Il

permet de locker le fichier, éditer tranquillement et délocker avec un
message.

C'est normalement installé sur tout bon système vaguement unixoïde  
depuis

les années 80.


Tout à fait, ça fait partie des best practices pour la gestion de  
serveurs depuis quelques temps. Par exemple : http://wikis.sun.com/display/BigAdmin/Configuration+files+best+practices


Il y a aussi tout un chapitre dédié à cette technique dans Absolute  
FreeBSD, 2nd Edition :

http://books.google.fr/books?id=vebgS-r9fP8C&pg=PA51&dq=absolute+freebsd+checkin+checkout&ei=7bvTStKSPKbKyQTVj7meDg#v=onepage&q=&f=false

Ceci étant valable pour les serveurs. Pour tout ce qui est équipement  
réseau, on peut passer par Rancid pour faire du versioning centralisé.


Et pour la centralisation de configurations (orienté serveur), il y a  
les outils comme cfengine, chef ou puppet.


On peut aussi penser rajouter une couche d'accounting RADIUS un peu  
partout pour suivre les modifications manuelles par exécution de  
commandes.


Tout ça ce sont des exemples d'outils remplissant une partie de la  
tâche de la gestion des configurations dans un système d'information.  
Pour quelque chose de totalement complet, ITIL CMDB, pouet pouet, je  
ne connais pas de solution intégrant chaque aspect même en payant cher  
(genre Cisco ou Tivoli).


Bon courage,

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

Re: [FRnOG] France-Ix Logo

[Arthur Fernandez]

Bonjour,

Raphael Maunier wrote:

[...]
Si ce n'est que ca, je peux egalement filer un peu de transit gratos 
aux associations ca reviendra au meme, je ne le verrais meme pas.




Chiche ! :)

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

Re: [FRnOG] De la gestion des fichiers de configuration

[Hugues Alary]

Re-Bonjour, ma réponse est partie un peu vite,

GIT me semble être la solution parfaite... http://git-scm.com/
Un peu difficile à prendre en main au départ, il est, une fois apprivoisé,
extrêmement puissant et r-a-p-i-d-e.
Je m'en sert personnellement à la fois pour versionner nos projets de
développement, mais aussi à des fins de sauvegardes.

Cordialement,
Hugues ALARY.

Le 11 octobre 2009 18:32, Youssef Ghorbal  a
écrit :

> Bonjour,
>
> Nous sommes une equipe qui travaille sur plusieurs serveurs de types
> *NIX (du GNU/Linux, du *BSD et du Solaris) Nous souhaitons mettre en
> place un mecanisme qui permet de versionner les fichiers de
> configuration tout en gardant la trace de qui a modifie quoi et quand.
> Certain preconise l'utilisation d'outils telque CVS/SVN... Ce que je
> reproche a ces outils est :
>  - La non gestion native des permissions et de l'ownership des
> fichiers maintenu dans le repository (qu'il soit local ou distant)
> pour des fichiers de configuration ceci est tout simplement
> necessaire.
>  - La plupart de ces outils suivent le paradigme "copy-modify-merge"
> tres utile dans le developpement logiciel mais tres peu pratique pour
> des fichiers de conf qui sont edite sur place. Ce qui est adapte aux
> fichiers de configuration est plutot le "lock-modify-unlock" (tres peu
> supporte par ces outils)
>
>  Qu'est ce que vous utilisez vous autres admin/sys de la liste. Est ce
> qu'il existe un gestionnaire de version oriente "fichier de conf" ou
> bien est ce que vous utilisez d'autres "techniques" ou bien vous avez
> developpez vos propres outils ?
>
> Bon dimanche,
> Youssef Ghorbal
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

Re: [FRnOG] De la gestion des fichiers de configuration

[Hugues Alary]

Bonjour,

GIT me semble être la solution parfaite... http://git-scm.com/
Quelque peu difficile à prendre en moment

Le 11 octobre 2009 18:32, Youssef Ghorbal  a
écrit :

> Bonjour,
>
> Nous sommes une equipe qui travaille sur plusieurs serveurs de types
> *NIX (du GNU/Linux, du *BSD et du Solaris) Nous souhaitons mettre en
> place un mecanisme qui permet de versionner les fichiers de
> configuration tout en gardant la trace de qui a modifie quoi et quand.
> Certain preconise l'utilisation d'outils telque CVS/SVN... Ce que je
> reproche a ces outils est :
>  - La non gestion native des permissions et de l'ownership des
> fichiers maintenu dans le repository (qu'il soit local ou distant)
> pour des fichiers de configuration ceci est tout simplement
> necessaire.
>  - La plupart de ces outils suivent le paradigme "copy-modify-merge"
> tres utile dans le developpement logiciel mais tres peu pratique pour
> des fichiers de conf qui sont edite sur place. Ce qui est adapte aux
> fichiers de configuration est plutot le "lock-modify-unlock" (tres peu
> supporte par ces outils)
>
>  Qu'est ce que vous utilisez vous autres admin/sys de la liste. Est ce
> qu'il existe un gestionnaire de version oriente "fichier de conf" ou
> bien est ce que vous utilisez d'autres "techniques" ou bien vous avez
> developpez vos propres outils ?
>
> Bon dimanche,
> Youssef Ghorbal
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

Re: [FRnOG] Re: [FRnOG] Routage téléphonique : ça coince

[Bernard Dugas]

Bonjour,

Thomas Mangin wrote:
 C'est quoi cette habitude des gens sur cette liste de penser que  
l'ARCEP c'est leur "GodMother" - La fee avec sa baguette magique qui  
peut tout regler !! ??


La comparaison était plus souvent avec GodFather :-)

A bientôt,
--
 __Bernard DUGAS __

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

Re: [FRnOG] comcast alerte via le navigateur les trafics qui ressemble a du malware

[Thomas Mangin]

http://scavenger.exa.org.uk/



C'est pas vraiment l'endroit mais bon ...

Tu scales a combien de capture ?


Le wrapper pour libpcap est en C donc la seule partie en Python c'est  
le traitement des données. Comme dans le flots SMTP, le contenu du  
mail est ignore, le traitement est donc _très_ rapide.
Et même Python n'est pas le langage le plus rapide du monde (ni de  
loin le plus lent), c'est loin d'être un problème.



Parce que python c'est bien sympa mais
tu te prends tjs le lock global de l'interpréteur dans les dents dès  
que

tu lui en demandes un peu trop, et donc de la latence dans le
runtime ...


Le Gloabl Lock n'est important que si le code est multi-threade (ce  
qui n'est pas le cas), et comme la charge de travail est distribue  
entre différents programmes, les cores du CPU sont correctement  
utilise (merci le kernel :p)


De plus ce n'est pas une application "real time" (ou la latence est  
importante) - si ca prends qque millisecondes de plus pour analyser un  
paquet. Le code est aussi conçu pour supporter l'absence de packets  
dans les flows. C'est pour cela que je peux concevoir intégrer netflow  
plus tard (même si cela ne sera pas aussi efficace)


Il y a des cas ou le C (ou a defaut Java/C# pour leur VM) est  
nécessaire, pour ce programme ce n'est pas trop le cas. Et comme les  
programmes sont independants, il serai facile d'en replacer un avec un  
version optimise si le cas devrait se montrer.


Maintenant, si qqun veut faire les tests, aucun problemes :D

Thomas


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

Re: [FRnOG] comcast alerte via le navigateur les trafics qui ressemble a du malware

[Jerome Benoit]

Le Mon, 12 Oct 2009 17:03:25 +0100,
Thomas Mangin  a écrit :


> 
> http://scavenger.exa.org.uk/
> 

C'est pas vraiment l'endroit mais bon ... 

Tu scales a combien de capture ? Parce que python c'est bien sympa mais
tu te prends tjs le lock global de l'interpréteur dans les dents dès que
tu lui en demandes un peu trop, et donc de la latence dans le
runtime ... 

a +.

-- 
Jérôme Benoit aka fraggle
La Météo du Net - http://grenouille.com
OpenPGP Key ID : 9FE9161D
Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D


pgpxIKil7b8q2.pgp
Description: PGP signature

Re: [FRnOG] De la gestion des fichiers de configuration

[Pascal Cabaud]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bonsoir,

Youssef Ghorbal disait le Sun Oct 11 2009 18:32:08 GMT+0200 (CEST) :
>  Qu'est ce que vous utilisez vous autres admin/sys de la liste. Est ce
> qu'il existe un gestionnaire de version oriente "fichier de conf" ou
> bien est ce que vous utilisez d'autres "techniques" ou bien vous avez
> developpez vos propres outils ?

http://www.eila.univ-paris-diderot.fr/user/pascal_cabaud/sysadmin/rvi
à coupler avec syslog.

pc

- --
Pascal CABAUD  
UFR EILA - Universite Paris Diderot 5 rue Watt, 210
tel: (33) 01-57-27-56-53 / 09-72-95-74-03 case 7002
   75205 Paris Cedex 13
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iEYEARECAAYFAkrTXigACgkQ7x5xjoqaEFScUgCeJiDv8GGo23COKl8aLZCJic+d
SH8AniY0L6uS3brb5dF9JsihsyXWjHlR
=Oc9T
-END PGP SIGNATURE-
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Routage téléph onique : ça coince

[Jérôme Nicolle]

Le 12 octobre 2009 17:44, Thomas Mangin
 a écrit :
> Je gere les mail pour ma boite et je crois sérieusement que tu sous-estimes
> le problème que SPIT va être pour la VOIP.

Non, je ne le sous estime pas tant que ça, mais comme l'anti-SPIT va
être un marché monstrueux dans 5 ans alors je vais garder quelques
unes des réflexions pour moi pour l'instant ;)

> je suis d'accord avec ton évaluation de FreeSwitch.

Ben au moins, je ne m'arrache pas les cheveux en pensant à changer de
métier quand je lis son code ;)

-- 
Jérôme Nicolle
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Conseil IPV6

[Pierre-Yves Maunier]

Olivier CALVANO wrote:
Une fois l'adresse affecté, je m'attaque a l'ISIS ipv6 et la config de 
mon BGP notamment au niveau de deux de mes transits qui font l'IPV6 et 
au niveau des des points de peering.


ISIS ipv6 rien à faire, ISIS est indépendant de la couche IP. C'est pour 
ca que c'est le même protocole pour ipv4/ipv6. Pas comme ospf (ipv4) et 
ospf3 (ipv6).
ISIS fonctionne sur le niveau 2 donc tu n'as absolument rien de 
spécifique à faire au niveau config ISIS.



Pierre-Yves

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

Re: [FRnOG] comcast alerte via le navigateur les trafics qui ressemble a du malware

[Thomas Mangin]

Sebastien WILLEMIJNS
http://www.h-online.com/security/US-ISP-provider-Comcast-warns-customers-of-virus-infections--/news/114440


C'est un des rares ISP qui ont les moyens de faire ce genre de  
chose; sans parler de l'argent que ça coûte à mettre en place, il va  
surement y avoir des répercussions légales aussi. Bon courage avec  
les faux positifs.


pub - tu peux faire quelque chose de similaire sans te ruiner, nous  
l'avons fait  - contre-pub c'est actuellement "off-line" car nous  
changeons notre infra.
Le code est disponible (je dois prendre les systemes en prods et  
mettre a jour le repo un de ces jours). Quand j'aurai le courage  
j'ajouterai netflow comme source d'info.


http://scavenger.exa.org.uk/

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

Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Routage tél éphonique : ça coince

[Thomas Mangin]

Le 12 octobre 2009 16:52,   a écrit :

Je n'ai pas l'impression que la reponse colle à la question.
Juste pour 1 mot sur l'ENUM: "ça ne marchera pas"(c) pour 2
raisons:
- je ne gagne pas 0.01Euro HT/min lorsque quelqu'un aboutit
 l'appel sur mes numeros (0.12/0.15 Euro TTC/min sur un
 08). etc.


On va surement voir dans les années a venir un "débat" entre les deux  
modeles de facturation. Je ne serai pas dire comment les choses vont  
evoluer, tout ce que je sais c'est que ma mere peut utiliser Skype  
(donc une forme de voip) et qu'elle est technophobe  - ce qui (a mon  
avis) ne présage rien de bon pour le modele actuel.



Je comprends
bien la problématique, mais on pourrait appliquer au SPIT quelques
règles du SPAM, comme l'authentification préalable de l'utilisateur
(pour whitelister les CID), qui ne poserai pas de problème à un
interlocuteur humain puisqu'il a l'habitude des services audiotel...


Je gere les mail pour ma boite et je crois sérieusement que tu sous- 
estimes le problème que SPIT va être pour la VOIP.



En tout cas c'est facile à implémenter avec Asterisk, et probablement
plus facile encore avec FreeSwitch.


je suis d'accord avec ton évaluation de FreeSwitch.

Thomas

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

Re: [FRnOG] Net neutrality

[Pierre-Louis Brenac]

Après Libé, Benjamin remet-ça sur France Culture !

émission du vendredi 9 octobre 2009
Petite histoire de la sérendipité / La neutralité des réseaux

http://sites.radiofrance.fr/chaines/france-culture2/emissions/place_toile/fiche.php?diffusion_id=77209

Invités
- Benjamin Bayart. Président de la FDN (French Data Network).
- Jérémie Zimmermann. Co-fondateur de La Quadrature du Net.
- Danièle Bourcier. Directrice de recherche au Centre d’Etudes et de
Recherches de Sciences Administratives (CERSA- CNRS/Paris II), membre du
Conseil Scientifique du programme Vox Internet II.
- Evelyne Gayou. Chercheur, compositeur, productrice à la radio, en charge
des éditions «papier» du GRM (Groupe de recherches musicales).

PL



2009/9/24 Dominique Rousseau 

> Le Fri, Sep 11, 2009 at 11:35:28PM +0200, T. Devergranne [...@hstd.net] a
> écrit:
> > Par exemple : skype sur iphone via 3g cela devrait être possible selon
> > vous ?
>
> Oui.
>
> > Est-ce que ce principe de neutralité doit s’appliquer de la même
> > manière sur les terminaux mobiles que sur les réseaux adsl/fibres…
>
> Pour quelle(s) raison(s) un accès internet mobile devrait être considéré
> comme citoyen de seconde zone, alors que le sens de l'histoire va de plus
> en plus vers une connectivité "permanente" par le biais d'outils de ce
> genre...
>
>
> --
> Dominique Rousseau
> Neuronnexion, Prestataire Internet & Intranet
> 50, rue Riolan 8 Amiens
> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

RE: [FRnOG] comcast alerte via le navigateur les trafics qui ressemble a du malware

[Michel Py]

> Sebastien WILLEMIJNS
> http://www.h-online.com/security/US-ISP-provider-Comcast-warns-customers-of-virus-infections--/news/114440

C'est un des rares ISP qui ont les moyens de faire ce genre de chose; sans 
parler de l'argent que ça coûte à mettre en place, il va surement y avoir des 
répercussions légales aussi. Bon courage avec les faux positifs.

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

[FRnOG] Re: [FRnOG] Re: [FRnOG] Routage téléphonique : ça coince

[Jérôme Nicolle]

Octave,

Le 12 octobre 2009 16:52,   a écrit :
> Je n'ai pas l'impression que la reponse colle à la question.
> Juste pour 1 mot sur l'ENUM: "ça ne marchera pas"(c) pour 2
> raisons:
> - je ne gagne pas 0.01Euro HT/min lorsque quelqu'un aboutit
>  l'appel sur mes numeros (0.12/0.15 Euro TTC/min sur un
>  08). etc.

Peut être que le problème viens justement de l'adaptation du business
model de la téléphonie à l'IP. Si tu vendais de la téléphonie comme tu
vends de la bande passante, et que tu n'avais pas à payer les demi
terminaisons chez les autres utilisateurs d'ENUM, ça ne poserai pas de
problème, si ?

> - comme il n'y a pas de couts, les abus sont possible. le marketing
>  coute pas cher sur l'IP et le voice-spam a du sens. ça coutera
>  pas cher de mettre   un serveur avec du SIP qui essaie tous les
>  numeros puis ce que tu veux

Ne pas faire quelque chose à cause des risques d'abus, c'est plus une
logique de moindre effort que de best-effort, non ? ;) Je comprends
bien la problématique, mais on pourrait appliquer au SPIT quelques
règles du SPAM, comme l'authentification préalable de l'utilisateur
(pour whitelister les CID), qui ne poserai pas de problème à un
interlocuteur humain puisqu'il a l'habitude des services audiotel...
En tout cas c'est facile à implémenter avec Asterisk, et probablement
plus facile encore avec FreeSwitch.

> On s'est posé la question chez Ovh sur l'ENUM, le 1er point n'était
> pas bloquant. Le 2ème si. Je n'ai pas envie de gerer le voice-spam
> entrant (déjà il faut le gerer en interne, fait par les clients qui
> prennent 30 connexions simu sur un trunk SIP et font 1 tests /min
> vers les numeros exterieurs à ovh. l'IP, ça facilité plein de chose,
> y compris les abus ...). En mettant un cout à des options, ça resoud
> ces problemes là. l'auroregulation ? :)

Le mieux est toujours de traiter le problème à la racine, peut être
qu'en faisant des abonnements plus chers sans ses limites, tu aurais
aussi moins d'abus. C'est le low cost qui fait que ton réseau est
envahi d'amateurs et d'arnaqueurs, pas le fait que la technique le
permet. A défaut de superviser ou de filtrer à l'entrée  (identité,
compétence), le filtre du prix aide un peu... Donc le téléphone
gratuit financé par les appels entrants, c'est peut être juste pas le
bon modèle d'avenir.



-- 
Jérôme Nicolle
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [FRnOG] Routage téléphonique : ça coince

[Thomas Mangin]

Vu la section France de enumdata, c'est soit pas à jour, soit mal  
barré...


Autant que je sache, c'est a jour.


Maintenant, l'approche DNS est intéressante, et ça laisse BGP en place
pour faire passer du SCTP/IP plutôt que de router au travers de liens
SIP, c'est bien l'idée ?


Carrier ENUM, c'es plutôt l'équivalent des pages blanches pour un  
réseau. Je me sert d'ENUM et SIP en interne pour router les calls vers  
le bon serveur.
Enum pour les utilisateurs permet a deux telephones de se trouver -  
comme MX fait pour le mail - mais avec le risque sur la qualité que  
passer par un réseau publique entraine, et les risque de SPAM via SIP  
(SPIT).



Ca a l'air d'être une simple évolution pour fusionner les réseaux de
transport,  mais ça ne concerne pas le routage des appels en lui même,
je me trompe ?


C'est SS7 sur IP :)


DUNDI a pas l'air tout à fait au point


C'est un jouet sympa mais rien de plus qu'un jouet.


Que lui manque t il d'après toi ?


Support de l'industrie et d'etre capable de monter en charge avec le  
nombre de connections/relation
Maintenant, je ne suis pas un expert SIP alors mon avis vaut ce qu'il  
vaut.



A défaut de pouvoir causer intelligemment avec les gros, apparemment
inapte au dialogue même en les payant 4500€/jour, un régulateur a
justement pour mission de servir de médiateur et de suivre la
résolution des conflits.


Menacer de refuser de payer sa facture tant que c'est pas réglé car il  
a rupture de contact suffit souvent pour trouver le bon interlocuteur  
sans aller jusqu'en justice.
La peur de la douleur est plus efficasse que la douleur quelque soit  
le bâton utilise.


Pouvoir prouver de manier concrète que son interlocuteur n'est pas  
coopératif aide toujours (liste de coups de fils, mails, avec la date  
- les gens contacte, réponses, promesse faites et non tenues, etc.).  
Utiliser/Partager ces informations avec la société en question leur  
permet souvent de réaliser que (1) tu es sérieux (2) tu montes ton  
dossier et que ce n'est peut-etre pas une bonne idée pour eu de  
continuer sur cette voie.


Je n'ai jamais eu besoin d'aller au delà - je suis peut-etre chanceux.

Thomas

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

Re: [FRnOG] Routage t?l?phonique : ?a coince

[Guénolé SAUREL]

Le Mon, Oct 12, 2009 at 03:30:00PM +0200, J?r?me Nicolle racontait :
> Je constate de plus en plus fréquemment des anomalies de routage
> depuis les réseaux mobiles (SFR en tête) vers des fournisseurs de
> VoIP. Dernier exemple en date, un mobile SFR vers un 09 73 87 xx xx
> qui aboutit à moins de 5% des tentatives. Les keyyo ou autre b3g ne
> font pas beaucoup mieux avec des périodes de plusieurs heures ou aucun
> appel vers un de leurs numéros n'est connecté par l'opérateur mobile.
> 
> Question donc, est ce que c'est dû au réseau initiant l'appel ou au
> réseau le terminant ? Comment diagnostiquer ce genre d'anomalies quand
> on a pas la main sur l'interco SS7 ? 

Faire avec les outils du bord, par exemple essayer depuis plusieurs
réseaux différents.

Sinon, pour les 097387, ce message a dut révéiller le noc de * que
j'ai cru un moment disséminé par une épidémie de grippe A, et donc ca
devrait se résoudre sous peut.

Après sur le fond, les petits opérateurs voip n'ont pas forcément
la capacité de gérer eux même l'interco ss7 dans les meilleures
conditions, ou de le faire eux même. 
Et les offre de wholesale en la matière ne sont pas non plus toujours 
de la meilleur qualité.

PS : Y'a une liste officielle pour discuter de ce genre de chose entre 
gens du métier ?

-- 
 Guénolé SAUREL
 
  -> disponible au 20.11.09
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [FRnOG] Rou tage téléphonique : ça coince

[oles]

> >Ou est ce un réel manque de bonne volonté
> >ou l'obsolescence de la techno de routage en place qui pose un
> >problème ?
> 
> A mon avis, un peu des deux,  voir ENUM :
>  - User enum : see http://www.enumdata.org/
>  - Carrier enum : qui correspond a l'usage d'ENUM en interne par les  
> telcos pour router le traffic.

Je n'ai pas l'impression que la reponse colle à la question.
Juste pour 1 mot sur l'ENUM: "ça ne marchera pas"(c) pour 2
raisons: 
- je ne gagne pas 0.01Euro HT/min lorsque quelqu'un aboutit 
  l'appel sur mes numeros (0.12/0.15 Euro TTC/min sur un 
  08). etc.
- comme il n'y a pas de couts, les abus sont possible. le marketing 
  coute pas cher sur l'IP et le voice-spam a du sens. ça coutera 
  pas cher de mettre   un serveur avec du SIP qui essaie tous les 
  numeros puis ce que tu veux

On s'est posé la question chez Ovh sur l'ENUM, le 1er point n'était
pas bloquant. Le 2ème si. Je n'ai pas envie de gerer le voice-spam
entrant (déjà il faut le gerer en interne, fait par les clients qui
prennent 30 connexions simu sur un trunk SIP et font 1 tests /min
vers les numeros exterieurs à ovh. l'IP, ça facilité plein de chose,
y compris les abus ...). En mettant un cout à des options, ça resoud
ces problemes là. l'auroregulation ? :)

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

[FRnOG] Re: [FRnOG] Re: [FRnOG] Routage téléphonique : ça coince

[Jérôme Nicolle]

Thomas,

Le 12 octobre 2009 16:21, Thomas Mangin
 a écrit :
>> Mais... Comment ça peut marcher ?!?
>
> Mal :D
>
>> n'ont ils pas pu voir le coup venir ?
>
> Les telcos sont de gros dinosaures qui ne bougent pas vite, par contre
> attention a ne pas être dans leur chemin :D
>
>> Ou est ce un réel manque de bonne volonté
>> ou l'obsolescence de la techno de routage en place qui pose un
>> problème ?
>
> A mon avis, un peu des deux,  voir ENUM :
>  - User enum : see http://www.enumdata.org/
>  - Carrier enum : qui correspond a l'usage d'ENUM en interne par les telcos
> pour router le traffic.

Vu la section France de enumdata, c'est soit pas à jour, soit mal barré...

Maintenant, l'approche DNS est intéressante, et ça laisse BGP en place
pour faire passer du SCTP/IP plutôt que de router au travers de liens
SIP, c'est bien l'idée ?

> Je ne bosse pas pour un telco, mais je pense que Carrier ENUM est bcp plus
> déployé que User ENUM - autant que je sache c'est un peu le nouvel IGP
> téléphonique.
> Ce qu'il manque toujours, c'est BGP pour telco :D


> http://en.wikipedia.org/wiki/SIGTRAN

Ca a l'air d'être une simple évolution pour fusionner les réseaux de
transport,  mais ça ne concerne pas le routage des appels en lui même,
je me trompe ?

>
>> DUNDI a pas l'air tout à fait au point
>
> C'est un jouet sympa mais rien de plus qu'un jouet.

Que lui manque t il d'après toi ?

>  C'est quoi cette habitude des gens sur cette liste de penser que l'ARCEP
> c'est leur "GodMother" - La fee avec sa baguette magique qui peut tout
> regler !! ??

A défaut de pouvoir causer intelligemment avec les gros, apparemment
inapte au dialogue même en les payant 4500€/jour, un régulateur a
justement pour mission de servir de médiateur et de suivre la
résolution des conflits.

Si un problème survient et que les déséquilibres commerciaux présents
sur le marché ne permette pas aux acteurs victimes de l'anomalie de
remédier au problème, ce qui semble être précisément le cas puisque
les petits téléphonistes seraient raccordés sur des trunks au rabais
sans engagement qualitatif ou en tout cas pas respecté (je crois qu'on
a la confirmation indirecte, un petit opérateur pro a été coupé du
monde par FT cet aprem), l'ARCEP est là pour recevoir les demandes de
régulation et gérer la résolution du conflit.

En fait, ça n'est que l'étape amiable précédent des actions en
justice... On ne va pas engorger les tribunaux et flamber le cash en
juridique alors qu'on peut régler ça entre gens du métier, qu'en
penses tu ?

>
> Thomas
>
>



-- 
Jérôme Nicolle
06 19 31 27 14
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Re: [FRnOG] Routage téléphonique : ça coince

[Thomas Mangin]

Mais... Comment ça peut marcher ?!?


Mal :D


n'ont ils pas pu voir le coup venir ?


Les telcos sont de gros dinosaures qui ne bougent pas vite, par contre  
attention a ne pas être dans leur chemin :D



Ou est ce un réel manque de bonne volonté
ou l'obsolescence de la techno de routage en place qui pose un
problème ?


A mon avis, un peu des deux,  voir ENUM :
 - User enum : see http://www.enumdata.org/
 - Carrier enum : qui correspond a l'usage d'ENUM en interne par les  
telcos pour router le traffic.


Je ne bosse pas pour un telco, mais je pense que Carrier ENUM est bcp  
plus déployé que User ENUM - autant que je sache c'est un peu le  
nouvel IGP téléphonique.

Ce qu'il manque toujours, c'est BGP pour telco :D

Quelqu'un de mieux place pour en parler ??


Quelqu'un sait s'il y a des projets de remplacement de SS7 ?


http://en.wikipedia.org/wiki/SIGTRAN


DUNDI a pas l'air tout à fait au point


C'est un jouet sympa mais rien de plus qu'un jouet.


P.S.: Bon ben je viens d'avoir un contact à la cellule réseau SFR, ils
m'ont raccroché au nez à défaut de comprendre le problème... Quelqu'un
de SFR me rappelles avant que j'ailles me plaindre dans les jupes de
l'ARCEP ?


 C'est quoi cette habitude des gens sur cette liste de penser que  
l'ARCEP c'est leur "GodMother" - La fee avec sa baguette magique qui  
peut tout regler !! ??


Thomas

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

[FRnOG] Re: [FRnOG] Routage téléphonique : ça coince

[Jérôme Nicolle]

Raphael,

Le 12 octobre 2009 15:45, Raphael Mazelier  a écrit :
> Le routage téléphonique est un domaine un peu effrayant quand on travaille
> dedans. En gros il faut imaginer un internet sans BGP, avec des milliers de
> routes statiques chez tout les opérateurs, avec des tuyaux plus ou moins
> bien dimensionnés.

Mais... Comment ça peut marcher ?!?

A l'époque reculée ou on avait un opérateur par pays, je comprends que
ça aie pu marcher. Mais l'ouverture du marché multipliant les
opérateurs, ça allait forcement tendre vers cette situation, n'ont ils
pas pu voir le coup venir ? Ou est ce un réel manque de bonne volonté
ou l'obsolescence de la techno de routage en place qui pose un
problème ?

> De plus il faut considérer que certains opérateurs ne
> surveillent absolument pas l'état de leur faisceaux. Bizarrement les
> intercos SS7 ou ISDN ont une certaine tendance à se bloquer pour pas grand
> chose, et le déblocage est manuel...

C'est là qu'on reconnaît les peon du réseau...

> Concernant les congestions c'est complexe, car cela peut arriver à
> énormément d'endroit. Par exemple pour prendre l'exemple de SFR vers B3G (au
> hasard) il faut savoir que SFR et B3G n'ont pas d'interco directe. Donc SFR
> a le loisir d'envoyer le traffic B3G vers ce qu'il l'arrange. Du coté B3G la
> collecte se fait principalement par Completel et FT.  A priori on n'a pas de
> saturation en entrée, donc on peut considérer que le problème se situe entre
> les deux. A savoir au choix : SFR, autre, Completel, FT.
> J'aurai tendance à taper sur SFR car je penses que pour tout les opérateurs
> "alternatifs" ils choissisent un faisceaux de sortie un peu pourri et pas
> surveillé, mais c'est vraiment pas sur.
>
> Les Télécoms c'est vraiment un monde merveilleux.

Entre la saturation des réseaux data mobile, le goulet d'étranglement
(et de complexité / coût) SS7, la qualité d'appels (acheminement et
audio) sur les réseaux mobiles, j'ai l'impression qu'il y a un sacré
relâchement du coté des principaux opérateurs.

Quelqu'un sait s'il y a des projets de remplacement de SS7 ? Ca fait
quelque mois que cette histoire de BGP de la téléphonie me trotte dans
la tête, mais DUNDI a pas l'air tout à fait au point, surtout au
niveau de l'interopérabilité et robustesse (un takeover sur abus de
confiance semble facile, un peu comme un BGP remarque, sauf que dans
le domaine de la téléphonie c'est vraiment problématique) et que les
accords de confiance sur l'acceptation d'annonce risquent d'être aussi
impossible à obtenir avec les gros que du peering avec 3215...

P.S.: Bon ben je viens d'avoir un contact à la cellule réseau SFR, ils
m'ont raccroché au nez à défaut de comprendre le problème... Quelqu'un
de SFR me rappelles avant que j'ailles me plaindre dans les jupes de
l'ARCEP ?

-- 
Jérôme Nicolle
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Routage téléphonique : ça coinc e

[Raphael Mazelier]

Le 12/10/2009 15:30, Jérôme Nicolle a écrit :

Bonjour !

Bien qu'on ait plutôt l'habitude de causer IP et BGP ici, la
convergence fait qu'on doit se taper quelques morceaux en SS7&co de
temps en temps.

Je constate de plus en plus fréquemment des anomalies de routage
depuis les réseaux mobiles (SFR en tête) vers des fournisseurs de
VoIP. Dernier exemple en date, un mobile SFR vers un 09 73 87 xx xx
qui aboutit à moins de 5% des tentatives. Les keyyo ou autre b3g ne
font pas beaucoup mieux avec des périodes de plusieurs heures ou aucun
appel vers un de leurs numéros n'est connecté par l'opérateur mobile.

Question donc, est ce que c'est dû au réseau initiant l'appel ou au
réseau le terminant ? Comment diagnostiquer ce genre d'anomalies quand
on a pas la main sur l'interco SS7 ? Est ce que ça vaut le coup
d'incendier les tekos de l'opérateur mobile ? Et quels problèmes du
même ordre avez vous pu constater ?

Si on avait été vendredi, j'auras volontiers présumé que le problème
se situe chez les gros opérateurs mobiles, et qu'ils ont un intérêt
évident à dégrader la qualité de service vers leurs concurrents, ce
qui serait une grave atteinte à la neutralité, à la libre concurrence,
à la vie, à l'univers et à tout le reste... Mais nous ne sommes pas
vendredi.

Merci !

P.S.: Raffit, tu rappelles ? ;)


   


Bonjour,

Le routage téléphonique est un domaine un peu effrayant quand on 
travaille dedans. En gros il faut imaginer un internet sans BGP, avec 
des milliers de routes statiques chez tout les opérateurs, avec des 
tuyaux plus ou moins bien dimensionnés. De plus il faut considérer que 
certains opérateurs ne surveillent absolument pas l'état de leur 
faisceaux. Bizarrement les intercos SS7 ou ISDN ont une certaine 
tendance à se bloquer pour pas grand chose, et le déblocage est manuel...


Concernant les congestions c'est complexe, car cela peut arriver à 
énormément d'endroit. Par exemple pour prendre l'exemple de SFR vers B3G 
(au hasard) il faut savoir que SFR et B3G n'ont pas d'interco directe. 
Donc SFR a le loisir d'envoyer le traffic B3G vers ce qu'il l'arrange. 
Du coté B3G la collecte se fait principalement par Completel et FT.  A 
priori on n'a pas de saturation en entrée, donc on peut considérer que 
le problème se situe entre les deux. A savoir au choix : SFR, autre, 
Completel, FT.
J'aurai tendance à taper sur SFR car je penses que pour tout les 
opérateurs "alternatifs" ils choissisent un faisceaux de sortie un peu 
pourri et pas surveillé, mais c'est vraiment pas sur.


Les Télécoms c'est vraiment un monde merveilleux.


--
raph




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

Re: [FRnOG] Routage téléphonique : ça coince

[Alexandre Legrix]

Salut.

On Mon, 2009-10-12 at 15:30 +0200, Jérôme Nicolle wrote:
> Bonjour !
> 
> Bien qu'on ait plutôt l'habitude de causer IP et BGP ici, la
> convergence fait qu'on doit se taper quelques morceaux en SS7 &co de
> temps en temps.
> 
> Je constate de plus en plus fréquemment des anomalies de routage
> depuis les réseaux mobiles (SFR en tête) vers des fournisseurs de
> VoIP. Dernier exemple en date, un mobile SFR vers un 09 73 87 xx xx
> qui aboutit à moins de 5% des tentatives. Les keyyo ou autre b3g ne
> font pas beaucoup mieux avec des périodes de plusieurs heures ou aucun
> appel vers un de leurs numéros n'est connecté par l'opérateur mobile.
> 
> Question donc, est ce que c'est dû au réseau initiant l'appel ou au
> réseau le terminant ? Comment diagnostiquer ce genre d'anomalies quand
> on a pas la main sur l'interco SS7 ? Est ce que ça vaut le coup
> d'incendier les tekos de l'opérateur mobile ? Et quels problèmes du
> même ordre avez vous pu constater ?
> 
> Si on avait été vendredi, j'auras volontiers présumé que le problème
> se situe chez les gros opérateurs mobiles, et qu'ils ont un intérêt
> évident à dégrader la qualité de service vers leurs concurrents, ce
> qui serait une grave atteinte à la neutralité, à la libre concurrence,
> à la vie, à l'univers et à tout le reste... Mais nous ne sommes pas
> vendredi.
> 
> Merci !
> 

Je remarque le même type de soucis.
C'est une très bonne question de jerome de savoir comment diagnostiquer
de tel soucis.


> P.S.: Raffit, tu rappelles ? ;)

P.S : En parlant de Raffit, depuis ma ligne Keyyo une fois sur deux
j'arrive pas a joindre Nerim.

> 
-- 
Alexandre Legrix
Euro Web - Location de serveurs dediés et infogérés.
Tel : 01 75 43 75 75

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

[FRnOG] Routage téléphonique : ça coince

[Jérôme Nicolle]

Bonjour !

Bien qu'on ait plutôt l'habitude de causer IP et BGP ici, la
convergence fait qu'on doit se taper quelques morceaux en SS7 &co de
temps en temps.

Je constate de plus en plus fréquemment des anomalies de routage
depuis les réseaux mobiles (SFR en tête) vers des fournisseurs de
VoIP. Dernier exemple en date, un mobile SFR vers un 09 73 87 xx xx
qui aboutit à moins de 5% des tentatives. Les keyyo ou autre b3g ne
font pas beaucoup mieux avec des périodes de plusieurs heures ou aucun
appel vers un de leurs numéros n'est connecté par l'opérateur mobile.

Question donc, est ce que c'est dû au réseau initiant l'appel ou au
réseau le terminant ? Comment diagnostiquer ce genre d'anomalies quand
on a pas la main sur l'interco SS7 ? Est ce que ça vaut le coup
d'incendier les tekos de l'opérateur mobile ? Et quels problèmes du
même ordre avez vous pu constater ?

Si on avait été vendredi, j'auras volontiers présumé que le problème
se situe chez les gros opérateurs mobiles, et qu'ils ont un intérêt
évident à dégrader la qualité de service vers leurs concurrents, ce
qui serait une grave atteinte à la neutralité, à la libre concurrence,
à la vie, à l'univers et à tout le reste... Mais nous ne sommes pas
vendredi.

Merci !

P.S.: Raffit, tu rappelles ? ;)

-- 
Jérôme Nicolle
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Conseil IPV6

[Thomas Mangin]

Salut,

Voici ce que nous avons fait pour notre allocation :

2a02:0b80:::::52db:0004
   /16  /32  /48  /64  /80  /96  /112 /128

Notre Infra est dans  2a02:b80:0::/48 (le premier /48 dans  
2a02:b80::/32) divise en 65535 /64's


2a02:0b80::::/64   Core Infrastructure
2a02:0b80::0001::/64   Core Infrastructure (overspill)
2a02:0b80::0002::/64   Point-To-Point Links
2a02:0b80::0003::/64   Point-To-Point Links (overspill)


Chaque router/switch a un ID unique que nous utilisons pour générer le  
nom de l'équipement. Par exemple, m7i-4 (quatrième router - de tous  
les routeurs - modèle M7i), nous donnons aussi un ID aux routeurs  
logiques (juniper's logical routers).


2a02:b80:0:[0,1]:location:deviceid:purpose:(value)

Purpose peut etre  0 = /128s for loopbacks, 1 = /112 internal router  
transfer net, etc

par exemple:
2a02:b80::4:0:1  router 4 admin loop
2a02:b80::4:0:2  router 4 bgp loopback
etc.

As we use the xxx.xxx.4.0/24 for IPv4 service IP (/32 customers are  
accessing), we decided to use

2a02:0b80::0006::/64   Service IPs
Nous avons d'autres /64 (utilise comme des /24 en v4) pour connecter  
les serveurs au réseau.

Les /128 sont redistribue soit en utilisant BGP ou routes statiques.

2a02:b80:0:6:portnum-in-hex:type:spare:instance

Auth DNS 1:   2a02:b80:0:6:35:a:0:1/128(a pour Auth, 0x35 =>  
port 53)

Auth DNS 2:   2a02:b80:0:6:35:a:0:2/128
Caching DNS 1 :   2a02:b80:0:6:35:c:0:1/128 (c pour Caching)
Caching DNS 2 :   2a02:b80:0:6:35:c:0:2/128
NTP 1 :   2a02:b80:0:6:7b:0:0:1/128
NTP 2 :   2a02:b80:0:6:7b:0:0:2/128


Thomas

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