Re: [TECH] [FRnOG] : retour d’expérience Cisco 2821

2012-12-22 Thread Xavier Beaudouin 
Hello,

Le 21 déc. 2012 à 19:48, Manuel Guesdon  a écrit :

> On Fri, 21 Dec 2012 17:07:45 +0100
> JC PAROLA  wrote:
>> | Le Fri, 21 Dec 2012 16:41:30 +0100,
>> | Simon Perreault  a écrit :
>> | 
>> | > J'ai récemment remplacé un 2821 qui bloquait à ~4000 pps. Je n'ai
>> | > jamais su exactement pourquoi. Il me semble que la config était très
>> | > ordinaire. Pas de Netflow, quelques ACLs simples. Peut-être IPv6?
>> | > 
>> | > On l'a remplacé par un PC ordinaire qui roule OpenBSD. Ce fut comme 
>> | > arriver soudainement au 21e siècle. ;)
>> | 
>> | C'est ce que je voulais faire au départ, je suis actuellement à 70
>> | mbs/s et ~7 000 pps. 
>> | 
>> | Je pense qu'OpenBSD pour faire du routage statique jusqu'à 400 mb/s et
>> | ~40,000 pps ne devrait pas impressionner un serveur bien dimensionné au
>> | niveau hardware.
> 
> Pour info, avec du bon matos on peut faire au minimum 150kpps avec BGP. Par
> contre bien choisir les cartes, le bus, etc... Le multi-processeur ne sert a
> rien par contre.

Si un peu quand même pour les calculs de routes. Bon c'est vrai ça sert à rien 
que prendre un 6 coeurs :)

Par contre en routage static, je te conseille plus un FreeBSD qu'un OpenBSD...

Si tu veux faire du BGP + OSPF, la OpenBSD est plus intégré que FreeBSD + 
OpenBGPd (OpenOSPF) ou Quagga (avec des bugs relous qui ne sont jamais intégrés 
malgrès mes patches)... surtout si tu prends des FreeBSD récents...

>> | est-il fou d'envisager de l'OpenBSD pour de la Prod (je rappelle 400
>> | mb/s sans BGP !! ) ?
> 
> Ca dépend.
> Avec du cisco/juniper&co: s'il y a un bug tu peux dire ben c'est
> un bug du constructeur on attend une release; voir tu peux faire intervenir le
> gars "qui te donnera des commandes à taper en CLI Shell qui tape directement
> l'Asic pour réparer ton bousin si jamais c'est un bug avéré." Y parait qu'on
> peut le joindre en moins de 45mn :-)
> 
> Avec de l'openbsd soit tu fixe toi même le pb si tu peux soit tu remontes le
> probleme sur la liste de discussion et tu attend qu'on guru fixe le truc (ou
> te dise que tu es un gros naze, que tu comprends rien et que de toute façon
> tous les constructeurs sont des menteurs).

+1 mais si tu expliques bien ce que tu fais tu peux avoir de bonnes surprises 
(surtout que Claudio écoutes bien quand tu tombes sur un truc picky), mais tu 
as quand même intérêt a bien savoir ce que tu dis, car contrairement aux 
constructeurs il y a pas un expert qui vas taper dans le noyau pour trouver la 
commande magique qui vas lui montrer que c'est pas toi qui ne sais pas faire, 
mais effectivement bien un bug.

Xavier

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

Re: [TECH] [FRnOG] : retour d’expérience Cisco 2821

2012-12-22 Thread Simon Perreault 

Le 2012-12-22 10:53, Xavier Beaudouin a écrit :

Par contre en routage static, je te conseille plus un FreeBSD qu'un
OpenBSD...


Pourquoi?


Si tu veux faire du BGP + OSPF, la OpenBSD est plus intégré que
FreeBSD + OpenBGPd (OpenOSPF) ou Quagga (avec des bugs relous qui ne
sont jamais intégrés malgrès mes patches)... surtout si tu prends des
FreeBSD récents...


Un autre avantage d'OpenBSD est que le pf dans FreeBSD est en retard 
d'environ 2 ans. Il y a plein de nouvelles features dans le pf d'OpenBSD.


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [TECH] [FRnOG] : retour d’expérience Cisco 2821

2012-12-22 Thread Thomas Barandon 
Le 22 décembre 2012 11:06, Simon Perreault  a
écrit :

> Un autre avantage d'OpenBSD est que le pf dans FreeBSD est en retard
> d'environ 2 ans. Il y a plein de nouvelles features dans le pf d'OpenBSD.


C'est pire que ça en fait.

La branche 8.x de FreeBSD contient une version datant de 2007 et la branche
9.x la version 4.5 de pf (sortie en 2009).
Néanmoins c'est un choix délibéré puisque la version 4.7 introduit un
changement de syntaxe lourd de conséquences.
Ca serait bête de casser son fw avec juste un upgrade (faudra bien que
FreeBSD passe le cap un jour de toute façon).

Par contre a part quelques bugs mineurs et des ajouts concernant le support
ivp6 je vois pas trop ou sont les "nouvelles features".

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

[FRnOG] [TECH] RFC 6821: Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality

2012-12-22 Thread Stephane Bortzmeyer 
Des rappels intéressants sur la sélection du pair en pair-à-pair :

http://www.bortzmeyer.org/6821.html



Auteur(s) du RFC: E. Marocco, A. Fusco (Telecom Italia), I. Rimac, V. Gurbani 
(Bell Labs, Alcatel-Lucent)




Le trafic du pair-à-pair peut, on le sait, représenter une bonne part 
de l'activité d'un réseau, malgré les efforts de l'industrie du 
divertissement pour diaboliser cette technique. Il y a donc depuis 
plusieurs années de gros efforts de recherche pour optimiser ce trafic, 
notammment via l'amélioration de la *sélection des pairs*. Si je veux 
télécharger la saison 1 de "Being human", et que trois pairs ont les 
données, auquel demander ? Le bon sens répond « au plus proche ». Mais 
le concept de « plus proche » est plus flou qu'il n'y parait, et, de 
toute façon, le logiciel pair-à-pair installé sur ma machine n'a pas 
forcément accès à toutes les informations nécessaires pour déterminer 
« le plus proche ». Il existe plusieurs solutions pour résoudre ce 
problème, mais notre RFC se penche plutôt sur le méta-problème : *la 
sélection des pairs améliore-t-elle les choses ?*

Tellement de choses ont été dites à ce sujet que l'ingénieur ou 
l'étudiant débutant qui se penche sur l'optimisation du pair-à-pair 
peut avoir une impression de grande confusion. Ce RFC choisit donc 
l'approche « retours aux faits ». Parmi toute la littérature 
scientifique et technique existante, peut-on trancher sur la question 
de l'intérêt de la sélection des pairs ?
 
Je préviens tout de suite que le titre de ce RFC, inutilement 
sensationnaliste, ne correspond pas à son contenu : le RFC ne dynamite 
pas de mythes, il examine un certain nombre de questions posées par la 
sélection des pairs et, pour chacune, en se basant sur des mesures ou 
des simulations déjà effectuées et publiées, fait une synthèse de leurs 
conclusions.

A priori, l'intérêt de la sélection est grand : comme les machines, 
dans un réseau pair-à-pair, ne connaissent pas la topologie 
sous-jacente (elles ne savent pas si les pairs sont proches ou 
lointains, s'ils sont joignables par des liens de "peering" gratuits ou 
par du transit payant, etc), elles risquent de ne pas choisir le 
meilleur pair. Une des conséquences fâcheuses sera l'utilisation 
d'inter-connexions lointaines, au lieu de rester dans le réseau du FAI. 
Il est donc logique que cette idée de sélection « intelligente » des 
pairs ait fait l'objet de nombreux travaux (résumés dans le RFC 6029 ; 
sinon, voir les articles « "Can ISPs and P2P systems co-operate for 
improved performance? 
" » d'Aggarwal, V., Feldmann, A., et C. Scheidler, ou 
« "Taming the Torrent: A practical approach to reducing cross-ISP 
traffic in P2P systems 
" » de Choffnes, D. et F. Bustamante, ou encore « "P4P: 
Explicit Communications for Cooperative Control Between P2P and Network 
Providers " » de Xie, 
H., Yang, Y., Krishnamurthy, A., Liu, Y., et A. Silberschatz) et qu'un 
groupe de travail de l'IETF, ALTO , 
travaille entièrement sur ce sujet (voir ses RFC 5693 et RFC 6708). (À 
noter que j'avais fait un exposé sur ces techniques en 2010 
.) L'évaluation de 
ces techniques n'est pas évidente, notamment de leur passage à 
l'échelle lorsque le réseau comprend des dizaines de millions de pairs.

Notre RFC suit le schéma suivant pour synthétiser la littérature 
existante :
* Décrire une croyance (un mythe, dit le RFC, terme très exagéré),
* Lister les faits (études, mesures, simulations, etc) disponibles,
* Discuter ces données,
* Conclure à la véracité ou à la fausseté de la croyance.
Naturellement, cette synthèse n'est valable qu'aujourd'hui : les 
progrès de la sciénce pourront changer les conclusions. Ah et, sinon, 
question terminologie, en l'absence d'une norme unique du pair-à-pair, 
ce RFC utilise largement le vocabulaire de BitTorrent (section 2), 
comme lee terme d'essaim pour désigner un groupe de pairs ayant les 
données convoitées.

Place maintenant aux croyances et à leur évaluation. La première : « la 
sélection des pairs permettra de diminuer le trafic entre domaines ». 
Les différents essais ou simulations montrent des réductions allant de 
20 à 80 % (la variation importante donne une idée de la difficulté à 
estimer cette réduction). 70 % pour la simulation de Xie, H., Yang, Y., 
Krishnamurthy, A., Liu, Y., et A. Silberschatz déjà citée. 34 % en 
sortie et 80 % en entrée pour les mesures du RFC 5632. Et jusqu'à 
99,5 % si le trafic est fortement localisé (beaucoup de pairs dans le 
même domaine) selon « "Pushing BitTorrent Locality to the Limit 
" » de Stevens Le Blond, Arnaud 
Legout et Walid Da

Re: [FRnOG] [MISC] USB/DB9 (femelle) Cable pour port console Cisco Bladecenter switch (3110G)

2012-12-22 Thread Julien Behem 
Bonjour à tous,

Au cas où certains seraient encore là dessus :
J'utilise un câble USB/miniUSB standard pour me connecter sur les derniers
Cisco en miniUSB (ex la gamme de Catalyst 2960S).
Une fois connecté, il faut utiliser ce driver fourni par Cisco et il sera
vu comme n'importe quel adaptateur USB/DB9.
http://software.cisco.com/download/release.html?mdfid=282867573&flowid=2574&softwareid=282855122&release=3.1&relind=AVAILABLE&rellifecycle=&reltype=latest

Julien


Le 28 novembre 2012 08:36, TROUSSE Fabrice  a
écrit :

> Bonjour,
>
> Nous en utilisons pour configurer nos Cisco 3012 dans les blade IBM.
> Le câble livré est de marque FOXCONN :
> Manufacturer Part number : CUBD010S-U29-DF
> Customer Part Number : 37-0932-01
>
> Si besoin,  j'en ai un de dispo sur Boulogne-Billancourt.
>
> Fabrice
>
>
>
> -Message d'origine-
> De : nico...@karp.fr [mailto:nico...@karp.fr] De la part de Nicolas KARP
> Envoyé : mardi 27 novembre 2012 21:46
> À : frnog-m...@frnog.org
> Objet : [FRnOG] [MISC] USB/DB9 (femelle) Cable pour port console Cisco
> Bladecenter switch (3110G)
>
> Bonjour la liste,
>
> Je suis à la recherche d'un cable USB/DB9 (femelle) pour me connecter sur
> un BladeCenter switch Cisco 3110G. Ils sont normalement fournis avec les
> switchs mais on les a tous jetés à l'époque :-(
>
> Ces switchs ne possèdent pas de port console RJ45 mais un port console USB.
>
> Quelqu'un aurait-il ça en stock et serait prêt à en vendre un pour me
> dépanner (je suis basé sur Paris) ?  J'en aurai besoin assez rapidement,
> d'où ma question sur la liste..
>
>
> Merci d'avance.
>
> Nicolas.
> +33 6 30 82 54 45
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement,

Julien BEHEM

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

Re: [FRnOG] [MISC] USB/DB9 (femelle) Cable pour port console Cisco Bladecenter switch (3110G)

2012-12-22 Thread Pascal Rullier 
Le 22 décembre 2012 18:00, Julien Behem  a écrit :
> Bonjour à tous,
>
> Au cas où certains seraient encore là dessus :
> J'utilise un câble USB/miniUSB standard pour me connecter sur les derniers
> Cisco en miniUSB (ex la gamme de Catalyst 2960S).
> Une fois connecté, il faut utiliser ce driver fourni par Cisco et il sera
> vu comme n'importe quel adaptateur USB/DB9.
> http://software.cisco.com/download/release.html?mdfid=282867573&flowid=2574&softwareid=282855122&release=3.1&relind=AVAILABLE&rellifecycle=&reltype=latest

et sous linux, c'est un serial style /dev/ttyUSB0 ???


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

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

2012-12-22 Thread Sylvain Vallerot 



On 21/12/2012 12:06, Thomas Mangin wrote:

Il y a 5  ans les courbes de trafic des FAI "eyeballs" avaient cette forme
de cloche, que l'on retrouve toujours chez les fournisseurs de transit.
Depuis, les lignes ont de plus en plus tendance a être utilise a' 100% 100%
du temps et le DPI est utilisé pour faire passer en priorité les protocoles
temps réels ou importants ( voip, email , ... ).
Le P2P  ( qui a dit Youtube !! ?? ) est ce qui passe normalement a la poubelle
le plus rapidement et rempli ce qui n'est pas utilisé par les autres protocoles.


Beaux exemples de ce qui se passe quand on abdique la neutralité du net,
des choix dictés par le marketing et par la déformation des usages :
- assimiler le mail à un protocole temps réel
- défavoriser le pair à pair
- favoriser les communications centralisées
- des tuyaux remplis à 100%

Carton plein : tout dans le mille.


Il semblerait que LEDBAT offre une solution intéressante et moins chère au
même problème de gestion de capacité ... mais avec moins de contrôle pour
le FAI.


s/FAI/commerciaux/

J'ai beaucoup de peine pour les grands bretons dont j'apprends ici qu'ils
sont déjà tous sous surveillance pour des raisons strictement commerciales.


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

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

2012-12-22 Thread Thomas Mangin 
STP ne me fais pas dire des choses que je n ai pas dites. Merci :)

Sent from my iPad

On 22 Dec 2012, at 21:25, Sylvain Vallerot  wrote:

> 
> 
> On 21/12/2012 12:06, Thomas Mangin wrote:
>> Il y a 5  ans les courbes de trafic des FAI "eyeballs" avaient cette forme
>> de cloche, que l'on retrouve toujours chez les fournisseurs de transit.
>> Depuis, les lignes ont de plus en plus tendance a être utilise a' 100% 100%
>> du temps et le DPI est utilisé pour faire passer en priorité les protocoles
>> temps réels ou importants ( voip, email , ... ).
>> Le P2P  ( qui a dit Youtube !! ?? ) est ce qui passe normalement a la 
>> poubelle
>> le plus rapidement et rempli ce qui n'est pas utilisé par les autres 
>> protocoles.
> 
> Beaux exemples de ce qui se passe quand on abdique la neutralité du net,

ici

> des choix dictés par le marketing et par la déformation des usages :
> - assimiler le mail à un protocole temps réel

ici

> - défavoriser le pair à pair
> - favoriser les communications centralisées

ici

> - des tuyaux remplis à 100%
> 
> Carton plein : tout dans le mille.
> 
>> Il semblerait que LEDBAT offre une solution intéressante et moins chère au
>> même problème de gestion de capacité ... mais avec moins de contrôle pour
>> le FAI.
> 
> s/FAI/commerciaux/
> 
> J'ai beaucoup de peine pour les grands bretons dont j'apprends ici qu'ils
> sont déjà tous sous surveillance pour des raisons strictement commerciales.

et la

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


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

RE: [FRnOG] [FRNOG] [TECH] Solution Wifi moyenne échelle

2012-12-22 Thread Thomas Basset 
*jingle applaudissements*


> -Original Message-
> From: frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] On Behalf
> Of Sylvain Vallerot
> Sent: lundi 17 décembre 2012 11:59
> To: frnog@frnog.org
> Subject: Re: [FRnOG] [FRNOG] [TECH] Solution Wifi moyenne échelle
> 
> 
> 
> On 17/12/2012 10:20, Frédéric wrote:
> > Le 2012-12-17 10:16, Bruno CAVROS / SKIWEBCENTER a écrit :
> >> 
> >>
> >> Il suffit de réfléchir un peu... le Campus de triffouilli les oies
> >> avec 2 salles ou campus de cambridge n'ont je pense pas la même
> >> superficie ni le même nombre d'utilisateurs..
> >>
> >> Dans le doute.. laissez faire des pros du réseau..
> >
> > Vachement constructif ta remarque...
> 
> Ben si c'est constructif. Et vu les questions étranges qui sont
> soumises ici depuis quelques semaines (répondre à l'étude de l'un,
> chiffrer le datacenter de l'autre, quantifier l'infra wifi du 3è)
> je comprends bien la réaction de Bruno.
> 
> Non pas que ces questions n'aient pas d'intérêt; mais ce sont des
> dossiers qui se constituent au moyen de longues recherches, études,
> démarches auprès des fournisseurs, prestataires, de négociations,
> business plan, étude de marché, et réactualisations incessantes,
> en fonction du lieu, du besoin, du ciblage, de l'implantation,
> des moyens de financement, de la stratégie.
> 
> Ce sont des dossiers complexes, qui prennent du temps et coûtent de
> l'argent à monter, il y a de quoi écrire un bouquin à chaque fois.
> Alors quelle espèce de recette miracle peut-on fournir qui soit plus
> pertinente que le dernier "perdre votre ventre en 2 semaines" ou
> "devenir riche sans sortir de chez soi" ?
> 
> Bonjour, je voudrais monter un FAI, pouvez-vous me proposer un
> business plan et m'apprendre le métier ?
> 
> Je ne suis pas loin de penser (comme Bruno ?) que quand on a besoin
> de monter un réseau sur un campus de la taille d'une petite ville et
> qu'on pose des question comme celle-là sur FRnog, il y a un décalage
> manifeste et la véritable question qu'il faut se poser est peut-être
> «ai-je la capacité de gérer un tel projet» ?
> 
> Et ça n'est pas une insulte : ce genre de questions il faut mieux se
> les poser avant que de se lancer dans un chantier au milieu duquel si
> on n'a pas les connaissances techniques et de gestion nécessaires, on
> on se retrouvera submergé par les imprévus, rattrapé par les deadlines
> et à court de cash forcé de déposer le bilan.
> 
> Il vaut mieux prévenir que guérir, et prévenir c'est souvent perçu
> comme négatif, mais en réalité c'est s'assurer que les bases sont
> saines pour pouvoir correctement construire.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

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

Re: [TECH] [FRnOG] : retour d’expérience Cisco 2821

2012-12-22 Thread Xavier Beaudouin 
Hello,

Le 21 déc. 2012 à 19:48, Manuel Guesdon  a écrit :

> On Fri, 21 Dec 2012 17:07:45 +0100
> JC PAROLA  wrote:
>> | Le Fri, 21 Dec 2012 16:41:30 +0100,
>> | Simon Perreault  a écrit :
>> | 
>> | > J'ai récemment remplacé un 2821 qui bloquait à ~4000 pps. Je n'ai
>> | > jamais su exactement pourquoi. Il me semble que la config était très
>> | > ordinaire. Pas de Netflow, quelques ACLs simples. Peut-être IPv6?
>> | > 
>> | > On l'a remplacé par un PC ordinaire qui roule OpenBSD. Ce fut comme 
>> | > arriver soudainement au 21e siècle. ;)
>> | 
>> | C'est ce que je voulais faire au départ, je suis actuellement à 70
>> | mbs/s et ~7 000 pps. 
>> | 
>> | Je pense qu'OpenBSD pour faire du routage statique jusqu'à 400 mb/s et
>> | ~40,000 pps ne devrait pas impressionner un serveur bien dimensionné au
>> | niveau hardware.
> 
> Pour info, avec du bon matos on peut faire au minimum 150kpps avec BGP. Par
> contre bien choisir les cartes, le bus, etc... Le multi-processeur ne sert a
> rien par contre.

Si un peu quand même pour les calculs de routes. Bon c'est vrai ça sert à rien 
que prendre un 6 coeurs :)

Par contre en routage static, je te conseille plus un FreeBSD qu'un OpenBSD...

Si tu veux faire du BGP + OSPF, la OpenBSD est plus intégré que FreeBSD + 
OpenBGPd (OpenOSPF) ou Quagga (avec des bugs relous qui ne sont jamais intégrés 
malgrès mes patches)... surtout si tu prends des FreeBSD récents...

>> | est-il fou d'envisager de l'OpenBSD pour de la Prod (je rappelle 400
>> | mb/s sans BGP !! ) ?
> 
> Ca dépend.
> Avec du cisco/juniper&co: s'il y a un bug tu peux dire ben c'est
> un bug du constructeur on attend une release; voir tu peux faire intervenir le
> gars "qui te donnera des commandes à taper en CLI Shell qui tape directement
> l'Asic pour réparer ton bousin si jamais c'est un bug avéré." Y parait qu'on
> peut le joindre en moins de 45mn :-)
> 
> Avec de l'openbsd soit tu fixe toi même le pb si tu peux soit tu remontes le
> probleme sur la liste de discussion et tu attend qu'on guru fixe le truc (ou
> te dise que tu es un gros naze, que tu comprends rien et que de toute façon
> tous les constructeurs sont des menteurs).

+1 mais si tu expliques bien ce que tu fais tu peux avoir de bonnes surprises 
(surtout que Claudio écoutes bien quand tu tombes sur un truc picky), mais tu 
as quand même intérêt a bien savoir ce que tu dis, car contrairement aux 
constructeurs il y a pas un expert qui vas taper dans le noyau pour trouver la 
commande magique qui vas lui montrer que c'est pas toi qui ne sais pas faire, 
mais effectivement bien un bug.

Xavier

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

Re: [TECH] [FRnOG] : retour d’expérience Cisco 2821

2012-12-22 Thread Simon Perreault 

Le 2012-12-22 10:53, Xavier Beaudouin a écrit :

Par contre en routage static, je te conseille plus un FreeBSD qu'un
OpenBSD...


Pourquoi?


Si tu veux faire du BGP + OSPF, la OpenBSD est plus intégré que
FreeBSD + OpenBGPd (OpenOSPF) ou Quagga (avec des bugs relous qui ne
sont jamais intégrés malgrès mes patches)... surtout si tu prends des
FreeBSD récents...


Un autre avantage d'OpenBSD est que le pf dans FreeBSD est en retard 
d'environ 2 ans. Il y a plein de nouvelles features dans le pf d'OpenBSD.


Simon
--
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source--> http://ecdysis.viagenie.ca
STUN/TURN server   --> http://numb.viagenie.ca


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

Re: [TECH] [FRnOG] : retour d’expérience Cisco 2821

2012-12-22 Thread Thomas Barandon 
Le 22 décembre 2012 11:06, Simon Perreault  a
écrit :

> Un autre avantage d'OpenBSD est que le pf dans FreeBSD est en retard
> d'environ 2 ans. Il y a plein de nouvelles features dans le pf d'OpenBSD.


C'est pire que ça en fait.

La branche 8.x de FreeBSD contient une version datant de 2007 et la branche
9.x la version 4.5 de pf (sortie en 2009).
Néanmoins c'est un choix délibéré puisque la version 4.7 introduit un
changement de syntaxe lourd de conséquences.
Ca serait bête de casser son fw avec juste un upgrade (faudra bien que
FreeBSD passe le cap un jour de toute façon).

Par contre a part quelques bugs mineurs et des ajouts concernant le support
ivp6 je vois pas trop ou sont les "nouvelles features".

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

[FRnOG] [TECH] RFC 6821: Improving Peer Selection in Peer-to-peer Applications: Myths vs. Reality

2012-12-22 Thread Stephane Bortzmeyer 
Des rappels intéressants sur la sélection du pair en pair-à-pair :

http://www.bortzmeyer.org/6821.html



Auteur(s) du RFC: E. Marocco, A. Fusco (Telecom Italia), I. Rimac, V. Gurbani 
(Bell Labs, Alcatel-Lucent)




Le trafic du pair-à-pair peut, on le sait, représenter une bonne part 
de l'activité d'un réseau, malgré les efforts de l'industrie du 
divertissement pour diaboliser cette technique. Il y a donc depuis 
plusieurs années de gros efforts de recherche pour optimiser ce trafic, 
notammment via l'amélioration de la *sélection des pairs*. Si je veux 
télécharger la saison 1 de "Being human", et que trois pairs ont les 
données, auquel demander ? Le bon sens répond « au plus proche ». Mais 
le concept de « plus proche » est plus flou qu'il n'y parait, et, de 
toute façon, le logiciel pair-à-pair installé sur ma machine n'a pas 
forcément accès à toutes les informations nécessaires pour déterminer 
« le plus proche ». Il existe plusieurs solutions pour résoudre ce 
problème, mais notre RFC se penche plutôt sur le méta-problème : *la 
sélection des pairs améliore-t-elle les choses ?*

Tellement de choses ont été dites à ce sujet que l'ingénieur ou 
l'étudiant débutant qui se penche sur l'optimisation du pair-à-pair 
peut avoir une impression de grande confusion. Ce RFC choisit donc 
l'approche « retours aux faits ». Parmi toute la littérature 
scientifique et technique existante, peut-on trancher sur la question 
de l'intérêt de la sélection des pairs ?
 
Je préviens tout de suite que le titre de ce RFC, inutilement 
sensationnaliste, ne correspond pas à son contenu : le RFC ne dynamite 
pas de mythes, il examine un certain nombre de questions posées par la 
sélection des pairs et, pour chacune, en se basant sur des mesures ou 
des simulations déjà effectuées et publiées, fait une synthèse de leurs 
conclusions.

A priori, l'intérêt de la sélection est grand : comme les machines, 
dans un réseau pair-à-pair, ne connaissent pas la topologie 
sous-jacente (elles ne savent pas si les pairs sont proches ou 
lointains, s'ils sont joignables par des liens de "peering" gratuits ou 
par du transit payant, etc), elles risquent de ne pas choisir le 
meilleur pair. Une des conséquences fâcheuses sera l'utilisation 
d'inter-connexions lointaines, au lieu de rester dans le réseau du FAI. 
Il est donc logique que cette idée de sélection « intelligente » des 
pairs ait fait l'objet de nombreux travaux (résumés dans le RFC 6029 ; 
sinon, voir les articles « "Can ISPs and P2P systems co-operate for 
improved performance? 
" » d'Aggarwal, V., Feldmann, A., et C. Scheidler, ou 
« "Taming the Torrent: A practical approach to reducing cross-ISP 
traffic in P2P systems 
" » de Choffnes, D. et F. Bustamante, ou encore « "P4P: 
Explicit Communications for Cooperative Control Between P2P and Network 
Providers " » de Xie, 
H., Yang, Y., Krishnamurthy, A., Liu, Y., et A. Silberschatz) et qu'un 
groupe de travail de l'IETF, ALTO , 
travaille entièrement sur ce sujet (voir ses RFC 5693 et RFC 6708). (À 
noter que j'avais fait un exposé sur ces techniques en 2010 
.) L'évaluation de 
ces techniques n'est pas évidente, notamment de leur passage à 
l'échelle lorsque le réseau comprend des dizaines de millions de pairs.

Notre RFC suit le schéma suivant pour synthétiser la littérature 
existante :
* Décrire une croyance (un mythe, dit le RFC, terme très exagéré),
* Lister les faits (études, mesures, simulations, etc) disponibles,
* Discuter ces données,
* Conclure à la véracité ou à la fausseté de la croyance.
Naturellement, cette synthèse n'est valable qu'aujourd'hui : les 
progrès de la sciénce pourront changer les conclusions. Ah et, sinon, 
question terminologie, en l'absence d'une norme unique du pair-à-pair, 
ce RFC utilise largement le vocabulaire de BitTorrent (section 2), 
comme lee terme d'essaim pour désigner un groupe de pairs ayant les 
données convoitées.

Place maintenant aux croyances et à leur évaluation. La première : « la 
sélection des pairs permettra de diminuer le trafic entre domaines ». 
Les différents essais ou simulations montrent des réductions allant de 
20 à 80 % (la variation importante donne une idée de la difficulté à 
estimer cette réduction). 70 % pour la simulation de Xie, H., Yang, Y., 
Krishnamurthy, A., Liu, Y., et A. Silberschatz déjà citée. 34 % en 
sortie et 80 % en entrée pour les mesures du RFC 5632. Et jusqu'à 
99,5 % si le trafic est fortement localisé (beaucoup de pairs dans le 
même domaine) selon « "Pushing BitTorrent Locality to the Limit 
" » de Stevens Le Blond, Arnaud 
Legout et Walid Da

Re: [FRnOG] [MISC] USB/DB9 (femelle) Cable pour port console Cisco Bladecenter switch (3110G)

2012-12-22 Thread Julien Behem 
Bonjour à tous,

Au cas où certains seraient encore là dessus :
J'utilise un câble USB/miniUSB standard pour me connecter sur les derniers
Cisco en miniUSB (ex la gamme de Catalyst 2960S).
Une fois connecté, il faut utiliser ce driver fourni par Cisco et il sera
vu comme n'importe quel adaptateur USB/DB9.
http://software.cisco.com/download/release.html?mdfid=282867573&flowid=2574&softwareid=282855122&release=3.1&relind=AVAILABLE&rellifecycle=&reltype=latest

Julien


Le 28 novembre 2012 08:36, TROUSSE Fabrice  a
écrit :

> Bonjour,
>
> Nous en utilisons pour configurer nos Cisco 3012 dans les blade IBM.
> Le câble livré est de marque FOXCONN :
> Manufacturer Part number : CUBD010S-U29-DF
> Customer Part Number : 37-0932-01
>
> Si besoin,  j'en ai un de dispo sur Boulogne-Billancourt.
>
> Fabrice
>
>
>
> -Message d'origine-
> De : nico...@karp.fr [mailto:nico...@karp.fr] De la part de Nicolas KARP
> Envoyé : mardi 27 novembre 2012 21:46
> À : frnog-m...@frnog.org
> Objet : [FRnOG] [MISC] USB/DB9 (femelle) Cable pour port console Cisco
> Bladecenter switch (3110G)
>
> Bonjour la liste,
>
> Je suis à la recherche d'un cable USB/DB9 (femelle) pour me connecter sur
> un BladeCenter switch Cisco 3110G. Ils sont normalement fournis avec les
> switchs mais on les a tous jetés à l'époque :-(
>
> Ces switchs ne possèdent pas de port console RJ45 mais un port console USB.
>
> Quelqu'un aurait-il ça en stock et serait prêt à en vendre un pour me
> dépanner (je suis basé sur Paris) ?  J'en aurai besoin assez rapidement,
> d'où ma question sur la liste..
>
>
> Merci d'avance.
>
> Nicolas.
> +33 6 30 82 54 45
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement,

Julien BEHEM

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

Re: [FRnOG] [MISC] USB/DB9 (femelle) Cable pour port console Cisco Bladecenter switch (3110G)

2012-12-22 Thread Pascal Rullier 
Le 22 décembre 2012 18:00, Julien Behem  a écrit :
> Bonjour à tous,
>
> Au cas où certains seraient encore là dessus :
> J'utilise un câble USB/miniUSB standard pour me connecter sur les derniers
> Cisco en miniUSB (ex la gamme de Catalyst 2960S).
> Une fois connecté, il faut utiliser ce driver fourni par Cisco et il sera
> vu comme n'importe quel adaptateur USB/DB9.
> http://software.cisco.com/download/release.html?mdfid=282867573&flowid=2574&softwareid=282855122&release=3.1&relind=AVAILABLE&rellifecycle=&reltype=latest

et sous linux, c'est un serial style /dev/ttyUSB0 ???


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

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

2012-12-22 Thread Sylvain Vallerot 



On 21/12/2012 12:06, Thomas Mangin wrote:

Il y a 5  ans les courbes de trafic des FAI "eyeballs" avaient cette forme
de cloche, que l'on retrouve toujours chez les fournisseurs de transit.
Depuis, les lignes ont de plus en plus tendance a être utilise a' 100% 100%
du temps et le DPI est utilisé pour faire passer en priorité les protocoles
temps réels ou importants ( voip, email , ... ).
Le P2P  ( qui a dit Youtube !! ?? ) est ce qui passe normalement a la poubelle
le plus rapidement et rempli ce qui n'est pas utilisé par les autres protocoles.


Beaux exemples de ce qui se passe quand on abdique la neutralité du net,
des choix dictés par le marketing et par la déformation des usages :
- assimiler le mail à un protocole temps réel
- défavoriser le pair à pair
- favoriser les communications centralisées
- des tuyaux remplis à 100%

Carton plein : tout dans le mille.


Il semblerait que LEDBAT offre une solution intéressante et moins chère au
même problème de gestion de capacité ... mais avec moins de contrôle pour
le FAI.


s/FAI/commerciaux/

J'ai beaucoup de peine pour les grands bretons dont j'apprends ici qu'ils
sont déjà tous sous surveillance pour des raisons strictement commerciales.


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

Re: [FRnOG] [TECH] RFC 6817: Low Extra Delay Background Transport (LEDBAT)

2012-12-22 Thread Thomas Mangin 
STP ne me fais pas dire des choses que je n ai pas dites. Merci :)

Sent from my iPad

On 22 Dec 2012, at 21:25, Sylvain Vallerot  wrote:

> 
> 
> On 21/12/2012 12:06, Thomas Mangin wrote:
>> Il y a 5  ans les courbes de trafic des FAI "eyeballs" avaient cette forme
>> de cloche, que l'on retrouve toujours chez les fournisseurs de transit.
>> Depuis, les lignes ont de plus en plus tendance a être utilise a' 100% 100%
>> du temps et le DPI est utilisé pour faire passer en priorité les protocoles
>> temps réels ou importants ( voip, email , ... ).
>> Le P2P  ( qui a dit Youtube !! ?? ) est ce qui passe normalement a la 
>> poubelle
>> le plus rapidement et rempli ce qui n'est pas utilisé par les autres 
>> protocoles.
> 
> Beaux exemples de ce qui se passe quand on abdique la neutralité du net,

ici

> des choix dictés par le marketing et par la déformation des usages :
> - assimiler le mail à un protocole temps réel

ici

> - défavoriser le pair à pair
> - favoriser les communications centralisées

ici

> - des tuyaux remplis à 100%
> 
> Carton plein : tout dans le mille.
> 
>> Il semblerait que LEDBAT offre une solution intéressante et moins chère au
>> même problème de gestion de capacité ... mais avec moins de contrôle pour
>> le FAI.
> 
> s/FAI/commerciaux/
> 
> J'ai beaucoup de peine pour les grands bretons dont j'apprends ici qu'ils
> sont déjà tous sous surveillance pour des raisons strictement commerciales.

et la

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


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

RE: [FRnOG] [FRNOG] [TECH] Solution Wifi moyenne échelle

2012-12-22 Thread Thomas Basset 
*jingle applaudissements*


> -Original Message-
> From: frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] On Behalf
> Of Sylvain Vallerot
> Sent: lundi 17 décembre 2012 11:59
> To: frnog@frnog.org
> Subject: Re: [FRnOG] [FRNOG] [TECH] Solution Wifi moyenne échelle
> 
> 
> 
> On 17/12/2012 10:20, Frédéric wrote:
> > Le 2012-12-17 10:16, Bruno CAVROS / SKIWEBCENTER a écrit :
> >> 
> >>
> >> Il suffit de réfléchir un peu... le Campus de triffouilli les oies
> >> avec 2 salles ou campus de cambridge n'ont je pense pas la même
> >> superficie ni le même nombre d'utilisateurs..
> >>
> >> Dans le doute.. laissez faire des pros du réseau..
> >
> > Vachement constructif ta remarque...
> 
> Ben si c'est constructif. Et vu les questions étranges qui sont
> soumises ici depuis quelques semaines (répondre à l'étude de l'un,
> chiffrer le datacenter de l'autre, quantifier l'infra wifi du 3è)
> je comprends bien la réaction de Bruno.
> 
> Non pas que ces questions n'aient pas d'intérêt; mais ce sont des
> dossiers qui se constituent au moyen de longues recherches, études,
> démarches auprès des fournisseurs, prestataires, de négociations,
> business plan, étude de marché, et réactualisations incessantes,
> en fonction du lieu, du besoin, du ciblage, de l'implantation,
> des moyens de financement, de la stratégie.
> 
> Ce sont des dossiers complexes, qui prennent du temps et coûtent de
> l'argent à monter, il y a de quoi écrire un bouquin à chaque fois.
> Alors quelle espèce de recette miracle peut-on fournir qui soit plus
> pertinente que le dernier "perdre votre ventre en 2 semaines" ou
> "devenir riche sans sortir de chez soi" ?
> 
> Bonjour, je voudrais monter un FAI, pouvez-vous me proposer un
> business plan et m'apprendre le métier ?
> 
> Je ne suis pas loin de penser (comme Bruno ?) que quand on a besoin
> de monter un réseau sur un campus de la taille d'une petite ville et
> qu'on pose des question comme celle-là sur FRnog, il y a un décalage
> manifeste et la véritable question qu'il faut se poser est peut-être
> «ai-je la capacité de gérer un tel projet» ?
> 
> Et ça n'est pas une insulte : ce genre de questions il faut mieux se
> les poser avant que de se lancer dans un chantier au milieu duquel si
> on n'a pas les connaissances techniques et de gestion nécessaires, on
> on se retrouvera submergé par les imprévus, rattrapé par les deadlines
> et à court de cash forcé de déposer le bilan.
> 
> Il vaut mieux prévenir que guérir, et prévenir c'est souvent perçu
> comme négatif, mais en réalité c'est s'assurer que les bases sont
> saines pour pouvoir correctement construire.
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/

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