Re: Re : [FRnOG] [TECH] Cohabition HSRP + VRRP

[Vincent Bernat]

 ❦ 21 juin 2012 17:18 CEST, Baptiste bed...@gmail.com :

 L'IP virtuelle est associée à l'adresse MAC hébergeant l'interface et
 est annoncées au switch et aux autres hosts sur le LAN via le
 gratuitious.

C'est une spécificité de certaines implémentations (dont Keepalived)
quand il est difficile d'utiliser des MAC virtuelles.
-- 
panic (No CPUs found.  System halted.\n);
2.4.3 linux/arch/parisc/kernel/setup.c


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

Re: [FRnOG] [TECH] 10Gbps Open Source Routing

[Vincent Bernat]

 ❦ 30 janvier 2013 10:38 CET, Stephane Bortzmeyer bortzme...@nic.fr :

 Conclusion : c’est faisable, mais pas avec toutes les cartes et tous
 les pilotes, il faut passer du temps à faire des réglages et, le coût
 par paquet étant important, ce débit n’est atteint que pour les
 paquets de plus de 256 octets.

L'article semble un peu vieux (2008?). Toutes les cartes 10G sont
maintenant capable de faire du multiqueue sans réglages particuliers ce
qui est la principale optimisation. Les cartes type bnx2x ou ixgbe ont
toutes au moins 16 queues dans les deux sens et peuvent donc faire
travailler tous les cores de 2 Xeon récents type X5650, y compris en
usant de fonctionnalités telles que Netfilter ou LVS.

La seule optimisation à faire est de sticker les queues sur un CPU
chacune (et de ne surtout pas laisser irqbalance faire le boulot, à
moins de tester avec une version = 1).
-- 
 /* Nobody will ever see this message :-) */
panic(Cannot initialize video hardware\n);
2.0.38 /usr/src/linux/arch/m68k/atari/atafb.c


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

Re: [FRnOG] [TECH] firewall sur routeur Quagga ??

[Vincent Bernat]

 ❦ 31 janvier 2013 15:02 CET, Christophe Baegert c.baegert-lis...@lixium.fr :

 Je me demande si d’installer et configurer un iptables sur un
 routeur BGP Quagga (debian) est une bonne chose ?
 Est-ce que cela ne vas pas ralentir le routage ?

 Il faut juste éviter qu'il fasse du connection tracking, pour ça le plus
 sûr est de faire un lsmod|grep conntrack. S'il est activé, on court à
 la catastrophe.

iptables -t raw -I PREROUTING -j NOTRACK
iptables -t raw -I OUTPUT -j NOTRACK

Cela permet aussi de conserver la conntrack pour les connexions
d'administration. Avec la mémoire dispo actuellement, il est aussi
possible de tuner la conntrack pour augmenter drastiquement la taille de
la table de connexions et diminuer le te timeout de la plupart des
états.

Sinon, on peut aussi filtrer avec tc.
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] Le troll du vendredi par Michel

[Vincent Bernat]

OoO En cette fin de matinée  radieuse du mardi 07 juin 2011, vers 11:01,
Emmanuel Thierry m...@sekil.fr disait :

 Le mieux c'est d'essayer: pour l'instant, je n'ai vu aucun hotspot qui 
 empêche les requêtes DNS.

 J'avais ouï dire d'un ami qui avait test que iodined ne marchait pas
 sur les aéroports de Paris, mais je ne peux pas l'assurer.

Possible que  les requêtes soient limitées  en taille.  Un  -m 220 est
assez passe-partout. Et suffisant pour consulter deux ou trois bricoles.
-- 
Vincent Bernat ☯ http://www.luffy.cx

Keep it right when you make it faster.
- The Elements of Programming Style (Kernighan  Plauger)
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Protocole de routage IS-IS

[Vincent Bernat]

On Mon, 4 Jul 2011 11:27:19 +0200, Xavier Beaudouin wrote:


Mon expérience avec OSPF V3 m'as donné des raisons de prendre de
l'ISIS... Déjà sur OSPF v3 on a un router id... en ipv4 (c'est quoi 
ce

délire ?) donc l'OSPF converge en ipv6 si et seulement si l'OSPF ipv4
a convergé... bref... avec de l'ospf v3 vas faire un réseau ipv6 only
(ou si quelqu'un a truc.. ?).


Le router ID, c'est juste un entier de 32 bits. On l'écrit sous forme 
d'IPv4 uniquement pour des raisons pratiques (et dans le cas d'IPv4, on 
essaie même de le deviner en prenant une IP de la machine). OSPFv3 ne 
fait que de l'IPv6. OSPFv2 ne fait que de l'IPv4. Ils ne peuvent pas se 
marcher sur les pieds.

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

Re: [FRnOG] [ALERT] Coupures chez Online cet après-midi

[Vincent Bernat]

 ❦ 18 mars 2014 20:53 CET, Arnaud aberming...@online.net :

 C'est fini. Trois coupures en tout, la plus longue de 2h.
 http://stats.pingdom.com/p5a9jfqdd46c/852886

 Un bug packet of death comme on aime en manger :-) impact 1 salle 13% du 
 parc 
 Le CR ici :
 http://forum.online.net/index.php?/topic/4270-dc2-salle-103-incident-r%C3%A9seau/

Possible de dévoiler quelques caractéristiques du paquet TCP en
question ? Il est valide ? Il a des entêtes supplémentaires ? Il est
petit ? Il est gros ? Il est malicieux ?
-- 
Indent to show the logical structure of a program.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] Re: [ALERT] Nouvelle faille openssl

[Vincent Bernat]

 ❦ 10 avril 2014 02:01 CEST, Gael Martinez gael.marti...@gmail.com :

 Des fois, une librairie est statique ...

 mgc@infra:~$ strings /usr/sbin/sshd  | grep -i ssl
 SSLeay
 OPENSSL_config
 OPENSSL_add_all_algorithms_noconf
 SSLeay_version
 OPENSSL_1.0.0
 OpenSSL version mismatch. Built against %lx, you have %lx
 $ uname -a
 Linux infra 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux

Il y a utilisation de la libcrypto (qui est OpenSSL), mais pas de la
libssl (qui est TLS et qui contient la faille).
-- 
printk(What? oldfid != cii-c_fid. Call 911.\n);
2.4.3 linux/fs/coda/cnode.c


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

[FRnOG] [TECH] Optiques flexOptix

[Vincent Bernat]

Hello,

Quelqu'un a déjà testé les optiques de cette boîte allemande ?
 http://www.flexoptix.net/en/

Elle propose de les programmer pour une meilleure compatibilité avec les
équipements (genre pour mettre dans un Juniper QFX). Elle met également
à disposition une boîte qui permet de reprogrammer les optiques.
-- 
#if 0
2.2.16 /usr/src/linux/fs/buffer.c


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

Re: [FRnOG] [TECH] IPv4 - Nécessité des Adresses de réseau et de broadcast sur Ethernet

[Vincent Bernat]

 ❦ 22 juillet 2014 09:25 +0200, Pierre Colombier pcdw...@pcdwarf.net :

 Je rebondis sur le thread précédent (Statut adresses IPv4 .0) où il
 est dit en passant que les liaisons point à point peuvent se faire
 avec une /31
 voir avec une /32.

 Cependant j'ai tenté plusieurs fois (sur linux) de faire du /31 sur de
 l'ethernet  et ça n'a jamais voulu fonctionner correctement.
 Il faut toujours une /30 avec 50% de perte pour l'adresse de réseau et
 de broadcast.

Linux n'a absolument aucun soucis avec un /31 :

Machine A:

6: peer2: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
inet 192.168.0.0/31 scope global peer2
   valid_lft forever preferred_lft forever

192.168.0.0/31 dev peer2  proto kernel  scope link  src 192.168.0.0 

Machine B :

7: peer1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
inet 192.168.0.1/31 scope global peer1
   valid_lft forever preferred_lft forever

192.168.0.0/31 dev peer1  proto kernel  scope link  src 192.168.0.1 

Et cela pingue entre les deux sans soucis.

Pas de problème non plus avec du unnumbered:

Machine A :

6: peer2: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
inet 192.168.0.0/31 scope global peer2
   valid_lft forever preferred_lft forever
inet 192.168.1.0/32 scope global peer2
   valid_lft forever preferred_lft forever

192.168.0.0/31 dev peer2  proto kernel  scope link  src 192.168.0.0 
192.168.1.1 dev peer2  scope link 

Machine B :

7: peer1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP 
group default qlen 1000
inet 192.168.0.1/31 scope global peer1
   valid_lft forever preferred_lft forever
inet 192.168.1.1/32 scope global peer1
   valid_lft forever preferred_lft forever

192.168.0.0/31 dev peer1  proto kernel  scope link  src 192.168.0.1 
192.168.1.0 dev peer1  scope link 

# ping -c 1 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.029 ms

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.029/0.029/0.029/0.000 ms
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [TECH] Statut adresses IPv4 .0

[Vincent Bernat]

 ❦ 23 juillet 2014 07:53 +0100, Thomas Mangin 
thomas.man...@exa-networks.co.uk :

 Ma derriere utilisation de unnumbered remonte en debut du siècle :p 

 Le seul petit problème avec l’unnumbered est que si l'interface qui a
 l'IP publique sur le LAN passe 'down' (par example le switch est
 éteint par le client durant le week-end ou soir), tu ne peux plus
 pinger ou collecter les stats SNMP. Tu ne sais donc pas si c'est un
 problème avec la ligne ou ou le LAN et le monitoring va chanter.

Faut la mettre sur la loopback. :)

Pour moi, le seul problème avec l'unnumbered, c'est que quand tu fais un
traceroute, tu ne sais pas exactement quelle interface est en ingress.
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [TECH] Statut adresses IPv4 .0

[Vincent Bernat]

 ❦ 23 juillet 2014 08:45 +0100, Thomas Mangin 
thomas.man...@exa-networks.co.uk :

 Le seul petit problème avec l’unnumbered est que si l'interface qui a
 l'IP publique sur le LAN passe 'down' (par example le switch est
 éteint par le client durant le week-end ou soir), tu ne peux plus
 pinger ou collecter les stats SNMP. Tu ne sais donc pas si c'est un
 problème avec la ligne ou ou le LAN et le monitoring va chanter.
 
 Faut la mettre sur la loopback. :)
 
 Pour moi, le seul problème avec l'unnumbered, c'est que quand tu fais un
 traceroute, tu ne sais pas exactement quelle interface est en ingress.

 Oui, c'est le meilleur choix si tu as une IP, quand le client a un
 block c'est moins pratique, et il faut bien configurer ARP, etc.

Oui, tu as raison. Sur un Linux, tu configures en loopback et si tu
utilises arp_ignore=1 et arp_announce=2, tu la configures aussi sur
chaque interface.

Sur du JunOS, loopback dédiée et sur chaque interface, déclaration en
unnumbered-address.

Psa testé avec d'autres équipements.

Il y a ça qui est passé sur le sujet il n'y a pas longtemps (bien que ce
soit dans un contexte d'autoconfiguration avec OSPF) :
 http://blog.ipspace.net/2014/06/unnumbered-ospf-interfaces-in-quagga.html
-- 
panic(bad_user_access_length executed (not cool, dude));
2.0.38 /usr/src/linux/kernel/panic.c


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

Re: [FRnOG] [MISC] Netflix in France

[Vincent Bernat]

 ❦ 28 juillet 2014 14:59 -0700, Greg Villain fr...@tadcons.net :

 Tout a fait d’accord.  C’est un problème a géométrie hautement
 variable, je te le concede volontiers.  Par contre, si une chose est
 sure a 100% c’est qu’il est impossible de faire mieux que l’offload
 que Netflix offre a travers ses appliances en passant par un
 quelconque CDN traditionnel.

Netflix tombe à 0% quand la seule vidéo regardée dans la journée n'est
pas dans le cache et représente 1000 vues. Un CDN traditionnel tombe à
presque 99.9% dans le même cas. Juste pour dire qu'un CDN avec cache
infini peut sans problème faire mieux que Netflix. Si le rapatriement
initial de Netflix compte comme une vue (parce que ça prend quand même
de la BP), un CDN avec cache infini fait toujours mieux.

J'ai pas d'avis dessus, mais sur NANOG, ils se sont bien étripés sur
quelle méthode est plus efficace entre provisionner par avance et cacher
au fil de l'eau. On peut comprendre que pour un petit provider, bouffer
1Gbps de sa BP sans vraiment être sûr que cela serve vraiment, ça peut
faire douter. Tandis que cacher au fil de l'eau, on est au moins sur
qu'il y a du monde qui regarde.
-- 
 /*
  *   Should be panic but... (Why are BSD people panic obsessed ??)
  */
2.0.38 /usr/src/linux/net/ipv4/ip_fw.c


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

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

[Vincent Bernat]

 ❦ 18 août 2014 18:55 GMT, Thierry Martin (Europe) 
thierry.mar...@dimensiondata.com :

 Monsieur Philippe Bourcier
 = trouvez-vous sur le commerce des PCs (et pas des serveurs) avec un
 port FO ou un slot pour un GBIC type SFP (nouvelle génération) ??

Pour 30$, il y a des cartes avec deux SFP sur chipset Intel 82575EB
(donc pas du bas de gamme). 30$ de plus pour le SFP. À l'unité.
-- 
Document your data layouts.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [TECH]

[Vincent Bernat]

 ❦ 27 août 2014 09:07 +0200, Mateusz Viste n...@border6.com :

 En ce qui concerne l'IPv6 (si c'est un critère de choix), ce n'est pas
 toujours utilisable en pratique, en fonction de ce qu'on veut
 faire... La dernière fois que j'ai vérifié sur ma freebox, ils ne
 proposaient qu'un /64, sans possibilité de segmentation/routage. Donc
 à part pour une utilisation sur un réseau à plat chez soit, sans
 passerelle custom, cela ne peut pas servir à grand chose d'autre. À
 moins de rentrer bien sûre dans des usines à gaz de type brouteur
 IPv4/IPv6, mais ça devient vite fatiguant à maintenir :)

Free utilise un /28 en préfixe 6rd, ce qui laisse 4 bits pour le
subnetting côté client. Donc en cas d'utilisation de son propre routeur,
ça laisse 16 réseaux possibles chez le client.
-- 
Don't just echo the code with comments - make every comment count.
- The Elements of Programming Style (Kernighan  Plauger)


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

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

[Vincent Bernat]

 ❦ 28 août 2014 14:23 +0200, Stephane Bortzmeyer bortzme...@nic.fr :

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

C'est plutôt incorrect (la RFC est un peu plus nuancée et indique que
cela est possible avec une reconfiguration mais semble indiquer qu'il
s'agit d'une action humaine). Les IP des machines peuvent être
annoncées dans un protocole de routage permettant le déplacement de la
machine. L'hyperviseur qui a reçu la VM va se mettre à annoncer son
IP. La machine conserve son IP et son routeur.
-- 
 /*
  * For moronic filesystems that do not allow holes in file.
  * We may have to extend the file.
  */
2.4.0-test2 /usr/src/linux/fs/buffer.c


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

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

[Vincent Bernat]

 ❦ 28 août 2014 15:35 +0200, Stephane Bortzmeyer bortzme...@nic.fr :

 Les IP des machines peuvent être annoncées dans un protocole de
 routage

 Annoncer les /32 et /128 en OSPF ? Pas bête mais inhabituel. Qui fait
 cela ?

Plutôt en BGP qui permet de mieux compartimentaliser et filtrer. Je ne
pense pas que ce soit si inhabituel que ça. Je ne le fais pas encore de
mon côté, mais c'est dans les cartons.

De manière proche, j'avais fait ça :
 http://vincent.bernat.im/en/blog/2013-exabgp-highavailability.html

Cela me semble très proche de ce qu'il faudrait faire pour permettre à
des IP de migrer n'importe où sur un réseau L3.

Il faut ajouter côté client que le routeur ne change pas, chose qui est
très facile en IPv6 (fe80::1 en routeur pour tout le monde) mais qui est
moins évident en IPv4 si on veut de la configuration via DHCP (en
statique, pas de soucis, on indique que le routeur par défaut qui est le
même pour tout le monde est sur eth0).

C'est un peu du SDN avec les technos d'il y a 20 ans. ;-)
-- 
Document your data layouts.
- The Elements of Programming Style (Kernighan  Plauger)


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

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

[Vincent Bernat]

 ❦ 29 août 2014 23:31 +0200, Radu-Adrian Feurdean 
fr...@radu-adrian.feurdean.net :

 Oui c'est assez courant d'annoncer des VIP en /32 dans le réseau, en 
 OSPF, ou plutôt en BGP (avec exabgp par exemple).

 Enfin, entre quelques VIP et *toutes* les machines, il y a une
 difference

Bah, pourquoi pas. Ça dépend combien tu as de machines. Il y a pas mal
de switchs ToR qui sont capables d'avoir beaucoup de routes (souvent le
même ordre de grandeur que le nombre de MAC). Genre 16k en IPv4 pour les
EX4200 (attention, beaucoup moins en IPv6) et autres de la même gamme,
128k en IPv4 pour les QFX5100.

Avant d'atteindre 128k VM, il y a de la marge.

Si tu passes par des route servers Linux, tu peux aussi aggréger avant
de redistribuer aux switchs ToR. Si les migrations se font généralement
par subnet ou de manière ponctuelle/discrète, la table de routage doit
pouvoir rester assez compacte.
-- 
printk(Entering UltraSMPenguin Mode...\n);
2.2.16 /usr/src/linux/arch/sparc64/kernel/smp.c


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

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

[Vincent Bernat]

 ❦ 30 août 2014 19:23 +0200, Radu-Adrian Feurdean 
fr...@radu-adrian.feurdean.net :

 Bah, pourquoi pas. Ça dépend combien tu as de machines. Il y a pas mal
 de switchs ToR qui sont capables d'avoir beaucoup de routes (souvent le

 Si ca n'oblige pas a avoir un quagga/bird/exabgp/ sur chaque
 serveur/VM, oui, pourquoi pas.

 Et tant qu'on y est, j'avais une autre idee, j'avais meme vu un article
 quelque-part a ce sujet mais je n'arrive plus a trouver le lien.

 On part du postulat que les machines dans un rack ne sont pas forcement
 dans le meme subnet, mais que des machines dans le meme subnet se
 trouvent dans des racks differents.
 L'idee est que chaque ToR porte l'IP du default gateway pour chaque
 subnet. Les addresses avec une entree ARP  valide sont redistribues en
 BGP, et dans chaque subnet il fait du proxy-ARP pour les IP dont il a
 une route recue d'ailleurs.

 Est-ce que c'est juste une idee dans le vent, ou il y en a bien des
 constructeurs qui permettent de faire ca ?

A priori, c'est comme ça que cela fonctionne chez Juniper en
restricted. C'est aussi le cas de Linux si tu configures correctement
le medium_id de chaque interface à des valeurs différentes (et
différentes de 0).
-- 
 /* Am I fucking pedantic or what? */
2.2.16 /usr/src/linux/drivers/scsi/qlogicpti.h


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

Re: [FRnOG] [MISC] Le pare-feu du geek barbu

[Vincent Bernat]

 ❦ 22 septembre 2014 00:53 -0700, Michel Py 
mic...@arneill-py.sacramento.ca.us :

 Attention, on peut se retrouver sur les spam lists sans envoyer du spam. 
 J'ai déjà vu les infos
 suivantes dans une black list: This was detected by observing this IP 
 attempting to make contact
 to a s_gozi2 Command and Control server, with contents unique to s_gozi2 CC 
 command protocols.
 This was detected by a TCP/IP connection from x.x.x.x on port 56162 going to 
 IP address y.y.y.y
 (the sinkhole) on port 443.

 D'accord, mais que peut-on y faire ?
 La liste des adresses bloquées par Malwarebytes, quelqu'un ? si on
 pouvait détecter qu'un invité (ou pas) essaie de se connecter sur un
 CC de bots, çà serait un début.

Si tu ne fais pas d'auto hébergement, tu t'en fous un peu d'avoir ton IP
résidentielle blacklistée.
-- 
printk(VFS: Busy inodes after unmount. 
Self-destruct in 5 seconds.  Have a nice day...\n);
2.3.99-pre8 /usr/src/linux/fs/super.c


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

Re: [FRnOG] [MISC] Le pare-feu du geek barbu

[Vincent Bernat]

 ❦ 11 octobre 2014 13:26 +0200, Xavier Beaudouin k...@oav.net :

 Je sais que Xen cay mieux, que KVM aussi ou bhyve aussi. Mais il a
 des fois des moment un geek (barbu ou pas) dois s'occuper de la vrai
 vie et passer 10h a se battre avec insert your open source solution
 here juste pour avoir de l'OpenSource (tiens, le CVE de Xen la avec
 0x3ff au lieu de 0xff, c'est open mais on l'as pas vu passé hein...)

Ben, la preuve que si. C'est le mainteneur de Xen dans SuSE qui l'a
trouvé.

 Pour revenir a l'ESXi (ou tout autre hyperviseur) ca reste quand même
 un machin qui produit des API comme la carte mère
 HP/Asus/Supermicro/whatever qui reste tout aussi propriétaire
 (chipset, carte réseau broadcom - 200% closed source au niveau des
 drivers qui fonctionnent -, ...).

Côté serveur, c'est très rare d'avoir des drivers proprios. Broadcom
maintient les drivers Linux mainline pour ses cartes réseau.
-- 
panic(mother...);
2.2.16 /usr/src/linux/drivers/block/cpqarray.c


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

[FRnOG] [TECH] 6rd et MTU

[Vincent Bernat]

Hello,

J'ai mon accès Internet chez Swisscom et j'ai remplacé la box fournie
par un routeur Linux. Pour l'IPv6, ils utilisent 6rd et je n'ai pas eu
trop de soucis à le configurer :

  ip tunnel add internet6 mode sit local $ip[firewall] ttl $sixrd_ttl
  ip tunnel 6rd dev internet6 6rd-prefix ${sixrd_prefix}
  ip addr add ${sixrd_delegated}1/64 dev internet6
  ip link set mtu ${sixrd_mtu} dev internet6
  ip link set internet6 up
  ip -6 route add default via ::${sixrd_br} dev internet6

Normalement, avec un MTU de 1500, le MTU de l'interface 6rd doit être de
1480. Soucis, quand j'utilise cette valeur, certains sites ont du mal à
répondre et ceci de manière aléatoire, ce qui n'aide pas.

Si je set le TCP MSS (ce que je n'aimerai pas faire car c'est une
solution partielle), le mettre à 1440 (1480 - 40) ne change absolument
rien. Par contre, baisser le MTU à 1460 me résout aussi le problème. En
tatonnant, je finis par trouver qu'il s'agit en fait d'un MTU à 1472.

Je note aussi que sur les machines IPv6 auxquelles j'ai accès, le MTU
découvert est de 1472 (ip -6 route show cache après avoir fait un for
i i $(seq 1 10); do cat /etc/passwd; done).

Du coup, il y a deux choses:

 1. Le MTU est de 1472 et non de 1480. Qu'est-ce qui peut me prendre 8
octets de plus sur le chemin ?

 2. Le PMTU peut ne pas fonctionner et ceci aléatoirement.

Sur le deuxième point, dans ce thread, ça parle un peu du problème de
MTU dans 6rd:

 http://www.gossamer-threads.com/lists/nsp/ipv6/49013

Notamment, l'ICMPv6 serait droppé au petit bonheur la chance pour que ça
marche à peu près dans la plupart des cas. Cela peut expliquer le côté
aléatoire. Est-ce une pratique courante ?

Quand j'étais chez Free, je n'avais pas ce problème. Cependant,
j'utilisais la Freebox. le PMTU était peut-être très bien géré ou alors
le MSS était setté par la Freebox ou par le CE.
-- 
panic (No CPUs found.  System halted.\n);
2.4.3 linux/arch/parisc/kernel/setup.c


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

Re: [FRnOG] [TECH] 6rd et MTU

[Vincent Bernat]

 ❦  1 novembre 2014 15:42 +0100, Vincent Bernat ber...@luffy.cx :

 Si je set le TCP MSS (ce que je n'aimerai pas faire car c'est une
 solution partielle), le mettre à 1440 (1480 - 40) ne change absolument
 rien. Par contre, baisser le MTU à 1460 me résout aussi le problème. En
 tatonnant, je finis par trouver qu'il s'agit en fait d'un MTU à 1472.

Mon calcul de MSS est foireux vu qu'en IPv6, il faut soustraire 60. Avec
un MTU de 1472 et un le set de TCP MSS à 1412 en sortie, je semble m'en
sortir convenablement. J'ai aussi checké qu'en IPv4, j'ai bien un MTU de
1500.
-- 
Write clearly - don't be too clever.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [TECH] 6rd et MTU

[Vincent Bernat]

 ❦  1 novembre 2014 17:39 +0100, Raphaël Jacquot sxp...@sxpert.org :

 Quand j'étais chez Free, je n'avais pas ce problème. Cependant,
 j'utilisais la Freebox. le PMTU était peut-être très bien géré ou alors
 le MSS était setté par la Freebox ou par le CE.

 j'ai comme l'impression que la MTU sur les box free est  1500

Ca expliquerait l'absence de probleme en IPv6 chez Free. Chez Swisscom,
je ne passe pas le premier routeur avec un MTU  1500, donc pas possible.
-- 
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [TECH] 6rd et MTU

[Vincent Bernat]

 ❦  1 novembre 2014 20:54 +0100, Radu-Adrian Feurdean 
fr...@radu-adrian.feurdean.net :

 http://tools.ietf.org/html/rfc4443
 
 on peut voir par l'utilisation du MUST que tout firewall qui dropperait 
 ICMPv6-packet-too-big est mal configuré

 Oui, mais nobody got fired for dropping all ICMP/ICMPv6.
 Deja si on commencait a dire aux gens que filtrer sauvagenet l'ICMP
 (surtout ICMPv6) n'est *PAS* plus securisant, et qu'il sert aussi a bien
 plus de choses que le legendaire ping de la mort (ca fonctionne encore
 en 2014 ???).

Dans le thread cité précédemment, c'est plutôt dans un soucis d'éviter
les DoS.
-- 
#ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT
2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c


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

Re: [FRnOG] [TECH] 6rd et MTU

[Vincent Bernat]

 ❦  1 novembre 2014 15:42 +0100, Vincent Bernat ber...@luffy.cx :

  1. Le MTU est de 1472 et non de 1480. Qu'est-ce qui peut me prendre 8
 octets de plus sur le chemin ?

Quelqu'un de Swisscom m'a indiqué que cette valeur était commune à tous
les clients et que comme certains clients étaient encore en PPPoE, les 8
octets en moins proviennent de l'entête PPPoE (comme il m'a aussi été
suggéré en privé).
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan  Plauger)


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

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

[Vincent Bernat]

 ❦ 11 novembre 2014 13:07 -0500, neo futur frnog@waisse.org :

  a mon avis pour lancer un vrai cdn il faut au minimum avoir des
 serveurs sur 4 continents sinon ca donne le meme genre de difference
 qu il y a entre youtube et dailymotion ( dailymotion ca marche a peu
 pres bien en europe et c est tout, et ca ne sera jamais un succes
 mondial a cause de ca )

Dailymotion a des serveurs en Europe, aux US et en Asie. Il y a aussi de
la diffusion depuis plusieurs CDN.

  vu d ici ( au perou ) j ai tout simplement arrete d essayer de
 visionner des videos dailymotion

Le Pérou, ça semble tout de suite assez représentatif du monde en dehors
de l'Europe.
-- 
HARDFAIL(Not enough magic.);
2.4.0-test2 /usr/src/linux/drivers/block/nbd.c


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

Re: [FRnOG] RE: [TECH] RFC 7404: Using Only Link-Local Addressing Inside an IPv6 Network

[Vincent Bernat]

 ❦ 20 novembre 2014 08:09 GMT, Michel Py mic...@arneill-py.sacramento.ca.us :

 Sauf que 10 ans après, j'ai toujours raison; c'est une
 monstruosité. Utiliser RFC1918, tout le monde l'a fait et continue à
 le faire. C'était crade, mais au moins il y avait une excuse à moitié
 bonne.

 Using Only Link-Local Addressing, c'est crade, çà va faire chier tout
 le monde, et il n'y a pas d'excuse.

Je ne vois pas trop le lien avec la RFC 1918. Les avantages cités sont :
 - table de routage plus petite (sans configuration supplémentaire)
 - plan d'adressage simplifié
 - moins de configuration à faire
 - moins de config dans le DNS
 - plus de sécurité (seul truc en lien avec la RFC 1918 et la RFC
   n'insiste pas énormément sur ce point)

Le selling point, c'est que tu configures une adresse globale en
loopback et tout le reste se retrouve juste avec des LLA. En IPv4, c'est
comme les unnumebered interface sauf qu'il y a encore moins à
configurer.
-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [TECH] Brancher le laptop en datacenter : USB3 to SFP

[Vincent Bernat]

 ❦  7 décembre 2014 10:17 +0100, Christophe Lucas christo...@clucas.fr :

 C'est vu comment sous Linux ? ethX ? gigaX ?

CDC ECM donc en ethX avec cdc-ether via usbnet.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [TECH] Routeur pour PME

[Vincent Bernat]

 ❦ 21 janvier 2015 19:14 GMT, Michel Py mic...@arneill-py.sacramento.ca.us :

 On est d'accord, c'est mieux de mettre le DNS interne sur autre chose que 
 le routeur.
 Maintenant, dans une TPE / petite PME, on a pas toujours cette possibilité 
 (tous les Win
 serveur n'ont pas le rôle DNS inclus, même s'il y a des softs tiers. Et 
 c'est dur de leur
 vendre un NAS synology rien que pour le DNS / DHCP / NTP)
 Donc, c'est mieux de mettre le DNS ailleurs que sur le routeur. Quand on 
 peut.

 Je ne vois pas ce cas de figure dans la réalité. Si la structure est
 si petite qu'elle n'a pas Active Directory, pourquoi avoir un DNS
 local ? C'est du Workgroup, la machinbox fait le DHCP et DNS
 externe. Si l'Internet tombe, pas besoin de DNS interne.

Pour faire ping le-pc-de-robert.local. Y'a le mDNS, mais c'est moins
universel.
-- 
Replace repetitive expressions by calls to a common function.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] Re: [TECH] DNS Free Down ?

[Vincent Bernat]

 ❦  6 janvier 2015 15:38 +0100, Xavier Beaudouin k...@oav.net :

 Je me permet de rebondir sur ce genre de détail, vu que ces deux
 premiers sont bon élèves n'est-il pas possible de faire justement un
 howto pour ouvrir proprement ce genre de résolveur et aussi
 accessoirement les soucis juridique d'avoir un dns resolveur
 ouvert...

Le wiki contenait quelques tips :
 https://www.diyisp.org/dokuwiki/doku.php?id=technical:dnsresolver

Et je crois que y'a ça qui est passé dans le fil (qui est le setup pour
ARN) :
 
http://www.guiguishow.info/2014/08/23/comment-mettre-en-place-un-serveur-dns-recursif-cache-ouvert-dans-de-bonnes-conditions/
-- 
Use library functions.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [TECH] Adresses ipv4 PI

[Vincent Bernat]

 ❦ 25 février 2015 09:36 +0100, Romain GUESDON r.gues...@nnx.com :

 Est-ce qu'en pratique, cela change quelque chose ? Qui utilise ce
 critère au niveau de leur routage (genre, dropper les annonces provenant
 d'IP PA) ?

 Avec un PA, tu pourra diffilement être multihomé et tu ne pourra facilement
 changer d'opérateur (car il faudra renumerotter à chaque changement) c'est
 vite galère :)

Ça, c'est si tu n'es pas propriétaire du PA. Mais tu peux être LIR et
avoir des PA et a priori, les multihomer sans soucis. Enfin, je pense
(mais je posais la question initial pour confirmer). Par exemple :

inetnum:188.65.127.0 - 188.65.127.255
netname:DAILYMOTION-NET
descr:  Dailymotion Anycast
country:FR
admin-c:DLY-RIPE
tech-c: DLY-RIPE
status: ASSIGNED PA
mnt-by: DAILYMOTION-MNT

(je prends cet exemple, car la plage est en plus utilisée en anycast)
-- 
He is now rising from affluence to poverty.
-- Mark Twain


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

Re: [FRnOG] [TECH] Adresses ipv4 PI

[Vincent Bernat]

 ❦ 25 février 2015 09:13 +0100, Sebastien Lesimple slesim...@laposte.net :

 IPv4 en PI ca n'existe plus en nouvelle allocation.
 IPv4 ne peut etre qu'en PA de nous jours.

Hello,

Est-ce qu'en pratique, cela change quelque chose ? Qui utilise ce
critère au niveau de leur routage (genre, dropper les annonces provenant
d'IP PA) ?
-- 
Let the machine do the dirty work.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [MISC]: annonce BGP

[Vincent Bernat]

 ❦ 27 avril 2015 11:00 +0200, JC PAROLA cont...@sels-ingenierie.com :

 Si je prend un cas extreme: je suis connecté avec plein d'opérateur et
 que via des local-policy je choisis cogent à chaque fois comme BEST
 PATH.

 Toutes les annonces de prefix par cogent seront propagées (même s'ils
 ont des AS-PATH plus long que les autres peer) au détriment de ceux
 annoncés par les autres peers.

Oui. Si tu veux conserver un peu de diversité et n'arbitrer que quand
l'AS path est égal, tu peux utiliser MED à la place. Mais comme souvent
cela a un impact économique, c'est local pref qui est utilisé.
-- 
Wrinkles should merely indicate where smiles have been.
-- Mark Twain


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

Re: [FRnOG] [MISC]: annonce BGP

[Vincent Bernat]

 ❦ 27 avril 2015 10:50 +0200, JC PAROLA cont...@sels-ingenierie.com :

 Je rencontre une situation que j'ai du mal à expliquer.

 J'avais un opérateur: Neo/Zayo

 J'en prend un deuxième: Orange AS3215

 Les 2 m'envoient la full table. Mes annonces sont correctes.

 Le looking glass d'Orange montre bien mon annonce (91.212.205.0/24 AS49328)

 Par contre, les peers directement connectés (ex cogent et L3) à Orange
 ne montrent pas mon prefix par l'AS d'orange dans leur LG.

 Ma question:
 Cogent peer (gratis) avec Neo/Zayo, je comprend que cogent passe par
 Neo/Zayo car c'est son BEST PATH mais au niveau de l'annonce, doit-il
 réannoncer
 ce qu'il a appris par Neo/Zayo ou par Orange (ou les deux)

BGP ne réannonce que le best path, sauf configuration particulière (pour
les route servers notamment). Du coup, à moins que le looking glass soit
très proche des routeurs recevant effectivement les annonces des deux
opérateurs, tu ne vois qu'une seule route.
-- 
Use the good features of a language; avoid the bad ones.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [MISC] Pétition : Non aux boîtes noires dans nos réseaux !

[Vincent Bernat]

 ❦ 18 avril 2015 06:30 GMT, Philippe Bourcier phili...@frnog.org :

 Quelques détails supplémentaires :
 http://frenchweb.fr/laurent-allard-pdg-dovh-la-loi-sur-le-renseignement-concerne-toute-leconomie-numerique/191171
 https://www.ovh.com/fr/news/articles/a1751.loi-sur-le-renseignement-vote-de-l-amendement-article-l8514

Au final, il s'agirait de l'amendement 437 :
 http://www.assemblee-nationale.fr/14/amendements/2697/AN/437.asp

L'article 861-3 dont il est question est l'actuel 242-9 :
 
http://www.legifrance.gouv.fr/affichCode.do?idSectionTA=LEGISCTA25508244cidTexte=LEGITEXT25503132dateTexte=20120618
-- 
This was the most unkindest cut of all.
-- William Shakespeare, Julius Caesar


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

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

[Vincent Bernat]

 ❦  3 juin 2015 10:18 +0200, Vincent vinc...@logaweb.fr :

 Tu fais quoi avec les dessins animés Japonais ? :P

 Hmm, ça dépend du ratio de ( tentacules + culottes )  / minute ... Ça
 promet des formules intéressantes ^^

Ce n'est qu'une affaire d'algorithme après tout.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] Re: [MISC] Une documentation Ubuntu recommande d'utiliser des adresses déjà allouées

[Vincent Bernat]

 ❦ 27 juin 2015 04:23 GMT, Michel Py mic...@arneill-py.sacramento.ca.us :

 Il y a 15 ans IPv6 était un jouet pour faire mumuse, un monde à
 part qui n'était pas encore vraiment intégré au monde réel.

 Ah ouai ouai, et aujourd'hui IPv6 c'est un jouet pour faire mumuse, un
 monde à part qui n'est pas encore vraiment intégré au monde réel.

 La différence, c'est que depuis 15 ans que j'entends des conneries qui
 prédisent le déploiement imminent (une chanson que j'ai chanté
 moi-même) maintenant si je vois pas l'élimination d'IPv4 en 3 ans je
 n'écoute plus le même disque rayé.

 IPv6 avec 10 ou 15 ans de plus à se taper dual-stack, je reste à
 IPv4. Comme tout le monde, à part ceux qui ont des milliards à ne pas
 savoir ou les dépenser.

Depuis 15 ans, il y a eu quelques changements :

 - Le top 3 Alexa est accessible en IPv6.
 - Plusieurs FAI (notamment dans le mobile) font de l'IPv6 only et
   utilisent du CGN pour permettre l'IPv4.

La moralité, c'est que pour une part croissante de la population, IPv4
est moins fiable/performant qu'IPv6 et ce n'est pas très grave parce que
ce qui est important est accessible en IPv6.

Du coup, si tu fournis du contenu en IPv4 only, ton service est dégradé
sur cette population. Sony et Microsoft ont collé le support IPv6 dans
la dernière génération de console pour cette raison, pas parce qu'ils
avaient des milliards à ne pas savoir où les dépenser.

Je rebondis un peu tard car c'est une conversation sur le SwiNOG qui m'a
fait penser à ça. UPC Cablecom, le plus gros cablo-opérateur suisse, est
en train de déployer des clients en IPv6 only avec du DS-Lite. Dans les
autres exemples connus, il y a T-Mobile US et Verizon.
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [MISC] Le super proxy chinois on y vient? ;-)

[Vincent Bernat]

 ❦ 10 août 2015 11:22 +0200, Carroussel Informatique carrous...@wanadoo.fr :

 Installer un soft du style Unboud sur ma bécane, ou sur une dédiée,
 c'est une bonne idée ou bien...?

L'avantage d'installer Unbound en local, c'est qu'il te fera en plus la
validation DNSSEC.
-- 
Use the good features of a language; avoid the bad ones.
- The Elements of Programming Style (Kernighan  Plauger)


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

Re: [FRnOG] [TECH] IPv4 - Expériences Broker

[Vincent Bernat]

 ❦ 15 juillet 2015 08:58 -0500, Duga Duga dug...@gmail.com :

 Tout d'abord, pardonnez ma naïveté ou le côté répétitif  éventuel de ma
 question.
 Malgré notre bonne volonté d'utilisation d'IPv6, nos clients ne sont pas
 forcément au même stade que nous simple fournisseurs de service. Donc on
 doit gérer notre pénurie d'IPv4 d'une manière ou d'une autre.

 Est ce que certains ont des retours d'expériences à partager avec ce genre
 d'organismes :
 http://ipv4marketgroup.com/broker-services/buy/

 Arnaque ? Pas arnaque ? Fiable ? Pas fiable ?
 Eventuellement des alternatives à partager ou tout autres conseils ?

Certaines sont listées directement sur le site du RIPE :

https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/ipv4-transfers/brokers
-- 
Let the machine do the dirty work.
- The Elements of Programming Style (Kernighan  Plauger)


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

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

[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/

Re: [FRnOG] [TECH] Les accents

[Vincent Bernat]

 ❦ 26 septembre 2015 09:07 +0200, David Ponzone  :

>> Les photos :
>> https://arneill-py.sacramento.ca.us/QWMichel/QWMichel.jpg
>
> Pourquoi 2 fois le \ ?

Sur un "vrai" QWERTY, la touche à gauche n'existe pas.

Et pour ma part, les accents en QWERTY classique se font avec une touche
Compose (mappée sur Windows droite par exemple).
-- 
Document your data layouts.
- The Elements of Programming Style (Kernighan & Plauger)


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

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

[Vincent Bernat]

 ❦ 23 septembre 2015 20:14 +0200, Pierre Emeriaud  :

>> un client me demande de créer un hôte DNS qui pointerait vers 127.0.0.1.
>
> Attention, certains resolvers comme par exemple[0] ceux de Free
> filtrent certains[1] résultats[2], comme par exemple les entrées qui
> pointent vers des entrées 1918. C'est mentionné dans la RFC, dans un
> passage qui pourrait s'appliquer pour 127.0.0.1 :
>
>Prominent examples of such references are DNS Resource
>Records and other information referring to internal private
>addresses. In particular, Internet service providers should take
>measures to prevent such leakage.

Ce qui est casse-pied au possible dès qu'on utilise des VPN sur des OS
dont le resolver ne sait pas faire de split DNS. C'est la raison
principale pour laquelle je fais tourner Unbound en local. Exemple
typique de position dogmatique qui empoisonne la vie des utilisateurs.
-- 
All things that are, are with more spirit chased than enjoyed.
-- Shakespeare, "Merchant of Venice"


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

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

[Vincent Bernat]

 ❦ 24 septembre 2015 15:13 +0200, David Ponzone  :

> Tu fais gérer le DNS auth de preprod.monsite.com par les devs, et
> s’ils cassent tout, c’est pas grave.
>
> Oui c’est cracra, mais c’est rigolo.

Dans pas mal de boîtes, les devs ne sont pas là uniquement comme
défouloir des sysadmins mais aussi pour faire du dev. Des devs qui ne
font plus de dev parce qu'on leur a délégué une partie de
l'infrastructure parce que c'est rigolo, c'est des jour-hommes perdus
sur les projets.
-- 
Replace repetitive expressions by calls to a common function.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Conseil hardware router pfsense

[Vincent Bernat]

 ❦ 22 septembre 2015 10:35 +0200, Jocelyn Lagarenne 
 :

> Pouvez vous m'aider ou du moins m'aiguiller dans la bonne direction ? mon
> budget est dans les 300/400€ max si possible.

En alternative avec ce qui a été proposé, tu peux regarder un Intel NUC
couplé à un switch administrable (type Netgear GS105, 30 €) pour pallier
à la limitation en nombre de ports. Tu n'auras aucun problème à
atteindre le gigabit. Si tu veux absolument un second port, pour 20 €,
un adaptateur USB3/Ethernet. On atteint aussi le gigabit avec ce genre
de bestioles. L'intérêt, c'est que tu fais un saut niveau puissance. Ca
consomme environ 10 à 15W dans les versions les plus puissantes.

À noter qu'un Raspberry Pi 2 sait faire du 30 Mo/s avec un adaptateur
USB3/Ethernet. Pour 50 €. C'est pour mettre en perspective.

Perso, j'ai tout mergé en un seul PC qui fait NAS+Kodi+routeur. J'ai
pris un de ces PC en forme de cube, une carte mini-ITX, un gros ventilo
qui tourne lentement, une alim passive et un Netgear GS108 (qui prend
deux SFP) et une borne wifi POE 802.11ac qui supporte plein de SSID (mais
dont le moindre changement de config est suivi d'un reboot, ils ont dû
s'inspirer de Windows 95).
-- 
Let me take you a button-hole lower.
-- William Shakespeare, "Love's Labour's Lost"


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

[FRnOG] [TECH] Serveur console

[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.
-- 
Test input for validity and plausibility.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Linux et ARP

[Vincent Bernat]

 ❦  7 juin 2016 20:41 CEST, David Ponzone  :

> Quelqu'un saurait me dire pourquoi sur un Linux type Debian,
> arp_ignore=2 n'est pas la valeur par défaut ?  La valeur par défaut à
> 0 me semble bien délicate dans certains cas, comme quand on fait du
> iSCSI multipath, et j'ai du mal à voir dans quel cas, à part des cas
> tordus, on en a besoin.

C'est cohérent avec la pratique de Linux d'accepter les connexions
indépendamment de l'interface d'arrivée sans avoir besoin d'activer le
routage. Perso, je trouve qu'il y a pas mal d'aspects pratiques à cette
façon de faire. On a toujours pu faire du unnumbered par exemple.

Il faut juste faire gaffe si on a des adresses en loopback que l'on ne
veut pas faire apparaître, par exemple une VIP inactive (dans le cas du
direct routing). Dans ce cas, on modifie aussi souvent arp_announce car
le routeur en face n'aime pas non plus avoir des requêtes ARP d'une IP
qui n'est pas dans le subnet.

La politique de Debian est de ne pas changer les réglages choisis par le
noyau. Ubuntu choisit par contre des valeurs plus "sécurisées"
(activation du rp_filter par exemple).
-- 
Make your program read from top to bottom.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] Re: [TECH] OpenDNS - Retour d'experience

[Vincent Bernat]

 ❦ 24 février 2016 09:47 +0100, Stephane Bortzmeyer  :

>> Avez-vous déjà utilisé OpenDNS ? Est-ce que quelqu’un l’utilise en
>> situation réelle et aurait-donc un retour d’expérience ?
>
> J'aurais tendance à demander d'abord : pourquoi diable un abonné à la
> liste FRnog aurait-il besoin d'OpenDNS ? C'est une liste d'OPÉRATEURS,
> il me semble. Donc, tout le monde ici gère déjà des résolveurs DNS,
> cela fait partie du service de base qu'on attend d'un FAI ou d'un
> hébergeur. Pourquoi en faut-il d'autres ?

OpenDNS ne fait pas que du résolveur public.
-- 
Go not to the elves for counsel, for they will say both yes and no.
-- J.R.R. Tolkien


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

Re: [FRnOG] Re: [TECH] "vous n'avez qu'Ã activer ipv6"

[Vincent Bernat]

 ❦ 27 février 2016 23:17 +0100, Nicolas Parpandet  :

>> Euh, je demande des précisions : si on ajoute des octets aux adresses
>> IPv4, sans rien toucher d'autre, on casse la compatibilité sur le
>> réseau et la compatibilité des applis. Donc, en quoi aurait-ce été
>> plus simple qu'IPv6 ? Détails techniques souhaités.
>
> Tout est possible ;), (je parle pas propreté ni architecture hein,
> juste de faisabilité !)  en réaffectant le champs TOS/DSCP par exemple
> (dont la fonction à déjà été modifiée par le passé), et pan 1 octet de
> gagné, on multiplie par 16 les ips mondiales disponibles ;),

Ben, c'est un tout petit octet alors.
-- 
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)


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

[FRnOG] Re: [TECH] OpenDNS - Retour d'experience

[Vincent Bernat]

 ❦ 25 février 2016 09:32 +0100, Stephane Bortzmeyer  :

>> OpenDNS ne fait pas que du résolveur public.
>
> Et que diable font-ils d'autre ?

Du filtrage via le DNS (plutôt que d'utiliser un proxy HTTP filtrant) et
de l'analytique pour les attaques.
-- 
Let me take you a button-hole lower.
-- William Shakespeare, "Love's Labour's Lost"


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

Re: [FRnOG] [TECH] Switch qui agit comme un hub sur un vlan

[Vincent Bernat]

 ❦ 20 février 2016 19:53 +0100, Xavier Beaudouin  :

> 1- un fortinet sait faire du BGP et surement mieux qu'un EX qui est un
> switch 

Ça me paraît pas évident. Le code BGP est sans doute exactement le même
que ce qui tourne sur les MX. Dans la même veine, un 6500 est aussi un
switch. Sans rien connaître du tout aux Fortinet.
-- 
Instrument your programs.  Measure before making "efficiency" changes.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] wikipedia

[Vincent Bernat]

 ❦ 10 mars 2016 14:12 +0100, Olivier Benghozi  :

> Et encore, dans le cas d'espèce on découvre que:
> https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Notori%C3%A9t%C3%A9_des_associations#Association_de_professionnels
> 
> et donc on constate qu'en fait c'est admissible (modulo les ergotages 
> minables aperçus dans la page de discussion).
>
> Donc bien (aussi) un problème de petit cowboy à trois balles.

Insulter copieusement les contributeurs bénévoles de Wikipedia ne va
pas aider des masses.
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] wikipedia

[Vincent Bernat]

 ❦ 10 mars 2016 18:54 +0100, hugues VOITURIER  :

> Y'a vraiment des mecs qui se prennent pas pour de la merde… 
>
> "Être cité ne suffit pas aux critères de Wikipédia ; il est demandé
> des sources centrées, ou au moins substantielles sur le sujet ; ne pas
> comprendre ça, c’est faire preuve d’une grande méconnaissance du
> fonctionnement de Wikipédia par les acteurs du fonctionnement de
> l’internet, et c’est vraiment dommage."
>
> Y'a vraiment des mecs qui se prennent pas pour de la merde… 

En réponse à "Supprimer la page FRnOG serait une preuve d'une grande
méconnaissance du fonctionnement de l'internet par les administrateurs
de wikipedia".

Il n'y a aucun zèle propre au Wikipedia francophone. La règle des
sources existe également sur le Wikipedia anglophone:

 https://en.wikipedia.org/wiki/Wikipedia:Verifiability#Reliable_sources
-- 
Don't comment bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] ifupdown et DHCPv6

[Vincent Bernat]

 ❦ 22 avril 2016 13:41 +0200, Olivier Benghozi  :

> Il est impossible de configurer SIMPLEMENT quoi que ce soit sous
> debian.

On attend tes contributions sur le sujet :
 https://www.google.fr/search?q=site:bugs.debian.org+Olivier+Benghozi

> (j'ai le droit, c'est vendredi)

Est-ce que c'est parce que c'est vendredi que je peux aussi me permettre
de dénigrer gratuitement un opérateur wifi couvrant certaines résidences
universtaires ?
 
https://lafibre.info/wifirst/coup-de-gueule-internet-residence-etudiante-wifirst/
-- 
Don't use conditional branches as a substitute for a logical expression.
- The Elements of Programming Style (Kernighan & Plauger)


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

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

[Vincent Bernat]

 ❦ 29 avril 2016 16:57 +0200, Alexandre DERUMIER  :

> j'imagine que ca doit fonctionner avec quagga en control plane ? (dans
> la doc ils utilisent zebbra, donc j'imagine que ca doit fonctionner)

Il n'y a pas besoin de Quagga. Le control plane est packet journey lui
même. Le configuration plane est le noyau Linux. Tu ajoutes une route
avec "ip route add", packet journey va être notifié et le prendra en
compte lors du prochain paquet slow path.

La doc mentionne bgpd et zebra comme exemple. zebra est le démon de
Quagga qui reçoit les demandes des autres démons et qui effectue
l'interface avec le noyau. Cela marcherait aussi avec bird par exemple.

Par contre, jamais essayé moi même, mais c'est dans la todo liste.
-- 
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)


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

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

[Vincent Bernat]

 ❦ 29 avril 2016 18:03 +0200, raf  :

>>> c'est simplement une suite logiciel de plusieurs daemons (bgpd,zebra,) ?
>>> donc zebra + bgpd , ca devrait être suffisant pour apprendre les
>>> routes et les injecter dans le kernel,
>> Oui.
> A ce sujet le lien la stack de routage et packetjourney/dpdk se fait
> via netlink et donc le kernel linux.
> Je trouve ça un peu contre productif personnellement et je reverrais
> d'une implémentation bypassant netlink.
> Après tout si le système est bien fait, le kernel n'a pas a connaitre
> les routes.

Au contraire, je trouve ça assez génial car cela permet d'utiliser
n'importe quel applicatif. 6Wind et Cumulus font la même chose. 

Ensuite, dans le détail, je pense que le noyau Linux continue de
gérer un certain nombre de cas en slow path (ARP?) mais c'est de la pure
spéculation.
-- 
Make input easy to proofread.
- The Elements of Programming Style (Kernighan & Plauger)


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

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

[Vincent Bernat]

 ❦ 29 avril 2016 17:17 +0200, Alexandre DERUMIER  :

> c'est simplement une suite logiciel de plusieurs daemons (bgpd,zebra,) ?
> donc zebra + bgpd , ca devrait être suffisant pour apprendre les
> routes et les injecter dans le kernel,

Oui.

> et ensuite c'est packet-journey qui s'occupe du forwarding via dpdk ?

Oui. Ce sera sans doute plus simple de d'abord se familiariser avec
Quagga avant d'ajouter packet-journey.
-- 
Indent to show the logical structure of a program.
- The Elements of Programming Style (Kernighan & Plauger)


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

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

[Vincent Bernat]

 ❦ 29 avril 2016 18:41 GMT, Michel Py  :

>> Sur un proc récent, tu peux viser 2 Mpps par coeur.
>
> Ca parait raisonnable.
>
>> Du coup, avec un hexacoeur, tu montes à 10G.
>
> Pas a 64 octets par paquet. Disons un double exacoeur te donne 24mpps,
> soit 1.5 Gbit/s qui était le nombre que je citais récemment; pas la
> peine de se fatiguer avec du 40G, même le 10G c'est encore loin.

Je sais pas trop comment tu comptes, mais 2 millions de paquets par
seconde, c'est 2*10^6 p/s * 84 octets/p * 8 bits/octet = 1.344*10^9
bits/s. Soit disons 1.5 Gbps avec le vent dans le dos. Après, tu veux
p'tet parler en full duplex, mais ça donne pas le facteur que tu
indiques non plus.

Ou alors, je suis vraiment fatigué.

>> Vincent JARDIN a écrit :
>> - un datapath logiciel sur serveurs (cf 6WIND aussi) là tu peux monter à 
>> 200Mpps @ 64 bytes
>
> Qu'est-ce qu'il y a d'autre dans ce domaine, à part 6WIND ? Je pose la
> question innocemment : mon prochain 40G çà sera du Cisco, j'ai pas le
> choix du vendeur. Ce que je vois arriver c'est que le pognon va pas
> être là, et que soudainement il va falloir que je système-D un routeur
> 40G avec un 486 :-(
> Si je devais le faire moi-même à pas cher, que conseillerais-tu ? Je
> veux un 6WIND gratuit ;-)

Ben, t'as packet-journey du coup ;-) J'ai pingué baloo de Gandi, je sais
pas s'il lit la ML.
-- 
Follow each decision as closely as possible with its associated action.
- The Elements of Programming Style (Kernighan & Plauger)


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

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

[Vincent Bernat]

 ❦ 30 avril 2016 04:45 GMT, Michel Py  :

> Pour que tout le monde soit d'accord : 500K préfixes minimum, 1
> million çà prend pas feu tout de suite.

Pour la partie routes, 1 route ou 5 millions de routes, cela n'influe
guère sur les performances.
-- 
Write clearly - don't be too clever.
- The Elements of Programming Style (Kernighan & Plauger)


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

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

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

Cependant, via switchdev, l'offloading est désormais intégré dans le
noyau Linux et donc avec le bon choix de carte réseau, tu devrais
pouvoir sans effort en bénéficier sous peu. C'est le cas avec des
Mellanox et cela devrait arriver avec le 4.6. Il y a eu une démo en 100G
au dernier NetDev mais en switching uniquement si j'ai bien compris (je
n'y étais pas).
-- 
I must have a prodigious quantity of mind; it takes me as much as a
week sometimes to make it up.
-- Mark Twain, "The Innocents Abroad"


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

Re: [FRnOG] [TECH] Loadbalancing CPU & Adresse IP paire...

[Vincent Bernat]

 ❦ 28 avril 2016 17:37 +0200, Valérie P  :

> Premier message sur la liste, j'espère vous fournir directement les
> informations attendues et que certains d'entre vous jouent parfois avec du
> système/chiffrement. ;)
>
> Je suis en train de faire quelques tests de chiffrement avec la solution
> Strongswan 5.1.2 (version fournie de base) entre deux serveurs Ubuntu 14.04
> en lab.
>
> Les comportements des deux serveurs étaient différents, les CPU de l'un
> étant quasi inutilisés (0,3% en moyenne) quand sur le second serveur la
> moitié des CPU est utilisée (tous les CPU impairs) le sont à 100%. Un top
> montre que ce sont les process ksoftirqd/x qui montent très haut dans les
> tours.
>
> En regardant de près, la seule différente entre les deux chiffreurs est
> située au niveau de leurs adresses IP. Côté "WAN" (ou du côté du trafic
> chiffré), le chiffreur 1 a l'adresse 10.0.0.1, le chiffreur 2 : 10.0.0.2
>
> - En changeant l'adresse du chiffreur 2 pour 10.0.0.3, le taux
> d'utilisation des CPU tombe à 0.3%
> - En changeant l'adresse du chiffreur 1 pour 10.0.0.4, le taux
> d'utilisation des CPU monte à 100% sur la moitié des CPU présents.
>
> J'ai suspecté d'abord irqbalance qui affecteraient des smp_affinities
> différentes aux deux chiffreurs, mais elles sont similaires. J'imagine
> qu'il y a un hash quelque part chez qui le dernier bit de l'adresse IP
> change quelque chose, mais à ce point!
>
> Avez-vous déjà observé un tel comportement? Vous auriez des pistes pour
> mieux comprendre ce qu'il se passe?

Si la carte est multiqueue, le hash se fait sur le couple d'adresses IP
et le protocole (cela se change éventuellement avec ethtool). Pour
savoir si la carte est multiqueue, tu peux vérifier quel est son qdisc
(avec ip l l, mq = multiqueue) ou alors checker avec "cat
/proc/interrupts".

Quel est la carte réseau ? ethtool -i eth0

Ensuite, il faut voir ce que sont les CPU pairs. Tu peux obtenir la
topologie de tes CPU avec:

 grep . /sys/devices/system/cpu/cpu*/topology/*_list

irqbalance va affecter chaque IRQ avec un ou plusieurs CPU. Vérifie
avec :

 grep . /proc/irq/*/smp_affinity_list

Regarde aussi dans /proc/interrupts quelle est la queue la plus
sollicitée.

Ensuite, trouver un lien entre la topologie et l'affinité CPU. Je trouve
très surprenant une telle différence. Le système est-il NUMA (lscpu le
dit) ?

Essaie sans HT ou avec irqbalance désactivé voir si cela change quelque
chose. Regarde aussi avec perf top (installe le paquet de debug pour le
noyau pour y voir plus clair).
-- 
Instrument your programs.  Measure before making "efficiency" changes.
- The Elements of Programming Style (Kernighan & Plauger)


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

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

[Vincent Bernat]

 ❦ 29 avril 2016 13:15 -0500, Vincent JARDIN  :

> En cartes 40G, tu peux regarder les CX4 de Mellanox ou les cartes
> Intel. Vérifie que tu as bien les bus x16 et Gen3.

Si je regarde une CX4, je ne trouve pas le nombre d'entrées qu'elle
prend. 32k ou 128k ? Pour une Intel, c'est 8k, mais je suppose que
Mellanox monte plus haut pour permettre son exploitation par switchdev.
-- 
It is a wise father that knows his own child.
-- William Shakespeare, "The Merchant of Venice"


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

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

[Vincent Bernat]

 ❦  1 mai 2016 17:10 GMT, Michel Py  :

> Puisqu'on est sur dans le sujet des performance routeur logiciel,
> est-ce que quelqu'un a essayé de faire passer du vrai trafic dans une
> Olive ou un IOU ?

Le vMX utilise DPDK pour obtenir de bonnes perfs. Peu probable que tu
arrives à quoi que ce soit avec Olive ou IOU.
-- 
Treat end of file conditions in a uniform manner.
- The Elements of Programming Style (Kernighan & Plauger)


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

[FRnOG] Re: [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

[Vincent Bernat]

 ❦ 22 juillet 2016 11:55 CEST, Stephane Bortzmeyer  :

>> Cela ne permet pas seulement d'économiser des IP publiques, cela
>> simplifie grandement la configuration.
>
> Oui, mais ma question ne portait pas sur le fait d'utiliser des
> interfaces non numérotées (c'est déjà décidé) mais sur le fait de
> n'avoir qu'une seule adresse IP publique pour tous les routeurs.

Yep, c'était uniquement une remarque annexe.

Sur le sujet, entre avoir 5 IP privées dans le traceroute et 5 fois la
même IP, je préfère avoir 5 IP privées. Si ce n'est pas ton AS, tu peux
toujours savoir à qui sont ces 5 IP en regardant la première IP publique
(doit pas avoir grand monde qui fait des intercos entre AS en adressage
privé). Si c'est ton AS, tu as les reverses pour savoir qui est
qui. Alors que si tu as une "fabrique IP" avec 100 routeurs qui se
partagent l'IP et de l'ECMP en pagaille, ça va être coton de
diagnostiquer.
-- 
Test programs at their boundary values.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Remplacement de switchs top of rack

[Vincent Bernat]

 ❦ 10 août 2016 16:23 CEST, mks mks  :

> Pour l'alim mono, tu peux mettre en place des bandeaux STS ?

En cas de problèmes, c'est assez susceptible d'impacter tes deux
arrivées électriques.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Remplacement de switchs top of rack

[Vincent Bernat]

 ❦  9 août 2016 20:41 CEST, raf  :

> Ex3300 de préférence. Les 4200 sont gros, la carte 10G est en option
> et sont EOL. Ex3300 ça marche sans problème chez nous (on a en
> beaucoup), c'est pas cher, c'est stackable (Virtual Chassis) et il y 4
> ports 10G de base. Ceci étant on peut certainement trouver encore
> moins cher ailleurs.

Seul soucis, c'est mono-alimenté.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: Fwd: Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[Vincent Bernat]

 ❦ 21 juillet 2016 15:01 CEST, William VINCENT  :

> Est ce que c'est normale que la VIP se mette sur les deux serveurs ?

Les deux keepalived ne se voient pas. Vérifie avec tcpdump sur
eno16777984 que tu vois bien les paquets multicast pour 224.0.0.18
(arriver et partir si les deux sont masters) ?
-- 
Use variable names that mean something.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: Fwd: Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[Vincent Bernat]

 ❦ 21 juillet 2016 16:11 CEST, William VINCENT  :

> 16:00:50 root@ldaptest2 ~ >   tshark -i eno16777984 multicast
> Running as user "root" and group "root". This could be dangerous.
> Capturing on 'eno16777984'
>   1 0.0  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
>   2 10.001008912  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
>   3 20.002060373  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
>   4 30.002706144  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
>   5 40.003754734  ip.ldap2 -> 224.0.0.18   VRRP 54 Announcement (v2)
>
>
> 16:00:52 root@ldaptest1:~ > tshark -i eno16777984 multicast
> Running as user "root" and group "root". This could be dangerous.
> Capturing on 'eno16777984'
>   1 0.0 ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
>   2 10.000906764  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
>   3 20.002005544  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
>   4 30.002651402  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
>   5 40.003705995  ip.ldap2 -> 224.0.0.18   VRRP 60 Announcement (v2)
>
> étonnant d'avoir des requêtes du backup uniquement et avec deux
> résultats différents en fonction d'où on capture les trames

Le fait que seul le master envoie des requêtes est normal. La différence
de VRID ne l'est pas. Peut-être que l'inspection des adresses MAC
donnerait quelques billes.
-- 
He is now rising from affluence to poverty.
-- Mark Twain


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

Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[Vincent Bernat]

 ❦ 21 juillet 2016 10:00 CEST, William VINCENT  :

> Hum c'est encore pire, je passe à un taux d'erreur de 50%, le slave
> répond aux requêtes au MASTER mais celui ci ne semble pas les
> retransmettre au client.

Un taux d'erreur de 50% avec du rr, ça ressemble du coup beaucoup à un
problème sur l'un des deux frontaux. Genre, sa route par défaut ne
repasse pas par le LB. Maintenant que tout est symétrique, cela devrait
être assez simple de débugguer avec tcpdump.

> Mais si on passe par du NAT, du coup ça ne créerait pas une surcharge
> du MASTER ? Ou est-ce vraiment négligeable ?

En IPVS, tu peux t'attendre à 100k nouvelles transactions par seconde
par cœur ou 500k paquets/s par cœur en régime établi sur un banal
Xeon. Le LDAP va sans doute flancher avant.
-- 
It is often the case that the man who can't tell a lie thinks he is the best
judge of one.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


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

Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[Vincent Bernat]

 ❦ 21 juillet 2016 09:24 CEST, William VINCENT  :

>   lb_algo rr
>   lb_kind DR

Pour du LDAP, c'est un peu luxueux de faire du DR. Que se passe-t'il
avec lb_kind NAT ?
-- 
I dote on his very absence.
-- William Shakespeare, "The Merchant of Venice"


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

Re: Fwd: Re: [FRnOG] [TECH] Keepalived et LoadBalancing OpenLDAP

[Vincent Bernat]

 ❦ 22 juillet 2016 08:59 CEST, Matthieu Racine  :

>> Le fait que seul le master envoie des requêtes est normal. La différence
>> de VRID ne l'est pas. Peut-être que l'inspection des adresses MAC
>> donnerait quelques billes.
>
> Bonjour,
>
> Arrêtez moi si je dis une bêtise, mais pour moi le DR, ça sert à
> mettre des serveurs "derrière" des loads balancers. Bien que
> "derrière" ne soit pas le terme correct puisqu'il faut que les LB et
> les serveurs soient sur le même lien de broadcast.
> Le VRRP inclus dans Keepalived, c'est la cerise qui permet de redonder
> (bascule, pas de mode actif/actif) les LB.
>
> Encore une fois, je me trompe peut-être, mais on ne met pas keepalived
> sur les serveurs eux même pour faire du DR / LB, non ???

Si, c'est le mode "local node" :
 http://www.linuxvirtualserver.org/docs/LocalNode.html
-- 
Terminate input by end-of-file or marker, not by count.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Bientôt le week-end, un débat sur l'adressage des routeurs

[Vincent Bernat]

 ❦ 22 juillet 2016 09:46 CEST, Stephane Bortzmeyer  :

> Si on manque d'adresses IPv4 (publiques, évidemment), numéroter toutes
> les pattes d'un routeur peut devenir difficile. Mettons qu'on mette
> pas mal de pattes en « non numéroté » (exemple chez Juniper
> )
> et qu'on n'utilise qu'une seule adresse par routeur, « donneur » (pour
> reprendre la terminologie JunOS) d'adresse pour toutes les
> interfaces.

Fonctionnalité assez bien supportée sur les MX, rudement moins bien
sur les QFX et plus du tout sur les EX. Ce qui est très embêtant vu
qu'il faut que tout le monde supporte la chose.

Cela ne permet pas seulement d'économiser des IP publiques, cela
simplifie grandement la configuration.
-- 
Choose variable names that won't be confused.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] La Post\e et les services secrets français

[Vincent Bernat]

 ❦  8 février 2017 03:34 GMT, Michel Py  :

> Bon peut-être que je suggère une connerie (çà serait pas la première
> fois, hein), mais est-ce que çà vaudrait le coup d'établir une charte
> de ce qui est postable ou pas sauf un vendredi ?

Cette "tradition" du vendredi rend globalement la liste peu lisible (et
déborde progressivement quelques jours avant, quelques jours
après). Perso, je trouve que ce serait pas mal de se modérer un peu sur
cet aspect.
-- 
Use debugging compilers.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Réponse DNS basé sur l'ASN de l'IP source

[Vincent Bernat]

 ❦  1 septembre 2016 16:15 CEST, julien  :

> J'ai un besoin aujourd'hui d'un service qui a besoin que la réponse à une
> requête du style:
> dig t...@ecute.org change selon l'ASN number de l'IP d'origine.
> Est-ce que vous connaissez une solution (Open source ou Propriétaire) qui
> pourrait faire l'affaire ?

Ça se fait pas mal pour la GeoIP. Il faut dans ce cas avoir également le
support pour EDNS client subnet pour gérer les DNS de Google. PowerDNS
et gdnsd supportent ça (avec GeoIP, faut voir pour les AS).
-- 
The last thing one knows in constructing a work is what to put first.
-- Blaise Pascal


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

Re: [FRnOG] [MISC] Rapport ARCEP sur problème IPv6

[Vincent Bernat]

 ❦  1 octobre 2016 11:49 CEST, Wallace  :

> Alors que d'autres ont évolués enfin malgré la pléthore de v4 à leur
> disposition :
> host www.orange.fr
> d.hpc.gtm.fti.net has address 193.252.122.103
> d.hpc.gtm.fti.net has IPv6 address 2a01:c9c0:b3:3000::4

Enfin. Ça date quand même pas mal (juin 2013 plus quelques jours autour
de juin 2012). Cela n'en fait pas un exemple, mais c'est loin d'être le
plus mauvais élève en la matière. Il a fallu attendre par exemple le
support d'ECMP pour IPv6 dans Linux (contribué par 6wind, fin 2012) et
il a fallu ensuite implémenter le support d'ECMP en IPv6 dans
Quagga. Aujourd'hui encore, pas de support ECMP (sans patch) pour IPv6
chez Quagga sous Linux. BIRD a eu ce support (partiel) le mois dernier.

D'autre part, support parcellaire d'IPv6 chez AWS. Support inexistant
chez Google Compute Engine. Support inexistant chez Microsoft Azure. Ça
ne justifie pas d'attendre sans rien faire, mais ça devrait quand même
donner un indice que c'est pas aussi simple que d'aller coller quelques
IPv6 sur des interfaces.
-- 
Make input easy to prepare and output self-explanatory.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Régénération optique

[Vincent Bernat]

 ❦ 23 octobre 2016 12:25 +0200, Jérôme Nicolle  :

> ILA : In Line Amplifier. C'est typiquement ce que tu héberges tous les
> 80km le long du tracé long-haul. Traditionnellement on utilise un ampli
> RAMAN pour pomper en amont et/ou un EDFA pour booster en aval.

On choisit comment ? Et quand c'est combiné, on le place en aval ou en
amont ?
-- 
Nothing so needs reforming as other people's habits.
-- Mark Twain


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

Re: [FRnOG] [TECH] BGP advertise route

[Vincent Bernat]

 ❦ 24 octobre 2016 14:54 +0200, mich...@domore.fr :

> je souhaite pouvoir annoncer en eBGP une route /23.
>
> Dans mon IGP, je ne reçois qu'une route d'un hôte en /32 appartenant
> au réseau que je souhaite annoncer.
>
> J'ai ajouté une route /23 gw null0 distance 250 afin que la réseau
> soit annoncé à mon peer BGP.
>
> Je ne trouve pas cette solution très "propre".

C'est assez classique.

Vu que tu dis null0, je suppose que tu es sur Cisco. Une solution
Juniper est de placer la route en "no-install". Elle ne sera pas
utilisée pour router. Tu peux aussi créer la route en /23 quand au moins
une route plus petite existe:

set routing-options aggregate route /23 policy when-to-create
no-install

set policy-options policy-statement when-to-create term 1 from protocol
ospf route-filter xxx/23 prefix-length-range /24-/32 then accept

set policy-options policy-statement when-to-create then reject

Je suppose qu'il existe un mécanisme équivalent chez Cisco.
-- 
Make the coupling between modules visible.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Régénération optique

[Vincent Bernat]

 ❦ 24 octobre 2016 18:10 +0200, Laurent Bloch  :

> À ce propos : qui pourrait m'indiquer un document sérieux qui explique
> comment fonctionne la régénération optique sur les fibres
> transocéaniques ? Si alimentation électrique nécessaire, comment ?

Y'a des amplis et l'alim court avec le câble. Plein de détails ici :

http://arstechnica.com/information-technology/2016/05/how-the-internet-works-submarine-cables-data-centres-last-mile/
-- 
He is now rising from affluence to poverty.
-- Mark Twain


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

Re: [FRnOG] [TECH] Phénomène incompréhensible via VPN IPSEC

[Vincent Bernat]

 ❦  9 décembre 2016 19:52 GMT, Sébastien 65  :

> J'ai un VPN IPSEC entre deux sites sur lequel je rencontre un gros problème 
> que je n'arrive pas à comprendre et résoudre.
>
> Le VPN est bien montée entre les deux routeurs Cisco. Je ping bien des 
> machines depuis n'importe quel côté du VPN.
>
> J'arrive à monter des sessions TSE sans problème, faire du SSH, du
> FTP, là où cela se complique est que certain service http/https ne
> fonctionnent pas, le navigateur tourne en rond...
>
> J'arrive à monter des partages Windows sans aucun problème par contre
> les partages présents sur serveur LINUX impossible !! Je peux utiliser
> l'interface d'admin pour accéder à une imprimante Brother mais pas
> celui de la Sharp (les deux imprimantes sont sur le même switch -
> depuis le lan je n'ai pas de soucis pour m'y connecter).
>
> Par exemple j'ai plusieurs NAS (D-Link) sur lequel je ne peux pas
> accéder à l'interface WEB (http) depuis le site distant, ni à utiliser
> les partages réseaux, cela mais trois plombe à afficher les partages
> ça mouline pendant des minutes...
>
> Chose encore plus délirante est que dans le poste de travail je vois
> bien la capacité du lecteur réseau (espace disque utilisé/restante)
> mais je ne peux pas y rentrer, ça mouline...
>
> Avez-vous déjà rencontré le phénomène ? Ai-je loupé un truc dans la
> configuration du VPN ?

Active TCPMSS. Le path MTU discovery est souvent défaillant sur les VPN.
-- 
You never have to change anything you got up in the middle of the night
to write.
-- Saul Bellow


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

Re: [FRnOG] [TECH] Linux, Multicast et VXLAN

[Vincent Bernat]

 ❦  2 décembre 2016 14:53 +0100, Baptiste Malguy  :

> Immédiatement les annonces multicast vers 239.0.0.10 sont émises depuis
> 192.168.50.5 sur eth0 et eth1, au lieu de eth0 seul.

Perso, je trouve cela fort suprenant si tu n'as pas encore mis de démon
de routage multicast. Linux route le multicast comme l'unicast et
consulte la table de routage classique. Es-tu sûr que tu ne vois pas
simplement les trames émises sur eth0 revenir sur eth1 ? ip mroute
est-il vide ?

Sur le VXLAN Linux, j'avais fait un peu de doc ici quand ça avait été
développé. J'ai retesté récemment et ça fonctionnait toujours :
 https://vincent.bernat.im/en/blog/2012-multicast-vxlan.html

Note que dans ton cas, faire de l'ECMP multicast ne marchera pas sans
démon de routage (genre du PIM-SM). Je compte faire ça très
prochainement, donc tout retour de ta part m'intéresse.
-- 
Keep it right when you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Pb pour joindre différents sites Web

[Vincent Bernat]

 ❦ 23 décembre 2016 19:05 +0100, Raphael Mazelier  :

> Le truc c'est que visiblement il n'y a pas encore assez de bonne
> documentation/formation sur les best practices de comment faire du
> réseau dans la vrai vie. On a tous plus ou moins appris sur le tas
> avec les exemples des autres.
>
> Le réseau c'est un métier mais j'ai toujours trouvé qu'on n'en
> facilitait pas l'accès...

J'espère un jour publier un exemple commenté de conf JunOS complète pour des
border routers (avec des transitaires, des peerings, des exemples de
politique de routage). Pour le moment, je dois encore travailler dessus. Ce
serait effectivement appréciable que cela existe.
-- 
Use data arrays to avoid repetitive control sequences.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [JOBS] [FRnOG] [MISC] Le troll du vendredi par Michel was: IPConnect recrute sur Montpellier un technicien junior

[Vincent Bernat]

 ❦ 10 mars 2017 04:01 GMT, Michel Py  :

> Bon et puisque c'est trolldi, je suis carrément déçu que personne n'ai
> donné des croquettes à mon troll de la semaine dernière à propos de ce
> que le gouvernement des iouèssé fait pour tuer la neutralité du net.

Cette "tradition" du vendredi descend notoirement le niveau de la ML et
déborde systématiquement (en temps et en endroit, comme ici sur
frnog-jobs). De plus, elle attire manifestement des personnes qui se
sentent autorisées à se verser dans le hors sujet total (cf récent
exemple de théorie du complot).

Juste pour dire que, personnellement, je souhaiterais que la ML devienne
plus professionnelle dans ce qu'elle transporte. Cela permettrait
peut-être de glaner des contributions plus techniques qui n'existent
actuellement pas car la ML se confond avec le PMU du coin.
-- 
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] - Simulateur de latence

[Vincent Bernat]

 ❦  2 mars 2017 18:13 +0100, David Neto  :

> J'ai un sujet actuel sur lequel je trouve plein d'outils, appliances ou
> projets opensource et j'aimerais avoir vos avis.
>
> L'idée est de pouvoir simuler la latence induite par un déménagement de
> serveurs de plusieurs pays d’Europe vers Paris.
>
> Je ne peux pas mettre de boitier en coupure physique des serveurs pour
> simuler cette latence.
>
> L'idéal serait d'avoir un agent à utiliser sur les serveurs à tester
> (exécutable, binaire, tool à installer, ... qui permette de faire varier la
> latence des paquets)

Si les serveurs à tester sont sous Linux, pour rajouter 100ms en sortie,
il y a :

tc qdisc replace dev eth0 root netem delay 100ms

En entrée, c'est plus compliqué.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] PTR et IPv6

[Vincent Bernat]

 ❦ 10 mars 2017 08:19 -0500, Daniel Jakots  :

> J'ai en tête que de ne pas avoir de reverse sur une IP n'est pas
> optimal. Autant en IPv4, c'est pas trop compliqué mais en IPv6...
>
> Si on utilise des IP fixes alors ça va, on peut juste faire "comme"
> IPv4 et mettre un reverse sur les (quelques) IP qu'on utilise. Dans le
> cas où il y a de l'auto conf privacy (par exemple), on ne peut pas
> prévoir quelles IPv6 seront utilisées. Avoir un fichier de zone qui met
> un PTR pour chaque IP d'un /64 n'est a priori pas vraiment jouable dans
> bind/nsd/knot.

Dans Knot justement, tu as un module pour retourner des records
synthétiques:

https://www.knot-dns.cz/docs/2.4/singlehtml/#synth-record-automatic-forward-reverse-records
-- 
Format a program to help the reader understand it.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] IPv6 chez Orange (grand public)

[Vincent Bernat]

 ❦ 28 février 2017 18:50 +0100, Alarig Le Lay  :

> send vendor-class-identifier = "sagem";
> option userclass code 77 = string;
> send userclass
> 2b:46:53:56:44:53:4c:5f:6c:69:76:65:62:6f:78:2e:49:6e:74:65:72:6e:65:74:2e:73:6f:66:74:61:74:68:6f:6d:65:2e:4c:69:76:65:62:6f:78:33;
> option authsend code 90 = string;
> send authsend
> 00:00:00:00:00:00:00:00:00:00:00:ici:mon:identifiant:fti:en:hexa;

Peut-être :

supersede dhcp-renewal-time 600;
-- 
Watch out for off-by-one errors.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Quagga migre en FRR

[Vincent Bernat]

 ❦  7 mars 2017 18:48 +0100, Dominique Rousseau  :

>> - pourquoi partir de quagga ? j'imagine que le code patché était
>> déjà important, mais bird (et surtout le futur bird 2.0) me semble
>> une bien meilleure base.
>
> Moi j'aurais plutot demandé pourquoi forker, alors que le développement
> de Quagga est encore actif ?
> (avec une release en 02/2017 !)

Le développement de Quagga est très fermé. Il y a de nombreux patchs qui
ne sont jamais intégrés. Pas mal de monde tourne alors avec des versions
patchées de Quagga. Malgré avoir été "contributeur" pendant un temps, je
ne comprends toujours pas la logique derrière les patchs qui sont
acceptés et ceux qui ne le sont pas. J'ai réussi sans problème à passer
des gros patchs sur OSPFv3, mais un petit patch pour gérer les routes
blackhole n'est jamais passé. Dans le même genre, Google a fait passer un
patch énorme pour le support d'ISIS en disant clairement qu'ils
comptaient pas en faire plus, paf, mergé.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] pfSense Unbound devient instable (was Pare-feu / IDS / UTM personnel)

[Vincent Bernat]

 ❦ 30 juillet 2017 07:56 +0200, megagolgoth  :

> Commençons un nouveau fil, j'aimerai bien comprendre le pourquoi et
> régler le soucis.
>
> De temps en temps certains domaines ne sont plus résolvable. Le
> dernier cas fut un nom de domaine auquel j'accédais et à un moment
> plus de résolution. J'ai redémarré Unbound et hop ça refonctionne.
>
> Le problème est rare, ça m'arrive une fois par mois environ. Je n'ai
> pas encore eu deux fois le même domaine.
>
> Pour faire rapide côté conf : j'ai activé l'enregistrement des
> hostname des machines de mon réseau local dans le DNS, DNSSEC et des
> overides.

Avec unbound-control, obtient une copie du cache et regarde dans quel
état est le domaine non fonctionnel.
-- 
ROMEO:  Courage, man; the hurt cannot be much.
MERCUTIO:   No, 'tis not so deep as a well, nor so wide
as a church-door; but 'tis enough, 'twill serve.


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

Re: [FRnOG] [TECH] Ping depuis ibgp/ospf quagga

[Vincent Bernat]

 ❦ 10 août 2017 18:33 GMT, Antoine DURANT  :

> J’ai deux quagga avec un ibgp/ospf, chaque routeur est connecté sur un 
> upstream différent.
>
>
> Via l’ibgp je vois bien les prefixes des différents upstream sur
> chaque routeur, par contre si le prefixe A.A.A.A/24 est plus court via
> provider2/quagga2, si j’essaye de faire un ping de A.A.A.A depuis
> quagga1 cela ne fonctionne pas.
>
> Depuis quagga2 le ping vers A.A.A.A passe sans encombre !
>
>
> interco OSP/BGP : quagga1 (ETH1=192.168.1.1/30)<>(ETH1=192.168.1.1/30) 
> quagga2

Directement sur le Linux, utilise "ip route get A.A.A.A". Tu obtiens
l'IP source qui sera utilisée quand aucune indication n'est donnée. Dans
le cas où cela ne fonctionne pas, ce sera l'IP source de l'interco qui
n'est pas routable. Utiliser "-I" pour forcer l'IP de la loopback en
adresse source.
-- 
Let the data structure the program.
- The Elements of Programming Style (Kernighan & Plauger)


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

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

[Vincent Bernat]

 ❦  5 juillet 2017 14:53 GMT, Sébastien 65  :

> J'explique : Si Debian1 tombe l'IP VIP bascule bien sur Debian2, en
> revanche lorsque Debian1 est de nouveau UP, il récupère l'IP de
> Debian2 (je voudrais éviter cette bascule).
>
>
> J'ai tourné toutes les options de UCARP ou Keepalived avec ou sans le
> preempt cela ne change strictement rien ! Même problème avec KALIVED
> avec les priority/MASTER>BACKUP/BACKUP>BACKUP.

Sur keepalived, pour chaque instance VRRP, il faut mettre "nopreempt",
il ne faut qu'aucun des deux ne se retrouve avec une priorité de 255 et
il faut mettre "state BACKUP" sur les deux.
-- 
Identify bad input; recover if possible.
- The Elements of Programming Style (Kernighan & Plauger)


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

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

[Vincent Bernat]

 ❦ 11 juillet 2017 06:51 GMT, Sébastien 65  :

> Avec la configuration préconisée dans les docs de keep voici l'arp sur le 
> master Deb1 :
>
>
> 10.0.0.2 (incomplete)  
> vrrp.1
> 10.0.0.2 ether   00:60:e0:6b:13:2a   C 
> bond0
>
>
> Sur Deb2 :
>
>
> 10.0.0.6 ether   00:1b:21:9f:cd:95   C 
> bond0
> 10.0.0.1 ether   00:1b:21:9f:cd:95   C 
> bond0

La conf préconisée dans la doc ne peut fonctionner que si bond0 n'a pas
d'IP propre ou si la VIP est une /32 (et non une /29). Sinon, passer
arp_announce à 2 devrait aussi résoudre le problème.
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] BGP et OSPF avec dummy/loopback sous linux

[Vincent Bernat]

 ❦ 12 juillet 2017 10:28 GMT, Antoine DURANT  :

> Je rencontre une difficulté en portant une config bgp/ospf cisco
> fonctionnelle sur du linux quagga. Je pense que mon problème vient de
> la gestion loopback ou dummy sous linux par rapport au lo traditionnel
> du cisco !
>
> Le bloc annoncé en bgp est A.A.A.0/24. Sur chaque quagga j'ai monté une dummy 
> A.A.A.1/24 et A.A.A.2/24.
>
> Je veux mettre en place un ibgp entre 2 quagga. Si j'utilise une
> adresse privé sur eth0 entre les 2 quagga 192.168.1.1/30 et
> 192.168.1.2/30 pour l'ospf la session bgp ne monte pas... Je ne peux
> pas joindre l'ip de l'interface dummy dans face depuis les 2 quagga.

Je ne comprends pas trop ce que tu cherches à faire. Qui est capable de
router le A.A.A.0/24 ? Ton setup ne fonctionne pas car Linux pense que
A.A.A.0/24 est routé sur dummy0, ce qui n'est sans doute pas le
cas. As-tu des routes plus spécifiques ?

Tu devrais utiliser des /32 que tu peux mettre sur dummy ou sur la
loopback. Annonce ces /32 dans OSPF (juste "passive-interface dummy0",
pas besoin de les citer explicitement) et monte les sessions iBGP entre
ces /32. Annonce le réseau A.A.A.0/24 de manière "classique".

Si A.A.A.0/24 contient d'autres préfixes et que tu ne veux annoncer que
la /24, tu peux mettre une route blackhole à la place :

   ip route A.A.A.0/24 blackhole

> Si je met directement une ip du bloc annoncé en bgp j'ai pas de problème 
> l'ibgp monte bien via ospf...
>
> #quagga 1 = eth0
> router ospf
>  ospf router-id A.A.A.1
>  network A.A.A.0/24 area 0.0.0.0
> #quagga 2  = eth0
> router ospf
>  ospf router-id A.A.A.2
>  network A.A.A.0/24 area 0.0.0.0

Je ne vois pas ce qui change avec cette configuration. Le router-id n'a
aucune incidence sur la configuration.
-- 
Patch griefs with proverbs.
-- William Shakespeare, "Much Ado About Nothing"


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

Re: [FRnOG] [TECH] Optimisation bgp avec 2 transits

[Vincent Bernat]

 ❦ 15 juillet 2017 11:43 GMT, Antoine DURANT  :

> Je nage dans le flou lol !
>
>
> une route map OUT peut-elle utiliser des local-preference ?

Peut-être, mais cela sera ignoré.

Pour influencer le trafic entrant, tu dois modifier les annonces de tes
routes (le out) en :

 - ajoutant une ou plusieurs fois ton propre AS en tête (set as-path
   prepend TONAS)

 - en ajoutant une communauté spécifiquement reconnue par ton
   transitaire (qui va soit modifier local-preference pour ton
   transitaire, ce qui n'est utile que si les deux connexions sont chez
   le même transitaire ou alors qui va prepender ton AS selon certains
   critères, notamment pour ne le faire que pour ceux qui ne sont pas
   clients directs de ton transitaire)

Pour influencer le trafic sortant, tu dois modifier les annonces que tu
reçois (le in) en :

 - ajoutant une ou plusieurs fois ton propre AS en tête

 - en modifiant la valeur de local preference

Pour le trafic entrant, prepender une fois est le plus simple, mais
regarde les communautés que proposent tes transitaires. Pour le trafic
sortant, il est plus simple de n'avoir qu'une seule stratégie, à savoir
modifier local preference. Si tu veux favoriser les routes qui sont en
direct, fait une règle qui passe local-preference à 500 quand l'AS path
ne contient qu'un seul AS.
-- 
Don't compare floating point numbers just for equality.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Optimisation bgp avec 2 transits

[Vincent Bernat]

 ❦ 16 juillet 2017 08:09 GMT, Antoine DURANT  :

> OK, donc local-pref de 50 sur transit2 et local-pref de 100 sur
> transit dans une route-map IN, permet de laisser prioritaire transit1.

C'est dommage de faire ainsi car tu vas envoyer tout sur transit1, même
les clients de transit2. Tu devrais utiliser les communautés envoyées
par chaque transitaire pour faire un choix plus éclairé. Tes
transitaires vont envoyer des communautés spéciales pour les routes
qu'ils ont directement avec leur client. Tu peux alors adapter la
local-pref sur ce critère.

ip community-list 1 permit 174:21101
ip community-list 110 deny
route-map COGENT-IN permit 10
  match community 1
  set local-preference 110
route-map COGENT-IN permit 20

ip community-list 2 permit 8218:100
ip community-list 2 permit 8218:101
ip community-list 2 permit 8218:10
ip community-list 2 deny
route-map NEO-IN permit 10
  match community 1
  set local-preference 110
route-map NEO-IN permit 20

Si tu as un jour une présence sur un IX, tu pourras faire:

route-map FRANCEIX-IN permit 10
  set local-preference 200

Note que tu as aussi possibilité de casser une égalité avec le MED. Cela
permet de laisser jouer l'AS path et de casser les égalités en faveur
d'un des transitaires.

router bgp 
  bgp always-compare-med

route-map COGENT-IN permit 10
  set metric 100
route-map NEO-IN permit 10
  set metric 50

Ainsi, en cas d'égalité sur la taille de l'AS path, le trafic ira vers
Neo. Note que tes transits peuvent envoyer des valeurs pour MED, tu dois
donc toujours avoir une route-map qui "set metric X" car tu ne maitrises
pas la valeur que peut avoir cet attribut.

> Sur le transit2 faire un prepend dans une route-map OUT afin que le
> trafic passe plutôt par transit1.

En out, par contre, le prepend est sans doute tout à fait suffisant
étant donné que tes transitaires feront sans doute ce qu'il faut pour
être efficace. Si besoin, sache qu'il y aussi des communautés que tu
peux placer pour les influencer.
-- 
Make sure special cases are truly special.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] RFC 8195: Use of BGP Large Communities

[Vincent Bernat]

 ❦  1 juillet 2017 11:03 +0200, Stephane Bortzmeyer  :

> Des exemples de politiques d'affectation de vos grandes communautés
> BGP (qui sont mieux que les communautés étendues, comme chacun sait)
>
> http://www.bortzmeyer.org/8195.html

Tu n'as pas souvent de retours ici sur tes articles, mais le contenu est
toujours appréciable. Je n'avais jamais pris le temps d'aller voir ce
qu'étaient ces "large communities". Me voilà informé et j'attends avec
impatience que ça arrive chez certains constructeurs.
-- 
Write and test a big program in small pieces.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Pénurie/doublons de vlan

[Vincent Bernat]

 ❦ 29 juin 2017 00:26 +0200, Guillaume Barrot  :

> Sinon une solution quand on a pas un radis, c'est de fabriquer son routeur
> maison.
>
> - DPDK pour le forwarding (http://dpdk.org/)
> - https://github.com/FRRouting/frr pour le control plane
> - TC pour la QoS (http://lartc.org/lartc.html#LARTC.QDISC)
>
> Ca fait pas réver, mais un monoproc avec 64Go de RAM, et 2 x Dual 10G, ça
> va tourner dans les 1000€ chez le broker du coin (et encore).
> Ca sera pas aussi joli qu'un ASR9K ou un MX, mais au moins, ça pourra
> dépanner le temps de.

Je sais pas comment tu comptes assembler tout ça, mais DPDK ne forwarde
rien tout seul, FRR ne cause pas DPDK et TC est court-circuité par
DPDK.

S'il n'y a pas utilisation de Netfilter, un hexacore doit pouvoir
pousser 40G avec Linux sans trop de soucis dans des conditions
défavorables.

Si l'on veut mieux, faut regarder des projets type VPP (fd.io), Packet
Journey (de Gandi) ou Snabb Switch (qui sait aussi router).
-- 
There are more things in heaven and earth,
Horatio, than are dreamt of in your philosophy.
-- Wm. Shakespeare, "Hamlet"


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

Re: [FRnOG] [TECH] Gérer le cas d'une rupture de liaison entre deux routeurs d'un même AS

[Vincent Bernat]

 ❦  5 juillet 2017 18:20 GMT, Aymeric Maure  :

> J'ai actuellement un réseau sur deux sites physiques distincts reliés
> par fibre noire en double adduction. Tous mes transits sont
> actuellement sur le site A ce qui me chagrine un peu. Et j'aurais donc
> bien aimé me faire livrer un des transits sur le site B.
>
>
> Problème : J'ai eu pour l'instant plus de problèmes liés à l'interco
> optique que de panne complète d'un des routeurs... Clairement mon
> routeur est plus "stable" que mon lien optique. (Ce qui ne veut pas
> dire que le lien optique est particulièrement instable mais il m'a
> ennuyé plus souvent).
>
>
> En donc l'idée est que en pratique je connecte Routeur A et Routeur B
> en iBGP mais que va t'il se passer un jour ou mon lien optique n'est
> plus disponible ? Logoiquement AS plus connecté et tout s'effondre (en
> théorie). Mon but c'est évidemment que mes deux sites restent
> connectés à Internet et vivent leur vie séparément le temps que l'on
> répare le tout.
>
>
> Quelle est la façon "propre" de faire cela ? Cad d'avoir deux sites
> avec leur propres transit, habituellement connectés mais qui puissent
> se comporter comme deux iles le temps que l'on répare ?

La solution "propre" est de prendre un second AS (et transformer le lien
iBGP en lien eBGP). Cela te fait deux AS à gérer.

Sinon, ne pas annoncer les mêmes IP des deux côtés et faire accepter les
boucles au niveau des AS par tes routeurs ("family inet unicast loops X"
chez Juniper, "allowas-in" chez Cisco). Quand le lien est down, le
trafic passera par les transitaires.
-- 
10.0 times 0.1 is hardly ever 1.0.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [BIZ] bloc d'IP à céder

[Vincent Bernat]

 ❦  7 août 2017 09:03 +0200, Thierry Del-Monte  :

> Les règles du RIPE sont pourtant claires :
> https://www.ripe.net/manage-ips-and-asns/resource-management/faq/faq-general-resources/can-i-buy-ip-addresses-from-the-ripe-ncc

Cela indique seulement que le RIPE ne vend pas directement des IP. La
vente d'adresses IP est parfaitement acceptées et documentée :

 https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/brokers
-- 
Harp not on that string.
-- William Shakespeare, "Henry VI"


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

Re: [FRnOG] [TECH] Découpage /22

[Vincent Bernat]

 ❦ 15 mai 2017 14:19 +0200, Richard MATOS  :

> Nous avons acquis récemment un /22 et maintenant je dois réfléchir à le
> découper de manière "intelligente"afin d’éviter de gaspiller des ip avec
> des découpage trop petits.
> Tout ceci en sachant que nous allouerons une partie pour les interco et
> l'autre pour de l'hébergement.

Tu peux économiser pas mal d'IP pour les intercos en utilisant des
interfaces "unnumbered". Cela marche sans soucis avec du Linux, du
Cisco, du Cumulus et ça marche au petit bonheur la chance chez Juniper
(pas de soucis sur du MX, des restrictions arbitraires sur les QFX, pas
de support sur les EX).
-- 
Kiss me, Kate, we will be married o' Sunday.
-- William Shakespeare, "The Taming of the Shrew"


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

Re: [FRnOG] [TECH] Découpage /22

[Vincent Bernat]

 ❦ 15 mai 2017 16:39 +0200, Alarig Le Lay  :

>> Tu peux économiser pas mal d'IP pour les intercos en utilisant des
>> interfaces "unnumbered".
>
> Qu’est-ce que tu entends par « unnumbered » ? Tu n’as pas d’IPs sur ton
> lien entre les routeurs ?

Oui. Ton routeur n'a qu'une IP sur la loopback et les autres interfaces
"empruntent" cette IP.
-- 
Perilous to all of us are the devices of an art deeper than we ourselves
possess.
-- Gandalf the Grey [J.R.R. Tolkien, "Lord of the
Rings"]


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

Re: [FRnOG] [TECH] Découpage /22

[Vincent Bernat]

 ❦ 15 mai 2017 17:06 +0200, Alarig Le Lay  :

>> Oui. Ton routeur n'a qu'une IP sur la loopback et les autres interfaces
>> "empruntent" cette IP.
>
> Du coup, tu rajoutes une route en /32 via cette interface pour parler au
> routeur en face ?

Oui. Cela peut être aussi géré automatiquement par OSPF.
-- 
Make sure all variables are initialised before use.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] postfix - archivage des queues pour rejeu en cas d'incident

[Vincent Bernat]

 ❦ 12 juin 2017 16:40 GMT, DELMAS JACQUES  :

> En effet notre souhait est de pouvoir rejouer l'intégralité des emails
> même ceux délivrés afin de pallier le manque de solidité d'une
> infra. Aujourd'hui nous gardons les emails pendant 4 jours si le
> serveur ne répond pas mais notre objectif est d'être capable de
> rejouer les emails lorsque la boite destination a été pleine ou que le
> serveur renvoyait un rejet de l'email (blacklist du serveur
> d'émission, faux positif en spam ou en virus ou autre problème de ce
> type).

S'il s'agit de reessayer les mails qui ont eu un 5xx, il y a
smtp_delivery_status_filter (ou simplement soft_bounce = yes). Le soucis
avec cette méthode, c'est que l'expéditeur ne sera pas prévenu
immédiatement d'un problème trivial (typo dans l'adresse
email). Cependant, smtp_delivery_status_filter devrait être assez
flexible pour ne gérer que les cas de blacklist/boîte pleine.

Pour ce qui est de stocker tous les mails, c'est possible en utilisant
"always_bcc" vers un utilisateur local. Les mails seront alors
disponibles au format mbox. C'est un généralisation de
recipient_bcc_maps.
-- 
Make it clear before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


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