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

2020-01-16 Par sujet BLANCPAIN Nicolas 
BTW: ou utiliser des "area", pour summary-ser
8k routes c'est beaucoup, tant à traiter pour Bird qu'à appréhender pour l'admin

-Message d'origine-
De : frnog-requ...@frnog.org  De la part de Alarig Le 
Lay
Envoyé : mercredi 15 janvier 2020 20:24
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] OSPF Bird et configure

Bonsoir,

On mer. 15 janv. 17:01:28 2020, Duchet Rémy wrote:
> Bonsoir la liste,
> 
> 
> 
> S’il y a des utilisateurs de Bird sur la liste (je suis sur que oui) 
> connaissez-vous un moyen de rajouter une route (autrement qu’en
> STATIC) sur le serveur Bird, pour que ce dernier l’annonce (OSPF ou
> BGP) sans avoir à faire un « configure » à chaque changement ?
> 
> Nous avons quelques routes OSPF que nous annonçons (+ 8000) et à 
> chaque « configure » Bird renvoie toute la table (on lui fait relire 
> un fichier de conf), du coup ça flood pas mal nos équipements (toutes 
> les minutes)..

Pourquoi tu n’apprends pas les routes depuis le kernel ?

BTW, 8k routes dans un OSPF, soit tu as un très gros réseau, mais dans ce cas 
y’a peu de chances que tu utilises bird, soit faut passer à BGP.

--
Alarig


---
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-16 Par sujet Duchet Rémy 
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
To: frnog@frnog.org
Subject: Re: [FRnOG] [TECH] OSPF Bird et configure

Bonsoir,

On mer. 15 janv. 17:01:28 2020, Duchet Rémy wrote:
> Bonsoir la liste,
>
>
>
> S’il y a des utilisateurs de Bird sur la liste (je suis sur que oui)
> connaissez-vous un moyen de rajouter une route (autrement qu’en
> STATIC) sur le serveur Bird, pour que ce dernier l’annonce (OSPF ou
> BGP) sans avoir à faire un « configure » à chaque changement ?
>
> Nous avons quelques routes OSPF que nous annonçons (+ 8000) et à
> chaque « configure » Bird renvoie toute la table (on lui fait relire
> un fichier de conf), du coup ça flood pas mal nos équipements (toutes
> les minutes)..

Pourquoi tu n’apprends pas les routes depuis le kernel ?

BTW, 8k routes dans un OSPF, soit tu as un très gros réseau, mais dans ce cas 
y’a peu de chances que tu utilises bird, soit faut passer à BGP.

--
Alarig


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

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

Re: [FRnOG] [MISC] Bizarrerie des From sur la liste depuis aujourd'hui

2020-01-16 Par sujet Benjamin Collet 
Salut,

On Tue, Jan 14, 2020 at 11:34:03PM +, Philippe Bourcier wrote:
> Laurent à rajouté une modif... ca va faire "On behalf of...".
> Vous verrez avec les prochains DMARCeux.

Sans vouloir pinailler, ça serait possible de faire commencer par le nom
original comme le fait NANOG (c'est plus clair dans les MUA je trouve,
en particulier sous mutt et consorts), par exemple :
  « Benjamin Collet via FRnOG »

++
Benjamin
-- 
Benjamin Collet


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

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

2020-01-16 Par sujet Duchet Rémy 
Bonjour Elise,



En fait c’est uniquement la partie OSPF qui est réannoncé, et heureusement, car 
j’ai du BGP sur la même instance de Bird.



Cordialement,

Rémy



From: Elise Vennegues 
Sent: mercredi, 15 janvier 2020 18:59
To: Duchet Rémy 
Cc: frnog-t...@frnog.org
Subject: Re: [FRnOG] [TECH] OSPF Bird et configure



Bonsoir Rémy,



Tu peux sans doute regarder du coté de la feature "BGP: Optional Adj-RIB-Out”, 
par contre tu auras besoin de la version 2.0.7 pour supporter cette 
fonctionnalité.

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



Bonne soirée.



—

Elise Vennéguès





   On Jan 15, 2020, at 6:01 PM, Duchet Rémy 
mailto:r...@duchet.eu>> wrote:



   Bonsoir la liste,



   S’il y a des utilisateurs de Bird sur la liste (je suis sur que oui) 
connaissez-vous un moyen de rajouter une route (autrement qu’en STATIC) sur le 
serveur Bird, pour que ce dernier l’annonce (OSPF ou BGP) sans avoir à faire un 
« configure » à chaque changement ?

   Nous avons quelques routes OSPF que nous annonçons (+ 8000) et à chaque « 
configure » Bird renvoie toute la table (on lui fait relire un fichier de 
conf), du coup ça flood pas mal nos équipements (toutes les minutes)..



   Merci pour vos suggestions.



   Cordialement,



   Rémy




   ---
   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-16 Par sujet Vincent Bernat 
 ❦ 15 janvier 2020 18:59 +01, "On behalf of Elise Vennegues " 
:

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

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


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

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

2020-01-16 Par sujet Alarig Le Lay 
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
> To: frnog@frnog.org
> Subject: Re: [FRnOG] [TECH] OSPF Bird et configure
> 
> Bonsoir,
> 
> On mer. 15 janv. 17:01:28 2020, Duchet Rémy wrote:
> > Bonsoir la liste,
> >
> >
> >
> > S’il y a des utilisateurs de Bird sur la liste (je suis sur que oui)
> > connaissez-vous un moyen de rajouter une route (autrement qu’en
> > STATIC) sur le serveur Bird, pour que ce dernier l’annonce (OSPF ou
> > BGP) sans avoir à faire un « configure » à chaque changement ?
> >
> > Nous avons quelques routes OSPF que nous annonçons (+ 8000) et à
> > chaque « configure » Bird renvoie toute la table (on lui fait relire
> > un fichier de conf), du coup ça flood pas mal nos équipements (toutes
> > les minutes)..
> 
> Pourquoi tu n’apprends pas les routes depuis le kernel ?
> 
> BTW, 8k routes dans un OSPF, soit tu as un très gros réseau, mais dans ce cas 
> y’a peu de chances que tu utilises bird, soit faut passer à BGP.
> 
> --
> Alarig
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [JOBS] [FrnoG] [Jobs] Canal+ Telecom - 2 postes à pourvoir Boulogne-Billancourt

2020-01-16 Par sujet CHAMPOURET Laurent (Canal Plus) 
Bonjour la guilde,

On recherche 2 postes.

 *   Localisé à Boulogne-Billancourt
 *   Intégré dans l'équipe ingénierie internationale (environ 10 personnes)


  *   Ingénieur réseau expérimenté avec connaissance d'un FAI bout en bout
  *   Responsable ingénierie IT/DevOps et automation

Pour en savoir plus, contactez moi.

Description de CANAL+ TELECOM :
Opérateur présent sur l'ensemble des DOM fournissant à ses clients des offres 
de service Grand Public 3 Play (Accès internet, Téléphonie et IPTV) et des 
prestations de services pour les Entreprises (Accès internet, Téléphonie, 
interconnexion de site). CANAL+ TELECOM est une filiale du groupe CANAL+ 
INTERNATIONAL, groupe qui opère à l'international et à l'outremer français, et 
qui offre des bouquets payants de chaines de télévisions, des services vidéo 
innovants, ainsi qu'une offre Canal Box d'accès à internet haut débit et de 
téléphonie.

Cordialement,
Laurent CHAMPOURET
Ingénierie CANAL+TELECOM
Mobile : +33 6 50 22 43 71
laurent.champou...@canal-plus.com


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

Re: [FRnOG] [BIZ] Cogent, Grand Prix de "L'éthique ? C'est quoi ?"

2020-01-16 Par sujet Clement Cavadore 
Hello,

On Thu, 2020-01-16 at 15:32 +0100, David Ponzone wrote:
> Leur service technique leur donne le résultat des stats Netflow du
> backbone, et ils annoncent directement au prospect qu’ils lui
> envoient déjà XX Mbps/Gbps de transit, via le fournisseur N (N pour
> niqué), et que ça serait mieux de plus avoir N dans la boucle pour
> améliorer la qualité.

Ils font ca depuis de nombreuses années. 

J'ai le souvenir d'avoir eu ce genre de mauvaises expériences à $job-4
il y a plus de 10 ans, et lorsque je les ai contactés pour leur
demander de cesser, la réponse a été "ah mais pas de problèmes,
fournissez-nous la liste de vos clients et on ne les démarchera plus". 

Et puis quoi encore !?

-- 
Clément Cavadore


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

Re: [FRnOG] [BIZ] Cogent, Grand Prix de "L'éthique ? C'est quoi ?"

2020-01-16 Par sujet David Ponzone 
Vas-y, balance le cochon :)

> Le 16 janv. 2020 à 16:47, Radu-Adrian Feurdean 
>  a écrit :
> 
> On Thu, Jan 16, 2020, at 15:32, David Ponzone wrote:
>> Leur service technique leur donne le résultat des stats Netflow du backbone
> 
> Ils ne sont pas les seuls. J'ai un autre qui fait ca en tete, mais pour des 
> raison un peu differents (mais pas forcement louables).
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [BIZ] Cogent, Grand Prix de "L'éthique ? C'est quoi ?"

2020-01-16 Par sujet Alain Bieuzent 
Ça ne fait que confirmer mon non choix de cette société, merci pour l'info David

Le 16/01/2020 15:32, « David Ponzone »  a écrit :

Cogent fait encore plus fort que simplement démarcher par téléphone en 
utilisant les bases des RIR.
Leur service technique leur donne le résultat des stats Netflow du 
backbone, et ils annoncent directement au prospect qu’ils lui envoient déjà XX 
Mbps/Gbps de transit, via le fournisseur N (N pour niqué), et que ça serait 
mieux de plus avoir N dans la boucle pour améliorer la qualité.

Alors là, le Tier1 qui vient niquer ses propres clients, c’est juste 
admirable.

Je sais, c’est pas vendredi, mais si certains ici ont l’éthique comme 
critère de choix d’un transitaire, je pense que cette information est 
pertinente.


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




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

Re: [FRnOG] [BIZ] Cogent, Grand Prix de "L'éthique ? C'est quoi ?"

2020-01-16 Par sujet Alarig Le Lay 
Hello,

On jeu. 16 janv. 16:02:12 2020, Clement Cavadore wrote:
> J'ai le souvenir d'avoir eu ce genre de mauvaises expériences à $job-4
> il y a plus de 10 ans, et lorsque je les ai contactés pour leur
> demander de cesser, la réponse a été "ah mais pas de problèmes,
> fournissez-nous la liste de vos clients et on ne les démarchera plus". 
> 
> Et puis quoi encore !?

Ça devait être compliqué de regarder si ton AS était dans le path. Il
valait mieux avoir des infos sur tes clients pour être sûr de ne pas les
démarcher.

-- 
Alarig


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

Re: [FRnOG] [BIZ] Cogent, Grand Prix de "L'éthique ? C'est quoi ?"

2020-01-16 Par sujet Radu-Adrian Feurdean 
On Thu, Jan 16, 2020, at 15:32, David Ponzone wrote:
> Leur service technique leur donne le résultat des stats Netflow du backbone

Ils ne sont pas les seuls. J'ai un autre qui fait ca en tete, mais pour des 
raison un peu differents (mais pas forcement louables).


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

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

2020-01-16 Par sujet Alarig Le Lay 
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
> > To: frnog@frnog.org
> > Subject: Re: [FRnOG] [TECH] OSPF Bird et configure
> >
> > Bonsoir,
> >
> > On mer. 15 janv. 17:01:28 2020, Duchet Rémy wrote:
> > > Bonsoir la liste,
> > >
> > >
> > >
> > > S’il y a des utilisateurs de Bird sur la liste (je suis sur que oui)
> > > connaissez-vous un moyen de rajouter une route (autrement qu’en
> > > STATIC) sur le serveur Bird, pour que ce dernier l’annonce (OSPF ou
> > > BGP) sans avoir à faire un « configure » à chaque changement ?
> > >
> > > Nous avons quelques routes OSPF que nous annonçons (+ 8000) et à
> > > chaque « configure » Bird renvoie toute la table (on lui fait relire
> > > un fichier de conf), du coup ça flood pas mal nos équipements
> > > (toutes les minutes)..
> >
> > Pourquoi tu n’apprends pas les routes depuis le kernel ?
> >
> > BTW, 8k routes dans un OSPF, soit tu as un très gros réseau, mais dans ce 
> > cas y’a peu de chances que tu utilises bird, soit faut passer à BGP.
> >
> > --
> > Alarig
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> >

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

2020-01-16 Par sujet Duchet Rémy 
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
> > To: frnog@frnog.org
> > Subject: Re: [FRnOG] [TECH] OSPF Bird et configure
> >
> > Bonsoir,
> >
> > On mer. 15 janv. 17:01:28 2020, Duchet Rémy wrote:
> > > Bonsoir la liste,

[FRnOG] [BIZ] Cogent, Grand Prix de "L'éthique ? C'est quoi ?"

2020-01-16 Par sujet David Ponzone 
Cogent fait encore plus fort que simplement démarcher par téléphone en 
utilisant les bases des RIR.
Leur service technique leur donne le résultat des stats Netflow du backbone, et 
ils annoncent directement au prospect qu’ils lui envoient déjà XX Mbps/Gbps de 
transit, via le fournisseur N (N pour niqué), et que ça serait mieux de plus 
avoir N dans la boucle pour améliorer la qualité.

Alors là, le Tier1 qui vient niquer ses propres clients, c’est juste admirable.

Je sais, c’est pas vendredi, mais si certains ici ont l’éthique comme critère 
de choix d’un transitaire, je pense que cette information est pertinente.


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

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

2020-01-16 Par sujet Alarig Le Lay 
C’est mon provisionng de VMs qui pousse un /32 sur l’interface de chaque
tap (il fait un ip route add blah /32 dev tap42 onlink) et bird
l’apprend via le kernel. Je n’ai pas besoin de reconfigurer bird à
chaque fois qu’une VM démarre ou est migrée. Et du coup, ça fait bien
statique (depuis le Linux) → BGP (via bird qui l’apprend via le kernel).

On jeu. 16 janv. 17:03:23 2020, 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à

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

2020-01-16 Par sujet Duchet Rémy 
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
> To: frnog@frnog.org
> Subject: Re: [FRnOG] [TECH] OSPF Bird et configure
>
> Bonsoir,
>
> On mer. 15 janv. 17:01:28 2020, Duchet Rémy wrote:
> > Bonsoir la liste,
> >
> >
> >
> > S’il y a des utilisateurs de Bird sur la liste (je suis sur que oui)
> > connaissez-vous un moyen de rajouter une route (autrement qu’en
> > STATIC) sur le serveur Bird, pour que ce dernier l’annonce (OSPF ou
> > BGP) sans avoir à faire un « configure » à chaque changement ?
> >
> > Nous avons quelques routes OSPF que nous annonçons (+ 8000) et à
> > chaque « configure » Bird renvoie toute la table (on lui fait relire
> > un fichier de conf), du coup ça flood pas mal nos équipements
> > (toutes les minutes)..
>
> Pourquoi tu n’apprends pas les routes depuis le kernel ?
>
> BTW, 8k routes dans un OSPF, soit tu as un très gros réseau, mais dans ce cas 
> y’a peu de chances que tu utilises bird, soit faut passer à BGP.
>
> --
> Alarig
>
>
> ---
> 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] Cogent, Grand Prix de "L'éthique ? C'est quoi ?"

2020-01-16 Par sujet Radu-Adrian Feurdean 
On Thu, Jan 16, 2020, at 16:56, Kave Salamatian wrote:
> Ce serait moi je ferais une notification CNIL RGPD. Les données NetFlow 
> ou LIR n’ont pas vocation à être utilisé en dehors du domaine technique 
> (pour du marketing par exemple) et une adresse IP c est définitivement 
> une info privée :-)

Par contre les stats aggreges par AS (le seul chose dont ils ont besoin), ca 
touche pas aux infos prives.
Les contacts type admin-c@, noc@, peering@ non plus (par contre il y a les 
contacts nominatifs qui peuvent l'etre).


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

RE: [FRnOG] [BIZ] Cogent, Grand Prix de "L'éthique ? C'est quoi ?"

2020-01-16 Par sujet Michel Py 
> David Ponzone a écrit :
> ils annoncent directement au prospect qu’ils lui envoient déjà XX Mbps/Gbps 
> de transit, via le fournisseur
> N (N pour niqué), et que ça serait mieux de plus avoir N dans la boucle pour 
> améliorer la qualité.

Ah je suis rassuré maintenant, en lisant le sujet on aurait pu croire que 
Cogent avait gagné un prix d'éthique.
pfff tu m'as fait peur.

T'as l'air surpris ?

Michel.


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

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

2020-01-16 Par sujet Baptiste Jonglez 
Bonjour,

Je ne vois pas ce que le passage à Bird 2 apporte dans ce cas.  Tu veux
juste redistribuer certaines routes du kernel vers OSPF, mais il te faut
un moyen de les identifier.

Tu peux matcher sur tous les attributs génériques de routes décrits ici :

  https://bird.network.cz/?get_doc=16=bird-5.html#ss5.5 (bird 1.6)
  https://bird.network.cz/?get_doc=20=bird-5.html#ss5.5 (bird 2.0)

+ ceux du protocole kernel (faut scroller un peu) :

  https://bird.network.cz/?get_doc=16=bird-6.html#ss6.6


Le plus simple est probablement d'utiliser krt_source qui correspond au
"proto" de iproute2 (cf. /etc/iproute2/rt_protos), ça ressemble à ça :

- ajouter une route dans ton automatisation : "ip route replace XXX/X via YYY 
proto 142"
  (j'utilise "replace" au lieu de "add" pour écraser une éventuelle route
  existante, à toi de voir ce que tu préfères dans ce cas)

- importer ces routes dans le proto kernel : soit "import all" soit plus
  précis "import where krt_source = 142"

- exporter ces routes dans le proto OSPF : "export where krt_source = 142"

Si tu exportais vers BGP, ce serait une bonne idée de mettre une
communauté pour que tous tes routeurs sachent d'où vient la route, ça
ressemblerait à ça :

filter kernel_import {
if krt_source = 142 then {
bgp_community.add((ton_AS, 142));
accept;
}
reject;
}

protocol kernel {
...
import filter kernel_import;
}

filter bgp_export {
 ...
 if filter(bgp_community, [(ton_AS, 142)]).len > 0 then accept;
 reject;
}

protocol bgp {
...
export filter bgp_export;
}


On fait un truc du genre pour le blackhole, il suffit d'ajouter une route
/32 dans le kernel (avec le bon proto) pour qu'elle soit propagée en BGP à
tous les transitaires avec la communauté de blackhole qui va bien.  C'est
la même conf que Gitoyen dispo ici :

  
https://code.ffdn.org/gitoyen/bird-config/blob/master/etc/local/bird/common/bgp-filters.conf#L134

Baptiste

On 16-01-20, 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

[FRnOG] [JOBS] Weborama recherche ingé système à Levallois

2020-01-16 Par sujet Alexis Lameire 
Bonjour la liste,

Vous le savez, trouver des personnes compétentes c'est mission impossible.

Je tente donc ma chance auprès des barbus avec deux offres d'ingé
système/réseau esprit devops (ou indus, ou SRE).

On a 2 postes ouvert :
  * Un poste SRE senior, coté qualification de nouveau outils (dans mon équipe)
  * Un poste SRE intermédiaire, dans les équipes métiers (pas beaucoup
plus loin)

Les taches des deux posts sont :
  * Gestion quotidienne des bobos de l'infra
  * Troubleshooting des problèmes plus pointus
  * Évolutions de l'infra motivées par l'équipe elle même, ou par un
besoin produit

Nous n'attachons pas une attention particulière aux logiciels que vous
connaissez déjà. Même si bien sûr c'est un plus que vous sachiez
utiliser SaltStack, Terraform ou Couchbase par exemple, nous portons
en réalité notre attention sur les fondamentaux, votre bon sens fera
le reste. Ainsi vous aurez besoin:

  * D'une connaissance fine du fonctionnement de Linux (analyse de
métriques système, gestion de la mémoire, identification des
saturations, gestion des signaux)
  * D'une connaissance de base du réseau (ARP, IP, TCP)

Pourquoi demandons-nous cela, essentiellement parce que nous nous
appuyons sur nos propres connaissances et non sur une aide externe,
pour résoudre nos problèmes. Weborama prend le parti de conserver les
compétences en interne, ce qui rend le poste plus intéressant, mais
aussi plus exigeant.

En ce qui concerne l'infra, elle est répartie entre 300 serveurs
physique et 250 instances GCP, le tout constitué exclusivement de
logiciels issus de l'open source. Les principales briques que l'on va
rencontrer sont :

  * Debian
  * SaltStack
  * Consul
  * Terraform et Packer
  * KVM/Libvirt
  * Kubernetes
  * Couchbase

Vient ensuite s'ajouter une liste non exhaustive de logiciels :
HAProxy, Hadoop, ElasticSearch, ClickHouse, RabbitMQ, Kafka,
Apache/Nginx, SGE, Zabbix, Datadog, Prometheus, MariaDB...

Concernent l'entreprise, Weborama est un des leaders dans l’industrie
du marketing numérique en Europe. Présent en France, Espagne,
Portugal, Italie, Hollande, Russie et USA, c’est plus de 600 millions
d’internautes actifs mensuels que Weborama gère pour ses clients, au
travers de ses différentes plateformes.

Que se soit au travers de campagnes publicitaires distribuées via
notre ad server, notre plateforme DMP qui permet d’agréger les données
du client quelle que soit leur source, ou encore via notre
classification statistique et anonyme des centres d’intérêts des
internautes, nous gérons plus d’un milliard de hits HTTP par jour.

Si vous voulez plus de détails une fiche de poste est également
disponible sur le site:
https://weborama.com/job/ingenieur-systemes-et-reseaux/ (désolé pour
les bloqueurs de pubs qui bloquent malheureusement notre dommaine en
raison de notre secteur d'activité)

En cas de questions, n'hésitez pas à me contacter en direct.

Alexis Lameire

PS : avant que les trolls ne viennent à moi, le salaire dépendra bien
entendue du niveau d'expérience.


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

RE: [FRnOG] [TECH] Numéro de mobile à 14 chiffres

2020-01-16 Par sujet Joffrey Fontaine 
Hello, @JOB pour le M2M, l’agrume nous filait des cartes SIM 14 chiffres.
Mais il ne sont pas capable de fournir tous leurs abonnements M2M en 14 
chiffres.
Typiquement, abonnement 5Go de data possible en 14 chiffres, 20Go de data 
impossible en 14 chiffres.
Du coup depuis la semaine passée, on est revenu à des cartes en 10 chiffres 
pour faire du m2m à 20Go de traffic ☺

Joffrey

From: frnog-requ...@frnog.org  On Behalf Of Guillaume 
Genty
Sent: mercredi 15 janvier 2020 18:25
To: frnog@frnog.org
Subject: Re: [FRnOG] [TECH] Numéro de mobile à 14 chiffres

Si j'ai bonne mémoire, la date du 01/01/2020 était la date limite pour 
l'obligation, jusqu'alors les opérateurs pouvaient encore attribuer des numéros 
à 10 chiffres en M2M le temps que les réseaux soit prêts, les exploitants de 
services M2M prêts, etc... Maintenant ils n'ont plus le droit d'en attribuer à 
10 chiffres pour ces usages.

J'avais aussi lu il y a quelques temps qu'il y avait un flou autours de 
l'utilisation possible de numéros M2M pour les abonnements data-only à usage 
personnel, où du coup le numéro n'avais pas à être connude l'usager.
Par-contre à l'inverse il y a aussi des problématiques sur des interphones 
connectés où l'appel voix est émit avec un numéro à 14 chiffres vers un usager, 
où parfois les réseaux de destination n'étaient pas encore prêt et du coup les 
appels n'aboutissaient pas...

Si tu as des exemples d'usages où les abonnements sont affectés à des usagés 
avec de la voix, je pense que l'ARCEP se fera un plaisir de creuser le sujet !
Mais j'ai comme un présentiment que ce sont des revendeurs qui ont acheté du 
M2M car moins cher pour le revendre au public, sans en avoir parlé au HNO 
(l'opérateur physique).

Cordialement,


Le 15/01/2020 à 17:43, Alain Bieuzent a écrit :
> Salut David,
>
> Dans le dernier plan de numérotation publié par l'ARCEP, l'usage des numéros 
> de mobiles a longueur étendue est bien restreint au M2M ou au SMS/MMS depuis 
> le 01/01/2020 (donc ce ne devais pas être le cas avant).
>
>Les numéros mobiles de longueur étendue sont alloués sans restriction 
> pour l’ensemble du territoire désigné au paragraphe 2.3.5 a) à l’exception de 
> « la Réunion, Mayotte et autres territoires de l’Océan Indien » où existent 
> les  restrictions suivantes :
>Mayotte
>La Réunion
>Numéros (format national)
>0ZAB = 07008
>0ZAB = 07009
>
>Conditions d’utilisation
>Les numéros mobiles de longueur étendue sont affectés à 
> l’identification d’un accès mobile, par l’opérateur fournissant cet accès 
> mobile à l’utilisateur final, pour la fourniture au public de services de 
> communications   électroniques.
>À compter du 1er janvier 2020, ces numéros ne peuvent pas être 
> utilisés pour fournir un service de communications interpersonnelles, 
> précision faite qu’ils peuvent toujours être utilisés pour fournir des 
> services de  communications « machine à machine » (ou « M2M ») qui ne peuvent 
> émettre ou recevoir des appels ou messages SMS/MMS qu’en relation avec un 
> nombre restreint d’utilisateurs prédéfinis tels que :
>- le service d’appel d’urgence eCall mentionné dans la 
> décision n° 585/2014/UE du Parlement Européen et du Conseil du 15 mai 2014 ;
>- les applications auxquelles seules des machines parfaitement 
> identifiées ou des techniciens habilités sont susceptibles d’accéder 
> (interphones, communications d’ascenseurs, systèmes de téléassistances pour 
> personnesâgées, …);
>- les applications domotiques qui s’adressent spécifiquement à 
> un foyer.
>
> Alain
>
> Le 15/01/2020 16:58, « David Ponzone »  david.ponz...@gmail.com>
>  a écrit :
>
>  Est-ce que quelqu’un sait où on peut trouver une communication de 
> l’ARCEP plus récente que 2012 concernant les numéros mobile à 14 chiffres ?
>  En particulier, une communication sur ce qui est attendu de la part des 
> différents acteurs.
>  Ce qui semblait être au départ une exception indispensable (mais loin 
> d’être idéale) pour les cartes M2M (utilisées dans des machines), a 
> semble-t-il déjà été dévoyé et des acteurs vendent maintenant des flottes de 
> cartes M2M pour des mobiles utiisés par des humains;
>  J’ai du mal à comprendre l’intérêt de fournir un numéro difficile à 
> mémoriser à un humain.
>
>
>  David
>
>
>  ---
>  Liste de diffusion du FRnOG
>  http://www.frnog.org/
>
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/



[cid:image001.png@01D5CCC4.9B3F2240]


Guillaume Genty

Directeur Innovation et Expertise - Chief Innovation Officer

1 Quai Marcel Dassault, 92150 Suresnes, France


  [cid:image003.png@01D5CCC4.9B3F2240]
[cid:image004.png@01D5CCC4.9B3F2240]


Gestion de vos tickets

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

2020-01-16 Par sujet MULLER Samuel 
Hello,

Je fais en ce moment VAE pour obtenir le diplôme IRSM du CNAM (le même donc).
Une VAE c'est 2 mémoires : celui de ton expérience professionnelle, et celui du 
mémoire d'ingénieur. Puis un oral pour synthétiser de vive voix tout ça.
- Concernant les motivations de la VAE, elles restent strictement personnelles, 
qu'elles soient une reconnaissance de ses pairs, un accès à un échelon/grade 
supérieur, à une envie de changement de situation professionnelle, etc. C'est 
ça que tu dois présenter. Le "jury" veut connaître la personne derrière les 
écrits, pas un bot qui récite sa leçon.
- Le plus important dans le dossier, c'est ton argumentaire. Lorsque tu 
regroupes tes UTCS (en général, le plus simple), c'est ~60 pages d'explication 
d'expériences professionnelles autour de ce regroupement, dans une démarche 
logique (j'ai 19 UCTS à valider, ça en fait des pages ...). C'est aussi montrer 
que tu as su te remettre en cause lorsque tu as fais face à des problèmes 
techniques, managériaux, ou autres
- Le mémoire d'ingénieur, c'est identique à celui d'une formation classique. Le 
CNAM met à disposition sa librairie de mémoires (de ceux qui l'ont autorisé) si 
tu estimes nécessaire d'avoir des exemples à suivre. Aucune différence puisque 
basé généralement sur un projet professionnel, que tu as mené (pas forcément 
seul), qui reste dans le cadre du diplôme visé avec la profondeur attendue de 
ce niveau d'ingénieur (reconnu quasi-partout sur cette planète, merci). Le 
sujet doit être bien bordé sinon ça part vite dans tous les sens vu le niveau 
de détail et de technicité attendu. Mais ce n'est pas un doctorat non plus ... 

A priori du fais du Cisco/Arista chez OVH, je suis convaincu qu'il y a de la 
matière là-dedans si t'es orienté réseaux, ou encore en devops/netops appliqué 
à du hosting si t'es orienté système (compatible avec le thème précédent ^^). 
En classique : mise en place d'une archi sys/net/voip/sécu..., migration d'une 
infra quelconque, implémentation d'un nouveau protocole dans un backbone ou un 
réseau d'accès, changement de paradigme de l'OSS/BSS, suppression du modèle VPN 
pour du Zero-Trust (ouh là ça c'est "disruptif" ^^), ... y'en a des caisses (et 
sans IPv6 ;).

Enfin, le CNAM propose un.e conseiller.e, que je te recommande vivement, avec 
des ateliers individuels et en groupe, vraiment enrichissants. Un 
investissement que j'ai estimé nécessaire pour ma part.

Sam


-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
frnog@frnog.org
Envoyé : mardi 14 janvier 2020 13:24
À : frnog-misc
Objet : [FRnOG] [MISC] Re: Idée de sujet de mémoire d'ingénieur?

Hello a tous,

Merci pour toutes ces réponses. Désolé de ne répondre que maintenant, il
faut le temps de se réveiller avec 6h de décalage :p. Pour répondre à
certaines interrogations:
- Il y a un accord de reconnaissance du diplôme d'ingénieur en informatique
du CNAM avec l'ordre des ingénieurs du Québec. Donc obtenir mon diplôme
français me permets de le faire valider au Québec.
- Même si l'expérience est primordiale, dans certains environnements, un
diplôme permets d’asseoir un poste, ou de pouvoir faire la différences. Je
pense notamment à des administrations ou certains grand groupe.
- Aujourd'hui je suis chez OVH, et je n'ai pas l'intention de les quitter.
Mais il me reste encore plus de 35 ans de vie professionnelle. Ou serais-je
demain? Je ne sais pas. Donc obtenir un diplôme d'ingénieur reste
important.
- Non, je ne suis pas spécialement encadré dans cette démarche. On m'a
demander de proposer un sujet, afin de me mettre en rapport avec un
enseignant tuteur. qui m'accompagnera. Mais d'ici la, je ne sais même pas
la forme ou le type de sujet.
- Oui, c'est toujours mieux de le faire sur un projet réel, dans le cadre
du boulot. La, du coup, j'ai des idées de ce que je peux faire. Je vais
regarder pour l'appliquer au quotidien, et trouver ce sujet de mémoire.

Encore merci, je savais que j'aurais plein de bons conseils sur la liste ;)

Olivier

Le mar. 14 janv. 2020 à 05:32, Kevin CHAILLY | Service Technique <
kchai...@adeo-informatique.com> a écrit :

> >>...je suis à la recherche d'une idée de mémoire d'ingénieur. Est-ce que
> >>vous auriez des idées/pistes/propositions? Je sèche un peu, sur le type
> >>de  sujet, et la complexité pour un mémoire d'ingénieur.
> >
> >La question est bizarre. Je crains qu'aucune réponse ne puisse satisfaire
> l'intéressé.
> >
> >Etes-vous accompagné dans cette démarche : sur la recherche du sujet, sa
> formulation, la structure du document, la manière de le soutenir ?
> >
> >Le mémoire doit être adossé à un besoin entreprise, réel ou suggéré. Dans
> le cas contraire, l'intérêt du lecteur s'étiole et la motivation de
> l'auteur est pauvre.
>
> Moi j'étais parti sur "Les FAI sont-ils tous des voleurs" si personne ne
> veut faire son mémoire dessus je vous le fais en présentation pour la
> prochaine FRnOG 
>
> Kévin
>
> - Mail original -
>

Re: [FRnOG] [MISC] Bizarrerie des From sur la liste depuis aujourd'hui

2020-01-16 Par sujet On behalf of Jonathan Leroy - Inikup 
Le jeu. 16 janv. 2020 à 09:11, Benjamin Collet  a écrit :
> Sans vouloir pinailler, ēa serait possible de faire commencer par le nom
> original comme le fait NANOG (c'est plus clair dans les MUA je trouve,
> en particulier sous mutt et consorts), par exemple :
>   « Benjamin Collet via FRnOG »

+1
Et ne pas mettre l'email original dans le From, puisqu'il est déjà
dans le Reply-To. C'est assez illisible je trouve.

--
Jonathan Leroy


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