Re: [FRnOG] Re: [MISC] Facebook en carafe ?

[Pierre-Yves Kerembellec]

 Mon traceroute ne va nulle part, ping non plus... don rien à poster :-)
 Une fois sorti du cache l'appli Android ne marche pas, et idem pour iPhone.
 
 On me dit qu'en revanche cela serait OK derrière d'autres FAI...
 
 Non, j'infirme. Ça ne fonctionne (résout) plus non plus...

Chouette, (vraies) vacances pour tous ! ^_^
(ne marche pas sur les DNS Google, enfin la paix ...)

--
Pierre-Yves


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

Re: [FRnOG] Re: [MISC] Facebook en carafe ?

[Pierre-Yves Kerembellec]

 Haha oui, enfin vacances presque pour tous... sauf peut-être pour ceux qui 
 doivent expliquer à leurs clients que non, internet n'est pas fermé 
 aujourd'hui (parceque leur facebook ne fonctionne pas...)

Le nainternet il est cassé quand c'est le grand Gogol qui marche plus pour 
madame Michu ;-)

http://www.youtube.com/watch?v=CWW05O05ypAt=20s

Pour se servir de QuickTime en PDF sans bousiller ton OpenOffice quand tu 
lances un bug sur ton mur de Face de Bouc

 En passant, c'est pas ce qu'un groupe d'anonymous voulaient faire, faire 
 tomber facebook via une attaque dns ?
 
 Chouette, (vraies) vacances pour tous ! ^_^
 (ne marche pas sur les DNS Google, enfin la paix ...)

--
Pierre-Yves


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

Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?

[Pierre-Yves Kerembellec]

 Tout à fait d'accord avec vous, c'est très prometteur. Le pb est que c'est 
 interdit par nos ayants droits :(
 
 Duh… je crois qu'un facepalm s'impose. On lit beaucoup de choses sur Internet 
 concernant l'ignorance crasse de ces « ayant droits » mais ce genre de 
 situation dépasse l'entendement…
 
 Dans le même genre, savez-vous pourquoi, sur Neuf TV, les chaines telles que 
 TF1 ou M6 sont transportées en chiffré sur le réseau ? Réponse : parce que 
 les ayant droits l'exigent.
 
 Évidemment, ça ne semble même pas venus à l'esprit de ces « décideurs » 
 qu'empêcher l'interception de ces flux ne sert strictement à RIEN étant donné 
 qu'il est beaucoup plus simple d'acheter une carte tuner TNT à 30 € et 
 d'enregistrer directement depuis l'hertzien, avec en prime une meilleure 
 qualité ! Par contre pour empêcher de regarder la Neuf TV sur autre chose que 
 le décodeur (par exemple sur un PC), ah pour ça c'est très efficace. Quel 
 gâchis.
 
 Dans un autre domaine, on passera aussi sur le fait que d'autres « ayant 
 droit » se croient toujours en guerre contre la copie de Bluray à travers 
 HDCP et AACS alors que ça fait des lustres que n'importe qui peut copier 
 n'importe quel Bluray sans aucune difficulté à l'aide d'un logiciel gratuit 
 (ou presque).
 
 Monde de fous.


Qui plus est, les technologies mises en place servent généralement à crypter le 
toyau (RTMPE) ou a rendre l'accès plus complexe (SWFVerif, token exchange),
pas à crypter le contenu lui-même. En terme de sécurité, c'est cassé depuis 
bien longtemps (RTMPE == RC4 avec un échange obfusqué de clés DH (hum)
dans l'échange initial entre le player et le server FMS/Wowza/whatever, quant 
à SWFVerif == SHA256 du player Flash vérifié par le serveur (et obfusqué
lui aussi dans un XTEA à 2 balles)). Bref, rien qui ne tienne bien longtemps 
face à du rev-eng : il serait temps que les ayants-droits comprennent que curl 
est
maintenant linké par défaut avec la librtmp et que des outils comme 
rtmpdump/rtmpgw (http://rtmpdump.mplayerhq.hu/) deviennent de plus en plus à la 
portée
du script-kiddie moyen.

Les nouvelles méthodes de diffusion (HTTP chunks + adaptive streaming) qui sont 
peu à peu en train de remplacer les protocoles propriétaires pour des raisons
de coûts de licences serveurs et d'efficacité de cache dans l'infrastructure 
Internet d'aujourd'hui vont nécessairement faire revenir les mesures de 
sécurité sur le
contenu (encryption AES128 des payload contenannt les keyframes vidéo, 
encryption d'un paquet audio sur n pour rendre la bande son insupportable à 
écouter,
etc ...), avec récupération des clés out-of-band par le client, selon un 
protocole variable (SSL dans le cas d'Apple HTTP LIve Streaming, SSL + 
certificats individuels
dans le cas d'Adobe Flash Access 2, etc.).

En gros, la sécurité va se déplacer du canal de distribution au contenu 
lui-même, c'est le grand retour des DRM (c'est vendredi, c'est permis) ;-)

Cordialement,
Pierre-Yves




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

Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?

[Pierre-Yves Kerembellec]

 On a été approché par plusieurs éditeurs de ce type de solutions, et elles 
 sont toutes très séduisantes.
 Dans un autre contexte, je n'hésiterai pas à les utiliser. Dans l'actuel, je 
 préfère ne pas prendre de risque.
 
 J'ai en tête une réduction de ~ 30% du transit lorsqu'on utilise du P2P. Si 
 c'est aussi le taux de perte financière en perdant certains de nos contenus, 
 ça n'a plus de sens.
 
 Vous me direz qu'on pourrait le faire sur nos contenus et continuer à faire 
 du transit sur les contenus sensibles, mais du coup ça fait deux plateformes 
 à maintenir, des couts supplémentaires, un peu plus de jus de cervelle, 
 davantage de points of failure à surveiller, ...
 
 Bref, c'est pas simple ;)

Ce n'est clairement pas simple de rassurer les ayants-droits (on en sait 
quelque chose chez Dailymotion aussi ^_^),
mais c'est dans l'air du temps : avec l'avènement de la balise vidéo dans HTML5 
par exemple, ainsi que du streaming
sur  mobiles, il va bien falloir trouver des solutions qui les rassurent tout 
autant. En ce qui concerne le P2P, des solutions
comme Giraffic sont également séduisantes, et ne sont pas nécessairement 
antinomiques avec l'approche de distribution
par fragments (cette approche facilite par essence le découpage de gros 
contenus, nécessaire à la distribution P2P).

 Tout à fait d'accord avec vous, c'est très prometteur. Le pb est que c'est
 interdit par nos ayants droits :(
 On doit se contenter de technologies classiques comme Flash ou Silverlight.
 Malheureusement, nous n'avons pas trop le choix.
 
 Martin
 
 Sauf que ces technologies (y compris RTMP de Adobe) permettent
 également de capturer le contenu.
 Sous Linux, c'est dingue le nombre de choses théoriquement impossibles
 à copier qu'on voit traîner dans /tmp (c'est un peu plus compliqué
 sous Windows). Les ayants-droits semblent pourtant se satisfaire de
 cette situation, vu que 95% des gens ne savent même pas que le fichier
 est accessible si on s'en donne la peine.
 
 Possible qu'avec un joli enrobage du protocole BitTorrent dans un
 front-end maison, et un dossier de stockage pas mieux caché que ce que
 fait FlashPlayer, ils n'y voient que du feu. C'est jouable?

Cordialement,
Pierre-Yves




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

Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arrive aux USA ?

[Pierre-Yves Kerembellec]

 As-tu trouvé un moyen d'apporter un quelconque niveau de sécurité sur du 
 HTML5, en dehors d'un token ?
 On y réfléchit et mes équipes me poussent pour qu'on fasse le saut, mais sans 
 sécurité state of the art et sans outils de monétisation (oui, je sais, on 
 en revient tjs à l'argent ...), c'est pas simple.

Pour ce qui est de la balise video sur iDevice, HTTP Live Streaming + AES128 
+ clé via SSL est supporté (Apple-centric). Pour une future
norme playlists + chunks + sécurité des chunks dans les balises vidéo des 
différents vendeurs de navigateurs, il y a les discussions au niveau
FOMS  WHATWG (auquel nous sommes un peu associés), mais ça se cherche 
(forcément, c'est pas simple de mettre tout le monde d'accord).
Qui plus est, dès qu'on parle de DRM (ou assimilé, au sens large), on a en 
face le monde de l'open-source qui ne veut pas trop aborder le
sujet ... bon, on s'éloigne un peu (voire même carrément) du sujet de la ML, la 
suite en privé si tu veux ... ;-)

Ce qui est important dans ces technologies d'un point de vue opérateur (donc 
plus dans le sujet de la liste), c'est que cette fragmentation et le
fait de déplacer la sécurité dans le contenu lui-même plutôt que dans le tuyau 
amènent l'augmentation de la cachabilité des contenus à tous les
niveaux de l'infrastructure Internet (proxy-caches de l'origine, CDN 
intermédiaire (éventuellement), proxy-caches FAI,, poste client, etc.). Tout le
monde reçoit finalement le même contenu, et dans le cadre d'une imposition de 
sécurité par un ayant droit X ou Y, seuls les clients qui ont accès
aux clés peuvent lire ce contenu. Le réseau (et le protocole de transfert) 
devient donc agnostique de ce point de vue, et l'idée est justement
d'éparpiller au maximum ces fragments pour que l'effet cache soit lui-aussi 
optimal. Sans même penser aux utilisations commerciales, le simple
fait de passer sur ces technologies permet également une plus grande 
pénétration dans les entreprises, y compris pour de la diffusion live (ce qui
ne passe pas ou très mal actuellement).

De plus en plus d'opérateurs mettent en place des proxies-cache transparents 
dans leur core-network, voire même déploient leurs propres CDN
pour minimiser les coûts de transit externes (logique, même s'ils ont des 
100aines de GB avec des tiers 1, c'est quand même le nerf de la guerre).
Utiliser HTTP comme protocole de transport est la garantie que ces déploiements 
peuvent être opérationnels relativement vite (comparés à du
déploiement de serveurs RTMP par exemple, pour les raisons de coûts de licences 
et/ou de scalabilité à grande échelle).

 Ce n'est clairement pas simple de rassurer les ayants-droits (on en sait 
 quelque chose chez Dailymotion aussi ^_^),
 mais c'est dans l'air du temps : avec l'avènement de la balise vidéo dans 
 HTML5 par exemple, ainsi que du streaming
 sur  mobiles, il va bien falloir trouver des solutions qui les rassurent 
 tout autant. En ce qui concerne le P2P, des solutions
 comme Giraffic sont également séduisantes, et ne sont pas nécessairement 
 antinomiques avec l'approche de distribution
 par fragments (cette approche facilite par essence le découpage de gros 
 contenus, nécessaire à la distribution P2P).

Cordialement,
Pierre-Yves




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

Re: [FRnOG] Troll du mardi

[Pierre-Yves Kerembellec]

 Avec le rachat de dailymotion par orange, va t'on voir celui ci devenir  
 accessible uniquement derrière 5511 ?
 Quels seraient les effets pour la plupart des fai mondiaux ?
 
 Vous avez 4 heures, ramassage des copies a 18h !


Trop en avance dans la semaine, passera pas ... ;-)

Cordialement,
Pierre-Yves

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

Re: [FRnOG] Troll du mardi

[Pierre-Yves Kerembellec]

 est ce la fin de l'AS 41690 ? y'a t'il du démanagement de plateforme à 
 prévoir vers l'AS 3215 ?

Mais non, 41690 reste bien là ! Et comme indiqué dans l'article ci-dessous, une 
majorité de l'audience
est faite en dehors de France. /troll

 mais pt est-ce deja un site dont les visiteurs sont seulement de france et 
 de navarre.
 
 C'est pas ce que dit le communiqué d'Orange : 
 Déjà fortement implanté à l’international, avec 80% de ses utilisateurs 
 hors 
 de France, Dailymotion pourra accélérer sa croissance à l’international en 
 s’appuyant sur la présence du groupe Orange dans 32 pays.
 
 source : http://www.orange.com/fr_FR/presse/communiques/cp110125fr.jsp


Cordialement,
Pierre-Yves



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

[FRnOG] Re: [FRnOG] IPV6 day / La France est à l'origine de la moitié du trafic #IPv6 mondial

[Pierre-Yves Kerembellec]

 http://blogs.cisco.com/sp/france-is-famous-for-fine-wine-cheese-and-now-ipv6/

Merci qui ? Merci 12322 et sa box/ses DSLAM développés en interne ! \o/

Pierre-Yves

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

Re: Re : [FRnOG] Re: DNS P2P

[Pierre-Yves Kerembellec]

Salut,

 Salut la ML.
 
 Le respect du TTL est une vaste farce, jusqu'à il y a peu je pensais qu'avec 
 le déploiement massif de solutions GSLB et la publication ancienne d'articles 
 sur le sujet (dead A record / cache négatif) que la situation s'était 
 améliorée.
 
 Après discussion avec une certaine personne de Cisco travaillant sur le 
 sujet, il semble que la situation ait empirée ces dernières années, il y a 
 beaucoup de problèmes avec l'Asie mais également en Europe de ce point de vue 
 là (il y a des ISP en France qui cachent pendant 24 ou 48 heures de manière 
 inconditionnelle, sympa quand tu veux migrer un site web à fort trafic 24/7).
 
 J'ai rencontré des gens en formation travaillant pour diverses très grandes 
 sociétés qui ont eu des problématiques de cache infini avec des providers 
 asiatiques... (grands comptes banque / finance / assurance)
 
 Les articles originaux (un peu datés mais les concepts sont toujours 
 valables) sont ici :
 
 http://www.tenereillo.com/GSLBPageOfShame.htm
 http://www.tenereillo.com/GSLBPageOfShameII.htm
 http://www.tenereillo.com/BrowserDNSCache.htm
  
 Le problème des caches DNS est un débat assez récurrent et on en avait parlé 
 sur vegan.net avant son extinction.
 
 http://vegan.net/lb/archive/05-2009/0027.html
 http://vegan.net/lb/archive/05-2009/0029.html

Et dans la même veine DNS-o-llesque, on peut aussi parler des serveurs Orange 
qui filtrent les réponses qui contiennent des @IP RFC1918, bonjour le 
tripatouilage abusif pour le coup ! :-(

Pierre-Yves

Re: [FRnOG] [TECH] Free expérimente t'il le filtrage DNS ?

[Pierre-Yves Kerembellec]

 Je viens de tomber sur un truc bizarre.
 A ce que je constate, les resolvers de free ne répondent pas a une query de 
 type A quand la réponse est une ip privée.

Idem chez Orange depuis bien longtemps (c'est pour vous protéger des méchants 
pirates Mme Michu!).
On en a parlé ici-même il y a une quinzaine de jours je crois, l'archive de la 
liste est ton amie ...

 Démonstration en interrogeant le grand 8.8.8.8:
 
 -
 [salim@dedix ~]# dig switch48.sdv.fr. @8.8.8.8
 ;  DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5  switch48.sdv.fr. @8.8.8.8
 ;; global options:  printcmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 47131
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;switch48.sdv.fr.INA
 
 ;; ANSWER SECTION:
 switch48.sdv.fr.86169INA172.20.1.48
 
 ;; Query time: 82 msec
 ;; SERVER: 8.8.8.8#53(8.8.8.8)
 ;; WHEN: Thu Dec  8 16:12:29 2011
 ;; MSG SIZE  rcvd: 49
 -
 
 On voit bien que Google a répondu 172.20.1.48, ce qui est correct.
 Posons la même question a dns1.proxad.net:
 
 -
 [salim@dedix ~]# dig switch48.sdv.fr. @dns1.proxad.net
 
 ;  DiG 9.3.6-P1-RedHat-9.3.6-16.P1.el5  switch48.sdv.fr. 
 @dns1.proxad.net
 ;; global options:  printcmd
 ;; Got answer:
 ;; -HEADER- opcode: QUERY, status: NOERROR, id: 41696
 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
 
 ;; QUESTION SECTION:
 ;switch48.sdv.fr.INA
 
 ;; Query time: 9 msec
 ;; SERVER: 212.27.40.240#53(212.27.40.240)
 ;; WHEN: Thu Dec  8 16:13:53 2011
 ;; MSG SIZE  rcvd: 33
 -
 
 La réponse est vide.
 J'ai testé avec plusieurs IP privées dans plusieurs domaines, cela semble 
 généralisé.
 
 Question subsidiaire : Combien de RFC ce comportement viole t'il ?

Cordialement,

--
Pierre-Yves


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

Re: [FRnOG] [MISC] un petit peu de detente dans un monde de brutes

[Pierre-Yves Kerembellec]

 Bonsoir à tous,
 C'est pas trés technique mais interressant, surtout pour les jeunes
 qui ne connaissent pas bien la musique classique ;)
 http://medici.tv le requiem de verdi en direct de verbier diffusé sur un CDN.
 Vos avis sur la qualité vidéo sont bienvenus

Dailymotion Cloud ? Oui, la qualité est forcément parfaite ! ;-)

Pierre-Yves


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

Re: [FRnOG] [TECH] Switch L2 48x1GbE + 4x10GbE (SFP+) ?

[Pierre-Yves Kerembellec]

Le 23 mai 2014 à 11:38, Pierre-Yves Maunier pymaunier+li...@gmail.com a écrit 
:

 EX3300-48T fiable et pas cher.
 J'en ai plein qui poussent plusieurs 10aines de gigabits/s et ça marche.
 PS : des stacks de 2xEX3300
 
 tu te prépares des nuits blanches, des nerveuses brékdones comme on dit
 de nos jours.
 
 Je voulais écrire : Nervousse brékdones
 Saleté de correcteur.

Inventé à une époque post-Audiard ... tiens, ça ça passe par un stack de 
2xEX3300 : http://www.dailymotion.com/video/xhey4s ;-)

Cordialement,
Pierre-Yves Kerembellec





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

Re: [FRnOG] [TECH] Switch L2 48x1GbE + 4x10GbE (SFP+) ?

[Pierre-Yves Kerembellec]

Le 23 mai 2014 à 11:51, Pierre-Yves Maunier pymaunier+li...@gmail.com a écrit 
:

  EX3300-48T fiable et pas cher.
  J'en ai plein qui poussent plusieurs 10aines de gigabits/s et ça marche.
  PS : des stacks de 2xEX3300
 
  tu te prépares des nuits blanches, des nerveuses brékdones comme on dit
  de nos jours.
 
  Je voulais écrire : Nervousse brékdones
  Saleté de correcteur.
 
 Inventé à une époque post-Audiard ... tiens, ça ça passe par un stack de 
 2xEX3300 : http://www.dailymotion.com/video/xhey4s ;-)
 Non mais les EX3300 ça juste marche. :-)
 Ma réflexion était surtout pour les produits récents chez Juniper qui souvent 
 sortent avant maturité.
 EX3300 ça fait un certain temps maintenant et c'est relativement rock solid.
 Après on fait des trucs très basiques avec mais ils le font super bien :)


Tout à fait d'accord, je remet pas en cause. Seul petit point noir (mais qui 
doit être commun à tous
les Juniper à base de Flash) : si jamais coupure brusque de courant il y a 
(EX3300 == mono-alim),
le file-system sur la Flash probablement tu flingueras ... :-(

Cordialement,
Pierre-Yves Kerembellec





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

Re: [FRnOG] usb 3G+ pour les vacances

[Pierre-Yves Kerembellec]

Si, nativement depuis la 3.0 mais il me semble (mais je dis peut  
etre une connerie) que c'est possible depuis le début avec iphone  
jailbreaké (avec le petit soft qui va bien


PDANet en jailbreaké via Cydia.

Cordialement,
Pierre-Yves




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

Re: [FRnOG] Nouveau troll : qui doit payer ?

[Pierre-Yves Kerembellec]

 J'interviens juste pour signaler juste que l'ARCEP a mis en ligne 2 interview 
 des représentants de Dailymotion et UFC-Que choisir... chacun donne sa 
 définition de la neutralité des réseaux, indique quels sont selon lui les 
 enjeux de cette neutralité et ce qu'il attend des pouvoirs publics.

Pour info, Giuseppe parle au nom de l'ASIC (même s'il y a un gros panneau 
Dailymotion derrière, locaux oblige ... ^_^).
http://www.lasic.fr/

 Vous pouvez reprendre le débat, que je ne regrette pas d'avoir lancé, en 
 espérant ne pas trop détourner cette liste de sa vocation initiale... si 
 c'était le cas l'arbitre sifflera évidemment la fin de la récréation :-)

Cordialement,
Pierre-Yves




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

Re: [FRnOG] Saturation du lien Neuf = FreeIX ?

[Pierre-Yves Kerembellec]

 J'ai un peu le meme probleme avec la video de ce site :
 http://www.medici-arts.tv c'est du streaming flash encodé à 400 Kbps
 et apparemment les utilisitateurs de Free ne peuvent pas la voir
 correctement alors que je ne vois pas de pertes de paquets exceptés
 sur les routeurs cores de Free qui sont je pense dus au rate limit
 icmp.
 
 Si les freenautes (ou autres) peuvent me confirmer directement
 si ils streament cette video correctement ca serait trés gentil de
 leur part.

Je confirme que cette vidéo laggue bien chez Free (3 secs de play, 1 sec
de rebuffering, 3 secs de play, 1 sec de rebuffering, etc ...).

Pierre-Yves


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

Re: [FRnOG] Saturation du lien Neuf = FreeIX ?

[Pierre-Yves Kerembellec]

 Pour info, cette vidéo passe nickel depuis un accès ADSL Wanadoo Pro deLyon.
 Mé bon, on est bien d'accord, Flash n'est pas fait pour streamer de la vidéo
 de bonne qualité ;-)

Vraiment ? ^_^

http://www.stream-in-box.com/mgw?index=2

Pierre-Yves

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

Re: [FRnOG] Saturation du lien Neuf = FreeIX ?

[Pierre-Yves Kerembellec]

 je veux pas faire un troll mais ca passe nickel sur ma freebox

Oui, c'est la vidéo de www.medici-arts.tv qui pose problème apparament.
www.stream-in-box.com est hébergé sur de une Dedibox, donc forcément de
Free Bezon - Free Tuileries, ça marche plutôt bien ... ^_^

  Pour info, cette vidéo passe nickel depuis un accès ADSL Wanadoo Pro deLyon.
  Mé bon, on est bien d'accord, Flash n'est pas fait pour streamer de la vidéo
  de bonne qualité ;-)
 
 Vraiment ? ^_^
 http://www.stream-in-box.com/mgw?index=2

Pierre-Yves


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

Re: [FRnOG] Saturation du lien Neuf = FreeIX ?

[Pierre-Yves Kerembellec]

Bonsoir,

 Certain FAI dans le monde limite protocole de streaming et on est obliger a
 utilise le streaming a l'intérieur de HTTP. Est-ce que qqn sait si c'est
 possible de force flash a utiliser HTTP ?

C'est possible en utilisant RTMPT (au lieu de RTMP, rtpmt://... au lieu de 
rtmp://...
dans l'objet NetConnection) : cela va forcer une encapsulation du dialogue RTMP 
dans
du HTTP. Mais bon, on s'éloigne du sujet initial là ... ;-)

Pierre-Yves

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

Re: [FRnOG] concert live flash

[Pierre-Yves Kerembellec]

 En fait il s'agissait d'un probleme de redirection CDN,
 les americains sont assez nul en geographie, quand je vous
 disais dans un thread historique qu'il faudrait un CDN à la francaise
 :) (si il y'a des investisseurs qui lisent cette liste, ils peuvent me
 contacter)

^_^ Y'en a déja, mais ils sont utilisés pour des besoins bien spécifiques 
(/troll)

 Quand au traffic c'est vrai que c'est pas trés optimisé, j'ai toujours
 douté des protocoles de streaming encapsulés dans TCP, de mon
 temps on utilisait UDP pour tout ce qui est sensible.
 En plus j'entends dire souvent n'a pas vraiment une culture serveur.
 FMS2 est écrit en java.

? FMS2 est écrit en C++.

 Quand on aura trouvé un moyen simple de faire du http avec du throtling pour
 ne pas siphonner la bande passante aura t'on vraiment besoin de serveurs 
 flash ?

Des CDN comme Limelight proposent déja ce service (+ seeking).

Cordialement,
Pierre-Yves

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

Re: [FRnOG] streaming video taux d'encodage

[Pierre-Yves Kerembellec]

 Flash seulement depuis la dernière version sait lire le h264, seul 
 encodage qui permet d'atteindre un débit/qualité équivalent à Xvid (en 
 fait c'est quasiment la même chose). Pour toutes les autres versions de 
 flash (et je ne sais pas si la version Linux est à jour pour lire le 
 h264), il faut utiliser un encodage h263 dans une capsule FLV, et c'est 
 de loin beaucoup moins bon comme qualité.

La première version qui supporte le H.264 (décodeur d'origine MainConcept
intégré au player Flash) est la 9.0.64.0 (beta jusqu'en 9.0.103.0). La
version officielle (non beta) est la 9.0.115.0 (disponible sur les 3
plate-formes Windows, MacOSX et Linux). Sinon, On2 VP6 comme indiqué
ci-dessous.

 Après, en application professionnelle (donc couteuse) mais de bonne 
 qualité et compatible jusqu'a flash 7 ou 8, il y a On2 VP6 qui est un 
 compresseur propriétaire qui donne une bonne qualité d'image. Attention 
 toutefois, car la mise en place du système pour le streaming n'est pas 
 ce qu'on pourrait appeler simple d'usage ni logique, mais la qualité le 
 vaut bien (tm).

Il est tout à fait possible de compresser en On2 gratuitement, en utilisant :

- en live, Flash Video Encoder v2
- en différé, mencoder avec le support VP62 dans ffmpeg

 D'autre part, pour un enregistrement pareil, je pense qu'il est mieux de 
 laisser une très bonne qualité de compression pour l'audio quitte a 
 sacrifier la video pour le même bitrate. Du mp3 256kbps me semble un 
 grand minimum pour le son (flash ne sachant pas lire autre chose que du mp3)

Le player que Damien utilise n'active pas le smoothing quand la vidéo est
zoomée, d'où le gros effet de pixels pas beau. Ca mange un max de CPU mais
ça change complètement la qualitée perçue.

  En revanche, vu la qualité de flash sous linux (CPU à 100% même pour
  une video youtube, dailymotion je n'en parle pas), je ne peux pas dire
  d'où ça vient.

Oui, mais les vidéos Dailymotion sont bien plus zolies aussi ^_^

Pierre-Yves

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

Re: [FRnOG] streaming video taux d'encodage

[Pierre-Yves Kerembellec]

  Oui, mais les vidéos Dailymotion sont bien plus zolies aussi ^_^
 ajoute fmt=18 à la fin de ta video youtube et dis moi si la
 version dailymotion est toujours plus jolie :)

Quand je prends une version Dailymotion On2 en 512x384, oui elle reste bien 
plus zolie.

Pierre-Yves

/offtopic on a net ML

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

Re: [FRnOG] Internet, on arrête de jouer !

[Pierre-Yves Kerembellec]

[snip]
 mais il y a toujours de puriste qui vont dire oui mais et ils sont sur 
 les marges du marché qu'on veut bien toucher. en gros on ne s'adressent à
 ces clients. et donc on reste bien dans le oui. je n'ai pas de clients
 qui peuvent dire ça rame et ça c'est le meilleur et le plus court
 argument de ce poste. à moins qu'ils soient sur les marges du marché. 
 
 je parle bien sûr de l'hébergement. 

Excellent, voila la solution ! Toute l'infra de diffusion vidéo de YouTube et
Dailymotion sur des Kimsufi, suffisait d'y penser ! ;-)

Trève de blagues douteuses et de citations hors contexte ... j'ai vu dans un 
post
précédent (de JMP je crois) un petit passage sur RTMP vs HTTP download (dans 
un
cas on a du rate limiting, dans l'autre on bourrine le fichier et donc on 
gache
potentiellement du volume et par aggrégation de la bande passante peak, ce qui 
peut
provoquer des grosses saturations sur les peerings).

Qu'en pensent justement les FAI ? Est-ce qu'un mode de diffusion full-RTMP (ou
équivalent dans les autres technos WM/Real/...) serait quelque chose de plus
viable ou pas ?

Pierre-Yves

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

Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Internet, on a rrête de jouer !

[Pierre-Yves Kerembellec]

  On arrive en ce début 2008 à de la vidéo plein ecran HD en streaming,
  (ex: dailymotion HD), le flux moyen par internaute après çà (1500kps)
  n'aura plus besoin d'augmenter.
 
 le truc c'est que Dailymotion HD c'est pas de la HD.
 c'est de la SD (aka standard definition - 640x480*30/s ou 768x576*25/s)
 la vraie HD (1920x1080 i/p) c'est plus pres des 20Mbit/s
 dailymotion normal, c'est du quart d'écran...

 Rien à voir avec la soi-disant HD de Dailymotion, Youtube etc.

Non, nous faisons bien de la HD [EMAIL PROTECTED] si la résolution du contenu 
uploadé est compatible.
Je suis d'accord qu'au niveau bitrate, c'est un peu faible, mais ça donne quand 
même des trucs déja
pas mal pour du web ... par exemple :

http://www.dailymotion.com/pyke369/video/x4zcib
http://www.dailymotion.com/pyke369/video/x4zqb8

Cliquez sur le bouton zoom dans la barre de controle du player (à gauche du 
logo HD) et vous pouvez
aussi aller dans le menu une fois zoomé et sélectionner Taille originale. 
Avant de zoomer, il y a
aussi le combo CTRLI pour afficher des statistiques.

Attention, machine un peu puissante recommandée (c'est du On2 VP6, la version 
H.264 n'est pas poussée
pour le moment). YouTube a annoncé de la HD qui n'est même pas de la SD 
effectivement (ils sont passés
de 320x240 à moins de 560x420 et annoncent ça comme de la HD ^_^)

Merci de vérifier un minimum avant de sortir des fausses-vérités ! ;-)

Pierre-Yves

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

Re: [FRnOG] Re: Internet, on a rrête de jouer !

[Pierre-Yves Kerembellec]

  Non, nous faisons bien de la HD [EMAIL PROTECTED] si la résolution du 
  contenu uploadé est compatible.
  Je suis d'accord qu'au niveau bitrate, c'est un peu faible, 
 
 On ne va pas polémiquer et je pense qu'il y a bien consensus sur le fait 
 que la vraie HD c'est une résolution élevée *et* un bitrate élevé.
 1,5 Mb/s, c'est un bon début, mais ce n'est que le tiers du bitrate d'un 
 bon DVD en SD.

Certes, sauf que 8Mbps en MPEG-2 ou 8Mbps en H.264 AVC, ça n'est pas la même 
chose !
Les codecs vidéos évoluent pour consommer moins de bande passante à qualité 
égale.
Je peux aujourd'hui ré-encoder un DVD [EMAIL PROTECTED] en [EMAIL PROTECTED], 
avec une qualité
perçue équivalente.

 C'est le bitrate qui permet ensuite au flux MPEG d'être vu sur un écran 
 42 ou plus sans que les artefacts ne piquent les yeux ;-)

Oui bien sur, sauf que là c'est quand même pour un usage web-centric. Il y a 
d'autres
moyens de faire de la vraie HD depuis Dailymotion (encore une fois si le 
contenu envoyé
est de qualité suffisante), avec de la boucle de programmes multicast sur de la 
box IPTV.

Tout ça pour dire que la nature a horreur du vide, même dans les tuyaux ... ^_^

Pierre-Yves

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

Re: [FRnOG] Re: Internet, on a rrête de jouer !

[Pierre-Yves Kerembellec]

 et une chose qu'il ne faut pas oublier ... la puissance de calcul amont et 
 aval pour fabriquer tout cela ...
 on n'est pas prêt de se passer de processeurs.

Hé si, car on va bientôt pouvoir switcher sur du GPU (Nvidia Tesla vient à 
l'esprit) pour l'encodage par exemple.

 Le problème est que l'expérience utilisateur devant un PC et N x X Ghz 
 devrait être aussi bonne que derrière un bête poste de
 télévision et un lecteur dvd et ... ce n'est pas encore le cas. Les playeurs 
 actuels ou ex-Macromédia sont-ils trop gourmands ?
 Est-ce que c'est plutôt du coté des protocoles à décoder (On2, H264 ...) 
 qu'il faut chercher.

C'est On2 VP6 dans Flash Player qui pose des problèmes en HD aujourd'hui 
(surtout quand on active l'anti-aliasing et le
post-processing) : en effet, une partie du traitement est faite en soft pur 
(pour des raisons de support multi plate-formes
et de compositing final avec les éléments vectoriels de Flash notamment). La 
librairie H.264 de MainConcept qui est présente
dans FP9 depuis la version béta 9.0.64.0 résoud bien des problèmes, tout en 
donnant à bitrate égal une meilleure qualité.

Autre problème : en progressive download (non rate-limité), le thread qui le 
flux dans le navigateur et le met dans un fichier
temporaire pour que le plugin Flash vienne le relire a tendance à bouffer un 
max de ressources I/O, ce qui provoque des sortes
de syncopes dans la lecture tant que tout le flux ne s'est pas téléchargé ... 
l'utilisation du rate-limiting (en HTTP ou bien
nativement en RTMP) résoud ce problème également et permet une lecture 
parfaitement fluide avec un petit tampon mémoire de 3-5
secondes d'avance.

 Bref souvent ... ca rame grave, comme dirait l'autre. Et pour une fois, on ne 
 parle pas de tuyaux insuffisants ici ;-)
 Vivement des puces Wimax / GPU / H264 généralisées dans tous nos matériels, 
 que les développeurs puissent s'en donner à
 coeur joie !

Juste du bi-core et du H.264 AVC avec Flash Player 9.0.115.0+ et on est bons. 
Et c'est déja dispo aujourd'hui bien sur,
préparez les tuyaux ... ^_^

Pierre-Yves

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

Re: [FRnOG] Re: Internet, on a rrête de jouer !

[Pierre-Yves Kerembellec]

 C'est un peu chiant ce thread qui part dans tous les sens... En plus, tout le 
 monde dit des
 choses vraies mais en même temps tout est faux et tout se contredit.
 
 Et il faudra m'expliquer pourquoi il faut du flash pour faire du H264 sur 
 internet... ya un concept qui m'échappe.

On a jamais dis ça ? On a juste dis qu'il faut la dernière version de Flash 
pour faire du H.264 dans Flash sur internet.

 Pour vos vidéos HD, utiliser des trucs genre Vimeo (ex 
 : http://www.vimeo.com/792126 ) , qui cherchent dés le début a
 tirer vers le haut plutôt ...

Ha tiens, c'est un player Flash ;-)

 Au pire, sur youtube, ajouter fmt=18 a la fin de l'url pour passer sur un 
 mode HQ : 
 http://fr.youtube.com/watch?v=1IUgVR7kptAfmt=18

Ha tiens, du H.264 basse résolution ;-)

 Mon avis c'est que de toute manière l'internet, ça va fermer, c'est qu'un feu 
 de paille ! :)

C'est bien vrai : 640Kbps should be enough for everybody !

/thread

Pierre-Yves

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

Re: [FRnOG] RE: [FRnOG] RE: [FRnOG] Filtrage d'URL via BGP shunt : quelle faisabilité ? (+ présentation )

[Pierre-Yves Kerembellec]

 A l'heure où tous les FAI déploient des box chez l'abonné, y installer un
 petit proxy transparent avec une blacklist mise à jour régulièrement serait
 il possible ? Quel coûts (hors dev) cela pourrait-il engendrer ?

Oui, sauf qu'il est toujours possible de remplacer la box opérateur par un
modem classique ADSL, au prix générallement de la perte de la partie
téléphonie/télévision ... par exemple chez Free, un simple modem/routeur qui
implémente les bonnes RFC et ça marche parfaitement.

Du coup, il faudrait également changer les contrats abonnés en leur interdisant
d'utiliser un modem tiers ?

 Tout cela militant encore une fois pour un coeur de réseau neutre et un 
 système
 de filtrage distribué à la périphérie (box et serveurs).
 Box uniquement, du coup, puisque le but est de lutter contre les mechants 
 vilains serveurs.

Je voulais parler d'egress filtering chez les hébergeurs low-cost (DDBX, OVH  
co),
afin de bloquer également la prolifération des proxies ouverts ... sinon ce 
sera
assez facile de contourner les filtres dans les box ...

Pierre-Yves

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

Re: [FRnOG] Liste des datacenters parisiens

[Pierre-Yves Kerembellec]

  Global Switch (clichy)
  Interxion (aubervilliers / st denis / nanterre)
  Equinix/Ixeurope (roissy / st denis)
  Neuf Telecom/Ldcom netcenter (courbevoie)
  Telecity/Redbus (courbevoie)
  Telehouse (paris / paris)
  Le DC1 d'OVH (paris)
  Sans garantie : 
  Orange Business Services : Rueil Malmaison et Chevilly la Rue
 
 Il y avait un data FTH a Malakoff, ca y est toujours ?

Ho que non ! (souvenirs, souvenirs, ...) ;-)

Pierre-Yves

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

Re: [FRnOG] [MISC] Netflix in France

[Pierre-Yves Kerembellec]

Le 29 juil. 2014 à 00:40, Vincent Bernat ber...@luffy.cx a écrit :

 Tout a fait d’accord.  C’est un problème a géométrie hautement
 variable, je te le concede volontiers.  Par contre, si une chose est
 sure a 100% c’est qu’il est impossible de faire mieux que l’offload
 que Netflix offre a travers ses appliances en passant par un
 quelconque CDN traditionnel.
 
 Netflix tombe à 0% quand la seule vidéo regardée dans la journée n'est
 pas dans le cache et représente 1000 vues. Un CDN traditionnel tombe à
 presque 99.9% dans le même cas. Juste pour dire qu'un CDN avec cache
 infini peut sans problème faire mieux que Netflix. Si le rapatriement
 initial de Netflix compte comme une vue (parce que ça prend quand même
 de la BP), un CDN avec cache infini fait toujours mieux.
 
 J'ai pas d'avis dessus, mais sur NANOG, ils se sont bien étripés sur
 quelle méthode est plus efficace entre provisionner par avance et cacher
 au fil de l'eau. On peut comprendre que pour un petit provider, bouffer
 1Gbps de sa BP sans vraiment être sûr que cela serve vraiment, ça peut
 faire douter. Tandis que cacher au fil de l'eau, on est au moins sur
 qu'il y a du monde qui regarde.

Sur de la « moyen-tail » (i.e. = 1 à 2 vues / heure glissante sur une zone 
donnée), on peut
facilement atteindre 88-90% sur un CDN du commerce (Akamai, Edgecast, Level3, 
…), et
ce sur un catalogue de 40M+ vidéos encodées chacune en 4 à 9 qualités (suivant 
la qualité
de la vidéo en entrée), en mode « fil de l’eau », avec une garantie de 
time-to-first-frame
inférieure à 300ms.

En interne (équivalent de NFLX OC sur des PoP au « cul » des IX), on atteint 
des efficacités
de cache supérieures (ratio 1/30 à 1/40), car on contrôle mieux l’heuristique 
de mise en cache.
Un cache du commerce va chercher à cacher tout ce qui bouge, ce qui n’est pas 
forcément
la meilleure stratégie, et c’est bien pour cela qu’on envoie pas de la 
long-tail sur ce genre de
solutions (ça exploserait les coûts de feed pour une efficacité proche de 0 sur 
~85% des contenus).

Pour les boitiers au sein des réseaux d’opérateurs, le deal est win-win, 
surtout là où le transit
coûte 3 bras (Asie par ex.). Exemple : chez un opérateur qui pompe 20-30Gbps 
vers ses eyeballs,
on place 3-4 boitiers à 5-6k$ chacun (dans notre cas cela donne à peu près 
~30To de cache), ça
divise par 10 les besoins en feed et c’est rentabilisé en 2 mois.

Les boitiers (appro, livraison, télé-adminstration  maintenance) sont 
généralement à la charge du
fournisseur de contenu, le hosting (électricité/frigorie) et la bande passante 
« interne » au réseau
opérateur sont à la charge de l’opérateur.

Believe it or not, de très nombreux opérateurs sont prêts à « sauter le pas » : 
ça garantit qu’un
service populaire sera mieux délivré à leurs abonnés (qui auraient été le 
consulter de toute manière),
et ce pour un coût extrêmement faible (ce ne sont généralement pas les mètres 
carrés qui manquent).

Mais comme quelqu’un l’a évoqué plus haut, c’est « chacun pour sa g. » au 
niveau des déploiements
(pas de mutualisation entre les services, chacun gère son cache et son 
load-balancing applicatif
comme il l'entend). Brave world … ;-)

Cordialement,
Pierre-Yves



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

Re: [FRnOG] Re: [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Pierre-Yves Kerembellec]

Le 28 août 2014 à 16:26, David Ponzone david.ponz...@gmail.com a écrit :

 Juste pour ma culture G, c’est quoi l’avantage par rapport à VRRP ?

L3  L3 everywhere  ;-)

 Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
 cela ?
 
 
 On a mis ça en place chez Iguane quand j'y étais (en BGP) et chez Daily on
 utilise ça aussi.
 
 Avec des petits tweaks, tu peux même faire de l'ECMP sur ton serveur,
 pratique quand il est raccordé à 2 routeurs avec re-routage si un routeur
 fail.

Cordialement,
Pierre-Yves





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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Pierre-Yves Kerembellec]

Le 28 août 2014 à 16:39, Pierre Colombier pcdw...@pcdwarf.net a écrit :

 Tout à fait d'accord avec le problème théorique
 Cependant, je n'ai jamais vu en pratique.
 Est-ce qu'on peut définir ce que c'est qu'un réseau large.
 
 Pour moi un segment réseau large c'est entre /24 et /20.
 Au delà, j'appelle ça anormalement large
 Est-ce que quelqu'un à réellement éprouvé en pratique des problèmes liés à la 
 charge ARP dans des réseaux de ce genre ?

Y'en a : https://www.youtube.com/watch?v=XvQPo5gZ-F4

 Dans le premier cas (réseau L3), c'est la section 4. Les réseaux
 utilisant le routage mettent un routeur IP dans chaque baie, voire un
 pour chaque machine physique. Gros avantage : la diffusion des messages
 ARP ou ND, qui ne va pas au delà du premier routeur, est très limitée.
 Le problème décrit dans le RFC 6820 disparait donc complètement.
 Inconvénient : on n'a plus aucune souplesse. Changer une VM de baie,
 voire de serveur physique dans la même baie, oblige à la changer
 d'adresse IP, ce qui va casser les sessions en cours, nécessiter une
 reconfiguration, etc. Cette architecture ne convient donc que lorsque
 le data center est assez statique, ou bien lorsque les services qui y
 tournent peuvent supporter ces changements d'adresses IP.

Cordialement,
Pierre-Yves





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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Pierre-Yves Kerembellec]

 Oui c'est assez courant d'annoncer des VIP en /32 dans le réseau, en 
 OSPF, ou plutôt en BGP (avec exabgp par exemple).
 
 Enfin, entre quelques VIP et *toutes* les machines, il y a une
 difference
 
 Bah, pourquoi pas. Ça dépend combien tu as de machines. Il y a pas mal
 de switchs ToR qui sont capables d'avoir beaucoup de routes (souvent le
 même ordre de grandeur que le nombre de MAC). Genre 16k en IPv4 pour les
 EX4200 (attention, beaucoup moins en IPv6) et autres de la même gamme,
 128k en IPv4 pour les QFX5100.
 
 Avant d'atteindre 128k VM, il y a de la marge.
 
 Si tu passes par des route servers Linux, tu peux aussi aggréger avant
 de redistribuer aux switchs ToR. Si les migrations se font généralement
 par subnet ou de manière ponctuelle/discrète, la table de routage doit
 pouvoir rester assez compacte.

Exactement. On remplace une table L2 (ARP) par une table L3 (IP) tout 
simplement.
Les 2 étant gérées en hardware dans les routeurs/switches depuis des années, 
cela
ne pose pas de problème … et apporte beaucoup de souplesse et moins de soucis
divers et variés avec le L2 (que celui ou celle qui n’a jamais galèré avec une 
boucle
STP lève le doigt ! ^_^)

Cordialement,
Pierre-Yves



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

Re: [FRnOG] [TECH] RFC 7342: Practices for Scaling ARP and ND in Large Data Centers

[Pierre-Yves Kerembellec]

Le 12 sept. 2014 à 11:44, Xavier Beaudouin k...@oav.net a écrit :

 Sinon pour soulager le protocole de routage, une solution :
 des top of racks faisant du routage, un subnet par rack : disons un /26 par
 rack pour 100 racks.
 Tu configures tes TOP of rack pour n'annoncer que son /26 vers l'agrégation
 bien que lui connaitra les 64x/32
 
 En temps normal tes switches/routeurs d'agrégation vont avoir 100 routes
 dans leur table.
 Si tu veux bouger un host vers un autre rack, le TOR du rack destination
 annoncera du coup son /26 et le /32 supplémentaire.
 Et rien ne t'empêche de changer l'IP de la machine pour qu'elle rentre dans
 le /26 du nouveau rack.
 
 En gros en situation optimale tu as 6400 hosts mais 100 routes dans
 l'aggreg.
 
 
 Pour couvrir le cas des 100aines de milliers de machines on va dire que tu
 tu es sur plusieurs DC.
 Disons un /14 par DC soit 256K hosts, ça fait 1000 racks de /24.
 
 Chaque coeur de DC connaitra le /14 du DC d'a cote et les 1000x/24 locaux
 et éventuellement quelques centaines de /32 more specific locaux, voire
 venant de l'autre DC si tu bouges des hosts du DC 1 au DC 2.
 
 Bref sans doute moins de 10k routes pour joindre 512k hosts.
 
 Dans tous les cas, un mec qui a plusieurs centaines de milliers de hosts
 peut se permettre d'avoir des routeurs prenant plusieurs millions d'entrées
 en RIB/FIB et BGP gère ça très bien.
 
 C'est marrant, quand je proposais ce genre de choses il y a 5 ou 6 ans on me 
 prenais pour un doux dingue...
 on ceci dit fallait bidouiller sec pour que ca marche, mais du L3 distribué = 
 flexibilité... 

Poussons plus loin : chaque machine est un porte-conteneur avec une /24 
attribuée, et dès qu’un conteneur
se spawne, il s’enregistre dans un système distribué qui permet de retrouver le 
service offert par ce conteneur.
Du coup il n’y a plus d’annonces dynamique au niveau réseau, juste plein de /24 
routées statiquement (et en
IPv6, là osef complètement …). Il est temps de passer à Docker ! \o/ /trolldi

Cordialement,
Pierre-Yves


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

Re: [FRnOG] [TECH] Content Delivery Network (CDN) à la francaise

[Pierre-Yves Kerembellec]

Bonsoir,

 Je ressors un vieux sujet de 2006 
 :)https://www.mail-archive.com/frnog@frnog.org/msg00854.html
 Nous sommes en 2014, il me paraît intéressant de faire le point / l'état des 
 lieux sur les différents sujets abordés à l'époque (évolution du trafic (plus 
 particulièrement trafic des plateformes de vidéo), peering, transit, 
 déploiement du GPON dans les zones moyennement denses, etc etc)
 En fait ce qui m'intéresse principalement c'est de savoir comment les 
 différents acteurs et la technologie se sont adaptés à l'évolution du web.
 Merci.

Je pense que les grosses plate-formes de vidéo ont déployé leurs propres 
réseaux, car les offres de
CDN sont quand même de grosses boites opaques assez chères, et il est possible 
de faire mieux et
moins cher en « interne » quand on atteint une certaine masse critique. Voir 
par exemple Google Caches,
Netflix OpenConnect, Dailymotion Caches, etc. … En ce qui concerne le routage 
du traffic, la méthode
évoquée par Damien (GSLB DNS / GeoDNS) s’avère beaucoup trop « simpliste » et 
ne permet pas de gérer
finement la popularité des contenus et l’affinité de caches : un « director » 
plus évolué (et généralement
basé sur des redirections HTTP), couplé à des remontées statistiques de 
saturation des liens et serveurs
est souvent plus pratique pour faire cela de manière fine.

Cordialement,
Pierre-Yves



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

Re: [FRnOG] [TECH] Content Delivery Network (CDN) à la francaise

[Pierre-Yves Kerembellec]

 Le 11 nov. 2014 à 20:09, Raphaël Jacquot sxp...@sxpert.org a écrit :
 
 On 11/11/2014 07:07 PM, neo futur wrote:
 a mon avis pour lancer un vrai cdn il faut au minimum avoir des
 serveurs sur 4 continents sinon ca donne le meme genre de difference
 qu il y a entre youtube et dailymotion ( dailymotion ca marche a peu
 pres bien en europe et c est tout, et ca ne sera jamais un succes
 mondial a cause de ca )
 
 Dailymotion a des serveurs en Europe, aux US et en Asie. Il y a aussi de
 la diffusion depuis plusieurs CDN.
 
 tout dépends de ta cible je dirais
 
 vu d ici ( au perou ) j ai tout simplement arrete d essayer de
 visionner des videos dailymotion
 
 Le Pérou, ça semble tout de suite assez représentatif du monde en dehors
 de l’Europe.
 
 pour ca faut voir avec pymaunier ;)

Le LATAM, c’est la misère au niveau connectivité et prix du transit. Du coup,
on galère bien (et pas qu’au Pérou), car en plus aucun gros CDN (Akamai, L3,
Edegcast, Limelight, …) n’est super bon là-bas non plus … :-(

Et sinon je confirme ce que dit Vincent, nous avons des serveurs un peu partout
(sauf SA et Afrique ! ^_^) , et nous utilisons en partie du multi-CDN suivant
les régions, en fonction de notre efficacité et de celle des-dits CDN en un 
point
donné du globe.

Cordialement,
Pierre-Yves



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

Re: [FRnOG] [TECH] Content Delivery Network (CDN) à la francaise

[Pierre-Yves Kerembellec]

 merci pour votre reponse, et content de voir que vous faites ce que
 vous pouvez, je sais effectivement que c est un peu la misere par ici,
 je revai de monter un petit datacenter au perou quand je suis venu ici
 il y a 6 ans et j ai un peu pris la peine de me renseigner . . .et oui
 c est la misere . . . et aussi un peu trop le monopole de telefonica.
 le perou aurait mechament besoin d un free.pe/online.pe local pour
 donner un coup de pied dans la fourmiliere . . .
 
 ici presque tout est 4 fois moins cher qu en europe, mais la
 telephonie et l internet sont au moins 2 fois plus chers qu en france
 . . . genre un adsl 2mb/s + telephone pas du tout illimite va couter a
 peu pres un quart du salaire minimum legal . . . ca fait peur
 
 mais, pour revenir au sujet initial, concurrencer google et les
 anglophones en gros, google reussit a le faire , les videos youtube
 sont generalement fluides, et avec un bon systeme de cache partout,
 meme dans mon player; dans le pire des cas quand ca rame un peu, je
 mets la pause dans mon firefox et je remets play apres 1 ou deux
 minutes et c est fluide, la video s est precharge pendant que je me
 servai un cafe.
 
 avec dailymotion, mettre la pause ne me sert a rien, la video ne se
 precharge meme pas, pour moi c est le point faible principal de
 dailymotion face a youtube

Si si, ça pré-charge bien en mode pause, c’est juste que l’indicateur de ce 
chargement
n’est pas affiché. Il suffit de lancer un petit coup de Charles (ou de regarder 
dans
les outils développeur du navigateur, onglet « réseau ») pour s’en convaincre : 
les
fragments continuent d’être téléchargés (et cachés en local) pendant la mise en 
pause.

 a mon avis pour lancer un vrai cdn il faut au minimum avoir des
 serveurs sur 4 continents sinon ca donne le meme genre de difference
 qu il y a entre youtube et dailymotion ( dailymotion ca marche a peu
 pres bien en europe et c est tout, et ca ne sera jamais un succes
 mondial a cause de ca )
 
 Dailymotion a des serveurs en Europe, aux US et en Asie. Il y a aussi de
 la diffusion depuis plusieurs CDN.
 
 tout dépends de ta cible je dirais
 
 vu d ici ( au perou ) j ai tout simplement arrete d essayer de
 visionner des videos dailymotion
 
 Le Pérou, ça semble tout de suite assez représentatif du monde en dehors
 de l’Europe.
 
 pour ca faut voir avec pymaunier ;)
 
 Le LATAM, c’est la misère au niveau connectivité et prix du transit. Du coup,
 on galère bien (et pas qu’au Pérou), car en plus aucun gros CDN (Akamai, L3,
 Edegcast, Limelight, …) n’est super bon là-bas non plus … :-(
 
 Et sinon je confirme ce que dit Vincent, nous avons des serveurs un peu 
 partout
 (sauf SA et Afrique ! ^_^) , et nous utilisons en partie du multi-CDN suivant
 les régions, en fonction de notre efficacité et de celle des-dits CDN en un 
 point
 donné du globe.

Cordialement,
Pierre-Yves



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

Re: [FRnOG] [MISC] Je suis Charlie

[Pierre-Yves Kerembellec]

 curl -I http://charliehebdo.fr
 
 HTTP/1.1 302 Found
 Server: nginx
 Date: Fri, 09 Jan 2015 14:33:20 GMT
 Content-Type: text/html; charset=iso-8859-1
 Content-Length: 221
 Connection: keep-alive
 Location: http://www.charliehebdo.fr/index.html
 Vary: Accept-Encoding
 X-Charlie-fr: Je suis toujours Charlie.
 X-Charlie-en: I am still Charlie.
 X-Charlie-es: Todavia soy Charlie.
 X-Charlie-de: Ich bin immer Charlie.
 X-Charlie-ro: Inca sunt Charlie.
 X-Charlie-cz: Jsem stale Charlie.
 
 histoire de recentrer la discussion

pyke@sd-28709:~$ traceroute www.dailymotion.com
traceroute to www.dailymotion.com (195.8.215.137), 30 hops max, 60 byte packets
 1  195-154-241-1.rev.poneytelecom.eu (195.154.241.1)  0.540 ms  0.542 ms  
0.539 ms
 2  a9k1-45-s103-1-dc2.dc3.poneytelecom.eu (195.154.1.122)  1.020 ms  1.375 ms  
1.454 ms
 3  dailymotion.franceix.net (37.49.236.96)  1.010 ms  1.005 ms  1.001 ms
 4  je.suis.charlie.dailymotion.com (195.8.214.211)  3.207 ms 2.568 ms  3.207 ms
 5  www.dailymotion.com (195.8.215.137)  0.923 ms

 semble pas être le bon endroit, d'autant plus qu'un débat va forcément
 dériver sur des questions religieuses ou politiques.

Cordialement,

--
Pierre-Yves Kerembellec | Head of Architecture
Dailymotion | 140 boulevard Malesherbes | 75017 Paris | France
Tel : +33 1 77 35 11 09 | Mobile : +33 6 08 91 46 15


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

Re: [FRnOG] [TECH] Hôte pointant vers 127.0.0.1

[Pierre-Yves Kerembellec]

Et Dieu inventa le devops qui savait utiliser Google et faire "brew install
unbound" ... et il vit que cela était bon ... ;-)

Pierre-Yves
Le 24 sept. 2015 4:26 PM, "Vincent Bernat"  a écrit :

>  ❦ 24 septembre 2015 15:13 +0200, David Ponzone  > :
>
> > Tu fais gérer le DNS auth de preprod.monsite.com par les devs, et
> > s’ils cassent tout, c’est pas grave.
> >
> > Oui c’est cracra, mais c’est rigolo.
>
> Dans pas mal de boîtes, les devs ne sont pas là uniquement comme
> défouloir des sysadmins mais aussi pour faire du dev. Des devs qui ne
> font plus de dev parce qu'on leur a délégué une partie de
> l'infrastructure parce que c'est rigolo, c'est des jour-hommes perdus
> sur les projets.
> --
> Replace repetitive expressions by calls to a common function.
> - The Elements of Programming Style (Kernighan & Plauger)
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Slides ExaBGP FRnOG 26

[Pierre-Yves Kerembellec]

> Salut Thomas,
> 
>> Thomas Mangin a écrit :
>> Pour ceux qui aiment vraiment se torturer l’esprit.
>> http://thomas.mangin.com/data/pdf/FRnOG%2026%20ExaBGP.pdf
> 
> Pour ceux qui n'aiment pas se torturer l'esprit, ne pas lire plus-bas :P
> 
> ExaBGP est l'injecteur du CBBC : http://arneill-py.sacramento.ca.us/cbbc/
> Ayant en vain attendu que tu viennes l'installer sur ma bécane, j'ai fini par 
> l'installer moi-même !
> C'est un peu la même idée que exabgp-edgerouter, en plus grand. Si tu n'as 
> jamais essayé, moi j'ai osé : ExaBGP qui injecte 60 K routes minimum et 
> jusqu'à 100 K routes. Ca marche aussi avec les communautés étendues (je me 
> sers d'ExaBGP pour injecter RT:4200065532:666, çà marche).
> 
> J'ai une question de débutant (on appelle çà Google-over-FRnOG) : ExaBGP lit 
> stdout; non j'ai pas lu la doc, il y aurait-il moyen que si ExaBGP voit 
> quelque chose qui commence par "#" il ne fait que l'afficher ? Quand on n'est 
> pas un dieu du .py, c'est pratique d'avoir la moulinette qui commente ce 
> qu'elle fait.
> 
> Merci d'avoir écrit ExaBGP. Je m'en sers. 

Idem chez Dailymotion, 1500+ servers en production entièrement provisionnés et 
redondés dans une architecture
CLOS grace à ExaBGP et un petit co-process en Python 
(https://github.com/pyke369/exabgp-helpers/blob/master/exasrv/exasrv.py)
qui gère à la fois les annonces des VIP (/32), la manipulation de la table de 
routage sortante pour faire de
l’ECMP sécurisé (bye-bye ip-rule), etc. … (donc un exemple de read-and-write 
co-process).

On a baptisé ça : BGPTTH (BGP-To-The-Host), en hommage à tous les xTTH de la 
transmission … ;-)

Merci pour le soft Thomas ! (et vivement la CLI locale pour une meilleure 
vision en cas de soucis, log.info()
c’est le niveau 0 du debug et ça a ses limites ^_^)

Cordialement,
Pierre-Yves



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

Re: [FRnOG] [TECH] Solution IPTV

[Pierre-Yves Kerembellec]

Bonjour,

> Je suis actuellement sur un projet IPTV et je souhaiterai savoir qu'elles
> solutions vous utilisez et quels sont vos retours sur ces différentes
> solutions.
> 
> J'ai eu l'occasion de tester le middleware Stalker avec les stb MAG, seul
> bémol le codec audio E-AC3 pour les chaine de la TNT HD n'est pas supporté.

Si tu maitrises la source de diffusion, un simple : dvbpipe ... | ffmpeg -re -i 
- -vcodec copy -acodec aac -ac 2 -b:a 128000 udp://...
fera l'affaire pour ces boitiers ...

Pierre-Yves


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

Re: [FRnOG] [MISC] Iliad / Scaleway - Pb de fibre

[Pierre-Yves Kerembellec]

Bonjour,

Sinon il y a toujours status.scaleway.com  avec 
toutes les informations en temps réel.
(scroller un peu vers le bas pour trouver le sujet "[DC2] Partial network 
outage")

> Bonjour,
> 
> De mon côté, j'ai reçu régulièrement des updates par SMS. J'avais renseigné
> les informations dans leur interface DC au préalable.
> 
> Bonne journée et bon courage,
> Fabien
> 
> Le sam. 9 févr. 2019 à 13:10, Nico  a écrit :
> 
>> Bonjour,
>> 
>> Iliad / scaleway a subit une coupure de fibre entre DC2 / DC3 hier.
>> 
>> Ils sont en cours de réparation : bon courage à eux.
>> 
>> Le routage est opérationnel et est revenu très rapidement (bravo) mais
>> concernant les liaisons d’interco de dc2 vers dc3… silence total.
>> 
>> A aucun moment, en tant que client, nous n’avons reçu d’information pour
>> signaler la panne.
>> 
>> Est-ce une pratique courante ? Peut-on considérer que Twitter est une
>> source
>> d’information à destination des clients fiable ?
>> 
>> Trouvez-vous normal de ne recevoir aucunes réponses aux mails ?
>> 
>> Merci  pour vos retour, cela va me permettre de me forger une opinion et /
>> ou de casser un sentiment négatif qui monte…
>> 
>> Nico


Bonne journée,
Pierre-Yves


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

Re: [FRnOG] [TECH] La chasse à la licorne 1U et en-dessous

[Pierre-Yves Kerembellec]

Lanner propose pas mal de chose dans ce domaine ... il y en a pour toutes les 
tailles
et toutes les bourses, utilisé et approuvé :

http://www.lannerinc.com/network-appliances/x86-rackmount-network-appliances/

> Le 23 nov. 2019 à 12:28, David Ponzone  a écrit :
> 
> Y a la licorne dual-PS, 4xSFP+, 2xGE, short-depth, à moins de 2000€ aussi.
> 
>> Le 23 nov. 2019 à 06:09, Michel Py  a 
>> écrit :
>> 
>> Désolé un peu en retard pour trolldi,
>> 
>> Tout le monde cherche la licorne pas cher qui fait tout et le café aussi.
>> 
>> A vraiment pas cher, je suis en train d'essayer çà :
>> https://www.untangle.com/shop/z4-appliance/
>> C'est trolldi, je parle d'acheter leur bécane pour mettre ma propre image 
>> dessus.
>> C'est un PC, 4 ports ethernet, Bios AMI, etc, pour 300 balles.
>> 
>> A part que pour le pare-feu de la belle-mère j'aime bien le produit, le 
>> hardware est pas crade pour 300 balles.
>> 
>> 
>> J'ai pas encore essayé de booter sur USB ou de remplacer l'image, mais c'est 
>> prometteur.
>> 
>> 
>> Un niveau au-dessus : qui c'est qui a un truc à 1000 balles avec double alim 
>> hot-swap ?
>> 1 slot PCIe çà serait pas pire non plus. C'est la chasse à la licorne.
>> 
>> Michel.


--
Pierre-Yves


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

Re: [FRnOG] [TECH] ANSSI Recommandations de sécurité relatives à TLS - v1.2

[Pierre-Yves Kerembellec]

> Le 29 mars 2020 à 18:59, Jean-Francois Billaud via frnog  a 
> écrit :
> 
> ANSSI Agence nationale de la sécurité des systèmes d'information
> Recommandations de sécurité relatives à TLS - Version 1.2 - 26/03/2020
> https://www.ssi.gouv.fr/guide/recommandations-de-securite-relatives-a-tls/
> Licence ouverte / Open Licence (Etalab v1) : 
> https://www.etalab.gouv.fr/licence-ouverte-open-licence
> 
> Pas de surprises dans ces recommandations.
> La version précédente 1.1 datait du 19/08/2016.
> 
> Les protocoles recommandés :
> TLS v1.2, TLS v1.3
> RSA ECDSA
> ECDHE secp256r1,secp384r1,secp521r1 (NIST), x25519, x448, 
> brainpoolP256r,brainpoolP384r, brainpoolP512r1
> DHE 2048 bits 3072 bits ou plus
> AES ChaCha20 Camellia ARIA
> GCM, CCM, CBC (sous condition)
> SHA256 SHA384
> Pas de compression
> ...
> 
> Suites recommandées en annexe A
> 
> Exemples d'application en annexe B
> - Application à la compilation de OpenSSL
> - Application à la configuration de modules applicatifs pour Apache [orienté 
> serveur public] et NGINX [client maîtrisé]
> 
> Pas de recommandation pour le mail (SMTP + StartTLS) ni DOH ni DOT
> 
> Pas de lien vers des outils de test.
> 
> Avis personnel pour tout ce qui suit :
> - brainpool Camellia ARIA inutiles si l'on ne maîtrise pas serveur et client 
> maison (ces protocoles ne sont pas implémentés
>  dans les navigateurs courants)
> - CCM est à réserver pour l'Internet des objets (pas implémenté dans les 
> navigateurs courants)
> - on peut privilégier x25519, x448 sur les courbes du NIST (question de 
> confiance)
> - x448 peut servir dans le cas de serveurs mandataires
> - dans le cas de SMTP + StartTLS, on observe qu'il y a toujours des acteurs 
> majeurs qui sont restés à TLS 1.0, il est
>  donc difficile de ne garder que TLS v1.2 et TLS v1.3
> 
> Pour HTTPS une configuration pourrait être :
> TLS v1.2, v1.3
> certificats ECDSA - RSA 4096 bits
> paramètres DH ffdhe4096.pem
> courbes X448:X25519:secp521r1:secp384r1:prime256v1
> suites
> TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256;
> (à adapter selon les goûts personnels)
> 
> Pour SMTP + StartTLS une configuration pourrait être :
> TLS v1, v1.1, v1.2, v1.3
> certificats ECDSA - RSA 4096 bits
> paramètres DH ffdhe4096.pem
> courbes X448:X25519:secp521r1:secp384r1:prime256v1
> suites
> TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256;
> (à adapter si pas besoin de TLS v1 et v1.1)
> 
> Les outils de test :
> Qualys SSL Server Test : https://www.ssllabs.com/ssltest/index.html
> Internet.nl : https://internet.nl/
> Hardenize.com : https://www.hardenize.com/
> STARTTLS Everywhere : https://starttls-everywhere.org/
> CryptCheck : https://tls.imirhil.fr/
> 
> Pour les enregistrements DANE TLSA (3 1 1 et 2 1 1 recomandés) :
> chaingen de Viktor Dukhovni : https://go6lab.si/DANE/chaingen
> hash-slinger : https://github.com/letoams/hash-slinger
> 
> JFB
> 
> PS Message sous licence CC0, règles de Croker applicables.

Un outil sympa : https://wiki.mozilla.org/Security/Server_Side_TLS 
, avec un générateur de 
configuration pour quelques
logiciels et languages : 
https://ssl-config.mozilla.org/#server=golang=1.13.6=intermediate=5.4
 


Le profil Intermediate est recommandé (TLS 1.2 & 1.3 uniquement, et uniquement 
des cypher-suites avec PFS) + envoi
d'un header HSTS pour HTTP(S). ARIA, Camellia, 3DES, & co sont désactivés.

sslscan2 est plus rapide et efficace que SSLLabs pour tester les serveurs une 
fois configurés : https://github.com/rbsec/sslscan 

(certes il n'affiche pas une "jolie note" à la fin ... ^_^)

--
Cordialement,
Pierre-Yves



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

Re: [FRnOG] [ALERT] Coupures câbles dans le sud de Paris

[Pierre-Yves Kerembellec]

> Hello,
> 
> je confirme.
> Nous sommes censés avoir 3 chemins différents dc2-pa4, dc2-cbv, dc2-th2,
> via Sipartech, actuellement tous HS.

Normal, le coup de pelleteuse s'est produit à Vitry (une des 2 adductions DC3 
est aussi complètement down).
Ca va souder du tube jusqu'à point d'heure ...

> Hello,
> 
> J'ai constaté pour info de nombreuses liaisons impactées par un
> fibercut vers 9h30 ce matin, chez plusieurs opérateurs différents.
> A mon avis ca va être la boucherie !
> Rien que chez Hivane, ca a coupé plein de liens différents:
> https://twitter.com/HivaneNetwork/status/125758117193813606
> 
> 
> Bon courage aux équipes qui cont réparer !

--
Pierre-Yves


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

Re: [FRnOG] [MISC] system de ticket pour support

[Pierre-Yves Kerembellec]

Salut Damien,

- si c'est plutôt orienté suivi de projets -> Jira
- si c'est plutôt orienté support -> Zendesk

Les 2 solutions proposent des versions SaaS avec un coût de base attractif pour 
des petits volumes.

> Hello,
> 
> Je suis, très intéressé par les retours qu'on peut avoir sur cette
> discussion, sommes aussi entrain d'envisager un nouvel outil.
> 
> Nous utilisons depuis des années un GLPI installé sur VM (
> https://glpi-project.org/fr/), pas grand chose à redire du système qui
> fonctionne plutôt bien, peu de reproches à faire.
> Et pourtant on ne l'utilise que via les Formulaires et la gestion "Tickets"
> intégrée, au final si on utilise 15% de l'outil complet .. C'est
> déjà beaucoup.
> Il y a vraiment des trucs sympa à faire, comme certains de nos prestas, en
> jouant notamment pour la gestion Support / SAV avec les Tickets / Projets /
> Changements (pour différencier par exemple Demandes Techs, Docs Techs, et
> Commandes de liens par exemple .. A juger selon les besoins de chacun).
> 
> On envisage notamment depuis peu un ERP NEXT (https://erpnext.com/), mais
> pour le moment pas encore de retours à faire, il n'est même pas encore au
> stade de tests 
> Si des gens s'en servent ici pour de la gestion commerciale et / ou du
> support technique, nous sommes preneurs !
> 
> *Clément ANNEHEIM*
> *Technicien Réseaux et Télécommunications*
> [image: CIRTEL]
> *CIRTEL*
> *31 rue de l'Europe - Bâtiment SIME*
> *68700 CERNAY - FRANCE*
> *Tel : 0389353560*
> *Email :* *c.anneh...@cirtel.net* 
> *www.cirtel.net* 
> 
> Société à responsabilité limitée (SARL) | Capital de 1 Euros | SIRET:
> 48946980900029 | NAF-APE: 6190Z | RCS/RM: Mulhouse B 489 469 809 | Num.
> TVA: FR62489469809
> Ce message électronique et tous les fichiers attachés qu'il contient sont
> confidentiels et destinés exclusivement à l'usage de la personne à laquelle
> ils sont adressés. Si vous avez reçu ce message par erreur, merci de le
> retourner à son émetteur. La publication, l'usage, la distribution,
> l'impression ou la copie non autorisée de ce message et des attachements
> qu'il contient sont strictement interdits.
> N'imprimez ce message que si vous en avez l'utilité
> 
> 
> 
> Le jeu. 4 juin 2020 à 17:17, Damien Wetzel  a écrit :
> 
>> Hello
>> Je cherche un système (simple) de ticket pour le support
>> pour interagir avec nos clients et eventuellement en meme temps
>> avec nos fournisseurs de solutions CDNs.
>> 
>> pour l'instant on utilise une mailing list ;)
>> 
>> auriez vous des recommendations à faire ?
>> 
>> merci d'avance

--
Pierre-Yves



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

Re: [FRnOG] [TECH] question sur les DNS publics et edns client subnet

[Pierre-Yves Kerembellec]

> Le 13 janv. 2022 à 14:35, Damien Wetzel  a écrit :
> 
> Stephane Bortzmeyer writes:
>> On Thu, Jan 13, 2022 at 12:22:47PM +0100,
>> Damien Wetzel  wrote 
>> a message of 23 lines which said:
>> 
>>> Mettent ils en dans la clé de cache l'adresse ip du client ?
>> 
>> C'est obligatoire, sinon ça ne marcherait pas. RFC 7871, section 7.3
>> ("Cache lookups are first done as usual for a DNS query, using the
>> query tuple of .  Then, the appropriate RRset MUST
>> be chosen based on the longest prefix matching.")
> Merci pour l'info, mais du coup ca doit etre extrement gourmand en memoire
> est ce pour cela que peu de resolveurs operateur le gèrent ?
>> 
>>> est ce que cette option obligatoire avec l'arrivée du DoH
>> 
>> Pardon ? Non, pas du tout, DoH n'a jamais imposé ECS.
> Si le resolveur au bout du DoH ne le gère pas alors les sites
> sous CDN diregeront de manière fantaisiste le enduser et il me faudra changer 
> de metier ;)

Dans le cas de DoH, le client qui se connecte directement au resolver ("over 
HTTPS"),
le resolver « voit » donc directement l’IP réelle du client et peut faire du 
geo si besoin.

--
Cordialement,
Pierre-Yves Kerembellec


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

Re: [FRnOG] [TECH] Projet client Anycast et Anycast HealthChecker

[Pierre-Yves Kerembellec]

> Eh bien non, de ce que l'équipe de geek a présenté, ils pensent arrêter
> d'annoncer un /32, pas un /24. comme je ne suis pas expert mais que
> j'avais un gros doute, je me suis permis de venir poser la question ici :)
> 
> En interne, il y a toute la quincaillerie qui permet de faire fonctionner
> ça mais sur une interconnexion privée etre deux DC en iBGP.
> 
> La démo : on a un service qui tourne sur le site 1 et sur le site 2. On
> stoppe le service sur le site 1, AnyCast-HealthChecker détecte que le
> service ne répond plus, il envoie à Bird une suppression d'annonce en /32
> (c'était indiqué comme ça sur un de leur schéma...) et Bird propage au
> coeur de routage, en iBGP, sur le site 1 et site 2 et par la magie du
> réseau le flux est rerouté vers le site 2 !
> 
> La démo est chouette mais leur but c'est de maintenant propager la modif
> sur  les peers BGP opérateurs qui filtreront tout /32.
> 
> Il semble que l'équipe qui propose ça n'a pas forcément saisie qu'on ne
> bascule pas un service "unitairement" en anycast dès qu'on passe en eBGP.
> 
> (j'espère être clair mais si je me trompe dans la forme ou dans le fond,
> vous me corrigerez ;) )
> 
> Ce que tu indiques sur la fiabilité du script est très pertinent, surtout
> sur les gardes fous à mettre en place, mais AMHA seulement dans le cas
> d'un reroutage d'un /24, pas d'un /32...
> 
>> -le script doit être archi-blindax quant aux citères qu?il utilise pour
>> décider que le service n?est pas bon
>> -le script ne doit PAS avoir le droit de rétablir l?annonce BGP s?il l?a
>> retirée 1 min avant (dampening, tout ça??). Je dirais même qu?il ne doit
>> plus avoir le droit de ré-annoncer avant 15 ou 30 min
>> -mais comme les devs sont des humains et qu?ils vont foirer, c?est sûr, je
>> pense que le service doit tourner dans un /24 dont l?annonce est anycast,
>> mais qu?il devrait y avoir un préfixe plus court (/22 ou /23 donc) qui est
>> annoncé en permanence par un site seulement peut-être, dans l?éventualité
>> certaine que le /24 soit dampené massivement un jour
>> 
> 
> Bon je pense que je vais aller les voir pour être sûr qu'ils ont tous les
> éléments... ou alors j'ai raté un truc.
> 
> Sinon je vais jeter un oeil sur ExaBGP ;)

Si tu veux le même type de fonctionnalités avec la toolbox ExaBGP (sans BIRD & 
co donc),
tu peux jeter un œil à :

https://github.com/pyke369/exabgp-helpers/tree/master/exasrv 


pyke


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

Re: [FRnOG] [TECH] Blocage Uptobox chez Orange (DNS)

[Pierre-Yves Kerembellec]

> On Mon, 15 May 2023 17:47:36 +0200
> Stephane Bortzmeyer  wrote:
> 
>> On Mon, May 15, 2023 at 07:20:09PM +0400,
>> Gwenaël Oberlinger  wrote 
>> a message of 28 lines which said:
>> 
>>> Uptobox.com uptobox.fr uptostream.com et uptostream.fr sont bloqués par
>>> les DNS Orange depuis ce matin.  
>> 
>> Le support Orange, toujours au top :
>> 
>> https://twitter.com/Starouille/status/1658133531535499272
> 
> Encore une ou deux actions brillantes de nos FAIs, et on va tous terminer
> avec des machines qui utiliseront 127.0.0.1 comme resolveur, et un
> bind/unboud/whatever-you-like en local sur les machines. 

Ce devrait être de base par défaut (ça l’est chez moi depuis des années en tout 
cas, et tant pis pour l’ "efficacité globale de cache").

> Et comme ca, le filtrage "pour notre securite et celle des petits enfants"
> tant voulu par notre president sera au top de l'efficacite...

—
Pierre-Yves


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