Re: [FRnOG] [TECH] FFRouting tunning du sysctl.conf

[Michel Moriniaux]

Tu peux regarder la config d'un SONiC:
https://github.com/Azure/sonic-buildimage/blob/master/build_debian.sh

vers la fin du fichier:

## Config sysctl
sudo mkdir -p $FILESYSTEM_ROOT/var/core
sudo augtool --autosave "
set /files/etc/sysctl.conf/kernel.core_pattern '|/usr/bin/coredump-compress
%e %t %p'
set /files/etc/sysctl.conf/kernel.softlockup_panic 1
set /files/etc/sysctl.conf/kernel.panic 10
set /files/etc/sysctl.conf/vm.panic_on_oom 2
set /files/etc/sysctl.conf/fs.suid_dumpable 2
set /files/etc/sysctl.conf/net.ipv4.conf.default.forwarding 1
set /files/etc/sysctl.conf/net.ipv4.conf.all.forwarding 1
set /files/etc/sysctl.conf/net.ipv4.conf.eth0.forwarding 0
set /files/etc/sysctl.conf/net.ipv4.conf.default.arp_accept 0
set /files/etc/sysctl.conf/net.ipv4.conf.default.arp_announce 0
set /files/etc/sysctl.conf/net.ipv4.conf.default.arp_filter 0
set /files/etc/sysctl.conf/net.ipv4.conf.default.arp_notify 0
set /files/etc/sysctl.conf/net.ipv4.conf.default.arp_ignore 0
set /files/etc/sysctl.conf/net.ipv4.conf.all.arp_accept 0
set /files/etc/sysctl.conf/net.ipv4.conf.all.arp_announce 1
set /files/etc/sysctl.conf/net.ipv4.conf.all.arp_filter 0
set /files/etc/sysctl.conf/net.ipv4.conf.all.arp_notify 1
set /files/etc/sysctl.conf/net.ipv4.conf.all.arp_ignore 2
set /files/etc/sysctl.conf/net.ipv4.neigh.default.base_reachable_time_ms
180
set /files/etc/sysctl.conf/net.ipv6.neigh.default.base_reachable_time_ms
180
set /files/etc/sysctl.conf/net.ipv6.conf.default.forwarding 1
set /files/etc/sysctl.conf/net.ipv6.conf.all.forwarding 1
set /files/etc/sysctl.conf/net.ipv6.conf.eth0.forwarding 0
set /files/etc/sysctl.conf/net.ipv6.conf.default.accept_dad 0
set /files/etc/sysctl.conf/net.ipv6.conf.all.accept_dad 0
set /files/etc/sysctl.conf/net.ipv6.conf.eth0.accept_dad 0
set /files/etc/sysctl.conf/net.ipv6.conf.default.keep_addr_on_down 1
set /files/etc/sysctl.conf/net.ipv6.conf.all.keep_addr_on_down 1
set /files/etc/sysctl.conf/net.ipv6.conf.eth0.keep_addr_on_down 1
set /files/etc/sysctl.conf/net.ipv6.conf.eth0.accept_ra_defrtr 0
set /files/etc/sysctl.conf/net.ipv6.conf.eth0.accept_ra 0
set /files/etc/sysctl.conf/net.ipv4.tcp_l3mdev_accept 1
set /files/etc/sysctl.conf/net.ipv4.udp_l3mdev_accept 1
set /files/etc/sysctl.conf/net.core.rmem_max 2097152
set /files/etc/sysctl.conf/net.core.wmem_max 2097152
" -r $FILESYSTEM_ROOT

On Thu, Nov 21, 2019 at 10:59 AM Sébastien 65  wrote:

> Bonjour la liste,
>
> Ces derniers jours il y a eu quelques discussions sur le sujet router
> soft, cela me donne envie de monter une bécane de test afin d'installer la
> dernière version FFR.
>
> Ayant déjà du QUAGGA qui tourne, j'avais procédé à la configuration du
> fichier /etc/sysctl.conf.
>
> Je me rappelle avoir du faire la modification sur le nombre de route max
> et également activer le forwarding et rp_filter  :
>
> net.ipv4.conf.default.rp_filter=0
> net.ipv4.conf.all.rp_filter=0
> net.ipv4.conf.lo.rp_filter=0
> net.ipv4.route.max_size=8388608
>
> net.ipv4.conf.all.forwarding = 1
> net.ipv4.conf.default.forwarding = 1
> net.ipv4.ip_forward=1
>
> net.ipv6.conf.all.forwarding=1
> net.ipv6.conf.default.autoconf=0
> net.ipv6.conf.default.accept_ra=0
> net.ipv6.conf.all.autoconf=0
> net.ipv6.conf.all.accept_ra=0
> net.ipv6.route.max_size=8388608
>
> J'ai du mal à trouver une documentation claire sur la configuration du
> SYSCTL pour BGP+OSPF sur un linux dernière génération (DEBIAN 9-10 ou
> UBUNTU).
> Je viens de tomber sur l'article
> https://adminscriptbank.wordpress.com/2019/04/15/frrouting-debian-ubuntu-install-guide/
>
> Sur
> http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-debian9.html
> la configuration du sysctl est ultra light (uniquement forwarding) !
> Debian 9 — FRR latest documentation<
> http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-debian9.html
> >
> Note. The libyang development packages need to be installed in addition to
> the libyang core package in order to build FRR successfully. Make sure to
> download and install those from the link above alongside the binary
> packages. Depending on your platform, you may also need to install the PCRE
> development package.
> docs.frrouting.org
> Qui a fait mumuse avec le fichier sysctl pour cet usage ?
>
> Sébastien
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Routeur 3 full tables BGP et 10G

[Michel Moriniaux]

Nos routeurs de bordure sont des Arista 7280
des transit et peers on en a plein par pizza-box et ca fonctionne tres bien
c'est a base de Jericho ( ou Qumran ) donc avec de la TCAM externe =>
grosse FIB.
Et c'est pas cher, on avait des vieux chassis ASR ( une bonne douzaine )
pour le prix d'un chassis et demi on a tout remplacé ( et on a gagné 3x
plus de ports 10G et moult ports 100G par box au passage )
Ils sont marketes comme deep buffer, nous on a pris le risque de les
prendre il y a 2 ans pour la TCAM on ne le regrette pas. Ca n'a pas ete
simple au debut mais maintenant le code est bien stable.


On Thu, Sep 26, 2019 at 1:35 PM jehan procaccia INT <
jehan.procac...@int-evry.fr> wrote:

> Bonjour,
>
> j'ai demandé un devis pour upgrader mon cisco ASR 1002x avec 2 ports 10G
> et la capacité de tenir 3 full tables (2 et 1/2 plus exactement car un
> peering France-ix << full table !)
>
> Bilan : 2 cartes SPA 10G + 16 GB Ram + XFP LR + upgrade licence debit >>
> au budget envisagé (plusieurs Dizaines de K€ !)
>
> Dans ces conditions, n'est-il pas plus avantageux de partir sur un
> nouveau routeur nativement multi 10G avec une capacité memoire
> suffisante, mais alors quel modele ?
>
> mon reseau est full cisco, il serait preferable de reprendre un cisco;
> ASR920 ? , 9500 ? sont-ils hors jeux a cause de la memoire pour les full
> tables (BGP v4 et v6 ) , un autre type d'ASR ?
>
> sinon juniper ou autre constructeur fiable  ?
>
> Merci pour vos conseils .
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] SONiC

[Michel Moriniaux]

vous pouvez essayer bcmcmd "show params" | grep chip

donc si effectivement c'est un TDII sans l'appui de dell ca va être
compliqué:
si vous regardez le repo sonic-buildimage vous trouverez l'arborescence
"device"
device va contenir des répertoires organises par constructeur
dans le dossier constructeur (ex: dell ) vous allez trouver les séries par
ex le s6000
dans le dossier d'une série se trouveront:
- les configurations matériel génériques: le fichier de conf pour
lm-sensors, la config pour les leds, des scripts spécifiques pour le reboot
ou l'intaller par ex.
- les "géométries" ce sont des sous dossiers qui vont décrire comment sont
configures les ports ( si vous vous souvenez pendant la prez on a précise
que sur certains ASIC il n'était pas possible de reconfigurer la vitesse ou
le breakout des ports ). ces géométries sont ce qu'on appelle les HWSKU
dans ces dossiers HWSKU (par ex: Force10-S6000-Q32/ un S600 configuré en
32*40G ) vous aller trouver:
- 2 fichiers magiques: port_config.ini et blabla.bcm ces fichier
contiennent tous les registres utilises par SAI et le driver Broadcom pour
configurer l'ASIC. c'est vraiment la config qui définit comment les
pinoches de l'ASIC sont connectées au reste du boitier, seul le
constructeur connaît ça ( vous pouvez aussi vous armer d'un tournevis et
d'une loupe et essayer de suivre les traces... mais je ne le conseille pas)

donc pour faire le portage il va falloir créer un dossier série suivi d'un
dossier hwsku. sans l'aide du constructeur c'est sport.

vous pouvez déjà essayer de lancer un 'show platform summary' et 'show
platform syseeprom' et pourquoi pas un 'sensors' pour voir ce qui est
réellement détecté. pour l'instant a mon avis le sonic ne connaît que le
CPU et les éléments 'génériques'


On Wed, Sep 18, 2019 at 9:46 AM Emmanuel DECAEN 
wrote:

> Bonjour Michel,
>
> Le 18/09/2019 à 17:44, Michel Moriniaux a écrit :
> > c'est une question a poser directement a Dell.
> > Je doute que vous puissiez y arriver cela dit car ce switch est a base
> > de Trident et cet ASIC n'est pas supporté par les couches SAI BRCM de
> > sonic
> > les Asic Broadcom les plus anciens supportés sont les Trident2 et
> > Tomahawk.
>
> Il me semble que nous sommes en Trident 2 sur le S4048.
> Je viens de jeter un oeil sur les HCL de Pica8, Cumulus Linux et
> ipinfusion, à priori, c'est bien indiqué Trident II (BCM56850).
> https://cumulusnetworks.com/products/hardware-compatibility-list/
> https://www.ipinfusion.com/hardware-compatibility-list/
>
> SONiC est installé sur le S4048, si il y a une commande magique dans
> SONiC pour confirmer, je suis preneur :-)
>
> Merci.
> --
> Emmanuel DECAEN
>
>
>

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

Re: [FRnOG] [TECH] SONiC

[Michel Moriniaux]

Bonjour,
c'est une question a poser directement a Dell.
Je doute que vous puissiez y arriver cela dit car ce switch est a base de
Trident et cet ASIC n'est pas supporté par les couches SAI BRCM de sonic
les Asic Broadcom les plus anciens supportés sont les Trident2 et Tomahawk.

Cordialement,
Michel Moriniaux



On Mon, Sep 16, 2019 at 8:43 AM Emmanuel DECAEN 
wrote:

> Bonjour,
>
> Suite à la présentation sympa de CRITEO à FRNOG vendredi, j'ai décidé de
> mettre SONiC sur un switch S4048 (Dell/Force10) pour le tester.
>
> Comme toujours avec ONIE, le changement d'OS est très simple et se fait
> en quelques minutes.
> Par contre, la plate-forme n'est pas dans la Hardware Compatibility
> List, et donc aucun port "front" n'est visible.
>
> Avez-vous eu vent d'un portage (même partiel) pour cet équipement ?
> https://github.com/Azure/SONiC/wiki/Porting-Guide
>
> Merci.
> -- *
> Emmanuel DECAEN*
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] nOS gratos pour ONIE/Trident2+

[Michel Moriniaux]

Hello,
ton switch FS.com resemble furieusement a un accton de la serie as58xx (
dis donc c'est bizarre on retrouve meme ce nombre dans la ref FS)
j'essaierai bien le truc suivant: installe un SONiC ( branche 201904 pour
avoir du code stable ) et met comme HWSKU 'Accton-AS5812-54X' dans la conf
Il est fortement probable que ca fonctionne.

sinon si tu peux poster le contenu de l'eeprom du switch ca peut aider ( il
faudra peut etre faire quelques tweaks ONIE pour le faire fonctionner ):
dans onie:
> onie-sysinfo -a
> onie-syseeprom -l


On Mon, Sep 16, 2019 at 8:55 AM Clément Gineste 
wrote:

> Bonjour à tous,
>
> Vous connaissez des network OS pour switch bare metal avec ONIE qui
> seraient gratos ? Supportant un Trident II+ BCM56854
> Par exemple pour aller sur le FS N5850-48S6Q et éviter de claquer quelques
> k€ en licence cumulus. https://www.fs.com/fr/products/69226.html
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

RE: [FRnOG] [MISC] La fin du monde est proche

[Michel Moriniaux]

On Aug 21, 2017 21:22, "Michel Py" 
wrote:


Ah oui oui ! félicitations, parce que tu étais près de la limite sud,
combien de temps tu as eu la totale ?


Un petit peu plus de 90s, mais même le temps max est toujours trop court



> Bon maintenant plus que 9:30 de route pour rentrer à Palo Alto...

Heureusement que le chat conduit ta bagnole :P


Ouai j'ai ripé sur mon lien...
15h le retour tout de même...

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

RE: [FRnOG] [MISC] La fin du monde est proche

[Michel Moriniaux]

Tiens cadeau, pris tout à l'heure à côté de Prineville
https://www.instagram.com/p/BYEP6mpBXQV/
Bon maintenant plus que 9:30 de route pour rentrer à Palo Alto...

On Aug 21, 2017 10:45, "Michel Py" 
wrote:

> > Francois Demeyer a écrit :
> > Paco vieillit, et ne la Rabanne plus trop de nos jours… 
> Ici on est restés sur notre faim aussi :-D
>
> Tout à fait sérieux :
>
> - Il y eu quelques spécialistes de la cyber-peur qui ont prédit que le
> réseau électrique allait s'effondrer à cause du manque de rendement des
> fermes solaires. On attend toujours; vu l'heure (10 heures du matin ici) la
> demande électrique n'est pas au maximum.
>
> - Hier soir il y a eu pas mal d'arnaques au logement : pas mal de gens ont
> dormi dans leur voiture, après avoir acheté une chambre dans un hôtel qui
> n'existe pas.
>
> - Les geeks regardent au travers d'une disquette au lieu des lunettes
> spéciales. C'est pas aussi clair, mais çà fait plus geeky.
>
> - Ici on est pas dans le noir complet; 78% et il fait bien jour.
>
> - Les zones claires dans l'ombre des arbres sont en forme de croissant.
>
> Ben ici c'est passé il y a 30 minutes maintenant et toujours pas de fin de
> l'Internet.
>
> Michel.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [MISC] RE: switch OS open source ?

[Michel Moriniaux]

Ce serait bien mais on en est loin.

qui se souvient du plaisir d'essayer d'avoir le wifi sur un linux et une
carte a base de broadcom au milieu des années 2000?

A mois que Pascal arrive a convaincre son management d'open sourcer leur
driver Trident/Tomahawk ;-)

2015-11-06 11:03 GMT+01:00 Vincent Bernat :

>  ❦  6 novembre 2015 10:27 +0100, Raphael Mazelier  :
>
> > Je suis intimement persuadé que le marché du switch va se trouver
> > profondément modifié par les switchs "compatible", comme le fut le
> > marché des ordinateurs avec les compatible PC (toute proportion gardé)
> > en son temps.
> >
> > La plupart des constructeurs commencent à proposer des switchs ONIE
> > basé sur du merchant silicon.
> >
> > On devrait se retrouver avec une situation avec d'un coté :
> >
> > - les vendeurs de silicium (marvel, broadcom, intel)
> > - les vendeurs de logiciels (cumulus, pica8, dell, juniper, etc...)
> > - et des solutions intégrés
>
> Pour appuyer ça, côté opensource, les versions récentes de Linux ont
> switchdev qui est un framework pour abstraire les capacités des
> différents switchs à être programmés :
>  https://www.kernel.org/doc/Documentation/networking/switchdev.txt
>
> C'était déjà possible avant, mais c'était différent pour chaque
> constructeur (et souvent en closed source).
> --
> Tell the truth or trump--but get the trick.
> -- Mark Twain, "Pudd'nhead Wilson's Calendar"
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] SDN chez Google

[Michel Moriniaux]

Je vous propose de venir en parler a un meetup que nous organisons ce soir
dans nos locaux 32 rue Blanche a Paris à partir de 17h00
nous couvrirons les sujets des DC L3, l'automatisation et l'urbanisation
industrielle des DC.

L'artisanat dans les réseaux à vécu son temps, à la scale à laquelle nous
opérons nous ne pouvons plus nous permettre de faire de l'artisanat. Qu'on
le veuille ou non le métier de plombier réseau va s'orienter vers le rôle
de dev réseau dans les 5 prochaines années.



2015-06-25 11:47 GMT+02:00 David Ponzone david.ponz...@gmail.com:

 Oui, j’allais un peu dire la même chose.
 Le monde financier aussi a tout passé en algorithmes. On voit le résultat,
 et encore, il nous a pas pété à la gueule.
 Je me pose des questions sur la stabilité long-terme d’un réseau géré par
 du code « intelligent » .

 Le 25 juin 2015 à 11:42, Julien Schafer j.scha...@actilogie.com a écrit
 :

  C'est bien cela qui me fait peur.
 
  Je n'irai pas jusqu'à dire qu'il n'y a jamais de bugs sur du matériel
 réseau, mais franchement ce que j'ai pu vivre et voir chez mes différents
 clients est de la rigolade au regard des problèmes que génèrent les OS,
 BDD, applis mal codées etc
 
  Si c'est pour appliquer le même modèle au monde des réseaux (qui
 globalement tourne bien) je suis pas sur du réel intérêt ;)
 
  -Message d'origine-
  De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la
 part de Michel Moriniaux
  Envoyé : jeudi 25 juin 2015 11:30
  À : Romain De Rasse
  Cc : Olivier Cochard-Labbé; Thomas Barandon; Jérôme Nicolle; Liste FRnoG
  Objet : Re: [FRnOG] [TECH] SDN chez Google
 
  Bonjour,
  ce n'est qu'une question de s'y mettre, il y a énormément d'outils
 libres sur lesquels on peut se baser aujourd'hui.
 
  la CLI est un dinosaure qu'il faut laisser s’éteindre mais
 malheureusement c'est la seule API universellement disponible. (bon,
 peut-être pas vu que beaucoup d'APIs constructeurs ne sont que des wrappers
 XML de CLI)
 
  https://github.com/criteo/netcompare
  netcompare est une des premières briques que nous publions d'un
 framework complet d'automatisation développé chez nous qui nous permet de
 gérer nos DC et WAN programmatiquement, nous allons bientôt publier
 d'autres modules pour équipements a commit non-atomiques qui s'intègrent
 dans Ansible et qui pourront étendre Napalm.
 
  le SDN est un acronyme galvaudé qui comme le cloud veut tout et rien
 dire. Pour nous le SDN ce n'est pas programmer un dataplane mais gérer tous
 les aspects d'un réseau par des algorithmes.
 
 
  2015-06-25 6:59 GMT+02:00 Romain De Rasse rom...@de-rasse.fr:
 
  Bonjour,
 
  Je n'ai pas testé mais il y a l'air d'y avoir des pistes niveau devops
  réseau par exemple :
  https://github.com/spotify/napalm/blob/master/README.md qui vient avec
  un plugin ansible.
 
  RDR
 
  Le 25 juin 2015 06:33:31 GMT+10:00, Olivier Cochard-Labbé 
  oliv...@cochard.me a écrit :
  2015-06-24 21:01 GMT+02:00 Thomas Barandon t.baran...@gmail.com:
 
  Hi,
 
 
  Bref, le SDN c'est bon. Mangez en. De toute façon il faudra
  composer
  avec.
 
 
  ​Juste un «détail» qui me chiffonne avec les solutions SDN du moment:
  Ou
  est passé le principe KISS ?
  Prenons l'exemple de Juniper Contrail (je prends cet exemple
  uniquement car la solution fonctionne pas mal et la doc bien foutue):
 
  cf le white paper CONTRAIL ARCHITECTURE, Figure 1 Contrail system
  overview:
  http://www.juniper.net/us/en/local/pdf/whitepapers/2000535-en.pdf
 
  Donc sur ce schéma d'introduction simplifié (car réduire OpenStack à
  un seul bloc, j'appelle cela de la simplification) je découvre un
  joli mélange
  de:
  - XMPP, pour que routeur fasse des échanges multimédias ou du chat
  entre eux et le contrôleur ? :-)
  - BGP, normal c'est du réseau
  - Netconf, tiens… enfin!
  - API Rest, car c'est la mode de tout encapsuler dans HTTP… quelle
  connerie d'avoir prévus 65535 ports pour TCP, alors qu'il en
  suffisait de trois:
  53,
  80 et 443.
  - Une couche d'overlay MPLS over GRE/UDP ou d'overlay VXLAN…
  - Pourquoi absolument du MPLS over quelques chose et pas le faire
  nativement ?
  - VXLAN: quel intérêt en 2015, dans un monde IP, d'ajouter une
  couche supplémentaire pour maintenir l'existence de domaines de
  broadcast Ethernet entre serveurs ?
  - hyperviseur
  - Comment garantir le jitter minimum lorsque l'on doit traverser
  plusieurs hyperviseurs ? (chainage de VMs)
 
  Et le pire: C'est que ça fonctionne.
  Par contre le jour il y aura un problème: Qui est capable de
  maitriser et comprendre l'ensemble des technos mis en œuvre dans une
  telle solution ?
  ​
 
  Cela me donne l'impression que la révolution SDN va vraiment trop vite.
  J'aurai aimé une étape intermédiaire plus simple avant, comme par
  exemple juste trouver une solution de déploiement automatisée de
  configuration d'un réseau hétérogène. Netconf, après des années de
  réflexions et je ne sais plus combien de RFC n'est toujours pas
  utilisable à grande échelle

Re: [FRnOG] [TECH] SDN chez Google

[Michel Moriniaux]

Bonjour,
ce n'est qu'une question de s'y mettre, il y a énormément d'outils libres
sur lesquels on peut se baser aujourd'hui.

la CLI est un dinosaure qu'il faut laisser s’éteindre mais malheureusement
c'est la seule API universellement disponible. (bon, peut-être pas vu que
beaucoup d'APIs constructeurs ne sont que des wrappers XML de CLI)

https://github.com/criteo/netcompare
netcompare est une des premières briques que nous publions d'un framework
complet d'automatisation développé chez nous qui nous permet de gérer nos
DC et WAN programmatiquement, nous allons bientôt publier d'autres modules
pour équipements a commit non-atomiques qui s'intègrent dans Ansible et qui
pourront étendre Napalm.

le SDN est un acronyme galvaudé qui comme le cloud veut tout et rien
dire. Pour nous le SDN ce n'est pas programmer un dataplane mais gérer tous
les aspects d'un réseau par des algorithmes.


2015-06-25 6:59 GMT+02:00 Romain De Rasse rom...@de-rasse.fr:

 Bonjour,

 Je n'ai pas testé mais il y a l'air d'y avoir des pistes niveau devops
 réseau par exemple :
 https://github.com/spotify/napalm/blob/master/README.md qui vient avec un
 plugin ansible.

 RDR

 Le 25 juin 2015 06:33:31 GMT+10:00, Olivier Cochard-Labbé 
 oliv...@cochard.me a écrit :
 2015-06-24 21:01 GMT+02:00 Thomas Barandon t.baran...@gmail.com:
 
  Hi,
 
 
  Bref, le SDN c'est bon. Mangez en. De toute façon il faudra composer
 avec.
 
 
 ​Juste un «détail» qui me chiffonne avec les solutions SDN du moment:
 Ou
 est passé le principe KISS ?
 Prenons l'exemple de Juniper Contrail (je prends cet exemple uniquement
 car
 la solution fonctionne pas mal et la doc bien foutue):
 
 cf le white paper CONTRAIL ARCHITECTURE, Figure 1 Contrail system
 overview:
 http://www.juniper.net/us/en/local/pdf/whitepapers/2000535-en.pdf
 
 Donc sur ce schéma d'introduction simplifié (car réduire OpenStack à un
 seul bloc, j'appelle cela de la simplification) je découvre un joli
 mélange
 de:
 - XMPP, pour que routeur fasse des échanges multimédias ou du chat
 entre
 eux et le contrôleur ? :-)
 - BGP, normal c'est du réseau
 - Netconf, tiens… enfin!
 - API Rest, car c'est la mode de tout encapsuler dans HTTP… quelle
 connerie
 d'avoir prévus 65535 ports pour TCP, alors qu'il en suffisait de trois:
 53,
 80 et 443.
 - Une couche d'overlay MPLS over GRE/UDP ou d'overlay VXLAN…
   - Pourquoi absolument du MPLS over quelques chose et pas le faire
 nativement ?
   - VXLAN: quel intérêt en 2015, dans un monde IP, d'ajouter une couche
 supplémentaire pour maintenir l'existence de domaines de broadcast
 Ethernet
 entre serveurs ?
 - hyperviseur
   - Comment garantir le jitter minimum lorsque l'on doit traverser
 plusieurs hyperviseurs ? (chainage de VMs)
 
 Et le pire: C'est que ça fonctionne.
 Par contre le jour il y aura un problème: Qui est capable de maitriser
 et
 comprendre l'ensemble des technos mis en œuvre dans une telle solution
 ?
 ​
 
 Cela me donne l'impression que la révolution SDN va vraiment trop vite.
 J'aurai aimé une étape intermédiaire plus simple avant, comme par
 exemple
 juste trouver une solution de déploiement automatisée de configuration
 d'un
 réseau hétérogène. Netconf, après des années de réflexions et je ne
 sais
 plus combien de RFC n'est toujours pas utilisable à grande échelle dans
 un
 environnement vraiment multi-constructeurs.
 Le monde de l'IT n'ont pas perdus leur temps en discussion: Ils
 disposent
 désormais de plusieurs solutions éprouvées qui leur permet de gérer
 leur
 énormes parc de serveurs (ansible, puppet, chef, salt, etc...). Et
 pendant
 ce temps là, nous au réseau: Que dalle! Pourtant un serveur est
 autrement
 plus complexe à gérer qu'un simple switch/routeur.
 Cela nous aurai permis de commencer tranquillement notre migration en
 mode
 devops au lieu de nous prendre la grosse claque SDN d'un coup.
 
 My two cents,
 
 Olivier
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/

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


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

Re: [FRnOG] [TECH] Switch SFP

[Michel Moriniaux]

mouais... un WS-C3750X-24S-S c'est $20k prix liste, on sait tous ce que
prix liste veut dire

2015-03-30 23:05 GMT+02:00 Jérôme Nicolle jer...@ceriz.fr:



 Le 30/03/2015 21:18, Michel Moriniaux a écrit :
  Huawei 5720

 Le S5720-32C-HI-24S-AC c'est $8k list price. Pas vu de dispo en broke ou
 autre à tarif décent.

 @+

 --
 Jérôme Nicolle
 06 19 31 27 14


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


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

Re: [FRnOG] [TECH] Switch SFP

[Michel Moriniaux]

Avec réponse a la liste
On Mar 30, 2015 9:17 PM, Michel Moriniaux moriniaux.li...@gmail.com
wrote:

 Huawei 5720
 28 ports sfp 1g + 4 combo rj45 + 4x10G sfp+.

 MM


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

Re: [FRnOG] [TECH] Demande contact NC

[Michel Moriniaux]

C'est un bridge où le routeur récupère une IP via DHCP.
LaBox en mode bridge ça fait longtemps que j'ai laissé tomber: entre
l'impossibilité de le faire fonctionner correctement, la perte de
fonctionnalités VOD/TV, le mode bridge qui disparaît au reboot, j'ai
préféré demander un modem netgear à part à NC, depuis aucun problème.


2014-12-08 10:32 GMT+01:00 Pierre Colombier pcdw...@pcdwarf.net:

 Je voudrais que tu qualifies ce que tu entends par bridge
 C'est du bridge façon freebox où tu choppe l'ip publique directement en
 ethernet ?
 ou bien ta box n'est vraiment plus qu'un modem et tu fait gérer la
 connexion PPPoE à ton routeur ?

 Quoiqu'il en soit, quelle est la MTU effective de la connexion ? 1500 ?

 essaie de voir si ça passe mieux en forçant à 1400 avec une règle comme ça
 sur ton routeur.

 iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1400

 et si ça résout le problème, remonte progressivement jusqu'à la valeur
 maximale où ça passe bien. (je parierai bien sur 1492).






 Le 07/12/2014 16:24, Fabrice Hanounou a écrit :

 Bonjour,

 Non mon problème est plus grave :( voici l'explication rapide :
 Le but de la manoeuvre étant de mettre en évidence le mauvais
 fonctionnement de la box depuis le dernier FW (coïncidence avec la nouvelle
 offre 400mb) lorsqu'un élément réseau actif supplémentaire est implémenté
 sur le lan.
 Petit lab avec box remise à zéro, tous les tests effectués via RJ45 1Gb.
 - box seule mode routeur avec un PC Windows == pas de perte de flux
 - box seule mode bridge avec un routeur et un PC Windows derrière le
 routeur == perte de flux aléatoire dans le temps pas immédiate
 - box seule mode routeur avec un routeur et un PC Windows derrière le
 routeur == perte de flux aléatoire dans le temps pas immédiate
 Ce que cite comme perte de flux, est mis en évidence via un tcpdump sur
 le routeur lors d'un simple téléchargement d'un iso via le PC Windows sur
 un serveur web.
 En effet le téléchargement ne s'interrompt pas mais plus aucun paquets ne
 passent après une série de paquets portant un flag reset venant de mon PC.
 Je préfère préciser que j'ai bien entendu essayé avec plusieurs PC
 (Windows ou Linux), plusieurs navigateurs, plusieurs types routeurs, et
 même activé le jumbo frame car je désespère de trouver une réponse.
 Ce que j'ai trouvé quand même très étrange c'est le comportement du
 bridge lors d'un trace route qui démontre que les paquets transitent par la
 box avec son ip locale.

 Suite à ces tests j'ai donc fait comme 'le bon père de famille' j'utilisé
 ma box seule on mode routeur, mis mes PC derrière et la box s'occupe du
 routage etc...
 Ma conclusion est que je ne peux plus utiliser la box avec un quelconque
 équipement réseau actif et ce cela vient probablement d'un nombre de sauts
 de paquets limités.

 Je ne sais pas si certains clients NC sont dans le même cas que moi, il
 est possible aussi que certains le soient mais ne s'en sont pas rendus
 compte car ce phénomène est transparent lorsqu'on surf uniquement.

 Merci, bon dimanche.



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


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

Re: [FRnOG] [MISC] Je suis rassuré

[Michel Moriniaux]

ne pas oublier que c'est la traditionnelle Shark Week estivale de
Discovery Channel.
en cette période, énormément de press releases surfent sur le
sensationnalisme du requin...



2014-08-19 10:40 GMT+02:00 Alexis Lameire alexis.lame...@gmail.com:

 d'ailleurs pour éviter ça, en plus d'augmenter la résistance des
 câbles on les enfuis sous terre a l'aide d'un robot sous marin

 My 2 cents
 Alexis Lameire

 Le 19 août 2014 10:25, Stephane Bortzmeyer bortzme...@nic.fr a écrit :
  Ce n'est pas la faute des requins !
 
 
 http://www.lefigaro.fr/secteur/high-tech/2014/08/19/01007-20140819ARTFIG00027-le-requin-une-menace-pour-internet-tres-exageree.php
 
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/


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


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

Re: [FRnOG] [MISC] Philippe Bourcier, la fibre au bureau

[Michel Moriniaux]

rhoo, c'est une carte ATM-25 en Optic over Copper.



2014-08-18 15:34 GMT+02:00 Pascal Rullier pas...@rullier.net:

 Bonjour,

 Certains n'ont peut être pas vu l'article dans le monde :

 http://www.lemonde.fr/pixels/article/2014/08/12/philippe-
 bourcier-la-fibre-au-bureau_4470193_4408996.html

 Philippe: coté poste de travail, tu as mis quelle carte optique ?

 Cdlt,

 --
 Pascal Rullier


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


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

Re: [FRnOG] [TECH] Gamme Juniper ?

[Michel Moriniaux]

2014-03-05 17:20 GMT+01:00 Frédéric GANDER fgan...@corp.free.fr:

 un pc avec un quagga ca devrait le fait non ?
 ok ok je sors


Mais non sors pas ;-) c'est ce que j'ai fait il y a 3 ans avec un MX80 et
un CER-RT. un script injectait des routes par palier de 250K dans quagga
 qui feedait ensuite le MX80 et le CER-RT.
comme c'est le sujet lequel a abandonné le premier? dans le mille, suivi du
quagga, je ne suis pas arrivé aux limites du CER (sur ce test là)
On a fini par choisir le CER comme border avec ports transit 1G, 4
full-view et plus de 100 peers, 3 minutes le reboot avec full montée.

comme le 7206 le fut en son temps le MX80 est une super boite, ça dépend de
ce que l'on veut lui faire faire.

MM

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

Re: [FRnOG] [TECH] Switch silencieux

[Michel Moriniaux]

bah justement: le Brocade ICX6430-24

MM


2014/1/9 Christophe Baegert c.baegert-lis...@lixium.fr

 Le 09/01/2014 10:40, Dominique Rousseau a écrit :
  Pour du switch desktop c'est suffisant, je trouve.

 Incroyable, 3 personnes le même jour sur FRNOG pour dire du bien d'un
 non-Cisco-non-Brocade-non-Juniper ! Que se passe-t-il ?

 Cordialement,

 Christophe


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


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

Re: [FRnOG] [TECH] Cablage de baies : longueurs sur mesure ?

[Michel Moriniaux]

Vendredi,
ça ne resoud pas son problème dans l'intégralité, une fois qu'il a fait ses
nattes avec le peigne il faut quand même qu’ il appelle sa coiffeuse pour
lui faire un joli dégradé

ok je sors, c'était une longue semaine
MM


2013/11/21 Sylvain Vallerot sylv...@gixe.net



 On 07/11/2013 20:07, Michel Moriniaux wrote:

 Bonjour Jerome,
 je ne connais pas de cables bundlés en 24 mais ce petit outil fait des
 miracles pour réaliser ce que tu veux:
 http://www.ebay.com/itm/AcomTools-CABLE-COMB-Category-
 Cable-Wire-Organizer-/330740751341
 ou alors le Panduit:
 http://www.cableorganizer.com/panduit/cable-organizer-tool/


 Il me semble que ça ne répond pas à la problématique de Jérôme, qui
 est de disposer d'un trunk de câbles par pas de 1u pour desservir toutes
 les machines d'un rack (depuis le switch en haut typiquement) avec juste
 la longueur nécessaire.

 Jérôme il me semble que ton approche n'est pas tout à fait exacte, parce
 que les câbles arrivant sur les ports 1, 23 (ou 47) de ton switch ne vont
 pas avoir 22*4,5 ou 46*4,5 cm de différence de longueur.

 Malheureusement ça complexifie pas mal le question et ça rend la gamme
 de produits assez compliquée et assez vaste, peut-être de quoi justifier
 qu'elle n'existe pas parce qu'il faudrait la décliner
  - en couleur
  - en type de câble
  - en type de prise (et ça peut faire pas mal de combinaisons)
  - en pas de distribution
  - selon la géométrie du switch

 Et aussi en longueur (j'ai un client qui met 3 switches en top of rack
 (LAN, WAN et IPMI) donc il y a 1u de décallage pour chacun, et la prise
 IPMI est parfois complètement ailleurs sur la machine (genre sur les
 PE 1950).

 Tout ça pour un trunk qui sera foutu à la moindre casse (prise RJ,
 connecteur LC ou fibre) donc il faut qu'il soit désolidarisable pour
 remplacer 1 lien sur les N, sans te retrouver avec un paquet de nouilles
 sur les godasses.

 Et enfin ça ne peut convenir que sur des racks parfaitement homogènes
 ce qui réduit le marché.

 Bref, ça me semble complexe même si le concept semble simple.



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


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

Re: [FRnOG] [MISC] Comment rangez-vous vos câbles réseaux ?

[Michel Moriniaux]

Pour des photos:

http://www.reddit.com/r/cableporn

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

Re: [FRnOG] [TECH] Cablage de baies : longueurs sur mesure ?

[Michel Moriniaux]

Bonjour Jerome,
je ne connais pas de cables bundlés en 24 mais ce petit outil fait des
miracles pour réaliser ce que tu veux:
http://www.ebay.com/itm/AcomTools-CABLE-COMB-Category-Cable-Wire-Organizer-/330740751341
ou alors le Panduit:
http://www.cableorganizer.com/panduit/cable-organizer-tool/

MM


2013/11/1 Jérôme Nicolle jer...@ceriz.fr

 Plop,

 Je cherche le bon compromis entre souplesse et compacité du câblage en
 arrière de baies.

 Pour l'elec, pas de problème, un bon PDU permet d'avoir des prises sur
 toute la hauteur de la baie, de part et d'autre, et donc de n'utiliser
 que des câbles de 3 longueurs différentes.

 Coté réseau par contre ça se complique. Outre le fait que peu de switchs
 sont en reverse-airflow, je ne trouve pas de troncs pré-assemblés avec
 des câbles de longueur différentes, par pas de 4.5 ou 9cm typiquement.

 Je cherche donc des bundle de câbles, en cat5e ou cat6, par lot de 12
 (pour des 2U) ou 24 (pour des 1U), pour connecter tous les serveurs au
 switch Middle of Rack le plus rapidement possible. Ou, à défaut, tout
 truc et astuce pour préparer le câblage des baies en amont.

 Des idées ? Liens ? Fourgues ?

 Merci !

 P.S. : suggestion aux vendeurs de PDU : intégrer le patching passif
 dedans serait quand même vachement pratique. Des pieuvres avec
 connecteurs compacts pour chopper le switch d'un coté (plutôt avec la
 longueur pour le récupérer en front), et des ports distribués sur toute
 la hauteur...). Sous forme d'un bandeau optionnel à accoler à celui de
 distribution d'énergie, ce serait juste parfait :)


 --
 Jérôme Nicolle
 06 19 31 27 14


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


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

Re: [FRnOG] [TECH] BGP software

[Michel Moriniaux]

Comme Radu et Jerôme:

un script qui tourne très souvent pour filtrer les agrégats déduits de
http://www.cidr-report.org/as2.0/aggr.html et pondre une prefix-list qui va
dans les border vers le mesh interne, la difficulté est de trouver le point
d’équilibre entre une table suffisamment filtrée et une prefix-list courte.
Ca a ses limites (pas fait par rapport à la vue locale) mais ça permet de
garder une table assez complète sans recours à une default (qui vient quand
même en plus pour sécuriser au cas d'une disparition de supernet entre 2
updates de la pf). Une agrégation minimale de 50 routes rend une
prefix-list de 219 lignes et une table réduite de 3 entrées ( dernier
run de ce matin)

Puis évolution du truc: je me suis mis a python pour coder un agrégateur
pour exaBGP: crée des agrégats vers le full mesh interne en fonction des
updates reçues des border, mais je ne lui fais pas (encore) confiance pour
la prod a cause de quelques coffin corner cases et de mon python-fu. Je
vois qu'on en est au même point ;-)

Et pour les clients qui veulent une full view des CER-RT qui peerent
directement avec les Border (CER-RT) via des LSP, qui est une première
étape si on évolue vers un BGP-free core.


 Si quelqu'un veut écrire qque chose de ce type, je suis prêt a' aider
l'intégration.
 https://github.com/Thomas-Mangin/exabgp

On en cause dans 2 semaines, de vive voix avec quelques binches en main ?

monter un workshop sur la question pourrait finir par une prez au FRNOG21

MM




2013/9/2 Jérôme Nicolle jer...@ceriz.fr

 Salut Thomas,

 Le 02/09/2013 19:16, Thomas Mangin a écrit :
  Ces logiciels magiques existent mais sont toujours propriétaires.

 Oui, et vu la criticité de la manip je ne peux pas leur faire confiance...


  Certains utilisent même ExaBGP comme backend BGP pour ce travail, avec
 des manipulations parfois très complexes : d'ailleurs certaines de ces
 solutions me font un peu très peur - mais ce n'est pas grave : pas mon
 réseau.
  Il y a des gens qui me font trop confiance - et non ce n'est pas ma
 femme :-D

 C'est bien pour ça que je me sers d'ExaBGP pour mes tests :p

 Ton ilem est bonne pour ça, quoique j'ai pas encore eu (pris?) e temps
 de te faire un feedback su mes dernières trouvailles. Mais promis, je
 ferais ça d'ici la fin de l'année.

 Une fois l'automate implémenté, i ne reste que le séquençage des
 agrégation et la structure de données permettant de modéliser les
 extrémités de ton réseau (ASBR). Avec ça en tête, c'est pas trop
 complexe à implémenter, mais pour l'instant je suis resté en pur python,
 donc c'est pas réactif du tout.

  Si quelqu'un veut écrire qque chose de ce type, je suis prêt a' aider
 l'intégration.
  https://github.com/Thomas-Mangin/exabgp

 On en cause dans 2 semaines, de vive voix avec quelques binches en main ?

 @+

 --
 Jérôme Nicolle
 06 19 31 27 14


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


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

Re: [FRnOG] [TECH] Un routeur de cœur de réseau peut-il espionner le trafic ?

[Michel Moriniaux]

 EM versus fibre, il y a une sacree difference.
pas tant que ça quand tu as accès au media, il y a des techniques
partiellement invasives qui n'alterent pas le signal.

Pareil, ecouter un cable tout entier (plusieurs 100 de Gbps) pour sortir
des morceaux bien choisis. hmmm il y a des meilleures approches.

certes mais la on traite le cas specifique où le cable est dans des eaux
étrangères et où n'a pas accès.

Ne pas oublier, comme l'a dit Michel Py plus haut dans le thread, la taille
de poches des gouvernements.
pas difficile de submerger un container rempli de disques et le poser a
coté de la fibre.

d'ailleurs je viens de voir un truc que font les Arista et peut etre
d'autres: il y a un FPGA embarqué user-programmable pour descendre des
fonctions applicatives sur le switch, dans l'exemple c'etait un module de
HFT.
pourquoi ne pas imaginer un parseur wirerate?




2013/6/26 Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net

 On Wed, Jun 26, 2013, at 15:30, Michel Moriniaux wrote:
  http://en.wikipedia.org/wiki/Operation_Ivy_Bells
 
  pas de la fibre a l’époque, mais les techniques sont les mêmes, voir ci
  dessus le Jimmy Carter

 EM versus fibre, il y a une sacree difference.
 Pareil, ecouter un cable tout entier (plusieurs 100 de Gbps) pour sortir
 des morceaux bien choisis. hmmm il y a des meilleures approches.


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

Re: [FRnOG] [TECH] Un routeur de cœur de réseau peut-il espionner le trafic ?

[Michel Moriniaux]

http://en.wikipedia.org/wiki/Operation_Ivy_Bells

pas de la fibre a l’époque, mais les techniques sont les mêmes, voir ci
dessus le Jimmy Carter




2013/6/26 Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net

 On Wed, Jun 26, 2013, at 14:02, Kavé Salamatian wrote:

  Non aucune acrobatie politique. J'ai vu des splitters sur le point de
  connexion de Fujairah du SEA-ME-WE 4. Il y'en a surement aux autres
  points de connexion (Arabie Saoudite, Egypte, Thailand, etc….

 Et a Fujairah ils peuvent intercepter le traffic entre Europe et
 Hong-Kong ?
 Quand a l'interceptions sans impunite aux extremites, J'aimerais bien
 savoir comment les services secret US arrivent a utiliser le splitter a
 Penmarch ou a Hong-Kong

 J'accepte bien que c'est techniquement possible dans certains cas
 (valide par la justice, ou des interets communs de celui qui veut
 ecouter et de celui qui a la jurisdiction sur la landing-station), mais
 que ca peut etre fait en secret, j'ai quand-meme des fortes doutes.
 Il faut aussi se poser la question si ce n'est pas plus simle d'ecouter
 beaucoup plus pres d'une des destinations, sans se compliquer a
 intercepter les comms sur la partie long-distance.


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


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

Re: [FRnOG] [ALERT] Adresses de support Proxad efficientes ?

[Michel Moriniaux]

on est Vendredi, nous aussi on veut jouer!

au pire ça reveillera l'utilisateur de la freebox qui fera l'ouverture de
ticket pour vous!



2013/6/21 Fleuriot Damien m...@my.gd


 On Jun 21, 2013, at 4:28 PM, Vincent LOUPIEN 
 vincent.loup...@upmf-grenoble.fr wrote:

  Bonjour à tous,
 
  Nous subissons depuis quelques semaines des tentatives de mise à jour de
 nos zones DNS directes et inverses sur les serveurs esclaves (secondaires)
 depuis l'adresse d'une Freebox. Nous avons écrit au support technique
 ab...@free.fr ainsi qu'a hostmas...@proxad.net et ab...@proxad.net pour
 nous plaindre de ce comportement la, sans réponse de leurs parts.
 
  Connaissez-vous d'autres adresses web ou de courriels du groupe Proxad
 qui nous permettraient de faire remonter plus efficacement cette plainte ?
  Et sinon, techniquement ou administrativement, mise à part des filtrages
 IP, que nous conseilleriez-vous ?


 D'envoyer 50mbs d'UDP à l'autre tarlouze planqué derrière sa freebox.

 50mbs c'est suffisamment petit pour ne coûter d'argent ni à vous ni à
 free, et ça fait quand même tomber l'autre petit malin.


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


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

Re: [FRnOG] [TECH] Switch 10G pour cohabitation 10G/1G

[Michel Moriniaux]

Bonjour,
qqun a-t'il déjà évalué des Mellanox? (HS car pas de support 1G)
le sx1016 (64 ports 10G) par ex?
http://www.mellanox.com/page/ethernet_switch_overview


2013/5/14 Raphael Maunier - Jaguar Network 
raphael.maun...@jaguar-network.com

 Hello Romain,

 J'avais vu ces équipements il y a 3 ou 4 ans ( juste avant que Juniper ne
 sorte la gamme EX ) pour la partie MPLS.

 Sur le papier ça avait l'air pas mal et les mecs avec qui j'en avais parlé
 en était très content.

 Apres, la suite …. J'aime bien les EX :)

 Cordialement,
 --
 Raphael MAUNIER
 Jaguar Network France

  On May 14, 2013, at 11:30 AM, Romain DEGEZ romain.de...@smartjog.com
 wrote:

  On 05/14/2013 09:20 AM, Moncef ZID wrote:
  Bonjour
 
  Les équipements Dowslake supportent  bien IPV6 :)  , je cherche l'info
 et je
  la poste
 
  Merci
 
  Jamais entendu parler de ces trucs avant et 2 minutes de googling plus
 loin je trouve assez peu rassurant le manque de visibilité de ces
 équipements... Absolument personne n'en parle :-)
 
  Curieux de savoir quel OS ils utilisent.
  Ils ont complètement re-développé une stack logicielle complète
 (OSPF/BGP/MPLS/EAPS) eux-même ?
 
  --
  RD
 
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 


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


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

Re: [FRnOG] [TECH] Switch 10G pour cohabitation 10G/1G

[Michel Moriniaux]

bah justement, la question est pour savoir si il faut prévoir le Maalox
avec :-)


2013/5/14 Raphael Maunier - Jaguar Network 
raphael.maun...@jaguar-network.com

 Pour rester HS et alimenter le troll : Acheter un switch qui a un nom de
 médoc, c'est un peu étrange :)

 Cordialement,
 --
 Raphael MAUNIER
 Jaguar Network France

  On May 14, 2013, at 4:52 PM, Michel Moriniaux moriniaux.li...@gmail.com
 wrote:

  Bonjour,
  qqun a-t'il déjà évalué des Mellanox? (HS car pas de support 1G)
  le sx1016 (64 ports 10G) par ex?
  http://www.mellanox.com/page/ethernet_switch_overview
 
 
  2013/5/14 Raphael Maunier - Jaguar Network 
  raphael.maun...@jaguar-network.com
 
  Hello Romain,
 
  J'avais vu ces équipements il y a 3 ou 4 ans ( juste avant que Juniper
 ne
  sorte la gamme EX ) pour la partie MPLS.
 
  Sur le papier ça avait l'air pas mal et les mecs avec qui j'en avais
 parlé
  en était très content.
 
  Apres, la suite …. J'aime bien les EX :)
 
  Cordialement,
  --
  Raphael MAUNIER
  Jaguar Network France
 
  On May 14, 2013, at 11:30 AM, Romain DEGEZ romain.de...@smartjog.com
  wrote:
 
  On 05/14/2013 09:20 AM, Moncef ZID wrote:
  Bonjour
 
  Les équipements Dowslake supportent  bien IPV6 :)  , je cherche l'info
  et je
  la poste
 
  Merci
 
  Jamais entendu parler de ces trucs avant et 2 minutes de googling
 plus
  loin je trouve assez peu rassurant le manque de visibilité de ces
  équipements... Absolument personne n'en parle :-)
 
  Curieux de savoir quel OS ils utilisent.
  Ils ont complètement re-développé une stack logicielle complète
  (OSPF/BGP/MPLS/EAPS) eux-même ?
 
  --
  RD
 
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 
 
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 


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


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

Re: [FRnOG] [TECH] Routage/Route leaking entre VRF et la global table

[Michel Moriniaux]

Hello Raph,
 bonne année!
on avait essayé ça en 2007 pour qui tu sais sans succes. Je ne sais plus
comment et si je l'avais fait fonctionner mais ce n'etait pas satisfaisant
pour du mass rollout.

Ca revient toujours au meme pour ce genre de choses: boucle externe d'un
port a un autre, sur le 887 ça te bouffe 50% des ports et comme ce sont des
ports switchés il doit y avoir une difficulté supplémentaire (genre un
couple de ports par vrf a importer etc...).

il y a peut etre des nouvelles fonctionnalités chez chicco la dessus, ça ne
va pas t'aider mais ça existe sur brocade depuis la 5.4:

essaye de chercher si tu as une commande du genre
vrf toto
rd 1:1
 import routes vrf default-vrf route-map tata
!



++
MM



2013/1/9 Raphael Mazelier r...@futomaki.net

 Bonjour,

 Une petite question technique pour changer. (Un truc qui me rend fou)

 J'ai un cpe cisco 887 avec une vrf dessus. J'aurai besoin de pouvoir
 router des paquets entre un vlan qui est dans la global et un vlan qui est
 dans la VRF.
 J'aimerais éviter de terminer avec du MPBGP et deux VRF (d'autant que ça
 risque d’être compliqué de bouger toute mes interfaces sans me couper la
 main).
 En gros je voudrais juste deux routes, une (GLB)subnetB - VRF_B et
 (VRF_B) subnetA - GLB. Sauf que cela ne semble pas possible simplement.

 J'ai terminé avec une conf chelou du style :

 ip vrf VPN
 rd 1:1
 !
 interface Loopback1
 ip vrf receive VPN
 ip address 1.1.1.1 255.255.255.255
 ip policy route-map TO_VPN
 !
 interface Vlan10
 ip address 192.168.31.1 255.255.255.0
 !
 interface Vlan20
 ip vrf forwarding VPN
 ip address 172.20.1.1 255.255.255.0
 !
 ip route 172.20.1.0 255.255.255.0 Loopback1
 ip route vrf INTV_VPN 192.168.31.0 255.255.255.0 Loopback1 1.1.1.1
 !
 route-map TO_VPN permit 10
 set vrf VPN

 Mon problème c'est que cela marche dans un sens a savoir :

 CPE1# ping 172.20.1.1
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 172.20.1.1, timeout is 2 seconds:
 !
 Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/4 ms

 mais pas dans l'autre :

 CPE1# ping vrf VPN 192.168.31.1
 Type escape sequence to abort.
 Sending 5, 100-byte ICMP Echos to 192.168.31.1, timeout is 2 seconds:
 

 Je suis preneur de tout conseil.

 Cdt,

 --
 Raphaël Mazelier



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


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

Re: [FRnOG] [TECH] Redondance sur chemins optiques

[Michel Moriniaux]

Ce serait pas plutot un ROADM que tu cherches?
adva, infinera etc.
2012/10/30 Gabriel Barazer gabr...@oxeva.fr

 En effet, je cherche à faire de la redondance uniquement au niveau fibre
 optique et pas au-dessus, afin de limiter la complexité. Sinon ça revient à
 déployer de la redondance L2 sur N x le nombre de canaux WDM, ce qui est
 précisément ce que je veux éviter :-). D'autre part, il y aura au moins un
 circuit sur lequel je n'aurais pas la main sur le niveau 2.

 Sinon, je crois que faire du LACP et autres sur des liens moyenne distance
 avec des latences qui peuvent être potentiellement différentes, ce n'est
 pas très pratique.

 Ça apporte en tout cas de l'eau à mon moulin, merci !

 Gabriel

 From: Surya ARBY [mailto:arbysu...@yahoo.fr]
 Sent: Tuesday, October 30, 2012 4:13 PM
 To: Jérémy Martin
 Cc: Gabriel Barazer; frnog@frnog.org
 Subject: Re: [FRnOG] [TECH] Redondance sur chemins optiques

 Le truc c'est qu'il a des mux/demux; je suis parti du postulat que
 peut-être qu'un jour il voudra faire passer autre chose que de l'ethernet
 ou avoir des topologies complexes (anneau ?)

 cdlt,

 Surya

 
  De : Jérémy Martin li...@freeheberg.com
 À : Surya ARBY arbysu...@yahoo.fr
 Cc : Gabriel Barazer gabr...@oxeva.fr; frnog@frnog.org 
 frnog@frnog.org
 Envoyé le : Mardi 30 octobre 2012 16h09
 Objet : Re: [FRnOG] [TECH] Redondance sur chemins optiques

 C'est peut être une vision très simpliste de ma part, mais on peut pas
 créer un LAG avec les deux fibres entre les deux POP ?

 'fin sauf si tu veux redonder aussi les switch (ça paraitrait logique).
 Mais si la problématique est juste la FO en elle même, ça me parait
 pertinent. Ou alors je suis à coté de la plaque ?


 Cordialement,
 Jérémy Martin

 Le 30/10/2012 15:34, Surya ARBY a écrit :
  Bonjour;
 
  Passe par de la protection du circuit optique matérielle si tu peux (un
 peu à la sauce SDH) tu peux avoir des temps de bascule de l'ordre de 50 ms
 de mémoire; sinon on laisse les protocoles supérieurs (L2) gérer la panne;
 en général la problématique étant de savoir si l'état réel du lien est bien
 reporté au équipements de chaque côté (signal down) ce qui est le cas si
 tous tes liens sont directs ou passent par des mux/demux passifs.
 
 
  cdlt,
 
  Surya
 
 
  
   De : Gabriel Barazer gabr...@oxeva.fr
  À : frnog@frnog.org
  Envoyé le : Mardi 30 octobre 2012 15h25
  Objet : [FRnOG] [TECH] Redondance sur chemins optiques
 
  Bonjour à tous,
 
  J'ai différentes configurations sur des fibres noires distantes
 d'environ 20km que je souhaiterais passer en double adduction. Quelles sont
 à votre avis les solutions optimales qui permettent d'y arriver ? J'ai sur
 ces chemins soit de l'ethernet sur WDM (avec mux/demux passifs) soit de
 l'ethernet direct.
 
  J'ai pensé a de l'encapsulation par-dessus du routage L3 et faire la
 redondance à ce niveau, mais ça me parait ajouter beaucoup trop de
 complexité alors que la problématique est très simple.
 
  Il me semble aussi qu'il existe des switches optiques permettant
 d'utiliser un chemin lumineux disponible et d'utiliser l'autre en cas de
 coup de pelleteuse sur le premier. Que pensez-vous de ces solutions, et
 avez-vous des préférences ?
 
  Merci !
 
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 


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



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


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

Re: [FRnOG] Re: [TECH] augmentation table de routage BGP et gestion de celle-ci sur les routeurs

[Michel Moriniaux]

en attendant de prendre le temps de lire la RFC, voici encore de la lecture
sur la petite pillule bleue qui fait durer les routeurs plus longtemps:
http://conferences.sigcomm.org/hotnets/2008/papers/19.pdf

2012/10/26 Jérôme Nicolle jer...@ceriz.fr

 On 26/10/2012 11:21, Stephane Bortzmeyer wrote:

 Ce cas ne semble pas couvert dans le RFC. Mais, oui, il me semble
 logique qu'un  FIR qui n'est pas un routeur (juste un serveur de
 routes) va en effet se passer de FIB et donc ne rien y installer.


 L’acronyme perdrait donc pas mal de sons sens. Pourtant c'est ce qui
 parait le plus logique comme architecture : on a quasiment tous des
 route-reflectors dans nos réseaux passé une dizaine de routeurs.

 Autant se fendre d'une implémentation purement logicielle de l'agrégation
 virtuelle dynamique avec les quelques extra comme le P.E.D. et le
 split-horizon qui bouffent pas mal de ram et de CPU...


 --
 Jérôme Nicolle
 06 19 31 27 14


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


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

Re: [FRnOG] [TECH] Templates Cacti MLX/CER

[Michel Moriniaux]

Salut Radu,
ce sont des graphes custom mais je n'ai pas inclu les graphes d'interface
pour eviter de veroler vos cacti lors d'un import. Par contre des RRA,CDEF
peuvent etre rajoutés/modifiés.
C'est quand meme mieux de les installer sur un cacti preprod avant de les
derouler sur la prod.

MM



2012/10/11 Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net


 On Thu, Oct 11, 2012, at 04:08 PM, Michel Moriniaux wrote:

  suite a suggestion de Laurent, voici mes templates cacti pour MLX/CER:
  CPU (MR et LP)
  CPU (tout sur un meme graphe - MLX8 only)
  DRAM (MR)
  Temperatures (MR et LP)
  Temperatures (tout sur un meme graphe - MLX8 only)
  stats optiques (gain/temperature)
  ipv4 FIB
  bgp neighbor routes

 Salut,

 Ce sont de templates crees par toi-meme ou des derives des templates qui
 circulent chez Brocade (ceux qui changent le format des graphs
 interface traffic standard) ?



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

[FRnOG] [TECH] Templates Cacti MLX/CER

[Michel Moriniaux]

Bonjour,
suite a suggestion de Laurent, voici mes templates cacti pour MLX/CER:
CPU (MR et LP)
CPU (tout sur un meme graphe - MLX8 only)
DRAM (MR)
Temperatures (MR et LP)
Temperatures (tout sur un meme graphe - MLX8 only)
stats optiques (gain/temperature)
ipv4 FIB
bgp neighbor routes

vous pouvez les telecharger ici:
http://dl.free.fr/lBuueq1rp
(desolé de vous faire voir de la pub, si vous avez un meilleur host je suis
preneur)

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

Re: [FRnOG] [MISC] Tout le monde a bien jeté ses routeurs Huawei à la poubelle ?

[Michel Moriniaux]

allez c'est presque Vendredi:

ils n' auraient pas dû se limiter au code de EIGRP, z'auraient pu copier le
code du process Check heaps



2012/8/2 ivan.meseg...@free.fr

 BockelvsGoauldRouters_SE01E04.ivy

 http://phenoelit.org/stuff/Huawei_DEFCON_XX.pdf

 source: https://twitter.com/41414141/status/230638257224966144

 Ivan

 - Mail original -
 De: Adrien Pestel pestoui...@gmail.com
 Cc: frnog@frnog.org
 Envoyé: Mercredi 1 Août 2012 14:40:11
 Objet: Re: [FRnOG] [MISC] Tout le monde a bien jeté ses routeurs Huawei à
 la poubelle ?

  Show must go on :

 http://www.computerworld.com/s/article/9229785/Hackers_reveal_critical_vulnerabilities_in_Huawei_routers_at_Defcon


 Le 31 juillet 2012 16:07, ivan.meseg...@free.fr a écrit :

  Pour ceux et celles d'entre vous qui auraient raté la réponse coté Huawei
  et ZTE
 
 
 
 http://www.pcinpact.com/news/72806-interdiction-routeurs-chinois-zte-et-huawei-repondent-au-rapport-bocke.htm
 
 
  Ivan Diego
 
 
 
  ---
  Liste de diffusion du FRnOG
  http://www.frnog.org/
 

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


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


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

Re: [FRnOG] Re: [ALERT] Trouble dans la force ( soucis vers AS3215 )

[Michel Moriniaux]

Stephane,
depuis que nous suivons vos interventions vous etes très evasif sur la
solution qui selon vous sauverait le monde. Vous semblez detenir une
verité que personne n'ici ne peut effleurer vu le ton de vos mails.
Je vous propose afin de calmer l'ambiance sur la ML de vous mettre a
votre plume et d'expliciter ces designs si resilients et de citer vos
sources plutot que de nous poser la question de ce que nous pensons
être la réponse. Nous attendons toujours les docs demandées par
Stephane Bortzmeyer la derniere fois.
La pluspart des membres actifs sur cette ML font vivre au jour le jour
des réseaux ayant presque tous des designs differents a toutes les
echelles, personellement j'ai connu un backbone tier 1 a budget
illimité satisfaisant votre laius sur les designs Sigtran mais il ne
permettait pas de se premunir des route-leak et hijack. Je suis
curieux de voir les differences de design entre votre modele et ceux
que je connais.

bref soyons constructifs et apprenons tous ensemble!


Pour la discussion annexe, si on ne peut plus dire sur FRNOG: eh les
gars j'ai un truc bizarre, pouvez vous confirmer? ou heads up!
Pakistan telecom refait des siennes je ne vois plus l'utilité
operationelle de la ML.

Michel Moriniaux

2012/7/26 Stephane Le Men stephane.le...@anycast-networks.com:
 Le 26/07/2012 12:09, Richard DEMONGEOT a écrit :

 Vu les trois points, RPKI ou non, le résultat est le même.


 Ma compréhension est que dans l'hypothèse où RPKI est déployé et activé, il
 aurait du couvrir ce problème d'annonces erronées.
 D'où l'invitation au troll de l'OP.


 L'important reste donc (encore) la réactivité des équipes techniques, et
 en l'occurence, 25 minutes c'est plus que raisonnable.


 C'est selon les jugements excellent ou lamentable. Si personne n'a rien vu,
 il n'y a rien à dire, si cela a été le tsunami au support, le responsable du
 support donnera sa propre appréciation de l'incident.



 Concernant la résilience :
 Orange n'est qu'une partie d'internet (certes importante pour le marché
 Francophone), mais une partie d'internet, et un AS parmis tant d'autres.
 (et encore, pas tout 3215 n'a été impacté à priori).


 Un AS parmi tant d'autre dans la table des ASN, mais quelle fraction trafic
 de l'AS, 1%, 10% , 30% ? Il n'y a que le propriétaire de l'AS qui peut
 répondre. Et cette fraction de trafic, c'est une fraction de son service
 qu'il vend, et non pas 1 divisé par nombre d'AS de la table des ASN de
 l'Internet.



 Est ce qu'il y a eu une coupure Internet ? Non. Il y a eu un incident sur
 une partie d'internet. La résilience doit être mesurée sur quelle partie
 d'internet?


 Sur chaque fraction de son trafic. A priori, rares sont les AS qui discutent
 uniformément en terme de volumétrie avec le reste de la planète. Chaque AS a
 son profil volumétrique.
 Je pense que si 99% de votre trafic ne se fait qu'avec 1 seul autre AS, cet
 AS mérite 99% de votre attention.

 Je suis partisan de cette répartition plutôt que d'une répartition qui
 consiste à se préoccuper de toutes les AS, y compris celles avec qui on n'a
 pas ou très peu de trafic.



 Enfin, mode avocat du diable :
 Le problème viens du fait qu'un AS a émis des routes vérreuses. Avec moins
 de résilience (aucun peering uniquement des upstreams), l'impact aurai été
 moins visible.

 Là encore, la résillience ne peut être mesurée sur des données aussi
 faibles, un acteur donné.



 J'ai la croyance qu'il vaut mieux diviser le problème de résilience pour y
 régner dessus, et je crois que la résilience globale obtenue d'un système ou
 d'un réseau n'est que la réunion de chacun de petits morceaux individuels de
 résilience du système.

 Du coup, quand il y a un problème avec une destination, ce problème dit
 quelque chose sur un petit morceau de résilience du réseau.

 Et normalement dans un réseau résilient, avant de perdre un service, on a
 perdu la résilience. Perdre un service, c'est une double faute.



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


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

Re: [FRnOG] Re: Plus d'IPv4 en Asie, on est les prochains!

[Michel Moriniaux]

J'ai la meme experience que Raphael à ce sujet, combien de fois par jour
j'ai les poils qui s'herissent en entendant le mot classe pour un /24, un
concept incompris et dépassé depuis 16ans mais tellement ancré dans nos
usages (et dans les vieux bouquins de formation) que ça à du mal a mourrir.
Sans compter les armées d'admin-sys qui considerent qu'un réseau c'est
forcement un LAN et obligatoirement en /24.

Je n'ai rencontré que très peu de gens connaissant et applicant des schemas
inspirés de RFC1219. et j'en vois encore moins qui font du RFC3531 pour IPv6

2011/4/15 Raphael MAUNIER rmaun...@neotelecoms.com


 On Apr 15, 2011, at 3:23 PM, Clément Game wrote:

 
  Je pense que beaucoup d'admin système et réseau qui n'ont pas évolué
 n'ont qu'une notion très vague de ce qu'est le CIDR.
 
  --
  Pierre-Yves Maunier
 
  Et moi je pense que cette considération ne reflette pas du tout la
 réalité.

 Dans la vrai vie, c'est malheureusement le cas.

  Je peux très bien admettre que certains n'ont qu'une vague notion de ce
 qu'est le CIDR, mais de là a dire qu'ils sont beaucoup

 Si si, c'est du vécu tout ça. Franchement, chez *beaucoup* de gens, la
 notion de CIDR reste un concept.
 
  Aussi de là a voir des considérations financieres dans ces
 sur-allocations il n'y a qu'un pas. Un fournisseur sera beaucoup plus tenté
 d'allouer un /24 PA à son client meme si celui-ci n'en utilise que le
 dixième ,parce que pour lui ya pas de probleme, il va quand meme facturer
 pour tout le range !! .

 De moins en moins vrai, en 2005 ok, mais plus depuis. Chez la plupart des
 gens responsable, on ne fait plus comme ça.

  C'est facile  de  taper  sur le  client mais je suis convaincu que lui
 aussi serait  ravi  de payer  moins cher et de se  debarasser de ressources
  qu'ils paye de facon récurente mais n'utilise pas.

 Faux, la plupart des clients historique ou non, ne veulent surtout pas
 toucher leur infrastructure en place et ne veulent surtout pas re-numéroter.
 Bien sur, sur un /24, ils ont pratiquement tous mis au début les serveurs
 et à la fin les équipements réseau.

  C.
 
 Raphael

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

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

[FRnOG] Re: [FRnOG] Architecture VPLS - Retour sur les équi pements Brocade NETIRON

[Michel Moriniaux]

Bonjour,
ça dépend de ce que l'on veut faire avec mais pour nos besoins ça tourne
bien depuis plusieures années sur du MLX et depuis peu sur du CER.
dispo pour en discuter si tu as des questions précises.

MM

2010/8/11 Christophe Lesur christo...@lesur.net

  Bonjour,



 Nous sommes actuellement en cours de définition de notre réseau VPLS.



 Notre choix s'oriente sur les équipements Brocade (ex foundry) NetIron MLX
 en cœur et des NetIron CES en distribution et collecte.



 Quelqu'un aurait-il un retour d'expérience sur ces matériels?



 Christophe.

[FRnOG] [vendredi] hacktivism is not dead

[Michel Moriniaux]

étant presque Vendredi:
http://www.zataz.com/news/19565/Judgement-day-for-Skynet.html
http://www.rtbf.be/info/societe/internet/un-hacker-veut-faire-chanter-belgacom-152625