date:20180516

[FRnOG] [MISC] Séminaire OWF « Le jour d’après »

2018-05-16 Par sujet David Ponzone

Quelqu’un était au séminaire OWF ?
Intéressant ?
Ils ont offert quoi pour faire oublier 2 jours de panne ?
Si une âme charitable pouvait m’envoyer le PPT de la présentation, ça m’évitera 
d’attendre le mailing général dans 3 semaines :)

Merci!

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

Re: [FRnOG] [MISC] Quand c'est pas le jour (14/05) !

2018-05-16 Par sujet Guillaume Barrot

https://france3-regions.francetvinfo.fr/auvergne-rhone-alpes/savoie/albertville/15-000-foyers-reseau-mobile-maurienne-apres-explosion-du-pont-albertin-1475147.html

Quand tu comprends que les nodeB de la Maurienne sont en pendulaire sur une
unique fibre qui passait par ce pont ...

2018-05-15 19:33 GMT+02:00 Xavier ROCA :

> https://www.ledauphine.com/savoie/2018/05/14/faits-divers
>
>
>
>
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement,

Guillaume BARROT

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

Re: [FRnOG] [MISC] Panne Nationale voix Orange : quand le service client est magique

2018-05-16 Par sujet Guillaume Barrot

de la TCAM pour router des n° de tel, le truc le plus statique du monde, et
pour le flux le moins consommateur en ressource de forwarding 
Nan, mais on peut surement aussi envoyer un coursier avec une clef usb à
chaque nouvelle regle de porta, chez chaque opérateur du monde, ça coutera
surement aussi cher...

Ce genre d'info est actuellement mis à jour à base d'envoi de fichier txt
sur un serveur à la con, une fois toutes les X heures.
Si déjà on passe sur une mécanique de type (L)DAP avec une synchro en
https/json, ou un truc du genre, on est 1000 fois mieux que le système
actuel.

Le 16 mai 2018 à 08:37, Raphaël Jacquot  a écrit :

>
>
> On 15/05/2018 19:28, Michel Py wrote:
>
> Pas grand-chose aujourd'hui si c'est de la RAM, mais si c'est de la TCAM
>> çà coute la peau du postérieur.
>> Un bit de TCAM çà prend 12 à 14 transistors si je comprends bien, au lieu
>> de 6 pour de la SRAM et 3 pour de la DRAM.
>>
>
> soit 1200 milliards environ
>
> étant donné qu'on en est a environ 20 milliards actuellement, il manque
> encore 2 ordres de grandeur, ou alors il va falloir optimiser comment on
> stocke les infos dans la TCAM
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

-- 
Cordialement,

Guillaume BARROT

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

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet Guillaume Barrot

Sinon, il reste LISP.
On prend l'e164 en EID, et une @IPv6 en RLOC (ça ne marchera que pour la
VoIP) ou bien l'adresse SS7 (pour le legacy).

C'est un système à base de mapping, donc de la grosse DB, et là, c'est
quand même carrément statique le bordel (on swappe pas de n° de tel tous
les jours, et les IPv6 pour 99% des besoins non plus, vu que de
l'extérieur, l'IPv6 sera surement celle du PxTR et non celle du device
final, donc un truc stable dans le temps).

Backend sur une base repliquée / shardée type MongoDB, un truc du genre, et
ça doit pouvoir scaller des milliards de mapping.

Et puis pour une fois qu'on pourrait trouver une application concrète à ce
protocole :D

Le 16 mai 2018 à 18:27, Guillaume Barrot  a
écrit :

> D'où mon analogie à EVPN. On summarise pas les @Macs. Depuis les
> portabilités de n°, on ne peut plus summariser les routes SS7 non plus :).
> Bref, c'est bien du routage de "/32" pour n millions de clients, mais ça
> reste ultra statique.
>
> Le 15 mai 2018 à 20:18, David Ponzone  a écrit :
>
>> Ce qui me dérange, c’est que vous semblez oublier qu’une plage de numéros
>> client c’est par exemple un /36 dans ton exemple (ZABPQMCD), mais il arrive
>> souvent qu’un numéro ait été sorti pour une ligne analogique (fax) donc ton
>> /36 devient 9 /40.
>> Difficile d’évaluer le nombre de routes que ça représente, probablement
>> gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va
>> faire mal (les particuliers ont tous un /40, et rien à aggréger).
>>
>> J’ai raté un truc ?
>>
>> On 15 mai 2018 20:07 +0200, Alexis Lameire ,
>> wrote:
>> > Hello frnog,
>> >
>> > Je ne suis pas un spécialiste voix, mais je suis aussi convaincu qu'il
>> y a
>> > des choses a faire avec une extensions à BGP. Je vais rajouter my 2
>> cent au
>> > schmilblick
>> >
>> > qu'est ce qui fait que BGP c'est le bien :
>> > * l'aggrégation des prefix
>> > * l'algo dee routage déjà tout fait
>> > * la responsabilité du routage laissé à chaque acteurs de la boucle
>> > * l'ouverture a d'autre protocole.
>> >
>> > Déjà premier truc dont je suis pas d'accord, la RFC sur l'EVPN me semble
>> > pas trop adapté, j’aurais tendance à me basé sur l'extension vpnv4.
>> >
>> > On a besoin en premier lieux de définir des zones cloisonnées de
>> routages,
>> > avec un numéro d'identification par pays. Dans ce cadre la, le country
>> code
>> > peut être utiliser.
>> > Ensuite chaque entité à besoin d'être identifié à la fois de façon
>> globale
>> > et de façon locale. L'identité sur internet me semble être un numéro
>> d'AS
>> > enregistrer auprès d'un RIR il n'y a pas à tortiller mille an. Par
>> contre
>> > d'un point de vue local cela dépend de l'entité administrative locale.
>> Dans
>> > le cadre de la france, l'ARCEP. On pourrait par exemple concevoir le
>> numéro
>> > d'enregistrement auprès de l'ARCEP comme une bonne variable
>> > d'identification. Mais il s'agit d'un champ de taille fixe dépendant du
>> > pays.
>> >
>> > Le second élément à prendre en compte est l’agrégation. Nous avons un
>> > soucis avec tous les plan de numérotation c'est qu'ils sont conçu en
>> base
>> > 10 et non dans une puissance de 2. Il faut donc trouver un codage
>> > intelligent. Je propose de coder les routes et les masques en
>> > BCD[1]
>> >
>> > ainsi la EZABPQ 011234 se code avec :
>> > un prefix binaire représenté en hexa : 01:12:34:00:00
>> > un masque binaire représenté en hexa : FF:FF:FF:00:00
>> >
>> > On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes
>> > spécifique étant en /40
>> >
>> > Il faut maintenant fournir les services d'un serveur de route auprès des
>> > différents opérateur. Un bon serveur de route se doit :
>> > * de vérifier la validité de ses membres : on peut ici utiliser RPKI, il
>> > faut simplement héberger les clef au niveau de l'APNF ou avoir une
>> > procédure auprès de l'iX pour vérifier la validité du peer.
>> > * de vérifier les bogon : comme certains transitaire vont vérifier les
>> > bases des RIR, la ressource de numérotion peut être vérifié auprès de
>> > l'APNF.
>> > * de vérifier la sécurité des annonce : on a une RFC qui est récente :
>> > BGPSEC
>> >
>> > La ou ça s'arete, c'est qu'en pratique les règle d'interco peuvent
>> différer
>> > d'un opérateur à l'autre et il faut pouvoir prendre en compte ces
>> > changement. Les informations de numérotation sont ainsi à fournir à la
>> > brique du backbone de l'opérateur téléphonique qui gére le LCR (pas la
>> NUM,
>> > on a toujours le cas des numéro d'urgence qui sont à réencoder et qui ne
>> > sont pas adapté à BGP (le cas des numéros qui changent selon l'heure)).
>> > C'est aussi nécessaire par ce que l'opérateur doit être en mesure
>> > d'appliquer des mesures anti fraude avant de transférer le trafic à
>> > l'I-SBC.
>> >
>> > Pour gérer l'interco au niveau du SBC il faut aussi prévoir deux champ
>> > obligatoire avec l'addresse du peer

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet Guillaume Barrot

D'où mon analogie à EVPN. On summarise pas les @Macs. Depuis les
portabilités de n°, on ne peut plus summariser les routes SS7 non plus :).
Bref, c'est bien du routage de "/32" pour n millions de clients, mais ça
reste ultra statique.

Le 15 mai 2018 à 20:18, David Ponzone  a écrit :

> Ce qui me dérange, c’est que vous semblez oublier qu’une plage de numéros
> client c’est par exemple un /36 dans ton exemple (ZABPQMCD), mais il arrive
> souvent qu’un numéro ait été sorti pour une ligne analogique (fax) donc ton
> /36 devient 9 /40.
> Difficile d’évaluer le nombre de routes que ça représente, probablement
> gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va
> faire mal (les particuliers ont tous un /40, et rien à aggréger).
>
> J’ai raté un truc ?
>
> On 15 mai 2018 20:07 +0200, Alexis Lameire ,
> wrote:
> > Hello frnog,
> >
> > Je ne suis pas un spécialiste voix, mais je suis aussi convaincu qu'il y
> a
> > des choses a faire avec une extensions à BGP. Je vais rajouter my 2 cent
> au
> > schmilblick
> >
> > qu'est ce qui fait que BGP c'est le bien :
> > * l'aggrégation des prefix
> > * l'algo dee routage déjà tout fait
> > * la responsabilité du routage laissé à chaque acteurs de la boucle
> > * l'ouverture a d'autre protocole.
> >
> > Déjà premier truc dont je suis pas d'accord, la RFC sur l'EVPN me semble
> > pas trop adapté, j’aurais tendance à me basé sur l'extension vpnv4.
> >
> > On a besoin en premier lieux de définir des zones cloisonnées de
> routages,
> > avec un numéro d'identification par pays. Dans ce cadre la, le country
> code
> > peut être utiliser.
> > Ensuite chaque entité à besoin d'être identifié à la fois de façon
> globale
> > et de façon locale. L'identité sur internet me semble être un numéro d'AS
> > enregistrer auprès d'un RIR il n'y a pas à tortiller mille an. Par contre
> > d'un point de vue local cela dépend de l'entité administrative locale.
> Dans
> > le cadre de la france, l'ARCEP. On pourrait par exemple concevoir le
> numéro
> > d'enregistrement auprès de l'ARCEP comme une bonne variable
> > d'identification. Mais il s'agit d'un champ de taille fixe dépendant du
> > pays.
> >
> > Le second élément à prendre en compte est l’agrégation. Nous avons un
> > soucis avec tous les plan de numérotation c'est qu'ils sont conçu en base
> > 10 et non dans une puissance de 2. Il faut donc trouver un codage
> > intelligent. Je propose de coder les routes et les masques en
> > BCD[1]
> >
> > ainsi la EZABPQ 011234 se code avec :
> > un prefix binaire représenté en hexa : 01:12:34:00:00
> > un masque binaire représenté en hexa : FF:FF:FF:00:00
> >
> > On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes
> > spécifique étant en /40
> >
> > Il faut maintenant fournir les services d'un serveur de route auprès des
> > différents opérateur. Un bon serveur de route se doit :
> > * de vérifier la validité de ses membres : on peut ici utiliser RPKI, il
> > faut simplement héberger les clef au niveau de l'APNF ou avoir une
> > procédure auprès de l'iX pour vérifier la validité du peer.
> > * de vérifier les bogon : comme certains transitaire vont vérifier les
> > bases des RIR, la ressource de numérotion peut être vérifié auprès de
> > l'APNF.
> > * de vérifier la sécurité des annonce : on a une RFC qui est récente :
> > BGPSEC
> >
> > La ou ça s'arete, c'est qu'en pratique les règle d'interco peuvent
> différer
> > d'un opérateur à l'autre et il faut pouvoir prendre en compte ces
> > changement. Les informations de numérotation sont ainsi à fournir à la
> > brique du backbone de l'opérateur téléphonique qui gére le LCR (pas la
> NUM,
> > on a toujours le cas des numéro d'urgence qui sont à réencoder et qui ne
> > sont pas adapté à BGP (le cas des numéros qui changent selon l'heure)).
> > C'est aussi nécessaire par ce que l'opérateur doit être en mesure
> > d'appliquer des mesures anti fraude avant de transférer le trafic à
> > l'I-SBC.
> >
> > Pour gérer l'interco au niveau du SBC il faut aussi prévoir deux champ
> > obligatoire avec l'addresse du peer sur l'IX ainsi que la norme d'interco
> > suivie. Ceci est nécessaire par ce qu'on ne souhaite pas que les RR gére
> le
> > dataplane.
> >
> > Ceci clos la partie purement voix. Pour gérer l'interco sur l'IX et
> éviter
> > le L2 il faudra aussi prévoir une interco BGP classique sur le routeur en
> > aval du I-SBC pour redistribuer les routes pour joindre les SBC des
> copain.
> > Mais rien de bien complexe.
> >
> > Enfin, d'un point de vue facturation, ayant dans les annonces BGP le
> numero
> > d'enregistrement auprès de l'APNF il est facile de mettre ça dans les CDR
> > pour se refacturer entre copain. On pourrait même concevoir que l'IX
> > fournisse la liste des adresse de facturation de ses membre pour
> simplifier
> > les choses voir pour les plus petit prenne en charge la refacturation
> > contre quelques % des sommes dues.
> >
> > C'était un long

[FRnOG] [JOBS] À la recherche d'un ingénieur système / virtualisation expérimenté à Bordeaux

2018-05-16 Par sujet BLANCPAIN Nicolas

Bonjour,

A la recherche d'un ingénieur système / virtualisation expérimenté à Bordeaux.
Me contacter par email.

Nicolas

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

[FRnOG] [JOBS] À la recherche d'une alternance sur Lyon

2018-05-16 Par sujet Jonas Chopin

Bonjour à tous,

Je me permets d'envoyer un mail sur cette liste car je suis actuellement
à la recherche d'un contrat en alternance en administration systèmes et
réseaux sur Lyon.

Ayant initialement un parcours de webmaster et SEO, j'ai eu l'occasion
d'appréhender l'administration systèmes en autodidacte et lors de mes
différentes expériences professionnelles (notamment en tant
qu'auto-entrepreneur ainsi qu'en stage). Aujourd'hui, je souhaite
vivement me réorienter vers ce domaine.

Actuellement deux possibilités de formation s'offrent à moi :

  * Je suis pris au Greta pour une formation individualisée d'un an ou
un an et demi (tout dépend du rythme d'alternance). L'alternance se
ferait en contrat de professionnalisation.

https://www1.ac-lyon.fr/greta/formation/administrateur-systeme-et-reseau-informatique-titre-professionnel-niveau-iii-inscrit-rncp?id=11732
  * J'ai également postulé à la formation Administrateur systèmes et
réseaux de l'Ipi (groupe IGS) et suis en cours de procédure
d'admission. D'une durée de 12 mois, l'alternance s'effectue dans le
cadre d'un contrat d'apprentissage.

http://www.cfa-igslyon.com/formation-en-apprentissage/titre-rncp-admin-systeme-reseaux-bdd/

Veuillez trouver mon cv à cette url :
https://framadrop.org/r/GkcVzAaXrV#GekoRqo8RLJqpABs4j5XII7rN6ZG40CEM3K7uXZJEGU=

Si vous n'êtes pas en mesure de me proposer un poste, accepteriez-vous
de transférer ma candidature à un collègue ou confrère susceptible
d'être intéressé ? Je suis également à l'écoute de tout conseil pouvant
m'aider dans ma recherche.

Merci à vous !

Bien cordialement,

-- 
Jonas Chopin
cont...@jonas-chopin.com
https://jonas-chopin.com
PGP : 0x26CF55A5

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

Re: [FRnOG] [TECH] Accès portail client Orange

2018-05-16 Par sujet Hugues Voiturier

C’est corrigé visiblement, vous confirmez ? 

Hugues 
AS50628 - AS57199

> On 16 May 2018, at 14:10, GUILLOT Florent  wrote:
> 
> Donc si je comprends bien, Orange (3215) demande à OpenTransit (5511) de 
> black holer ces IP, et garde dans son pool DNS (espaceclientv3.orange.fr 
> ) des IP qu'il black hole volontairement.
> Donc c'est "normal" que l'espace client d'Orange soit inaccessible depuis 
> tout plein d'endroits...
> Merci pour ces infos.
> Florent
> 
> -Message d'origine-
> De : felix.bouy...@setenforce.one  
> [mailto:felix.bouy...@setenforce.one ]
> Envoyé : mercredi 16 mai 2018 12:07
> À : Laurent GUERBY >; GUILLOT 
> Florent >; 
> frnog-t...@frnog.org 
> Objet : Re: [FRnOG] [TECH] Accès portail client Orange
> 
> J'avais eu une réponse d'Opentransit - AS5511 (par lequel on passe si on est 
> chez Cogent ou NTT par exemple) le 4 mai :
> 
> "Hello
> 
> IP 193.252.122.175 is black holed by customer itself through Arbor tool for 
> the security reason,  The BH will be running for at least one week.
> 
> At our end  case - 1804Z90259 is open.
> 
> Will share further update, once we have new info in this ."
> 
> Pas eu d'info depuis, je suppose qu'ils sont toujours attaqués.
> 
> Félix
> 
> 14 mai 2018 11:32 "Laurent GUERBY"  a écrit:
> 
>> On Mon, 2018-05-14 at 07:25 +, GUILLOT Florent wrote:
>> 
>>> Bonjour à tous,
>>> 
>>> On a des soucis pour accéder à https://espaceclientv3.orange.fr  dep
>>> uis Level3.
>>> 
>>> traceroute to espaceclient.orange.fr (193.252.133.37), 30 hops max,
>>> 60 byte packets
>>> 1  gateway (10.0.2.2)  0.120 ms  0.048 ms  0.157 ms
>>> 2  10.158.70.1 (10.158.70.1)  2.815 ms  2.800 ms  2.964 ms
>>> 3  192.168.252.9 (192.168.252.9)  2.937 ms  2.904 ms  2.985 ms
>>> 4  192.168.254.254 (192.168.254.254)  4.535 ms  4.891 ms  4.876 ms
>>> 5  5.149.184.2 (5.149.184.2)  33.395 ms  33.562 ms  34.971 ms
>>> 6  172.31.31.6 (172.31.31.6)  7.157 ms  7.167 ms  7.136 ms
>>> 7  172.31.31.30 (172.31.31.30)  7.109 ms  3.528 ms  3.421 ms
>>> 8  ge-6-16.car1.lyon1.level3.net (212.73.204.113)  3.381 ms  3.351 ms
>>> 4.618 ms
>>> 9  * * *
>>> 10  * * *
>>> 11  * * *
>>> 
>>> Une petite mesure avec les sondes atlas montre bien qu’on est pas les
>>> seuls : https://atlas.ripe.net/measurements/12456082/#!probes
>>> En gros, tous ceux qui peer en direct avec AS3215 ont l’air d’être
>>> OK, mais pour les autres c’est KO.
>>> 
>>> Le plus drôle c’est que ça fait bien 2/3 semaines que c’est comme ça
>>> !
>>> Y a quelqu’un par ici qui sait ce qui se passe (ou qui est en mesure
>>> de réparer) ? 
>>> 
>>> Bonne journée
>>> Florent GUILLOT
>> 
>> Bonjour,
>> 
>> Pareil avec 24600 et 8891 injoignable via cogent mais ok via un peer
>> qui passe par 3215, la liste des regles custom pour les petits AS
>> orange grossit petit a petit chez nous :)
>> 
>> #wanadoo portail
>> if (bgp_path ~ [= * 3215 24600 =]) then preference = 600; #orange
>> portail if (bgp_path ~ [= * 3215 8891 =]) then preference = 600;
>> 
>> Sincèrement,
>> 
>> Laurent
>> AS197422 http://tetaneutral.net
>> 
>>> __
>>> Ce message contient des informations dont le contenu est susceptible
>>> d' etre confidentiel. Il est destine au(x) destinataire(s) indique(s)
>>> exclusivement.
>>> A moins que vous ne fassiez partie de la liste des destinataires, ou
>>> que vous soyez habilite a recevoir le mail a leur place, il vous est
>>> interdit de le copier, de l'utiliser ou de devoiler son contenu a un
>>> tiers.
>>> Si vous avez recu cet email par erreur, merci de prendre contact avec
>>> l'emetteur.
>>> Les opinions exprimees dans cet e-mail sont celles de l'emetteur et
>>> ne refletent pas necessairement celles de l'entreprise.
>>> Ce e-mail peut contenir des pieces jointes dont certaines pourraient
>>> contenir des virus qui pourraient endommager votre systeme
>>> informatique.
>>> La compagnie a pris toutes dispositions afin de minimiser ce risque
>>> et decline toute responsabilite pour toute perte ou dommage resultant
>>> directement ou indirectement de l'utilisation de cet email ou de son
>>> contenu.
>>> Il vous appartient d'effectuer vos propres controles anti-virus avant
>>> d'ouvrir la ou les pieces jointes.
>>> __
>>> 
>>> ---
>>> Liste de diffusion du FRnOG
>>> http://www.frnog.org
>> 
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org
> __
> Ce message contient des informations dont le contenu est susceptible d' etre 
> confidentiel. Il est destine au(x) destinataire(s) indique(s)

Re: [FRnOG] [TECH] Serveur d'authentification

2018-05-16 Par sujet Stephane Branchoux


Bonjour,

Pour la connexion aux équipements réseau, j'utilise freeradius sous 
Linux ( avec backend openldap) depuis de nombreuses années .


La gestion des mots de passe devrait s'effectuer coté annuaire.

Sinon, il y a Cisco ISE qui doit répondre à beaucoup de ces points . La 
partie Tacacs dans Cisco ISE est payante, je garde donc encore 
Freeradius pour cette fonctionnalité.


Cordialement,

Le 15/05/2018 à 06:55, marcel.durega...@yahoo.fr a écrit :

Bonjour la liste,

Auriez-vous des conseils concernant un serveur d'authentification radius
(si il fait tacacs en plus, c'est un avantage) pour l'authentification
d'utilisateurs sur des devices (typiquement switch, routeurs cisco, cpe
divers, etc), qui puisse:

- gï¿½rer des groupes d'utilisateurs
- gï¿½rer 'simplement' les attributs radius (on n'a pas que du cisco, mais
plusieurs fabricants)
- permettre de forcer une politique de mots de passe (min 12 caractï¿½res,
avec chiffres, caractï¿½res spï¿½ciaux, etc...)
- permettre de dï¿½finir une durï¿½e (on veut que les credentials ne durent
que 3mois, et qu'on doive dï¿½finir un nouveau mdp ensuite)
- le must (mais j'ai peur que ce soit propre ï¿½ tacacs), qui permettre de
changer le mdp ï¿½ la volï¿½e en se logguant sur la CLI cisco. p.e on se
connecte ï¿½ un router cisco avec nos credentials, le serveur radius donne
son ack, mais impose le changement de mdp car il a expirï¿½ (le supplicant
est forcï¿½ de changer son mdp, via l'interface de l'authenticator)
- si possible pas sous windows, mais si le produit est vraiment bien, ok
pour du windows.
- le module de billing (typique ï¿½ radius) n'a aucune importance pour nous.


L'ex ACS de cisco ï¿½tait bien, mais bien trop complet (et complexe) pour
ce simple besoin, et trop cher.
On ne cherche pas forcï¿½ment du free, une solution payante (mais pas
exorbitante) est possible.

Merci d'avance,


--
Marcel


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


--
Stephane BRANCHOUX
Centre de Ressources Informatiques de l'Université de Perpignan.
Systèmes/Réseaux - RSSI
mailto:stephane.branch...@univ-perp.fr
04 68 66 21 24 / 07 60 73 38 42




smime.p7s
Description: Signature cryptographique S/MIME

[FRnOG] [BIZ] Vente CISCO NEXUS N5K et N2K

2018-05-16 Par sujet Sylvain BURAN

Bonjour,

Je vends des Cisco Nexus N5K et N2K :

2x N5K-C5548UP-FA
2x N2K-C2232TM-E

Ils seront dispo entre le 15-20 Juin.


Merci

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

RE: [FRnOG] [TECH] Accès portail client Orange

2018-05-16 Par sujet GUILLOT Florent

Donc si je comprends bien, Orange (3215) demande à OpenTransit (5511) de black 
holer ces IP, et garde dans son pool DNS (espaceclientv3.orange.fr) des IP 
qu'il black hole volontairement.
Donc c'est "normal" que l'espace client d'Orange soit inaccessible depuis tout 
plein d'endroits...
Merci pour ces infos.
Florent

-Message d'origine-
De : felix.bouy...@setenforce.one [mailto:felix.bouy...@setenforce.one]
Envoyé : mercredi 16 mai 2018 12:07
À : Laurent GUERBY ; GUILLOT Florent 
; frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Accès portail client Orange

J'avais eu une réponse d'Opentransit - AS5511 (par lequel on passe si on est 
chez Cogent ou NTT par exemple) le 4 mai :

"Hello

IP 193.252.122.175 is black holed by customer itself through Arbor tool for the 
security reason,  The BH will be running for at least one week.

At our end  case - 1804Z90259 is open.

Will share further update, once we have new info in this ."

Pas eu d'info depuis, je suppose qu'ils sont toujours attaqués.

Félix

14 mai 2018 11:32 "Laurent GUERBY"  a écrit:

> On Mon, 2018-05-14 at 07:25 +, GUILLOT Florent wrote:
>
>> Bonjour à tous,
>>
>> On a des soucis pour accéder à https://espaceclientv3.orange.fr  dep
>> uis Level3.
>>
>> traceroute to espaceclient.orange.fr (193.252.133.37), 30 hops max,
>> 60 byte packets
>> 1  gateway (10.0.2.2)  0.120 ms  0.048 ms  0.157 ms
>> 2  10.158.70.1 (10.158.70.1)  2.815 ms  2.800 ms  2.964 ms
>> 3  192.168.252.9 (192.168.252.9)  2.937 ms  2.904 ms  2.985 ms
>> 4  192.168.254.254 (192.168.254.254)  4.535 ms  4.891 ms  4.876 ms
>> 5  5.149.184.2 (5.149.184.2)  33.395 ms  33.562 ms  34.971 ms
>> 6  172.31.31.6 (172.31.31.6)  7.157 ms  7.167 ms  7.136 ms
>> 7  172.31.31.30 (172.31.31.30)  7.109 ms  3.528 ms  3.421 ms
>> 8  ge-6-16.car1.lyon1.level3.net (212.73.204.113)  3.381 ms  3.351 ms
>> 4.618 ms
>> 9  * * *
>> 10  * * *
>> 11  * * *
>>
>> Une petite mesure avec les sondes atlas montre bien qu’on est pas les
>> seuls : https://atlas.ripe.net/measurements/12456082/#!probes
>> En gros, tous ceux qui peer en direct avec AS3215 ont l’air d’être
>> OK, mais pour les autres c’est KO.
>>
>> Le plus drôle c’est que ça fait bien 2/3 semaines que c’est comme ça
>> !
>> Y a quelqu’un par ici qui sait ce qui se passe (ou qui est en mesure
>> de réparer) ? 
>>
>> Bonne journée
>> Florent GUILLOT
>
> Bonjour,
>
> Pareil avec 24600 et 8891 injoignable via cogent mais ok via un peer
> qui passe par 3215, la liste des regles custom pour les petits AS
> orange grossit petit a petit chez nous :)
>
> #wanadoo portail
> if (bgp_path ~ [= * 3215 24600 =]) then preference = 600; #orange
> portail if (bgp_path ~ [= * 3215 8891 =]) then preference = 600;
>
> Sincèrement,
>
> Laurent
> AS197422 http://tetaneutral.net
>
>> __
>> Ce message contient des informations dont le contenu est susceptible
>> d' etre confidentiel. Il est destine au(x) destinataire(s) indique(s)
>> exclusivement.
>> A moins que vous ne fassiez partie de la liste des destinataires, ou
>> que vous soyez habilite a recevoir le mail a leur place, il vous est
>> interdit de le copier, de l'utiliser ou de devoiler son contenu a un
>> tiers.
>> Si vous avez recu cet email par erreur, merci de prendre contact avec
>> l'emetteur.
>> Les opinions exprimees dans cet e-mail sont celles de l'emetteur et
>> ne refletent pas necessairement celles de l'entreprise.
>> Ce e-mail peut contenir des pieces jointes dont certaines pourraient
>> contenir des virus qui pourraient endommager votre systeme
>> informatique.
>> La compagnie a pris toutes dispositions afin de minimiser ce risque
>> et decline toute responsabilite pour toute perte ou dommage resultant
>> directement ou indirectement de l'utilisation de cet email ou de son
>> contenu.
>> Il vous appartient d'effectuer vos propres controles anti-virus avant
>> d'ouvrir la ou les pieces jointes.
>> __
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org
__
Ce message contient des informations dont le contenu est susceptible d' etre 
confidentiel. Il est destine au(x) destinataire(s) indique(s) exclusivement.
A moins que vous ne fassiez partie de la liste des destinataires, ou que vous 
soyez habilite a recevoir le mail a leur place, il vous est interdit de le 
copier, de l'utiliser ou de devoiler son contenu a un tiers.
Si vous avez recu cet email par erreur, merci de prendre contact avec 
l'emetteur.
Les opinions exprimees dans cet e-mail sont celles de l'emetteur et ne 
refletent pas necessairement celles de l'entreprise.
Ce e-mail peut contenir des pieces jointes dont certaines pourraient contenir 
des virus qui

Re: [FRnOG] [TECH] Accès portail client Orange

2018-05-16 Par sujet felix . bouynot

J'avais eu une réponse d'Opentransit - AS5511 (par lequel on passe si on est 
chez Cogent ou NTT par exemple) le 4 mai :

"Hello
 
IP 193.252.122.175 is black holed by customer itself through Arbor tool for the 
security reason,  The BH will be running for at least one week.
 
At our end  case - 1804Z90259 is open.
 
Will share further update, once we have new info in this ."

Pas eu d'info depuis, je suppose qu'ils sont toujours attaqués.

Félix

14 mai 2018 11:32 "Laurent GUERBY"  a écrit:

> On Mon, 2018-05-14 at 07:25 +, GUILLOT Florent wrote:
> 
>> Bonjour à tous,
>> 
>> On a des soucis pour accéder à https://espaceclientv3.orange.fr  dep
>> uis Level3.
>> 
>> traceroute to espaceclient.orange.fr (193.252.133.37), 30 hops max,
>> 60 byte packets
>> 1  gateway (10.0.2.2)  0.120 ms  0.048 ms  0.157 ms
>> 2  10.158.70.1 (10.158.70.1)  2.815 ms  2.800 ms  2.964 ms
>> 3  192.168.252.9 (192.168.252.9)  2.937 ms  2.904 ms  2.985 ms
>> 4  192.168.254.254 (192.168.254.254)  4.535 ms  4.891 ms  4.876 ms
>> 5  5.149.184.2 (5.149.184.2)  33.395 ms  33.562 ms  34.971 ms
>> 6  172.31.31.6 (172.31.31.6)  7.157 ms  7.167 ms  7.136 ms
>> 7  172.31.31.30 (172.31.31.30)  7.109 ms  3.528 ms  3.421 ms
>> 8  ge-6-16.car1.lyon1.level3.net (212.73.204.113)  3.381 ms  3.351
>> ms  4.618 ms
>> 9  * * *
>> 10  * * *
>> 11  * * *
>> 
>> Une petite mesure avec les sondes atlas montre bien qu’on est pas les
>> seuls : https://atlas.ripe.net/measurements/12456082/#!probes
>> En gros, tous ceux qui peer en direct avec AS3215 ont l’air d’être
>> OK, mais pour les autres c’est KO.
>> 
>> Le plus drôle c’est que ça fait bien 2/3 semaines que c’est comme ça
>> !
>> Y a quelqu’un par ici qui sait ce qui se passe (ou qui est en mesure
>> de réparer) ? 
>> 
>> Bonne journée
>> Florent GUILLOT
> 
> Bonjour,
> 
> Pareil avec 24600 et 8891 injoignable via cogent mais ok via un peer
> qui passe par 3215, la liste des regles custom pour les petits AS
> orange grossit petit a petit chez nous :)
> 
> #wanadoo portail
> if (bgp_path ~ [= * 3215 24600 =]) then preference = 600;
> #orange portail
> if (bgp_path ~ [= * 3215 8891 =]) then preference = 600;
> 
> Sincèrement,
> 
> Laurent
> AS197422 http://tetaneutral.net
> 
>> __
>> Ce message contient des informations dont le contenu est susceptible
>> d' etre confidentiel. Il est destine au(x) destinataire(s) indique(s)
>> exclusivement.
>> A moins que vous ne fassiez partie de la liste des destinataires, ou
>> que vous soyez habilite a recevoir le mail a leur place, il vous est
>> interdit de le copier, de l'utiliser ou de devoiler son contenu a un
>> tiers.
>> Si vous avez recu cet email par erreur, merci de prendre contact avec
>> l'emetteur.
>> Les opinions exprimees dans cet e-mail sont celles de l'emetteur et
>> ne refletent pas necessairement celles de l'entreprise.
>> Ce e-mail peut contenir des pieces jointes dont certaines pourraient
>> contenir des virus qui pourraient endommager votre systeme
>> informatique.
>> La compagnie a pris toutes dispositions afin de minimiser ce risque
>> et decline toute responsabilite pour toute perte ou dommage resultant
>> directement ou indirectement de l'utilisation de cet email ou de son
>> contenu.
>> Il vous appartient d'effectuer vos propres controles anti-virus avant
>> d'ouvrir la ou les pieces jointes.
>> __
>> 
>> ---
>> 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/

RE: [FRnOG] [ALERT] Problème interco orange

2018-05-16 Par sujet Antoine Debarre

Hello,


Pour le moment mes courbes sont bonnes mais j'ai été surpris de voir le retour 
d'Alphalink ce matin à 8h15.

"L'incident d'interco Orange est en cours de résolution"

...


De : frnog-requ...@frnog.org  de la part de David 
Ponzone 
Envoyé : mercredi 16 mai 2018 10:42
À : frnog@FRnOG.org; Mickael Hubert
Objet : Re: [FRnOG] [ALERT] Problème interco orange

Je suis le seul à avoir l’impression que ça recommence ?
Je veux pas crier au loup, mais ça fait 2 fois qu’un client en VGA a des 
coupures en m’appelant…


On 16 mai 2018 10:09 +0200, Mickael Hubert , wrote:
> Bonjour à tous,
> je confirme que le problème est résolu de notre coté et voici l'info de la
> part de SFR:
>
> "Le défaut ayant impacté vos services voix fixes et mobiles est résolu.
> Orange a apporté des correctifs sur leurs infrastructures et confirme à
> présent que le défaut sur leurs interconnexions VoIP avec les opérateurs
> est résolu. Nous sommes à présent en fonctionnement nominal sur nos
> interconnexions avec Orange. Nous gardons vos services en observation
> jusqu¿à demain matin et nous excusons de la gène occasionnée."
>
> Si jamais vous avez un véritable RFO de la part d'Orange ça serait sympa de
> partager
>
> merci d'avance et bonne journée
>
> Le 15 mai 2018 à 17:02, Alain Bieuzent  a écrit :
>
> > Mail reçu a l'instant de mon ccial ORANGE : "La situation est quasiment
> > totalement résolue, nous vous ferons un retour sur les causes de cet
> > incident très prochainement."
> >
> > Bonne soirée
> >
> > Le 15/05/2018 11:36, « Mickael LE MOINE »  > nom de fr...@realitik.com> a écrit :
> >
> > Bonjour,
> >
> > Voici le retour de Orange à 11h30 :
> >
> > /Nous confirmons un incident technique impactant l’interconnexion fixe
> > et mobile avec les autres opérateurs.///
> >
> > ///Il ne s’agit pas d’une panne mais bien d’un service fortement
> > dégradé
> > pour les interconnexions./
> >
> > /Nous n'avons malheureusement pas de délai de rétablissement à vous
> > communiquer pour le moment./
> >
> > Très cordialement.
> >
> > Le 15/05/2018 à 11:11, Mickael Hubert a écrit :
> > > info de SFR à 10h47
> > >
> > > "L¿incident ayant impactant les services Voix au niveau national (y
> > compris
> > > intra-SFR sur les services mobiles) le 14/05 10H a été corrigé par
> > Orange
> > > sur leur infrastructure hier à 16H45. Cependant, nous subissons une
> > > nouvelle occurrence sur les services voix fixes ce jour depuis 10H.
> > Nos
> > > équipes techniques sont mobilisées avec l¿opérateur historique pour
> > > résoudre ce problème."
> > >
> > > Le 15 mai 2018 à 10:27, Thomas Raynal  a écrit :
> > >
> > > > Bonjour,
> > > >
> > > > Même constat ici.
> > > > A noter que contrairement à hier, ils cassent les appels avec des
> > "404 not
> > > > found" plutôt que des "408 timeouts".
> > > > Ce n'est pas vraiment le code d'erreur que j'aurai attendu s'ils
> > avaient
> > > > mis en place un mécanisme de shaping pour protéger leurs
> > équipements.
> > > > Quelque chose d'autre qui s'est effondré chez eux avec la montée en
> > charge
> > > > ce matin?
> > > >
> > > >
> > > > Le 15/05/2018 à 10:15, Steeve BEAUVAIS - Société Serinya Telecom a
> > écrit :
> > > >
> > > > > Bonjour,
> > > > >
> > > > > On dirait bien que c'est reparti. Mon outils de supervision me
> > remonte des
> > > > > échecs d'appels.
> > > > >
> > > > > Cordialement,
> > > > >
> > > > > [image:
> > > > > http://www.serinyatelecom.fr/signatures/signature-steeve-bea
> > > > > uvais-serinya-telecom.jpg]
> > > > >
> > > > >
> > > > >  > serinyatelecom.php
> > > > >
> > > > >
> > > > > Le 15 mai 2018 à 10:12, Mickael Hubert  a
> > écrit :
> > > > >
> > > > > Un petit ENUM vite fait, c'est faisable, mais tu veux te passer de
> > la TA
> > > > > > (taxe d'acheminement) ?
> > > > > > Bon, elle ne cesse de baisser, mais ça risque de faire grincer
> > des dents.
> > > > > > mdr
> > > > > >
> > > > > > Le 15 mai 2018 à 09:40, David Ponzone  > a écrit
> > > > > > :
> > > > > >
> > > > > > A priori rien chez nous pour le moment.
> > > > > > > Mais possible que les clients comprennent que le problème n’est
> > pas
> > > > > > > terminé et n’appellent pas
> > > > > > >
> > > > > > > Bon, qui met un petit ENUM en place vite fait, pour qu’on ait
> > les appels
> > > > > > > entre nous au moins ? :)
> > > > > > >
> > > > > > >
> > > > > > > On 15 mai 2018 09:37 +0200, Mickael Hubert ,
> > wrote:
> > > > > > >
> > > > > > > Bonjour à tous,
> > > > > > >
> > > > > > >
> > > > > > > Et ça continue ;)
> > > > > > > Ce matin 8h30 parfait, mais nous étions en période creuse.
> > > > > > > 9h - 9h30 de nouveau impacté.
> > > > > > >
> > > > > > > Pouvez-vous nous donner une vision de votre coté svp ?
> > > > >

Re: [FRnOG] [ALERT] Problème interco orange

2018-05-16 Par sujet BASSAGET Cédric

Je viens de faire un test depuis mobile free vers un numéro livré sur une
interco SIP orange : environ un appel sur 4 qui n'aboutit pas

Le 16 mai 2018 à 10:42, David Ponzone  a écrit :

> Je suis le seul à avoir l’impression que ça recommence ?
> Je veux pas crier au loup, mais ça fait 2 fois qu’un client en VGA a des
> coupures en m’appelant…
>
>
> On 16 mai 2018 10:09 +0200, Mickael Hubert , wrote:
> > Bonjour à tous,
> > je confirme que le problème est résolu de notre coté et voici l'info de
> la
> > part de SFR:
> >
> > "Le défaut ayant impacté vos services voix fixes et mobiles est résolu.
> > Orange a apporté des correctifs sur leurs infrastructures et confirme à
> > présent que le défaut sur leurs interconnexions VoIP avec les opérateurs
> > est résolu. Nous sommes à présent en fonctionnement nominal sur nos
> > interconnexions avec Orange. Nous gardons vos services en observation
> > jusqu¿à demain matin et nous excusons de la gène occasionnée."
> >
> > Si jamais vous avez un véritable RFO de la part d'Orange ça serait sympa
> de
> > partager
> >
> > merci d'avance et bonne journée
> >
> > Le 15 mai 2018 à 17:02, Alain Bieuzent  a écrit
> :
> >
> > > Mail reçu a l'instant de mon ccial ORANGE : "La situation est quasiment
> > > totalement résolue, nous vous ferons un retour sur les causes de cet
> > > incident très prochainement."
> > >
> > > Bonne soirée
> > >
> > > Le 15/05/2018 11:36, « Mickael LE MOINE »  > > nom de fr...@realitik.com> a écrit :
> > >
> > > Bonjour,
> > >
> > > Voici le retour de Orange à 11h30 :
> > >
> > > /Nous confirmons un incident technique impactant l’interconnexion fixe
> > > et mobile avec les autres opérateurs.///
> > >
> > > ///Il ne s’agit pas d’une panne mais bien d’un service fortement
> > > dégradé
> > > pour les interconnexions./
> > >
> > > /Nous n'avons malheureusement pas de délai de rétablissement à vous
> > > communiquer pour le moment./
> > >
> > > Très cordialement.
> > >
> > > Le 15/05/2018 à 11:11, Mickael Hubert a écrit :
> > > > info de SFR à 10h47
> > > >
> > > > "L¿incident ayant impactant les services Voix au niveau national (y
> > > compris
> > > > intra-SFR sur les services mobiles) le 14/05 10H a été corrigé par
> > > Orange
> > > > sur leur infrastructure hier à 16H45. Cependant, nous subissons une
> > > > nouvelle occurrence sur les services voix fixes ce jour depuis 10H.
> > > Nos
> > > > équipes techniques sont mobilisées avec l¿opérateur historique pour
> > > > résoudre ce problème."
> > > >
> > > > Le 15 mai 2018 à 10:27, Thomas Raynal  a écrit :
> > > >
> > > > > Bonjour,
> > > > >
> > > > > Même constat ici.
> > > > > A noter que contrairement à hier, ils cassent les appels avec des
> > > "404 not
> > > > > found" plutôt que des "408 timeouts".
> > > > > Ce n'est pas vraiment le code d'erreur que j'aurai attendu s'ils
> > > avaient
> > > > > mis en place un mécanisme de shaping pour protéger leurs
> > > équipements.
> > > > > Quelque chose d'autre qui s'est effondré chez eux avec la montée en
> > > charge
> > > > > ce matin?
> > > > >
> > > > >
> > > > > Le 15/05/2018 à 10:15, Steeve BEAUVAIS - Société Serinya Telecom a
> > > écrit :
> > > > >
> > > > > > Bonjour,
> > > > > >
> > > > > > On dirait bien que c'est reparti. Mon outils de supervision me
> > > remonte des
> > > > > > échecs d'appels.
> > > > > >
> > > > > > Cordialement,
> > > > > >
> > > > > > [image:
> > > > > > http://www.serinyatelecom.fr/signatures/signature-steeve-bea
> > > > > > uvais-serinya-telecom.jpg]
> > > > > >
> > > > > >
> > > > > >  > > serinyatelecom.php
> > > > > >
> > > > > >
> > > > > > Le 15 mai 2018 à 10:12, Mickael Hubert  a
> > > écrit :
> > > > > >
> > > > > > Un petit ENUM vite fait, c'est faisable, mais tu veux te passer
> de
> > > la TA
> > > > > > > (taxe d'acheminement) ?
> > > > > > > Bon, elle ne cesse de baisser, mais ça risque de faire grincer
> > > des dents.
> > > > > > > mdr
> > > > > > >
> > > > > > > Le 15 mai 2018 à 09:40, David Ponzone  > > a écrit
> > > > > > > :
> > > > > > >
> > > > > > > A priori rien chez nous pour le moment.
> > > > > > > > Mais possible que les clients comprennent que le problème
> n’est
> > > pas
> > > > > > > > terminé et n’appellent pas
> > > > > > > >
> > > > > > > > Bon, qui met un petit ENUM en place vite fait, pour qu’on ait
> > > les appels
> > > > > > > > entre nous au moins ? :)
> > > > > > > >
> > > > > > > >
> > > > > > > > On 15 mai 2018 09:37 +0200, Mickael Hubert <
> mick...@winlux.fr>,
> > > wrote:
> > > > > > > >
> > > > > > > > Bonjour à tous,
> > > > > > > >
> > > > > > > >
> > > > > > > > Et ça continue ;)
> > > > > > > > Ce matin 8h30 parfait, mais nous étions en période creuse.
> > > > > > > > 9h - 9h30 de nouveau impacté.
> > > > > > > >
> > > > > > > > Pouvez-vous nous donner

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet Cedric Millet (pro)

Xavier, je suis intéressé pour faire partie de la ML
PS : d’après ton 1er email : " [IAV]  pour "Interco_Voix_Alternative" " ,
c'est donc la balise IVA pas IAV  ;)


2018-05-16 10:04 GMT+02:00 Radu-Adrian Feurdean <
fr...@radu-adrian.feurdean.net>:

> On Tue, May 15, 2018, at 20:18, David Ponzone wrote:
> > Ce qui me dérange, c’est que vous semblez oublier qu’une plage de
> > numéros client c’est par exemple un /36 dans ton exemple (ZABPQMCD),
> > mais il arrive souvent qu’un numéro ait été sorti pour une ligne
> > analogique (fax) donc ton /36 devient 9 /40.
> > Difficile d’évaluer le nombre de routes que ça représente, probablement
> > gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va
> > faire mal (les particuliers ont tous un /40, et rien à aggréger).
>
> J'i des doutes que je suis le seul a faire trainer des milliers (bientot
> dizaines de milliers) de /32 dans mon (MP-)iBGP. Plus autant de /128 et
> encore autant de /56 ou /48
> Donc cote scalabilite, je vois pas de probleme 1.2M routes sur mon RR,
> et ce n'est pas le pire que ca puisse exister
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [ALERT] Problème interco orange

2018-05-16 Par sujet David Ponzone

Je suis le seul à avoir l’impression que ça recommence ?
Je veux pas crier au loup, mais ça fait 2 fois qu’un client en VGA a des 
coupures en m’appelant…


On 16 mai 2018 10:09 +0200, Mickael Hubert , wrote:
> Bonjour à tous,
> je confirme que le problème est résolu de notre coté et voici l'info de la
> part de SFR:
>
> "Le défaut ayant impacté vos services voix fixes et mobiles est résolu.
> Orange a apporté des correctifs sur leurs infrastructures et confirme à
> présent que le défaut sur leurs interconnexions VoIP avec les opérateurs
> est résolu. Nous sommes à présent en fonctionnement nominal sur nos
> interconnexions avec Orange. Nous gardons vos services en observation
> jusqu¿à demain matin et nous excusons de la gène occasionnée."
>
> Si jamais vous avez un véritable RFO de la part d'Orange ça serait sympa de
> partager
>
> merci d'avance et bonne journée
>
> Le 15 mai 2018 à 17:02, Alain Bieuzent  a écrit :
>
> > Mail reçu a l'instant de mon ccial ORANGE : "La situation est quasiment
> > totalement résolue, nous vous ferons un retour sur les causes de cet
> > incident très prochainement."
> >
> > Bonne soirée
> >
> > Le 15/05/2018 11:36, « Mickael LE MOINE »  > nom de fr...@realitik.com> a écrit :
> >
> > Bonjour,
> >
> > Voici le retour de Orange à 11h30 :
> >
> > /Nous confirmons un incident technique impactant l’interconnexion fixe
> > et mobile avec les autres opérateurs.///
> >
> > ///Il ne s’agit pas d’une panne mais bien d’un service fortement
> > dégradé
> > pour les interconnexions./
> >
> > /Nous n'avons malheureusement pas de délai de rétablissement à vous
> > communiquer pour le moment./
> >
> > Très cordialement.
> >
> > Le 15/05/2018 à 11:11, Mickael Hubert a écrit :
> > > info de SFR à 10h47
> > >
> > > "L¿incident ayant impactant les services Voix au niveau national (y
> > compris
> > > intra-SFR sur les services mobiles) le 14/05 10H a été corrigé par
> > Orange
> > > sur leur infrastructure hier à 16H45. Cependant, nous subissons une
> > > nouvelle occurrence sur les services voix fixes ce jour depuis 10H.
> > Nos
> > > équipes techniques sont mobilisées avec l¿opérateur historique pour
> > > résoudre ce problème."
> > >
> > > Le 15 mai 2018 à 10:27, Thomas Raynal  a écrit :
> > >
> > > > Bonjour,
> > > >
> > > > Même constat ici.
> > > > A noter que contrairement à hier, ils cassent les appels avec des
> > "404 not
> > > > found" plutôt que des "408 timeouts".
> > > > Ce n'est pas vraiment le code d'erreur que j'aurai attendu s'ils
> > avaient
> > > > mis en place un mécanisme de shaping pour protéger leurs
> > équipements.
> > > > Quelque chose d'autre qui s'est effondré chez eux avec la montée en
> > charge
> > > > ce matin?
> > > >
> > > >
> > > > Le 15/05/2018 à 10:15, Steeve BEAUVAIS - Société Serinya Telecom a
> > écrit :
> > > >
> > > > > Bonjour,
> > > > >
> > > > > On dirait bien que c'est reparti. Mon outils de supervision me
> > remonte des
> > > > > échecs d'appels.
> > > > >
> > > > > Cordialement,
> > > > >
> > > > > [image:
> > > > > http://www.serinyatelecom.fr/signatures/signature-steeve-bea
> > > > > uvais-serinya-telecom.jpg]
> > > > >
> > > > >
> > > > >  > serinyatelecom.php
> > > > >
> > > > >
> > > > > Le 15 mai 2018 à 10:12, Mickael Hubert  a
> > écrit :
> > > > >
> > > > > Un petit ENUM vite fait, c'est faisable, mais tu veux te passer de
> > la TA
> > > > > > (taxe d'acheminement) ?
> > > > > > Bon, elle ne cesse de baisser, mais ça risque de faire grincer
> > des dents.
> > > > > > mdr
> > > > > >
> > > > > > Le 15 mai 2018 à 09:40, David Ponzone  > a écrit
> > > > > > :
> > > > > >
> > > > > > A priori rien chez nous pour le moment.
> > > > > > > Mais possible que les clients comprennent que le problème n’est
> > pas
> > > > > > > terminé et n’appellent pas
> > > > > > >
> > > > > > > Bon, qui met un petit ENUM en place vite fait, pour qu’on ait
> > les appels
> > > > > > > entre nous au moins ? :)
> > > > > > >
> > > > > > >
> > > > > > > On 15 mai 2018 09:37 +0200, Mickael Hubert ,
> > wrote:
> > > > > > >
> > > > > > > Bonjour à tous,
> > > > > > >
> > > > > > >
> > > > > > > Et ça continue ;)
> > > > > > > Ce matin 8h30 parfait, mais nous étions en période creuse.
> > > > > > > 9h - 9h30 de nouveau impacté.
> > > > > > >
> > > > > > > Pouvez-vous nous donner une vision de votre coté svp ?
> > > > > > >
> > > > > > > merci d'avance
> > > > > > >
> > > > > > > Le 14 mai 2018 à 22:44, Julien OHAYON  a
> > écrit :
> > > > > > >
> > > > > > > C’est pour ça qu’on a aussi inventé les DNS.
> > > > > > > On est archaïque :)
> > > > > > >
> > > > > > > Une adresse mail pour appeler serait tellement mieux :)
> > > > > > >
> > > > > > > Julien OHAYON
> > > > > > > Directeur Technique
> > > > > > > APPLIWAVE
> > > > > > >
> > > > > > >

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet David Ponzone

Je m’auto-corrige:
10 ou 20 fois la table de routage globale pour juste les E164 en France….


On 16 mai 2018 10:13 +0200, David Ponzone , wrote:
> C’est rassurant.
> Je remontais juste ce point car le nombre de routes en téléphonie peut être 
> de l’ordre de 10 ou 20 fois ce qu’on a en IPv4.
> C’est difficile à prédire, mais à priori plus le temps passe, plus ça se 
> désagrège.
> Evidememnt, ce BGP orienté E164 pourrait être fait par des routeurs soft, 
> blindés en RAM et qui monte des sessions multihop-BGP avec le RS de l'IX , 
> puisqu’il n’y a nul besoin de se reposer sur les routeurs IPv4 existants pour 
> ce BGP là.
>
> On 16 mai 2018 10:04 +0200, Radu-Adrian Feurdean 
> , wrote:
> > On Tue, May 15, 2018, at 20:18, David Ponzone wrote:
> > > Ce qui me dérange, c’est que vous semblez oublier qu’une plage de
> > > numéros client c’est par exemple un /36 dans ton exemple (ZABPQMCD),
> > > mais il arrive souvent qu’un numéro ait été sorti pour une ligne
> > > analogique (fax) donc ton /36 devient 9 /40.
> > > Difficile d’évaluer le nombre de routes que ça représente, probablement
> > > gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va
> > > faire mal (les particuliers ont tous un /40, et rien à aggréger).
> >
> > J'i des doutes que je suis le seul a faire trainer des milliers (bientot 
> > dizaines de milliers) de /32 dans mon (MP-)iBGP. Plus autant de /128 et 
> > encore autant de /56 ou /48
> > Donc cote scalabilite, je vois pas de probleme 1.2M routes sur mon RR, 
> > et ce n'est pas le pire que ca puisse exister
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/

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

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet David Ponzone

C’est rassurant.
Je remontais juste ce point car le nombre de routes en téléphonie peut être de 
l’ordre de 10 ou 20 fois ce qu’on a en IPv4.
C’est difficile à prédire, mais à priori plus le temps passe, plus ça se 
désagrège.
Evidememnt, ce BGP orienté E164 pourrait être fait par des routeurs soft, 
blindés en RAM et qui monte des sessions multihop-BGP avec le RS de l'IX , 
puisqu’il n’y a nul besoin de se reposer sur les routeurs IPv4 existants pour 
ce BGP là.

On 16 mai 2018 10:04 +0200, Radu-Adrian Feurdean 
, wrote:
> On Tue, May 15, 2018, at 20:18, David Ponzone wrote:
> > Ce qui me dérange, c’est que vous semblez oublier qu’une plage de
> > numéros client c’est par exemple un /36 dans ton exemple (ZABPQMCD),
> > mais il arrive souvent qu’un numéro ait été sorti pour une ligne
> > analogique (fax) donc ton /36 devient 9 /40.
> > Difficile d’évaluer le nombre de routes que ça représente, probablement
> > gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va
> > faire mal (les particuliers ont tous un /40, et rien à aggréger).
>
> J'i des doutes que je suis le seul a faire trainer des milliers (bientot 
> dizaines de milliers) de /32 dans mon (MP-)iBGP. Plus autant de /128 et 
> encore autant de /56 ou /48
> Donc cote scalabilite, je vois pas de probleme 1.2M routes sur mon RR, et 
> ce n'est pas le pire que ca puisse exister
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

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

Re: [FRnOG] [ALERT] Problème interco orange

2018-05-16 Par sujet Mickael Hubert

Bonjour à tous,
je confirme que le problème est résolu de notre coté et voici l'info de la
part de SFR:

"Le défaut ayant impacté vos services voix fixes et mobiles est résolu.
Orange a apporté des correctifs sur leurs infrastructures et confirme à
présent que le défaut sur leurs interconnexions VoIP avec les opérateurs
est résolu. Nous sommes à présent en fonctionnement nominal sur nos
interconnexions avec Orange. Nous gardons vos services en observation
jusqu¿à demain matin et nous excusons de la gène occasionnée."

Si jamais vous avez un véritable RFO de la part d'Orange ça serait sympa de
partager

merci d'avance et bonne journée

Le 15 mai 2018 à 17:02, Alain Bieuzent  a écrit :

> Mail reçu a l'instant de mon ccial ORANGE : "La situation est quasiment
> totalement résolue, nous vous ferons un retour sur les causes de cet
> incident très prochainement."
>
> Bonne soirée
>
> Le 15/05/2018 11:36, « Mickael LE MOINE »  nom de fr...@realitik.com> a écrit :
>
> Bonjour,
>
> Voici le retour de Orange à 11h30 :
>
> /Nous confirmons un incident technique impactant l’interconnexion fixe
> et mobile avec les autres opérateurs.///
>
> ///Il ne s’agit pas d’une panne mais bien d’un service fortement
> dégradé
> pour les interconnexions./
>
> /Nous n'avons malheureusement pas de délai de rétablissement à vous
> communiquer pour le moment./
>
> Très cordialement.
>
> Le 15/05/2018 à 11:11, Mickael Hubert a écrit :
> > info de SFR à 10h47
> >
> > "L¿incident ayant impactant les services Voix au niveau national (y
> compris
> > intra-SFR sur les services mobiles) le 14/05 10H a été corrigé par
> Orange
> > sur leur infrastructure hier à 16H45. Cependant, nous subissons une
> > nouvelle occurrence sur les services voix fixes ce jour depuis 10H.
> Nos
> > équipes techniques sont mobilisées avec l¿opérateur historique pour
> > résoudre ce problème."
> >
> > Le 15 mai 2018 à 10:27, Thomas Raynal  a écrit :
> >
> >> Bonjour,
> >>
> >> Même constat ici.
> >> A noter que contrairement à hier, ils cassent les appels avec des
> "404 not
> >> found" plutôt que des "408 timeouts".
> >> Ce n'est pas vraiment le code d'erreur que j'aurai attendu s'ils
> avaient
> >> mis en place un mécanisme de shaping pour protéger leurs
> équipements.
> >> Quelque chose d'autre qui s'est effondré chez eux avec la montée en
> charge
> >> ce matin?
> >>
> >>
> >> Le 15/05/2018 à 10:15, Steeve BEAUVAIS - Société Serinya Telecom a
> écrit :
> >>
> >>> Bonjour,
> >>>
> >>> On dirait bien que c'est reparti. Mon outils de supervision me
> remonte des
> >>> échecs d'appels.
> >>>
> >>> Cordialement,
> >>>
> >>> [image:
> >>> http://www.serinyatelecom.fr/signatures/signature-steeve-bea
> >>> uvais-serinya-telecom.jpg]
> >>>
> >>>
> >>>  serinyatelecom.php>
> >>>
> >>>
> >>> Le 15 mai 2018 à 10:12, Mickael Hubert  a
> écrit :
> >>>
> >>> Un petit ENUM vite fait, c'est faisable, mais tu veux te passer de
> la TA
>  (taxe d'acheminement) ?
>  Bon, elle ne cesse de baisser, mais ça risque de faire grincer
> des dents.
>  mdr
> 
>  Le 15 mai 2018 à 09:40, David Ponzone 
> a écrit
>  :
> 
>  A priori rien chez nous pour le moment.
> > Mais possible que les clients comprennent que le problème n’est
> pas
> > terminé et n’appellent pas
> >
> > Bon, qui met un petit ENUM en place vite fait, pour qu’on ait
> les appels
> > entre nous au moins ? :)
> >
> >
> > On 15 mai 2018 09:37 +0200, Mickael Hubert ,
> wrote:
> >
> > Bonjour à tous,
> >
> >
> > Et ça continue ;)
> > Ce matin 8h30 parfait, mais nous étions en période creuse.
> > 9h - 9h30 de nouveau impacté.
> >
> > Pouvez-vous nous donner une vision de votre coté svp ?
> >
> > merci d'avance
> >
> > Le 14 mai 2018 à 22:44, Julien OHAYON  a
> écrit :
> >
> > C’est pour ça qu’on a aussi inventé les DNS.
> > On est archaïque :)
> >
> > Une adresse mail pour appeler serait tellement mieux :)
> >
> > Julien OHAYON
> > Directeur Technique
> > APPLIWAVE
> >
> > Tel : 09.71.18.71.11
> >
> > Le 14 mai 2018 à 22:39, David Ponzone 
> a écrit
> >
> > :
> >
> >
> > Hmm s’il n’a jamais été possible de changer d’ISP en gardant son
> IPv4,
> >
> > il y avait peut être une raison ? :)
> >
> >

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet Radu-Adrian Feurdean

On Tue, May 15, 2018, at 20:18, David Ponzone wrote:
> Ce qui me dérange, c’est que vous semblez oublier qu’une plage de 
> numéros client c’est par exemple un /36 dans ton exemple (ZABPQMCD), 
> mais il arrive souvent qu’un numéro ait été sorti pour une ligne 
> analogique (fax) donc ton /36 devient 9 /40.
> Difficile d’évaluer le nombre de routes que ça représente, probablement 
> gérable entre opérateurs petits, mais si un SFR ou Free se pointe, ça va 
> faire mal (les particuliers ont tous un /40, et rien à aggréger).

J'i des doutes que je suis le seul a faire trainer des milliers (bientot 
dizaines de milliers) de /32 dans mon (MP-)iBGP. Plus autant de /128 et encore 
autant de /56 ou /48
Donc cote scalabilite, je vois pas de probleme 1.2M routes sur mon RR, et 
ce n'est pas le pire que ca puisse exister

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

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet Raphael Jacquot

On 05/16/2018 09:35 AM, Sébastien Lesimple wrote:

> Bref, ce n'est pas un problème d'ingés mais un problème business et le
> modèle associatif à la FranceIX ne fonctionne pas quand on aborde le
> business de la voix.

il va bien y avoir un moment ou un des acteurs un peu kamikaze va se
décider a disrupter ce business model bien huilé depuis une bonne
centaine d'années...

Raphaël

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

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet Sébastien Lesimple

Cela doit bien faire 20 ans que j'entends ce genre d'échange.
Ca a commencé à l'époque de la présélection, puis de la démocratisation
de l'interco C7, puis du SIP mais rien n'a jamais aboutis.
Toutes les tentatives se sont traduites par un échec.

L'investissement pour atteindre cet objectif est lourds en
temps/RH/ressources.
De plus il sous-entendrait de maintenir une interco avec l'ensemble des
opérateurs "puissants" afin de fournir une "route" aux plus modestes et
compenser les trous dans la raquette, parce-que hormis Orange qui a une
vraie ODR, les autres, c'est la valse du grand n'importe quoi...

Bref, ce n'est pas un problème d'ingés mais un problème business et le
modèle associatif à la FranceIX ne fonctionne pas quand on aborde le
business de la voix.

Seb.

Le 15/05/2018 à 15:40, Mickael Hubert a écrit :
> +1 pour participer a ce type de discussion passionnante !
>
> Il est vrai que les obstacles sont nombreux, mais si on ne commence pas, ça
> n'avancera jamais ;) Et se faire un POC n'engage a rien (contractuellement
> parlant).
> Et au final c'est quoi ? => Mettre au goût du jour un techno vieillissante.
> Il y a bien l'annonce de "la fin" du RTC pour le end user pourquoi pas
> l'annonce de "la fin" du SS7 pour les opérateurs (ok, je m'avance un peu ;)
> ) ?
>
> ++
>
>
>
> Le 15 mai 2018 à 15:30, Alain Bieuzent  a écrit :
>
>> +1 avec David, pas de problème pour discuter et/ou boire un bière a
>> l'occase et encore mieux si on peut effectivement faire mieux que les
>> "gros" et notamment de la HD
>>
>> Le 15/05/2018 15:27, « David Ponzone » > de david.ponz...@gmail.com> a écrit :
>>
>> Moi je suis comme Fabien, extrêmement sceptique sur la viabilité du
>> projet, mais je ne suis pas contre participer aux débats :)
>> Il y a par contre un argument qui pourrait pousser des acteurs moyens
>> à se joindre au projet, c’est de pouvoir (enfin) utiliser des codec HD et
>> video, donc fournir quelque chose qui n’est pas dispo (ou pas complètement)
>> pour le moment quand Orange est intermédiaire.
>>
>> On 15 mai 2018 14:56 +0200, Fabien H , wrote:
>> > Effectivement, on va arrêter de polluer la liste mais une dernière
>> chose :
>> >
>> > sans vouloir faire le pessimiste, il y'a quand même 2 gros freins
>> pour ce
>> > projet qui ont été évoqués :
>> >
>> > - Le fait que s'il n'y a pas de gros dans le projet, le trafic
>> échangé sera
>> > négligeable, donc le gain négligeable
>> > - Le fait qu'il faut des interco de qualité pour la voix avec des
>> liens
>> > d'interco garantis et de qualité (+ QOS, ..) et cela ça a un cout,
>> qui sera
>> > à multiplier par le nombre d'opérateurs dans le projet. Et du coup,
>> la
>> > viabilité purement financière sera surement limite, voire au final
>> cela
>> > coutera cher, par rapport à terminer chez son fournisseur de
>> terminaison
>> > habituel (Orange ou autre), sur lequel on a investit au niveau
>> interco, et
>> > qui lui garantit "normalement" le transport dans des conditions
>> > excellentes.
>> > Sinon solution best effort, on peut toujours passer par le transit
>> "par
>> > défaut", mais sur le long terme, on n'est jamais à l'abri d'un
>> problème de
>> > qualité de voix, et c'est je pense ce que la plupart ici ne veulent
>> pas.
>> >
>> > ---
>> > 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/
>>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet Raphaël Jacquot




On 16/05/2018 09:08, Alexis Lameire wrote:

Raphaël,
Ta remarque est pertinente sauf que ton plan de num est différent selon le
pays, donc c'est 3digit + padding + num. On a besoin de mettre le padding à
cette endroit pour que la notion de masque reste valide (et profiter de
l’agrégation).



ca n'était qu'une hypothèse qui peut être effectivement raffinée en 
fonction des besoins.
On pourrait décider d'affecter un /16 a la téléphonie, et etre plus 
large dans le découpage en blocs (ca laisserait 28 chiffres BCD à 
découper...)


Raphaël


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

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet Alexis Lameire

Raphaël,
Ta remarque est pertinente sauf que ton plan de num est différent selon le
pays, donc c'est 3digit + padding + num. On a besoin de mettre le padding à
cette endroit pour que la notion de masque reste valide (et profiter de
l’agrégation).

L'identification d'un opérateur ne peut se faire uniquement avec le numéro
d'AS, il y a toujours/souvent un enregistrement local complémentaire qui
est nécessaire à la vérification de la validité du plan de num annoncé. Il
faut donc le recevoir dans l'annonce BGP. On pourrais utiliser le vpnv6
mais utiliser la notion de vrf pour coder l'identification de l'opérateur
c'est pas crédible. On souhaite isoler les plan de num par pays et non par
opérateur (dont le numéro pourrait se recouvrir sur deux pays différent)

On peut sinon concevoir de transférer l'information d'identification ARCEP
via l'utilisation d'un bloc de communauté well know et rester dans les
clous. Comme ça on rajoute le moins de truc au protocole.

Le seul truc sur lequel il faut pas transiger, c'est l'utilisation
mémoire/tcam. Et donc il faut définir une extension pour router des bloc de
64bit avec prefix.

Alexis

Le 16 mai 2018 à 08:46, Raphaël Jacquot  a écrit :

>
>
> On 15/05/2018 20:07, Alexis Lameire wrote:
>
> ainsi la EZABPQ 011234 se code avec :
>> un prefix binaire représenté en hexa : 01:12:34:00:00
>> un masque binaire représenté en hexa : FF:FF:FF:00:00
>>
>> On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes
>> spécifique étant en /40
>>
>
> STOP right there...
>
> je pense qu'une solution est possible sans même ajouter d'extension a
> BGP...
>
> * une adresse IPv6 est composée de 128 bits, soit 32 blocs de 4 bits.
> * d'après https://en.wikipedia.org/wiki/Telephone_numbering_plan
>   un numéro de téléphone, au niveau mondial, a 15 caracteres BCD
>
> Il serait donc extremement simple, et le plus naturel du monde, de mapper
> tout ca sur un seul /64,
> * le code pays est sur 3 digits
> * le reste du numéro sur les 13 digits restants
>
> ce qui simplifierai grandement les tables de routages au niveau
> international
>
> Raphaël
>
>
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Serveur d'authentification

2018-05-16 Par sujet David Ponzone

A ma connaissance seul Tacacs+ permet le changement de password depuis le 
client, mais je ne sais pas si ça marche avec un autre que celui de Cisco.
Et la gestion des droits est plus fine.

Il reste principalement:
tacacs.net
celui de shrubbery
Cisco ISE (bling bling)

David Ponzone



Le 16 mai 2018 à 04:30, Michel Py  a écrit :

>> Marcel Duregards a écrit :
>> Auriez-vous des conseils concernant un serveur d'authentification radius (si 
>> il fait tacacs en plus, c'est un avantage)
>> pour l'authentification d'utilisateurs sur des devices (typiquement switch, 
>> routeurs cisco, cpe divers, etc), qui puisse:
> 
> As-tu regardé freeradius ?  https://freeradius.org/  j'ai utilisé dans le 
> passé, çà a marché pour moi.
> 
>> - le must (mais j'ai peur que ce soit propre ï¿½ tacacs), qui permettre de 
>> changer le mdp ï¿½ la volï¿½e en se logguant sur
>> la CLI cisco. p.e on se connecte ï¿½ un router cisco avec nos credentials, 
>> le serveur radius donne son ack, mais impose le
>> changement de mdp car il a expirï¿½ (le supplicant est forcï¿½ de changer 
>> son mdp, via l'interface de l'authenticator)
> 
> Euh, c'est quelle page de code que tu utilises, là ? je suis le seul qui à eu 
> les accents pas glop ?
> 
> Michel.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet Raphaël Jacquot




On 15/05/2018 20:07, Alexis Lameire wrote:


ainsi la EZABPQ 011234 se code avec :
un prefix binaire représenté en hexa : 01:12:34:00:00
un masque binaire représenté en hexa : FF:FF:FF:00:00

On peut ainsi employer la notation CIDR en 01:12:34:00:00/24 les routes
spécifique étant en /40


STOP right there...

je pense qu'une solution est possible sans même ajouter d'extension a BGP...

* une adresse IPv6 est composée de 128 bits, soit 32 blocs de 4 bits.
* d'après https://en.wikipedia.org/wiki/Telephone_numbering_plan
  un numéro de téléphone, au niveau mondial, a 15 caracteres BCD

Il serait donc extremement simple, et le plus naturel du monde, de 
mapper tout ca sur un seul /64,

* le code pays est sur 3 digits
* le reste du numéro sur les 13 digits restants

ce qui simplifierai grandement les tables de routages au niveau 
international


Raphaël





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

RE: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet Xavier ROCA

Merci Nicolas pour ton retour et ta participation,
Perso pas sur Paris, j'ai réduit au max les déplacements (trains et avions) ces 
derniers temps, on se demanderait presque pourquoi 

On a pas mal de point en commun avec ta réflexion.
Je fais un retour dès que je penses que tous ceux qui souhaitent traiter le 
sujet on fait signe de la main.

Donc ceux qui ont déjà posté mais non pas expressément dit qu'il voulait se 
joindre merci de lever la main.

De préférence sur mon mail avec la balise [IAV] pour des questions de 
traitements automatique des mails ce serait sympa.
En plus avec le 25/05 qui arrive a grand pas il serait bien d'avoir votre 
consentement explicite :) 

On n'a pas forcément nom et prénom via vos mails ce serait aussi très bien de 
nous communiquer les informations comme :
L'email sur lequel on va diffuser (si différent de celui identifié dans votre 
mail), un pro si possible
Le nom de la boite, si c'est possible mais on comprendra très bien que certains 
ne soit pas strictement dans le cadre pro de la boite sur ce sujet donc pas 
obligatoire. C'est juste bien de voir avec qui on va travailler.
Le poste idem c'est toujours intéressant mais pas obligatoire.

Xavier

PS1 : H-1 pour le début de la montée en charge  à suivre
PS2 : qui a eu une RFO (Reason For Outage) de la part d'Orange ?


-Message d'origine-
De : Nicolas Bougues  
Envoyé : mercredi 16 mai 2018 02:09
À : frnog@frnog.org
Objet : Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

Bonsoir à tous,

Ca doit bien faire 10 ans que je n'ai pas posté ici mais j'ai déjà pas mal 
réfléchi sur ce sujet d'interco SIP multi latérale.

Je me permets donc de vous exposer en quelques mots les principaux points sur 
lesquels j'ai un avis.

D'un point de vue technique, ça tournerait autour de :

   - une poignée de proxys SIP, genre Kamailio par exemple, installés de
   façon géographiquement / topologiquement diversifiée, adressés en
   round-robin / failover
   - ces machines ne géreraient que la signalisation; le media serait routé
   directement entre les SBCs des opérateurs reliés; il serait donc laissé à
   l'appréciation de chaque opérateur s'il lui parait pertinent de se
   contenter, pour parler avec chaque opérateur, d'une interco publique,
   privée ou d'un hybride (VLAN sur un GIX, whatever)
   - la signalisation serait basée sur les specs SIP FFT (qui sont
   maintenant à peu près complètes et bien supportées), avec des
   recommendations plus étendues en ce qui concerne le media (codecs audio
   variés, video, T38...). Le SDP permet une négo pourquoi s'en priver ?
   - bien évidemment un filtrage d'IPs serait réalisé, chaque opérateur
   membre publiant sa liste d'IPs in/out pour sig et media, publication qui
   serait utilisée par les proxies pour filtrer en input et forwarder les
   appels, et diffusée aux membres pour accepter les flux media

En ce qui concerne le routage :

   - pour répondre à ce que j'ai vu plus haut dans la discussion, il semble
   difficile de "penser BGP" : la notion d'aggrégation (qui préside pourtant à
   l'attribution de tranches de 1000 ou 1 numéros aux opérateurs par
   l'ARCEP) est complètement annihilée par la portabilité et autres exceptions
   (liste de numéros en routage TDM par exemple)
   - on est donc à peu près obligé d'avoir d'un côté un routage par défaut
   suivant l'opérateur attributaire de la tranche, avec un lookup unitaire sur
   une (voire des) base(s) d'exceptions; c'est de toute façon ce que font
   aujourd'hui tous les opérateurs (ne serait-ce que parce que le préfixage
   des numéros portés est facturable s'il n'est pas fait par l'opérateur
   appelant)
   - ces informations (tranches, portas...) sont aujourd'hui publiées sous
   forme de fichiers CSV ou de web services par l'APNF, qui le fait très bien
   - en ce qui concerne ENUM, c'est une belle idée sur le papier, mais j'ai
   plusieurs réserves :
  - ça nécessite la mise en place chez chaque acteur d'un DNS  précis
  et disponible; ça ne fait pas partie des choses "bien connues" chez les
  opérateurs telecom, même s'ils font de la VoIP
  - ça nécessite d'être mis à jour en temps réel et avec exactitude par
  l'attributaire d'un numéro lors d'une porta sortante; or il n'est pas
  exceptionnel qu'un attributaire ne réalise pas correctement leur part des
  portas sortantes (c'est-à-dire le reroutage vers le préfixe destination);
  dans un tel cas, une publication APNF par le prenant permet de régler
  l'essentiel du problème à l'échelle de 24h et sans le concours du cèdant;
  difficile d'imaginer revenir à un routage indirect seulement
  - Numérobis, en 2002, ça rappelle quelque chose à quelqu'un ? ;)
  - ma conclusion, c'est qu'il ne faut pas baser un tel projet sur
  ENUM, en tous cas au départ, et que si ENUM il devait y avoir, une version
  centralisée (gérée par l'APNF ou sur la base des données APNF) serait

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

2018-05-16 Par sujet Philippe Bourcier



Bonjour,

Un peu de top-posting pour la peine...
2 remarques basiques d'un point de vue (relativement) extérieur :

1 - traiter la désagrégation de l'annuaire :
Votre besoin c'est un storage clé-valeur persistant. La clé c'est 
le numéro de tel... la valeur c'est l'info de routage, codec, etc... le 
tout dans un joli petit json, pratique à parser et à debugger. 
Franchement, avec 3 serveurs corrects blindés de RAM (répliqués sur un 
autre DC, histoire d'assurer) et une solution type redis ou mieux (pour 
ce besoin précis), couchbase, on peut faire tenir tous les numéros FR en 
désagrégé sans aucun problème. Le tout avec une latence de moins de 10 
ms par requête, réseau (sur Paris) compris... bref, un truc totalement 
invisible au niveau téléphonie. Ensuite on peut mettre cette data dispo 
via DNS (pdns backend) ou n'importe quel autre système et/ou API...


2 - le métier de l'interco (téléphonique, ici), ça me rappelle aussi le 
métier d'IX :
Pourquoi une asso existante, tel France-IX, ne pourrait pas prendre 
le problème à son compte et travailler sur cette question ? Après tout, 
c'est une diversification économique intéressante (on peut imaginer un 
fixed-fee mensuel pour accéder à ce service). Bien sure, son concurrent 
Equinix-IX Paris pourrait faire de même, mais je crois qu'ils sont moins 
staffés... et, pour le coup, avoir 2 systèmes opérés par 2 entités 
différentes, aurait un certain intérêt en terme de redondance.



Cordialement,
Philippe Bourcier

On 2018-05-16 00:09, Nicolas Bougues wrote:

Bonsoir à tous,

Ca doit bien faire 10 ans que je n'ai pas posté ici mais j'ai déjà 
pas mal

réfléchi sur ce sujet d'interco SIP multi latérale.

Je me permets donc de vous exposer en quelques mots les principaux 
points

sur lesquels j'ai un avis.

D'un point de vue technique, ça tournerait autour de :

   - une poignée de proxys SIP, genre Kamailio par exemple, installés 
de

   façon géographiquement / topologiquement diversifiée, adressés en
   round-robin / failover
   - ces machines ne géreraient que la signalisation; le media serait 
routé
   directement entre les SBCs des opérateurs reliés; il serait donc 
laissé à

   l'appréciation de chaque opérateur s'il lui parait pertinent de se
   contenter, pour parler avec chaque opérateur, d'une interco 
publique,

   privée ou d'un hybride (VLAN sur un GIX, whatever)
   - la signalisation serait basée sur les specs SIP FFT (qui sont
   maintenant à peu près complètes et bien supportées), avec des
   recommendations plus étendues en ce qui concerne le media (codecs 
audio
   variés, video, T38...). Le SDP permet une négo pourquoi s'en 
priver ?
   - bien évidemment un filtrage d'IPs serait réalisé, chaque 
opérateur
   membre publiant sa liste d'IPs in/out pour sig et media, 
publication qui
   serait utilisée par les proxies pour filtrer en input et forwarder 
les

   appels, et diffusée aux membres pour accepter les flux media

En ce qui concerne le routage :

   - pour répondre à ce que j'ai vu plus haut dans la discussion, il 
semble
   difficile de "penser BGP" : la notion d'aggrégation (qui préside 
pourtant à
   l'attribution de tranches de 1000 ou 1 numéros aux opérateurs 
par
   l'ARCEP) est complètement annihilée par la portabilité et autres 
exceptions

   (liste de numéros en routage TDM par exemple)
   - on est donc à peu près obligé d'avoir d'un côté un routage par 
défaut
   suivant l'opérateur attributaire de la tranche, avec un lookup 
unitaire sur
   une (voire des) base(s) d'exceptions; c'est de toute façon ce que 
font
   aujourd'hui tous les opérateurs (ne serait-ce que parce que le 
préfixage
   des numéros portés est facturable s'il n'est pas fait par 
l'opérateur

   appelant)
   - ces informations (tranches, portas...) sont aujourd'hui publiées 
sous
   forme de fichiers CSV ou de web services par l'APNF, qui le fait 
très bien
   - en ce qui concerne ENUM, c'est une belle idée sur le papier, 
mais j'ai

   plusieurs réserves :
  - ça nécessite la mise en place chez chaque acteur d'un DNS  
précis
  et disponible; ça ne fait pas partie des choses "bien connues" 
chez les

  opérateurs telecom, même s'ils font de la VoIP
  - ça nécessite d'être mis à jour en temps réel et avec 
exactitude par
  l'attributaire d'un numéro lors d'une porta sortante; or il 
n'est pas
  exceptionnel qu'un attributaire ne réalise pas correctement 
leur part des
  portas sortantes (c'est-à-dire le reroutage vers le préfixe 
destination);
  dans un tel cas, une publication APNF par le prenant permet de 
régler
  l'essentiel du problème à l'échelle de 24h et sans le concours 
du cèdant;

  difficile d'imaginer revenir à un routage indirect seulement
  - Numérobis, en 2002, ça rappelle quelque chose à quelqu'un ? 
;)
  - ma conclusion, c'est qu'il ne faut pas baser un tel projet 
sur

  ENUM, en tous cas au départ, et que si ENUM il devait y avoir,
une version
  centralisée (gérée par

[FRnOG] [MISC] Séminaire OWF « Le jour d’après »

Re: [FRnOG] [MISC] Quand c'est pas le jour (14/05) !

Re: [FRnOG] [MISC] Panne Nationale voix Orange : quand le service client est magique

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

[FRnOG] [JOBS] À la recherche d'un ingénieur système / virtualisation expérimenté à Bordeaux

[FRnOG] [JOBS] À la recherche d'une alternance sur Lyon

Re: [FRnOG] [TECH] Accès portail client Orange

Re: [FRnOG] [TECH] Serveur d'authentification

[FRnOG] [BIZ] Vente CISCO NEXUS N5K et N2K

RE: [FRnOG] [TECH] Accès portail client Orange

Re: [FRnOG] [TECH] Accès portail client Orange

RE: [FRnOG] [ALERT] Problème interco orange

Re: [FRnOG] [ALERT] Problème interco orange

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

Re: [FRnOG] [ALERT] Problème interco orange

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

Re: [FRnOG] [ALERT] Problème interco orange

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

Re: [FRnOG] [TECH] Serveur d'authentification

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

RE: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

Re: [FRnOG] [MISC] Peering SIP (was Problème interco orange)

28 matches

Site Navigation

Mail list logo

Footer information