Re: [FRnOG] [TECH] Avis sur serveur SuperMicro Vs ASUS

[Olivier Cochard-Labbé]

On Mon, Jan 22, 2024 at 2:47 PM Julien Beaucourt 
wrote:

> Sinon j'ai toujours aimé cette marque concurrente de super micro, leurs
> cartes mères sont hyper robustes et les prix corrects c'est Tyan :
> https://www.tyan.com/
>
>
On déploie du serveur à base de Tyan depuis quelques années, et j’apprécie
l'accessibilité de leur support.
Que ce soit pour remplacer leur BMC propriétaire par de l’OpenBMC, ou nous
assister avec des SFP mal supportés par leur NIC embarqués, ils sont plus
réactifs que l’autre constructeur mentionné.

Olivier

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

Re: [FRnOG] [BIZ] Fortinet augmentation tarif

[Olivier Cochard-Labbé]

On Thu, Jul 7, 2022 at 11:04 PM Julien RICHER  wrote:

>
> Là ils sont quand même dans de l'extrême, je ne pense pas que quelqu'un qui
> ait un trafic de production de 50G envisage du Mikrotik CHR aujourd'hui.
> Mais ça reste intéressant à suivre, comme les avancées de Netflix qui
> arrivent à servir 400Gbps de contenu par serveur (sous FreeBSD).
>
> C'est vieux ça :-)
C'est 800Gbps actuellement mais le streaming vidéo c'est essentiellement
des gros paquets TCP, donc un faible throughput (paquet-par-secondes) qui
ne pose pas trop de problème aux routeurs.
Prochaine présentation prévue en septembre à Vienne sur ce sujet:
https://2022.eurobsdcon.org/program/

Cordialement,
Olivier

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

Re: [FRnOG] [MISC] upgrade du routeur Cisco perso

[Olivier Cochard-Labbé]

On Mon, Oct 4, 2021 at 12:02 PM Cécile MORANGE 
wrote:

>
> > Pas Cisco : j'ai plein d'options; ne pas suggérer. EIGRP nécessaire et
> j'ai pas envie de débogger FRR.
> Tiens, je pensais que EIGRP c'était une légende et qu'on l'apprenait que
> en cours :D
> Par curiosité, pourquoi utiliser EIGRP et pas un autre IGP comme OSPF ou
> IS-IS (voir RIP, mais pour moi ça reste dans la catégorie "vu qu'en
> cours et pas en vrai") ?
>

La seule fois ou j'ai croisé de l'EIGRP, c'était un réseau assez étendu
géographiquement (centaine de sites au travers d'un pays de montagne) qui
avait un mélange de liens satellite et terrestres pas très stable (et avec
des architectes très Cisco fanboy).
Et donc les métriques delay, relialibily, bandwidth  permettaient
d'optimiser le routage dans ce cas très particulier.

Olivier

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

Re: [FRnOG] [TECH] Bitream -> Bras alternatives a JunCisco?

[Olivier Cochard-Labbé]

On Thu, Apr 1, 2021 at 11:13 AM Mathieu  wrote:

> il y a aussi accel-ppp:
>
> https://accel-ppp.org/
>
> qui doit pouvoir faire ça. Moi je l'utilise depuis des années en prod mais
> juste pour du pppoe, sans l2tp.
>
> Par contre, ça ne sait pas faire la partie LAC, et si quelqu'un connait
> une solution libre pour ça, je suis preneur, parce que même Mikrotik
> utilise du cisco pour faire ça dans sa doc officielle.
>
> mpd5: http://mpd.sourceforge.net/

Avec un exemple de configuration simple ici:
https://bsdrp.net/documentation/examples/pppoe_and_l2tp_lab

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

Re: [FRnOG] [TECH] Prise électrique commandée par câble (USB ?) : genre de PDU mono-prise sans réseau

[Olivier Cochard-Labbé]

On Mon, Dec 7, 2020 at 5:05 PM DUVERGIER Claude <
frnog...@claude.duvergier.fr> wrote:

> Bonjour,
>
> Je recherche un produit (ou un bricolage offrant la même fonctionnalité)
> pour pouvoir redémarrer électriquement un équipement assez simple
> (modem/routeur de FAI) à distance : sans avoir à me déplacer sur place.
>
J'ai eu le même problème sur un lab avec du matos non IPMI (PC engines APU)
et ma solution: 44€ le pack des 4 prises intelligentes «Smart Life»:
https://www.amazon.fr/gp/product/B086C1RJCZ/ref=ppx_yo_dt_b_asin_title_o07_s00
Il faut du wifi dans le labo, mais ensuite c'est «Alexa, reboot mon
routeur» :-)

Olivier

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

[FRnOG] [JOBS] Poste Senior Network Engineer ouvert chez Netflix

[Olivier Cochard-Labbé]

Bonjour,

Poste ouvert en full-remote (détail non indiqué dans le descriptif),
c'est-à-dire depuis n'importe quel pays européen où nous disposons d'un
bureau (FR, UK, DE, ES, NL si je n'en oublie pas).

Pour la description détaillée et pour postuler c'est par ici:
https://jobs.netflix.com/jobs/39251267

Pour en savoir plus sur la culture interne c'est par là:
https://jobs.netflix.com/culture?lang=Fran%C3%A7ais

Bonne soirée,

Olivier

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

Re: [FRnOG] [TECH] UDP - DDOS : Solution globale possible ?

[Olivier Cochard-Labbé]

On Fri, Sep 4, 2020 at 8:25 AM Fabien H  wrote:

> >
> > Alors comment faire ?
> > Une solution facile est d'embarquer ta propre pile TCP modernisée dans
> ton
> > logiciel client qui lui va encapsuler le tout dans de l'UDP en sortie
> pour
> > limiter l'overhead.
> >
> >
> OK et donc QUIC en est un exemple
>
> Du coup les fournisseurs type Netflix recherchent avec l'UDP un certaine
> réactivité / diminution de la latence ? Parce qu'avec l'augmentation des
> débits des liens Internet, l'overhead TCP devient moins problématique ?
>
>
Pour l'amélioration de la réactivité, et donc ceci ne concerne que
l'interface de navigation, il suffit d'augmenter la densité de son CDN pour
réduire la latence au maximum (en rapprochant les serveurs des clients).

Concernant l'overhead TCP, j'ai du mal m'exprimer:
Le comportement de la pile TCP (donc son overhead) existe toujours, mais
elle est embarquée dans le logiciel client (qui réimplémente sa propre pile
TCP en espace utilisateur).
Le logiciel client va encapsuler son TCP personnalisé dans de l'UDP
«standard» géré par n'importe quel OS.
Le but ici étant d'avoir, comme mentionné dans ce thread, un algorithme de
congestion TCP adapté à l'usage: Vu les quantités de données servies,
l'impact des améliorations, même insignifiantes, ont des répercussions très
importantes.

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

Re: [FRnOG] [TECH] UDP - DDOS : Solution globale possible ?

[Olivier Cochard-Labbé]

On Thu, Sep 3, 2020 at 9:49 AM Fabien H  wrote:

>
> Bien sur cela va à l'encontre de la neutralité du net, et l'utilisateur qui
> veut utiliser des services UDP (VoIP, NTP, ..) chez un autre opérateur
> risque de ne plus avoir accès aux services.
>
> Bonjour,

j'ai l'impression que l'usage de l'UDP risque au contraire d'augmenter, et
voici pourquoi:

Prenons l'exemple où tu offres un service SVOD et que tu sois donc en
recherche constante d'offrir la meilleure qualité possible à tes abonnées.
En plus d'avoir une équipe dédiée à l'optimisation des codecs audio/vidéo,
tu en as une dédiée a améliorer les différents protocoles de congestion TCP
(BBR, RACK).
Il va être simple de faire évoluer la pile TCP de tes propres serveurs,
mais tu vas très vite être bloqué par le côté client:
Ton logiciel client étant déployé sur un ensemble très exotique de matériel
plus ou moins vieux (de la Wii U à l'ensemble des télés connectées, en
passant par les STB des FAI et smartphones), il t’est impossible de faire
évoluer leur pile TCP car gérée par l'OS de ces clients auquel tu n'as pas
la main.

Alors comment faire ?
Une solution facile est d'embarquer ta propre pile TCP modernisée dans ton
logiciel client qui lui va encapsuler le tout dans de l'UDP en sortie pour
limiter l'overhead.

Cordialement,
Olivier

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

Re: [FRnOG] [MISC] Réduction du bitrate de Netflix

[Olivier Cochard-Labbé]

On Fri, Mar 20, 2020 at 11:30 AM Paul Rolland (ポール・ロラン) 
wrote:

> Bonjour,
>
>
> Pas exactement la meme chose... YT change sa resolution "par defaut", mais
> on peut toujours demander a revenir a qq chose avec une meilleure
> resolution, il suffit de cliquer...
> Netflix, c'est juste magique... Ils passent sur la compression max
> possible, et vont ainsi faire de l'Europe la zone de validation de tous
> leurs travaux de R en matiere de compression. Et si tout le monde est
> content, ca sera valide globalement, et surement generalise.
> On est juste en train de leur offrir le plus beau terrain de validation
> live dont ils puissent rever... et on les felicite en plus pour ca.
>
>
Bonjour,

il n'y a rien d'expérimental dans ce qui est appliqué actuellement, et cet
article de Numerama le résume très bien:
https://www.numerama.com/tech/612869-baisse-de-la-qualite-sur-netflix-quest-ce-que-cela-change-pour-vous.html

Pour résumer: L'adaptive streaming est momentanément désactivé pour ne
proposer que le bitrate minimum possible pour chaque résolution.

Et cela permet de réduire d'environ 25% la consommation de bande passante:
https://www.protocol.com/Bulletins/netflix-to-reduce-eu-bandwidth-by-25

Olivier

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

Re: [FRnOG] [TECH] Match Fortigate vs pfsense

[Olivier Cochard-Labbé]

On Fri, Mar 6, 2020 at 5:59 AM David Ponzone 
wrote:

> Ami.e.s de la QoS (mais pas de la neutralité du net),
>
> Je me demandais où en était pfsense, par rapport à un constructeur
> référence dans ce domaine comme Fortinet, au niveau du contrôle applicatif
> (shaping prioritisation, etc…).
>
> On peut espérer l’auto-détection des services de streaming, et de les
> prioritiser au détriment du reste par exemple ?
> Et shaper à mort tout ce qui est Torrent (même sur ports custom) ?
>
> Je vais tester, mais si on me dit directement que Forti a encore une
> grosse longueur d’avance du côté de la détection auto et de la simplicité
> de configuration, je vais peut-être pas perdre de temps.
>
>
Bonjour,
à l'époque de Napster et autre eMule, je m'étais retrouvé dans la situation
de «limiter la casse» d'un accès internet d'une cité étudiante.
Et j'avais utilisé une méthode KISS qui ne nécessitait pas de détecter le
type de trafic, mais de simplement de partager la bande passante disponible
par utilisateur (ie adresse IP "active").
J'ai un exemple de configuration ici, utilisant IPFW & dummynet:
https://bsdrp.net/documentation/examples/fair_traffic_shaping_per_ip_with_ipfw-dummynet

Olivier

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

Re: [FRnOG] [TECH] Routeur BGP matériel ou logiciel

[Olivier Cochard-Labbé]

On Sat, Nov 9, 2019 at 7:22 AM Michel Py 
wrote:

>
> > PS2: Netflix utilisent également des AMD et surprend sur les
> performances réseaux :
> >
> https://www.phoronix.com/scan.php?page=news_item=Netflix-NUMA-FreeBSD-Optimized
>
>
Bonjour,

je suis dans l'équipe qui travaille sur ce sujet chez Netflix… mais je
viens de l'ancien monde (Cisco/Juniper chez gros telco) et je passe mon
temps libre à jouer avec du routeur logiciel.
Donc je vais en profiter pour quelques précisions et avertissements:
1. Oui il est possible de servir du 200Gb/s TLS sur des serveurs
classiques. Les améliorations étant reversées dans FreeBSD -head (branche
de dev) c'est dispo pour tout le monde. Ensuite il ne s'agit que de la
partie OS, reste maintenant à faire les bons choix matériels et
l'optimisation du serveur web (nginx dans notre cas).
2. Servir de la VOD est assez simple car les paquets émis font la taille
maximale permise, donc le travail d'optimisation se concentre
essentiellement sur les problèmes de bande passante (disque -> carte
réseau). Par contre dans le cas d'un routeur, avant la notion de bande
passante c'est le nombre de paquets par seconde (pps) routé qui est l'unité
de base. C'est-à-dire que si j'installe 2 interfaces 100Gb sur serveur, le
premier exercice va être de vérifier comment il réagit, non pas en recevant
un flux à 100Gb/s, mais plutôt 148 Millions pps en cas de DoS… et ce n'est
pas la même chose.
3. Concernant la gestion d'un DoS, à partir de 10Mpps va falloir utiliser
des cartes réseau disposant de fonctionnalités d'assistance matérielle
comme un firewall supportant le line-rate. Je l'ai testé sur une carte
Chelsio 40Gb en lui envoyant un DoS d'environ 50Mpps et elle a fait
parfaitement le boulot (j'ai juste eu besoin d'aide de Chelsio pour le
paramétrage car la documentation est très rare sur le sujet). Maintenant il
y a d'autre problématique concernant la limite des règles de ce firewall en
elle même.
4. Et le dernier point: Je ne suis pas sûr que de se lancer dans une
solution de routeur logiciel «DIY» (c'est-à-dire autre qu'un 6Wind/Netgate
TNSR ou équivalent acheté clé en main) dans une optique de faire
essentiellement des économies soit une bonne idée. Car il va falloir
embaucher un profil capable de comprendre et de débugger: le fonctionnement
matériel d'un serveur/CPU moderne, le noyau, les drivers réseau et le FRR
ou Bird. Donc oui vous allez économiser en licence, mais je ne pense pas
qu'un profil «kernel C» soit au même prix qu'un admin Cisco/Juniper.

Cordialement,
Olivier

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

Re: [FRnOG] [TECH] - Recherche IOS le plus récent pour cisco 2651XM

[Olivier Cochard-Labbé]

2017-10-16 12:25 GMT+02:00 Stéphane Diacquenod :

> Bonjour,
>
> Merci à tous pour vos réponses, il y a des choses intéressantes en effet !
>
> On m'a soufflé dans l'oreillette une proposition à base de rasberyPI et de
> pieuvre DB9 (https://www.amazon.com/Gearmo-Serial-Windows-Certified-
> Drivers/dp/B004ETDC8K/ref=pd_sim_147_62?_encoding=UTF8_
> rd_i=B004ETDC8K_rd_r=GXM8950N89EAHHVEM8W2_rd_w=zJdW6&
> pd_rd_wg=KGnTK=1=GXM8950N89EAHHVEM8W2).
>
> Certains ont-ils déjà expérimenté cela ?
>
>
Bonjour,
j'ai été très déçu par la qualité des pieuvres DB9/USB car certains ports
tombaient en panne très rapidement:
Donc si vous avez une référence fiable je suis preneur.
Du coup je me suis monté des serveurs de terminal série à base de PC
Engines APU + 2 cartes miniPCI 4-ports série (Delock 95001).
Le tarif des 2 cartes Delock (environ 74€ l'unité) a fait exploser mon
budget, mais j'ai gagné énormément en robustesse.
J'ai aussi fait un prototype de châssis 1U pour cet ensemble APU + 8 ports
DB9 série supplémentaires. Il y a des choses à revoir dans cette première
version (angle a arrondir, ajout de marge, etc.), mais le DXF est en ligne
pour ceux que ça intéresse:
https://github.com/ocochard/BSDRP/blob/master/EINE/docs/PC-Engines-APU-Terminal-Server-QCAD-R27.dxf

Cordialement,
Olivier

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

Re: [FRnOG] [TECH] Buzz autour du SD-WAN

[Olivier Cochard-Labbé]

2017-08-17 8:51 GMT+02:00 Xavier Beaudouin :

> Ceci dit, attention à l'eugénisme software si on veux pas avoir les mêmes
> emmerdes futures comme le leap seconds qui ont foutu la grouille avec les
> Java et Linux.
>
>
​Ha ben là c'est trop tard :-(
Il suffit de regarder le choix des technos​ utilisés dans les contrôleurs
SDN pour s'apercevoir que ces solutions ont été pensées par le stagiaire
Web 2.0 qui n'avais pas grande notion des technos télécoms/réseau ni de la
sécurité.

Exemple avec Juniper Contrail [1]:
1. Ils ne savaient pas ce qu'était BGP alors ils ont utilisé du XMPP à la
place.
2. Ils ne connaissaient pas les fichiers textes pour stocker la
configuration, alors ils ont déployé du Cassandra, oui le truc pour du big
data pour stocker la configuration de leur solution. Et comme cette base
était aussi utilisée pour collecter l'ensemble des netflows de la
plateforme, ben il suffisait qu'un client sur la plateforme génère un gros
nombre de flux (style un serveur DNS) pour remplir la base et bloquer
l'ensemble. :-)
3. Ils s’obstinent a vouloir que les VMs partagent le même domaine de
broadcast de niveau 2 entre-elles (on devrait leur expliquer que les applis
sont essentiellement en IP), donc ils utilisent des technos d'overlay de
VLAN (VXLAN ou autre). Va falloir leur expliquer que pour le cloisonnement
large-scale, MPLS a fait ses preuves et que la mise au point d'un
MPLS-over-Ethernet (et pas over-GRE ou over-UDP) aurait peut-être était
plus judicieux et surtout plus simple?
Le seul intérêt potentiel que je vois a garantir ce domaine de broadcast de
niveau 2, est pour le VM-motion entre différents DC (garder la même MAC/IP
de la VM). Mais le VM-motion n'est utile que dans un cas très particulier:
Le déplacement d'applications interactives (style serveur TSE ou gateway
VoIP) qui ne permettent pas de simplement démarrer une nouvelle instance et
d'éteindre l'ancienne instance de façon transparente pour l'utilisateur.
C'est quand même très limité comme cas pour toute cette complexité.
4. Pour la gestion des configurations, c'est du NETCONF qui est utilisé… le
truc tellement simple qu'il faut plus de 35 RFC pour l'expliquer. Comment
cela se fait qu'il existe depuis longtemps de nombreuses solutions de
gestion de configuration des serveurs, qui pourtant sont beaucoup plus
compliqués à gérer qu'un routeur/switch, et qu'aucune de ces solutions
n'ait été réutilisée ici ?
5. À la place de netflow ils utilisent du Sandesh, ben oui c'est plus
simple de tout mettre dans du XML;
6. Ils ont découvert l'existence d'IPv6 très très tard;
7. Le tout est validé pour fonctionner sur de l'Ubuntu, car le stagiaire
n'avait que cela sur son poste ?
8. Et ne pas oublier que comme c'est du réseau, c'est à faire
installer/administrer/débugger par vos équipes réseaux… sauf que bien sûr
vous n'avez pas pensé à la leur reconversion professionnelle en devops
(compter 6-mois minimum). ATT semble être l'unique exception sur ce sujet
[2]. Ailleurs (dans les grosses boites de taille identique) je ne suis pas
sur que ce soit le cas.

Donc pourquoi les opérateurs font du SDN ? Car Gartner a dit que c'était
l'avenir, donc il faut rapidement sortir une offre comme les concurrents,
même si on a aucune idée de ce que cela va donner.
Les solutions actuelles sont d'une complexité hallucinante et tombent
miraculeusement en marche. Je ne souhaite pas être dans le coin le jour ou
il faudra déboguer cette usine à gaz: L'empilement énorme des différentes
technologies rend ingérables ces solutions. Il n'y a qu'a regarder la
figure n°1 (page 9) de la doc Juniper qui se permet de résumer OpenStack à
un seul bloc pour avoir un aperçu de l'ensemble. J'aurais bien aimé
calculer le nombre de ligne de code de l'ensemble des éléments d'une
solution complète pour rigoler ainsi que le nombre de technos/langages
différents utilisés.

Au final c'est quand même positif: enfin les équipes réseau vont, forcées,
découvrir l'ensemble des technos matures (et en majorité open source)
utilisées par les équipes devops et du coup cela permettra d'accélérer des
sujets comme l'automatisation des configurations, tests de régression et
intégration continue, d'envisager d'utiliser des solutions à base de x86
pour remplacer des routeurs Cisco/Juniper et de tester des switchs ONIE.

Olivier

[1] http://www.juniper.net/us/en/local/pdf/whitepapers/2000535-en.pdf
[2] https://networkingexchangeblog.att.com/wp-content/uploads/2017/
04/ATT-Tech-Dev-Transformation-Whitepaper-FINAL.pdf

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

Re: [FRnOG] [TECH] UCARP/VRRP avec Debian problème

[Olivier Cochard-Labbé]

2017-07-11 8:51 GMT+02:00 Sébastien 65 :

> Je trouve étrange que keep ou carp ne fonctionnent pas sur du bond... Car
> si on veux une tolérance aux pannes + de débit rien ne vaut un bond/lacp
> avec du switch !
>
>
> J'ai du mal à comprendre le fonctionnement des deux softs... Il va peut
> être falloir migrer sous BSD pour faire bond+vrrp@vmac !!
>
>
>
​Bonjour Sébastien,
pour ta conversion vers FreeBSD et te guider vers la lumière, voici comment
le faire ;-)

Soit une machine avec 2 cartes réseaux Intel (drivers igb).
Pour la première machine (master):

sysrc hostname=depenguinator1
sysrc cloned_interfaces="lagg0"
sysrc ifconfig_igb0="up"
sysrc ifconfig_igb1="up"
sysrc ifconfig_lagg0="inet 10.0.0.1/29 laggproto loadbalance laggport igb0
laggport ibg1"
sysrc ifconfig_lagg0_alias0="inet 10.0.0.6/32 vhid 1 advskew 100 pass
abcd123"
echo 'carp_load="YES"' >> /boot/loader.conf
kldload carp
service netif restart

Pour la seconde machine (backup):

sysrc hostname=depenguinator2
sysrc cloned_interfaces="lagg0"
sysrc ifconfig_igb0="up"
sysrc ifconfig_igb1="up"
sysrc ifconfig_lagg0="inet 10.0.0.2/29 laggproto loadbalance laggport igb0
laggport igb1"
sysrc ifconfig_lagg0_alias0="inet 10.0.0.6/32 vhid 1 advskew 200 pass
abcd123"
echo 'carp_load="YES"' >> /boot/loader.conf
kldload carp
service netif restart

Et comme demandé: pas de preempt d'activé, pour éviter que la master
reprenne son rôle de master suite à un reboot de celui-ci.

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

Re: [FRnOG] [TECH] Mutualiser deux connexions internet

[Olivier Cochard-Labbé]

2017-04-28 21:34 GMT+02:00 Helyousa BJ :

> Bonjour la liste,
>
> Pour le besoin d'une pme qui galère avec sa connexion adsl, on a commandé
> un routeur 4g qui dispose d'un meilleur débit. Neanmoins, je souhaiterai
> mutualiser les 2 connexions et pouvoir cumuler, deja pour avoir un backup
> en cas de perte 4g et aussi pour ne pas laisser à l'abandon l'ADSL.
>
> Je cherche donc une solution pas trop cher pour faire ça.
>
>
​Pour l’agrégation de lien:​

​Premier exemple avec le logiciel libre MLVPN (
https://zehome.github.io/MLVPN/):
https://bsdrp.net/documentation/examples/aggregating_multiple_isp_links_with_mlvpn

Deuxième exemple avec du MLPPP par le logiciel libre mpd5 (
http://mpd.sourceforge.net/):
https://bsdrp.net/documentation/examples/aggregating_multiple_isp_links
​

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

Re: [FRnOG] [JOBS] Orange recrute un admin réseau

[Olivier Cochard-Labbé]

2017-01-10 10:43 GMT+01:00 Laurent :

> Le 10/01/2017 à 10:24, Pierre Emeriaud a écrit :
> > Orange recrute à Cesson-Sévigné (à coté de Rennes) un admin réseau
> > confirmé pour renforcer l'équipe en charge de l'exploitation du
> > backbone OBS.
>
> Pourquoi beaucoup d'annonces ne mentionnent pas le salaire envisagé ?
> Et je ne parle pas du post - merci pour le lien - mais de l'annonce
> elle-même.
> Pour postuler, on est obligé de donner son mail, son cv, et sa lettre de
> motiv, avant même de savoir si le salaire est correct.
>
> C'est tabou le salaire ?
>
>

Disclaimer: Je suis un collègue ​de Pierre.

​Mon hypothèse concernant l'absence de salaire: Ce n'est peut-être pas
l'information la plus pertinente et surtout donner une fourchette de
salaire n'est pas suffisant.
Il manquerait l'ensemble du package autour (les moyens en formation, la
participation, les avantages CE & AS sportives, la mutuelle, l'ambiance
sociale, la stabilité et les opportunités de mobilité interne, etc.) et
l'annonce risque d'être 3 fois plus longue au final.
Donc en priorité on recherche une personne qui vient le matin car elle
prend son pied à s'amuser avec toutes ces technos réseau… Si elle vient
pour un job uniquement alimentaire, ce n'est peut-être pas le bon job.

Salutations

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

Re: [FRnOG] [TECH] router linux : quagga + packet-journey , quelqu'un a déjà essayé ?

[Olivier Cochard-Labbé]

2016-04-29 19:51 GMT+02:00 Vincent Bernat :

>  ❦ 29 avril 2016 17:20 GMT, Michel Py  > :
>
> >> En revanche avant de penser à utiliser packet journey comme
> >> forwarding plane :), il faut bien évaluer si cela en vaut la peine.
> >> Est ce que tu fais tant de trafic que tu ait besoin de dpdk ? aka
> >> supérieur à xGo/s ? Est ce qu'un simple linux/bsd bien tuné ne
> >> suffirait pas ?
> >
> > La carte mentionnée sur la page de Gandi est une 40 Gbit/s (XL710).
> >
> > Question de débutant dans ce domaine : un serveur comme ci-dessus,
> > avec juste BIRD et une distro sans fioritures (pas de DPDK, pas de
> > packet shader), on peut en sortir quel débit, avec des paquets de 64
> > octets ? Je me suis laissé dire qu'on dépassait difficilement 1 ou 2
> > Gbit/s.
>
> Ça dépend combien de coeurs tu as sur ta machine, vu que pour du
> routage, ça scale de manière linéaire sur le nombre de coeurs avec assez
> peu d'efforts. Sur un proc récent, tu peux viser 2 Mpps par coeur. Du
> coup, avec un hexacoeur, tu montes à 10G. Il semble qu'avec des noyaux
> plus récents (> 4), les performances ont été multipliées par 2. Je suis
> pas très à jour là-dessus.
>


​Je confirme: avec un FreeBSD 11-head, branche routing (pour corriger un
bug de non-linéarité), c'est en effet environ 1.5Mpps/cœurs et linéaire à
condition de n'avoir qu'un seul package physique: Les architectures NUMA
posent d'autre problèmes.
​
Exemple, avec un Intel Xeon E5-2650 a 2.6GHz et 8 cœurs (Hyperthreading
desactivé), on atteins "presque" les 10Mpps:

​
https://github.com/ocochard/netbenches/blob/master/Xeon_E5-2650-8Cores-Chelsio_T540-CR/nXxq10g.random.harvest.mask.351/results/fbsd11-routing.r287531/README.md

​(le harvest.mask mentionné sur ces graphs concerne la configuration des
sources d'entropie a utiliser: Utilise le trafic Ethernet créer un problème
de performance avec 8 cœurs ou plus).

​​Cordialement,

​Olivier

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

Re: [FRnOG] [TECH] BGP Quagga - Choix Hardware

[Olivier Cochard-Labbé]

2016-04-21 12:25 GMT+02:00 Joe Yabuki :

> Bonjour à tous,
>
> ​Bonjour Joe,
​


> Apres avoir décidé de déployer Quagga sur mon réseau BGP (sauf si vous me
> conseillez autre chose), j'essaie de savoir quel Hardware pourrait
> convenir.
>

Quagga fonctionne bien mais essayez bird​, vraiment.


> Le contexte est le suivant :
>   - Deux Serveurs Quagga  en iBGP
>   - eBGP pour recevoir une Full Table INET
>   - Le trafic IN/OUT est de 500Mb
>
>
​C'est plus le nombre de paquets par secondes qui va être le facteur
bloquant, car une valeur en Mb/s ne veut pas dire grand-chose: Avec 100% de
Jumbo frame n'importe quelle vieille bécane même avec des NIC RealTek (le
pire) serait capable d'atteindre 500Mb/s.
​De plus vous ne maitrisez pas le trafic entrant, donc il faut que votre
hardware supporte sans broncher le maximum possible de l'interface.
C'est-à-dire qu'avec une interface Gigabit, il doit encaisser sans problème
1.48Mpps.
Va donc falloir une NIC multiqueue, plusieurs cœurs et un OS supportant le
tout.
Et c'est le cas des petites configuration:
Une petite machine style Netgate RCC-VE 4860 (4 cores Intel Atom C2558E,
8Go de RAM, NIC Intel i350) sous FreeBSD 10.2 continue de router du 700Kpps
nativement (sans netmap ni DPDK), c'est-à-dire environ équivalent à 2Gb/s
avec une distribution simple IMIX. Alors que ce test lui envoie le maximum
(1.48Mpps).
Les résultats sont ici:

https://github.com/ocochard/netbenches/blob/master/Atom_C2558_4Cores-Intel_i350/fastforwarding-pf-ipfw/results/fbsd10.2/README.md

​Il va falloir attendre FreeBSD 11 qui corrigera un problème de performance
et rendra ses performances en routage linéaire en fonction du nombre de
cœurs: Sur cette petite configuration on passe à environ 1.1Mpps.​

Les caractéristiques de mes deux seront les suivants :
>   - CPU: Core i7 900
>   - RAM: 16 Go
>   - HDD: SSD 200GB
>   - NIC: SFP ? Quel carte me faudrait-il, j'imagine que le critère le plus
> important sera le buffer ?
>
>
Je ne connais pas Linux mais sous FreeBSD les NIC Chelsio offrent
d'excellentes performances et le support technique de leur drivers est
ultra réactif.
Par contre je ne pense pas qu'un gros buffer soit une bonne idée à cause de
la latence induite quand il faut vider celui-ci.

Cordialement,

Olivier
​

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

Re: [FRnOG] [TECH] Serveur console

[Olivier Cochard-Labbé]

2015-12-25 0:19 GMT+01:00 Vincent Bernat :

> Hello,
>
> Un projet de serveur console 1U en open hardware est disponible ici :
>
>  https://freetserv.github.io/
>
> 48 ports. Un Raspberry Pi 2 pour gérer tout ça. 720 euros environ de
> matériel. Malheureusement, à souder soi-même.
>

​​​Merci pour le lien !
Je ne connaissais pas la puce FT4232H.
J'avais commencé un PoC pour un serveur console 1U avec 8 ports série (il
en inclus 10 en tout) à base de:
- carte mère PC Engines APU (inclus 2 ports série, mais j'en garde un pour
la console): environ 125€
- un module mSATA 16Go: 19€
- L'alim: 5€
- 2 cartes miniPCI 4 ports RS-232 (Delock module MiniPCIe I/O PCIe full
size 4 x Serial RS-232): 75€ l'unité
- Un châssis 1U bête et méchant, dessiné par moi-même et réalisé par la
première boite de découpe laser/pliage du coin: 20€ le boitier pour une
série de 10 minimum. Les plans du châssis sont dispo pour ceux que ça
intéresse, mais des améliorations sont à prévoir.
J'arrivai à un total d'environ 320€ H.T.​​

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

Re: [!!Mass Mail][FRnOG] [TECH] Petit routeur pour remplacer netscreen

[Olivier Cochard-Labbé]

On Fri, Aug 21, 2015 at 10:14 AM, Vivien Prodhomme 
vivien.prodho...@tevolution.fr wrote:

 Hello,

 Si tu te sens d'humeur un peu plus roots :
 - si t'as les sous : routeur soekris + OpenBSD (
 http://soekris.com/products/net6501-1.html)
 - si t'as pas les sous : routeur (WiFi + gigabit) compatible + OpenWRT


​Bonjour,

Je trouve beaucoup trop cher cette vieille gamme de Soekris (la nouvelle
net6801 ne semble pas encore disponible) comparé aux nouvelles gammes
multi-cœurs style le
PC Engines APU ​(
​2 cœurs AMD 64bits,
 3
​NIC realtek
)
​ ou le Netgate RCC-VE 2440 (2 cœurs Intel Atom 64bits, 4 NIC Intel) ou
4860 (4 cœurs, 6 NIC). Et avec un pfSense/opnsense d'installé cela ne fait
pas si root que cela. Par contre
toutes ces nouvelles plateformes étant multi-cœurs, mettre de l'OpenBSD
​qui n'utilise que 1 cœur pour le routage/filtrage c'est un peu dommage.

​Cordialement,

Olivier

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

Re: [FRnOG] [TECH]Info sur le CCNP

[Olivier Cochard-Labbé]

2015-02-13 15:43 GMT+01:00 Carrel Yakpovi car...@akposso.com:

 Bonjour

 Voici un lien utile


 http://olivier.cochard.me/reseaux/cisco/conseils-pour-la-preparation-aux-certifications-cisco


Oula... attention: Les conseils donnés datent de 2004. Les liens risquent de
ne plus être valides tous comme les numéros des examens.
Mais sinon oui le CCNP (Routing  switch) est pas mal pour bien comprendre
les technos de base: J'ai appris énormément en préparant cette
certification et plus de 10ans après cela me sert toujours.

Cordialement,

Olivier

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

Re: [FRnOG] [TECH] Agrégation de liaisons SDSL

[Olivier Cochard-Labbé]

2014-12-09 22:11 GMT+01:00 Laurent Coustet e...@zehome.com:


 Regarde le projet que j'ai écrit mlvpn [1] qui répond à ce besoin.

 Le système monte un tunnel niveau 3 puis équilibre les envois de paquets
 UDP selon le débit défini par lien.


Bonjour,

J'utilise le même concept, mais avec du MLPPP (et donc L2TP).
Pour cela j'utilise l'outil mpd5 (mpd.sourceforge.net) et voici un exemple
de configuration:
http://bsdrp.net/documentation/examples/aggregating_multiple_isp_links

Je connaissais pas mlvpn: Merci pour l'info.

Olivier

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

Re: [FRnOG] [TECH] 107M de sockets TCP et encore et encore

[Olivier Cochard-Labbé]

2014-09-09 23:12 GMT+02:00 Vincent JARDIN vincent.jar...@6wind.com:

 Merci à IXIA qui nous a monté un système spécifique unique (avec
 l'alimentation électrique qui allait bien ;) ) pour stresser un simple
 serveur HP sur lequel on a monté 107M de sockets TCP à 5M par seconde avec
 le 6WINDGate. Le DPDK est utilisé pour les IO et le 6WINDGate pour sa stack
 réseau de fast path complémentant le DPDK.

 http://www.6wind.com/news-events/press-releases-2014/
 6wind-press-release-september-9/

 Ca sert à quoi de faire 107M de sockets TCP? ;D


Impressionnant !

Mais une question en lisant l'annonce:
- 242 Gbps of outbound HTTP application throughput
- with over 10x the performance of standard Linux

Donc vous considérez qu'un Linux standard ne délivre que 24.2Gbps maximum.
Or un linux standard avec ngnix sur une machine plus ancienne que la votre
donne du 40Gbps: Cf figure 4c du doc suivant:
http://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201408-sigcomm2014-specialization.pdf
(le code source de sandstorm et namestorm devrait être en ligne dans
quelques semaines).

Le gain en performance serai plutôt de 5x que de 10x non ?
Mais c'est quand même bien sympa 5x! :-)

Concernant l'Intel DPDK: Est-ce que cela ne fonctionne qu'avec processeur
Intel ? Ou est-ce un framework agnostique du processeur (comme netmap) ?

Cordialement,

Olivier

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

Re: [FRnOG] [MISC] La machinbox du geek barbu

[Olivier Cochard-Labbé]

2014-09-06 8:08 GMT+02:00 Emmanuel Thierry m...@sekil.fr:

 Bonjour,

 Dans ton cas on dirait un Raspberry Py ! ;)
 Est-ce que les APU de chez PC Engines ne répondraient pas à la majorité
 des requirements ? (à part le HDMI)
 http://www.pcengines.ch/apu.htm

 Cordialement
 Emmanuel Thierry


Je plussoie: l'APU de PC Engin
es permet de monter a environ 155Kpps
(environ 440Mb/s d'IMIX) en routage et 115Kpps (environ 325Mb/s d'IMIX) en
firewalling.
http://bsdrp.net/documentation/examples/forwarding_performance_lab_of_a_pc_engines_apu
Sans compter que les extensions (mSATA de 16Go, carte wifi, etc...)
proposées par PC Engine ne sont vraiment pas cher: J'en suis à environ 140 EURO
au total.
Je n'ai pas mesuré les perfs en IPSec car je ne sais pas comment faire:
Quelles sont les valeurs pertinentes à mesurer pour définir les perfs
IPsec ? (je ne pense pas que cela se résume au pps max avec taille mini
comme pour un routeur).

Cordialement,

Olivier

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

Re: [FRnOG] [TECH] Appliance 1U - pour routeur

[Olivier Cochard-Labbé]

2014-03-11 9:20 GMT+01:00 Sébastien 65 sebastien...@live.fr:

 Bonjour,

 Je suis à la recherche d'un ou des contacts concernant des Appliance 1U de
 type Intel ATOM - 2 à 4 Go RAM - 2 disques 2.5 - 4 ports (ou plus) Giga
 RJ45, SFP?...

 Le but final est d'en faire un routeur de bordure sous Linux/BGP...

 Utilisez-vous ce genre de configuration sur votre backbone ? (Me semble
 que Gitoyen utilise des trucs comme ça, une recherche sur NanoBSD et je
 suis tombé sur leur page...)


Bonjour,

J'ai actuellement en test (pas encore en production) un SuperMicro
SuperServer 5018A-FTN4 (Intel Rangeley: Atom C2758 8 coeurs avec 4 ports
Giga).
Voici l'état actuel des performances que j'obtiens sous FreeBSD 10-stable
(BSDRP est juste un nanobsd customizé):
http://bsdrp.net/documentation/examples/forwarding_performance_lab_of_a_superserver_5018a-ftn4

= Je pensais obtenir de meilleures performances (du gigabit line-rate
minimum par exemple) sur ce type de machine.
Les différences de comportement en fonction du nombre de queues affectées
au drivers sont assez étranges: Il faudrait faire d'autres tests sous Linux
pour voir si ce problème ne viens pas de FreeBSD.

 Ensuite que pensez-vous d'installer l'OS sur une carte SD/Flash plutôt
que sur un disque dur ?

J'utilise actuellement des simples clés USB, mais je vais passer aux
modules SATA-Flash.

Cordialement,

Olivier

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

Re: [FRnOG] [TECH] Recherche Equipement Router/Modem/Firewall

[Olivier Cochard-Labbé]

2014-02-13 20:46 GMT+01:00 Matthias Xguard xguard.matth...@gmail.com:

 Bonjour la liste,

 Je suis actuellement à la recherche d'un boitier modem/routeur/firewall qui
 me permettrait d'avoir :
  - 4 ports Giga Ethernet minimum (avec possibilité d'un ou plusieurs SFP
 serait un +)
  - aDSL
  - sDSL (ATM et EFM)
  - Firewall, QOS, NAT

 J'ai pu trouver pas mal d'équipementiers tels que :
  - Microtik RB2011 vraiment excellent mais il manque la partie Modem (adsl
 et sdsl)
  - Zyxel, Elecdan, aethra, rad, eltektec mais tous sont bridés en 10/100M
 sur la partie LAN.
  - Solutions à base d'Alix bridés en 10/100M en LAN et pas de modules xDSL


Et les produits (français!) de Oneaccess ?

Par exemple le 1321:
http://www.oneaccess-net.com/images/stories/resources/datasheets/ead/ds_1321.pdf

Olivier

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

Re: [FRnOG] [TECH] Firewall DataCenter

[Olivier Cochard-Labbé]

2014/1/25 Guillaume Barrot guillaume.bar...@gmail.com


 = double atomisation soyons serieux bordel et finalisation du lustrage
 par un point Godwin bien mérité.


Le point Godwin c'est bien quand on essaye d'expliquer que la techno
«statefull» d'un firewall a été pensée pour protéger un parc de machine
cliente non pas un parc de serveur ? (donc pas trop d’intérêt chez un
hébergeur).

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

Re: [FRnOG] [TECH] FWSM sur 650x

[Olivier Cochard-Labbé]

2013/11/26 Gaëtan Allart gae...@nexylan.com:


 Sachant que nous hésitons entre les solutions suivantes :

 - FWSM mutualisé sur les 6500 pour tous les clients
 - Chassis ASA 552x pour chaque client
 - Firewall typé open-source (PF/IPtables) mutualisé
 - autre ?

Concernant le firewall open-source, pour faire du 10G line-rate (donc
14Mpps) avec un FreeBSD (ipfw ou smp-pf sur la 10.0) il va falloir
prévoir pas-mal de cœur (pas moins de 16 je pense).
Mes benchs sur un IBM x3550M3 (avec 4 cœurs) donne un firewall qui
tiens la route pour du line-rate 1Gbs (1,48Mpps) avec ipfw en
stateless mais pas plus (et la version netmap-ipfw qui pousse à
6.5Mpps n'est pas prête).
http://dev.bsdrp.net/benchs/BSD.network.performance.TenGig.png

Cordialement,

Olivier


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

[FRnOG] [MISC] SDN et la neutralité du réseau

[Olivier Cochard-Labbé]

Bonjour,

Il y a un truc qui semble être de plus en plus à la mode: le
software-defined networking (SDN).
J'ai donc regardé de plus prêt la solution OpenFlow et le concept du
«flow» me fait tiquer.
Si j'ai bien compris, dans un SDN on ne route plus un paquet en
fonction de son IP de destination mais en fonction de plusieurs
paramètres tel que: IP source, IP dest, TCP source, TCP dest, etc…

Or la définition de la neutralité du réseau «exclut ... toute
discrimination à l'égard de la source, de la destination ou du contenu
de l'information transmise sur le réseau» (Wikipedia).

J'ai donc comme l'impression qu'un SDN ne peut, par nature, être un
réseau neutre.
Est-ce que je me trompe ?

Merci


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

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

[Olivier Cochard-Labbé]

2012/12/22 Thomas Barandon t.baran...@gmail.com:
 Le 22 décembre 2012 11:06, Simon Perreault simon.perrea...@viagenie.ca 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.

Non c'est mieux !


 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).


FreeBSD ne passera pas ce cap car ils ont choisi une autre approche:
En ajoutant le support multi-cœur a pf, ils ont fait le choix de
forker le pf d'OpenBSD.
source: http://lists.freebsd.org/pipermail/freebsd-pf/2012-September/006740.html
Et si la multiplication de ces perfs pf par l'usage de l'ensemble de
vos cœurs ne vous suffit pas: il reste netmap.
Netmap est un nouveau framework qui permet de générer/capturer 14.88
Mpps sur une interface 10 GigE interfaces (avec un seul cœur à
900Mhz).
Le firewall historique de FreeBSD (ipfw) a été couplé avec netmap (car
netmap tout seul ne fait pas forwarding, juste du bridge… pour
l'instant): Le résultat nous amène à 6Mpps.
sources:
http://info.iet.unipi.it/~luigi/netmap/
http://info.iet.unipi.it/~luigi/dummynet/#8696

Mais je n'ai pas trouvé le matériel pour valider ces résultats.

Cordialement,

Olivier


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

Re: [FRnOG] [MISC] Téléphones et paranoïa

[Olivier Cochard-Labbé]

2012/9/8 Gaël gag...@gmail.com:
 Bonjour FRnOG !

Bonsoir,

 J'entends depuis longtemps certaines rumeurs, et j'aimerais enfin en
 extraire la vérité :

 - Lorsqu'un GSM n'est pas en communication (cad allumé, mais dans une poche
 par exemple), est-il possible pour certaines organisations d'écouter via le
 micro du téléphone ?


Je pense que c'est très facile pour un opérateur de transformer
n'importe quel téléphone (pas la peine d'un smartphone) en micro:
1. L'opérateur émet un message pour configurer le téléphone en
«décroché automatique» (il faudrait chercher les possibilités offerte
par les protocoles GSM, je pense à la sous-couhe «Call Control» de la
couche «Connection Management» par exemple);
2. Puis l'opérateur appelle le téléphone dans la foulée.
= Le téléphone ne va pas éméttre la moindre sonnerie et prendre
l'appel, il suffit ensuite d'écouter.

Cordialement,

Olivier


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

Re: [FRnOG] [TECH] Choix de routeur

[Olivier Cochard-Labbé]

2012/7/30 Surya ARBY arbysu...@yahoo.fr:
 Je ne pense pas qu'il y ait d'équipements capables de traiter en soft 100
 Mbps ou plus (à cause des interruptions générées sur la CPU tout
 simplement).


Bonjour,

je ne serai pas aussi catégorique sur les capacités de traitement soft
d'un serveur:
Cf le framework netmap qui permet de générer 14.8Mpps sur une
interface 10Gig (avec 1 seul cœur):
http://info.iet.unipi.it/~luigi/netmap/
Et avec l'adaptation du firewall IPFW à ce framework, il est possible
d'atteindre les 9-10Mpps (toujours avec 1 seul cœur).
http://lists.freebsd.org/pipermail/freebsd-net/2012-July/032869.html

Par contre c'est toujours en cours de dev et non utilisable
immédiatement (sauf netmap pour de la capture de trafic à 10Gig).

Cordialement,

Olivier


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

Re: [FRnOG] [TECH] Choix de routeur

[Olivier Cochard-Labbé]

2012/7/30 Surya ARBY arbysu...@yahoo.fr:
 Bonjour.

 ça nécessite des cartes PCI-express TOE pour assurer les performances non ?

 Il me semble que toutes les interfaces 10GE serveur sont forcément TOE
 pour éviter de tuer la CPU avec l'overhead du au traitement de la stack par
 l'OS.

Si je regarde le matériel utilisé
(http://info.iet.unipi.it/~luigi/papers/20120503-netmap-atc12.pdf), il
s'agit d'un système 4 cœur i7-870 4-core CPU a 2.93 GHz
avec carte deux ports 10 Gbit/s (Intel 82599).
Le data sheet de cette carte indique quelle supporte le TCP
segmentation offload et la gestion des interruptions:
http://www.intel.com/content/www/us/en/ethernet-controllers/82599-10-gbe-controller-datasheet.html
Le drivers FreeBSD (ixgbe) correspondant à ces cartes supportes bien
les fonctionnalités TSO, LRO et Checksum Offload (tous activés par
défaut).
Par contre je n'ai pas trouvé quel était l'état de ces fonctionnalités
lors des tests netmap.

Sinon toujours concernant les travaux de cette équipe, il y a un
projet en cours très sympa aussi:
Towards a Billion Routing Lookups per Second in Software
http://info.iet.unipi.it/~luigi/papers/20120601-dxr.pdf
… qui permet de trouver la bonne route très rapidement.

Bref, vivement que tous ces morceaux de code soient mis en place pour
nous pondre des routeurs/firewalls logiciels à la puissance plus que
suffisante pour beaucoup de nos besoins…

Cordialement,

Olivier


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

Re: [FRnOG] Quagga vs Vyatta

[Olivier Cochard-Labbé]

2011/5/9 Dominique Rousseau d.rouss...@nnx.com:
 Sinon, d'assez bons échos de l'utilisation de Quagga sur base Freebsd,
 avec une distribution Nanobsd.


Bonsoir,

je vais en profiter pour faire de la pub pour un de mes projets:

Pour ceux qui veulent tester rapidement un nanobsd (FreeBSD 8.2) avec
Quagga et Bird (ainsi que du FreeVRRPd, CARP et mpd), il y a BSD
Router Project (http://bsdrp.net).

C'est un jeune projet, avec une liste de fonctionnalité assez réduite
pour l'instant (http://bsdrp.net/features).
Il ne demande qu'une clé USB ou compact flash de 256Mo pour son installation.

Un des des intérêts de ce projet est la possibilité de monter un lab
assez facilement par l'usage de VMs
(http://bsdrp.net/documentation/examples) et de passer sur des
machines réelles une fois la configuration testée.

Tous commentaires ou contributions sont les bienvenues car je n'ai pas
la possibilité de l'utiliser en environnement autre que virtuel.

Cordialement,

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

Re: [FRnOG] Retour de prod sur du Juniper.

[Olivier Cochard-Labbé]

2011/2/7 Sébastien FOUTREL sfout...@gmail.com:
 Bonjour,
 Je cherche des avis venant de production pour les EX4200 avec le stack
 virtual chassis et sur le MX80.


Bonjour,

2 piles de 10 commutateurs EX4200 en production (avec entre 5 et 6
Virtual Routers d'activés et une centaine de vlans par pile) depuis
environ 2 ans sans problème. Les piles sont presque pleines.

Je reproche quand même quelques limitations:

1. On est limité à 64 agrégat par pile… Lorsque l'on dispose de 480
ports ce n'est pas beaucoup.

2. J'attends la fonctionnalité ISSU (In-Service Software Upgrade)
depuis très longtemps… Quelqu'un à des nouvelles de la date d'arrivée
sur la gamme EX ?

3. Les logs ne remontent pas assez de problème sur ces équipements.
Voici deux exemples de problèmes que j'ai rencontrés:
- Pas de message dans les logs en cas de bagottement d’adresse MAC sur
2 ports (cas typique de serveur avec 2 interfaces configurées en
agrégat…uniquement du coté serveur). Lorsque plus de 50 serveurs sont
paramétrés de la sorte (no comment), la CPU des commutateurs s'affole
et trouver la cause d'une erreur aussi bête, par le manque d'un
message simple dans les log, n'est pas facile (essayez de comparer la
sortie de plusieurs «show ethernet-switching table» lancée a quelques
secondes d'intervalles).
- Nous avions un problème matériel interne dans un commutateur qui
«perdait» des trames: Les conséquences étaient des débits très faibles
concernant l'ensemble des flux de la pile qui devait traverser ce
commutateur. Et nous avons (avec le support Juniper) mis énormément de
temps à trouver la cause du problème. Pourtant les compteurs d'une
interface internes (inter PFE) indiquait un nombre élevé d'erreur,
mais aucun message dans les logs.

4. C'est dommage de devoir passer par des règles de filtrage pour
faire du routage inter-VR (j'aurais bien aimé pouvoir simplement
déclarer un VR comme next-hop a une route statique), car lorsque l'on
a beaucoup de subnet cela fait de longue règles de filtrage.

Voila pour mon avis sur l'EX4200.

Olivier

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

Re: [FRnOG] Hardware Appliance Vyatta

[Olivier Cochard-Labbé]

2010/5/5 Radu-Adrian Feurdean r...@ftml.net:

 Tu comptes router quelques dizaines de Gbps avec un minima de filtrage,
 table BGP complete et une cinquantaine (voir centaine) de peers avec un
 PC + Linux + Quagga 

Ca n'est pas justement le but du protocole ForCES (Forwarding and
Control Element Separation protocol) ?

Le PC FreeBSD/Linux + Quagga sera utilisé pour faire le routage (rôle
de CE: Control Element) et il déléguera la commutation à ses cartes
ASIC multi-ports Ethernet (rôle de FE: forwarding element)… L'ensemble
discutant en utilisant le protocole ForCES ?

Reste à voir le coût des cartes ForCES…

Olivier
http://bsdrp.net

ps: Merci à Stéphane Bortzmeyer pour m'avoir fait découvrir ForCES :
http://www.bortzmeyer.org/5812.html
---
Liste de diffusion du FRnOG
http://www.frnog.org/