Re: [FRnOG] [TECH] Tencent sur aucun IX en France ?

[Vincent Bernat]

On 2024-01-22 09:40, David Ponzone wrote:

En plus, je viens de voir qu’ils s’amusent bien avec leurs annonces:
tous leurs biocs sont désagrégés, et annoncés à différents transits, un
peu comme on faisait pour optimiser le load-balancing à la fin des
années 90…..

On fait comment de nos jours ?

J’avais la faiblesse de penser que le ratio coût de la bande passante/besoin 
avait largement diminué.


Quand on a besoin de beaucoup de BP, c'est mieux de répartir sur 
plusieurs routeurs et dans ce cas, on ne peut pas forcément compter sur 
ceux en face pour répartir correctement le trafic.



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

Re: [FRnOG] [TECH] Tencent sur aucun IX en France ?

[Vincent Bernat]

On 2024-01-20 16:41, David Ponzone wrote:

En plus, je viens de voir qu’ils s’amusent bien avec leurs annonces:
tous leurs biocs sont désagrégés, et annoncés à différents transits, un
peu comme on faisait pour optimiser le load-balancing à la fin des
années 90…..


On fait comment de nos jours ?


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

Re: [FRnOG] [MISC] "Récupération de vos documents"

[Vincent Bernat]

On 2023-10-06 11:15, Frédéric de Villepreux wrote:

Pour clore ce fil,
inutile à la fin,
voici le retour de l'intéressé.


Avez-vous eu son autorisation pour diffuser publiquement sa réponse ?


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

Re: [FRnOG] [TECH] LACP et EVPN

[Vincent Bernat]

On 2023-07-20 16:12, Lucas REYMOND wrote:
Ma question est la suivante et je pense découle d'une méconnaissance du 
protocole LACP, Comment les PEs peuvent monter un LACP "commun" alors 
qu'ils n'échangent manifestement aucune information ?


Ils n'ont besoin de rien échanger car tu configures le system-id 
manuellement sur chaque PE (pour qu'il soit identique). C'est la seule 
chose nécessaire à partager pour que deux ports soient considérés dans 
la même agrégation de lien.



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

Re: [FRnOG] [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

[Vincent Bernat]

On 2023-06-26 19:52, Vincent Bernat wrote:

Mon anti-ddos que j'ai payé une blinde gère pas ca correctement, 
alors j'ai désactivé IPv6



Je ne suis pas d'accord avec ta traduction mais intéressé par la 
solution que tu aurais appliquée.


Pourrais-tu éventuellement m'indiquer ton anti-ddos (si possible 
gratuit comme le mien) qui permet de parer jusqu'à 2^64 pirates sans 
solliciter solliciter d'avantage de ressource que de les ignorer en 
bloc ?


Bah facile, tu bloques les /64. L'assignement des /64 se fait par 
utilisateur (que ce soit côté serveur ou côté client). Tu blacklistes 
autant de monde sur un /64 IPv6 que sur une /32 IPv4.


Je n'avais pas manifestement compris ta remarque dans le bon sens. Une 
correction donc :


1. Moins de pirates en IPv6 qu'en IPv4
2. À population égale, pourquoi tu aurais plus de /64 IPv6 utilisées que 
de /32 IPv4 ?



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

Re: [FRnOG] [TECH] Mise en œuvre d'IPv6 dans les infrastructures mail

[Vincent Bernat]

On 2023-06-26 19:18, Laurent Barme wrote:

Mon anti-ddos que j'ai payé une blinde gère pas ca correctement, alors 
j'ai désactivé IPv6



Je ne suis pas d'accord avec ta traduction mais intéressé par la 
solution que tu aurais appliquée.


Pourrais-tu éventuellement m'indiquer ton anti-ddos (si possible gratuit 
comme le mien) qui permet de parer jusqu'à 2^64 pirates sans solliciter 
solliciter d'avantage de ressource que de les ignorer en bloc ?


Bah facile, tu bloques les /64. L'assignement des /64 se fait par 
utilisateur (que ce soit côté serveur ou côté client). Tu blacklistes 
autant de monde sur un /64 IPv6 que sur une /32 IPv4.



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

Re: [FRnOG] [TECH] Vos retours sur StarLink ?

[Vincent Bernat]

On 2023-03-01 16:23, Minh-Truong LAM wrote:

J'arrive de mon côté à monter de l'ipsec en mode dialup sans pbs, par
contre je rencontre un souci en terme de perf.
Je sature autour de 20Mbps pour mon trafic tunnelisé (pas de saturation au
niveau du concentrateur) versus 150Mbps pour l'accès internet "direct"
Starlink.

Pour ceux qui ont monté de l'ipsec vous avez pu constater des perfs
similaires ? Pour ceux qui font du WG vous avez une idée des perfs dessus ?


Sous Linux, malheureusement, l'implémentation IPSec est monothreadé par 
défaut. Il est possible de passer en multithread by pcrypt, mais les 
perfs scalent très mal en raison d'un code qui fait beaucoup appel aux 
locks. WireGuard a été écrit avec le multithread dès le départ et ne 
souffre pas de ce problème.


https://wiki.strongswan.org/projects/strongswan/wiki/Pcrypt

Sur le papier, IPSec sait utiliser les mêmes ciphers que WireGuard, donc 
les perfs devraient être similaires. IPSec peut même avoir des perfs 
meilleures via des ciphers qui sont accélérés matériellement, tels que 
AES-GCM.



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

Re: [FRnOG] [TECH] Recherche solution "PCAP -> IPFIX/NETFLOW"

[Vincent Bernat]

On 2023-01-06 17:54, sbu sbu wrote:

Je suis à la recherche d'une solution qui saurait prendre du PCAP en entrée
(10 x TAP optique 10G mono et multi) et le convertir en Flow. pour
l'envoyer vers un seul puits de stats.
J'ai bien pensé à prendre des switch mais ceux que j'ai, ont besoin d'une
licence pour le flow, que je n'ai pas, qui coûte un bras. Et je ne suis
même pas certain de pouvoir récupérer le flux des Tap et le NetFlowiser.
En gros l'idéal serait des Gigamon lite  pour ceux qui connaissent, sans
les fonctions des flux metadata et pour beaucoup mon cher.
Pour info ce constructeur me propal plus de 200k€ sur 3 ans (achat +
support de 2 boites)... (volume de data 10G en burste sur l'aggregation des
10 points de collecte)
Si quelqu'un à déjà utilisé d'autre techno basique ou on intervient
uniquement sur l'échantillonnage. Solution hardware, boîtier matriciel
comme les Gigamon ou single ou même une solution software qui fonctionne,
je suis preneur du retour d'expérience.


pmacct sait lire des pcap (pcap_savefile) et exporter en IPFIX 
(nfprobe_receiver + nfprobe_version).



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

Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1 dans RouterOs 7.4

[Vincent Bernat]

On 2022-08-30 08:17, Vincent Bernat wrote:
Je ne suis pas sur d'avoir bien tout compris mais il semble bien que 
le fameux algo de hash sha1 ou sha2-256 ou autre soit inclus dans le 
"rsa_signature_blob"


Cette partie est utilisée dans le protocole SSH lors de 
l'authentification, pas dans le format de la clef.


Dans le code source de OpenSSH:

#v+
static const struct keytype keytypes[] = {
...
{ "ssh-rsa", "RSA", NULL, KEY_RSA, 0, 0, 0 },
{ "rsa-sha2-256", "RSA", NULL, KEY_RSA, 0, 0, 1 },
{ "rsa-sha2-512", "RSA", NULL, KEY_RSA, 0, 0, 1 },
{ "ssh-dss", "DSA", NULL, KEY_DSA, 0, 0, 0 },
...
#v-

Donc les trois types sont mappés sur KEY_RSA. Hors signature par une CA 
(avec -s), il n'y a pas de différence entre ces 3 options.



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

Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1 dans RouterOs 7.4

[Vincent Bernat]

On 2022-08-30 03:21, Pierre Colombier via frnog wrote:

Je ne suis pas sur d'avoir bien tout compris mais il semble bien que le 
fameux algo de hash sha1 ou sha2-256 ou autre soit inclus dans le 
"rsa_signature_blob"


Cette partie est utilisée dans le protocole SSH lors de 
l'authentification, pas dans le format de la clef.



aug/30 01:23:26 ssh,debug pki algorithm: ssh-rsa


Ca ressemble pas aux messages de debug de OpenSSH. C'est un OpenSSH qui 
tourne sur les Mikrotik ? Elle fait quelle taille cette vieille clef ? 
Les releases notes de la 7.4 disent que le change ne concerne que ceux 
qui ont activé strong-crypto=yes, est-ce ton cas ?



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

Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1

[Vincent Bernat]

On 2022-08-29 23:13, Pierre Colombier via frnog wrote:

En d'autres termes, quand il y a bien longtemps, sur une debian 8 far 
far away, j'ai fait un


ssh-keygen -t rsa -b 4096

ou bien aujourd'hui sur une debian 11

ssh-keygen -t rsa-sha2-256 -b 4096


C'est exactement pareil que -t rsa ou -t ssh-rsa car une clef RSA, ce 
sont deux nombres. Il n'y a pas de hash. Le -t rsa-sha2-256 est utilisé 
quand on signe des clefs avec un certificat.


je crée toujours une clé rsa de 4096 bits, j'ai bien toujours un fichier 
id_rsa.pub qui a le même format et commence par "ssh-rsa", mais par 
contre, il y a bien une différence, car quand bien même le client ssh 
serait récent, la première a cessé d'être acceptée par les serveur ssh 
récents, alors que la seconde fonctionne bien.


donc, le "public key blob" quand bien même il ne change pas de format, 
embarque bien quelque chose qui est basé sur un hash sha1 ou sha256 (ou 
autre).


Refait la même chose avec -t ssh-rsa et cela fonctionnera aussi. Ce 
n'est pas pour ça que ta clef n'est plus acceptée. C'est soit qu'elle 
est trop petite, soit que ce n'est pas elle qui est dans le known hosts.
Ou alors, le "blob" contient juste la clé publique + une étiquette qui 
dit quel algo de hash on est sensé employer et dans ce cas j'aurais bien 
aimé modifier mon fichier .pub pour employer le nouvel algo tout en 
gardant la même clé. ça me rendrait la migration beaucoup plus simple.


Nope. Le format est dans la RFC 4253. Ce sont deux nombres encodés.
https://datatracker.ietf.org/doc/html/rfc4253#section-6.6


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

Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1

[Vincent Bernat]

On 2022-08-29 18:51, Pierre Colombier via frnog wrote:


D'ailleurs ma nouvelle clé publique type "rsa-sha2-256" commence bien  > par 
"ssh-rsa B3NzaC1yc2EAA.."


Il n'y a pas de SHA dans une clef publique RSA. Une clef publique RSA, 
ce sont deux grands entiers. Ce que peut refuser un serveur, c'est une 
clef publique trop courte. Depuis quelques années, la longueur minimale 
pour une clef RSA est de 1024 bits (contre 768 auparavant).


Ma question "académique" est que je ne comprends pas d'où vient ce 
besoin d'une signature/hash ? que ce soit md5, sha1, sha256 ou autre, en 
quoi l'algo rsa seul n'est-il pas suffisant ?


RSA est un algorithme de chiffrement/signature à clef publique. Il est 
trop lent pour tout chiffrer avec. Le chiffrement des données en SSH 
s'effectue avec une clef partagée qui est négociée à la création de la 
session (c'est la partie Diffie-Hellman, pas concernée ici). La clef RSA 
est utilisée dans ce contexte pour authentifier l'utilisateur et le 
serveur avec une signature. Signer quelque chose avec une clef RSA, 
c'est appliquer une fonction de hash sur des octets et ensuite les 
chiffrer avec la clef privée. La vérification est faite avec la clef 
publique. C'est cette signature qui a besoin d'une fonction de hash.



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

Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1

[Vincent Bernat]

On 2022-08-29 15:25, Pierre Colombier via frnog wrote:


du coup, si tous les usagers ont des clées rsa installées et si ssh est
la seule façon d'administrer le routeur, et bien on perds toute 
possibilité d'accès

après la mise à jour.


Ce ne sont pas les clefs "ssh-rsa", c'est l'algo de signature à clef 
publique ssh-rsa qui est désactivé par défaut. Pour se connecter à un 
vieux serveur qui n'accepte pas d'algo plus moderne, on peut toujours 
utiliser "-o HostKeyAlgorithms=+ssh-rsa" pour le réactiver.


Le format de clef ssh-rsa n'est pas prévu d'être déprécié. Il n'y a pas 
d'utilisation de SHA1 dans les clefs ssh-rsa.



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

Re: [FRnOG] [TECH] ARP Negative Caching

[Vincent Bernat]

On 6/30/22 21:41, David Ponzone wrote:

Hmm donc ils ont 2 IPs, une privée dans un /24 ou autre pour monter le iBGP et 
un alias à /32 qui va être annoncé ?


Pas forcément, tu peux enlever entièrement le L2. /31 avec le switch en 
face. Ou simplement utiliser le link-local IPv6 pour la session BGP et 
annoncer ta /32 dedans.



Mais je vois 2 problèmes:
-tu maitrises pas l’OS et donc tu peux pas mettre Quagga/Bird/autre


Après, ce qui est possible sur les hyperviseurs est aussi possible sur 
les switchs. GW en anycast sur chaque port en /24 avec proxy ARP, route 
statique vers le host et redistribute des statiques en question en BGP, 
relai DHCP. Il te manque à trouver comment éviter que le faux /24 sur 
chaque port ne génère de l'ARP quand le client scanne son propre /24. 
Sur des switchs Linux type Cumulus, cela est possible en indiquant de ne 
pas installer la route connected qui correspond.



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

Re: [FRnOG] [TECH] ARP Negative Caching

[Vincent Bernat]

On 6/30/22 21:16, Vincent Bernat wrote:

Si tu veux dire: construire une table de /32 à blackholer que j’envoie 
en iBGP à mes routeurs BGP avec blackhole comme NH, pour bloquer les 
paquets en ingress grâce à uRPF, j’aurais bien aimé, mais mes routeurs 
BGP ont un bug au niveau uRPF et ça marche pas comme prévu.

Faut que je vois si un upgrade récent corrige ça.


Non, je veux dire que tu ne fais plus de L2, mais que tu laisses tes 
serveurs annoncer leur IP en BGP en /32. Un serveur qui n'existe pas n'a 
pas de route et son trafic est blackholé. Tu peux filtrer les annonces 
pour n'accepter que le "/24" du LAN et tu as une sécurité équivalente à 
du L2.


Je réponds au mauvais message... Désolé.


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

Re: [FRnOG] [TECH] ARP Negative Caching

[Vincent Bernat]

On 6/30/22 21:01, David Ponzone wrote:

Si tu veux dire: construire une table de /32 à blackholer que j’envoie en iBGP 
à mes routeurs BGP avec blackhole comme NH, pour bloquer les paquets en ingress 
grâce à uRPF, j’aurais bien aimé, mais mes routeurs BGP ont un bug au niveau 
uRPF et ça marche pas comme prévu.
Faut que je vois si un upgrade récent corrige ça.


Non, je veux dire que tu ne fais plus de L2, mais que tu laisses tes 
serveurs annoncer leur IP en BGP en /32. Un serveur qui n'existe pas n'a 
pas de route et son trafic est blackholé. Tu peux filtrer les annonces 
pour n'accepter que le "/24" du LAN et tu as une sécurité équivalente à 
du L2.



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

Re: [FRnOG] [TECH] ARP Negative Caching

[Vincent Bernat]

On 6/30/22 20:02, David Ponzone wrote:

Je viens d’entrer en guerre contre le broadcast inutile, juste pour le fun.
J’en ai marre de me taper un broadcast sur tout le LAN à chaque fois qu’un 
Kevin quelque part envoie un paquet SYN ou autre vers une IP non-utilisée sur 
mon réseau.

Donc je me demandais si des constructeurs avaient eu l’idée d’implémenter du 
negative caching dans la table ARP de leurs routeurs.
Evidemment, ça a des effets secondaires pénibles le jour où on veut se mettre à 
utiliser l’IP, mais avec un cache à 60/120/180s, c’est acceptable (ça dépend 
des usages évidemment).
Je vais appeler Cisco pour leur dire d’ajouter ça dans l’IOS pour le mois 
prochain, mais avant, je me demande si je dis une connerie parce qu’il y a une 
conséquence pas du tout acceptable sur un réseau en prod.

Sinon y a une autre solution à laquelle je pense pas ?
J’ai bien pensé ajouter des entrées statiques dans mes routeurs, mais ça va 
rien changer.
Le routeur va envoyer un unicast, qui va devenir un broadcast sur le premier 
switch. Et pareil pour les paquets suivants.

Idées ingénieuses (encore une fois, juste pour le principe) ?


Passe en full L3, default route en blackhole.


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

Re: [FRnOG] [MISC] libreNMS

[Vincent Bernat]

 ❦ 29 November 2021 03:17 GMT, Michel Py via frnog:

>> Cécile Martron
>> CCIE Datacenter
>> Ingénieure Systéme Réseaux et Télécommunication
>> +33 (0) 6 85 44 33 38
>
> Euh, juste par curiosité, c'est quoi ton numéro de CCIE ?
>
> Le mien, c'est #6673
> https://www.cciehof.com/
>
> Gougleu "cecile martron ccie" : resultat zero sauf _une_ contrib sur
> cette liste. C'est bien de se toucher le clitoris en rêvant qu'un jour
> on va devenir CCIE, mais passer le lab c'est une autre histoire.

Je suis toujours impressionné comment tu parviens à repousser
régulièrement les limites de l'indécence sur cette liste.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] Dans la série est-ce bien ou pas le draft sur 127/8...

[Vincent Bernat]

 ❦ 19 November 2021 18:53 GMT, Michel Py via frnog:

>> On me glisse dans l’oreille qu’entre les gros eyeballs et les gros CDN, 
>> c’est du peering privé.
>
> C'est clair, mais ça ne veut pas dire que ça ne touche pas le switch d'AMS-IX 
> :
>
>> Private Interconnect : A secure and cost-effective solution to interconnect 
>> directly with your
>> peers, customers, suppliers or business partners. How it works : A Private 
>> Interconnect enables
>> direct traffic exchange between two networks over a dedicated VLAN on our 
>> platform.
>
> Ce n'est plus le cross-connect de papa ou on mettait une jarretière
> dans la MMR.

99% des PNI sont des jarretières dans la MMR. Les IX ne voient passer le
trafic entre les ISP et les gros fournisseurs de contenu. Par exemple,
au delà de 1 Gbps de trafic, Google demande un PNI cross-connect de
papa (parce que le but, c'est de pas bouffer la BP de l'IX pour laisser
la place à la long tail).
-- 
"... an experienced, industrious, ambitious, and often quite often
picturesque liar."
-- Mark Twain


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

Re: [FRnOG] [MISC] Dans la série est-ce bien ou pas le draft sur 127/8...

[Vincent Bernat]

 ❦ 19 November 2021 17:18 GMT, Michel Py:

>>>> Vivien, du forum lafibre.info, maintient un document avec les stats par 
>>>> pays : 
>>>> https://lafibre.info/images/ipv6/statistiques_ipv6.pdf?version=last
>>>> La méthode et les sources sont décrites ici : 
>>>> https://lafibre.info/ipv6/ipv6-pays/
>>>> Taux d’utilisation d’IPv6 pour l’accès à Internet (mesuré au niveau d’un 
>>>> fournisseur de contenu qui propose IPv6)
>
>>> Michel Py a écrit :
>>> Autre méthode de faire mentir les chiffres : on mesure le trafic chez un 
>>> fournisseur
>>> qui a v6, et on "oublie" de mesurer le trafic chez ceux qui ne l'ont pas.
>>> Moi, je regarde ça : https://stats.ams-ix.net/sflow/ether_type.html
>>> C'est l'ensemble de l'IX y compris les intercos.
>
>> Vincent Bernat a écrit :
>> Difficile de faire moins représentatif. La quasi totalité du trafic des ISP 
>> passe en dehors des IX.
>
> Et les FAI ils se connectent ou à l'Internet si ce n'est pas dans un IX ?
> AMS-IX c'est 10 Térabits de trafic et il y a 883 ASNs sur 16
> datacenters, mais à part ça ce n'est pas représentatif. Bravo.

Les FAI achètent du transit auprès de tiers 1 comme pas mal de monde.
Ils négocient aussi des PNI avec certains gros producteurs de trafic
(type Netflix, Google, Facebook).
-- 
No violence, gentlemen -- no violence, I beg of you!  Consider the furniture!
-- Sherlock Holmes


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

Re: [FRnOG] [MISC] Dans la série est-ce bien ou pas le draft sur 127/8...

[Vincent Bernat]

 ❦ 18 November 2021 23:40 GMT, Michel Py via frnog:

>> Guy Larrieu a écrit :
>> Vivien, du forum lafibre.info, maintient un document avec les stats par pays 
>> : 
>> https://lafibre.info/images/ipv6/statistiques_ipv6.pdf?version=last
>> La méthode et les sources sont décrites ici : 
>> https://lafibre.info/ipv6/ipv6-pays/
>> Taux d’utilisation d’IPv6 pour l’accès à Internet (mesuré au niveau
>> d’un fournisseur de contenu qui propose IPv6)
>
> Autre méthode de faire mentir les chiffres : on mesure le trafic chez
> un fournisseur qui a v6, et on "oublie" de mesurer le trafic chez ceux
> qui ne l'ont pas.
>
> Moi, je regarde ça : https://stats.ams-ix.net/sflow/ether_type.html
> C'est l'ensemble de l'IX y compris les intercos.

Difficile de faire moins représentatif. La quasi totalité du trafic des
ISP passe en dehors des IX.
-- 
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] [TECH] RFC 9107: BGP Optimal Route Reflection (BGP ORR)

[Vincent Bernat]

 ❦ 14 September 2021 18:26 +02, Raphael Mazelier:

>> ORR on utilise depuis que nos rr ipv4 sont passés off-path, mais
>> uniquement pour les routeurs qui ne supportent pas add-path, parce que
>> add-path est tout de même mieux, plus déterministe. Il ne dépend pas
>> de l'igp, tu fais ce que tu veux avec les LP.
> Ah intérressant. En effet dans ce cas ORR est utile sinon j'avais
> toujours considéré qu'avec add-path c'était un peu une feature
> inutile. Bon peut etre qu'il faudrait virer les routeurs qui ne
> supportent pas add-path parce que c'est pas tout jeune non plus mais
> sur un gros backbone j'entends que ce ne soit pas forcément facile.

Certains vendeurs ne supportent pas (p'tet au passé, pas checké
récemment) add-path dans une "routing-instance". Pénible.
-- 
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] Geolocalisation IP sur les plateformes de streaming

[Vincent Bernat]

 ❦ 24 August 2021 10:59 +02, Julien Escario:

> Est-ce qu'il y a ici des gens qui savent quelle service utilisent les
> plateformes de streaming pour déterminer si une IP est utilisée en tant
> que VPN/Proxy ou a accès à un catalogue ?
>
> Depuis la mi-juillet, nous avons identifié au moins deux plateformes
> (Netflix et FranceTV) qui interdisent l'accès à des IPs dans un subnet
> chez nous (185.123.87.0/24) et je ne parviens pas à en connaître la
> raison exacte.
>
> RIPE DB propre (obviously) et Maxmind nous situe bien en France. J'avoue
> que je ne vois pas trop quoi d'autre modifier pour qu'ils remettent le
> sub dans la bonne catégorie.

Il y a plein de bases différentes et les content providers sont plutôt
discrets pour te dire quelle base ils utilisent. Il y a quelques indices
sur comment faire corriger la base de chaque provider ici (plutôt
orienté US) :

https://thebrotherswisp.com/index.php/geo-and-vpn/

Pour FranceTV, je n'ai jamais trouvé un contact. Pour Netflix, c'est
normalement rapide si tu as effectivement des utilisateurs dans ce
range. Cela vaut le coup de faire chacun des providers de la liste
préventivement et de proposer systématiquement un geofeed pour éviter
d'avoir à refaire la démarche régulièrement.
-- 
Condense soup, not books!


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

Re: [FRnOG] [MISC] 40.94.101.0/24 ?

[Vincent Bernat]

 ❦ 31 July 2021 22:16 GMT, Michel Py via frnog:

> Bon c'est sur que microchiotte, dans leur grande sagesse, ils auraient
> pu mettre un reverse DNS qui voulait dire quelque chose, et un truc
> dans la requête qui expliquerait ce que leur bot fait; mais je ne
> trouve pas le principe répréhensible.

Comme ça, quand tu veux héberger un malware, tu peux les identifier
direct et renvoyer une photo de hérisson.
-- 
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] Fwd: Jarretières pour Turris Omnia, was [FRsAG] [Matos] La jarretière suivi de ?

[Vincent Bernat]

 ❦ 15 July 2021 21:42 GMT, Michel Py via frnog:

> En descendant (opérateur -> client) 1490nm Tx 2.5G Tx. En montant (client -> 
> opérateur) 1310nm Rx 1.25G Rx.
> Cette optique : https://www.fs.com/products/64169.html c'est donc une
> optique pour le coté opérateur, ce qui pourrait expliquer le prix; je
> pense que le laser de transmission doit patater plus à cause des
> divisions de la fibre.

Bien vu. C'est écrit OLT.

> Du coté CPE, c'est l'inverse.
> En montant (client -> opérateur) 1310nm Tx 1.25G Tx. En descendant (opérateur 
> -> client) 1490nm Rx 2.5G Rx.
>
> Si tu veux essayer de bidouiller une optique Ethernet en GPON coté client, 
> c'est donc celle-ci qu'il faut essayer :
> https://www.fs.com/products/15535.html

Aucune chance de marcher. Le SFP GPON gère aussi toute la surcouche
protocolaire liée au L1, avec le déchiffrement et le TDMA.
-- 
Say what you mean, simply and directly.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Fwd: Jarretières pour Turris Omnia, was [FRsAG] [Matos] La jarretière suivi de ?

[Vincent Bernat]

 ❦ 15 July 2021 20:02 +02, N R:

> Ca fait un petit moment que je regarde ce qui se passe, mais là je fais
> appel à vous.
> Je viens de craquer pour un routeur avec un connecteur SFP (le omnia Turris
> de chez .cz).
> J'ai une arrivé fibre avec un joli connecteur de type SC(fourni par R=D).
>
> Maintenant comment fais-je pour insérer la jarretière dans le connecteur ?
> J'ai cru comprendre qu'il y avais une sorte de chaussette mais étant plus
> un gars du système ma matière grise ne demande qu'à apprendre.
>
> J'ai trouvé une liste de modules supporté[1], cependant n'étant pas un
> "expert", je préfère étayer le sujet. Premièrement elle est un poil
> restreinte et je suis convaincu que d'autre modules son disponible et
> fonctionnel.
>
> Je dispose du boitier de l'opérateur[2] comme solution en attendant, mais
> j'apprécierais vraiment de le remplacer par un simple module pour caler
> tout le "bazar" dans le boitier technique.

Le problème n'est pas que de choisir un SFP qui soit compatible avec la
Turris, il faut aussi s'assurer qu'il sera accepté dans le réseau de
l'opérateur. Soit il y a un secret partagé entre l'ONT et l'OLT (l'autre
côté) et il faut être capable de le reprendre et de le programmer dans
le SFP via la Turris. Soit c'est le numéro de série qui est utilisé et
il faudra pouvoir le faire changer par l'opérateur.

Perso, vu que ce le boitier n'est qu'un CPE plutôt basique qui ne fait
que du L2, je le laisserais en place. Tu colles ta Turis derrière.

> Je suis tombé sur le fabricant "FS", mais entre les modules optique et les
> modules PON je m'y perd.

A priori, celui-ci serait OK.

https://www.fs.com/products/64169.html

Mais il existe bien plus économique en cherchant les SFP utilisés par
Orange pour ses Livebox :

https://www.ebay.fr/itm/203524169344?hash=item2f62fc5e80:g:0G8AAOSw3B5fIAdz

Ça te permet d'essayer sans risquer grand chose. Ils sont capables de
programmer une clef
-- 
question = ( to ) ? be : ! be;
-- Wm. Shakespeare


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

Re: [FRnOG] [TECH] choix transitaires

[Vincent Bernat]

 ❦ 11 June 2021 04:06 GMT, Romain BAFFERT:

> cogent par les retours que j’en ai eu + le fait qu’ils n’ont pas tout
> internet ipv6 et que ça sent mauvais de partie avec une rustine…

Cogent est très embêtant pour ça et cela fait des années que cela ne
bouge pas malgré des promesses. En pratique, c'est toutefois assez peu
gênant vu que toutes les apps vont fallback en IPv4 si tu perds ton
second transit. Par contre, si tu as des clients pros derrière, cela
fera sans doute sonner leur monitoring.

Cogent souffre également de mauvaise réputation avec sa politique
commerciale de harceler les gens pour prendre du transit chez eux.

En dehors de ces deux points, Cogent a un excellent rapport
qualité/prix. Étant souvent les moins chers, il y a finalement beaucoup
de monde sur leur réseau. Ils sont aussi disponibles dans beaucoup de
DC, y compris des petits alors que pour d'autres, il faudra
éventuellement aller les chercher en longue distance, voire via une
wave. Pour ma part, ils ont aussi toujours été très flexibles (par
exemple, on nous a monté nx10G sur du CWDM sans soucis pour économiser
le prix des crosscos dans des DC US, on nous offre les ports 1G pour
l'OOB). Et au niveau du support, on a souvent des réponses dans l'heure
et les requêtes type "perte de paquets entre tel hop et tel hop" ou "les
paquets font un détour par ici" sont pris en compte et corrigés en
instant un peu, contrairement à d'autres qui nous disent "Internet,
c'est comme ça".

> D’un point de vue contrat, vu que les prix dégringolent chaque année,
> que négociez vous quand vous entrez chez un fournisseur ? Réévaluation
> des prix sur la durée de l’engagement ? Croissance du débit à prix
> constant etc ? En gros j’ai l’impression que m’engager sur 3 ans sur
> un fournisseur même avec une belle remise sera au final plus douteux
> que de les challenger chaque année :) ça c’était pour la partie
> commerciale.

Si tu dépasses significativement ton commit, tu peux renégocier
régulièrement les prix en disant que pour ce mois-ci, tu passes ton
trafic sur un autre transitaire.

> Et pour finir, je me pose la question de l’opportunité de compléter
> tout de suite / plus tard / pas du tout par une présence avec un IX
> type lyonIX (je suis sur lyon)…

En France, cela fonctionne assez bien pour écouler du trafic. Voici
aussi l'opportunité d'utiliser deux Tiers 2 au lieu de deux Tiers 1.
Cela coûte plus cher, mais cela permet d'éviter à avoir à faire des
peerings ou passer par des IX. De plus en plus proposent également des
prestations anti-DDoS sur demande. Le mélange peut sembler un compromis,
mais cela apporte son lot de problèmes (difficulté à contrôler le trafic
entrant).
-- 
It were not best that we should all think alike; it is difference of opinion
that makes horse-races.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


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

Re: [FRnOG] [TECH] [BGP] Traffic arrivant sur un seul lien au lieu de deux

[Vincent Bernat]

 ❦  9 June 2021 23:15 GMT, Michel Py via frnog:

>> $ show ip bgp 80.77.225.0/24
>> [..]
>>  174 34536
>>Origin IGP, metric 43130, valid, external
>>Community: 174:21101 174:22008
>
> Comment expliquer que dans certains looking-glass (pas tous), on ne voit même 
> pas ce chemin ?
> Est-il possible que certains looking-glass n'afficheraient pas tous
> les chemins ?
>
> Il y a au moins 3 looking-glass qui ne montrent pas le chemin Cogent pour 
> 80.77.225.0/24 :
> https://lookingglass.sunet.se/lg.cgi
> https://lg.he.net/
> https://enterprise.verizon.com/why-verizon/looking-glass/
>
> HE à la limite ça ne serait pas surprenant, on sait qu'entre HE et
> Cogent c'est pas le grand amour, mais Sunet or Verizon ?

Pour chaque préfixe, BGP n'annonce que le meilleur préfixe. Soit le
looking glass n'a accès qu'aux meilleurs préfixes pour chaque routeur,
soit tous les upstreams de chaque routeur ont tous choisi le même
meilleur préfixe et ainsi de suite.
-- 
Zounds!  I was never so bethumped with words
since I first called my brother's father dad.
-- William Shakespeare, "Kind John"


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

Re: [FRnOG] [TECH][BGP] Traffic arrivant sur un seul lien au lieu de deux

[Vincent Bernat]

 ❦  9 June 2021 18:41 +02, David Ponzone:

> Peut-être plus « fiable »  d’annoncer le /23 aux 2, et un /24 à
> chacun, sans prepend.

Tout à fait. Le prepend, surtout avec deux transitaires qui ne sont pas
de même niveau, ne permet pas de contrôler le trafic entrant. Par
exemple, ceux qui peerent avec SFR auront sans doute un local pref plus
élevé qui prendra le pas sur le prepend. À l'inverse, les clients Cogent
non multi-homés n'auront aussi que la route via Cogent. Tu peux tenter
de changer cela avec des communautés (chez Cogent, la route que tu
préfères ne pas avoir via Cogent peut être annoncée avec 174:70). Mais
la solution générique, c'est d'annoncer plus spécifique sur un seul
transitaire et de faire du backup en annonçant moins spécifique aux deux
transitaires. Tant que tu ne te connectes qu'avec des gens qui font de
la DFZ (pas sur un IX), tu es assuré que le trafic entre au bon endroit.
-- 
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)


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

[FRnOG] [TECH] Jerikan : un système de gestion de configuration pour les équipes réseau

[Vincent Bernat]

Hello !

Nous avons publié (nous = l'équipe réseau de Blade/Shadow) notre outil
interne de gestion de configuration orienté réseau. Cela comprend un
soft qui génère des fichiers de configuration à partir d'une source de
vérité et de templates, d'un playbook Ansible mais aussi de la
configuration quasi-complète de nos datacenters de San Francisco et de
Corée du Sud. Cela couvre la partie datacenter mais aussi la partie
edge.

https://vincent.bernat.ch/fr/blog/2021-reseau-jerikan-ansible

Il me semble que c'est assez peu fréquent de trouver ce genre de choses
et cela peut donc intéresser ceux qui se demandent comment configurer un
routeur pour du transit et du peering (Junos ou IOS XR) ou comment faire
le provisioning des switchs en datacenter.

Nous publions ceci "tel quel" car notre société a été rachetée et
l'infrastructure va être migrée chez OVHcloud. Les deux DC en question
sont déjà éteints. Du coup, c'est une bonne occasion de pouvoir publier
des vraies configurations qui ont tourné pour de vrai en production.
-- 
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] Google bloqué depuis accès 4G SFR / Trafic inhabituel provenant de votre réseau ?

[Vincent Bernat]

 ❦ 24 mai 2021 17:00 +02, Stéphane Rivière:

> Pour être précis, la /première fois/ que cette page est appelée par un
> butineur, le serveur s'aperçoit qu'il n'a pas la gouglefonte, il la dl
> chez gougle et l'installe bien au chaud chez lui, puis livre la page au
> butineur, avec les gouglefontes. Gougle voit l'ip du serveur, une fois,
> et c'est tout, et osef le rgpd est content.

OK, je n'avais pas compris comme ça. Cela dit, Google livre un CSS qui
télécharge ensuite la fonte. Si tu ne caches que le CSS, cela ne suffit
donc pas. Sinon, en plus simple :

https://google-webfonts-helper.herokuapp.com/fonts

-- 
Use uniform input formats.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Google bloqué depuis accès 4G SFR / Trafic inhabituel provenant de votre réseau ?

[Vincent Bernat]

 ❦ 24 mai 2021 11:49 +02, Stéphane Rivière:

> C'est comme les google fonts... Sur nos sites, on les cache localement,
> et gougle ne voit rien (i.e. il ne peut pas créer un "réseau de
> relation" entre users, serveurs, ip, etc. vs des "centres d'intérêts").

Ils peuvent maintenant. Les navigateurs cloisonnent les caches par
origine depuis quelques mois.
-- 
A is for Apple.
-- Hester Pryne


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

Re: [FRnOG] [TECH] 2FA, avec ou sans bastion ?

[Vincent Bernat]

 ❦ 13 avril 2021 18:28 +02, Will van Gulik:

> De ce que j'ai lu dans le man et en re-regardant ma conf, j'utilise le
> forwarding-agent dans ma config, et je me connecte à un host (final) via 
> un bastion. Dans ce cas, j'ai une clef pour mon bastion, et des clefs/une 
> clef pour mes
> serveurs derrière, et je ne stocke pas de clef sur le bastion, en toute 
> logique. Dans mon fichier ssh j'utilise les paramèẗres ProxyCommand et
> ForwardAgent .

Pas besoin de ForwardAgent du coup.
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Vincent Bernat]

 ❦  7 avril 2021 08:45 +02, Francois Lesueur:

>> Ce qui est super chiant quand tu développes (car tu bosses généralement avec 
>> de l'auto signé)
>
> Pour les certificats de dév, il y a mkcert
> (https://github.com/FiloSottile/mkcert) qui est super et exprès pour ça
> : création d'une CA locale et installation sur le système/les browsers
> en une ligne, puis création d'un certif signé par cette CA en une autre
> ligne, et zou !

Ce n'est pas forcément la panacée non plus. On se retrouve avec un
certificat racine qui permet d'intercepter tout le trafic HTTPS.
Certains auront vite fait de se partager une CA déjà générée. C'est bien
signalé dans le README, mais il faut sans doute bien faire l'éducation
des users sur le sujet.

Il serait pas mal de limiter la validité de la CA à un domaine
particulier avec l'extension Named Constraints.

> Pour aller un poil plus loin, la suite smallstep est top :
> https://smallstep.com/docs/step-ca/getting-started . Ça permet de
> générer une vraie CA, il y aussi une commande pour l'installer
> proprement sur les browsers locaux, puis les certifs. Ça fait même du
> ACME (protocole de Let's Encrypt) :
> https://smallstep.com/docs/tutorials/acme-challenge

Ça a effectivement l'air très sympathique comme produit ! Merci du lien !
-- 
Make sure every module hides something.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] La "backdoor" de Chrome

[Vincent Bernat]

 ❦  7 avril 2021 08:55 +02, Francois Lesueur:

>> Auto-signé ou pas c'est au moins chiffré, ce qui permet d'éviter
>> l'evedropping passif.
>
> Le but du modèle HTTPS/CA, c'est de chiffrer *avec la bonne personne*.
> L'auto-signé évite certes l'attaque purement passive, mais le but du
> protocole et de son déploiement, c'est de t'assurer que tu échanges bien
> de manière sécurisée avec le bon interlocuteur. Avec l'auto-signé, tu
> chiffres, mais tu n'as aucun moyen de savoir si tu chiffres entre toi et
> l'attaquant (en MitM, qui re-chiffre ensuite pour ta destination mais
> voit le contenu donc) ou entre toi et ta destination (crypto
> bout-en-bout).

L'auto-signé fonctionne désormais en mode "trust on first use", comme
SSH. Cela apporte donc une authentification partielle. Dans Firefox, le
hash du certificat est stocké dans "cert_override.txt" dans le profil de
l'utilisateur.
-- 
A horse!  A horse!  My kingdom for a horse!
-- Wm. Shakespeare, "Richard III"


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

Re: [FRnOG] [TECH] Client IPsec Linux

[Vincent Bernat]

 ❦  1 avril 2021 17:20 +02, Hugo SIMANCAS:

> Avez vous sous la main un client gratuit ou payant pouvant faire de 
> l'IPSec nomade avec Linux (ubuntu?) - équivalent à TheGreenbow Windows

L2TP over IPsec. Côté serveur, libreSwan + xl2tpd. Côté client, c'est
intégré dans tous les OS, y compris Linux avec Network Manager. Pour la
doc, ne pas hésiter à regarder openSwan + xl2tpd, c'est la même chose
(libreSwan est un fork).

Si tu ne maîtrises pas la solution côté serveur, Network Manager sait
aussi faire de l'IPsec classique avec Xauth (ce qui est courant dans le
monde Cisco).
-- 
Program defensively.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] OVH : SBG-2 en feu

[Vincent Bernat]

 ❦ 17 mars 2021 23:04 +01, Barthélémy DELUY:

> Parce que je suis sysadmin, pas expert en datacenter ni en réseau (merci
> les experts de FRnOG de me sortir chaque jour un peu plus de mon
> inculture), donc je me dis bêtement
> "j'ai un serveur à SBG1, un autre à SBG2, et dans toutes les boîtes
> où j'ai fait de la presta les DC sont physiquement éloignés",
> pas
> "en fait SBG1 et SBG2 c'est le même DC il y a juste une cloison
> entre les deux et aucune mesure de protection classique de datacenter, en
> fait dans toutes les autres boîtes on appellerait ça SBG1-1 et SBG1-2 mais
> ça doit pas être assez vendeur".

Pas forcément. Par exemple, Equinix PA2 et PA3 sont accolés.
-- 
I don't know half of you half as well as I should like; and I like less
than half of you half as well as you deserve.
-- J. R. R. Tolkien


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

Re: [FRnOG] [TECH] Question bête Cisco IOS / BGP / Flapping / Dampening

[Vincent Bernat]

 ❦  2 mars 2021 05:50 GMT, Michel Py via frnog:

> Contexte, c'était sur le routeur à la maison, le tout-puissant
> flambant neuf Cisco 2851. Le logiciel du control-plane n'est pas en
> carton (IOS 15.4), par contre processeur qui le fait tourner c'est un
> 486 ou vaguement un Pentium, faut pas demander un miracle.

C'est du RM7065C autour de 500 MHz, donc du MIPS 64 bits, pas grand chose
à voir avec un 486 ou un Pentium.
-- 
Habit is habit, and not to be flung out of the window by any man, but coaxed
down-stairs a step at a time.
-- Mark Twain, "Pudd'nhead Wilson's Calendar


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

Re: [FRnOG] [TECH] BGP internal routes et external routes

[Vincent Bernat]

 ❦ 23 février 2021 21:53 GMT, Michel Py:

>> Cisco ne compare pas les distances administratives entre iBGP et eBGP car ce 
>> critère est inclus dans la
>> sélection du meilleur chemin BGP. La distance ne sert que pour comparer BGP 
>> avec un autre protocole.
>
> C'est tout à fait correct, pourquoi donc est-ce que j'ai cette notion de 
> distance administrative en tête ?
>
> Quelque part la distance administrative iBGP de 200 va faire que les
> routes OSPF vont être préférées, mais c'est irrelevant avec seulement
> BGP.
>
> Pourtant quelque part dans mon subconscient il y a une route interne
> qui vient prendre la priorité sur une route eBGP.
> Ah oui, 3. Prefer the path that was locally originated via a network
> or aggregate BGP subcommand or through redistribution from an IGP.
> https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html

Non plus. C'est le point 7 qui est appliqué (préférer eBGP à iBGP). L'OP
semble indiquer que les deux routes sont apprises de la même façon et
devraient donc avoir la même origine (chez Cisco, IGP quand on utilise
une directive network, incomplete pour les autres type de
redistribution). Ensuite, l'attribut ne doit plus être modifié.
-- 
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] BGP internal routes et external routes

[Vincent Bernat]

 ❦ 23 février 2021 19:51 GMT, Michel Py:

> Sur Cisco, il y a la distance administrative :
> https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/15986-admin-distance.html
> eBGP a une AD de 20, donc prioritaire sur iBGP qui a une AD de 200.

Cisco ne compare pas les distances administratives entre iBGP et eBGP
car ce critère est inclus dans la sélection du meilleur chemin BGP. La
distance ne sert que pour comparer BGP avec un autre protocole.
-- 
"You have been in Afghanistan, I perceive."
-- Sir Arthur Conan Doyle, "A Study in Scarlet"


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

Re: [FRnOG] [TECH] Perte de paquets entre Free et Colt

[Vincent Bernat]

 ❦ 12 février 2021 15:37 +01, Michel GALLE:

> je vous écrits pour me renseigner sur les peering.
>
> Depuis vendredi nous constatons de légères (mais suffisantes) pertes
> de paquets entre des collègues en télétravail à domicile abonnés à
> Free et notre passerelle VPN reliée par COLT, en région Parisienne.
>
> Un traceroute et pings me ramène à AMS IX comme le lieu de la perte de
> paquet.
>
> - https://www.ams-ix.net/ams/connected-networks?search=free
> - https://www.ams-ix.net/ams/connected-networks?search=colt
>
> Cependant, le support COLT m'a déjà répondu n'avoir aucun soucis de
> leur coté ni rien à signaler.

Si vous avez un traceroute dans les deux sens montrant la parte au
niveau de l'AMSIX (perte qui se propage aux hops suivants), Colt ne peut
pas trop dire qu'il n'y a rien à signaler de leur côté. Fournissez les
traceroutes et insistez pour que la correction soit effectuée.
-- 
The ripest fruit falls first.
-- William Shakespeare, "Richard II"


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

Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent

[Vincent Bernat]

 ❦ 29 janvier 2021 07:23 GMT, Michel Py:

> Ca n'a pas marché avec moi. La différence entre jeune et con et vieux
> et con : le vieux et con essaie d'expliquer au jeune et con de ne pas
> faire les mêmes conneries.
[...]

J'ai dépassé la quarantaine il y a un moment. Toujours est-il que je
n'expose pas à longueur de journée ma haine pour 99% de la planète. Tout
le monde ne peut pas être aussi génial que toi mais un peu d'empathie
pour les autres te ferait pas de mal.
-- 
Must I hold a candle to my shames?
-- William Shakespeare, "The Merchant of Venice"


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

Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent

[Vincent Bernat]

 ❦ 28 janvier 2021 21:52 GMT, Michel Py:

>> Tu veux le mouton a 5 pattes, faut sortir les billets.
>
> Normal, ce n'est pas ça dont je me plains. Ce qui me gonfle, c'est
> quand ils ne mettent pas (ou enlèvent) quelque chose banal pour forcer
> à acheter le modèle préconisé par le marketing.
> Exemple : Nexus il n'y a pas VTP (mode transparent seulement). C'est
> même pas dans le chipset, c'est logiciel dans le control-plane.
> Ca me crée du travail en plus de ne pas l'avoir alors que ça existe
> sur tous les Catalyst, et j'en ai plein les bottes que les marketeux
> décident à ma place ce que je peux et ne peux pas faire sur mon
> réseau. Pourquoi je peux pas mettre un Nexus dans mon réseau Catalyst
> avec VTP ? Parce qu'un glandu qui a jamais vu un cable console croit
> qu'il peut faire de l'architecture ou de l'ingénierie de réseau, sur
> mon réseau, unique comme beaucoup, et qui est au-delà de sa
> compréhension. Je demande pas un mouton à 5 pattes, je demande le
> produit que, si c'était un ingénieur qui l'avait conçu, j'aurais même
> pas besoin de demander car ça aurait ce dont j'ai besoin.

Ou alors, c'est une décision due au fait que de nos jours, les clients
de Cisco préfèrent utiliser de l'automatisation et/ou des overlays et
n'ont plus besoin d'un protocole propriétaire de propagation des VLANs.
Du coup, Cisco ne développe pas une fonctionnalité qu'il faudra tester
et supporter pendant des années. On ne peut pas raisonnablement penser
pouvoir acheter d'occasion et peser dans la roadmap du constructeur.

Et ce mépris continuel pour les autres... Le mec du marketing, il a
jamais vu un cable console, mais il sait ce que c'est VTP.
-- 
question = ( to ) ? be : ! be;
-- Wm. Shakespeare


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

Re: [FRnOG] [MISC] Les âneries que les vendeurs nous racontent

[Vincent Bernat]

 ❦ 27 janvier 2021 04:24 GMT, Michel Py:

> Maintenant parlons d'ASIC. Un peu plus tard (on passe directement du
> processeur 8 bits à 32 bits), le 486SX. Le 80486 (le prédécesseur
> direct du Pentium), avait un coprocesseur mathématique intégré. Son
> prédécesseur, le 80386 (même si certaines versions (386DX) avaient
> aussi le coprocesseur intégré) était généralement vendu comme 386SX
> (sans coprocesseur), et les utilisateurs qui voulaient la virgule
> flottante en hard ajoutaient le coprocesseur 80387. Il y avait un
> support sur la carte mère pour ça.

Le 386SX avait un bus de données de 16 bits au lieu de 32 et le 386DX
n'a pas de copro intégré.

Je ne vois pas de quoi il y a à s'indigner de la segmentation
artificielle du marché. Que je sache, ce 486SX, il était vendu moins
cher que le 486DX. Si Intel trouvait plus économique d'avoir un seul CPU
à produire au final, ça les regarde. Cela permet de ne faire payer la
R sur le FPU qu'à ceux qui achètent cette fonctionnalité. Cela permet
aussi de réduire les coûts en vendant les CPU avec un FPU défectueux.

> Le marketing de Junisco qui raconte des conneries, c'était prévisible.
> Toi, c'est surprenant.

Hôpital, charité, ...
-- 
October 12, the Discovery.

It was wonderful to find America, but it would have been more wonderful to miss
it.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


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

Re: [FRnOG] [TECH] Petite question tech concernant l'accès à la TV depuis Free

[Vincent Bernat]

 ❦  7 janvier 2021 14:21 +01, David Ponzone:

> J’essaie de diagnostiquer un souci chez un membre de ma famille abonné Free 
> et je me pose des questions.
> Depuis quelques temps, les chaines de TV (au moins la TNT) sur la
> Freebox (en CPL) freezent et pixelisent à certaines heures (JT 13h, JT
> 20h).

J'ai aussi ça chez mes parents. Ils sont en Freebox v4 avec le boitier
TV derrière le CPL. Pour moi, c'est la Freebox qui ne sait plus gérer
correctement la QoS car ça arrive plutôt quand les petits-enfants sont
dans le coin. Pas tenté le support.
-- 
As to the Adjective: when in doubt, strike it out.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


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

Re: [FRnOG] Re: [TECH] Pourquoi les entreprises désactivent IPv6

[Vincent Bernat]

 ❦  6 janvier 2021 08:46 +01, Stephane Bortzmeyer:

>> En analysant un peu, ce n'est pas un problème nouveau; RFC7610 et
>> DHCPv6-guard, çà n'existe pas pour rien; mais c'est loin d'être
>> parfait.
>
> Quand il va découvrir qu'on peut faire exactement la même attaque en
> IPv4, Toto va angoisser.
>
> https://www.bortzmeyer.org/7610.html

En IPv4, il y a DHCP-guard. En IPv6, c'est rare parce qu'il était
attendu (à ma connaissance) que les OS ne feraient du DHCPv6 que s'ils
recevaient un RA qui disait de faire du DHCP et il y a normalement
RA-guard. Pourquoi Windows fait-il du DHCPv6 sans avoir de RA qui lui
dit d'en faire ?
-- 
Big book, big bore.
-- Callimachus


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

Re: [FRnOG] [TECH] probleme de TTL-security sur une session BGP

[Vincent Bernat]

 ❦ 15 décembre 2020 23:07 GMT, Michel Py:

>>>  Ceci est la partie la plus difficile, AMHA. Il faut que le VLAN en 
>>> question ait une IP publique, et pas une "empruntée" à DoD ou autres, 
>>> soit annoncé vers l'extérieur (il y a plein de VLANs de peering / 
>
>> Radu-Adrian Feurdean a écrit :
>> Dans son cas, c'est plus simple: a l'interieur il y a des eyeballs (dont 
>> probablement
>> Jean-Kevin Michu, le rennome script-kiddie), a l'exterieur l'internet. 
>> L'interieur
>> peut joindre les IP d'interco en question sans autre mecanisme de protection.
>
> Et je suis le seul à penser que le propriétaire de l'interco en
> question il pourrait mettre une protection ant-spoofing sur son VLAN
> d'interco au lieu de se pignoler avec des protections partielles
> basées sur le TTL ? Au lieu de protéger les sessions BGP contre le
> spoofing, on protège le VLAN entier contre le spoofing. C'est quand
> même pas compliqué : sur tous les autres VLANs, mettre une ACL en
> entrée qui dénie le trafic en provenance d'adresses (spoofées) qui
> appartiennent au VLAN de l'interco ? C'est exactement pour ce genre de
> chose que uRPF a été inventé.

La protection via TTL permet de protéger le control plane sans se
soucier des mesures anti-spoofing mises en place par le peer en face.
-- 
The Public is merely a multiplied "me."
-- Mark Twain


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

Re: [FRnOG] [TECH] DF reset

[Vincent Bernat]

 ❦ 14 décembre 2020 17:04 +01, David Ponzone:

> Je viens de m’apercevoir un peu par hasard que pas mal d’IP sur
> Internet, quand on leur envoie un ICMP echo-request avec DF, répondent
> avec un ICMP techo-reply sans DF.

Perso, je vois pas pourquoi le bit DF devrait être copié. En checkant
vite fait dans le code de Linux, je ne vois rien qui copie le flag DF
dans les réponses ICMP.
-- 
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] probleme de TTL-security sur une session BGP

[Vincent Bernat]

 ❦ 13 décembre 2020 19:24 GMT, Michel Py:

> Question bête : est-ce que quelqu'un connait un seul exemple ou
> TTL-security aurait résolu un problème ? Cà ressemble à une solution
> qui cherche un problème.

C'est une méthode pour se protéger d'un DOS sans coopération
particulière du peer en face (notamment, pas besoin qu'il filtre les
paquets spoofés). Sa simplicité permet que le filtrage soit effectué
directement au niveau de la linecard.
-- 
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: [MISC] Re: [FRnOG] annonce letsencrypt

[Vincent Bernat]

 ❦  8 novembre 2020 11:04 +01, Adrien Rivas:

> Cette blague effectivement. Galaxy note 2 : 2 maj, un saut de version
> mineur. Galaxy note 4 : 4 majs en 2 ans. Galaxy tab : 3 upgrades et puis
> s'en va. Oneplus 6 : une maj tous les deux mois, 3 versions majeures
> d'Android reçues.

Faut piocher dans les bons élèves : OnePlus, Nokia, Motorola, Sony, Huawei.
-- 
Consider well the proportions of things.  It is better to be a young June-bug
than an old bird of paradise.
-- Mark Twain, "Pudd'nhead Wilson's Calendar"


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

Re: [FRnOG] [TECH] Hosting et la sécurité sur le LAN

[Vincent Bernat]

 ❦ 30 septembre 2020 11:46 +02, David Ponzone:

> Ok ça revient au même que le modèle avec une VM de routage, sauf que là, 
> c’est l’HV qui route.
> J’avoue que je n’ai jamais considéré ce modèle. Pour moi l’HV est pas
> là pour router.

Jusqu'ici, il bridgeait. Router, c'est finalement pas tellement
différent (enfin, plus pour un Linux que pour un switch hardware, mais
pas sur le principe).
-- 
Grief can take care of itself; but to get the full value of a joy you must
have somebody to divide it with.
-- Mark Twain


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

Re: [FRnOG] [TECH] Hosting et la sécurité sur le LAN

[Vincent Bernat]

 ❦ 30 septembre 2020 10:54 +02, David Ponzone:

>> - désactiver le switching, activer le routing
>> - activer uRPF
>> - activer proxy-ARP
>> - ajouter l'adresse de gateway en /32 pour le client (ou /24 en
>>   n'installant pas la route)
>> - mettre la route en /32 vers le client
>> - activer le relai DHCP
>> 
>> Pas de L2, pas de sécurité L2 à faire. Le client pense être dans un L2
>> classique. La seule difficulté réside dans le DHCP qui doit contenir les
>> infos pour identifier le client (circuit-id souvent est dispo) et doit
>> éventuellement être amadoué pour accepter de fonctionner sur un /32.
>
> Vincent,
>
> Je comprends bien l’idée, et je suis bien d’accord quand on héberge
> des machines physiques, mais comme l’infra réseau devient maintenant
> virtuelle pour l’hébergement de VM (un HV intègre un switch logiciel),
> il faut pouvoir isoler les VM qui sont sur le même LinuxBridge/OVS,

Dans la VM, ne met pas de bridge, même configuration que ci-dessus. La
VM ne peut plus usurper l'identité d'une machine du même réseau.

> Je me demande donc si c’est un risque pris actuellement par un
> hébergeur qui fait de l’industriel, ou s’ils font autrement.

https://vincent.bernat.ch/en/blog/2018-l3-routing-hypervisor

Tu obtiens des choses similaires avec OpenStack + Calico.
-- 
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] Hosting et la sécurité sur le LAN

[Vincent Bernat]

 ❦ 29 septembre 2020 16:36 +02, David Ponzone:

> Après, dans ce qui est accessible avec du matos standard:
> -sur le routeur Edge, assignation d’un /32 sur Eth X, routage du /32 Y
> du client vers l’interface Eth, et configuration en dur de l’adresse
> MAC de Y
> -sur la VM (Linux), assignation de Y sur eth0 et route par défaut avec
> un nexthop via X dev eth0 onlink

Sur le switch, sur chaque interface :
 - désactiver le switching, activer le routing
 - activer uRPF
 - activer proxy-ARP
 - ajouter l'adresse de gateway en /32 pour le client (ou /24 en
   n'installant pas la route)
 - mettre la route en /32 vers le client
 - activer le relai DHCP

Pas de L2, pas de sécurité L2 à faire. Le client pense être dans un L2
classique. La seule difficulté réside dans le DHCP qui doit contenir les
infos pour identifier le client (circuit-id souvent est dispo) et doit
éventuellement être amadoué pour accepter de fonctionner sur un /32.
-- 
Avoid temporary variables.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Hosting et la sécurité sur le LAN

[Vincent Bernat]

 ❦ 26 septembre 2020 16:27 +02, David Ponzone:

> Comme l’hébergement sérieux version 2020 m’est inconnu, je me
> demandais comment l'hébergeur gère la sécurité sur un LAN quand les
> machines qui y sont hébergées sont gérés par un tiers (risque d'IP
> foireuse, netmask foireux, proxy-arp, etc….).
> ARP en dur au niveau de l’équipement Edge, et désactivation/filrage
> des ARP Request vers le LAN et des gratuitous ARP venant du LAN ?
> Des trucs plus complexes ?

Une archi en L3-only avec reverse path filtering élimine tous les
problèmes L2 que tu cites.
-- 
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] - Remote console avec admin centralisée

[Vincent Bernat]

 ❦ 18 septembre 2020 11:11 +02, Cédric Houzé:

> Je cherche à faire évoluer mon parc d'une centaine de boîtiers OoB console
> pour y ajouter de nouvelles fonctionnalités.
> Entre autres, j'aimerais :
> - que l'administration soit centralisée
> - pouvoir récupérer automatiquement des informations sur les équipements
> qui y sont connectés (au moins le hostname)
>
> Connaissez-vous des solutions intégrant ces fonctions ?
> Avez-vous des retours d'expérience sur celles-ci ?

Hello,

Jette un œil sur conserver: https://www.conserver.com/. L'idée est de
laisser tous tes boîtiers en configuration "par défaut" (ne pas nommer
les ports) et de déporter la configuration sur conserver. Cela te rend
indépendant des différents boîtiers et tu as juste à faire "console
machinchose" sur l'hôte faisant tourner conserver. C'est assez flexible
pour te permettre d'exécuter des commandes sur-mesure pour se connecter
sur les équipements directement et d'en profiter pour setter la vitesse
nécessaire avant la connexion.

Cela ne répond pas au second point cependant.
-- 
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/

[FRnOG] [MISC] Re: Appliwave recrute un Ingénieur VOIX SIP

[Vincent Bernat]

 ❦  5 septembre 2020 23:31 +02, Jean Théry:

> ça permet surtout de jeter l'offre direct a la poubelle comme le font
> les recruteurs indélicat voulant le mouton a 5 pattes et qui en plus
> donne de l'argent pour bosser.

Pour rappel, Philippe a déjà demandé de ne pas débattre autour d'une
annonce pour ne pas dégoûter les gens d'en poster :

https://www.mail-archive.com/frnog@frnog.org/msg48869.html

Il a également demandé de ne pas faire un débat autour du fait qu'il n'y
a pas de salaire indiqué :

https://www.mail-archive.com/frnog@frnog.org/msg40847.html
-- 
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] Q-in-Q Cisco sur CELAN

[Vincent Bernat]

 ❦ 15 août 2020 07:13 +00, Michel Py:

>> Je pointais juste le fait que l'explication de comment la CAM fonctionne 
>> n'est pas bonne depuis 20 ans.
>
> Excellente remarque, j'avais en effet pris quelques raccourcis dans 
> l'histoire.
>
>> Perso, jamais fait de Q-in-Q
>
> As-tu déjà mis un câble en boucle entre 2 ports sur le même switch?

Oui (entre deux VRF dans mon cas). Je ne vois pas le rapport avec les
carottes. Je réitère donc : je souligne juste que ton explication était
fausse (depuis 20 ans). Comme c'était a priori la seule base
scientifique pour expliquer pourquoi c'est une mauvaise idée, j'ai fait
la remarque. Je n'y connais rien en Q-in-Q et donc je n'ai pas d'avis
sur le fait que ce soit ou non une bonne idée dans le cas présenté.
-- 
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] Q-in-Q Cisco sur CELAN

[Vincent Bernat]

 ❦ 14 août 2020 15:35 +00, Michel Py:

>>> Rappel de base : la CAM est construite en écoutant l'adresse MAC
>>> source et en l'associant au port sur lequel le trafic est arrivé. Il
>>> peut y avoir plusieurs MAC par port, mais pas plusieurs ports par MAC.
>
>> L'association MAC/port se fait par VLAN.
>> sh mac address-table
>> sh platform mac-address-table mac-address X vlan Y
>
> Et ce que Sébastien veut faire c'est d'injecter un VLAN dans un autre
> tout en encapsulant un VLAN dans un autre en même temps.
[...]

Je pointais juste le fait que l'explication de comment la CAM fonctionne
n'est pas bonne depuis 20 ans. Perso, jamais fait de Q-in-Q.
-- 
Don't over-comment.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Q-in-Q Cisco sur CELAN

[Vincent Bernat]

 ❦ 12 août 2020 17:10 +00, Michel Py:

> Ce n'est pas tellement STP ou 802.1q qui me chagrine dans cette
> combine, c'est la gestion de la table CAM dans le switch.
> Rappel de base : la CAM est construite en écoutant l'adresse MAC
> source et en l'associant au port sur lequel le trafic est arrivé. Il
> peut y avoir plusieurs MAC par port, mais pas plusieurs ports par MAC.

L'association MAC/port se fait par VLAN.

sh mac address-table
sh platform mac-address-table mac-address X vlan Y
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)


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

[FRnOG] [BIZ] Contact FranceTV et Canal+

[Vincent Bernat]

Hello,

Nous (Blade/Shadow) avons des soucis de géolocalisation sur un de nos
subnets (utilisateurs français, mais subnet localisé aux US). Je
recherche un contact chez FranceTV et chez Canal+ pour m'aider à régler
cela. Quelqu'un pourrait-il m'aguiller ?

Merci.

-- 
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain


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

Re: [FRnOG] [MISC] Scan RDP venant de 94.177.238.132

[Vincent Bernat]

 ❦ 23 mai 2020 22:49 +02, David Ponzone:

>> Nous avons des utilisateurs de Microsoft qui utilisent le RDP en écoute
>> sur le port standard et sur l'Internet sans filtrage, pas de problèmes.
>
> Tu dis donc le contraire de tout le monde ici qui confirme que laisser
> un port RDP ouvert, c’est pas une super idée. Dois-je croire ton
> expertise ou la leur ?

Amazon, Microsoft, Google et Tencent (sans compter tous les petits
clouds providers) n'ont pas eu le mémo. Ils proposent des VM Windows
avec RDP activé par défaut. Quelqu'un devrait leur dire de venir se
renseigner ici avant de faire des choses pareilles.
-- 
Many pages make a thick book, except for pocket Bibles which are on very
very thin paper.


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

Re: [FRnOG] [ALERT] Scan RDP venant de 94.177.238.132

[Vincent Bernat]

 ❦ 23 mai 2020 09:54 +00, Duchet Rémy:

> J'ai quand même l'impression que ce fil est en train de disserter sur
> la longueur de la jupe de la dame, en oubliant qu'il y a une (ou des)
> victimes.

IMO, les analogies avec la vie réelle sont rarement pertinentes : je
peux en trouver une qui dit exactement l'inverse. Si je décide de ne pas
mettre de porte à ma maison car je trouve ça laid, est-ce que la police
va se déplacer pour chaque personne qui vient visiter pendant mon
absence ?

> Aujourd'hui on parle de scan RDP, mais c'est la même chose pour
> n'importe quel service. Croire que le service XX sera épargné parce
> qu'il est protégé par la solution YY, et que du coup, on s'en tape du
> scan, c'est se mettre des œillères.

Shodan répertorie l'intégralité des ports ouverts sur IPv4. Il recense
4,5 millions de ports RDP ouverts, notamment via les clouds providers
fournissant des Windows. Si j'y entre mon IP (dynamique Orange), il y
découvre mon serveur web ainsi que mon SSH sur un port non standard. Il
a scanné ma machine hier.

Aucune mesure de sécurité ne peut reposer sur le fait qu'un port ouvert
n'est pas une donnée publique. À partir de là, rapporter le moindre scan
de port ne conduit qu'à rendre insensible les services d'abuse et à
passer à côté des problèmes plus sérieux.
-- 
Use uniform input formats.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Retro-ingénierie de la FSbox ?

[Vincent Bernat]

 ❦ 17 mai 2020 10:47 +02, Denis Fondras:

>> Elle marche pas sous Linux avec Chrome ?
>
> Non, "No FS_Service driver installed".
> Sous Linux, il semble que la solution soit d'avoir une VM Windows et 
> d'attacher
> le périphérique USB à la VM.

Je pensais que ça allait marcher comme une Flexbox et simplement
utiliser le support USB HID de Chrome.
-- 
The smallest worm will turn being trodden on.
-- William Shakespeare, "Henry VI"


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

Re: [FRnOG] [TECH] Retro-ingénierie de la FSbox ?

[Vincent Bernat]

Elle marche pas sous Linux avec Chrome ?
-- 
In the first place, God made idiots; this was for practice; then he made
school boards.
-- Mark Twain

 ――― Original Message ―――
 From: Denis Fondras 
 Sent: 16 mai 2020 19:43 +02
 Subject: [FRnOG] [TECH] Retro-ingénierie de la FSbox ?
 To: frnog-t...@frnog.org

> Est-ce que quelqu'un a déjà tenté la rétro-ingénierie de la FSbox pour la 
> faire
> fonctionner avec autre chose que MS ou la Pomme ?
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] Re: [MISC] Prochaine assemblée générale du RIPE - Vote pour le renouvellement de trois siège au board

[Vincent Bernat]

 ❦ 15 mai 2020 13:27 +02, Stephane Bortzmeyer:

>> Tentatives de putsch de Cohen et des iraniens mises en échec!
>
> Le terme est franchement exagéré, aussi bien pour Cohen que pour les
> iraniens (qui ont, je le rappelle, autant de droits que les autres de
> se présenter, le RIPE est à eux, aussi).
>
> Ce qui m'inquiète est que Cohen soit « quatrième » (il a eu à chaque
> fois davantage de voix que les iraniens, ou que Jordi Palet Martinez).

Il faudrait faire tourner l'algo jusqu'au bout. En lisant le décompte en
diagonale, il était soit placé premier (parfois seul, parfois non), soit
placé dernier. On ne peut pas regarder les premiers tours pour déduire
sa place finale. Regarde Raymond Jetten qui a fait un très mauvais score
pour le première siège.

Sans compter qu'il a spammé tout le monde en prétendant offrir un /21
IPv4 (pas IPv4+) s'il est élu. J'espère qu'il y aura des conséquences,
mais j'en doute.
-- 
Use self-identifying input.  Allow defaults.  Echo both on output.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [MISC] RE: [FRnOG] [TECH] FRNOG [TECH] Fwd: Message important concernant les élections du RIPE

[Vincent Bernat]

 ❦ 11 mai 2020 01:53 +00, Michel Py:

> Cà fait longtemps qu'on a perdu l'adressage de bout-en-bout, de toute
> façon. Il y a 20 ans, quand je croyais encore à IPv6, il y avait un
> vague consensus que faire IPv6 avec NAT çà ne marcherait jamais.
> Regardons ou nous en sommes aujourd'hui, écrit par Monsieur IPv6
> lui-même :
> https://www.slideshare.net/RNIDS/ipv6-transition-and-coexistance-jordi-palet
> Allez à la page 57. J'ai loupé quelque chose, ou IPv6 n'a que 9 types
> de NAT différents, dont aucun ne marche ?

T'as loupé quelque chose. Il décrit des mécanismes qui ont chacun leur
avantage et inconvénient. Cela n'a aucun impact sur le trafic pur IPv6
qui est n'est concerné par aucun de ces mécanismes. Ces mécanismes sont
une réalité pour de nombreux ISP qui n'ont pas l'air eu d'avoir ton mémo
sur le fait qu'IPv6 ne marchera jamais. Et ils sont la principale
motivation pour inciter les content providers à passer à IPv6, vu qu'ils
ont tous un impact sur la qualité.

>> - Mais nous n'avons surtout pas besoin d'une bidouille comme cet IPv4+, qui
>> n'est pas compatible de grand chose, et génèrera des tonnes d’embêtement.
>
> Attention de ne pas généraliser la merde à 32bits-et-demi de Elad
> Chohen et le reste. Même si la probabilité d'une évolution d'IPv4 avec
> "juste" plus de bits est improbable, çà reste une possibilité.

Non. Comme indiqué par Kavé, cela nécessite d'introduire une nouvelle
famille et cela impacte absolument toutes les couches, des applications
aux ASIC. Personne n'a envie de faire ça pour quelques bits
supplémentaires alors que le travail est fait pour IPv6. D'ailleurs, il
n'y a que des propositions farfelues sur le sujet.
-- 
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] Re: [MISC] L’Internet pendant le confinement

[Vincent Bernat]

 ❦ 26 mars 2020 03:15 +00, Michel Py:

>> +75% de trafic supplémentaire pour Netflix pendant le pic samedi 14 vers 23h.
>
> Vachement relevant. Le trafic a 23h. Un samedi. Vachement relevant
> pour l'impact du confinement sur le télétravail. Aucun graphe
> détaillé.

Le sujet c'est l'impact du confinement sur Internet ("L’Internet pendant
le confinement"). Le débat était autour du fait si le volume durant le
peak time avait changé. Nokia n'a sans doute pas le droit de publier de
données brutes ou aggrégées et se contente donc de faire des analyses
globales. Je suis désolé que ces données ne sont pas du niveau attendu
de notre spécialiste local ès comptoir de bistrot qui a toujours pour
habitude de débattre sur des données sourcées et chiffrées et non sur
des anecdotes "moi, je".
-- 
Lord, what fools these mortals be!
-- William Shakespeare, "A Midsummer-Night's Dream"


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

Re: [FRnOG] Re: [MISC] L’Internet pendant le confinement

[Vincent Bernat]

 ❦ 22 mars 2020 11:14 +01, Stephane Bortzmeyer:

>> Le trafic des plus gros ISP français n'est pas sur les IX. Il n'y a
>> aucune chance qu'un IX soit représentatif du trafic internet. Le
>> trafic de Michel Py n'est pas représentatif non plus du trafic
>> internet en France.
>
> C'était un des points essentiels de mon article : personne n'est
> représentatif. L'Internet étant comme il est, chaque lien, chaque
> réseau, est différent, et ne va pas voir la même chose. Des questions
> comme « quelel est l'augmentaton du trafic Internet depuis le
> confinement ? » n'ont pas de sens.
>
> J'ai utilisé des statistiques publiques. Mais j'aimerais bien que les
> BOFS publient des statistiques temps-réel du débit sur leur PNI avec
> Netflix :-)

https://www.nokia.com/blog/early-effects-covid-19-lockdowns-service-provider-networks-networks-soldier/

+75% de trafic supplémentaire pour Netflix pendant le pic samedi 14 vers
23h. Ils ne disent pas exactement quels pays sont concernés ni quels
ISP, mais Europe de l'Ouest, donc sans doute l'Italie.
-- 
Let him choose out of my files, his projects to accomplish.
-- Shakespeare, "Coriolanus"


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

Re: [FRnOG] [MISC] L’Internet pendant le confinement

[Vincent Bernat]

 ❦ 22 mars 2020 01:33 +00, Michel Py:

> C'est tout a fait exact, quand je remplis ma fiche de temps en ligne,
> que je le fasse de la maison ou du bureau çà ne change pas grand-chose
> : le service en question était déjà habitué à la charge. Quand
> j'achète quelque chose sur eBay, Amazon, fs.com, pareil.
> Une grosse partie de ce trafic va traverser un IX, ce qui valide les
> liens que tu as postés à propos de France-IX et autres. C'est le
> trafic interactif (a l'opposé du trafic broadcast glorifié, qui
> consiste à pousser un flux vidéo d'un cache le plus proche possible de
> l'utilisateur). Même si les totaux du trafic dans un IX ne sont qu'une
> partie du trafic global, les tendances y sont respectées.

C'est un extraordinaire déni. Le trafic de Google/Netflix/Facebook ne
passe pas par les IX. Le trafic des plus gros ISP français n'est pas
sur les IX. Il n'y a aucune chance qu'un IX soit représentatif du trafic
internet. Le trafic de Michel Py n'est pas représentatif non plus du
trafic internet en France.
-- 
Say what you mean, simply and directly.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] L’Internet pendant le confinement

[Vincent Bernat]

 ❦ 22 mars 2020 00:11 +01, Radu-Adrian Feurdean:

>  - OK, O/F/S/B couvrent une grande partie de la population d'eyeballs,
> mais ils ne sont pas les seuls (et en consequence ils ne couvrent pas
> la totalite). Il y en a des plus petits qui font tres bien le boulot
> eux aussi (voir meme parfois mieux que certains des 4). Et ces
> "autres" peuvent bien utiliser les IX pour echanger du traffic aces
> Google et Netflix.

S'ils représentent 1% des abonnés, cela ne change pas le fait que le
trafic Google/Netflix est quasi invisible sur les IX. Google n'a que
2x20G sur FranceIX et Netflix n'a que 40G. Cela montre bien que les IX
ne sont que peu utilisés pour cet usage.
-- 
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] [MISC] L’Internet pendant le confinement

[Vincent Bernat]

 ❦ 21 mars 2020 23:01 +01, Alarig Le Lay:

>> Pourtant, aucune difficulté. Du moment que tu paies le crossco, ils te
>> montent sans problème un tel PNI. C'est ce qu'ils indiquent aussi ici :
>>  
>
> Vu la qualité plus que médiocre de leur NOC, je me permets de douter.

Je l'ai fait en juillet dernier environ 1.5G en 95th. PNI monté en 15
jours. Cela permet aussi d'accéder au portail ISP de Google, très
pratique pour faire géolocaliser correctement ses IP.
-- 
Make sure your code "does nothing" gracefully.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] L’Internet pendant le confinement

[Vincent Bernat]

 ❦ 21 mars 2020 22:44 +01, Hugues Voiturier:

>> tu as tout intérêt à prendre un PNI pour le prix d'un crossco (100
>> balles) alors que le port France-IX coûte mini 300 balles par mois.

> Ben, avec ce raisonnement là, autant prendre du transit et ne pas peer
> ? :)

Pas compris.

> Au dela de ça, avec 1G au 95th, peu de chances que Google te monte un
> PNI…

Pourtant, aucune difficulté. Du moment que tu paies le crossco, ils te
montent sans problème un tel PNI. C'est ce qu'ils indiquent aussi ici :
 

>> Et de toute façon Google n'a quasiment aucune capacité au France-IX
>> (50Gd'après PeeringDB),
>
> 2x100G quand même, ça commence à faire, si mes calculs sont bons, 20%
> d’1Tbps !

Sur PeeringDB, ils disent 2x20G. Sans doute sur des ports 100G,
n'empêche qu'ils doivent sans doute respecter leur limitation. Donc
invisible.

> Maintenant oui, la majorité du trafic de FranceIX, c’est du B2B, mais
> l’énorme avantage pour un Google ou un Netflix, c’est de pouvoir
> joindre des centaines de “petits” avec 2 ports 100G, au lieu de tirer
> 1 Xco par AS ou de tout passer en transit.

Je prétends pas que les IX ne servent à rien. Je dis juste qu'ils sont
un mauvais témoin du trafic qui circule sur Internet.
-- 
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] [MISC] L’Internet pendant le confinement

[Vincent Bernat]

 ❦ 21 mars 2020 21:26 +01, Radu-Adrian Feurdean:

>> Le trafic des IX n'est pas forcément très représentatif de
>> l'augmentation de trafic. Les gros consommateurs tels que
>> Youtube/Netflix ne passent pas par le FranceIX (Google refuse de peerer
>> via un IX au-delà d'1 Gbps). Seuls les intéressés peuvent donc avoir les
>> données.
>
> Meme si c'est loin de leurs capacites reels, ils poussent quand-meme
> des quantites non-negligeables de traffic sur France-IX. Effectivement
> Google utilise les PNI pour les reseaux qui poussent plusieurs Gbps,
> cependant la "long tail" c'est sur les IXP qu'ils l'evacuent. Pour
> Netflix, le seuil semble etre un peu plus haut. Et dans les deux cas,
> les IX sont utilises comme debordement.

Je ne comprends pas trop ce que tu veux dire. La très grande majorité
des eyeballs en France, c'est Orange/Free/SFR/Bouygues, non ? Surtout en
ce moment. Aucun de ceux là n'utilise un IX pour échanger avec Google.
Pour les autres, dès que tu échanges plus de 1 Gbps, tu as tout intérêt
à prendre un PNI pour le prix d'un crossco (100 balles) alors que le
port France-IX coûte mini 300 balles par mois.

Et de toute façon Google n'a quasiment aucune capacité au France-IX (50G
d'après PeeringDB), donc normal que ce soit invisible sur les 1T de
trafic en pointe du France-IX.
-- 
Tempt not a desperate man.
-- William Shakespeare, "Romeo and Juliet"


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

Re: [FRnOG] [MISC] L’Internet pendant le confinement

[Vincent Bernat]

 ❦ 21 mars 2020 17:01 +01, Samuel Thibault:

> - "Il y a les enfants qui consomment de la capacité réseau à la
> maison dans la journée". L'argument que je donne dans mon entourage,
> c'est que les réseaux ont déjà l'habitude d'encaisser le rush de 19h où
> tous les gosses se précipitent pour regarder des vidéos. S'ils en
> regardent pendant toute la journée, c'est juste le même rush. Et c'est
> même possible qu'en fait ça fasse moins de monde à 19h, et donc au final
> même moins difficile à encaisser pour le réseau :)

Je pense que c'est plutôt faux. Hors confinement, les enfants ont des
activités le soir (dance, tennis, équitation, foot, soirée chez des
amis), ce qui tiens une partie d'entre eux éloignés des écrans. La
charge est donc répartie sur plusieurs jours selon les emplois du temps.
Là, ils sont tous chez eux et vont potentiellement regarder des vidéos
potentiellement en même temps avant le repas. Je ne pense pas que le
lissage sur la journée change quelque chose.
-- 
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] [MISC] L’Internet pendant le confinement

[Vincent Bernat]

 ❦ 21 mars 2020 16:43 +01, Stephane Bortzmeyer:

> Ça pourrait vous intéresser (en attendant, merci à ceux qui font
> fonctionner l'Internet, et me permettent donc d'écrire des
> articles). Commentaires positifs et négatifs bienvenus :
>
> https://framablog.org/2020/03/21/linternet-pendant-le-confinement/

Le trafic des IX n'est pas forcément très représentatif de
l'augmentation de trafic. Les gros consommateurs tels que
Youtube/Netflix ne passent pas par le FranceIX (Google refuse de peerer
via un IX au-delà d'1 Gbps). Seuls les intéressés peuvent donc avoir les
données.

Cela dit, je ne pense pas que ça invalide la conclusion.
-- 
Make input easy to proofread.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] OSPF Bird et configure

[Vincent Bernat]

 ❦ 15 janvier 2020 18:59 +01, "On behalf of Elise Vennegues " 
:

> Sinon tu peux aussi considérer l’ajout d’une table supplémentaire
> connectée par un pipe à la table master et ensuite tu y appliques sur
> le pipe un “export” spécifique et tu peer en out vers tes routeurs
> depuis cette table (j’avoue c’est un peu tordu mais tu reload que le
> pipe et non toutes tes sessions).

Je pense que c'est la bonne solution. Et pas besoin de reconfigurer quoi
que ce soit quand on ajoute une route. Perso, je déclare aussi les
routes RTBH de cette façon.
-- 
"... all the modern inconveniences ..."
-- Mark Twain


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

Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur CISCO depuis une VM Linux

[Vincent Bernat]

Je pense que c'est plutôt le contraire. Par exemple les IX n'annoncent
pas leurs subnets pour éviter les attaques (exemple, France-IX, AMS-IX).
Et ils demandent de ne pas les réannoncer non plus.
-- 
Don't stop at one bug.
- The Elements of Programming Style (Kernighan & Plauger)

 ――― Original Message ―――
 From: David Ponzone 
 Sent: 20 décembre 2019 10:37 +01
 Subject: Re: [FRnOG] [TECH] RTBH : Propager une route BGP Null0 sur un routeur 
CISCO depuis une VM Linux
 To: Alarig Le Lay
 Cc: frnog@frnog.org

> A la base c’est pas considéré comme « bad practice » d’avoir des
> équipements qui renvoient des ICMP depuis des IP non annoncées ?
>
>> Le 20 déc. 2019 à 10:35, Alarig Le Lay  a écrit :
>> 
>> Pour les traceroutes/mtr et le PMTUd.
>> 
>> On 20/12/2019 10:34, David Ponzone wrote:
>>> OK ça se défend.
>>> Ca te gêne pour les traceroute ou pour autre chose ?
>>> 
 Le 20 déc. 2019 à 10:29, Alarig Le Lay  a écrit :
 
 Je n’ai jamais eu de soucis de spoof d’IP pas annoncées. Par contre, ne
 plus recevoir les ICMP des backbones pas annoncés, j’ai déjà eu. Donc
 l’intérêt est négatif pour moi.
 
 On 20/12/2019 10:27, David Ponzone wrote:
> Ben si t’as pas de route pour l’IP source du paquet, tu le drop au plus 
> tôt non ?
> 
> 
>> Le 20 déc. 2019 à 10:23, Alarig Le Lay  a écrit :
>> 
>> Je ne vois pas l’utilité de l’uRPF si c’est pas en mode strict perso :p
>> 
>> On 20/12/2019 10:22, David Ponzone wrote:
>>> Pas en mode strict en tout cas.
>>> 
 Le 20 déc. 2019 à 10:16, Alarig Le Lay  a écrit :
 
 uRPF faut le faire sur ton réseau à toi, pas sur les intercos vers
 l’extérieur, sinon effectivement ça casse tout.
 
 On 20/12/2019 09:57, Fabien H wrote:
> Bonjour Michel (quand il fera jour outre-atlantique :-) )
> 
> J'ai regardé un peu uRPF, effectivement, c'est très intéressant
> effectivement !
> 
> Par contre juste une question qui me chagrine, en environnement 
> multi-homé,
> multi-transitaire avec ton préfixe /22 annoncé sur tous les 
> transitaires,
> sans local pref sur le sortant vers tel ou tel transitaire, il n'y a 
> pas un
> risque que le paquet arrive "de bonne foi" par le mauvais transitaire 
> ?
> 
> 
> 
> 
> 
> 
> Le jeu. 19 déc. 2019 à 21:27, Michel Py 
> 
> a écrit :
> 
>>> Fabien H a écrit :
>>> announce route A.B.C.D/32 next-hop 10.10.2.41 community 65532:666
>> 
>> Change 65532 pour quelque chose d'autre. Réservé pour Michel/CBBC :P
>> A éviter aussi : 65332 (team Cymru)
>> 
>> Ne pas oublier :
>> 
>> interface null 0
>> no ip unreachables
>> 
>>> Pas de problème de peformance si le routeur envoie d'abord vers 
>>> 192.0.2.1
>>> puis cherche la route 192.0.2.1 vers Null 0 ?
>> 
>> Non, c'est la bonne manière.
>> 
>> Tu as quoi pour sh ip route 0.0.0.0 ? tu utilises la route par 
>> défaut ?
>> 
>> Prochaine étape : uRPF sur l'interface externe.
>> 
>> Michel.
>> 
>> 
>> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 
 
 
 ---
 Liste de diffusion du FRnOG
 http://www.frnog.org/
>>> 
>> 
> 
 
>>> 
>> 
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

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

[Vincent Bernat]

 ❦ 21 novembre 2019 11:14 +01, Vincent Bernat :

>> net.ipv6.route.max_size=8388608
>
> Utile (c'est à mon sens un défaut de la part de Linux d'avoir une valeur
> basse par défaut).

Un récent thread sur la ML de BIRD m'a rappelé qu'en fait, depuis Linux
4.2, il vaut mieux laisser la valeur par défaut. Il s'agit de la taille
maximale du cache et depuis Linux 4.2, seulement les routes pour
lesquelles un MTU plus faible a été détecté sont ajoutées à ce cache.
-- 
Use the "telephone test" for readability.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] Re: [TECH] Attaque basée sur QUIC ?

[Vincent Bernat]

 ❦ 30 novembre 2019 17:51 +01, David Ponzone :

> Paquet venant du serveur Cloudflare vers utilisateur, identifié comme QUIC 
> par Wireshark:
>
> QUIC (Quick UDP Internet Connections)
> Public Flags: 0x4d
>  ...1 = Version: Yes
>  ..0. = Reset: No
>  11.. = CID Length: 8 Bytes (0x03)
> ..00  = Sequence Length: 1 Byte (0x00)
> 01..  = Reserved: 0x01
> CID: 2326183228098302765
> Version: * HT
> Sequence: 84
> Payload: 502f312e310d0a486f73743a3233392e3235352e3235352e…
>
> Le plus étrange c’est que si on change l’IP publique de l’utilisateur, plus 
> de flux.
> Dès qu’on lui remet l’ancienne, le flux reprend, mais ça commence par
> un paquet UDP venant du serveur (port 443) vers l’IP de l’utilisateur
> (port 1900).

Ça ressemble plus à de la réflexion SSDP.
-- 
Don't sacrifice clarity for small gains in "efficiency".
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] IPv4 pool @RIPE NCC: Game over !

[Vincent Bernat]

 ❦ 26 novembre 2019 09:08 +01, David Ponzone :

> Si on part du postulat qu’accéder au GAFAM en IPv6 est 1000 fois plus
> important que tout le reste, effectivement, on est plus à 35/40%:
>
> https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption
> 
>
> Mais si au contraire on part du postulat que le volume importe peu
> parce que pouvoir accéder au site des Impôts en IPv6-only est aussi
> important qu’accéder à Google, voir plus, le chiffre est pas le même.
>
> Je pense que les années 2020-2030 vont être les années
> CGNAT-pour-tout-le-monde.

Le CGNAT va rester longtemps, mais du point de vue des ISP, cela a un
coût. Puisque la majorité des content providers sont accessibles en v6,
l'ISP peut se permettre de sous-dimensionner son CGNAT. En tant que
content provider, on s'expose donc à une expérience dégradée pour les
utilisateurs (notamment mobiles) derrière du CGNAT. Ce n'est pas par pur
défi technique que les fournisseurs de contenu pour qui la performance
est importante sont tous disponibles en IPv6.
-- 
Take care to branch the right way on equality.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] IPv4 pool @RIPE NCC: Game over !

[Vincent Bernat]

 ❦ 25 novembre 2019 23:01 +00, Michel Py :

> Cà fait quand même 20 ans que çà dure, cette plaisanterie. Il y a 20
> ans, j'étais sur le 6bone et j'avais IPv6 sur un Cisco 2500.

Genre le vieil oncle qui dit qu'il a voté à gauche dans sa jeunesse et
qui vote FN maintenant parce qu'il "sait".

> https://stats.ams-ix.net/sflow/ether_type.html
> Croissance = 0
> Part d'IPv6 : même pas 3%.

Comme je l'ai dit la dernière fois que tu as cité cette stat, elle ne
vaut rien. Le gros du trafic Internet ne passe pas par les switchs des
IX. Par exemple, si tu dépasses 1G de trafic, Google demande un PNI.
-- 
Use recursive procedures for recursively-defined data structures.
- The Elements of Programming Style (Kernighan & Plauger)


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

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

[Vincent Bernat]

 ❦ 21 novembre 2019 09:57 +00, Sébastien 65 :

> net.ipv4.conf.default.rp_filter=0
> net.ipv4.conf.all.rp_filter=0
> net.ipv4.conf.lo.rp_filter=0

C'est la config par défaut.

> net.ipv4.route.max_size=8388608

Ce n'est pas utilisé en IPv4 depuis le 3.6.

> net.ipv4.conf.all.forwarding = 1
> net.ipv4.conf.default.forwarding = 1
> net.ipv4.ip_forward=1

Beaucoup de redondance. Changer all change également default. Changer
ip_forward change all qui change default.

> net.ipv6.conf.all.forwarding=1
> net.ipv6.conf.default.autoconf=0
> net.ipv6.conf.default.accept_ra=0
> net.ipv6.conf.all.autoconf=0
> net.ipv6.conf.all.accept_ra=0

Même remarque all/default. De plus, forwarding activé fait que accept_ra
dans sa valeur par défaut (1) n'accepte pas les RA. Idem pour autoconf.

> net.ipv6.route.max_size=8388608

Utile (c'est à mon sens un défaut de la part de Linux d'avoir une valeur
basse par défaut).

> http://docs.frrouting.org/projects/dev-guide/en/latest/building-frr-for-debian9.html
> la configuration du sysctl est ultra light (uniquement forwarding) !

Ils ont raison. Linux a des défauts plutôt smart, on trouve plein de
docs qui changent les valeurs un peu aléatoirement comme une recette
magique. Il ne faut pas les suivre quand les changements ne sont pas
motivés.
-- 
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] Supprimer IPV4 RFC1918 dans un LAN ?

[Vincent Bernat]

 ❦ 26 octobre 2019 15:32 +02, Pierre Colombier :

> Suite à la mise en place de IPv6 dans un LAN, je n'ai plus besoin
> d'IPv4 dans ce réseau.
>
> De ce fait, il m'est pénible de maintenir la dual-stack avec des IPv4
> RFC1918 qui ne servent qu'a accéder à l'internet v4 via un NAT en
> bordure.
>
>
> La question est sans doute ancienne mais je voudrais savoir si il
> existe un moyen de supprimer la stack IPv4 dans le lan tout en gardant
> un NAT 6 vers 4 pour accéder au "vieux" net v4.
>
> Le truc qui semble le plus intuitif est le NAT-PT où on mappe les 32
> bits IPv4 dans un prévixe IPv6 mais le problème plus difficile est
> alors de maper aussi les enregistrements DNS A dans des 
> correspondants.

C'est le rôle de DNS64. Google en fournit un gratuitement avec le
préfixe par défaut. unbound sait faire ça out of the box aussi :

server:
  module-config: "dns64 iterator"
  dns64-prefix: 64:ff9b::/96

Pour le NAT, Tayga est un bricolage, il faut partir sur Jool (dont la
doc explique aussi les possibilités).

> Avec tous les efforts de sécurisation de DNS en ce moment, ce genre de
> manipe risque de poser plein d'autres problèmes.
>
> Aparemment le NAT-PT est déconseillé par l'IETF pour cette raison là.

Cela pose aussi problème aux trucs qui collent les IP en dur. Je ne sais
pas à quel point c'est courant. On cite souvent Skype et Spotify.

> Sauf que si c'est déconseillé, je n'ai pas trouvé l'alternative
> recommandée.

Il y a le 464XLAT, mais cela assume que chaque device sait faire la
partie CLAT. Les téléphones sous Android et iOS savent faire, mais
j'ignore s'ils savent faire en wifi et comment les en persuader. Il va
falloir lire les RFC pour voir si c'est exploitable sur un LAN.
-- 
Avoid unnecessary branches.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] La taxe sur IPv4

[Vincent Bernat]

 ❦ 16 octobre 2019 18:04 +00, Michel Py :

> Comme si ce que font les municipalités hollandaises allait changer l'Internet.
> Moi je regarde les données, pas les présentations.
> En Hollande, IPv6 c'est 2,5% du traffic à AMS-IX.
> https://stats.ams-ix.net/sflow/ether_type.html

L'AMSIX, c'est 6T en pointe. C'est une goutte d'eau dans le trafic
régional. C'est utilisé pour faire du trafic entre acteurs du même type
ou pour initier des PNI à faible débit avant de switcher sur des liens
privés qui n'apparaissent donc pas dans les stats. Par exemple, Google
n'effectuera aucun peering via l'AMSIX si tu dépasses 1G de trafic avec
eux.

> Faut arrêter de vous pignoler, les mecs. Votre bousin IPv6-only,
> personne n'en veut.

Les données, c'est que les ISP switchent vers IPv6 car il n'y a pas
assez d'IPv4, notamment sur mobile. Ceux qui le font ont alors 70-95% de
leur traffic en IPv6 de bout en bout (State of IPv6 Deployment 2017,
Internet Society,
)
car le gros du contenu est disponible en IPv6 (Google / YT / Facebook /
Akamai / Cloudflare / Netflix, tous accessibles en IPv6). Le reste du
trafic passe alors par du CGNAT ce qui pousse les content providers à
passer en IPv6 pour ne pas subir les aléas d'un saut supplémentaire,
aussi bien en terme de latence que de disponibilité (le jour où le CGNAT
a un hoquet, comme la grande majorité du trafic ne passe pas à travers,
cela ne sera pas forcément prioritaire pour l'ISP en charge).

La pénurie d'IPv4 est emmerdant pour les content providers pour
atteindre les ISP historiques mais avec les conversions en cours, l'IPv4
est en bonne passe de devenir minoritaire dans quelques années (mais pas
de disparaître). Même Orange France bascule son réseau mobile en
IPv6-only avec du 464XLAT sur les terminaux compatibles depuis quelques
semaines.
-- 
The only way to keep your health is to eat what you don't want, drink what
you don't like, and do what you'd rather not.
-- Mark Twain


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

Re: [FRnOG] [TECH] Combien de temps pour atteindre 100% de visibilité sur un nouveau préfixe ?

[Vincent Bernat]

 ❦ 16 septembre 2019 17:43 +02, Alarig Le Lay :

>> Cogent fait de l’IRR ? C’est nouveau ? Pour moi, c’était justement le
>> seul des “gros” à ne pas être capable de le gérer convenablement… 
>
> Sisi, mes ranges de LIR et ceux que j’ai délégués sont passés chez eux
> alors que je n’ai jamais écrit à leur NOC à ce propos.

J'ai posé la question au support il y a moins d'un an et c'était pas
possible pour eux d'exploiter juste les préfixes présents en IRR.
Possible donc qu'ils ne te filtrent pas du tout.
-- 
Use uniform input formats.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] AS32 bit private range et SNMP

[Vincent Bernat]

 ❦  4 septembre 2019 12:54 +02, Guillaume Barrot :

> Merci pour toutes ces infos, mais j'avais déjà effectivement desactivé la
> MIB par défaut pour passer sur la MIB Juniper.
> Ma question était plutot, est-ce que tous les constructeurs ont intégrés ça
> dans une MIB propriétaire, ne respecte pas la RFC sur la MIB générique (ie,
> ont remplacé Integer32 par Unsigned32), ou bien s'appuie sur la MIB
> BGP4V2-MIB.
> En clair, qu'elle est (si elle existe) la solution la plus générique
> possible pour intégrer le max d'équipements (je n'ai que du Juniper et
> Fortinet sous la main, pas de Cisco, etc.)

La BGP4V2-MIB est toujours en draft au niveau IETF. Son auteur a jeté
l'éponge. Il faudrait différentes implémentations pour pouvoir la faire
avancer, mais aucun constructeur, y compris Juniper, ne veut se risquer
à implémenter une MIB qui risque de changer un an plus tard. Du coup,
chacun reste sur sa MIB proprio qui ressemble plus ou moins à la
proposition du draft.
-- 
Keep it simple to make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] linux route cache

[Vincent Bernat]

 ❦ 22 août 2019 12:21 +02, Pierre Colombier :

> pierre@zebulon: ~ $ ip route show cache
>
> ne retourne rien. (et ne se plaint pas non plus)
>
> J'aurais aimé avoir toute la liste plutôt que de spécifier une cible.
>
> Est-ce que je me trompe de cache ?
>
> est-ce ça a changé récemment ?

Il n'y a plus de cache depuis Linux 3.6. C'est remplacé par des
exceptions qui sont attachées à chaque entrée. À ma connaissance, il n'y
a pas moyen de dumper l'intégralité de ses infos.
-- 
AWAKE! FEAR! FIRE! FOES! AWAKE!
FEAR! FIRE! FOES!
AWAKE! AWAKE!
-- J. R. R. Tolkien


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

Re: [FRnOG] [MISC] IPV6 Name and Shame

[Vincent Bernat]

 ❦ 28 avril 2019 21:34 +02, Xavier Beaudouin :

> Reste les frontaux web... Non plus un (ou des) nginx en reverse proxy
> c'est pas non plus impossible... Surtout que Apple avec iOS impose le
> dual stack (sinon l'appli n'est pas validée du tout, facile à by
> passer mais... la tendance est là).

Apple impose le dual stack au niveau de l'appli. Le backend peut être
IPv4-only du moment que l'appli fonctionne dans un environnement
utilisant DNS64.
-- 
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] Bonding Linux mode active-backup

[Vincent Bernat]

 ❦ 23 avril 2019 17:02 +02, MERCKEL Aurélien :

> Est-ce que quelqu'un aurait déjà mis en production une configuration
> linux en avec 2 interfaces en mode bond, mode 1 (active-backup) avec
> les options arp_ip_target, arp_interval ?
> Beaucoup de documentations se contredisent (certaines indiquent que
> c'est possible, d'autres non).

Pas mis en production, mais arp_ip_target s'utilise en conjonction avec
n'importe lequel de modes, donc active-backup. La documentation
officielle donne même en exemple :

BONDING_OPTS="mode=active-backup arp_interval=60 arp_ip_target=192.168.1.254"

https://github.com/torvalds/linux/blob/master/Documentation/networking/bonding.txt
-- 
The difference between a Miracle and a Fact is exactly the difference
between a mermaid and a seal.
-- Mark Twain


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

Re: [FRnOG] [MISC] tagger correctement

[Vincent Bernat]

 ❦ 23 mars 2019 17:06 +00, Michel Py :

>> je trouve le rapport signal/bruit particulièrement et constamment faible.
>
> Ben t'est pas obligé de lire [MISC], si çà ne te plait pas pourquoi tu
> continues à lire ?

Cela ne changerait pas grand chose au problème. Tant que le bruit est
là, des conversations intéressantes n'auront pas lieu car personne ne
vient poser les questions et personne n'y apporte de réponses. Par
exemple, au milieu du brouhaha ambiant, il y a la question PA/PI qui n'a
obtenu aucune réponse franche. Pourtant, il doit bien y avoir des
personnes sur cette liste qui connaissent la réponse. Ou p'tet qu'il n'y
en a plus.
-- 
Make it right before you make it faster.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [MISC] tagger correctement

[Vincent Bernat]

 ❦ 22 mars 2019 19:25 +01, Stéphane Rivière :

> Et après on se fait taper sur les doigts... On se croirait à l'école,
> ça me rajeunit :)

Il est dommage qu'il soit nécessaire de rappeler les gens à l'ordre sur
une mailing list de professionnels du réseau. Personnellement, entre les
conversations personnelles n'ayant aucun rapport avec le réseau et la
tradition du "trolldi" qui démarre deux jours en avance et finit deux
jours en retard, je trouve le rapport signal/bruit particulièrement et
constamment faible. Il y a quand même une différence flagrante entre le
Michel Py qui poste ici et le Michel Py qui poste dans NANOG.

Les questions intéressantes sont noyées dans le bruit. Certains sont
sans doute dissuadés de poser leurs questions devant cette ambiance
village gaulois et certains de ceux qui pouvaient répondre ont cessé de
lire ou ne prennent plus la peine de répondre.
-- 
After all, all he did was string together a lot of old, well-known quotations.
-- H. L. Mencken, on Shakespeare


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

Re: [FRnOG] [MISC] Adoption de nouveaux protocoles

[Vincent Bernat]

 ❦  6 mars 2019 22:50 +00, Michel Py :

>> Nous sommes d'accord qu'IPv6 c'est pas demain qu'il va se généraliser
>
> Si tu as admis çà (comme beaucoup, aujourd'hui), regarde l'avenir.
> En tant que FAI, tu as quel choix ?
> 1. CGNAT
> 2. v6-only cote client + NAT64 & DNS64.
> Donc t'es dans la mouise, ou alors t'es dans la mouise :-( A tout
> prendre, je resterais sur CGNAT.

A priori, les nouveaux déploiements dans le mobile (T-Mobile, China
Telecom) se font en v6-only + NAT64 & DNS64. Y'en a p'tet qui les font
en CGNAT, mais ils osent pas en parler. Le résultat, c'est que la
majorité du trafic sur ces déploiements (Google, Facebook, Youtube,
Netflix) se fait en IPv6 natif. Si t'es un fournisseur de contenus en
IPv4-only, tu te retrouves à faire passer ton trafic à travers des
boîtiers supplémentaires sur lesquels l'opérateur n'est pas forcément
incité à fournir une qualité exceptionnelle. Si tes utilisateurs sont
sensibles à la perte de paquets ou à la latence, ils risquent de se
retrouver avec un service dégradé. S'ils sont essentiellement mobiles et
aux US, tu impactes ainsi les trois quarts de tes clients.
-- 
There is an old time toast which is golden for its beauty.
"When you ascend the hill of prosperity may you not meet a friend."
-- Mark Twain


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

Re: [FRnOG] [TECH] numero de Vlan élevé = problèmes ?

[Vincent Bernat]

 ❦ 22 février 2019 19:11 +01, "s.caps" :

> Question totalement naïve au dessus de quel chiffre c'est un
> paratonnerre à emmerdes ? Et pourquoi (compatibilités entre
> fabricants/modèles j'imagine ?)

Non, il n'y a aucun problème. Évite le range 1002-1005 qui est réservé
sur les Catalysts, mais tout le reste fonctionne sans soucis si tu as
des équipements fabriqués après les années 80.
-- 
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] solution gestion zones et serveurs DNS

[Vincent Bernat]

 ❦ 19 novembre 2018 11:54 +0100, Wallace :

> Alors pour couper cours, on ne souhaite pas utiliser les dns mis à
> disposition par OVH / Gandi / Amazon et consorts plusieurs raisons :
[...]

Avec dnscontrol, tu peux mixer deux opérateurs et ainsi ne pas avoir les
problèmes que tu cites.
-- 
Make input easy to proofread.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] 10Gbps chez les particuliers

[Vincent Bernat]

 ❦ 15 octobre 2018 08:09 +0200, Alexandre :

> Ces derniers temps, entre autre à cause de la (peut-être) sortie
> prochaine de la Freebox v7, on entend un peu parler de l'arrivée des
> connexions fibres 10Gbps chez les particuliers.
> Est-ce un mythe ou bientôt une réalité ?

En Suisse, Salt fait ça en XGS-PON. À voir l'intérêt par rapport à
d'autres opérateurs qui font du 1G symétrique en actif.
-- 
The mind is its own place, and in itself
Can make a Heav'n of Hell, a Hell of Heav'n.
-- John Milton


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

Re: [FRnOG] [TECH] BGP avec des switches "OpenNetwork"

[Vincent Bernat]

 ❦ 10 septembre 2018 18:44 +0200, David Ponzone :

> Un gros mot dès lundi ? :)

C'est exactement dans la target. À l'aide de tes vues et des
informations exportées par Netflow, ça te sélectionne les routes à
coller en hardware sur le routeur. Voir par exemple :
 http://www.pmacct.net/dbarroso_plucente_waltzing_v0.7.pdf
-- 
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] BGP avec des switches "OpenNetwork"

[Vincent Bernat]

 ❦ 10 septembre 2018 17:58 +0200, David Ponzone :

> Oui je suis assez d’accord.
> Si tu prends un petit modèle comme le Dell 4048-ON, tu as droit à 128K routes 
> IPv4.
> Or il est quand même à environ 2k€ en refurb (sans trop chercher).
> Donc ça va être franchement plus cher de tenir 1 ou 2M routes IPv4.

Tu associes ça à un produit SD-WAN et le tour est joué.
-- 
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] Protection contre les attaques DDoS en IPv6

[Vincent Bernat]

 ❦  1 août 2018 21:58 +0200, Matthieu Texier :

> De manière générale, une attaque ciblée IPv6 n’a pas beaucoup de sens
> dans la situation actuelle du déploiement. L’essentielles des
> plateformes et des fournisseurs d’accès, font utilisation de
> l’approche dual-stack. Cette approche rend une attaque IPv6 peu ou pas
> efficace. Les machines dual-stack mettant en oeuvre le happy eyeball
> (RFC 6555, RFC 8305), un client ne joignant pas une ressource en IPv6,
> basculera sur IPv4 dans les 250 ms rendant une telle attaque
> inopérante.

IPv6 passe généralement par les mêmes équipements et tuyaux qu'IPv4.
L'intérêt d'attaquer en IPv6, c'est de profiter du fait que l'outillage
pour se protéger est moins abouti que pour IPv4.
-- 
Use the fundamental control flow constructs.
- The Elements of Programming Style (Kernighan & Plauger)


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

Re: [FRnOG] [TECH] Quagga ou FRRouting ?

[Vincent Bernat]

 ❦ 30 juillet 2018 22:28 GMT, Michel Py :

> J'ai bientôt besoin de monter un serveur de routes, et o suprême
> insulte la syntaxe proche de Cisco est une nécessité donc pas de BIRD
> (dommage, j'aime bien leur looking glass).
> Quagga ou FRRouting ? j'ai mon avis mais j'aimerais bien savoir ce que
> la liste en pense.

FRRouting. Il y a peu de débat, Quagga est quasi-mort.

Pour un serveur de routes, il est dommage de se couper de la flexibilité
d'un BIRD. Selon l'usage, regarde ce que sait faire ARouteServer pour
générer la configuration.
-- 
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] 10G ER et 10G ZR sur le meme lien

[Vincent Bernat]

 ❦ 22 juin 2018 04:30 GMT, Michel Py  :

>> Est-ce que je peux mettre sur un même lien d'environ 20 km une optique 
>> 10G-ER à un bout
>> et une optique 10G-ZR avec un atténuateur de 5 dB en réception à l'autre 
>> bout ? Il ne me
>> semble pas clair si le codage du signal utilisé est le même pour les deux 
>> technos.
>
> Pourquoi tu veux faire çà ? J'aimerais bien savoir, c'est le genre de
> truc que j'essaierais (avec et sans l'atténuateur), je parie un
> bouchon de Stroh que çà marche, mais pourquoi tu n'achètes pas une
> deuxième optique 10G-ER pour 100 et quelques malheureux € ?

C'est sur du DWDM. Du coup, à la fois le prix et le fait que l'optique
est moins réutilisable.
-- 
You tread upon my patience.
-- William Shakespeare, "Henry IV"


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