Re: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

2018-05-18 Par sujet Radu-Adrian Feurdean 
On Fri, May 18, 2018, at 18:42, Raphael Mazelier wrote:
> - Alcaltel : ils existent encore ? :)

s/Alcatel/Nokia/g
Mais pas sur qu'ils ont ce que tu cherches (pas vu du 25 Gbps chez eux, le 100G 
"merchant silicon" uniquement chassis...).


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

Re: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

2018-05-18 Par sujet Raphael Mazelier 

On 18/05/2018 10:27, Julien Thomas wrote:

Salut,
Dell série Z!

http://www.dell.com/en-us/work/shop/povw/networking-z-series

Tu peux même choisir l'OS que tu mets dessus derrière (Dell OS9, 0S10, 
Cumulus, etc.)
Le support Dell network est réactif et compétent et le prix est très 
correcte par rapport à la concurrence, donc c'est vraiment pas mal.





Mhm les pricing que j'avais eu n'était pas fou fou.
OS9 , OS10 je n'ai jamais testé. C'est censé être stable et avoir des 
features en L3 ?


--
Raphael Mazelier


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

Re: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

2018-05-18 Par sujet Raphael Mazelier 

On 18/05/2018 10:06, BLANCPAIN Nicolas wrote:

Question idiote sans doute, mais pourquoi pas les classiques : Cisco, Alcatel, 
HP ?
Trop cher ?



- Cisco : hors de prix, avec un NOS sur ces modèles contestable on va dire.
- HPE : ils n'ont quasi plus de nouvelle gamme, mais je vais demander 
quand même vu que c'est ce que j'ai actuellement (HPE 5200, 12500) et 
que j'en suis plutôt content. Ceci dit chez HP c'est un peu le souk 
niveau gamme. Sur leur site tu trouve du HPE, du ex-procurve, du Aruba, 
du Arista, et même de l'Alcatel...

- Alcaltel : ils existent encore ? :)

--
Raphael Mazelier


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

RE: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

2018-05-18 Par sujet Michel Py 
> Emmanuel DECAEN a écrit :
> - fs.com qui fait des switchs maintenant En étant prudent sur la 
> disponibilité des switchs dans l'entrepôt
> en Allemagne, ça doit pouvoir se tester ;-) Quand j'avais regardé l'année 
> dernière, Cumulus ne faisait pas
> partie dela liste des NOS supportés, j'avais donc décidé d'attendre un peu 
> avant de tester.

Ils ont plusieurs modèles "barebones" qui viennent avec ONIE donc on peu 
installer Cumulus, jamais essayé. Si il y a quelqu'un qui essaie je serais 
intéressé par le retour.

Michel.


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

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

2018-05-18 Par sujet GUILLOT Florent 
Pareil chez nous, mdp.orange.fr ne fonctionne pas via Level3.
Et ça ne ping même pas (alors que depuis 3215 ça répond bien au ping)
Le traceroute se perd juste après le premier saut Level3.
Les sondes atlas confirment: 
https://atlas.ripe.net/measurements/12770773/#!probes

L'Internet by Orange c'est compliqué...
Florent

-Message d'origine-
De : Laurent GUERBY [mailto:laur...@guerby.net]
Envoyé : vendredi 18 mai 2018 15:21
À : GUILLOT Florent ; Hugues Voiturier 

Cc : felix.bouy...@setenforce.one; frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Accès portail client Orange

On Thu, 2018-05-17 at 07:10 +, GUILLOT Florent wrote:
> Effectivement c’est corrigé !
>
> Bonne journée,
> Florent

Bonjour,

Un collegue via Renater AS2200 m'a signalé que https://mdp.orange.fr/ n'etait 
plus joignable et coté AS197422 ca ne marche que si on rebascule sur un chemin 
via AS3215, donc j'ai remis nos petites regles vers l'operateur qui sait 
(presque) faire du telephone qui marche.

Troll du vendredi ? :)

Laurent


> De : Hugues Voiturier [mailto:hugues-lis...@milkywan.fr]
> Envoyé : mercredi 16 mai 2018 15:17
> À : GUILLOT Florent  Cc :
> felix.bouy...@setenforce.one; Laurent GUERBY  >; frnog-t...@frnog.org
> Objet : Re: [FRnOG] [TECH] Accès portail client Orange
>
> C’est corrigé visiblement, vous confirmez ?
>
> Hugues
> AS50628 - AS57199
>
>
> On 16 May 2018, at 14:10, GUILLOT Florent  mailto:fguil...@fltechno.scc.com>> 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 mailto:laur...@guerby.net>>;
> GUILLOT Florent mailto:FGUILLOT@fltechno.s
> cc.com>>; 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" mailto:laurent
> @guerby.net>> 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

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

2018-05-18 Par sujet Laurent GUERBY 
On Thu, 2018-05-17 at 07:10 +, GUILLOT Florent wrote:
> Effectivement c’est corrigé !
> 
> Bonne journée,
> Florent

Bonjour,

Un collegue via Renater AS2200 m'a signalé que
https://mdp.orange.fr/ n'etait plus joignable
et coté AS197422 ca ne marche que si on rebascule
sur un chemin via AS3215, donc j'ai remis nos petites
regles vers l'operateur qui sait (presque) faire
du telephone qui marche.

Troll du vendredi ? :)

Laurent


> De : Hugues Voiturier [mailto:hugues-lis...@milkywan.fr]
> Envoyé : mercredi 16 mai 2018 15:17
> À : GUILLOT Florent 
> Cc : felix.bouy...@setenforce.one; Laurent GUERBY  >; frnog-t...@frnog.org
> Objet : Re: [FRnOG] [TECH] Accès portail client Orange
> 
> C’est corrigé visiblement, vous confirmez ?
> 
> Hugues
> AS50628 - AS57199
> 
> 
> On 16 May 2018, at 14:10, GUILLOT Florent  mailto:fguil...@fltechno.scc.com>> 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 mailto:laur...@guerby.net>>;
> GUILLOT Florent mailto:FGUILLOT@fltechno.s
> cc.com>>; 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" mailto:laurent
> @guerby.net>> 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
> co

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

2018-05-18 Par sujet Sébastien Lesimple 
Bof, ca s'automatise a tous les niveaux si vous filez des API bien foutus.
Trunk, plans de num etc...


Le 18/05/2018 à 13:55, David Ponzone a écrit :
> Moyennement gérable s’il y a 30/40 acteurs quand même…
>
>
> On 18 mai 2018 13:54 +0200, Sébastien Lesimple
> , wrote:
>> Hello,
>>
>> Si je devais remonter ma solution tech, la seule chose dont j'aurais
>> besoin, c'est le plan de num de chaque membre en fichier à plat dans un
>> SFTP (avec sa fréquence de mise a jour) et un trunk vers le membre
>> détenteur de ND. Les SLA et les CAPS de chacun pour pas bastonner trop
>> fort et c'est tout...
>>
>> En fait c'est déjà comme cela que je faisais en 2006, rien de nouveau.
>> Les usines a gaz ou je maitrise pas la terminaison, j'ai vécu avec
>> Viatel...
>> Merci, mais non merci!
>>
>> Seb.
>>
>> Le 17/05/2018 à 12:08, Mickael Hubert a écrit :
>>> Bonjour à tous,
>>>
>>> Le 17 mai 2018 à 11:19, Richard DEMONGEOT  a
>>> écrit :
>>>
 Hello,

 Toutes les idées a base de BGP sont très sexy, et intéressantes,
 mais il
 reste un problème de base. Comment chaque opérateur va devoir
 implémenter
 un composant liant BGP / Voix.
 Cependant, comme évoqué à plusieurs reprises, pas de modifications
 incessantes de la table de routage voix.

>>>
>>> *Pour ma part le composant de routage pour la voix devrait-être le DNS
>>> (ENUM), je sais j'insiste sur ce point ;) , mais devoir trouver /
>>> développer un composant "gateway" entre BGP et voix pour gérer du
>>> trafic de
>>> prod me semble hasardeux.*
>>> *Bon, ce composant existe peut-être déjà, je ne sais pas...*
>>>
>>>
 Pour la table de routage internationale, OSEF dans un IX. (ou
 alors, c'est
 un GIE, donc avec plusieurs fournisseurs, et c'est plus complexe). Dans
 tous les cas, les changements sur les non-membres : on s'en fout.
 (porta
 depuis / vers les membres à gérer uniquement). Exemple : porta
 orange / sfr
 : quel impact vu qu'a moyen terme aucun des deux ne sera dessus? Pire,
 belgacom / proxymus?

 Pour moi, le plus simple, sur, rapide, fonctionnel reste :

 Un IX dédié à la voix (qu'on peut multiplier à souhaits).
 Sur cet IX :
 - Chaque membre qui s'y connecte doit y mettre un ou plusieurs SBC;
 - L'association fourni un ou plusieurs proxy SIP - en guise de
 voice route
 server.

 Coût pour l'association :
 1 switch (1G/10G de préférence);
 3 serveurs (db + proxy).

 Le cheminement serai alors le suivant :
 Le SBC du client envoie son INVITE SIP, sur le / l'un des proxy.
 Le proxy intérroge la DB, fournie par l'APNF, et route sur le bon
 membre.
 => Si c'est pas sur un membre, alors plusieurs cas sont possibles :
 A/ L'association renvoi un code retour temporaire ou permanent sur ce
 numéro (pas routable sur l'IX);
 B/ L'association étant un GIE, et disposant de contrat de
 terminaison SIP
 peut router le numéro. ==> Quid de la facturation/re-facturation? Par
 contre, économie d'échelle si les contrats sont mutualisés.
 => Si le membre ne réponds pas (SIP option réguliers) alors on
 réponds une
 erreur temporaire. (ou on load balance sur moins d'IP si le membre a
 plusieurs SBC)

>>>
>>> *Chaque provider connecté au X doit avoir une réplication de la DB.
>>> Car si
>>> tout est géré (au niveau routage voix par le X) nous nous
>>> retrouverons dans
>>> le même cas (plantage d'Orange) si celui-ci plante.*
>>>
>>>
>>> *De plus, cela engendre du trafic SIP (et des réponses) pour pas grand
>>> chose.*
>>>
>>> *Je voyais cela plutôt:*
>>>
>>> *- lors de l'import de la DB APNF chez le provider, celui-ci sait qui se
>>> trouve connecté sur tel ou tel X et donc créé sa propre DB avec tel
>>> préfixe
>>> vers tel X (donc telle IP), puis tel préfixe vers l'autre X, etc ...
>>> (cela
>>> peut-être automatisé, voir même si on parle d'asso en plus de l'APNF,
>>> celle-ci pourrait fournir une DB modifiée avec les préfixes quelle
>>> gère)*
>>>
>>> *- lors d'un appel vers tel numéro hors de son réseau, la DB chez le
>>> provider sait où envoyer au plus proche*
>>> *- Sinon on envoie par défaut sur son transitaire voix (du genre
>>> Orange ;)
>>> )*
>>>
>>>
>>>
 Dans les deux cas, ralentissement de l'établissement de quelques
 milli-secondes pour le SBC appelant, c'est largement acceptable pour
 fall-back sur un autre fournisseur.

 Dans le modèle IX, je préfère l'option A, qui simplifie le boulot pour
 l'asso.

 Et pour la croissance me direz vous?
 Là encore, deux options :
 A/ On déploie un IX dans chaque DC, en se moquant complètement de
 l'interco, c'est à dire que chaque POP est stand-alone; (coûts
 multipliés
 par le nombre de POP)

 B/ On déploie un réseau multi DC (donc plus complexe), et les
 membres de
 l'interco Lyon peuvent taper sur des ressources Bordeaux. Pour les
 SBC des
 clients, c'est si

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

2018-05-18 Par sujet Sébastien Lesimple 
Encore plus simple, l'info de routage envoyée dans le SIP URI pour
indiquer ou envoyer le trafic et roulez bolides...
Pas besoin de tripatouiller le RTC, vous traitez uniquement la SIG comme
il se doit, rien d'autre.
Seb.

Le 18/05/2018 à 13:53, Sébastien Lesimple a écrit :
> Hello,
>
> Si je devais remonter ma solution tech, la seule chose dont j'aurais
> besoin, c'est le plan de num de chaque membre en fichier à plat dans un
> SFTP (avec sa fréquence de mise a jour) et un trunk vers le membre
> détenteur de ND. Les SLA et les CAPS de chacun pour pas bastonner trop
> fort et c'est tout...
>
> En fait c'est déjà comme cela que je faisais en 2006, rien de nouveau.
> Les usines a gaz ou je maitrise pas la terminaison, j'ai vécu avec Viatel...
> Merci, mais non merci!
>
> Seb.
>
> Le 17/05/2018 à 12:08, Mickael Hubert a écrit :
>> Bonjour à tous,
>>
>> Le 17 mai 2018 à 11:19, Richard DEMONGEOT  a écrit :
>>
>>> Hello,
>>>
>>> Toutes les idées a base de BGP sont très sexy, et intéressantes, mais il
>>> reste un problème de base. Comment chaque opérateur va devoir implémenter
>>> un composant liant BGP / Voix.
>>> Cependant, comme évoqué à plusieurs reprises, pas de modifications
>>> incessantes de la table de routage voix.
>>>
>> *Pour ma part le composant de routage pour la voix devrait-être le DNS
>> (ENUM), je sais j'insiste sur ce point ;) , mais devoir trouver /
>> développer un composant "gateway" entre BGP et voix pour gérer du trafic de
>> prod me semble hasardeux.*
>> *Bon, ce composant existe peut-être déjà, je ne sais pas...*
>>
>>
>>> Pour la table de routage internationale, OSEF dans un IX. (ou alors, c'est
>>> un GIE, donc avec plusieurs fournisseurs, et c'est plus complexe). Dans
>>> tous les cas, les changements sur les non-membres : on s'en fout. (porta
>>> depuis / vers les membres à gérer uniquement). Exemple : porta orange / sfr
>>> : quel impact vu qu'a moyen terme aucun des deux ne sera dessus? Pire,
>>> belgacom / proxymus?
>>>
>>> Pour moi, le plus simple, sur, rapide, fonctionnel reste :
>>>
>>> Un IX dédié à la voix (qu'on peut multiplier à souhaits).
>>> Sur cet IX :
>>> - Chaque membre qui s'y connecte doit y mettre un ou plusieurs SBC;
>>> - L'association fourni un ou plusieurs proxy SIP - en guise de voice route
>>> server.
>>>
>>> Coût pour l'association :
>>> 1 switch (1G/10G de préférence);
>>> 3 serveurs (db + proxy).
>>>
>>> Le cheminement serai alors le suivant :
>>> Le SBC du client envoie son INVITE SIP, sur le / l'un des proxy.
>>> Le proxy intérroge la DB, fournie par l'APNF, et route sur le bon membre.
>>> => Si c'est pas sur un membre, alors plusieurs cas sont possibles :
>>> A/ L'association renvoi un code retour temporaire ou permanent sur ce
>>> numéro (pas routable sur l'IX);
>>> B/ L'association étant un GIE, et disposant de contrat de terminaison SIP
>>> peut router le numéro. ==> Quid de la facturation/re-facturation? Par
>>> contre, économie d'échelle si les contrats sont mutualisés.
>>> => Si le membre ne réponds pas (SIP option réguliers) alors on réponds une
>>> erreur temporaire. (ou on load balance sur moins d'IP si le membre a
>>> plusieurs SBC)
>>>
>> *Chaque provider connecté au X doit avoir une réplication de la DB. Car si
>> tout est géré (au niveau routage voix par le X) nous nous retrouverons dans
>> le même cas (plantage d'Orange) si celui-ci plante.*
>>
>>
>> *De plus, cela engendre du trafic SIP (et des réponses) pour pas grand
>> chose.*
>>
>> *Je voyais cela plutôt:*
>>
>> *- lors de l'import de la DB APNF chez le provider, celui-ci sait qui se
>> trouve connecté sur tel ou tel X et donc créé sa propre DB avec tel préfixe
>> vers tel X (donc telle IP), puis tel préfixe vers l'autre X, etc ... (cela
>> peut-être automatisé, voir même si on parle d'asso en plus de l'APNF,
>> celle-ci pourrait fournir une DB modifiée avec les préfixes quelle gère)*
>>
>> *- lors d'un appel vers tel numéro hors de son réseau, la DB chez le
>> provider sait où envoyer au plus proche*
>> *- Sinon on envoie par défaut sur son transitaire voix (du genre Orange ;)
>> )*
>>
>>
>>
>>> Dans les deux cas, ralentissement de l'établissement de quelques
>>> milli-secondes pour le SBC appelant, c'est largement acceptable pour
>>> fall-back sur un autre fournisseur.
>>>
>>> Dans le modèle IX, je préfère l'option A, qui simplifie le boulot pour
>>> l'asso.
>>>
>>> Et pour la croissance me direz vous?
>>> Là encore, deux options :
>>> A/ On déploie un IX dans chaque DC, en se moquant complètement de
>>> l'interco, c'est à dire que chaque POP est stand-alone; (coûts multipliés
>>> par le nombre de POP)
>>>
>>> B/ On déploie un réseau multi DC (donc plus complexe), et les membres de
>>> l'interco Lyon peuvent taper sur des ressources Bordeaux. Pour les SBC des
>>> clients, c'est simple, ils mettent une interface en /28 sur le POP, et une
>>> route vers la /22. (coût qui ne sont pas proportionnels au nombre de POP,
>>> mais besoin d'équipement L3 pour gérer le backbone).
>>>
>>> Poin

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

2018-05-18 Par sujet David Ponzone 
Moyennement gérable s’il y a 30/40 acteurs quand même…


On 18 mai 2018 13:54 +0200, Sébastien Lesimple 
, wrote:
> Hello,
>
> Si je devais remonter ma solution tech, la seule chose dont j'aurais
> besoin, c'est le plan de num de chaque membre en fichier à plat dans un
> SFTP (avec sa fréquence de mise a jour) et un trunk vers le membre
> détenteur de ND. Les SLA et les CAPS de chacun pour pas bastonner trop
> fort et c'est tout...
>
> En fait c'est déjà comme cela que je faisais en 2006, rien de nouveau.
> Les usines a gaz ou je maitrise pas la terminaison, j'ai vécu avec Viatel...
> Merci, mais non merci!
>
> Seb.
>
> Le 17/05/2018 à 12:08, Mickael Hubert a écrit :
> > Bonjour à tous,
> >
> > Le 17 mai 2018 à 11:19, Richard DEMONGEOT  a écrit :
> >
> > > Hello,
> > >
> > > Toutes les idées a base de BGP sont très sexy, et intéressantes, mais il
> > > reste un problème de base. Comment chaque opérateur va devoir implémenter
> > > un composant liant BGP / Voix.
> > > Cependant, comme évoqué à plusieurs reprises, pas de modifications
> > > incessantes de la table de routage voix.
> > >
> >
> > *Pour ma part le composant de routage pour la voix devrait-être le DNS
> > (ENUM), je sais j'insiste sur ce point ;) , mais devoir trouver /
> > développer un composant "gateway" entre BGP et voix pour gérer du trafic de
> > prod me semble hasardeux.*
> > *Bon, ce composant existe peut-être déjà, je ne sais pas...*
> >
> >
> > > Pour la table de routage internationale, OSEF dans un IX. (ou alors, c'est
> > > un GIE, donc avec plusieurs fournisseurs, et c'est plus complexe). Dans
> > > tous les cas, les changements sur les non-membres : on s'en fout. (porta
> > > depuis / vers les membres à gérer uniquement). Exemple : porta orange / 
> > > sfr
> > > : quel impact vu qu'a moyen terme aucun des deux ne sera dessus? Pire,
> > > belgacom / proxymus?
> > >
> > > Pour moi, le plus simple, sur, rapide, fonctionnel reste :
> > >
> > > Un IX dédié à la voix (qu'on peut multiplier à souhaits).
> > > Sur cet IX :
> > > - Chaque membre qui s'y connecte doit y mettre un ou plusieurs SBC;
> > > - L'association fourni un ou plusieurs proxy SIP - en guise de voice route
> > > server.
> > >
> > > Coût pour l'association :
> > > 1 switch (1G/10G de préférence);
> > > 3 serveurs (db + proxy).
> > >
> > > Le cheminement serai alors le suivant :
> > > Le SBC du client envoie son INVITE SIP, sur le / l'un des proxy.
> > > Le proxy intérroge la DB, fournie par l'APNF, et route sur le bon membre.
> > > => Si c'est pas sur un membre, alors plusieurs cas sont possibles :
> > > A/ L'association renvoi un code retour temporaire ou permanent sur ce
> > > numéro (pas routable sur l'IX);
> > > B/ L'association étant un GIE, et disposant de contrat de terminaison SIP
> > > peut router le numéro. ==> Quid de la facturation/re-facturation? Par
> > > contre, économie d'échelle si les contrats sont mutualisés.
> > > => Si le membre ne réponds pas (SIP option réguliers) alors on réponds une
> > > erreur temporaire. (ou on load balance sur moins d'IP si le membre a
> > > plusieurs SBC)
> > >
> >
> > *Chaque provider connecté au X doit avoir une réplication de la DB. Car si
> > tout est géré (au niveau routage voix par le X) nous nous retrouverons dans
> > le même cas (plantage d'Orange) si celui-ci plante.*
> >
> >
> > *De plus, cela engendre du trafic SIP (et des réponses) pour pas grand
> > chose.*
> >
> > *Je voyais cela plutôt:*
> >
> > *- lors de l'import de la DB APNF chez le provider, celui-ci sait qui se
> > trouve connecté sur tel ou tel X et donc créé sa propre DB avec tel préfixe
> > vers tel X (donc telle IP), puis tel préfixe vers l'autre X, etc ... (cela
> > peut-être automatisé, voir même si on parle d'asso en plus de l'APNF,
> > celle-ci pourrait fournir une DB modifiée avec les préfixes quelle gère)*
> >
> > *- lors d'un appel vers tel numéro hors de son réseau, la DB chez le
> > provider sait où envoyer au plus proche*
> > *- Sinon on envoie par défaut sur son transitaire voix (du genre Orange ;)
> > )*
> >
> >
> >
> > > Dans les deux cas, ralentissement de l'établissement de quelques
> > > milli-secondes pour le SBC appelant, c'est largement acceptable pour
> > > fall-back sur un autre fournisseur.
> > >
> > > Dans le modèle IX, je préfère l'option A, qui simplifie le boulot pour
> > > l'asso.
> > >
> > > Et pour la croissance me direz vous?
> > > Là encore, deux options :
> > > A/ On déploie un IX dans chaque DC, en se moquant complètement de
> > > l'interco, c'est à dire que chaque POP est stand-alone; (coûts multipliés
> > > par le nombre de POP)
> > >
> > > B/ On déploie un réseau multi DC (donc plus complexe), et les membres de
> > > l'interco Lyon peuvent taper sur des ressources Bordeaux. Pour les SBC des
> > > clients, c'est simple, ils mettent une interface en /28 sur le POP, et une
> > > route vers la /22. (coût qui ne sont pas proportionnels au nombre de POP,
> > > mais besoin d'équipement L3 pour gérer le backbone).
> > >
>

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

2018-05-18 Par sujet Sébastien Lesimple 
Hello,

Si je devais remonter ma solution tech, la seule chose dont j'aurais
besoin, c'est le plan de num de chaque membre en fichier à plat dans un
SFTP (avec sa fréquence de mise a jour) et un trunk vers le membre
détenteur de ND. Les SLA et les CAPS de chacun pour pas bastonner trop
fort et c'est tout...

En fait c'est déjà comme cela que je faisais en 2006, rien de nouveau.
Les usines a gaz ou je maitrise pas la terminaison, j'ai vécu avec Viatel...
Merci, mais non merci!

Seb.

Le 17/05/2018 à 12:08, Mickael Hubert a écrit :
> Bonjour à tous,
>
> Le 17 mai 2018 à 11:19, Richard DEMONGEOT  a écrit :
>
>> Hello,
>>
>> Toutes les idées a base de BGP sont très sexy, et intéressantes, mais il
>> reste un problème de base. Comment chaque opérateur va devoir implémenter
>> un composant liant BGP / Voix.
>> Cependant, comme évoqué à plusieurs reprises, pas de modifications
>> incessantes de la table de routage voix.
>>
>
> *Pour ma part le composant de routage pour la voix devrait-être le DNS
> (ENUM), je sais j'insiste sur ce point ;) , mais devoir trouver /
> développer un composant "gateway" entre BGP et voix pour gérer du trafic de
> prod me semble hasardeux.*
> *Bon, ce composant existe peut-être déjà, je ne sais pas...*
>
>
>> Pour la table de routage internationale, OSEF dans un IX. (ou alors, c'est
>> un GIE, donc avec plusieurs fournisseurs, et c'est plus complexe). Dans
>> tous les cas, les changements sur les non-membres : on s'en fout. (porta
>> depuis / vers les membres à gérer uniquement). Exemple : porta orange / sfr
>> : quel impact vu qu'a moyen terme aucun des deux ne sera dessus? Pire,
>> belgacom / proxymus?
>>
>> Pour moi, le plus simple, sur, rapide, fonctionnel reste :
>>
>> Un IX dédié à la voix (qu'on peut multiplier à souhaits).
>> Sur cet IX :
>> - Chaque membre qui s'y connecte doit y mettre un ou plusieurs SBC;
>> - L'association fourni un ou plusieurs proxy SIP - en guise de voice route
>> server.
>>
>> Coût pour l'association :
>> 1 switch (1G/10G de préférence);
>> 3 serveurs (db + proxy).
>>
>> Le cheminement serai alors le suivant :
>> Le SBC du client envoie son INVITE SIP, sur le / l'un des proxy.
>> Le proxy intérroge la DB, fournie par l'APNF, et route sur le bon membre.
>> => Si c'est pas sur un membre, alors plusieurs cas sont possibles :
>> A/ L'association renvoi un code retour temporaire ou permanent sur ce
>> numéro (pas routable sur l'IX);
>> B/ L'association étant un GIE, et disposant de contrat de terminaison SIP
>> peut router le numéro. ==> Quid de la facturation/re-facturation? Par
>> contre, économie d'échelle si les contrats sont mutualisés.
>> => Si le membre ne réponds pas (SIP option réguliers) alors on réponds une
>> erreur temporaire. (ou on load balance sur moins d'IP si le membre a
>> plusieurs SBC)
>>
>
> *Chaque provider connecté au X doit avoir une réplication de la DB. Car si
> tout est géré (au niveau routage voix par le X) nous nous retrouverons dans
> le même cas (plantage d'Orange) si celui-ci plante.*
>
>
> *De plus, cela engendre du trafic SIP (et des réponses) pour pas grand
> chose.*
>
> *Je voyais cela plutôt:*
>
> *- lors de l'import de la DB APNF chez le provider, celui-ci sait qui se
> trouve connecté sur tel ou tel X et donc créé sa propre DB avec tel préfixe
> vers tel X (donc telle IP), puis tel préfixe vers l'autre X, etc ... (cela
> peut-être automatisé, voir même si on parle d'asso en plus de l'APNF,
> celle-ci pourrait fournir une DB modifiée avec les préfixes quelle gère)*
>
> *- lors d'un appel vers tel numéro hors de son réseau, la DB chez le
> provider sait où envoyer au plus proche*
> *- Sinon on envoie par défaut sur son transitaire voix (du genre Orange ;)
> )*
>
>
>
>> Dans les deux cas, ralentissement de l'établissement de quelques
>> milli-secondes pour le SBC appelant, c'est largement acceptable pour
>> fall-back sur un autre fournisseur.
>>
>> Dans le modèle IX, je préfère l'option A, qui simplifie le boulot pour
>> l'asso.
>>
>> Et pour la croissance me direz vous?
>> Là encore, deux options :
>> A/ On déploie un IX dans chaque DC, en se moquant complètement de
>> l'interco, c'est à dire que chaque POP est stand-alone; (coûts multipliés
>> par le nombre de POP)
>>
>> B/ On déploie un réseau multi DC (donc plus complexe), et les membres de
>> l'interco Lyon peuvent taper sur des ressources Bordeaux. Pour les SBC des
>> clients, c'est simple, ils mettent une interface en /28 sur le POP, et une
>> route vers la /22. (coût qui ne sont pas proportionnels au nombre de POP,
>> mais besoin d'équipement L3 pour gérer le backbone).
>>
>> Point bonus de la solution B, le proxy peut être anycasté entre plusieurs
>> POP.
>>
>> Dans tous les cas, l'asso ne gère pas de transcoding (les membres envoient
>> le RTP de pair à pair);
>> Tant que tous les membres respectent un critère simple, supporter au moins
>> le G.711, tout est inter-opérable;
>> Si deux membres veulent jouer avec de la visio, ou des codec de plus haute
>> qualité,

RE: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

2018-05-18 Par sujet Clement Thery 
Pour ma part j'aime bien le NCS de Cisco que l'on peut trouver a un prix 
raisonnable en 1U en 24/36 ports 100G (QSFP je precise)
On a quelques bécanes en test, pour ceux qui veulent un peu plus d'info

Clement 


-Message d'origine-
De : frnog-requ...@frnog.org  De la part de BLANCPAIN 
Nicolas
Envoyé : vendredi 18 mai 2018 10:07
À : Xavier ROCA ; 'Raphael Mazelier' ; 
frnog-t...@frnog.org
Objet : RE: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

Question idiote sans doute, mais pourquoi pas les classiques : Cisco, Alcatel, 
HP ?
Trop cher ?

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Xavier ROCA Envoyé : vendredi 18 mai 2018 09:53 À : 'Raphael Mazelier' 
; frnog-t...@frnog.org Objet : RE: [FRnOG] [TECH] Switch / 
Routeur 100G cheap or not ?

Bonjour,

On y pense pas vraiment à Lenovo (surtout en France) mais ils ont une belle 
gamme de switch dont des 25G et 100G suite a différent rachat c'est de la 
techno déjà bien éprouvé.
https://www3.lenovo.com/us/en/data-center/networking/ethernet-rackswitch/c/ethernet-rackswitch
Prix très raisonnable comme pour les optiques

Pour nous la prise en main en Cloud NOS  lors d'un test n'a pas été fructueuse 
car bien trop différent de ce que l'on utilise habituellement.
Si besoin de contact, j'ai ça

Xavier

-Message d'origine-
De : Raphael Mazelier  Envoyé : jeudi 17 mai 2018 22:45 À : 
frnog-t...@frnog.org Objet : [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

Bonsoir la liste,

Étant à la recherche de matos edge ayant de la densité en port 100g et 25g, je 
suis en train de regarder les différents acteurs.

Niveau hardware ça sera visiblement le même partout, Broadcom et x86.
Fine.

Le choix se porte donc sur l’intégrateur du dit hardware et le NOS.
Niveau fonctionnalité j'ai besoin de bien peu de choses : BGP simple, pas de 
full (max 10k), ECMP 64way ça serait bien, sflow, et c'est à peu près tout.

On aurait donc :

- Arista 70XX, 71XX : ça à l'air d’être hype, EOS à l'air cool, mais c'est trop 
cher (le support notamment) et ils ont l'air rigide (les optiques ça se règle 
mais sur le principe déjà). On sent un peu la boite qui commence à être en 
position de force...
- Juniper QFX5200 : quid de la stabilité ? budget ?

et du whitebox :

- Edgecore
- fs.com qui fait des switchs maintenant
- et je viens de tomber la dessus NETBERG sur bm-switch à des prix imbattables 
, surtout avec un package avec l'os broadcom ICOS.

La question à 100 balles : qui connaît ces derniers ? et ICOS ? et aurait même 
de l'expérience en prod avec ca ? sur le papier c'est dans le registre du trop 
beau pour être vrai.

Sinon niveau NOS plus établi des avis éclairés entre Cumulus, Pica8, Bigswitch ?


Bon trolldi,


--
Raphael Mazelier











---
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] [TECH] Switch / Routeur 100G cheap or not ?

2018-05-18 Par sujet Julien Thomas 
Salut,
Dell série Z!

http://www.dell.com/en-us/work/shop/povw/networking-z-series

Tu peux même choisir l'OS que tu mets dessus derrière (Dell OS9, 0S10,
Cumulus, etc.)
Le support Dell network est réactif et compétent et le prix est très
correcte par rapport à la concurrence, donc c'est vraiment pas mal.


2018-05-18 10:06 GMT+02:00 BLANCPAIN Nicolas <
nicolas.blancp...@ext.pichet.com>:

> Question idiote sans doute, mais pourquoi pas les classiques : Cisco,
> Alcatel, HP ?
> Trop cher ?
>
> -Message d'origine-
> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part
> de Xavier ROCA
> Envoyé : vendredi 18 mai 2018 09:53
> À : 'Raphael Mazelier' ; frnog-t...@frnog.org
> Objet : RE: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?
>
> Bonjour,
>
> On y pense pas vraiment à Lenovo (surtout en France) mais ils ont une
> belle gamme de switch dont des 25G et 100G suite a différent rachat c'est
> de la techno déjà bien éprouvé.
> https://www3.lenovo.com/us/en/data-center/networking/
> ethernet-rackswitch/c/ethernet-rackswitch
> Prix très raisonnable comme pour les optiques
>
> Pour nous la prise en main en Cloud NOS  lors d'un test n'a pas été
> fructueuse car bien trop différent de ce que l'on utilise habituellement.
> Si besoin de contact, j'ai ça
>
> Xavier
>
> -Message d'origine-
> De : Raphael Mazelier  Envoyé : jeudi 17 mai 2018
> 22:45 À : frnog-t...@frnog.org Objet : [FRnOG] [TECH] Switch / Routeur
> 100G cheap or not ?
>
> Bonsoir la liste,
>
> Étant à la recherche de matos edge ayant de la densité en port 100g et
> 25g, je suis en train de regarder les différents acteurs.
>
> Niveau hardware ça sera visiblement le même partout, Broadcom et x86.
> Fine.
>
> Le choix se porte donc sur l’intégrateur du dit hardware et le NOS.
> Niveau fonctionnalité j'ai besoin de bien peu de choses : BGP simple, pas
> de full (max 10k), ECMP 64way ça serait bien, sflow, et c'est à peu près
> tout.
>
> On aurait donc :
>
> - Arista 70XX, 71XX : ça à l'air d’être hype, EOS à l'air cool, mais c'est
> trop cher (le support notamment) et ils ont l'air rigide (les optiques ça
> se règle mais sur le principe déjà). On sent un peu la boite qui commence à
> être en position de force...
> - Juniper QFX5200 : quid de la stabilité ? budget ?
>
> et du whitebox :
>
> - Edgecore
> - fs.com qui fait des switchs maintenant
> - et je viens de tomber la dessus NETBERG sur bm-switch à des prix
> imbattables , surtout avec un package avec l'os broadcom ICOS.
>
> La question à 100 balles : qui connaît ces derniers ? et ICOS ? et aurait
> même de l'expérience en prod avec ca ? sur le papier c'est dans le registre
> du trop beau pour être vrai.
>
> Sinon niveau NOS plus établi des avis éclairés entre Cumulus, Pica8,
> Bigswitch ?
>
>
> Bon trolldi,
>
>
> --
> Raphael Mazelier
>
>
>
>
>
>
>
>
>
>
>
> ---
> 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/
>



-- 

*Julien Thomas*
Direct: +33 1 71 72 27 94
julien.tho...@1000mercis.com

[image: 1000mercis] 
[image: Facebook] [image: Twitter]
[image: Linkedin]


[image: Numberly]


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

RE: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

2018-05-18 Par sujet BLANCPAIN Nicolas 
Question idiote sans doute, mais pourquoi pas les classiques : Cisco, Alcatel, 
HP ?
Trop cher ?

-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Xavier ROCA
Envoyé : vendredi 18 mai 2018 09:53
À : 'Raphael Mazelier' ; frnog-t...@frnog.org
Objet : RE: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

Bonjour,

On y pense pas vraiment à Lenovo (surtout en France) mais ils ont une belle 
gamme de switch dont des 25G et 100G suite a différent rachat c'est de la 
techno déjà bien éprouvé.
https://www3.lenovo.com/us/en/data-center/networking/ethernet-rackswitch/c/ethernet-rackswitch
Prix très raisonnable comme pour les optiques

Pour nous la prise en main en Cloud NOS  lors d'un test n'a pas été fructueuse 
car bien trop différent de ce que l'on utilise habituellement.
Si besoin de contact, j'ai ça

Xavier

-Message d'origine-
De : Raphael Mazelier  Envoyé : jeudi 17 mai 2018 22:45 À : 
frnog-t...@frnog.org Objet : [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

Bonsoir la liste,

Étant à la recherche de matos edge ayant de la densité en port 100g et 25g, je 
suis en train de regarder les différents acteurs.

Niveau hardware ça sera visiblement le même partout, Broadcom et x86.
Fine.

Le choix se porte donc sur l’intégrateur du dit hardware et le NOS.
Niveau fonctionnalité j'ai besoin de bien peu de choses : BGP simple, pas de 
full (max 10k), ECMP 64way ça serait bien, sflow, et c'est à peu près tout.

On aurait donc :

- Arista 70XX, 71XX : ça à l'air d’être hype, EOS à l'air cool, mais c'est trop 
cher (le support notamment) et ils ont l'air rigide (les optiques ça se règle 
mais sur le principe déjà). On sent un peu la boite qui commence à être en 
position de force...
- Juniper QFX5200 : quid de la stabilité ? budget ?

et du whitebox :

- Edgecore
- fs.com qui fait des switchs maintenant
- et je viens de tomber la dessus NETBERG sur bm-switch à des prix imbattables 
, surtout avec un package avec l'os broadcom ICOS.

La question à 100 balles : qui connaît ces derniers ? et ICOS ? et aurait même 
de l'expérience en prod avec ca ? sur le papier c'est dans le registre du trop 
beau pour être vrai.

Sinon niveau NOS plus établi des avis éclairés entre Cumulus, Pica8, Bigswitch ?


Bon trolldi,


--
Raphael Mazelier











---
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-18 Par sujet Alexis Lameire 
sauf que d'un point de vue opérateur de transit, c'est pas dans leur
intérêt de te donner les informations de LCR de façon clair.

La communauté pour la factu est utile, mais ne sera pas en pratique utilisé
par ceux chez qui celà serait utile. D'un point de vue LCR horaire on a le
soucis du temps de convergance BGP, on peut se retrouver sur des périodes
de quelques minute a faire passer les appels sur un LCR pas approprié.

Pour régler ce soucis il faut deux communauté : une communauté pour la
plage actuelle et une communauté pour la plage suivante avec le timestamp
de début. Ca permet de palier le temps de convergence.

Cordialement

Le 17 mai 2018 à 22:09, Jérôme Nicolle  a écrit :

> David,
>
> Le 15/05/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).
>>
>
> Dans le cas du routage voix on a pas du tout le même problème qu'avec l'IP
> : le lookup ne doit être fait qu'une fois par session, et il peut prendre
> quelques ms. Du coup le nombre de préfixe n'est qu'un problème de RAM sur
> le speaker MP-BGP, qui va de toute façon pousser ses updates dans une "FIB"
> à base de SQL ou d'ENUM en fonction des implémentations.
>
> On a donc pas de problème à gérer les 48 bits que requièrent le codage
> d'un numéro E.164, même si on devait les désagréger dans de très nombreux
> cas.
>
> Si on confirme la piste d'utiliser MP-BGP pour les annonces de préfixes et
> portabilités, alors on aurait à définir des communautés pour l'encodage de
> la tarification d'acheminement. Cela règlerait une fois pour toute la
> problématique d'implémentation d'un Least Cost Routing dynamique.
>
> En outre, les modifications temporelles de routage sont faciles à gérer,
> puisqu'il suffit d'un update MP-BGP à chaque changement de plage horaire.
>
> Globalement ça semble permettre de traiter en amont tout le merdier de
> redirections d'aboutement.
>
> @+
>
> --
> Jérôme Nicolle
> +33 6 19 31 27 14
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

RE: [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

2018-05-18 Par sujet Xavier ROCA 
Bonjour,

On y pense pas vraiment à Lenovo (surtout en France) mais ils ont une belle 
gamme de switch dont des 25G et 100G suite a différent rachat c'est de la 
techno déjà bien éprouvé.
https://www3.lenovo.com/us/en/data-center/networking/ethernet-rackswitch/c/ethernet-rackswitch
Prix très raisonnable comme pour les optiques

Pour nous la prise en main en Cloud NOS  lors d'un test n'a pas été fructueuse 
car bien trop différent de ce que l'on utilise habituellement.
Si besoin de contact, j'ai ça

Xavier

-Message d'origine-
De : Raphael Mazelier  
Envoyé : jeudi 17 mai 2018 22:45
À : frnog-t...@frnog.org
Objet : [FRnOG] [TECH] Switch / Routeur 100G cheap or not ?

Bonsoir la liste,

Étant à la recherche de matos edge ayant de la densité en port 100g et 25g, je 
suis en train de regarder les différents acteurs.

Niveau hardware ça sera visiblement le même partout, Broadcom et x86.
Fine.

Le choix se porte donc sur l’intégrateur du dit hardware et le NOS.
Niveau fonctionnalité j'ai besoin de bien peu de choses : BGP simple, pas de 
full (max 10k), ECMP 64way ça serait bien, sflow, et c'est à peu près tout.

On aurait donc :

- Arista 70XX, 71XX : ça à l'air d’être hype, EOS à l'air cool, mais c'est trop 
cher (le support notamment) et ils ont l'air rigide (les optiques ça se règle 
mais sur le principe déjà). On sent un peu la boite qui commence à être en 
position de force...
- Juniper QFX5200 : quid de la stabilité ? budget ?

et du whitebox :

- Edgecore
- fs.com qui fait des switchs maintenant
- et je viens de tomber la dessus NETBERG sur bm-switch à des prix imbattables 
, surtout avec un package avec l'os broadcom ICOS.

La question à 100 balles : qui connaît ces derniers ? et ICOS ? et aurait même 
de l'expérience en prod avec ca ? sur le papier c'est dans le registre du trop 
beau pour être vrai.

Sinon niveau NOS plus établi des avis éclairés entre Cumulus, Pica8, Bigswitch ?


Bon trolldi,


--
Raphael Mazelier











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



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