Re: [FRnOG] [MISC] Femtocell et cambriolage

[Jean-Yves Bisiaux]

Il aurait fallu reussir à importer un ISMI catcher :-)

https://www.alibaba.com/trade/search?fsb=y=product_en==IMSI+catcher

Jean-Yves

On Wed, Jan 2, 2019 at 12:51 PM Olivier Macchioni <
olivier.macchi...@gmail.com> wrote:

> Bonjour la liste, et bonne année 2019!
>
> Pour ma part, l'année 2018 a mal terminé - cambriolage à la maison le 31
> décembre, et évidemment on était pas chez nous. J'ai quelques vidéos du
> malfrat, mais ça risque de ne pas suffire pour l'identifier (merci Netatmo
> !).
>
> D'où ma question pour les pros de Femtocells de la liste - j'ai une Freebox
> Revolution avec Femtocell. La qualité du réseau public Free est mauvaise,
> donc nos téléphones se connectent dessus dès qu'on est à la maison.
>
> Dans l'hypothèse où le malfrat a également un téléphone Free, j'imagine que
> la même chose lui sera arrivée... peut-être aussi si il est chez un autre
> opérateur (soit Français, soit étranger avec accord de roaming ?).
>
> Est-ce que des logs de ces connections existent quelque part, avec par
> exemple l'ICCID, l'IMEI ou l'IMSI lié au visiteur?
>
> Si c'est le cas, j'imagine que je n'y ai pas accès, mais est-ce que la
> gendarmerie peut faire une demande à l'opérateur sur une Femtocell précise,
> voire sur un ensemble de Femtocells en comptant celles des voisins?
>
> Si ce genre de traçabilité est possible, et connaissant la portée limitée
> des femtocells, j'imagine que ça peut être un outil efficace dans ce genre
> de cas.
>
> Merci pour vos réponses éclairées,
>
> Olivier
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
Best regards / Cordialement
--
Jean-Yves Bisiaux

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

Re: [FRnOG] [TECH] Split DNS

[Jean-Yves Bisiaux]

Bonjour Roger,

Avec BIND j'utiliserais sortlist dans ton cas.
En plus c'est plus facile si tu decides de signer ta zone dans le future.

Jean-Yves


>
> > Le 31 mai 2017 à 21:27, Roger YERBANGA  a
> écrit :
> >
> > Bonjour à tous,
> > Sur une infra de DNS (bind9) hébergeant quelques centaines de domaines,
> j'ai un enregistrement particulier qui doit donner 2 réponses différentes
> en fonction de l'IP source de la requête.
> > Oui, ca se fait avec des views.En ce moment, je n'ai pas de vue sur les
> serveurs en question, et je ne souhaite pas dupliquer mes zones dans 2 vues
> différentes à cause d'un seul record dans une seule zone.Quelqu'un a-t-il
> une piste à me proposer ?
> > Merci d'avance.
> >  ! roger
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [ALERT] Réponse bizarre d'OpenDNS concernant calendar.google.com

[Jean-Yves Bisiaux]

Je confirme.
A la difference de 8.8.8.8 de temps en temps il renvoie:

calendar.google.com. 554449 IN CNAME www3.l.google.com.
www3.l.google.com. 143 IN A 74.125.195.139
www3.l.google.com. 143 IN A 74.125.195.138
www3.l.google.com. 143 IN A 74.125.195.101
www3.l.google.com. 143 IN A 74.125.195.113
www3.l.google.com. 143 IN A 74.125.195.102
www3.l.google.com. 143 IN A 74.125.195.100

Pb de geolocalisation chez Cisco.

Rien ne vaut mieux que de faire soit meme la recursion.





2017-04-21 11:51 GMT+02:00 David Ponzone :

> Depuis hier, OpenDNS semble résoudre calendar.google.com vers des IP qui
> ne marchent pas.
> Si quelqu’un peut confirmer ou si quelqu’un a plus d’infos…
>
> Merci
>
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] RE: Route Google DNS |

[Jean-Yves Bisiaux]

Oui meme constat. Le DNS en UDP est bricolé sur le réseau, pas en TCP.
Plein de paquets perdus certains jours.
Sur unbound on contourne le problème avec l'option tcp-upstream à Yes. Mais
comme tous les DNS ne répondant pas à TCP, il faut ensuite forwarder les
requetes vers une autre resolver ouvert acceptant le TCP, beurk!

Ca serait quand meme bien de pouvoir faire du DNS normal.

2016-12-15 14:00 GMT+01:00 Jonathan Leroy :

> Le 1 décembre 2016 à 01:02, Francois Romieu  a
> écrit :
> > J'ai observé le phénomène lundi dernier avec un résolveur dans le réseau
> > local. Seul le trafic DNS était affecté. Depuis il transite via un autre
> > opérateur el cheapo et le reste du trafic transite toujours via Orange.
> >
> > Ce qu'il me reste de capture réseau de lundi corroborerait une différence
> > de traitement entre l'UDP et le TCP.
>
> Je déterre ce thread.
>
> Chez moi j'utilise une connexion Livebox Fibre résidentielle, et
> depuis leur grosse panne de DNS, je suis sans arrêt déconnecté de mes
> connexions OpenVPN (UDP).
>
> Est-ce d'autres clients Orange ont constaté des problèmes de filtrage
> agressif d'UDP sur les ports autre que 53 ?
>
> Merci,
>
> --
> Jonathan Leroy.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Named/Bind question

[Jean-Yves Bisiaux]

2016-03-15 23:22 GMT+01:00 David Ponzone :

> Tu dois pouvoir arriver au même résultat avec la fonction dnsspoof de
> unbound:
>
>
>
Ce sont deux serveurs faisant autorité sur leurs domaines. Pas de
récursivité, donc pas de Unbound ici. Deux NSD (ou Knot) font l'affaire. Le
reste est une affaire de contenu, ca se script facilement.

--
jyb

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

Re: [FRnOG] [MISC] Porte dérobée dans le VPN Juniper/ScreenOS

[Jean-Yves Bisiaux]

Le 19 décembre 2015 à 03:56, Michel Py 
a écrit :

> qui écrivent le code avec les pieds et ne comprennent rien à ce qu'ils
> font.
>

Hummm, pas certain. Il y a quand meme pas mal de code pour faire une belle
porte comme celle-ci. Autoriser l'utilisateur, sélection du VPN,
breakout... c'est quand meme du bel ouvrage. Ma main à couper qu'elle a été
développée suivant une spécification fonctionnelle détaillée, un beau plan
de test et meme une campagne de validation bien compléte comme sait le
faire une grand fournisseur comme Juniper ou Volkswagen.

Du reste, ce qui m'étonne plus ce sont les techniques de management de ces
grosses boites pour garder des secrets aussi énormes aussi longtemps. C'est
trés ambitieux quand meme ... ca c'est de la sécurité !

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

Re: [FRnOG] Re: [ALERT] Problème sur la racine du DNS

[Jean-Yves Bisiaux]

Le 3 décembre 2015 à 19:18, Léo  a écrit :

> Dans le scénario que je mentionne, le but n'est pas d'avoir une
> amplification, mais simplement de pouvoir viser plus de serveurs
> racine différents à partir d'un unique point géographique, pour lequel
> l'anycast l'aurait toujours emmené sur les mêmes machines.
>

Si un resolveur avait été utilisé nous n'aurions pas observé une
concentration de l'attaque sur 4 des 13 root serveurs.

--
jyb

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

Re: [FRnOG] [JOBS] Candidature Admin sys

[Jean-Yves Bisiaux]

Tu te trompes. Un bon admin fait des fautes !
A la différence des RH Google, je pense qu'un tech qui ne fait pas de
fautes est un imposteur.

Ronan pour que tu gardes confiance, Marcel Proust était nul en
orthographe...

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

Re: [FRnOG] [JOBS] Candidature Admin sys

[Jean-Yves Bisiaux]

C'est vrai. Enfin ici Ronan écrit dans la ML, sur un CV c'est bien entendu
différent.

Le 23 septembre 2015 11:18, Barthélémy DELUY  a
écrit :
>
>
> Les deux points de vue se défendent: on peut faire des fautes au quotidien
> dans son métier, mais lorsqu'on postule pour un job, se faire relire est
> généralement recommandé par les recruteurs (même si nous sommes plus de
> techs sur la liste que de RH il me semble).
>
>

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

Re: [FRnOG] [ALERT] Problème chez level3 ? avec Free

[Jean-Yves Bisiaux]

Pour info: http://www.bgpmon.net/massive-route-leak-cause-internet-slowdown/

Best regards / Cordialement
--
Jean-Yves Bisiaux

Check out EfficientIP DNS Blast: Up to 17million DNS queries per second!
http://www.efficientip.com/dns-blast
Download IDC 2014 DNS Security survey at
http://www.efficientip.com/idc-dns-security-survey

Le 12 juin 2015 16:22, Thierry Del-Monte tdelmo...@integra.fr a écrit :

 Bonjour à tous,

 Nous rencontrons des problèmes entre level3 et Free, et certains clients
 nous remontent des problèmes d'accès depuis la plaque nord américaine
 utilisant Level3.
 Nous avons fait le nécessaire en interne (reroutage), et ouvert un
 incident chez level3.
 Mais avez-vous les mêmes symptômes ??


 Thierry



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

Re: [FRnOG] Re: [MISC] Vous savez mesurer « le trafic sur la bande passante d'Internet » ?

[Jean-Yves Bisiaux]

Le 3 juin 2015 15:35, Stephane Bortzmeyer bortzme...@nic.fr a écrit :

 Depuis quand faut-il faire de la DPI pour utiliser Netflow/IPfix ???


Peut-etre pour appliquer differentes taxes en fonction des contenus, les
dessins animés moins taxés que le porno?

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

Re: [FRnOG] [TECH] DNS Questions

[Jean-Yves Bisiaux]

Si tu mettais un point a la place du tiret ca marcherais peut-etre mieux :-)

laeuropea.com.mx

laeuropea-com.mx
--
jyb

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

Re: [FRnOG] [TECH] Une proposition de loi veut imposer l'IPv6 dans les appareils au 30 juin 2015

[Jean-Yves Bisiaux]

Le 28 juillet 2014 10:14, Ramanou S. BIAOU biaous2...@gmail.com a écrit :

 Mais si le débat est sur la table depuis de nombreuses années, l'IPv6 ne
 s'est pas encore imposé partout. « *En dépit d’appels pressants à accélérer
 la migration vers l’IPv6, force est de constater que la France n’est pas
 prête techniquement, aujourd’hui, à fonctionner avec cette norme* » notent
 ainsi les députés à l'origine de la proposition de loi.
 « Obligation de mise à la norme d’adressage IPv6 de tous les matériels »


Même si je trouve l'initiative fort intéressante, ce qui m' inquiète c'est
l'association du terme Obligation avec Norme pouvant résulter
d'une Certification.

Et là, je cauchemarde: bien entendu ces certifications obligatoires ne
pourront êtres délivrées (à titre onéreux) que par un nombre limité
d'organismes autorisés.


Best regards / Cordialement
--
Jean-Yves Bisiaux

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

Re: [FRnOG] [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification

[Jean-Yves Bisiaux]

Salut Stephane,

Oui c'est interessant, mais ces techniques de blocage de requetes DNS sont
tres discutables et pourraient devenir rapidement un outil extraordinaire
pour les hackers.
Par exemple une requete DNS bloquee facilite le cache poisoning. Ou encore
avoir la possibilite de bloquer l'adresse IP (spoofe) d'un serveur racine
ou du DNS d'un ISP est une tres belle opportunite pour mettre la pagaille.

De mon point de vue, la meilleure solution est de ne pas bloquer les
requetes DNS mais d'y repondre.

--
Jean-Yves Bisiaux


Le 30 mai 2014 13:42, Stephane Bortzmeyer bortzme...@nic.fr a écrit :

 Très bon travail de Dobbins :

 https://app.box.com/s/r7an1moswtc7ce58f8gg

 Notez surtout la fin, « que faire » et, encore mieux, le slide « que
 ne PAS faire », qui rassemble beaucoup de c...ies faites au nom de la
 lutte anti-DoS.


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

[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification

[Jean-Yves Bisiaux]

  Oui c'est interessant, mais ces techniques de blocage de requetes
  DNS sont tres discutables et pourraient devenir rapidement un outil
  extraordinaire pour les hackers.

 Bloquer le DNS ? L'article dit exactement le contraire « Do not
 indiscriminately block UDP/53 on your networks! »


Dire:

• Do not indiscriminately block UDP/53 on your networks!
• Do not block UDP/53 packets larger than 512 bytes!
• Do not block TCP/53 on your networks!

laisse a penser que certaines requetes DNS peuvent etre bloquees. Non ?

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

[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification

[Jean-Yves Bisiaux]

Je disais que les technique de blocage sont tres discutable, dans le sens
ou celles qui sont automatiques sont dangereuse car basées sur des
euristiques de statistiques tres/trop simples.

Le 30 mai 2014 15:26, Stephane Bortzmeyer bortzme...@nic.fr a écrit :

 On Fri, May 30, 2014 at 03:20:03PM +0200,
  Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net wrote
  a message of 15 lines which said:

  Il ne parle jamais de bloquer les requetes DNS au niveau reseau,
  juste de ne pas repondre (en tant que resolver) a tout le monde.

 Ce qui est une Bonne Pratique depuis longtemps
 http://www.bortzmeyer.org/5358.html (RFC vieux de six ans)



Ici tu parles de resolver ouvert, moi je te le refais avec un resolver
fermé.
Un faux serveur autoritaire (spoofed) flood un serveur recursif fermé, tu
limites la prise en compte de reponses en dropant des paquets sur ton
recursif.
Regarde la page 7 de ce slide:
http://www.ssi.gouv.fr/IMG/pdf/DNS-OARC-2013-Blocking_DNS_Messages_Is_Dangerous.pdf



  Le probleme etant quand le serveur repond n'importe quoi (X fois
  plus de data dans le reponse que dans la requete) a une addresse
  spoofe.

 Là, la solution est clairement la limitation de trafic (dont Dobbins
 ne parle pas) https://conf-ng.jres.org/2013/planning.html#article_37


Je suis d'accord avec toi, c'est avant tout un pb de spoofing, qu'on ne va
pas resoudre en bloquant les paquets.

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

[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification

[Jean-Yves Bisiaux]

Le 30 mai 2014 15:54, Stephane Bortzmeyer bortzme...@nic.fr a écrit :

 On Fri, May 30, 2014 at 03:46:40PM +0200,
  Jean-Yves Bisiaux j...@efficientip.com wrote
  a message of 44 lines which said:

  Dire:
 
  • Do not indiscriminately block UDP/53 on your networks!
  • Do not block UDP/53 packets larger than 512 bytes!
  • Do not block TCP/53 on your networks!
 
  laisse a penser que certaines requetes DNS peuvent etre bloquees. Non ?

 Ben, c'est pareil que pour IP. Je pense qu'on sera tous d'accord pour
 dire qu'il ne faut pas indiscriminately block IP on your networks,
 néanmoins nous allons tous bloquer des paquets de temps en temps, sur
 des critères comme l'adresse IP de destination, en cas de dDoS.


OK au cas par cas.
Donc tu ne laisse pas un système automatique le faire à ta place ?



 Donc, oui, si nos serveurs crachent un flot continu de réponses DNS
 énormes, nous allons bloquer (ou, plus exactement, limiter) le trafic
 des requêtes DNS venant de cette adresse (les guillemets à cause de
 l'usurpation d'adresse).


C'est bien pour ca que RRL renvoie toujours une reponse.
Mais la tu est dans l'optique de proteger la victime.

Les solutions de pure DDOS sont en périphérie du DNS et ne protège pas que
les victimes mais le DNS dans sa globalité. En pensant se protéger d'une
manière radicale contre un flooding (reflexion, DDOS, amplifiaction) on
finit par se mettre en danger avec des mécanismes de protection.

Agir autrement ne serait pas responsable
 puisque le réflecteur participe, même si ce n'est pas volontaire, à
 une attaque. (Notez qu'il s'agit d'une opinion personnelle, ce point
 ne figure *pas* dans l'exposé de Dobbins.)


Complétement d'accord.

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

[FRnOG] Re: [TECH] Excellent exposé sur les attaques dDoS réflexion/amplification

[Jean-Yves Bisiaux]

Le 30 mai 2014 16:30, Stephane Bortzmeyer bortzme...@nic.fr a écrit :

 On Fri, May 30, 2014 at 04:14:13PM +0200,
  Jean-Yves Bisiaux j...@efficientip.com wrote
  a message of 96 lines which said:

  Je disais que les technique de blocage sont tres discutable, dans le sens
  ou celles qui sont automatiques sont dangereuse car basées sur des
  euristiques de statistiques tres/trop simples.

 Je suggère d'essayer de mettre plus de rigueur dans la
 discussion. Radu-Adrian Feurdean a fait remarquer à juste titre qu'on
 parle ici dans une perspective d'opérateur réseau. Bloquer le DNS dans
 le réseau, non, et c'est ce que dit Dobbins. Mais qu'un serveur ne
 réponde pas, c'est tout à fait autre chose. Une machine a toujours le
 droit de ne pas répondre si ça la gonfle !

 Peut-être je comprendrai mieux si je savais de quoi on parle ?  De
 RRL ?


Pas de RRL qui répond lui, mais des équipements de detection de flooding et
de mitigation automatique anti-DDOS.



  Ici tu parles de resolver ouvert, moi je te le refais avec un
  resolver fermé.

 S'il est fermé, aucun problème. Et Dobbins ne cite *aucune*
 recommandation concernant ces résolveurs fermés. Il faut lire son
 exposé.


Ok, je vais bien le relire alors. :-)


  Un faux serveur autoritaire (spoofed) flood un serveur recursif
  fermé, tu limites la prise en compte de reponses en dropant des
  paquets sur ton recursif.

 Je ne comprends pas. Si quelqu'un émet une réponse à un récursif, en
 se faisant passer pour un serveur faisant autorité, la réponse ne sera
 pas acceptée par le récursif (mauvais Query ID, port source,
 etc). Aucun besoin de mesure spécifique.


Tu le sais, c'est une approche court terme.
Seul DNSSEC aujourd'hui ou d'autres mécanisme actifs garantissent la
protections.



  Regarde la page 7 de ce slide:
 
 http://www.ssi.gouv.fr/IMG/pdf/DNS-OARC-2013-Blocking_DNS_Messages_Is_Dangerous.pdf

 Je connais. Je ne suis pas d'accord. Et, de toute façon, ce n'est pas
 le cas que vous décrivez, il s'agit dans cet exposé d'un serveur
 faisant autorité, et décidant de ne pas répondre à tout (grâce à RRL).


Dans ce document on parle effectivement de l'exploitation d'un serveur
faisant l'autorite,  mais pour empoisonner un resolveur.
Le message general est qu'il ne faut pas bloquer les paquets.
Et encore une fois l'empoisonnement du cache n'est qu'un exemple.
Le declenchement automatique du bloquage d'une adresse spoofed (resolveur
d'un ISP ...) bien choisie serait tres efficace comme acte de malveillance.

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

Re: [FRnOG] Re: [ALERT] Soucis sur maps.google.fr en IPv6 depuis ce matin

[Jean-Yves Bisiaux]

Bonsoir,

Alors celle-ci elle est pas mal! Si j'ai bien compris, quand on utilise le
resolver de google on arrive plus à resoudre les domaines de google. Mais
aussi quelle drole d'idée d'utiliser le resolver de Google. :-D


Best regards / Cordialement
--
Jean-Yves Bisiaux


Le 1 mai 2014 22:22, Laurent GUERBY laur...@guerby.net a écrit :

 On Tue, 2014-04-29 at 10:12 +0200, Laurent GUERBY wrote:
  Bonjour,
 
  On observe depuis AS197422 des gros soucis de performances (ca rame)
  vers google maps AS15169 uniquement en IPv6 alors qu'en IPv4 ca marche
  nickel, depuis ce matin. Notre prod passe par l'interco
  France-IX=TouIX directement sur le routeur France-IX de google
  aller et retour, pas de soucis sur les autres destinations.
 
  D'apres nos tests via le NLNOG Ring on est pas les seuls a avoir le
  probleme, un script de test rapide contribué par Mehdi est ici :
 
  http://paste.debian.net/96333/
 
  Mail envoyé a n...@google.com mais pas de retour pour le moment.
 
  Sincèrement,
 
  Laurent

 Bonsoir,

 Le NOC de google a répondu dans la journée : le soucis ne se produisait
 que quand le serveur DNS interrogé etait 8.8.8.8, un ticket interne a
 été ouvert.

 Je viens de verifier a l'instant et le probleme de performance n'est
 plus reproductible de chez AS197422.

 De notre coté on a remplacé quelques 8.8.8.8 par un resolveur
 plus local au passage.

 Sincèrement,

 Laurent



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


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

Re: [FRnOG] [FRNOG][TECH] Outils de transferts de fichiers sur UDP

[Jean-Yves Bisiaux]

Essaye UDT il a un overhead plus faible que Tsunami:

http://udt.sourceforge.net/

Best regards / Cordialement
--
Jean-Yves Bisiaux


Le 18 avril 2014 21:53, Simon Perreault si...@per.reau.lt a écrit :

 BitTorrent?

 Le 2014-04-18 15:43, Erik LE VACON a écrit :
  Bonsoir à tous,
  Je vous contacte dans le cadre d'une recherche de solutions de
  transferts de données sur réseaux à latence importante.
 
  Les volumétries concernées sont de plusieurs téras de données par jour,
  en transcontinental (latence de 85 à 150ms en fonction des points nous
  concernant).
 
  La majorité des transferts se faisant traditionnellement en TCP (rsync,
  ftp, scp et autres), avec les problématiques connues générées par
  l'augmentation du RTT,  j'ai donc tenté des alternatives sur différentes
  solutions de transfert sur UDP, comme Tsunami-UDP, RBUDP et GridFTP, en
  gratuit , et Aspera en payant.
 
  Je suis passé y compris par de la tuyauterie maison from scratch à
  base de scripts NC, PIGZ et TAR, avec multi-threads  pour le transfert...
 
  Bref, dans tous les cas, le taquet n'est pas atteint, mais les taux de
  transferts sont intéressant, notamment sur Tsunami, mais n'atteignent
  que péniblement les 500-600mbps sur le gigabit dont nous disposons
  actuellement, malgré des raids 0 vides hors fichiers pour test, de
  chaque côté, étant capables de gérer les 100-110MBps attendus, et un
  circuit vide.
 
  Précisons que les tests ont été menés y compris directement en sortie
  des RAD de chaque côté en off-hours, pour détecter d'éventuels pbs de
  conf sur les appliances de sécu.
 
  Donc, la question: avez vous rencontré de telles problématiques, et si
  oui, quelles autres solutions, de type OpenSource ou à défaut peu
  couteuses, avez vous adopté pour faire face ? S'entend, solutions autres
  que les technologies de WAN-optim embarquées sur certaines baies
 récentes ?
 
  Merci de vos retours,
 
  Excellent weekend à tous,
 
 


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


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