RE: [FRnOG] [TECH] Question à propos du DSLAM Adtran Total access 1248

[Michel Py]

> Michel Py a écrit :
> Question bête : sur un DSLAM Adtran TA1248 quad-T1 ou octal-T1 (1179641AL1 / 
> 1179641AL4) qui a Ethernet,
> est-ce qu'on peut se servir de l'Ethernet pour le backhaul ou est-ce qu'il 
> faut impérativement se servir des T1 ?

Je me réponds à moi-même : non. ATM seulement, quelle ch..., va falloir que je 
mette des NM-ATM-T1 dans un 2600 :-(

Faut que je monde un petit DSLAM en interne (environ 150 ports) et j'ai besoin 
d'un truc pas cher et pas emmerdant, suggestions bienvenues.

Michel.


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

[FRnOG] [TECH] Question à propos du DSLAM Adtran Total access 1248

[Michel Py]

Bonsoir à tous,

Question bête : sur un DSLAM Adtran TA1248 quad-T1 ou octal-T1 (1179641AL1 / 
1179641AL4) qui a Ethernet, est-ce qu'on peut se servir de l'Ethernet pour le 
backhaul ou est-ce qu'il faut impérativement se servir des T1 ? J'ai lu quelque 
part que le port Ethernet c'était que pour "management".

Faut que je monde un petit DSLAM en interne (environ 150 ports) et j'ai besoin 
d'un truc pas cher et pas emmerdant, suggestions bienvenues.

Michel.


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

RE: [FRnOG] [Tech] Seagate "hyperscale"

[Michel Py]

> Frederic Dumas a écrit :
> Une question destinée aux membres de la liste qui auraient rencontré ces 
> disques durs dans leurs baies. Il s'agit des modèles chez Seagate :
> ST1NM0086 et ST1NM0016

Pour commencer, c'est pas le modèle que je prendrais. Je prendrais le SAS, pas 
le SATA.
ST1NM0096

> La seule différence entre ces deux modèles tiendrait à leur firmware. Le 
> premier serait "standard", l'autre "hyperscale"/"ultra-évolutif"). Le 
> firmware "hyperscale" offrirait 20% d'IOPS en plus. En contrepartie, 
> présente-t-il certains inconvénients ?

C'est pas ce que je lis. Dans ceci :
https://www.seagate.com/files/www-content/datasheets/pdfs/exos-x-10DS1948-1-1709US-en_US.pdf
Le modèle standard est plus performant que le "hyperscale".
Random Read/Write 4K QD16 WCD (IOPS) 170, 138 170, 138 170, 370 170, 370

En plus, il n'y a pas de modèle hyperscale pour le SAS, ce qui me fait penser 
que c'est beaucoup d'air chaud du marketing et pas grand-chose de concret.
Tu montes un boitier pétaoctet ? avec tes propres disques ?

Michel.


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

RE: [FRnOG] [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Michel Py]

> Kavé Salamatian a écrit :
> J’ai informé moi même début 2018 Verizon de problèmes similaires à ceux 
> décrits dans
> l’article (et de toutes une série d’autres relatifs à d’autres pays, eg, la 
> Russie).  
> J’attend toujours une réponse :-).
> J’ai fait la même démarche auprès d’autres opérateurs qui s’en foutent autant 
> …

Tu perds ton temps :-( Si tu n'es pas en client direct les informer de ce genre 
de chose c'est comme pisser dans un violon.
(même si tu es un client direct c'est la croix et la bannière...)


> Stephane Bortzmeyer a écrit :
> D'autre part, je suis très surpris que ce détournement ait duré
> deux ans sans que personne ne s'en aperçoive.

Pas moi.

> Mais la conclusion complotiste me laisse sceptique. Tout le monde peut
> voir les annonces BGP. Impossible de nier ou de dissimuler.

C'est vrai, mais je n'élimine pas la conclusion complotiste. C'est le système 
S.C.P.C.P : si çà passe, çà passe.
S'ils sont assez c... pour ne pas s'en apercevoir et ignorer ce que Kavé leur 
dit, pourquoi ne pas essayer ?
Il n'y a rien d'interdit, ce qui est interdit c'est de se faire piquer.

Il y a aussi la possibilité que çà soit techniquement débile mais sur le papier 
moins cher : c'est comme l'histoire des billets d'avion aller-retour dans la 
même semaine : il était un temps ou c'était moins cher d'acheter 2 
aller-retours avec le retour la semaine d'après et de n'utiliser que l'aller. 
Vu que les accords de peering sont confidentiels, faut s'attendre à tout et 
n'importe quoi.

La fonction de routage est au niveau 9 du modèle ISO :

+---+--+
| 9 | Politics | <== BGP
| 8 | Money| $
| 7 | Application  | HTTP
| 6 | Presentation | SSL
| 5 | Session  | RPC
| 4 | Transport| TCP
| 3 | Network  | IP
| 2 | Data-link| Ethernet
| 1 | Physical | Fiber
+---+--+

Michel.


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

Re: [FRnOG] [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Kavé Salamatian]

Je confirme. Nous avons en place depuis deux ans un observatoire BGP qui fait 
des snapshots toutes les minutes du graphe InterAS et on monitore donc les BGP 
hijack et autres événements BGP (qui ne soit pas que des chinoiseries, loin de 
la …).  J’ai informé moi même début 2018 Verizon des problèmes décrits dans 
l’article (et de toutes une série d’autres relatifs à d’autres pays, eg, la 
Russie).  J’ai informé moi même début 2018 Verizon de problèmes similaires à 
ceux décrits dans l’article (et de toutes une série d’autres relatifs à 
d’autres pays, eg, la Russie).  

J’attend toujours une réponse :-).

J’ai fait la même démarche auprès d’autres opérateurs qui s’en foutent autant …

Ca changera le jour ou on aura une véritable attaque BGP à grande échelle et 
que les gouvernements commenceront à mettre le nez dedans …

A+

Kv


> Le 9 nov. 2018 à 19:22, Bill Woodcock  a écrit :
> 
> 
> 
>> On Nov 9, 2018, at 12:36 AM, Stephane Bortzmeyer  wrote:
>> D'autre part, je suis très surpris que ce détournement ait duré deux
>> ans sans que personne ne s'en aperçoive. Verizon n'utilise pas BGPmon,
>> RIPE stat ou un service équivalent ? Ils ne regardent pas de looking
>> glass pendant deux ans ? Et, même s'ils ne supervisent pas BGP, ils
>> supervisent forcément le RTT depuis plusieurs points de mesure et le
>> détour par la Chine a dû faire un bond sérieux à la latence. Et leur
>> Nagios n'a pas couiné ???
> 
> Depuis que nous exécutons un résolveur récursif, nous voyons beaucoup de 
> chemins intercontinentaux surprenants et inutiles des utilisateurs finaux via 
> leurs ISPs, qui persistent souvent pendant une longue période, malgré les 
> rapports de problèmes de notre part et de leurs clients.
> 
> L'un des plus grands opérateurs de téléphonie mobile a perdu toutes les 
> réponses entrantes de deux des serveurs de noms racine, en raison d'un 
> problème de routage interne, jusqu'à ce que nous le leur informions. Des 
> dizaines de milliers de requêtes par seconde pendant plus de trois mois.
> 
>-Bill
> 


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

Re: [FRnOG] [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Bill Woodcock]

> On Nov 9, 2018, at 12:36 AM, Stephane Bortzmeyer  wrote:
> D'autre part, je suis très surpris que ce détournement ait duré deux
> ans sans que personne ne s'en aperçoive. Verizon n'utilise pas BGPmon,
> RIPE stat ou un service équivalent ? Ils ne regardent pas de looking
> glass pendant deux ans ? Et, même s'ils ne supervisent pas BGP, ils
> supervisent forcément le RTT depuis plusieurs points de mesure et le
> détour par la Chine a dû faire un bond sérieux à la latence. Et leur
> Nagios n'a pas couiné ???

Depuis que nous exécutons un résolveur récursif, nous voyons beaucoup de 
chemins intercontinentaux surprenants et inutiles des utilisateurs finaux via 
leurs ISPs, qui persistent souvent pendant une longue période, malgré les 
rapports de problèmes de notre part et de leurs clients.

L'un des plus grands opérateurs de téléphonie mobile a perdu toutes les 
réponses entrantes de deux des serveurs de noms racine, en raison d'un problème 
de routage interne, jusqu'à ce que nous le leur informions. Des dizaines de 
milliers de requêtes par seconde pendant plus de trois mois.

-Bill



signature.asc
Description: Message signed with OpenPGP

[FRnOG] [Tech] Seagate "hyperscale"

[Frederic Dumas]

Une question destinée aux membres de la liste qui auraient rencontré ces 
disques durs dans leurs baies. Il s'agit des modèles chez Seagate :


ST1NM0086

et

ST1NM0016





La seule différence entre ces deux modèles tiendrait à leur firmware. Le 
premier serait "standard", l'autre "hyperscale"/"ultra-évolutif"). Le 
firmware "hyperscale" offrirait 20% d'IOPS en plus. En contrepartie, 
présente-t-il certains inconvénients ?



Quelqu'un a-t-il en sait-il plus sur le sujet ?


--
Frédéric Dumas
f.du...@ellis.siteparc.fr


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

Re: [FRnOG] [TECH] ASN USA

[Guillaume Genty (Waycom)]

Hello la liste,

C'est effectivement pas propre d'utiliser le même AS pour deux réseaux 
distincts, mais dans ce cas tu peux faire comme nous et demander un second AS 
au RIPE pour ensuite ne l'annoncer qu'aux US.

Cordialement,

--
Guillaume Genty | WAYCOM
Directeur Technique Adjoint
5 quai Marcel Dassault | F-92150 Suresnes, FRANCE
T. : +33 (0)1 41 44 83 00 | F. : +33 (0)1 41 44 00 22
gge...@waycom.net | www.waycom.net

Le 07/11/2018 à 19:18, Pierre Emeriaud a écrit :

Le mer. 7 nov. 2018 à 18:50, Hugues Voiturier
 a écrit :

J’ai du mal à voir en quoi ça pose un souci d’utiliser le même AS partout dans 
le monde. Pour moi c’est même une bonne pratique, m’enfin.

oui bonne pratique _si_ tu as un backbone contigu. Allow-as-in c'est
juste s'exposer à de potentiels ennuis.


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

wcm_nosign


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

Re: [FRnOG] [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Eugène Ngontang]

Merci @Jérôme Nicolle   ;)

Le ven. 9 nov. 2018 à 15:38, Jérôme Nicolle  a écrit :

> Pierre,
>
> Le 09/11/2018 à 14:25, Pierre Emeriaud a écrit :
> > Cela ressemble beaucoup à ce qui peut arriver par erreur quand un
> > grand réseau comme CT gère un peu mal ses annonces. Oui, ça peut être
> > malveillant. Mais ça peut aussi être de l'incompétence.
>
> Je dirais même plus :
>
> « Ne jamais attribuer à la malveillance ce que la bêtise suffit à
> expliquer »
>
> (Rasoir d'Hanlon : https://fr.wikipedia.org/wiki/Rasoir_d%27Hanlon)
>
> @+
>
> --
> Jérôme Nicolle
> 06 19 31 27 14
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>


-- 
LesCDN 
engont...@lescdn.com

*Aux hommes il faut un chef, et au*

* chef il faut des hommes!L'habit ne fait pas le moine, mais lorsqu'on te
voit on te juge!*

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

Re: [FRnOG] [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Jérôme Nicolle]

Pierre,

Le 09/11/2018 à 14:25, Pierre Emeriaud a écrit :
> Cela ressemble beaucoup à ce qui peut arriver par erreur quand un
> grand réseau comme CT gère un peu mal ses annonces. Oui, ça peut être
> malveillant. Mais ça peut aussi être de l'incompétence.

Je dirais même plus :

« Ne jamais attribuer à la malveillance ce que la bêtise suffit à
expliquer »

(Rasoir d'Hanlon : https://fr.wikipedia.org/wiki/Rasoir_d%27Hanlon)

@+

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


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

Re: [FRnOG] Re: [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Jonas Termeau]

> T'façon OSEF, avec EverythingOverHTTPS, le MitM ça sert plus à rien.

Alors soit ça sonne peut-être aujourd'hui comme de la science fiction, mais 
collecter de larges quantités de traffic chiffré pour donner à manger à des 
prototypes d'ordis quantiques qui bossent sur des attaques de déchiffremlent 
c'est pas impossible non plus. Auquel cas le MiTM aurait encore du sens

(il se peut aussi que je sois passé à côté du sarcasme sans le voir)

Jonas Termeau 
Sysop / Sysadmin 




- Mail original -
De: "Jérôme Nicolle" 
Cc: frnog@frnog.org
Envoyé: Vendredi 9 Novembre 2018 15:02:17
Objet: [FRnOG] Re: [TECH] Strange snafu misroutes domestic US Internet traffic 
through China Telecom



Le 09/11/2018 à 15:00, Stephane Bortzmeyer a écrit :
> Les Experts Internationaux qui commentent les articles d'Ars
> Technica, ou qui écrivent sur Twitter, se soucient, eux, des enjeux
> politiques, et pensent que le Monde Libre est menacé.

Ah, Oui, Bon, OK Alors.

T'façon OSEF, avec EverythingOverHTTPS, le MitM ça sert plus à rien.

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


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


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

[FRnOG] Re: [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Jérôme Nicolle]

Le 09/11/2018 à 15:00, Stephane Bortzmeyer a écrit :
> Les Experts Internationaux qui commentent les articles d'Ars
> Technica, ou qui écrivent sur Twitter, se soucient, eux, des enjeux
> politiques, et pensent que le Monde Libre est menacé.

Ah, Oui, Bon, OK Alors.

T'façon OSEF, avec EverythingOverHTTPS, le MitM ça sert plus à rien.

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


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

[FRnOG] Re: [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Stephane Bortzmeyer]

On Fri, Nov 09, 2018 at 01:44:49PM +0100,
 Jérôme Nicolle  wrote 
 a message of 33 lines which said:

> C'est techniquement, économiquement et stratégiquement débile de
> faire un tel détour, mais c'est aussi totalement normal que BGP s'en
> foute !  Après tout, tu connais beaucoup d'admin réseau de gros
> opérateurs qui se soucient de quelque manière que ce soit de
> l'optimalité du routage ou d'enjeux politiques ?

Les Experts Internationaux qui commentent les articles d'Ars
Technica, ou qui écrivent sur Twitter, se soucient, eux, des enjeux
politiques, et pensent que le Monde Libre est menacé.


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

Re: [FRnOG] [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Pierre Emeriaud]

Le ven. 9 nov. 2018 à 09:37, Stephane Bortzmeyer  a écrit :
>
> L'article n'est pas mal, comme souvent chez Ars :
>
> https://arstechnica.com/information-technology/2018/11/strange-snafu-misroutes-domestic-us-internet-traffic-through-china-telecom/
>
> Mais la conclusion complotiste me laisse sceptique. Tout le monde peut
> voir les annonces BGP. Impossible de nier ou de dissimuler. Ça
> convient pour des attaques type « take money and run » comme l'attaque
> contre MyEtherWallet en avril 2018 mais pour une attaque d'État ?

J'ai lu l'article d'origine également, et je suis sceptique tout comme
toi. Cela ressemble beaucoup à ce qui peut arriver par erreur quand un
grand réseau comme CT gère un peu mal ses annonces. Oui, ça peut être
malveillant. Mais ça peut aussi être de l'incompétence.

Ensuite, il n'y a pas forcément non plus des masses d'interconnexions
à travers le pacifique. Dire que de l'australie ce n'est pas normal de
passer par la chine pour aller au UK, mouais.

L'article d'Ars fait suite à
https://scholarcommons.usf.edu/cgi/viewcontent.cgi?article=1050=mca,
que je trouve encore moins précis : "la route la plus courte entre le
canada et la korée c'est la ligne directe, mais le routage internet
passe par la chine" (cf page 8 dudit document) : c'est du flan. On
sait tous ici que le routage bgp est politique et non technique, mais
en ces périodes de cyber-guerre froide c'est bien de parler de
l'insécurité de l'internet.


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

[FRnOG] Re: [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Jérôme Nicolle]

Stéphane,

Le 09/11/2018 à 13:34, Stephane Bortzmeyer a écrit :
> Cela explique le détournement BGP (un problème pas si rare que ça)
> mais pas sa non-détection pendant deux ans.

En fait, je ne vois toujours pas de problème : ça a bien fonctionné
comme ça le devait, je ne vois pas en quoi ce serait un détournement
offensif !

Il se pourrait que la relation entre china telecom et verizon n'était
pas un peering classique et qu'il soit finalement normal que 703
apparaisse dans le cône client de China Telecom…

C'est techniquement, économiquement et stratégiquement débile de faire
un tel détour, mais c'est aussi totalement normal que BGP s'en foute !
Après tout, tu connais beaucoup d'admin réseau de gros opérateurs qui se
soucient de quelque manière que ce soit de l'optimalité du routage ou
d'enjeux politiques ?

@+

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


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

[FRnOG] Re: [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Stephane Bortzmeyer]

On Fri, Nov 09, 2018 at 11:08:12AM +0100,
 Jérôme Nicolle  wrote 
 a message of 23 lines which said:

> L'explication la plus simple que j'y vois c'est que Chinanet aurait
> ré-annoncé (très probablement par erreur de tagging et en violation
> du peering agreement avec vrz) des routes de 703 à ses pairs et que
> ces annonces soient préférées parce que verizon a une politique de
> peering de merde.
> 
> C'est le comportement normal et attendu entre un (trop) gros réseau
> pas forcément rigoureux et un réseau mal connecté, non ?

Cela explique le détournement BGP (un problème pas si rare que ça)
mais pas sa non-détection pendant deux ans.


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

Re: [FRnOG] [MISC] Chaîne d'alerte SSI et signalement

[Richard Klein]

Bonjour,

c'est plus a L'ANSSI de nous creer un observatoire ou de mettre en place ce
type de projet ?

Richard

Le ven. 9 nov. 2018 à 12:47, Alain BERNARD  a
écrit :

> Bonjour à toutes et à tous,
>
> Notre organisme est en train de définir/formaliser une chaîne d'alerte SSI.
>
> D'un point de vue opérationnel et organisationnel, comment les incidents
> de sécurité (hors escalade en gestion de crise) sont-ils signalés dans
> votre structure sur les jours non ouvrés ou en dehors des heures de
> permanences téléphoniques ?
>
> Certes, cela dépend en partie des activités de l'entreprise (i.e SOC
> ...). Je cherche avant tout à adopter de bonnes pratiques.
>
> Merci d'avance pour vos contributions.
>
> Bien cordialement,
>
> Alain B.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

RE: [FRnOG] [TECH] Performance Mikrotik CRS317-1G-16S+RM

[Pierre-Loïc Carette - ALPESYS]

D'accord avec Hugues !
En L3 ça ne tient  que 1.5G

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Hugues 
Voiturier
Envoyé : vendredi 9 novembre 2018 12:57
À : Julien Escario 
Cc : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] Performance Mikrotik CRS317-1G-16S+RM

Ça les tient en RouterOS ou en SwOS indéfiniment. Et tant qu’à faire, autant ne 
pas utiliser cette bouse de SwOS.

Sent from my iPhone

> On 9 Nov 2018, at 12:04, Julien Escario  wrote:
> 
>> Le 07/11/2018 à 12:18, Hugues Voiturier a écrit :
>> Ça tient le débit en switching sans souci. Après si tu as un peu plus de 
>> sous, un Nexus 3064 en broke reste une valeur plus sûre. 
> 
> Je confirme, ça tenait sans problème 9Gbps de payload TCP en pratique 
> dans nos essais (donc ~10Gbps line-rate).
> En SwOS par contre. 'tention à l'aspect sécurité.
> 
> On l'a gardé pour du stockage parce qu'après une phase rapide de 
> tuning des cartes Intel, on avait une latence plutôt sympa.
> 
> Julien
> 
> 
> ---
> 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] Performance Mikrotik CRS317-1G-16S+RM

[Hugues Voiturier]

Ça les tient en RouterOS ou en SwOS indéfiniment. Et tant qu’à faire, autant ne 
pas utiliser cette bouse de SwOS.

Sent from my iPhone

> On 9 Nov 2018, at 12:04, Julien Escario  wrote:
> 
>> Le 07/11/2018 à 12:18, Hugues Voiturier a écrit :
>> Ça tient le débit en switching sans souci. Après si tu as un peu plus de 
>> sous, un Nexus 3064 en broke reste une valeur plus sûre. 
> 
> Je confirme, ça tenait sans problème 9Gbps de payload TCP en pratique
> dans nos essais (donc ~10Gbps line-rate).
> En SwOS par contre. 'tention à l'aspect sécurité.
> 
> On l'a gardé pour du stockage parce qu'après une phase rapide de tuning
> des cartes Intel, on avait une latence plutôt sympa.
> 
> Julien
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [MISC] Chaîne d'alerte SSI et signalement

[Alain BERNARD]

Bonjour à toutes et à tous,

Notre organisme est en train de définir/formaliser une chaîne d'alerte SSI.

D'un point de vue opérationnel et organisationnel, comment les incidents
de sécurité (hors escalade en gestion de crise) sont-ils signalés dans
votre structure sur les jours non ouvrés ou en dehors des heures de
permanences téléphoniques ?

Certes, cela dépend en partie des activités de l'entreprise (i.e SOC
...). Je cherche avant tout à adopter de bonnes pratiques. 

Merci d'avance pour vos contributions.

Bien cordialement,

Alain B.


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

Re: [FRnOG] [TECH] Performance Mikrotik CRS317-1G-16S+RM

[Julien Escario]

Le 07/11/2018 à 12:18, Hugues Voiturier a écrit :
> Ça tient le débit en switching sans souci. Après si tu as un peu plus de 
> sous, un Nexus 3064 en broke reste une valeur plus sûre. 

Je confirme, ça tenait sans problème 9Gbps de payload TCP en pratique
dans nos essais (donc ~10Gbps line-rate).
En SwOS par contre. 'tention à l'aspect sécurité.

On l'a gardé pour du stockage parce qu'après une phase rapide de tuning
des cartes Intel, on avait une latence plutôt sympa.

Julien


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

Re: [FRnOG] [TECH] OpenVPN PfSense

[Justin Petermann]

Bonjour, 

Dans System > Advanced > Miscellaneous > Gateway Monitoring 

peux tu vérifier que : 
--- 
State Killing on Gateway Failure 
Flush all states when a gateway goes down The monitoring process will flush all 
states when a gateway goes down if this box is checked. 
--- 
est bien décoché ? 

Ce problème me prenait la tête et cela a résolut pas mal de pb. 

Pour une connexion stable, je te conseille vraiment de fixer l'adresse MAC dans 
ton client openvpn : 
lladdr ee:3c:21:xx:xx:xx (en récupérant par exemple celle qu'il utilise) 

car sinon, en cas de deconnexion il réattribut une nouvelle adresse MAC et 
toutes les sessions sont perdues. 

++ 
Justin 


De: "Wallace"  
À: frnog@frnog.org 
Envoyé: Mercredi 7 Novembre 2018 12:14:09 
Objet: Re: [FRnOG] [TECH] OpenVPN PfSense 

Bonjour, 

Ta modification concerne le tunnel ou un autre élément comme les rules? 

J'ai remarqué que depuis une ou deux versions, un changement dans les 
règles purge les sessions actuellement ouvertes. Je ne me suis pas 
encore penché sur le souci, il doit y avoir une option pour changer ce 
comportement je pense. 


Le 07/11/2018 à 12:08, Bastien Le Ribler a écrit : 
> Bonjour, 
> 
> Nous utilisons OpenVPN sur un PfSense pour avoir un VPN Site-to-Site. 
> Mais lorsque nous effectuons une modification sur le PfSense, OpenVPN 
> redémarre et nous perdons la connexion avec le site distant. 
> 
> Y'aurait-il un moyen pour empêcher OpenVPN de redémarrer après une 
> modification sur le Firewall ? 
> 
> Cordialement, 
> Bastien 
> 
> --- 
> Liste de diffusion du FRnOG 
> http://www.frnog.org/ 

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

[FRnOG] [FRNOG] [JOBS] Technicien Supérieur de Support en Informatique

[Sabri Boukari]

Hi Network, J’ai obtenu récemment mon titre professionnel de Technicien
Supérieur de Support en Informatique et je suis en recherche des postes
suivants : - Technicien de support de proximité - Technicien d’exploitation
- Technicien informatique

Peu importe le contrat de prestation du moment que ce dernier est
raisonnable ( > 4 mois). Ma zone de recherche se trouve principalement
entre Lyon, Mâcon, Villefranche sur Saône et Bourg-en-Bresse. J’étudierai
avec le plus grand soin chaque proposition et vous ferai un retour qu’il
soit positif ou négatif (c’est la moindre des choses). Je vous
communiquerai mes prétentions salariales en privé. Je remercie sincèrement
ceux qui prendront le temps de lire ce post, ceux qui le l’aimeront, le
partageront, ceux qui en parleront à leur proche et de manière générale
ceux qui me témoigneront de la bienveillance. Cordialement

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

[FRnOG] [JOBS] Profil réseau et infrastructure / Moirans (38)

[Olivier Le Brouster]

Bonjour à tous,

Vous trouverez ci-dessous une fiche de poste pour un CDI à PVNum. Ce
poste est situé à Moirans en Isère et débutera au premier trimestre
2019. Ingénieur ou technicien, nous nous adapterons au profil.

N'hésitez à revenir vers moi pour toute question.

Bonne suite de journée,
Olivier Le Brouster

---8<--8<--8<--8<--8<--8<--8<--8<---

PVNum est une SCIC (Société Coopérative d’Intérêt Collectif) qui a été
créée par un collectif d’entreprises de Voiron décidé à promouvoir le
très haut débit sur tout le Pays Voironnais à des prix accessibles y
compris aux TPE/PME. Nous commercialisons aux entreprises et aux
propriétaires de locaux professionnels des raccordements fibre optique
sur l’infrastructure réseau du Pays Voironnais.

Nous recherchons un profil réseau pour renforcer notre équipe.

Principales missions :

- vous procédez à la commande et au paramétrage des équipements
- vous intervenez sur site pour installer et assurer la maintenance des
  équipements réseau
- vous opérez l’administration des équipements
- vous supervisez notre réseau et en assurez la maintenance
- vous coordonnez les actions de prestataires externes

Compétences techniques

- Compétences réseau niveau 2 (VLAN/QinQ, QoS, STP)
- Compétences réseau niveau 3 (BGP, OSPF)
- Solide bases en administration système dans environment GNU/Linux

Qualités requises :

- Vous êtes rigoureux
- Vous avez le sens du service
- Vous êtes autonome
- Vous aimez apprendre et partager vos connaissances

--->8-->8-->8-->8-->8-->8-->8-->8---


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

Re: [FRnOG] [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Jérôme Nicolle]

Plop,

L'explication la plus simple que j'y vois c'est que Chinanet aurait
ré-annoncé (très probablement par erreur de tagging et en violation du
peering agreement avec vrz) des routes de 703 à ses pairs et que ces
annonces soient préférées parce que verizon a une politique de peering
de merde.

C'est le comportement normal et attendu entre un (trop) gros réseau pas
forcément rigoureux et un réseau mal connecté, non ?

@+

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


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

[FRnOG] [TECH] Strange snafu misroutes domestic US Internet traffic through China Telecom

[Stephane Bortzmeyer]

L'article n'est pas mal, comme souvent chez Ars :

https://arstechnica.com/information-technology/2018/11/strange-snafu-misroutes-domestic-us-internet-traffic-through-china-telecom/

Mais la conclusion complotiste me laisse sceptique. Tout le monde peut
voir les annonces BGP. Impossible de nier ou de dissimuler. Ça
convient pour des attaques type « take money and run » comme l'attaque
contre MyEtherWallet en avril 2018 mais pour une attaque d'État ?

D'autre part, je suis très surpris que ce détournement ait duré deux
ans sans que personne ne s'en aperçoive. Verizon n'utilise pas BGPmon,
RIPE stat ou un service équivalent ? Ils ne regardent pas de looking
glass pendant deux ans ? Et, même s'ils ne supervisent pas BGP, ils
supervisent forcément le RTT depuis plusieurs points de mesure et le
détour par la Chine a dû faire un bond sérieux à la latence. Et leur
Nagios n'a pas couiné ???

THRESHOLD is ,% where  is the round trip average travel
time (ms) which triggers a WARNING or CRITICAL state, and  is the
percentage of packet loss to trigger an alarm
state. ()


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