Re: [TECH] [FRnOG] Re: Un CDN Down ?

2021-06-10 Par sujet Raphael Mazelier



On 10/06/2021 15:41, Damien Wetzel wrote:

Ton systeme ne fonctionne que si tu mets en cache que les sous domaines de ta 
page
(pas le www) et neccessite un developement agile du site (ils sont souvent 
figés et il est difficile d'en changer l'archi)


Disons que si tu as la problèmatique du multi cdn tu dois être assez 
gros pour avoir une équipe de dev capable de réaliser ceci. Après 
globalement ce que tu mets en cache c'est quand meme souvent tes assets 
et ou des choses très statiques qui ne sont pas accédé directement. 
Enfin tu peux tenter de CDNiser tout ton site mais c'est assez casse 
gueule, qu'on se rappelle la blague sur l'invalidation de cache.



D'autres part, j'ai l'impression que la plupart des resolveurs operateurs 
acceptent
et obeissent à des ttl relativement courts contrairement à une époque ancienne.
La solution DNS meme si elle n'est pas parfaite me parait la seule utilisable à 
l'heure
actuelle.


Je suis d'accord qu'avoir un ou plusieurs niveaux d'indirections niveau 
DNS avec des ttl(s) courts (et globalement ca marche meme si moche 
théoriquement) est une solution simple. La question après c'est à qui tu 
confie ta gestion de ton DNS. Les services types route53 sont vraiment 
pratique mais ont souffert leur lots d'indisponibilités. Tu peux aussi 
avoir un mécanisme qui controle différente API de différents fournisseur 
DNS en effet.


--

Raphael Mazelier


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


Re: [TECH] [FRnOG] Re: Un CDN Down ?

2021-06-09 Par sujet Raphael Mazelier



On 09/06/2021 14:51, Renaud Chaput wrote:

a m'ammène à la question du multi-CDN, est ce que sa complexité
se justifie pour palier à des problemes comme celui rencontré hier
qui sont quand meme relativement trés rares ?


Cela dépend de ton buisness comme toujours.

Le multi CDN n'est pas nécessairement complexe et tu n'as pas besoin 
d'un intermédiaire pour le faire.


Cela dépend evidement de ce que tu caches mais cela ne me parait pas 
déconnant d'avoir une brique interne qui construit les URLs de ce que tu 
as à cacher/servir via ton CDN.


On le faisait dans un previous job et cela avait beaucoup d'avantage, 
redondance de CDN, controle des couts aussi. Et tout cela sans 
intervention/magie DNS.


Tu peux meme cacher le resultat avec un ttl assez court pour lisser les 
gros burst et protéger tes origines. Cela ne te protégera pas 
complétement mais cela limitera beaucoup la casse.


Sinon en beaucoup plus simple tu utilise un DNS type route53 et tu fais 
du weighted DNS sur les x domains de tes x CDNs. Alors évidement dans ce 
cas tu déportes le spof chez ton fournisseur de DNS.




Est ce que avoir une config de secours sur un autre CDN + un DNS
configurable
rapidement avec des TTL courrs ~1min a un sens ?
Voir ci dessus, perso je pense que cela peut valoir le coup, mais tout 
dépend de ton buisness.


Le gros problème du multi-CDN c’est la configuration du-dit CDN. Si tu ne
t’en sers que pour du cache simple de fichiers statiques, pourquoi pas,
mais si tu fais des choses plus complexes (réécriture de requêtes,
sécurité, optimisation d’images, routage dynamique, intelligence at the
edge) ça devient beaucoup plus compliqué.


J'ai un avis assez tranché sur le fait qu'on ne devrait pas mettre 
d'intelligence spécifique à un fournissseur CDN (ou autre d'ailleurs) 
pour des raisons de risque de couplage.


Sinon quand tu veux bouger pour x raisons (souvent financière) tu es un 
petit peu dans le mal.




Et vu que la grosse force de Fastly c’est de pouvoir faire un peu ce que tu
veux en terme de config, ça me parait vraiment complexe de le redonder. Et
ensuite, quelle est la probabilité que ta brique qui gère la redondance
cause à son tour une panne, est-ce plus ou moins élevé que la proba que
Fastly (ou autre) tombe ? Est-ce que tu n’introduis pas un SPOF via ton
outil de multi-CDN ?

Bref, sujet complexe et pas évident quand on commence à considérer tous les
aspects.


Assurément mais passionnant.

--

Raphael



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


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

2021-06-09 Par sujet Raphael Mazelier



On 09/06/2021 18:51, Michel Py via frnog wrote:


Je confirme SFR pour les deux (vu de Verizon). Vu que tu prepends 6 fois ton AS 
pour le 225, il serait logique en effet que le chemin par Cogent soit préféré, 
mais non.
Par contre, en venant de Comcast, ça passe par Cogent.


6 fois carrement ? de souvenir au dela de 3 tout le monde normalise.

Et encore une fois après ton transitaire il réanonce bien comme il veut.

--

Raphael Mazelier


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


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

2021-06-09 Par sujet Raphael Mazelier
Oui ca ca doit marcher, parce si que tes upstreams changent tes annonces 
la c'est vraiment abusé.


On 09/06/2021 18:41, David Ponzone wrote:

Certes.

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


Le 9 juin 2021 à 18:32, Raphael Mazelier  a écrit :

De toute manière on ne répettera jamais assez qu'influencer le trafic in n'est 
pas une science exacte, tes upstreams pouvant précisement faire ce qu'ils 
veulent.

On 09/06/2021 18:21, David Ponzone wrote:

J’ai pas encore regardé en détail, mais déjà avoir comme upstream:
-un Tier1 (même si certains considèrent que Cogent n’est pas un T1)
-un Tier2, qui comme toi a ce Tier1 comme upstream
c’est se mettre dans une situation un peu compliquée et que tu maitrises pas 
forcément.

Moi de mon côté, je vois:
80.77.224.0/24 par SFR seulement, sans prepend
80.77.225.0/24 par COGENT (sans prepend) et par SFR (avec prepend)

Donc c’est bon.

Qu’est-ce qui te fait penser qu’il y a un problème ?
Zero traffic sur le lien Cogent ?




---
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][BGP] Traffic arrivant sur un seul lien au lieu de deux

2021-06-09 Par sujet Raphael Mazelier
De toute manière on ne répettera jamais assez qu'influencer le trafic in 
n'est pas une science exacte, tes upstreams pouvant précisement faire ce 
qu'ils veulent.


On 09/06/2021 18:21, David Ponzone wrote:

J’ai pas encore regardé en détail, mais déjà avoir comme upstream:
-un Tier1 (même si certains considèrent que Cogent n’est pas un T1)
-un Tier2, qui comme toi a ce Tier1 comme upstream
c’est se mettre dans une situation un peu compliquée et que tu maitrises pas 
forcément.

Moi de mon côté, je vois:
80.77.224.0/24 par SFR seulement, sans prepend
80.77.225.0/24 par COGENT (sans prepend) et par SFR (avec prepend)

Donc c’est bon.

Qu’est-ce qui te fait penser qu’il y a un problème ?
Zero traffic sur le lien Cogent ?





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


Re: [FRnOG] [TECH] Technos pour du lan bouclé

2021-06-04 Par sujet Raphael Mazelier

Salut Pierre,

Moi j'aime bien celle de l'oob qui boucle et qui mets par terre toute la 
prod :)


Dans une autre vie j'ai pas mal d'anectode avec le VTP, ou avec du 
redback aussi...


En effet ca serait intérressant d'archiver toutes nos expériences de 
prod un peu touchy/marrante et pas que de le réseau d'ailleurs, j'ai un 
paquets d'histoire coté systeme/stockage aussi.


++

On 04/06/2021 17:46, Pierre LANCASTRE wrote:

Roh j en ai pas mal des histoires comme ça, et des récentes sur d'autres
matos, mais même si c' est Vendredi, on va éviter de trop en dire.

Petite question : il existerait un forum / blog type "corbeau du réseau" où
seraient tracés les bugs les plus sympas que les gens aient pu voir ?





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


Re: [FRnOG] [BIZ] Recherche fibre noire ou lambda 10G France-IX <=> Equinix PA4

2021-05-20 Par sujet Raphael Mazelier



On 20/05/2021 16:51, Radu-Adrian Feurdean wrote:


Ca depend de MUX. Il y en a avec des filtres, il y en a sans.



Ca dépend, ca dépasse :)

J'imagine tout de meme que chez lambda-paris (sipartech) on a des mux 
qui filtrent.


De souvenirs d'ailleurs ils testent bien ton optiques et ne te laissent 
pas trop le choix (du ZR quoi, pour pouvoir se permettre du re-reroutage 
le cas écheant)


--

Raphael Mazelier


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


Re: [FRnOG] [BIZ] Boitier Multi-ISP

2021-05-04 Par sujet Raphael Mazelier



-

A cause de l’option manquante pour ajouter une route statique sur la Livebox en 
mousse ?

Tu t’en fous, tu fais du NAT sur ton routeur intermédiaire, et y a un autre NAT 
sur le CPE opérateur.
Le double-NAT a jamais tué personne.
Tu peux aussi virer la Livebox….



C'est ce que j'allais dire. Le moins d'equipement de ton ISP tu as le 
mieux tu te portes en général.


--

Raphael Mazelier


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


Re: [FRnOG] [BIZ] Looking for Data Centers Near Orléans

2021-04-22 Par sujet Raphael Mazelier






Brittany => Rennes => Reims => Orleans ...


You may want to try Paris :-)



it's getting closer.

--
Raphael Mazelier


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


Re: [FRnOG] [TECH] Panne SIP Free (Free et Centile)

2021-04-22 Par sujet Raphael Mazelier



Le SIP over internet, over un truc qui fait du bricolage nat comme le 
cgnat free, bon courage en effet. C'est bien pour cela que les 
entreprises de Centrex fournissait l'accès internet ou exigeait un accès 
vraiment neutre (ou mettais en place un VPN). bref bon debug.


--

Raphael Mazelier

On 22/04/2021 11:02, Emmanuel DECAEN wrote:

Bonjour,

Oui, je constate aussi le problème, cela ne concerne pas que Centile, 
j'ai une borne Gigaset N720 touchée.

Dans le cas de la borne Gigaset, l'audio ne fonctionne que dans un sens.

Il faudrait voir si la nouvelle version des Freebox (4.3.x) n'est pas 
en cause.





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


Re: [FRnOG] [TECH] Panne Free sur des centaines de DSLAM ?

2021-04-21 Par sujet Raphael Mazelier



Les dslams font grêve suite au départ de Rani ?

/me => []

--

Raphael Mazelier

On 21/04/2021 09:55, jehan Procaccia wrote:

bonjour,

apparement il y aurai une panne generalisée de centaines de DSLAM [1] 
Free  dans l'oeust/sud-ouest !?


cf https://www.free-reseau.fr/

*[1] 361 DSLAMs ne sont pas joignables actuellement*





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


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

2021-03-30 Par sujet Raphael Mazelier



On 30/03/2021 17:01, David Ponzone wrote:

Go Krotik!

C’est du pppoe sur un l2 de bout en bout, ou dans du L2TP ?



Il y a pas des solutions soft sous nux ou bsq qui pourraient faire le taf  ?


--

Raphael Mazelier


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


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

2021-03-10 Par sujet Raphael Mazelier



On 10/03/2021 10:00, Wallace wrote:

Vous avez souvenir d'autres incidents du même type en France ou EU? A
part des mini départs lors de maintenances maitrisés rapidement avec ou
sans impact électrique, je n'ai pas connaissance d'autres cas.


Bonjour, et bien sur toutes mes pensées aux OPs Ovh et autres sociétés 
qui sont impactés par ce sinistre.


Je me posais la même question si on avait des cas similaires récents (ou 
moins) en France. Le seul truc dont je me rappelle qui ressemble 
vaguement à cela c'est l'incendie partiel de NetCenter CBV en 2004(5?). 
Un moteur de climatisation avait pris feu, ce qui avait eu la double 
conséquence de 1) faire prendre feu au batiment 2) couper la clim sur 
une partie du DC. L'incendie en lui meme avait été promptement éteint 
mais la clim avait du mettre une 20aine d'heure à revenir. Résultat des 
courses il y avait eu beaucoup de casse dans les salles. A l'époque ma 
société s'en était bien sortie car nous avions pu accéder à notre salle, 
tout éteindre, et ouvrir les fénetres (sic). Mais d'autres n'avaient pas 
eu cette chance, et a priori il y avait eu beaucoup de matériel HS.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Convertisseur Fibre 1G LC - Cuivre en DC

2021-03-04 Par sujet Raphael Mazelier
N'importe quel média conv fera l'affaire. Niveau fiabilité ces trucs 
sont tellement simple qu'ils marchent. J'ai en mis en prod des dizaines 
et n'ai jamais eu à m'en plaindre ; type : 
https://www.fs.com/c/media-converters-extenders-1037


vu le prix tu prends un spare et voilà :)

--

Raphael Mazelier

On 04/03/2021 09:34, Fabien H wrote:

Bonjour,

je suis à la recherche d'un convertisseur fiable pour brancher une porte de
collecte monomode LC 1G sur un routeur CISCO avec port Cuivre 1G.

Je ne peux pas utiliser nos SW CISCO pour faire la conversion pour des
raisons d'isolation des VLAN qui y transitent.

Avez-vous des références très fiables (uptime et non buggé) et pas trop
trop cher ? Alim 220V

Merci,
Fabien

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



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


Re: [FRnOG] [MISC] Comment AWS implémentent-tils 169.254.169.254?

2021-02-23 Par sujet Raphael Mazelier



On 23/02/2021 10:05, Philippe Bourcier wrote:


Cela dit, tu peux aussi faire un réseau entièrement static en adressage 
APIPA... comme si c'était une autre plage d'IPs privées (192.168/16, 10/8, 
etc.) et c'est ce que semble faire AWS.


Pour répondre à la question initiale : comment AWS gére 169.254.169.254 
(et quelques autres) ?


Sur ton instance AWS en général tu vois une route du style :

|169.254.0.0/16 dev INT_PRIV_VPC scope link metric 1000 |

Donc si tu interroge donc 169.254.169.254 la trame va partir sur le 
réseau local et un équipement réseau va l'intercepter pour la rediriger 
vers un serveur de metadata proche.


On peut dire que l'IP en question est partout et nulle part à la fois 
(sur aucun équipement/serveur) :p


D'une manière générale AWS fait du custom sur son réseau; ca serait très 
intérressant de savoir comment ils gérent toute cette infra at scale 
mais ce n'est pas très publique. (il y a bien quelque confs, papiers 
mais cela reste parcelaire)


--

Raphael Mazelier


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


Re: [FRnOG] [MISC] TF1.....

2021-02-18 Par sujet Raphael Mazelier



On 18/02/2021 14:12, David Ponzone wrote:

Pas de JT de 13h sur TF1, la cause serait une cyber-attaque (ransomware ou 
autre).
Quelqu’un (de E-TF1 peut-être) aurait plus d’infos ?

etf1 c'est très séparé du "broadcast" tf1. De toute facon même si 
quelqu'un savait quelque chose ce serait étonnant qu'il commente cela 
publiquement, car pour connaitre un petit peu la boite je me doute que 
cela a du être une décision difficile.


Attendons donc le communiqué officiel.

--

Raphael Mazelier



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


Re: [FRnOG] [MISC] Notre meilleur argument pour vendre du FTTO

2021-01-15 Par sujet Raphael Mazelier




Tain le cauchemard… C'est fou, et désespérant…

On voit aussi un peu de positif avec des opérateurs qui forcent les 
recâblages et qui semblent avoir compris un petit peu l'ampleur du 
problème.


Mais dans l'ensemble cela ne m’étonne guère ; déjà à l’époque qu'est ce 
que j'ai pu pester contre le câblage fait en datacenter de certaines de 
mes précédentes compagnies dans les telcos (avec de belles exceptions, 
coucou max, coucou etf1).


Ce que je trouve particulièrement désolant c'est que les personnes qui 
réalisent du mauvais câblage n'ont aucun respect pour les personnes qui 
viennent après eux. C'est un manque de professionnalisme et de l’égoïsme.


--

Raphael Mazelier



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


Re: [FRnOG] [TECH] 1.1.1.1 sur France-IX

2021-01-13 Par sujet Raphael Mazelier
C'est réparé depuis 3215 et ça passe bien par 5510. Coïncidence ? je ne 
crois pas.


--

Raphael Mazelier


On 13/01/2021 18:27, Philippe ASTIER via frnog wrote:

Yep ! Réactifs, CloudFlare :)

philippe@Mini-M1 Application Support % host yahoo.fr <http://yahoo.fr> 
1.1.1.1

Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases:

yahoo.fr <http://yahoo.fr> has address 74.6.136.150
yahoo.fr <http://yahoo.fr> has address 124.108.115.100
yahoo.fr <http://yahoo.fr> has address 212.82.100.150
yahoo.fr <http://yahoo.fr> has address 106.10.248.150
yahoo.fr <http://yahoo.fr> has address 98.136.103.23
yahoo.fr <http://yahoo.fr> mail is handled by 10 
mx-eu.mail.am0.yahoodns.net <http://mx-eu.mail.am0.yahoodns.net>.


Le 13 janv. 2021 à 18:24, Clement Cavadore <mailto:clem...@cavadore.net>> a écrit :


Probleme réglé :)

Host    Loss%   Snt   Last   Avg  Best 
 Wrst StDev

(...)
2. hundredgige0-8-0-2.auvtr5.auberv  0.0% 2    0.9   0.9   0.9 
  0.9   0.0
3. hundredgige0-1-0-10.partr2.saint  0.0% 2    0.9   0.9   0.9 
  0.9   0.0
4. cloudflare-18.gw.opentransit.net 
<http://cloudflare-18.gw.opentransit.net>  0.0% 2    1.8   1.6 
  1.4   1.8   0.2
5. one.one.one.one   0.0% 1    1.2   1.2   1.2 
  1.2   0.0


Le mercredi 13 janvier 2021 à 09:06 -0800, Louis Poinsignon a écrit :

On a mis à jour Cloudflare status: pour suivre l'incident en cours
https://www.cloudflarestatus.com/incidents/t2vcfxt28rwn 
<https://www.cloudflarestatus.com/incidents/t2vcfxt28rwn>


On Wed, Jan 13, 2021 at 8:54 AM Jérôme Fleury 
wrote:


Merci pour le signalement. C'est en cours d'investigation chez
Cloudflare.

En ce qui concerne l'annonce sur les RS, je confirme que Cloudflare
n'annonce pas 1.1.1.0/24 et 1.0.0.0/24 sur les route-servers de
FranceIX
(et aucun route-server en general)

On Wed, Jan 13, 2021 at 5:48 PM Clement Cavadore <
clem...@cavadore.net>
wrote:


Message passé à qui de droit pour 1.1.1.1, tant coté Cloudflare,
que
OTI. (Nb: 1.0.0.1 fonctionne depuis OTI)

Le mercredi 13 janvier 2021 à 17:30 +0100, Romain a écrit :

Si, ça dépend comment tu tests. Ca a été corrigé via le
firmware il y
a
longtemps, même si un traceroute par défaut le route en local
sur la
livebox.
Un traceroute en UDP sur le port 53 montre bien un routage
correct
vers
l'extérieur.

Le mer. 13 janv. 2021 à 17:17, Paul Caranton <
caranton.p...@gmail.com

a

écrit :


1.1.1.1 ne fonctionne pas derrière une Livebox (pas la 4 en
tout
cas).

Paul
AS208261

Le 13 janv. 2021 à 17:16, à 17:16, Raphael Mazelier <
r...@futomaki.net> a
écrit:

Je ne sais pas mais chez moi (cnx orange) 1.1.1.1 était
pétave
aussi.

On 13/01/2021 17:03, David Ponzone wrote:

Ami.e.s France-IXien.ne.s,

Est-ce normal que Cloudflare n’annonce pas le 1.1.1.0/24
aux RS
de

France-IX ?

Merci


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


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


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



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


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



---
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/ <http://www.frnog.org/>




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


Re: [FRnOG] [TECH] 1.1.1.1 sur France-IX

2021-01-13 Par sujet Raphael Mazelier



On 13/01/2021 18:00, David Ponzone wrote:

Je me demande si c’est pas une coïncidence. Un dev qui aurait utilisé 1.1.1.1 à 
une époque où c’était sans impact.
Sinon, ils intercepteraient 8.8.8.8 aussi non ?


Pour la livebox je ne sais pas. Je pensais plutôt à la SFR box qui fait 
de l'interception magique de dns (quel qu'il soit), en filtrant par 
exemple les rfc1918. A quoi ça sert ?


--

Raphael Mazelier



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


[FRnOG] Re: [TECH] 1.1.1.1 sur France-IX

2021-01-13 Par sujet Raphael Mazelier



On 13/01/2021 17:18, Stephane Bortzmeyer wrote:

Il doit s'agir de deux choses différentes. L'absence sur les serveurs
de route ne signifie pas injoignabilité (le transit est là) et
certaines Livebox ont un microcode qui fait des choses pas belles avec
1.1.1.1.


Parce que j'ai une tête à garder la livebox ? :)

--

Raphael Mazelier


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


Re: [FRnOG] [TECH] 1.1.1.1 sur France-IX

2021-01-13 Par sujet Raphael Mazelier

Je ne sais pas mais chez moi (cnx orange) 1.1.1.1 était pétave aussi.

On 13/01/2021 17:03, David Ponzone wrote:

Ami.e.s France-IXien.ne.s,

Est-ce normal que Cloudflare n’annonce pas le 1.1.1.0/24 aux RS de France-IX ?

Merci


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



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


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

2021-01-09 Par sujet Raphael Mazelier



On 08/01/2021 22:27, Pierre LANCASTRE wrote:



Récemment retourne chez Free en Freebox PoP en fibre (négo a 5G/700M) 
je suis très loin de saturer le downstream et j'ai eu pas mal de 
problèmes de lag/glitch de son, signe de perte de paquets. Mais pas 
sur toutes les chaînes, c était surtout TF1 et BFM TV pendant les Peak 
hours. Sachant que je suis en filaire partout et qu avec ma box orange 
j' avais 0 souci, je pense que ça vient de plus haut :) peut être 
saturation entre leur backbone et l olt de ma zone, ou plus haut? Il y 
a pas mal de Root cause possibles. En tout cas, ce soir tout va bien, 
peut être qu ils ont lu le thread ^^


My 2 cents

Sur le flux tnt ? bah c'était peut être une saturation généralisée sur 
le réseau de distribution des flux tv coté Free ? (je rappelle flux live 
"tnt" ça reste sur les infras des opérateurs, et heureusement j'ai envie 
de dire)


--

Raphael Mazelier



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


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

2021-01-08 Par sujet Raphael Mazelier



On 07/01/2021 20:26, Vincent Bernat wrote:

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.


Piste intéressante mais dans le cas de David il semble dire qu'il n'y a 
pas spécifiquement d’activé sur la box au même moment (après question à 
la noix, il y aurait t'il le freewifi d'activé ?)


--

Raphael Mazelier


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


Re: [FRnOG] [MISC] SFR NUMERICABLE, c'est déjà trolldi ?

2021-01-08 Par sujet Raphael Mazelier



On 08/01/2021 08:01, Benoit SERRA wrote:

En aparté, abonné à SFR-NUMERICABLE depuis presque 3 ans (c'est ça ou l'accès 
adsl à 2mbps) j'ai constaté que leur box, en mode Routeur, ne donne pas le 
débit. Mais passée en mode bridge avec un vrai routeur derrière, j'ai le débit 
quasi nominal en 1Gbps Dl et 50 Mbps UL.

Yes en réduisant la box au minimum vital cela fonctionne (Box SFR Zive). 
Il faut passer en mode "bridge" et tout désactiver et c'est ok. De base 
la box gère très très mal le nat. A noter tout de même que la box fait 
quand même de l'interception DNS, bridge ou pas ce qui peut être pénible.


--

Raphael Mazelier



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


Re: [FRnOG] [TECH] Règles de Nommage des zones DNS privées

2021-01-08 Par sujet Raphael Mazelier



On 07/01/2021 20:59, Philippe Bourcier wrote:


Enfin, j'aurais tendance à prendre un mondomaine.tld dédié à l'IT, qui n'a pas 
forcément de lien avec le nom de la boîte, ce qui permet d'éviter une migration 
AD en cas de revente/renommage de la boîte...




+1000 on ne sait jamais si une société va être racheté ou non, alors le 
domaine interne sans rapport avec le nom de la société c'est souvent 
salvateur.


--

Raphael Mazelier


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


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

2021-01-07 Par sujet Raphael Mazelier



On 07/01/2021 17:14, David Ponzone wrote:

C'est sûr, mais 13h30, même en ce moment, j’avais du mal à imaginer que ça soit 
une crête du même ordre que celle du soir.


Ah tu as le problème à 15h30 ? a la fois sur le flux "tnt" et en OTT ?

Very strange.


--

Raphael Mazelier


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


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

2021-01-07 Par sujet Raphael Mazelier



On 07/01/2021 17:07, David Ponzone wrote:


Tout est possible, je dois refaire des tests, mais au même moment, je n’avais 
aucun problème depuis une fibre Bouygues.


Sur les peak hours ça m’étonnerait guère que divers trucs qui n'ont 
aucun rapport soient saturés.


--

Raphael Mazelier


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


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

2021-01-07 Par sujet Raphael Mazelier



On 07/01/2021 16:58, David Ponzone wrote:



Ben non puisque ça déconne aussi en OTT sur le web de France2 ou Arte.


Simple coincidence horaires ?

--


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


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

2021-01-07 Par sujet Raphael Mazelier



On 07/01/2021 16:11, David Ponzone wrote:
En streaming, le splitter est le serveur qui reçoit un flux live et le 
diffuse vers X clients. Enfin, ça s’appelait comme ça avant.
Mais d’après ce que tu me dis, les chaines sont reçues par le FAI avec 
une techno de broadcasting dédiée (IP ou non), probablement via un TDF 
ou Globecast, et donc, plus de point commun, sauf le réseau interne Free.


En général pour les grosses chaînes et FAI c'est en direct de gré à gré, 
avec une techno X de broadcast (je ne me rappelle même plus, peut être 
du SDI over IP, enfin en tout cas un flux full patate niveau qualité). 
Pour les plus petits broadcaster, ou pour le backup ca peut passer par 
des réseaux intermédiaires style TDF par exemple, mais cela reste des 
réseaux privés.


Un joyeux bazar de fibre bien concentré à TH2 par ailleurs.


J’ai oublié de dire qu’au même moment, j’ai fait un nperf à 12Mbps 
descendant, 500Kbps montant, ce qui est à peu près la capa de l’ADSL, 
donc j’ai pas de raison de penser que le réseau de Free va mal 
(fast.com <http://fast.com> et openspeedtest.net 
<http://openspeedtest.net> m’ont par contre sorti un résultat 
délirant, du genre 12Mbps entrants et 120Mbps sortants, ça arrive de 
plus en plus souvent).

Bref, pas assez de tests pour comprendre, je vais essayer d’en faire plus.

C'est peut être le réseau/infra de streaming interne de Free qui est 
saturé ?


--
Raphael Mazelier


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


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

2021-01-07 Par sujet Raphael Mazelier



On 07/01/2021 16:01, David Ponzone wrote:

Il y a quand même un point commun si le flux live de France2 arrive en IPv4 
vers les splitters de Free.
France2——IPv4——> Free Splitter——IPvx——>abonné
France2——IPv4———>abonné Free
Dans les 2 cas, le transit IPv4 de Free est impliqué mais j’ai du mal à croire 
qu’ils saturent vers France2 et Arte etc…..
Ou alors ils ont un problème sur un IX depuis quelques jours.



Je ne t'ai pas suivi : qu'est ce que tu appelles les splitters free ?

Les flux live des chaînes qui sont redistribués par les FAI sont sur des 
réseaux privés bien séparés (et qui ne sont pas saturés, enfin on 
peut/doit l’espérer, et aussi c'est un débit stable et fixe dans le 
temps ) .


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Règles de Nommage des zones DNS privées

2021-01-07 Par sujet Raphael Mazelier



On 07/01/2021 15:25, Alain Bieuzent wrote:

Bonjour la liste,

  


Existe t’il quelque part des règles ou recommandations de nommages des zones et 
sous zones DNS.

  


Par ex , quels est le plus propre entre :
printer.private.fr.mondomaine.tld
ou
private.printer.fr.mondomaine.tld
ou
fr.printer.private.mondomaine.tld
etc …



Bonne question. A priori la seule vrai règle est d'utiliser un vrai 
domaine publique et non whatever.priv ou whatever.internal. Je ne vois 
pas de problème à utiliser priv.corp.com par exemple.


--

Raphael Mazelier



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


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

2021-01-07 Par sujet Raphael Mazelier
Hello je vais essayer de te répondre car j'étais dans le milieu il n'y a 
pas si longtemps.


On 07/01/2021 14:21, David Ponzone wrote:

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).
Depuis un PC en WIFI, même problème sur le web direct de France2 ou Arte (en 
IPV4 à priori), mais Netflix est nickel (en IPv6 probablement).

Je me demande donc où est le dénominateur commun: est-ce que quand je vais sur 
le web direct de France2 ou Arte, je suis renvoyé vers un serveur de streaming 
chez Free (auquel cas il a du mal en ce moment aux heures de pointe), ou est-ce 
que quand je regarde une chaine TNT sur la Freebox TV, je suis renvoyé vers les 
serveurs de la chaîne demandée (auquel cas c’est plutôt le transit IPv4 de Free 
qui aurait un souci mais ça me semble un peu gros). Connaissant la logique 
économique d’un FAI, je suppose qu’ils font le maximum pour que ça reste on-net 
donc je penche pour le cas 1.
Ou il y a un dénominateur commun que j’ai raté….


Il faut bien distinguer deux cas :

- le live et replay depuis ta freebox (et/ou player free) tu tapes sur 
les serveurs/archi free. Dans les deux cas le contenu est ingéré depuis 
chaque broadcaster vers free. Pour le live c'est fait via des DFs 
dédiés, en multicast . Ensuite Free en fait ce qu'il veut et en 
l’occurrence le diffuse via son infra que je connais mal, mais qui 
globalement ré-encode le flux recu, le mets sur ses serveurs et le 
diffuse (je crois que ca utilise du multicast aussi, et que c'est un peu 
régionalisé). Pour les replays, les broadcasters envoient les replays 
via X méthodes (ftp parfois :) ) puis pareillement Free le ré-encode et 
les mets sur ses serveurs puis les diffuse de la manière qu'il lui plaît 
(pour le coup c'est sans doute un simple CDN interne).


- le live et replay OTT, donc quand tu vas sur le site de chaque 
broadcaster. Dans ce cas tu passes via le grand internet et tu tapes sur 
les serveurs de diffusions des chaînes qui sont soit délivrés via des 
CDNs publiques ou via des CDNs privée (certains broadcaster ont des PNIs 
avec Free). Pas de magie ici.


Il n'y a donc pas vraiment de point commun, à part qu'au départ tu 
passes par le réseau interne Free. Si dans les deux cas tu as 
l'impression que c'est saturé au même horaires c'est soit une 
coïncidence, soit que le réseau interne de ta plaque Free est saturé à 
ce moment, mais c'est étrange que Netflix passe au même moment.


--

Raphael Mazelier








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


Re: [FRnOG] [BIZ] Revendeur câble RJ45 au métre

2021-01-04 Par sujet Raphael Mazelier

Ah tu as un lien pour ca ?

On 04/01/2021 12:50, Xavier Beaudouin wrote:

Il y a des connecteurs SC/UPC (ou même SC/APC) qui sont a visser qui font assez 
bien le travail.

Oui c'est moins chouppi qu'un beau connecteur bien fait, mais ça marche.

- Mail original -

De: "Raphael Mazelier" 
À: "frnog" 
Envoyé: Lundi 4 Janvier 2021 12:20:43
Objet: Re: [FRnOG] [BIZ] Revendeur câble RJ45 au métre

Sans pousser à la consommation (à la maison je reste au cuivre et au wifi), çà
devient plus que raisonnable :
Switch 8 ports GE plus 2 ports SFP+ 10G : cent balles
https://mikrotik.com/product/css610_8g_2s_in

SFP+ 10G : 16 balles
https://www.fs.com/fr/products/74668.html?attribute=106

Jarretière 10G fibre 2m : 4 balles
Plus long : 1 € le mètre
https://www.fs.com/fr/products/40220.html


Pas de problème coté équipement, SFP. C'est plus que je ne peux pas
faire passer une jarretière dans mes fourreaux (encore que je pourrais
essayer) et que je n'ai pas le matos pour faire les connecteurs.

--

Raphael Mazelier


---
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] [BIZ] Revendeur câble RJ45 au métre

2021-01-04 Par sujet Raphael Mazelier




Sans pousser à la consommation (à la maison je reste au cuivre et au wifi), çà 
devient plus que raisonnable :
Switch 8 ports GE plus 2 ports SFP+ 10G : cent balles
https://mikrotik.com/product/css610_8g_2s_in

SFP+ 10G : 16 balles
https://www.fs.com/fr/products/74668.html?attribute=106

Jarretière 10G fibre 2m : 4 balles
Plus long : 1 € le mètre
https://www.fs.com/fr/products/40220.html

Pas de problème coté équipement, SFP. C'est plus que je ne peux pas 
faire passer une jarretière dans mes fourreaux (encore que je pourrais 
essayer) et que je n'ai pas le matos pour faire les connecteurs.


--

Raphael Mazelier


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


Re: [FRnOG] [BIZ] Revendeur câble RJ45 au métre

2021-01-04 Par sujet Raphael Mazelier



On 04/01/2021 11:51, Daniel Caillibaud wrote:

Tant qu'on cause câbles, est-ce que la fibre résiste mieux dans la durée en 
extérieur ?

Je dois tirer des câbles elec dans un fourreau enterré pour alimenter une 
maison de jardin, et
je voulais y passer aussi un câble réseau, mais on m'a dit (sur une ml, me 
rappelle plus où)
que c'était pas très résistant dans le temps (froid et humidité).

Du coup j'hésite, car ça va pas servir avant un an ou deux (faut d'abord 
construire la maison),
et un répéteur wifi près d'une fenêtre sera peut-être suffisant (actuellement 
ça sort très mal
de la maison).

Je dois tirer tout ça maintenant car l'accès au fourreau va devenir bcp plus 
compliqué ensuite…

La fibre ne craint pas grand chose surtout si c'est dans un fourreau. 
Enfin cela craint les , mais a priori pas grand chose coté condition météo.


Je reviens du massif central ou on déploie la fibre en aérien donc c'est 
pour te dire qu'avec le bon type de câble zéro problème. Et conseil fait 
le avant qu'il soit trop tard; tu vois moi quand j'ai acheté mon appart 
je n'ai pas câblé et maintenant je vais faire du bricolage pas très propre.




--

Raphael Mazelier



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


Re: [FRnOG] [BIZ] Revendeur cable RJ45 au métre

2021-01-03 Par sujet Raphael Mazelier



Merci à tous pour ces réponses. J'ai appris quelques trucs, notamment 
l'existence du CCA (je comprends pourquoi, le cuivre est cher, mais je 
ne savais pas qu'on en était arrivé là).


Je vais donc partir sur du cat6 classique bien raide, mon ambition étant 
le 1G en passant par des gaines existantes. Je pourrais fibrer mais je 
n'ai pas le matériel, et pour le moment çà se terminerait avec des 
convertisseurs, donc on verra quand cela se présentera.


Par ailleurs si par hasard quelqu'un sur la liste en RP possède du rab, 
je peux échanger contre divers matos en stock (cpe cisco divers, petit 
fw srx, mediaconv, sfp, xfp, etc..) en MP.


--

Raphael Mazelier





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


[FRnOG] [BIZ] Revendeur cable RJ45 au métre

2021-01-01 Par sujet Raphael Mazelier

Bonne année 2021 amis des réseaux !

Bonne résolution de l'année (entre autre choses) je vais enfin me 
décider à câbler mon appartement.


J'aurais donc besoin d'acheter du câble RJ45 CAT6 ou 7 au mètre (200m 
environ). Retiré du business réseau si vous avez des bons revendeurs à 
me conseiller je prends.


Merci.

--
Raphael Mazelier



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


Re: [FRnOG] [TECH] lien de transit SFR

2020-12-18 Par sujet Raphael Mazelier

Bonjour,

Latence, packet loss quelconque ? Quel type de lien de transit ? sur 
quel medium ?


btw pourquoi prendre du transit chez SFR ? (seul transitaire disponible ?)

Cdt,

On 18/12/2020 11:52, Nicolas Parpandet wrote:


Bonjour,

Nous avons un nouveau lien de transit 1Gbits/s avec SFR,
l'UDP monte bien à 850Mbits, mais une session tcp plafonne à 100Mbits/s comme 
si il y avait une QOS quelque part sur les sessions TCP,
(le chiffre de 100Mbits/s revient tellement souvent dans nos tests, la 
probabilité que cela soit lié au hasard me semble faible...)

De plus, avec une dizaine de sessions tcp en // , le débit global plafonne à 
350Mbits...

Cela fait plusieurs semaines que nous échangeons dans tous les sens avec 
l'opérateur (iperfs etc),
c'est bien sur à nous de prouver le problème, et cela n'avance pas !

est-ce que quelqu'un sur la liste aurait déjà rencontré ce type de limite avec 
cet opérateur ?,
nous avons fait énormément de contrôles de notre côté, il me semble que c'est 
bien en face le soucis ...,
il peut toujours subsister un doute, mais si quelqu'un à une expérience sur le 
sujet !

Merci, A+

Nicolas



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



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


Re: [FRnOG] [BIZ] Devis Diagnostic CRC Fibre

2020-12-17 Par sujet Raphael Mazelier

Bonjour,

Tu peux déjà commencer par lire les niveaux optiques sur tes interfaces/sfp.

Cela te donnera un début d'idée de si tu es complètement limite niveau 
budget optique ou pas.


Sinon cela peut être aussi tes SFP; as tu testé de changer une paire ?

Cdt,

On 17/12/2020 11:49, Fabien wrote:

Bonjour la liste,

Je travaille dans l'équipe réseau d'une entreprise qui gère une infra cloud
répartie sur 40 racks eux-mêmes répartis sur 3 datacenters en région
parisienne (2 Equinix et 1 Interxion). Ces datacenters sont interconnectés
par 3 fibres noires qui sont exploitées via des muxs passifs 40 canaux.
Nous rencontrons depuis quelques mois de sérieux problèmes de CRC sur une
quinzaine de chemins fibre qui transportent de l'IP ou du Fibre Channel.

Au vu de la complexité de l'infra (passage sur plusieurs FON vis des muxs,
en MMR, sur plusieurs datacenters) et des techniques à utiliser (réflectos,
tests BERT, etc.) nous avons besoin d'assistance pour diagnostiquer la
cause de ces CRC et de conseil pour la solution à appliquer. Si quelqu'un
parmi vous (ou vos connaissances) peuvent répondre à notre demande
n'hésitez pas à me contacter (jamrek[at]gmail.com) pour avoir plus détails.

Cordialement,

Fabien

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



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


Re: [FRnOG] [ALERT] Qui a cassé Google ?

2020-12-14 Par sujet Raphael Mazelier

Yes au moins la console GCP, Gsuite, etc..

On 14/12/2020 13:03, Stephane Bortzmeyer wrote:

YouTube qui affiche un joli message d'erreur et, apparemment, d'autres
services Google en carafe.


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



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


Re: [FRnOG] [TECH] Retour d'expériences AWS

2020-11-23 Par sujet Raphael Mazelier



On 23/11/2020 18:50, Wallace wrote:


En dehors de ce problème légal, attention à l'utilisation des 
fonctionnalités avancées des clouds, il vaut mieux déployer ses 
propres instances avec les services que l'on veut et que l'on maîtrise 
plutôt que de s'enfermer dans une solution AAS et ne plus pouvoir 
bouger à moins de redévelopper les connecteurs API et souvent les applis.


Avec une solution maitrisée en interne tu peux rapidement réinstaller 
dans un autre cloud avec une simple migration dns et des données. 
Quand tu utilises la base de donnée managé, le load balancer, le ... 
ben t'es bien coincé.



Plutôt pour Frsag mais c'est intéressant.

En effet c'est une des grosses questions qu'il faut se poser quand on va 
dans l'un des trois gros cloud publique. Quel degré d'adhérence tolérer 
pour mon déploiement ?


D'un coté tu voudrais avoir le moins d'adhérence possible, donc en 
faisait du pur IaaS. D'un autre coté utiliser un cloud sans ses services 
managés c'est perdre une grande partie de son intérêt. Ce que je 
préconiserais c'est d'utiliser les services managés avec parcimonie, et 
de surtout regarder leur compatibilité.


Par exemple : LB , pas de problème il s'agit de reverse proxy https 
classiques, RDS(aws) pour Mysql/Postgres, pas trop de problème puisque 
c'est standard et que tu peux re-migrer tes datas sur du Mysql/Maria à 
toi. Pareil avec ElastiCache qui est compatible Redis. S3 est un as plus 
intéressant, car utiliser un cloud publique sans utiliser son object 
storage c'est se passer d'une ressource plus qu'avantageuse. L'ennui 
c'est que S3 est devenu un standard de facto (voir Minio par exemple) 
mais pas disponible partout (notamment sur Azure). Résultat ma 
recommandation la dessus serait de l'utiliser mais avec une petite 
couche d'abstraction. Pour le reste des autres services types DynamoDB 
(pourtant bien pratiques) ou SNS/SQS j'essayerais de m'en passer, car 
c'est en effet trop se locker.


--

Raphael Mazelier




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


Re: [FRnOG] [TECH] Retour d'expériences AWS

2020-11-23 Par sujet Raphael Mazelier

Hello réponse inline de ce que j'en connais.

On 23/11/2020 15:38, Mickael Hubert wrote:

Interco L2 avec des clients c'est possible ? Si on a du L2 remontant de TH2
par exemple, il y a moyen de remonter ce L2 en cross-co chez AWS ou un
partenaire à eux (j'ai peur de votre réponse ...) ?

Nope. No way. Déjà chez en interne chez AWS il n'y a pas de L2 étendu 
entre AZ et encore moins entre région, alors avec l'extérieur.

Peut-on gérer ses accès VPN, ses plages d'IP (Ex: ne gérant pas l'overlap
IP, on a fait le choix de bosser avec la RFC 6598 pour éviter les conflits
avec les subnets de nos clients) peut-on attribuer n'importe quel subnet à
nos VM ?
Coté réseau et vpn oui tu peux/doit créer ton propre plan d'adressage 
avec toutes les IPs rfc1918 à disposition. Coté VPN tu peux même faire 
un peu de BGP pour échanger tes routes.


A-t-on le choix de son routeur (on bosse pas mal avec FRR), encore faut-il
pouvoir router soi-même ... ?


Auparavant ce n'était pas possible du tout, tu étais obligé d'utiliser 
les boites noires AWS, aws-gateway ou aws-nat-gateway. Depuis la 
situation a évolué pour permettre d'utiliser tes propres gateway sur une 
instance ec2 (principalement pour autoriser la vente d'appliance sur la 
market place je dirais). Une nouvelle feature vient même de sortir 
permettant de redonder/load balancé ces gw : 
https://aws.amazon.com/fr/elasticloadbalancing/gateway-load-balancer/


En revanche pose toi bien la question de pourquoi tu voudrais faire ça. 
Généralement la seule bonne raison valable serait de faire de 
l'inspection de trafic centrale ou de mettre un firewall centralisé (ce 
qui est à l'opposé du modèle de sécurité AWS)




Côté VoIP, j'imagine que ça "marche", car de mémoire twilio sont full AWS.
Mais côté NAT etc... ça marche comment ? Je crois savoir qu'on a jamais
d'IP publique au cul de sa VM, mais que c'est du NAT 1/1. Ça se passe bien ?

Tu peux tout à fait associer une IP publique à une instance. Deux mode 
soit tu laisses AWS choisir, le mode par défaut, mais dans ce cas il 
s'agit d'une IP aléatoire à chaque ré-initialisation de l'instance, soit 
tu attaches une Elastic IP à une instance qui ne changera jamais. Pas 
besoin de NAT in sur AWS généralement.



--

Raphael Mazelier



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


Re: [FRnOG] Re: [ALERT] FREE et/ou Internet saturé

2020-11-17 Par sujet Raphael Mazelier
Bien qu’intéressant je pense que la discussion aura plus de sens sur le 
forum de lafibre.info.


--

Raphael Mazelier

On 17/11/2020 11:13, Daniel via frnog wrote:


Exactement.

En tous cas je confirme le problème, je n'arrive pas plus à joindre la 
ligne FREE Rosace à partir d'une fibre FREE à Strasbourg.


À partir de chez Hetzner la dernière station vue par mtr est 
decix.proxad.net





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


Re: [FRnOG] [BIZ] Baie

2020-09-24 Par sujet Raphael Mazelier



On 24/09/2020 08:25, David Ponzone wrote:

Plutôt à Tokyo ou LA ?



J'ai un peu de place dans la baie dans mon garage :p




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


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

2020-09-03 Par sujet Raphael Mazelier



On 03/09/2020 16:54, Olivier Cochard-Labbé wrote:

En plus d'avoir une équipe dédiée à l'optimisation des codecs audio/vidéo,
tu en as une dédiée a améliorer les différents protocoles de congestion TCP
(BBR, RACK).
Il va être simple de faire évoluer la pile TCP de tes propres serveurs,
mais tu vas très vite être bloqué par le côté client:


Il faut déjà une certaine taille avant de pouvoir avoir ce genre d'équipe.

Youtube, Netflix et peut être quelques autre ont la taille suffisante et 
un intérêt à le faire. Après de ma connaissance sur le pseudo streaming 
l'effort se porte plutôt sur les codecs que sur le transport, ou du 
moins je ne pas le sentiment qu'on aille au delà d'optimiser tes 
serveurs CDNs (couverture et coût). Dans le cas de la svod on travaille 
sur des chunks plutôt très gros, et ou la latence n'est pas un gros 
soucis. Donc l'overhead de TCP me semble plutôt marginal. Cela pourrait 
être différent sur des use case de low-latency.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] split BX vers LX/LH

2020-08-06 Par sujet Raphael Mazelier

Si on reste dans cette logique (qui me parait bonne), une optique colorée ne 
l'est que du coté transmission, le coté réception ne change pas car c'est le 
demux qui se charge d'isoler le bon lambda. Le coté réception d'une optique 
colorée serait-il donc le même que celui d'une optique grise ?


De ma compréhension absolument.

Cdt,

--

Raphael Mazelier


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


Re: [FRnOG] [TECH] split BX vers LX/LH

2020-08-05 Par sujet Raphael Mazelier

De souvenir les optiques sont très très permise en réception.

Donc tu peux beaucoup bricoler et monter des liaisons avec des optiques 
différentes de chaque coté. Puissance ou longueur d'onde n'ont pas 
forcément besoin d’être aligné et cela peut dépanner quand tu n'as pas 
la bonne optique en stock.


--

Raphael Mazelier

On 05/08/2020 09:25, Duchet Rémy wrote:

J'avoue que le coup des optiques LX qui lisent le 1490 en provenance d'une BX 
alors qu'elles attendent du 1310, j'ai pas encore fait. Je me demande toujours 
si t'es pas en train de pratiquer la pêche au troll, d'ailleurs. Moi 
Saint-Thomas :P

Testé recement, (par erreur) 1535 (DWDM) =>  1310 . Le lien monte sans soucis. 
Après, j'ai pas fait de test de perf..

Rémy



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


Re: [FRnOG] [TECH] Choix de routeur en 2020

2020-07-01 Par sujet Raphael Mazelier




Question bête sur Nokia : au pif aiguisé, je ne demande pas de la science.
Considérant que je ne connais rien à Juniper (ce n'est pas vrai, mais pas grand 
chose); à part Cisco, si je devais apprendre un nouveau routeur de coeur, en 
2020, qu'est ce que tu ferais à ma place ? apprendre Juniper, ou apprendre 
Nokia ?


Franchement si tu as les bases du réseaux, une syntaxe est une syntaxe. 
C'est un peu comme apprendre un nouveau langage de programmation en plus 
simple.


--

Raphael Mazelier


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


Re: [FRnOG] [ALERT] Perte chez Orange / OTI

2020-06-22 Par sujet Raphael Mazelier



On 22/06/2020 12:24, Johann wrote:

Hello,

On a effectivement une grosse saturation entre Zayo et Orange, cela semble
être dû à un port down + l'arrêt des annonces de Orange sur HOPUS.


Ouch. Ça doit faire un poil trop de report de trafic :/

--

Raphael Mazelier


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


Re: [FRnOG] [TECH] NAT, Free et ports bas

2020-06-09 Par sujet Raphael Mazelier

Bonjour,

A partir de quand tu considères qu'un port est bas ? 1024 ?

Cdt,

On 09/06/2020 09:06, fabrice prigent wrote:

Bonjour à tous,

    Première question de ma part. Je suis responsable sys et réseau 
dans une université avec 2 étudiants. La période actuelle nous 
permet de découvrir des problèmes "plutôt rares", mais gênants, le 
dernier en date étant la transformation NAT A+P de Free (les exemples 
qui nous sont remontés sont systématiquement liés à Free pour l'instant).


    Notre Firewall est conçu pour bloquer toutes les communications 
"non standard", telles que des ports bas vers d'autres ports pas. Mais 
le NAT A+P de Free ne semble pas du tout prendre en compte ce 
principe, ce qui fait que nous bloquons un nombre "important" de 
requêtes légitimes.


    A la dernière analyse, ce comportement (connexion d'un port bas 
vers le port 80 par exemple) était à 96% du à des scanners de 
vulnérabilités (on ne va pas dire pirates.), mais les 4% restants sont 
des étudiants et personnels chez Free. (Je résume).


    Docteur(s), suis-je psycho-rigide ? Sommes-nous le seul cas ? 
Dois-je :


    - prier le dieu Free afin que dans sa clémence il corrige ce 
comportement


    - me dire "ranapéter, je continue de bloquer"

    - me dire "Ils sont trop grands, je suis trop petit, j'accepte"

    - multiplier par 4 la taille de mes règles iptables afin de 
désactiver les ports bas quand il s'agit de free et ainsi rendre 
honneur au plat préféré de mes femmes : les spaghettis


    - faire honneur à mon pays du rugby, avec un magnifique bottage en 
touche en disant aux utilisateurs "takademanderuneipfisc"


    - "42"

    Merci d'avance de vos réponses.




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



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


Re: [FRnOG] [TECH] Patchbox a encore frappé.....

2020-06-08 Par sujet Raphael Mazelier





Pour tous ceux qui ont besoin de racker seul du matos assez lourd,

On m’a envoyé ça, Patchbox a encore frappé!

https://patchbox.com/setup-exe <https://patchbox.com/setup-exe>

Ca mérite un award du génie!



Franchement c'est top. Tout ceux qui ont déjà bricolé en DC peuvent 
témoigner qu'on a tous fait des bricolages plus ou moins exotiques pour 
racker des éléments lourds ou pour avoir une tablette pour laptop.


--

Raphael Mazelier



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


Re: [FRnOG] [MISC] system de ticket pour support

2020-06-04 Par sujet Raphael Mazelier
Je ne sais pas. A titre personnel j'ai plutôt un souvenir positif de RT. 
En revanche j'ai fait des cauchemar avec OTRS.



On 04/06/2020 18:08, David Ponzone wrote:

Mais qu’a donc la Terre entière contre Request-Tracker….


Le 4 juin 2020 à 17:59, Jean-Yves LENHOF  a écrit :

Quelques outils OpenSource :

OTRS

Itop

GLPI

Après plus orienté Dev Web :

Mantis

Redmine

Bugzilla



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



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


Re: [FRnOG] [ALERT] Coupures câbles dans le sud de Paris

2020-05-05 Par sujet Raphael Mazelier



On 05/05/2020 16:09, François Lacombe wrote:



Hypothèse très partiellement fondée : l'utilisateur habituel de la 
gaine verte a aussi été impacté

https://www.zdnet.fr/actualites/une-coupure-de-reseau-orange-detectee-dans-le-sud-est-de-paris-39903247.htm

Beaucoup d’opérateurs ont pris la foudre ce matin...


Je n'ai pas dit qu'il s'agissait d'un acte ciblé contre un opérateur. 
J'espère réellement que la justice fera son œuvre et tirera cette sombre 
histoire au clair.


--

Raphael Mazelier


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


Re: [FRnOG] [ALERT] Coupures câbles dans le sud de Paris

2020-05-05 Par sujet Raphael Mazelier



On 05/05/2020 15:47, Raphaël Jacquot wrote:

bizarre, tous ces cables gainés de vert qui s'en tirent "miraculeusement"...

#JDCJDR


Effectivement il s'agit très clairement d'un acte de malveillance ciblé.

--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Stack de logs / netflow

2020-04-28 Par sujet Raphael Mazelier



On 28/04/2020 13:21, Remi Desgrange wrote:

Il est vrais que les outils de la stack ELK bouffe beaucoup (trop) de 
ressources. Mais quand tu a beaucoup de données, La JVM tu t'y retrouve. C'est 
pas pour rien que les stacks big data tourne sur la JVM (le log de 700 
équipements c'est pas du big data, on est d'accord).

Étant dans le milieu de la bigdata depuis peu, je ne suis pas sur que la 
raison profonde du choix de la JVM soit la performance. Je crois que 
c'est plutôt affaire écosystème (la plupart des frameworks sont ecris en 
Java/Scala), et que c'est avant tout car ces langages ont une certaine 
expressivité qui manquent à des langages plus bas niveau, et donc qu'il 
serait extrêmement pénible de manipuler des structures de données 
complexes dans des lesdits langages.


(Il y aussi énormément de python mais la on ne parle même plus de 
performances.)


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Stack de logs / netflow

2020-04-28 Par sujet Raphael Mazelier



On 28/04/2020 12:47, Xavier Beaudouin wrote:

Okay rrdtool ne permet pas d'avoir des stats journalières précises a plus d'un
mois mais donnent largement ce qu'il faut pour avoir des métriques d'utilisation
d'une plateforme.


Il y a un truc qui est vrai dans ce que tu dis c'est que toutes les 
solutions actuelles à base d'elastisearch, ou tsdb c'est la difficulté à 
gérer de l'historique long et le downsampling.


(parfois il m'arrive de regretter rrd pour ce point précis pas pour le 
reste).



Alors pourquoi utiliser un machin en java qui est un OS sur un autre OS alors
qu'on pourrais utiliser des API normales d'un OS (oui la libc... / libthread).

Pour faire un parallèle : nginx vs apache voila ce que j'en pense (hormis
les problèmes de licences et de FUD liées au modele de dev).


Pour le coup je ne comprends pas trop l'analogie. Nginx est plus simple 
et plus performant qu'Apache. Je vois Nginx comme un gros framework 
orienté web et perf (mais c'est peut être parce que j'ai codé des 
modules nginx).


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Stack de logs / netflow

2020-04-28 Par sujet Raphael Mazelier

Bonsoir,

Tu parles de deux choses complètement différentes : la centralisation de 
logs d'équipements et la collection de flow réseaux.


Pour les logs la plupart des équipements ne savent encore que parler 
syslog, mais ce n'est pas le problème. Ensuite tu dois choisir une 
solution pour ingérer, découper, classer, stocker  et exploiter ces logs.


Coté stockage en open source Elasticsearch est omniprésent pour le 
stockage des logs (ce qui peut faire sens, vu qu'il s'agit souvent de 
stocker des documents textes indexés et de faire des recherches). Ce 
n'est clairement pas le plus performant mais c'est un standard connu. 
Ensuite vient le choix de l'ingestion et de l'interface de visualisation.


La stack E(L|F)K est la plus présente, mais à titre personnel ce n'est 
pas ma préféré (n'étant pas un grand fan de Kibana, ni de logstash, ni 
de Fluent). Pour un usage modéré j'ai plutôt de bon souvenir de graylog. 
A noter qu'il existe des alternatives plus jeune mais prometteuses (voir 
Loki de la cncf). Ensuite Splunk très bien, mais cher.


Pour les flows je dirais que c'est encore plus ouvert. J'ai 
personnellement mis en place beaucoup de solutions autour de pmacct > 
message broker > agrégateur > tsdb (ou base rapide) homemade. C'est un 
peu de travail à mettre en place néanmoins.


Il existe beaucoup de solutions commerciales peu chère qui font le boulot.

--
Raphael Mazelier

On 28/04/2020 11:38, Christian d'Autume wrote:

Bonjour la liste,


On lance des réflexions chez nous pour refondre notre stack de 
centralisation de logs (type syslog, voir netflow); et regardons un 
peu ce qui se fait principalement en opensource.



Vous auriez des retours d'expériences sur des appliances types elk / 
splunk, pour un parc hétérogène (~700 équipements: nxos, ftd, ios, 
asa, juniper ...) ?



En vous remerciant d'avance pour vos retours.


Christian



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



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


Re: [FRnOG] [BIZ] Devis Observium

2020-04-08 Par sujet Raphael Mazelier



On 08/04/2020 09:25, David Ramahefason wrote:

Euh je pense que Cécile connaît ce genre de structure et sait comment ça
marche ...
Bizarre de penser autrement...

Dans un ex travail dans une grosse structure nous avions l'habitude pour 
ce genre de demande de passer par une société écran. Cette société nous 
fournissait un devis acceptable par nos différents strates de contrôle, 
et effectuait l'achat pour nous.


Évidement cette société prenait une petite marge mais bon quel confort. 
On pu faire passer des choses impossible de ce style (petite licence, 
matos en vrac, même achat au grey market)



--

Raphael Mazelier


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


Re: [FRnOG] [TECH] accès à https://myaccount.google.com

2020-04-06 Par sujet Raphael Mazelier
Non mais je sais :^p mais des filtres en 172/8 j'en ai vu un paquet dans 
ma carrière.


Cdt,

On 06/04/2020 17:29, Yoann Moulin wrote:

Le 06/04/2020 à 17:27, Raphael Mazelier a écrit :

172. Il n'y a que moi que cela fait tilter ? :)

NetRange:   172.217.0.0 - 172.217.255.255
CIDR:   172.217.0.0/16
NetName:GOOGLE
NetHandle:  NET-172-217-0-0-1
Parent: NET172 (NET-172-0-0-0-0)
NetType:Direct Allocation
OriginAS:   AS15169
Organization:   Google LLC (GOGL)
RegDate:2012-04-16
Updated:2012-04-16
Ref:https://rdap.arin.net/registry/ip/172.217.0.0

NetRange:   172.16.0.0 - 172.31.255.255
CIDR:   172.16.0.0/12
NetName:PRIVATE-ADDRESS-BBLK-RFC1918-IANA-RESERVED
NetHandle:  NET-172-16-0-0-1
Parent: NET172 (NET-172-0-0-0-0)
NetType:IANA Special Use

;)


On 06/04/2020 17:20, Clément Guivy wrote:

bonjour,

Des users nous remontent des problèmes pour accéder à 
https://myaccount.google.com/ (l'authentification de google pour ses différents
services) depuis un site en particulier (qui a son propre accès internet). 
Concrètement dans ce cas c'est un timeout, on ne reçoit aucun
paquet en réponse de la part de google.

Mes constatations :

Depuis le site pour lequel cela ne fonctionne pas, myaccount.google.com résoud 
sur 172.217.19.238
Depuis le site pour lequel cela fonctionne, myaccount.google.com résoud sur 
216.58.206.238

Depuis le site qui ne fonctionne pas, le ping vers 172.217.19.238 ne répond 
pas, le ping vers 216.58.206.238 répond
Depuis le site qui fonctionne, le ping vers les deux IP répond

Depuis le site qui ne fonctionne pas, le traceroute vers 172.217.19.238 arrive 
jusque chez google, dernier saut 216.239.59.209 (IP google),
puis pas de réponse au delà
Depuis le site qui fonctionne, le traceroute vers 172.217.19.238 arrive à 
destination

Si je modifie les résolveurs des PC du site qui ne fonctionne pas pour utiliser 
les mêmes que ceux du site qui fonctionne, tout fonctionne bien.

Donc en conclusion, depuis le site qui ne fonctionne pas, la résolution DNS de 
myaccount.google.com nous répond une IP qui n'est pas joignable
depuis ce site. Un traceroute vers cette IP montre que 1) elle est joignable 
depuis d'autres endroits, donc elle n'est pas entièrement HS, et
2) quand on tente de la joindre on arrive jusque chez google, donc on ne peut 
pas incriminer notre FAI sur cette base.

Des idées ?

Autre curiosité pas forcément liée au problème, je remarque qu'on reçoit de nos 
transitaires des annonces en provenance de l'AS google plus
spécifiques que ce que google annonce sur France IX. Exemple Google annonce 
216.58.192.0/19 via France IX, mais par transitaire on reçoit
216.58.196.0/23, 216.58.198.0/24, 216.58.199.0/24 etc. Ca vous semble normal ?


---
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] accès à https://myaccount.google.com

2020-04-06 Par sujet Raphael Mazelier

172. Il n'y a que moi que cela fait tilter ? :)


On 06/04/2020 17:20, Clément Guivy wrote:

bonjour,

Des users nous remontent des problèmes pour accéder à 
https://myaccount.google.com/ (l'authentification de google pour ses 
différents services) depuis un site en particulier (qui a son propre 
accès internet). Concrètement dans ce cas c'est un timeout, on ne 
reçoit aucun paquet en réponse de la part de google.


Mes constatations :

Depuis le site pour lequel cela ne fonctionne pas, 
myaccount.google.com résoud sur 172.217.19.238
Depuis le site pour lequel cela fonctionne, myaccount.google.com 
résoud sur 216.58.206.238


Depuis le site qui ne fonctionne pas, le ping vers 172.217.19.238 ne 
répond pas, le ping vers 216.58.206.238 répond

Depuis le site qui fonctionne, le ping vers les deux IP répond

Depuis le site qui ne fonctionne pas, le traceroute vers 
172.217.19.238 arrive jusque chez google, dernier saut 216.239.59.209 
(IP google), puis pas de réponse au delà
Depuis le site qui fonctionne, le traceroute vers 172.217.19.238 
arrive à destination


Si je modifie les résolveurs des PC du site qui ne fonctionne pas pour 
utiliser les mêmes que ceux du site qui fonctionne, tout fonctionne bien.


Donc en conclusion, depuis le site qui ne fonctionne pas, la 
résolution DNS de myaccount.google.com nous répond une IP qui n'est 
pas joignable depuis ce site. Un traceroute vers cette IP montre que 
1) elle est joignable depuis d'autres endroits, donc elle n'est pas 
entièrement HS, et 2) quand on tente de la joindre on arrive jusque 
chez google, donc on ne peut pas incriminer notre FAI sur cette base.


Des idées ?

Autre curiosité pas forcément liée au problème, je remarque qu'on 
reçoit de nos transitaires des annonces en provenance de l'AS google 
plus spécifiques que ce que google annonce sur France IX. Exemple 
Google annonce 216.58.192.0/19 via France IX, mais par transitaire on 
reçoit 216.58.196.0/23, 216.58.198.0/24, 216.58.199.0/24 etc. Ca vous 
semble normal ?



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



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


Re: [FRnOG] [TECH] Filtrage DNS chez SFR

2020-03-20 Par sujet Raphael Mazelier



On 20/03/2020 20:53, Baptiste Chappe wrote:

Bonsoir,

J'ai eu la même ce jour avec un client sur une Freebox. Je monte le VPN
avec un split. Seul le trafic vers le range precis passe dans le tunnel.
Impossible de ping la ressource en DNS.
Je change le DNS par Google et paf ca marche.

Je suis un dingue en publiant dans le DNS des clients une IP privée ? J'ai
rarement la chance d'avoir un DNS en local sur les sites (TPME 5 à 30
personnes).
  Ex : imprimante.toto.com = 192.168.1.2

Merci



Messieurs merci de ne pas tous mélanger.

Les résolveurs de Free sont connus pour filtrer les rfc1918.

Les résolveurs de SFR/ex-NC semblent ok (et effectivement ne répondent 
que depuis le réseau SFR/ex-NC).


A priori mais c'est à confirmer cela n'impacte qu'un certain type de box 
SFR (l'ingénierie SFR est sur le coup, merci à eux).


PS : non ce n'est pas complètement fou comme pratique mais tu t'exposes 
à ce genre de problèmes.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Filtrage DNS chez SFR

2020-03-20 Par sujet Raphael Mazelier



On 20/03/2020 19:43, Alarig Le Lay wrote:

dig -t A roucool.int.no.swordarmor.fr @89.2.0.1


Non cela semble venir de la box. On debug en off et on vous donnera les 
conclusions quand on aura trouvé.


Cdt,

--

Raphael Mazelier


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


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

2020-03-20 Par sujet Raphael Mazelier



On 20/03/2020 17:59, Ducassou Laurent wrote:
Le vrai problème de fond de cette "non information" est que Netflix 
prends cher comme youtube à une époque... La seule différence c'est 
qu'ils ne peuvent pas se planquer derrière le "petit bout de doigt" du 
"c'est gratuit donc râlez pas trop !" car ils n'ont pas fait des tuyau 
assez gros avec les principaux FAI des principaux pays... (car oui, 
les serveurs de cache qui sont là pour absorber chez les FAI, là ils 
sont out game car vu que les gens ont "que ça a faire" ils vont au 
très fond du catalogue que personne regarde d'habitude !)



Le hit ratio a du baisser sur les OCAs (je n'ai pas les stats mais ça 
semble logique).


Ceci dit je pense que le facteur limitant se situe vraiment coté FAIs 
sur le backbone interne.


Donc finalement ce n'est pas une si mauvaise décision, après les ISP 
auraient été forcés de prendre ce genre de mesure eux même mais c'était 
techniquement plus délicat.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Filtrage DNS chez SFR

2020-03-20 Par sujet Raphael Mazelier



On 20/03/2020 12:44, Paul Rolland (ポール・ロラン) wrote:

d'une manière ou d'une autre

les requêtes DNS (ALG dns ?).

Questions cons :
  - est-ce que 192.168.0.x correspond au "lan local" de ta box ?
  - si oui, est-ce que tu as le meme comportement avec des adresses RFC1918
qui ne font pas partie de l'adressage de ce LAN local ?


Non tu as le même comportement avec 10/8, 172/12 et 192.168/16.

Testé et désapprouvé.

--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Filtrage DNS chez SFR

2020-03-20 Par sujet Raphael Mazelier

Bonjour David, enchanté.

Je serais ravi d'échanger avec vous pour déboguer ce sujet.

Les dns reçu en dhcp sont 89.2.0.1 et 89.2.0.2. Je ne sais pas si le 
filtrage se situe au niveau de ces serveurs.


J'en doute même cf l'exemple :

Derrière box SFR :

dig rfc1918.futomaki.net +short > timeout

dig @9.9.9.9 rfc1918.futomaki.net +short> timeout

Depuis ailleurs (disons une vm dans le cloud) :

dig @9.9.9.9 rfc1918.futomaki.net +short > 192.168.0.43

Donc my guess c'est que la box intercepte d'une manière ou d'une autre 
les requêtes DNS (ALG dns ?).


Cdt,


--

Raphael Mazelier


On 20/03/2020 11:01, GAVARRET, David wrote:

Bonjour Raphael,

pourriez-vous préciser les IP des resolvers SFR en question ?
Je suis directement en charge de ces plateformes, et je peux vous assurer qu'on 
ne fait aucune bidouille dans le filtrage des réponses en dehors de nos 
obligations règlementaires.

D'autre part, il n'y a aucun filtrage de trafic à destination de resolveurs 
tiers. Je vois mal comment nous pourrions en interdire l'usage ne serait-ce 
qu'à nos clients B2B/Transit IP.

A disposition pour investiguer sur ce sujet.

Cordialement,
--
David Gavarret



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


[FRnOG] [TECH] Filtrage DNS chez SFR

2020-03-20 Par sujet Raphael Mazelier

Hello, c'est vendredi alors je me permets.

Depuis cette semaine nous sommes tous en wfh et nous avons noté un 
comportement assez laid de la part de SFR.


Comme beaucoup nous avons des zones dns publiques qui pointent sur des 
enregistrements rfc1918. Les résolveurs SFR filtrent ces réponses, soit.


En revanche ce qui est inédit c'est que lorsqu'on set le resolveur de 
cloudflare, ou google, voir faire un dig @1.1.1.1 iprfc1918.pipo.net, 
cela timeout.


C'est donc filtré à un endroit et ça c'est très laid, car cela veut sans 
doute dire qu'avec SFR on ne peut pas simplement changer de serveur dns, 
ou du moins être sur que c'est le serveur pointé qui te réponds.


Ceci dit un dig @9.9.9.9 isitblocked.org renvoie bien un nxdomain, donc 
cela ne semble filtrait que les rfc1918.


Qu'est ce que cela vous inspire ? C'est vendredi matin j'ai peut être 
raté quelque chose.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

2020-03-18 Par sujet Raphael Mazelier




Si tu savais… :D

Je bloque sur un point sur l'idée de relais RTP : que se passe-t-il quand le 
RTP learning foire ? Fin des appels ?
Parce que là, je viens de tester entre du Linphone winwin et Linux. Ça ne 
fonctionnait pas avant (donc le VPN OpenVPN apporte quelque chose) et, surtout, 
je constate que le RTP learning n'arrive pas au stade
« Complete » et que les softphones échangent en P2P. Que va-t-il se passer pour 
eux si je force un relais RTP ? Moi je comprends qu'ils ne pourront plus se 
téléphoner… Pas cool.



Le rtp learning c'est une invention d'asterisk j'imagine qui doit être 
une fonctionnalité qui essaie de découvrir la topologie réseau et donc 
setter les adresses ip dans le rtp.


C'est aussi pour cela que je n'aime pas trop asterisk, ca fait beaucoup 
de magie et a la fin on ne comprends pas vraiment ce que l'on fait.


Une bonne manière de bien comprendre c'est de démarrer avec un 
opensips/kamailio et du rtpproxy/mediaproxy.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

2020-03-18 Par sujet Raphael Mazelier



On 18/03/2020 14:34, David Ponzone wrote:

Je connais pas ton archi, mais si derrière t’as une Patton/Audiocodes/Bero qui 
peut joindre les endpoint, alors oui, tu peux faire du direct.
Sinon tu es obligé d’utiliser l’* comme B2BUA/SBC.


Oui mais la encore c'est casse gueule. Ce n'est pas pour rien qu'on a 
inventé les rtp-proxy.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

2020-03-18 Par sujet Raphael Mazelier



On 18/03/2020 13:47, Guillaume LUCAS wrote:


Côté Asterisk, donc.
J'suis pas encore chaud pour qu'Asterisk soit relais RTP de tout le monde… D'un 
autre côté… avec le RTP autolearn, il l'est implicitement depuis longtemps, si 
je comprends bien ?


Pourquoi ? sans transcoding c'est juste la copie de paquet, ça coûte que 
dalle en cpu. Pareil en réseau. Et ça va résoudre 90% de tes problèmes.


Mon conseil tu fais tout passer par ton asterisk SIG+RTP, et tu trouve 
la conf qui va bien pour laisser les ports RTP ouverts. (parce que sinon 
effectivement tu vas tomber dans les problèmes de comm semi blanche à 
30s, enfin le temps du timeout d'un port nat udp sur le fw local). Sinon 
si tu peux centraliser la conf de tes linphones ca serait aussi pour toi 
le meilleur, avec pareil l'option qui va bien.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Télétravail = VPN = fête du SIP (ou y'a-t-il vraiment autant de bugs que ça dans les implémentations SIP ?!)

2020-03-17 Par sujet Raphael Mazelier
Cela me ramène quelque année en arrière. Et cela me rappelle aussi 
pourquoi on posait des box chez les clients.  (coucou les ex-B3G, 
Ipnotic, Paritel)


Faire de la Voip si tu ne maîtrise pas le lan client c'est possible mais 
source d'emmerdements infinis.


Comme déjà mentionné il faut absolument que ton RTP soit in path de ton 
asterisk (rtp proxy , whatever).


Au final je me demande si tu ne t’embête pas plus avec un vpn que sans. 
(alors surtout un ASA qui si tu n'y prend pas garde va joyeusement faire 
n'importe quoi avec tes paquets SIP, a se demander d'ailleurs pourquoi 
on a crée des ALGs SIP pour qu'au final la 1ere chose à faire c'est de 
les désactiver).


En public ICE/STUN/TURN peuvent définitivement aider. Après si pour X 
raison tu es obligé d'utiliser un VPN, bin bon courage. Wireshark va 
être ton ami proche des prochains jours.


Good luck.

--

Raphael Mazelier

On 17/03/2020 18:43, Guillaume LUCAS wrote:

- Mail original -
De: "frnog" 
Réussis tu à pinguer l'IP en 192.168.x.y à partir du PABX ?

Non. Et surtout, je ne veux pas ping les réseaux domestiques de mes usagers. Ce 
n'est pas mon rôle d'utiliser notre VPN pour accéder à leur réseau local.


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



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


Re: [FRnOG] [TECH] HAProxy multi DC

2020-03-07 Par sujet Raphael Mazelier





Tout dépend du point de vu :)  A une époque pas si lointaine quand le
devops n'existait que dans nos cauchemars (pardon rêves ;)) les plus fous,
c'est l'infrastructure seule qui portait cette responsabilité. Ce paradigme
a quelque peu évolué depuis et on retrouve cette notion des deux côtés de
la barrière.

D'ailleurs c'est aussi l'intérêt de cette approche dev/ops car au final si
on veut quelque chose d'efficient il vaut mieux se coordonner ;)

Perso je doute que tout se passe d'un côté ou de l'autre.

Tu as raisons il n'y a pas de coté. On devrait être tous est focus sur 
ce qui importe aka délivrer un service à un client.


Au début tout était plus simple car maîtrisable par les même personnes. 
Je ne sais pas quand exactement on a commencé à trop spécialiser les 
informaticiens et à ne plus se parler.


Il y a effectivement une période ou on pouvait entendre régulièrement : 
la redondance ce n'est pas mon soucis en tant que développeur, l'infra 
doit me fournir un runtime résilient, pareil pour le réseau. De manière 
ironique le cloud a participé à cette rectification, avec les fameux 
application "cloud ready", et/ou remettre au centre le fait que l'infra 
n'est pas infaillible et que le meilleur endroit pour savoir ce qu'il se 
passe c'est encore dans l'application.


Le mouvement "devops" est finalement une normalisation de ce qui aurait 
du toujours être.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] HAProxy multi DC

2020-03-06 Par sujet Raphael Mazelier

On 05/03/2020 21:54, Philippe Bourcier wrote:


Ca n'aurait pratiquement aucun intérêt... puisque c'est déjà ce que ferait un 
OS/browser.

Je ferais plutôt :
1. le client JS fait sa requête DoH
2. il voit N CNAMEs : srv[1,2,3...].frnog.org
3. il lance 2 threads de connexion (get d'une page de status) vers 2 des N 
serveurs
4. il choisit celui qui répond "tout va bien" (ce qui permet de désactiver un 
node (ie: lors d'une mise en prod)) et qui a la meilleure latence... Le tout est contenu 
avec un timeout de 150ms... si aucun des 2 n'est OK, on passe au(x) node(s) suivant(s)...
5. il lance la/les requêtes API vers cet élu... si failure, re-bascule sur un 
des autres (avec un sleep++ plus on retry, passé les N serveurs du pool)...

Oui c'est ce que je pensais.


3. _caches DNS_ : on en revient au cas DNS classique et au problème du
TTL mini effectif de 20 minutes. En DoH on a le contrôle sur le
serveur qu'on interroge et on peut remonter directement à l'origine
(SOA) et court-circuiter les caches (ce qui revient à ignorer le TTL)


On ignore pas le TTL on aura le vrai TTL. On pallie des comportements de 
certains ISP peu scrupuleux. Btw DoH sera bientôt utilisé par défaut 
dans pas mal de browser ce qui nous facilitera la tache. Je pense même 
que les gros vont finir pas imposer des serveurs DoH par défaut 
overridant ceux du système.



4. _latence DNS_ : à benchmarker (DoH en JS à l'origine vs. DNS
classique via des resolvers qui cachent)


Oui c'est un des gros points à vérifier. La latence initiale risque de 
ne pas être fameuse.


A voir si c'est acceptable. Pour une grosse SPA je pense que ça passe.


Faudrait clairement faire un PoC...


I'm in.

--

Raphael Mazelier



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


Re: [FRnOG] [TECH] HAProxy multi DC

2020-03-05 Par sujet Raphael Mazelier
Yes le fameux compute@edge. Très pratique mais pas très donné pour le 
moment.


--

Raphael Mazelier

On 05/03/2020 12:43, Théophile Helleboid wrote:

Avec les "Workers" qu'on peut exécuter directement chez le CDN, on
peut faire un mix.

Par exemple :
- Un worker qui vérifie chaque upstream…
- et qui génère un fichier de configuration avec au moins un upstream
qui fonctionne : { api_host: "https://api1.example.com; }.
L'application Javascript télécharge ce fichier de configuration et
utilise ce hostname pour toutes les requêtes d'API
- ou juste une page minimale qui permet de charger le javascript
depuis le bon upstream : 

Ça permet de mettre un peu de logique dans le "worker" (optimisation
géographique, vérifications précises de l'état de l'upstream), sans
tomber dans l’extrême et l'utilisation d'IP.



On Thu, Mar 5, 2020 at 2:01 PM Raphael Mazelier  wrote:

Je crois que l'on a mélangé un peu plusieurs discussions mais au final
on en revient toujours au même débat : ou placer la redondance ? coté
infra ou coté applicatif ?

La redondance infrastructure est d'une certaine manière plus facile à
réaliser mais moins efficace ou plus dure à mettre au point.

La redondance coté client est sans doute très intéressante si l'on
accepte de passer du temps coté client. C'est vrai pour qu'une page web,
on peut sans doute trouver des solutions intéressantes avec les
possibilités de bricoler en js actuelle.

Une squelette statique délivré via un CDN (avec un peu de cache), du js
qui fait des checks sur les différents serveurs de ressources,
construction de la page après. Ça doit se faire.

Même pas besoin de DoH en fait. D'ailleurs DoH coté client js, why not,
mais après il faudrait pouvoir faire comprendre au browser qu'il doit
utiliser ce qui vient d’être résolu pour le reste, ce qui est peut être
possible mais je ne sais pas comment faire.

Ca serait intéressant de faire un POC la dessus.

--

Raphael Mazelier

On 05/03/2020 00:50, Jonathan Leroy - Inikup via frnog wrote:


Le mer. 4 mars 2020 à 23:04, Philippe Bourcier  a écrit :

Utiliser des cookies, en 2020 ? ... :)
Web Storage, JWT, sessionless... ?

Web Storage n'est pas fait pour stocker des infos de session
(n'importe quel script tiers sur la page peut accéder à son contenu).
JWT est une horreur à éviter à tout prix
(https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid).
Dans les faits le sessionless quasiment impossible pour une app web
sans utiliser JWT.

Donc oui, les cookies sont nécessaires en 2020. :)

Pour répondre à la question initiale :
   - Vraie solution propre : si tu as besoin d'un failover sur un DC
secondaire, c'est que ton business est critique et que toute coupure
te coûte une somme non négligeable. Donc il te faut demander un /24
(ainsi qu'un /48, car nous sommes en 2020) à un LIR et l'annoncer en
BGP. Ton hébergeur n'est pas capable de faire ça ? Qu'il change de
métier (ou à défaut, tu peux changer d'hébergeur).

   - Solution pas trop sale alternative : Cloudflare propose un LB dans
le cloud qui fait ça très bien et pour pas cher. Ça check les serveurs
de ton pool toutes les 15 seconds et il y a même une API.



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






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


Re: [FRnOG] [TECH] HAProxy multi DC

2020-03-05 Par sujet Raphael Mazelier
Je crois que l'on a mélangé un peu plusieurs discussions mais au final 
on en revient toujours au même débat : ou placer la redondance ? coté 
infra ou coté applicatif ?


La redondance infrastructure est d'une certaine manière plus facile à 
réaliser mais moins efficace ou plus dure à mettre au point.


La redondance coté client est sans doute très intéressante si l'on 
accepte de passer du temps coté client. C'est vrai pour qu'une page web, 
on peut sans doute trouver des solutions intéressantes avec les 
possibilités de bricoler en js actuelle.


Une squelette statique délivré via un CDN (avec un peu de cache), du js 
qui fait des checks sur les différents serveurs de ressources, 
construction de la page après. Ça doit se faire.


Même pas besoin de DoH en fait. D'ailleurs DoH coté client js, why not, 
mais après il faudrait pouvoir faire comprendre au browser qu'il doit 
utiliser ce qui vient d’être résolu pour le reste, ce qui est peut être 
possible mais je ne sais pas comment faire.


Ca serait intéressant de faire un POC la dessus.

--

Raphael Mazelier

On 05/03/2020 00:50, Jonathan Leroy - Inikup via frnog wrote:


Le mer. 4 mars 2020 à 23:04, Philippe Bourcier  a écrit :

Utiliser des cookies, en 2020 ? ... :)
Web Storage, JWT, sessionless... ?

Web Storage n'est pas fait pour stocker des infos de session
(n'importe quel script tiers sur la page peut accéder à son contenu).
JWT est une horreur à éviter à tout prix
(https://paragonie.com/blog/2017/03/jwt-json-web-tokens-is-bad-standard-that-everyone-should-avoid).
Dans les faits le sessionless quasiment impossible pour une app web
sans utiliser JWT.

Donc oui, les cookies sont nécessaires en 2020. :)

Pour répondre à la question initiale :
  - Vraie solution propre : si tu as besoin d'un failover sur un DC
secondaire, c'est que ton business est critique et que toute coupure
te coûte une somme non négligeable. Donc il te faut demander un /24
(ainsi qu'un /48, car nous sommes en 2020) à un LIR et l'annoncer en
BGP. Ton hébergeur n'est pas capable de faire ça ? Qu'il change de
métier (ou à défaut, tu peux changer d'hébergeur).

  - Solution pas trop sale alternative : Cloudflare propose un LB dans
le cloud qui fait ça très bien et pour pas cher. Ça check les serveurs
de ton pool toutes les 15 seconds et il y a même une API.




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


Re: [FRnOG] [TECH] HAProxy multi DC

2020-03-05 Par sujet Raphael Mazelier
Oui si on accepte d'utiliser un service tiers, un dns global type 
route53 est simple (peu cher) et efficace pour ce genre de redondance.


On 05/03/2020 10:41, Thomas Quinot wrote:

* Renaud RAKOTOMALALA, 2020-03-03 :


- t'appuyer sur un service tier pour le DNS qui en conscience adaptera
la réponse sur le ou les IP publiques de tes HAProxy

Ça peut être une solution assez simple à mettre en œuvre avec AWS
Route53, qui permet d'associer les RR retournés à des "health checks"
(et/ou à d'autres critères tels que des estimations de latence, si on
veut favoriser un serveur "proche", au-delà du simple partage de charge).

Thomas.


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



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


Re: [FRnOG] [TECH] HAProxy multi DC

2020-03-03 Par sujet Raphael Mazelier
Résultat gslb avec gdnsd me semble une bonne solution. Les ttls court 
c'est moche mais tout le monde le fait alors bon.


--

Raphael Mazelier

On 03/03/2020 13:15, Mickael Hubert wrote:

Un grand merci à tous pour vos retours !
BGP pas possible coté hébergeur, ses IP arrivent de façon indépendantes sur
ses 2 DC, pas possible d'annoncer le subnet du DC A sur le DC B en cas de
perte du DC A.
J'ai bien un L2 entre les 2 DC, mais il ne me servirait que pour le côté
privé. Et d'ailleurs ça casserait mon design L3 (car j'ai remonté un L3 au
dessus du L2 fourni par l'hébergeur)
En gros c'est DNS, à faire soi-même ou à déléguer, mais pas le choix
d'avoir un TTL très court ...

Si vous avez d'autres idées, faites vous plaisir ;)

++


Le mar. 3 mars 2020 à 13:06, Michel 'ic' Luczak  a
écrit :


Hello,


On 3 Mar 2020, at 11:15, Mickael Hubert  wrote:

Bonjour à tous,
nous devons réaliser du HA (et si possible du loadbalancing) entre 2
instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC

différents.

Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP
publique de l'un à l'autre des DC.

La solution la plus simple serait de réaliser du round robin DNS pour
pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer

tête

baissée dans le truc, je souhaitais savoir si vous auriez d'autre

solutions

à me proposer ?

Je fais ça pour faire du “cdn lite” pour des clients avec du varnish sur 2
serveurs dédiés. Chacun porte aussi un gdnsd avec un healthcheck des deux
serveurs. Les deux sont configurés comme NS du sous domaine “static.”. En
situation normale, les deux renvoient l’IP des deux, si un des deux tombe
(niveau varnish) pour une raison ou une autre, une seule IP est renvoyée.
Si une des deux machines tombe complètement, un seul DNS fonctionne (c’est
suffisant) et ne renvoie que l’IP de la survivante.

++ ic



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



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


Re: [FRnOG] [TECH] HAProxy multi DC

2020-03-03 Par sujet Raphael Mazelier
Yep globalement deux options : GSLB (du pauvre ou pas, mais j'aime bien 
l'approche) ou anycast BGP.


--

Raphael Mazelier

On 03/03/2020 11:37, Thomas Pedoussaut wrote:

Tu as la version DNSLB du pauvre, j'en ai fait depuis 2007.

Ca utilise le fait que naturellement, la chaine de resolution DNS va 
chercher à trouver un NS up pour une zone.


Soit ton site www.example.com

Soit ta Machine A comme ip 1.2.3.4

Soit ta Machine B comme ip 5.6.7.8

Tu cree une sous zone lb.example.com

Voici un extrait de ton fichier de zone:

machineA IN A 1.2.3.4

machineB IN A 5.6.7.8

lb IN NS machineA

lb IN NS machineB

www IN CNAME www.lb.example.com.


Et sur chacun des serveur tu fais aussi tourner un bind, chacun 
faisant autorité pour lb.example.com


Et qui contient

www 60 IN A 1.2.3.4  (sur la machineA)

ou

www 60 IN A 5.6.7.8 (sur la machine B)

(pas de master/slave pour cette zone)


Si les 2 serveurs fonctionnent, tu auras grosso modo du round robin.

Si un serveur est down, immédiatement les client qui n'ont pas l'IP en 
cache seront tous sur l'instance encore UP.


Au bout de 60 sec, les cache auront expiré et pareil tout le traffic 
arrivera sur la machine UP



Il te reste a faire un mecanisme sur chaque serveur pour eteindre bind 
si ton haproxy (ou tous ses backend) est down pour ne plus servir la 
mauvaise IP.



On 03/03/2020 11:15, Mickael Hubert wrote:

Bonjour à tous,
nous devons réaliser du HA (et si possible du loadbalancing) entre 2
instances HAProxy, ces 2 Haproxy doivent-être hébergés dans 2 DC 
différents.

Pas possible de réaliser du VRRP car nous ne pouvons pas switcher l'IP
publique de l'un à l'autre des DC.

La solution la plus simple serait de réaliser du round robin DNS pour
pointer sur les 2 IP publiques des 2 HAproxy. Mais avant de se lancer 
tête
baissée dans le truc, je souhaitais savoir si vous auriez d'autre 
solutions

à me proposer ?
Car à ma connaissance, si un des HAProxy est HS, le DNS n'en saura 
rien et

continuera à balancer du trafic dessus (avec 50% d'échec).

Merci d'avance pour votre aide !

++

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




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



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


Re: [FRnOG] [MISC] le pétaoctet du pauvre

2020-02-29 Par sujet Raphael Mazelier

Concernant le hardware Maxime est un spécialiste ;)

La bonne question : c'est que tu veux stocker dans tes 1Po ? et comment 
tu veux y accéder ?


Sur ce genre de volumétrie j’éviterais le filer pur, je partirais plutôt 
sur du stockage objet (ceph, scality, openio).


--

Raphael Mazelier

On 29/02/2020 19:51, Michel Py wrote:

Maxime De Berraly a écrit :
Si tu a des DS4246 en trop je peut comprendre :D , mais sauf si c'est pour 
s'amuser
pourquoi ne pas partir sur un storinator? https://www.45drives.com/

J'ai regardé avec beaucoup d'intérêt; vu de mon coté il y a 3 inconvénients 
majeurs :
1. C'est super profond; pour remplacer les disques il faut avoir les mégas 
rails avec les bras articulés pour les cables.
2. Impossible de remplacer les expanders SAS à chaud. Est-ce que çà fait le 
double-port SAS (multipath IO) ?
3. Ca chauffe. Les disques dans la dernière rangée, j'aimerais pas être à leur 
place.

J'ai des MDS 600 : 
https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c01671885
70 disques chacun, plein d'emmerdes. Mécaniquement c'est naze.

J'ai aussi regardé çà :
https://www.supermicro.com/en/products/chassis/4U/847/SC847E2C-R1K28JBOD
Problème : single point of failure : l'expander SAS n'est pas remplaçable et la 
même carte fait les deux ports SAS.



Michel 'ic' Luczak a écrit :
https://github.com/ewwhite/zfs-ha/wiki

J'ai regardé avec beaucoup d'intérêt aussi, au niveau hardware c'est l'idéal : 
tout est hot-swap.
Inconvénient : il n'y a que NFS. Pas de iSCSI target ni de Samba :-(



Phil Regnauld a écrit :
Oui, ça marche, si on veut mettre tous ses oeufs dans un seul panier :)

Le failover du stockage, c'est comme le failover de data center : çà marche des 
fois, des fois pas, faut tester souvent, et le jour ou t'en as vraiment besoin 
généralement il y a une surprise.
C'est pas quand t'es dans la mouise qu'il faut commencer à regarder pourquoi 
pacemaker et corosync n'ont pas marché.
En plus, le failover n'est pas immédiat, et il est plus que probable qu'il y a 
des trucs qui vont se planter.
Je dis pas que çà sert à rien, mais faut que çà soit fait super bien.


J'ai aussi regardé çà :
https://www.synology.com/en-us/products/RC18015xs+ avec 
https://www.synology.com/en-us/products/RXD1215sas
Problème : 1 seul port SAS qu'il faut cascader, en performance c'est nul.
Le mettre dans son propre serveur c'est possible : https://xpenology.org/
Mais même s'il n'y avait pas l'aspect légal, c'est la galère avec les MAJ et le 
support.



En fonction du besoin, fe ferais deux machines et du ZFS avec répliction 
croisées.

Avec quel logiciel ?


Si on veut vraiment 1 TO de stockage contigu/agregé,

J'ai pas besoin de contigu. Un RAID60 / RAIDZ2 stripe de 300TO c'est suffisant 
pour moi.


faut regarder CEPH plutôt

J'ai regardé, pas encore essayé. Cà a l'air un peu usine à gaz sur les bords.

Michel.



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



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


Re: [FRnOG] [TECH] Bascule IP Publique

2020-02-14 Par sujet Raphael Mazelier



On 14/02/2020 04:55, Michel Py wrote:

Je plussoie aussi. La redondance, c'est bien. La redondance testée, c'est mieux 
! Quel que soit le système, çà marche rarement la première fois.

J'ai presque envie de dire que même si cela a marché pendant le test 
cela ne marchera pas quand tu en auras besoin.


La meilleure redondance d'infrastructure (réseau/système) c'est celle 
dont tu n'as pas besoin.


Premièrement c'est toujours meilleur d'avoir une redondance pensé au 
niveau applicatif.


Deuxièmement si je me fie à mes 18 ans d'expériences, finalement je 
pense qu'essayer de rendre les choses redondantes m'ont posé plus de 
problèmes et faire perdre de temps que sauver quoi ce soit.


Le meilleur exemple, parmi les nombreuses anecdotes que je pourrais 
avoir sur le sujet, c'est la redondance de data-center, ou on essaye 
d'avoir tout en double équitablement réparti, et que finalement on 
double le spof, et que dès qu'un des deux DCs à un soucis, l'ensemble 
est HS. Testé et approuvé de nombreuse fois. Ceci étant je peux moduler 
ce propos, car en cas de crash majeur (type incendie ou autre) c'est 
tout de même beaucoup plus rapide de repartir de ton second datacenter.



--

Raphael Mazelier



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


Re: [FRnOG] [TECH] Bascule IP Publique

2020-02-13 Par sujet Raphael Mazelier
Un lan étendu entre 2 dc(s) ce n'est pas le meilleur design que je 
conseillerais.


Le mieux pour de la vrai redondance c'est du shared nothing, donc de la 
redondance avec un DNS externe. A défaut du L3, et une IP annoncée en 
BGP de l'un coté ou de l'autre.


Ah oui c'est beaucoup mieux si possible d'avoir de l'actif/actif. Sinon 
le jour ou tu dois basculer tu peux être sur qu'il y a un détail qui 
fera que cela ne fonctionnera pas.


--

Raphael Mazelier

On 13/02/2020 20:34, Free wrote:

Bonsoir,

Pour ma part je te conseille effectivement d’utiliser du BGP pour la partie 
publique.

Concernant la partie LAN, un niveau 2 entre les 2 DC serait le bienvenue (même 
plan d’adressage LAN sur les 2 DC du coup).

Tu peux protéger ton infra par une HA entre deux firewalls, ton site A sera 
primaire et tu track des IPs/interface pour déclencher la bascule sur le FW 
secondaire et donc le 2e DC.
Les 2 FW auront la même IP LAN (de ce que j’ai vu chez fortinet en tout cas) et 
donc pas de soucis de Gateway.

Bonne soirée.




Le 13 févr. 2020 à 19:07, Jean Théry  a 
écrit :

Clairement.



Le 13/02/2020 à 19:06, David Ponzone a écrit :
Pour moi, les 2 (LAN et WAN) sont nécessaires.
C’est bien d’avoir uCARP ou truc pour bouger l’IP d’un serveur à l’autre entre 
les 2 DC, mais l’IP doit être joignable par les 2 transits.


Tout en oubliant pas que les 2 machines/équipements doivent être sur le
même domaine de broadcast/multicast

(marrant le lien Wikipédia ne parle même pas de FreeBSD alors que le
support existe depuis v9 :)

Perso je conseillerai plutôt la solution BGP ici.


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

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


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


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



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


Re: [FRnOG] [TECH] Bascule IP Publique

2020-02-13 Par sujet Raphael Mazelier
Comme proposé par mes collègues tu as la solution d'annoncer un /24 sur 
l'un ou l'autre des sites. Mais le meilleur serait à mon avis de ne pas 
avoir à le faire est d'assurer ta redondance niveau DNS. Cela dépend 
évidement du type de service que tu veux exposer (mais bon de nos jour 
tout est sur http(s) non ?).


--
Raphael Mazelier


On 13/02/2020 17:10, Bruno LEAL DE SOUSA wrote:

Bonjour à tous,

Je pose la question car je sais qu'ici y en a forcément qui l'ont déjà fait
ou étudié :)

On est actuellement en train d'étudier un projet Datacenter pour
centraliser tous nos actifs en louant des racks chez un hébergeur.
On aurait deux salles séparées par 50 Km.

On fait arriver des liens internet dessus sur les deux salles. Mais comment
basculer une IP publique d'une salle à une autre ?
Le but est d'avoir deux salles extrêmement identiques et de basculer de
l'une à l'autre en toute transparence.

Quelles sont les solutions possibles dans ces cas là ? IP Publique
virtuelle ? Interfaçage de mes routeurs avec ceux des opérateurs ?

Merci pour vos retours !

A+




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


Re: [FRnOG] [TECH] Nouvelle Livebox sans SFP ?

2020-01-29 Par sujet Raphael Mazelier
Il faudrait faire de l’agrégation over the box. C'est possible mais cela 
n'a aucun intérêt. Enfin d'une manière générale je ne comprends même pas 
le point d'avoir plus de 1gbit/s @home.


--

Raphael Mazelier

On 29/01/2020 12:28, Romain wrote:

Il y a 2 Gbps au cul de la box mais que des ports 1 Gbps et pas de support
de l'agrégation.
Y'a un topic ici :
https://lafibre.info/orange-les-news/livebox-5-2-gbs-sur-un-seul-pc/

Le mer. 29 janv. 2020 à 12:25, Richard Klein  a
écrit :


Bonjour

Le nom de code était Ankaa pour la phase beta
Pas pu testé les 2G mais il parait que c'est 2G par agrégation de deux port
lan 1G

Richard

Le mer. 29 janv. 2020 à 12:17, Module Fibre <
aurelien.rina...@modulefibre.com> a écrit :


Bonjour David,

Oui je confirme, un technicien Orange me l'a confirmé la semaine dernière

Aurélien


*Aurélien Rinald**i*

aurelien.rina...@modulefibre.com
*Directeur associé / Module Fibre*
15 avenue de Norvège / ZA Courtaboeuf
91140 Villebon sur Yvette
06.22.53.15.87
*www.modulefibre.fr <http://www.modulefibre.fr>*

Retrouvez nous au *Cloud Datacenter* le 18/19 mars 2020 à Portes de
Versailles
https://www.datacenter-cloud.com


Le mer. 29 janv. 2020 à 12:13, David Ponzone  a
écrit :


FRnOGien.ne.s,

On me dit qu’Orange aurait commencé à déployer des nouvelles box sans

ONT

et sans SFP (donc connecteur fibre en dur et non-extractible).
C’est vrai ou on m’a bullshité ?
Si oui, c’est une mauvaise nouvelle (surtout pour ceux qui achètent du
Just Fibre, parce que ça va être Just Fibre et Box).

Merci


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


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


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


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



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


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

2020-01-17 Par sujet Raphael Mazelier
Personnellement j'injecterais ces routes en BGP (via exabgp ou autre).  
Pas besoin de reloader quoi que ce soit coté Bird.


(Btw je migrerais tes 8k routes ospf dans ibgp)

--

Raphael Mazelier

On 16/01/2020 18:03, Duchet Rémy wrote:

L'objectif c'est justement que Bird apprenne les routes via autre chose que 
"STATIC".  Aujourd'hui c'est un script qui modifie un simple fichier, via de 
l'automatisation. Et c'est STATIC => OSPF .
Mais dans ce sens pour ajouter une route dans la table STATIC, ça demande le 
"configure" pour que la route soit active pour Bird. Et donc le changement de 
la table STATIC provoque la propagation de l'intégralité de la table OSPF à tous les 
autres devices.

Pour la partie BGP je n'ai pas de soucis, d'autant que c'est un de nos RS.
Par contre, dans la 2.0.7 Ipv4 et IPv6 c'est le même process. Et c'est les 
TABLE qui semblent séparer les versions, du coup toute la config change.

Cordialement,

Rémy

-Original Message-
From: Alarig Le Lay 
Sent: jeudi, 16 janvier 2020 17:49
To: Duchet Rémy 
Cc: frnog@frnog.org
Subject: Re: [FRnOG] [TECH] OSPF Bird et configure

What ?!

bird> show route
Table master4:
0.0.0.0/0unicast [kernel_ipv4 09:46:49.133] (10)
 via 85.166.184.1 on enp2s0
45.91.126.32/28  unicast [ospf_ipv4 09:47:05.225] E1 (150/20) [45.91.126.96]
 via 45.91.126.96 on enp3s0.50
79.170.80.128/25 unicast [ospf_ipv4 10:10:59.225] E2 (150/10/64) [4faa50fa] 
[45.91.126.236]
 via 45.91.126.236 on tinc0
[…]
bird> show route protocol kernel_ipv4
Table master4:
0.0.0.0/0unicast [kernel_ipv4 09:46:49.133] (10)
 via 85.166.184.1 on enp2s0
85.166.184.0/22  unicast [kernel_ipv4 09:46:49.133] (10)
 dev enp2s0
bird> show route protocol kernel_ipv6
Table master6:
::/0 unicast [kernel_ipv6 09:46:49.133] (10)
 via fe80::5e5e:abff:fe43:1ece on enp2s0
2001:4640:a14f::/48  unreachable [kernel_ipv6 09:46:49.133] (10)

J’ai bien des routes OSPF et bird ne les apprend pas via le kernel. Je ne vois 
pas comment ça pourrait marcher s’il le faisait d’ailleurs.

Et en version BGP (avec une full) c’est pareil :

bird> show route
128.0.128.0/20 via 89.234.186.33 on vmbr12 [ibgp_asbr01_ipv4 2020-01-04] * 
(100/?) [AS25513i]
via 89.234.186.33 on vmbr12 [ibgp_asbr02_ipv4 2020-01-11 
from 89.234.186.34] (100/?) [AS25513i]
208.0.208.0/24 via 89.234.186.34 on vmbr12 [ibgp_asbr02_ipv4 2020-01-11] * 
(100/20) [AS46559i]
via 89.234.186.34 on vmbr12 [ibgp_asbr01_ipv4 2020-01-11 
from 89.234.186.33] (100/20) [AS46559i]
40.0.40.0/24   via 89.234.186.34 on vmbr12 [ibgp_asbr02_ipv4 2020-01-11] * 
(100/20) [AS4249i]
via 89.234.186.34 on vmbr12 [ibgp_asbr01_ipv4 2020-01-11 
from 89.234.186.33] (100/20) [AS4249i] […]
bird> show route protocol kernel1
89.234.186.114/32  dev tap109i0 [kernel1 2019-09-29] * (10)
89.234.186.115/32  dev tap106i0 [kernel1 2019-09-29] * (10)
80.67.190.218/32   dev tap140i0 [kernel1 2019-09-29] * (10)
[…]

Et ça correspond bien aux routes que j’exporte :

bird> show route export ibgp_asbr01_ipv4
89.234.186.114/32  dev tap109i0 [kernel1 2019-09-29] * (10)
89.234.186.115/32  dev tap106i0 [kernel1 2019-09-29] * (10)
80.67.190.218/32   dev tap140i0 [kernel1 2019-09-29] * (10)
89.234.186.112/32  dev tap101i0 [kernel1 2019-09-29] * (10) […]

Et là, c’est du 1.6 (merci debian…)

On jeu. 16 janv. 16:28:36 2020, Duchet Rémy wrote:

En fait les routes BGP apparaissaient dans le kernel avec les routes OSPF.
En lisant le mail, je viens de relire la config de Bird.
Je viens de me rendre compte que j'avais un export all sous le protocol kernel 
qui me polluait.

Du coup, je regarde pour upgrader en 2.0.7, pour loader les routes (dans l'idée linux 
=> kernel => annonce bgp) et ainsi supprimer l'OSPF.
Mais bien évidement la migration 1.6 => 2 se fait dans la ré-écriture complète 
de la conf.

Merci à tous pour les réponses.

Rémy

-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of
Alarig Le Lay
Sent: jeudi, 16 janvier 2020 09:41
To: Duchet Rémy 
Cc: frnog@frnog.org
Subject: Re: [FRnOG] [TECH] OSPF Bird et configure

Non, tu connais seulement les routes qui sont insérées « à la main » (ou via un 
autre soft).
Sinon bird apprendrait ses propres routes et bonjour la boucle infinie.

On jeu. 16 janv. 08:08:22 2020, Duchet Rémy wrote:

Bonjour,

Sur cette même instance Bird, on a déjà du BGP pour agréger
plusieurs full view.
Du coup, le kernel connaissant déjà toutes les routes BGP, ça va
faire mal de chercher à voir si une route OSPF est déjà dans la table..

Mais oui, une des pistes est de basculer sur du "tout" BGP. Mais la
problèmatique sera identique si on doit faire du configure pour
ajouter des routes.

Cordialement,

Rémy

-Original Message-
From: frnog-requ...@frnog.org  On Behalf Of
Alarig Le Lay
Sent: mercredi, 15 janvier 2020 20:24

Re: [FRnOG] [TECH] Admin Outofband or not

2020-01-15 Par sujet Raphael Mazelier



On 15/01/2020 14:48, Guillaume Genty (Waycom) wrote:

Hello,

Si tu veux quelques conseils en OOB que on a identifié au fil du temps 
chez nous:


- Avoir les consoles de tous les équipements critiques en OOB (genre 
pour avoir le rommon cisco qui reboot pas)
Oui je n'ai pas préciser mais OOB pour moi c'était uniquement des 
routeurs console.
- Éviter au max le L2 ou L3 entre la prod et l'OOB. (un broadcast 
storm pourrait te planter ton routeur OOB)


Règle numéro un de l'OOB aucun lien, mais vraiment aucun lien avec ton 
réseau.


- Pour les équipements avec un port de management L3 IP (genre ASR) 
mettre un bête switch premier prix pour ne pas utiliser le L2 de prod


Je ne suis pas pour connecter les cartes de managements à l'OOB.

Un hébergeur a connu un incident marrant  par exemple; broadcast storm 
sur son réseau Admin/OOB, interface de management d'une certaine marque 
commençant par J connectée, trafic qui remontent aux CPUs des control 
plane. Plouf.


- Si tu met des restrictions IP, prévoit une VM de rebond à 
l'extérieur de ton réseau, elle même accessible depuis n'importe 
quelle IP

+1.
- Des connexions grand public 4G ou de l'ADSL (pour les sites où ça ne 
captent pas) sont largement suffisantes, par-contre prévoit un tunnel 
qui remonte sur ta VM de rebond
- Supervise tes équipements de OOB !!! Je pense même que c'est le 
point le plus important de la liste !

+100


Avec tout ça, tu devrais être tranquille un moment...




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


Re: [FRnOG] [TECH] Admin Outofband or not

2020-01-15 Par sujet Raphael Mazelier

Hello,

Ce qui reste certain c'est qu'il te faut un OOB sur chaque site.

Sur un nombre restreint de pop (moins de 20 disons) et des pops connus, 
je trouvais toujours à m'arranger avec des amis pour avoir un accès L3 
depuis un autre AS.


On déployait de l'opengear avec restrictions IP et clé ssh (on estimait 
que c'était suffisant comme sécu). On supervisait à minima ces 
équipements (ping , probe ssh).


Maintenant sur des pops plus exotiques il faut souvent demander au DCs, 
ou au pire faire du reverse vpn 4g.


--

Raphael Mazelier

On 15/01/2020 13:00, FAGART, Thomas wrote:

Bonjour la liste,

Suite à des incidents récents un peu durailles sur nos réseaux, on se repose un 
peu la question de plus développer notre réseau out of band.

Finalement nous sommes un peu jeune là-dessus,  on a fait quelques tentatives 
listées ci-dessous :


-Outofband « interconnecté » avec l'IGP via de l'ADSL Tiers + VPN sur 
des pops importants

-Outofband en mode console only sur des sites de transmission critiques 
via de la 3G/4G Tiers + VPN

Les difficultés qu'on a rencontrées ou qui me viennent en tête sont les 
suivantes :


-Comme l'outofband n'était pas considéré comme critique, la sup ne l'était 
pas nécessairement non plus et le jour où on en besoin, ben ça ne fonctionne plus 
-> surtout une question de process

-L'outofband passant par du tiers en L3 c'est aussi bien souvent une 
fenêtre sur des pops importants et des équipements importants qu'il est plus 
compliqué de sécuriser

Du coup mes questions :


-Comment faites-vous chez vous ? (si c'est pas indiscret :) )

-Quels sont vos conseils ?

Merci

Thomas
--
Les donnees et renseignements contenus dans ce message sont personnels, 
confidentiels et secrets. Toute publication, utilisation ou diffusion, meme 
partielle, doit etre autorisee. Si vous n'etes pas le bon destinataire, nous 
vous demandons de ne pas lire, copier, utiliser ou divulguer cette 
communication. Nous vous prions de notifier cette erreur a l'expediteur et 
d'effacer immediatement cette communication de votre systeme.

Any data and information contained in this electronic mail is personal, 
confidential and secret. Any total or partial publication, use or distribution 
must be authorized. If you are not the right addressee, we ask you not to read, 
copy, use or disclose this communication. Please notify this error to the 
sender and erase at once this communication from your system.

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



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


Re: [MISC] RE: [FRnOG] [MISC] Idée de sujet de mémoire d'ingénieur?

2020-01-14 Par sujet Raphael Mazelier



On 14/01/2020 11:21, Laurent GUINCHARD wrote:

"IP/MPLS Vs EVPN en environnement data-center"


Ou BGP dans le data-center et les réseaux de clos ?

--

Raphael Mazelier


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


Re: [FRnOG] [TECH] port down malgré niveau optique correcte

2020-01-09 Par sujet Raphael Mazelier
Il existe plein de raisons pour lesquelles un port avec une connectivité 
L1 peut être down.


En général il faut regarder au niveau protocolaire l2 (stp, auto-neg, etc..)

Cdt,

--

Raphael Mazelier

On 09/01/2020 10:24, Alexis Lameire wrote:

si c'est de l'arista, il faut souvent passer un speed forced 10fgfull
sur l'interface

Cordialement
Alexis Lameire




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


Re: [FRnOG] [TECH] plusieurs routers bgp problème avec igp

2019-12-27 Par sujet Raphael Mazelier



On 26/12/2019 19:46, Alarig Le Lay wrote:

Perso j’aime pas le next-hop self, c’est un coup à faire passer trois
switches à un paquet alors qu’un autre routeur peut être juste à côté.
Je considère que mes intercos font partie de ma topologie, donc je les
mets dans mon OSPF.

Cela peut être complètement légitime de faire le tour de ton backbone 
pour aller au routeur d'à coté.


Tu dois maîtriser ta topologie avec les poids qui vont bien sur tes 
liens d'interco. Si tu ne fait pas ça tu vas toujours au plus prêt.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] plusieurs routers bgp problème avec igp

2019-12-26 Par sujet Raphael Mazelier



On 26/12/2019 12:33, Paul Rolland (ポール・ロラン) wrote:



Peut-être pour te contraindre à TOUJOURS monter tes sessions BGP sur les
Loopback.

Peut-etre aussi parce que ca t'oblige a regler d'abord tes problemes de
NLRI ;)

Parce que selon moi c'est le plus propre et lisible. Un IGP ne servant 
qu'à faire du calcul de topologie tu n'as donc que ta topologie dedans.


Et effectivement cela t'oblige à faire du next-hop self sur tes sessions 
iBGP ce qui me semble une bonne pratique, sinon tu as vite fait de 
l'oublier et d'avoir des routes avec des NH qui pointe sur des IPs 
d'intercos.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] plusieurs routers bgp problème avec igp

2019-12-26 Par sujet Raphael Mazelier



On 26/12/2019 11:01, Antoine DURAND wrote:

Merci David :)
Je viens de comprendre mon erreur et effectivement c'est tout bon, je 
n'ai plus de rib-failure !!!
Est-ce que sur les interfaces qui sont côtés transitaires ou qui ne 
sont pas dans le igp je dois indiquer à OSPF de les passer passive 
(passive-interface FastEthernetX/X) ?


A titre personnel je le ferais. Pour moi IGP ce n'est activé que sur les 
interfaces dites "Core/Interco" de ton backbone.


Cdt,

--

Raphael Mazelier


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


Re: [FRnOG] [TECH] plusieurs routers bgp problème avec igp

2019-12-26 Par sujet Raphael Mazelier



On 26/12/2019 09:31, David Ponzone wrote:


Donc la seule chose que tu dois redistribuer dans OSPF, c’est les connected:


A titre personnel je ne mettrais que les loopbacks. Il y a un micro 
débat sur mettre les subnets d'interco core.


(tiens pourquoi ne parle d'ISIS quand on parle IGP ?)



La seule chose que tu dois redistribuer dans BGP, c’est tes statiques (à 
priori):


Tout le reste que tu veux joindre non ? donc tes connected (clients), 
statiques, BGP customers, etc...


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] TCP shape depuis les US - Identifier l'origine ?

2019-12-12 Par sujet Raphael Mazelier



On 12/12/2019 10:19, Frederic Dumas wrote:



C'est une question de curiosité, pas un problème réel dans le cas 
présent.



En général le rtt (et donc la vitesse de la lumière), et le loss sont 
une bonne indication du débit théorique que tu peux atteindre en TCP ,;)


--

Raphael Mazelier


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


Re: [FRnOG] [MISC] Grève : blackout en datacenter?

2019-12-11 Par sujet Raphael Mazelier



On 11/12/2019 14:50, Hervé BRY wrote:


Certains sont qualifiés "Opérateur d'Importance Vitale", mais je ne sais
pas ce que ça implique vraiment en cas de crise...


J'imagine qu'il ne sont pas soumis au délestage en cas de gros problème 
d’approvisionnement électrique et qu'il n'est pas non plus possible de 
pas manuellement arrêter leur distribution sous peine de sanction légale ?


--

Raphael Mazelier



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


Re: [FRnOG] [TECH] BGP best practice

2019-12-11 Par sujet Raphael Mazelier



On 11/12/2019 08:36, Antoine DURAND wrote:

Hello,

Période calme pour moi avant les fêtes, je me remets sur la refonte de 
mon archi BGP...


Est-ce que vous supprimez la route par défaut 0.0.0.0/0 de vos 
routeurs BGP lorsque vous êtes en full-view ?


Il y a deux choses : accepter une route par défaut de tes transits (ça 
se discute) et avoir une default dans ta table.


J'avais l'habitude de garder une default statique vers l'un de mes 
transits sur mes edge, comme çà en cas de grosse foirade tes paquets 
peuvent quand même sortir, et tu peux te connecter sur ton edge sur l'ip 
d'une de tes intercos.


--

Raphael Mazelier




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


Re: [FRnOG] [MISC] Besoin d'avis pour mon avenir professionnel

2019-11-19 Par sujet Raphael Mazelier

Bonjour,

Sur ce sujet hautement inflammable je me permets de donner mon 
expérience et mon petit avis/conseil.


Pour le contexte : j'ai l’équivalent d'un master2 en Ingénierie Réseau 
et Système, donc la fac (UVSQ), ayant auparavant eu un DUT informatique 
(à Nantes). Il faut savoir que j'avais choisi de faire un DUT (cycle 
court) car je m'ennuyais profondément en cours au lycée, et que je ne 
voulais pas partir en prépa.


Je ne regrette pas du tout ce choix, bien au contraire. J'estime que mes 
années d'études font partie des meilleurs moments de ma vie.


La 1ere partie, l'IUT n'était pas fou en terme d'enseignement mais

1) j'ai appris énormément avec mes collègues et je n'en serais 
clairement pas la ou j'en suis si je ne les avais pas rencontré


2) j'ai profité des ces années pour me découvrir (aka faire des 
expériences, la fête mais pas que).


Si tu peux financièrement le faire ne te prive pas de ses années.

La 2eme partie : la fac + dess auront été fondamentales pour moi en 
terme d'apprentissage.


J'ai eu la chance de revenir sur la théorie de toutes les notions 
pratiques que nous avions survolé en IUT. J'ai adoré même si clairement 
je n'utilise pas tout ce que j'ai appris. Mais cela m'a donné les bases 
théoriques nécessaires pour voir plus loin que le bout de mon nez, et 
l'envie de repousser les limites (les limites/boundaries en entreprise 
je pourrais en parler longuement).


Évidement tout le monde est différent, et je connais des autodidactes 
qui sont maintenant CTO, ou qui s'éclatent dans des supports postes.


Je pense toutefois que c'est plus dur, pas sans diplôme (je crois que 
les sociétés ne font plus trop attention à ca maintenant) mais sans ce 
bagage théorique. Tu peux l’acquérir après, mais dés que tu bosses tu es 
forcément sur un domaine spécifique, et le soir tu auras peut être plus 
de mal à t'autoformer.


Maintenant si ça te saoule et que tu as envie de toute défoncer en 
entreprise => go. L'essentiel c'est de garder cette soif d'apprentissage 
constant.


My 2cents.

--
Raphael Mazelier


-Message d'origine-
De : Cécile MORANGE  Envoyé : dimanche 17 novembre 2019 
22:10 À : frnog-m...@frnog.org Objet : [FRnOG] [MISC] Besoin d'avis pour mon avenir 
professionnel

Hello la liste !

Avant de me lancer dans une aventure pour le moins risqué (= quitter ma 
formation actuelle et aller faire un vrai métier qui me plait), j’aimerais 
avoir votre avis, vous qui travaillez dans ce secteur d’activité et vous qui 
savez la réalité des choses.
Pour ceux qui ne me connaissent pas, Cécile, 19 ans, Aix-en-Provence, en 
alternance BTS SIO SISR (en gros système réseau) chez un OIV. Mon CV est 
disponible ici : https://cecilemorange.fr. @AtaxyaNetwork sur twitter (oui oui, 
la folle qui a fait une server room chez elle).

Ma question est la suivante :
- Si je quitte mon BTS maintenant, aurai-je des chances de trouver un boulot 
qui me plait ?
(Le pourquoi du comment se trouve ici : 
https://www.twitlonger.com/show/n_1sr2c32. En résumé, j’ai l’impression de rien 
apprendre en cours, et mon travail consiste à 90% à faire des tickets)

J’en ai parlé avec plusieurs personnes dans cette liste, on a déjà débattu sur 
le « Oui, mais un diplôme c’est mieux », mais dans l’état actuel des choses, la 
seule chose qui me freine à arrêter ce BTS et l’alternance est de ne pas 
retrouver de travail.

Un boulot qui me plairait ? De la technique. (bon, plus en système qu’en 
réseau), c’est-à-dire toucher à des serveurs, des configs, et pas faire des 
tickets pour que ce soit l’infogérant qui le fasse.
Et un qui me fait rêver ? En datacenter.

Voilà, j’ai besoin de vos avis (et des idées de métier que je pourrais viser) 
pour m’aider dans ma décision finale

Merci d’avance et bonne fin de week-end à tous (ou bon lundi, ça dépends de 
quand vous lirez ce mail !)



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


Re: [FRnOG] [TECH] changement hardware et choix Quagga/FRRouting

2019-11-14 Par sujet Raphael Mazelier



On 14/11/2019 20:05, Alarig Le Lay wrote:

On jeu. 14 nov. 18:16:34 2019, Antoine DURAND wrote:
Je l’active pour BCP38 et autres trucs du genre, mais toujours sur des
trucs en stateless ; et je ne fais pas du tout de NAT.

Yes soit tu te passes complètement d'iptables sur tes routeurs linux 
(c'est complètement faisable avec un peu de config ip et des tables). 
Soit tu fais au pire du stateless. Activer iptables même en stateless 
est coûteux, en statefull c'est l'échec.


Encore une belle différence avec un routeur qui peut gérer ça en 
hardware. Après je ne connais pas le statut dans dpdk.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] changement hardware et choix Quagga/FRRouting

2019-11-14 Par sujet Raphael Mazelier



On 13/11/2019 15:44, Alarig Le Lay wrote:

Et quand on a compris la logique, on ne veut pas retourner sur du cisco
like :p

Sérieusement, des gens *aiment* la CLI de IOS ou IOS-XE ?

Disons que la CLI cisco est un standard de facto et qu'elle est plutôt 
simple et concise à lire.


En revanche j'ai toujours détesté l’édition (bon avec un commit mode ça 
passe un peu mieux, style sur nxos ou sur ios-xr). Pire encore sont les 
access-list et les route-map.


Une configuration juniper ou bird sera plus verbeuse mais beaucoup plus 
flexible et simple à changer.


Cdt,

--

Raphael Mazelier




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


Re: [FRnOG] [TECH] changement hardware et choix Quagga/FRRouting

2019-11-13 Par sujet Raphael Mazelier



On 13/11/2019 11:10, Jérôme Nicolle wrote:


Le projet a forké depuis quelques années déjà, et c'est de loin le plus
actif. C'est donc préférable de partir sur FRR plutôt que Quagga.

C'est un retour source en quelque sorte :)


BIRD est aussi un excellent choix, plus simple à automatiser que FRR à
mon avis, mais il n'a rien à voir en terme de CLI.



Bird est beaucoup plus flexible au prix d'une certaine courbe 
d'apprentissage.


Je préfère personnellement mais je peux comprendre l'approche CLI cisco 
like.


--

Raphael Mazelier


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


Re: [FRnOG] [TECH] Multihoming BGP avec COGENT en principal et SFR en backup

2019-11-09 Par sujet Raphael Mazelier

oui et je mentirais si je disais ne jamais l'avoir fait.

--

Raphael Mazelier

On 09/11/2019 01:44, Guillaume Barrot wrote:

ou de monter un GRE ...

Le jeu. 7 nov. 2019 à 14:35, Raphael Mazelier  a écrit :





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


Re: [FRnOG] [TECH] Multihoming BGP avec COGENT en principal et SFR en backup

2019-11-07 Par sujet Raphael Mazelier



On 07/11/2019 14:24, Emmanuel DECAEN wrote:


D'ailleurs, c'est assez surprenant de constater que les Tier 1
paraissent globalement nettement moins chers que les Tier 2.
J'ai du mal à m'expliquer ce phénomène, j'imagine que tout est question
de volume...


Le volume principalement. (taille des tuyaux et société)

Et aussi les tier1 ne fournissent pas le même service par nature.

En résumant grossièrement un tier1 va pouvoir évacuer beaucoup de trafic 
de manière non optimale.


Un tier2 va pouvoir évacuer moins de trafic (car il n'est pas sizé pour) 
mais de manière plus optimale, car théoriquement il doit avoir un réseau 
avec plus de capillarité.


--

Raphael Mazelier



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


  1   2   3   4   5   6   >