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

2017-03-07 Par sujet David Ponzone 

> ...que j'ai fait un imper….

Ah saloperie de correcteur orthographique :)


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

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

2017-03-07 Par sujet Raphael Mazelier 



On 07/03/2017 18:27, Guillaume Barrot wrote:


Pour avoir testé les deux récemment, c'est surtout de la guerre de chapelle
entre les pro Bird, et les pro Quagga.


Je ne voulais froisser personne en posant cette question (meme si je 
m'apercois que j'ai fait un imper). J'ai géré mon premier véritable AS 
avec un pII sous zebra en 2002 :)



Les deux se comportent plutôt pas mal, et je pense qu'en dehors du cas
particulier des routes servers _ où BIRD s'impose surtout par ses capacités
de filtering _ , il n'y a plus vraiment de différence de perf entre les
deux, que ce soit en temps de convergence, temps de compute, etc.
Il faut avouer que le matériel récent joue aussi beaucoup dans un lissage
des perfs.



Je serais tout de meme curieux d'avoir des benchs de temps de 
"convergence" d'une full actuellement avec les deux, meme si cela doit 
etre surtout lié à netlink.




Bird semble vraiment centré sur le routing, alors que Quagga devient plus
un gros control plane complet (y compris du proto orienté L2, genre LLDP).


True.

Pour moi les principales différences, au délà des protocoles supportés, 
et des détails techniques internes (qui me font préferer bird) sont 
l'expressivité du langage de configuration et l'utilisation massives des 
tables dans bird. Dans un cas on est limité par ce qu'il est 
prévu/possible de configurer, dans l'autre cas on est plus dans de la 
programmation.  (un peu comme cisco vs juniper, en pire)


Il me semble donc plus simple d'appréhender quagga quand on est 
débutant. Mais il me parait plus aisé d'utiliser bird pour mes 
uses-cases tordus.


Maintenant le support d'ISIS, LDP, RSVP et autre protocole un peu 
indispensable risque de faire la différence (dans un sens ou l'autre).
C'est quand meme un peu la loose qu'en 2017 on est pas une stack MPLS 
libre digne de ce nom (au moins un control plane).

Meme s'il parait que MPLS c'est mort :)


Pour reprendre un posteur régulier de la liste, qui se reconnaîtra, mais un
moment faut arrêter avec les IGP de mamie (OSPF) et prendre un vrai
protocole d'homme avec des poils quoi (IS-IS, évidemment).



Ahaha je ne sais pas qui à dit ca mais je ne peux qu'approuver :)


--
Raphael Mazelier



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

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

2017-03-07 Par sujet Vincent Bernat 
 ❦  7 mars 2017 18:48 +0100, Dominique Rousseau  :

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

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


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

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

2017-03-07 Par sujet Dominique Rousseau 
Le Fri, Mar 03, 2017 at 07:51:47PM +0100, Raphael Mazelier [r...@futomaki.net] 
a écrit:
> - pourquoi partir de quagga ? j'imagine que le code patché était
> déjà important, mais bird (et surtout le futur bird 2.0) me semble
> une bien meilleure base.

Moi j'aurais plutot demandé pourquoi forker, alors que le développement
de Quagga est encore actif ?
(avec une release en 02/2017 !)


-- 
Dominique Rousseau 
Neuronnexion, Prestataire Internet & Intranet
21 rue Frédéric Petit - 8 Amiens
tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop


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

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

2017-03-07 Par sujet Sébastien Lesimple 
:)

On 07/03/2017 18:27, Guillaume Barrot wrote:
> "- pourquoi partir de quagga ? j'imagine que le code patché était déjà
> important, mais bird (et surtout le futur bird 2.0) me semble une bien
> meilleure base."
>
> Pour avoir testé les deux récemment, c'est surtout de la guerre de chapelle
> entre les pro Bird, et les pro Quagga.
> Les deux se comportent plutôt pas mal, et je pense qu'en dehors du cas
> particulier des routes servers _ où BIRD s'impose surtout par ses capacités
> de filtering _ , il n'y a plus vraiment de différence de perf entre les
> deux, que ce soit en temps de convergence, temps de compute, etc.
> Il faut avouer que le matériel récent joue aussi beaucoup dans un lissage
> des perfs.
>
> Perso pour des petits déploiement centré sur un protocole unique, je trouve
> BIRD plus facile, et souple à utiliser (mais pas exempt de bug énorme quand
> même) avec une force particulière sur le route filtering (l'implémentation
> des "routes-maps" est extrêmement complet), alors que Quagga a un intérêt
> énorme, de par sa structure en daemon autonome, pour faire du
> multiprotocol.
> Bird semble vraiment centré sur le routing, alors que Quagga devient plus
> un gros control plane complet (y compris du proto orienté L2, genre LLDP).
> Après Quagga était loin d'être moribond, il suffit de voir le nombre de
> post/jour sur la mailing dev depuis au moins 1 an.
>
> A noter que le papy de Quagga, Zebra, a donné naissance à une boite
> commerciale (IpInfusion) qui a longtemps fournit des modules complets de
> routing (via ZebOS pour ceux qui connaissent) et qui vend un NOS complet
> (oCNOS) qui vient d'être choisi, si mes sources sont bonnes, pour remplacer
> les équipements réseaux d'un IX Européen sur base de switch Edge Core (si
> certains ont plus d'infos, d'ailleurs)
>
> Par contre, quand même, lire ça en 2017 :
> "as well as very early support for IS-IS"
>
> Pour reprendre un posteur régulier de la liste, qui se reconnaîtra, mais un
> moment faut arrêter avec les IGP de mamie (OSPF) et prendre un vrai
> protocole d'homme avec des poils quoi (IS-IS, évidemment).
>
>
> Le 3 mars 2017 à 19:51, Raphael Mazelier  a écrit :
>
>>
>>
>>
>>> C'est chouette, par contre, FRR c'est plutôt con comme acronyme pour
>>> un daemon de routage. J'imagine même pas les résultats d'une recherche
>>> "frr bgp" par exemple...
>>>
>>>
>> C'est définitivement une excellente nouvelle de voir un projet de routage
>> libre renaître de ces cendres. Les nouveautés sont tellement attendues
>> (LDP, add-path, ISIS). On pourra peut être prétendre un jour avoir une
>> pseudo stack MPLS.
>>
>>
>> Deux questions toutefois :
>>
>> - pourquoi FRR ? à part jeu de mot c'est effectivement confusant :)
>> - pourquoi partir de quagga ? j'imagine que le code patché était déjà
>> important, mais bird (et surtout le futur bird 2.0) me semble une bien
>> meilleure base.
>>
>> --
>> Raphael Mazelier
>>
>>
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
>


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

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

2017-03-07 Par sujet Guillaume Barrot 
"- pourquoi partir de quagga ? j'imagine que le code patché était déjà
important, mais bird (et surtout le futur bird 2.0) me semble une bien
meilleure base."

Pour avoir testé les deux récemment, c'est surtout de la guerre de chapelle
entre les pro Bird, et les pro Quagga.
Les deux se comportent plutôt pas mal, et je pense qu'en dehors du cas
particulier des routes servers _ où BIRD s'impose surtout par ses capacités
de filtering _ , il n'y a plus vraiment de différence de perf entre les
deux, que ce soit en temps de convergence, temps de compute, etc.
Il faut avouer que le matériel récent joue aussi beaucoup dans un lissage
des perfs.

Perso pour des petits déploiement centré sur un protocole unique, je trouve
BIRD plus facile, et souple à utiliser (mais pas exempt de bug énorme quand
même) avec une force particulière sur le route filtering (l'implémentation
des "routes-maps" est extrêmement complet), alors que Quagga a un intérêt
énorme, de par sa structure en daemon autonome, pour faire du
multiprotocol.
Bird semble vraiment centré sur le routing, alors que Quagga devient plus
un gros control plane complet (y compris du proto orienté L2, genre LLDP).
Après Quagga était loin d'être moribond, il suffit de voir le nombre de
post/jour sur la mailing dev depuis au moins 1 an.

A noter que le papy de Quagga, Zebra, a donné naissance à une boite
commerciale (IpInfusion) qui a longtemps fournit des modules complets de
routing (via ZebOS pour ceux qui connaissent) et qui vend un NOS complet
(oCNOS) qui vient d'être choisi, si mes sources sont bonnes, pour remplacer
les équipements réseaux d'un IX Européen sur base de switch Edge Core (si
certains ont plus d'infos, d'ailleurs)

Par contre, quand même, lire ça en 2017 :
"as well as very early support for IS-IS"

Pour reprendre un posteur régulier de la liste, qui se reconnaîtra, mais un
moment faut arrêter avec les IGP de mamie (OSPF) et prendre un vrai
protocole d'homme avec des poils quoi (IS-IS, évidemment).


Le 3 mars 2017 à 19:51, Raphael Mazelier  a écrit :

>
>
>
>
>> C'est chouette, par contre, FRR c'est plutôt con comme acronyme pour
>> un daemon de routage. J'imagine même pas les résultats d'une recherche
>> "frr bgp" par exemple...
>>
>>
> C'est définitivement une excellente nouvelle de voir un projet de routage
> libre renaître de ces cendres. Les nouveautés sont tellement attendues
> (LDP, add-path, ISIS). On pourra peut être prétendre un jour avoir une
> pseudo stack MPLS.
>
>
> Deux questions toutefois :
>
> - pourquoi FRR ? à part jeu de mot c'est effectivement confusant :)
> - pourquoi partir de quagga ? j'imagine que le code patché était déjà
> important, mais bird (et surtout le futur bird 2.0) me semble une bien
> meilleure base.
>
> --
> Raphael Mazelier
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement,

Guillaume BARROT

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

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

2017-03-07 Par sujet Guillaume Barrot 
La page originale doit dater d'au moins 2005-2006

https://www.freebsd.org/doc/en/articles/filtering-bridges/article.html

Testée en 2008, sur un mini PC à la con, ça marche.
Donc avec un petit boitier récent, genre Supermicro E300-8D
 (2 x
10G), ça doit le faire sur tous les débits jusqu'à 10G.

Le 6 mars 2017 à 11:58, David Neto  a écrit :

> Hello la liste,
>
> Merci pour vos retours.
>
> J'avais déjà TC et Wanem en tête mais à présent, d'autres méritent d'être
> testé.
>
> @+ et bonne journée.
>
>
>
> Le 6 mars 2017 à 09:59, CapsLock  a écrit :
>
> > On 05/03/2017 16:02, Dimitri Dim wrote:
> > > Peut-être plus compliqué à mettre en oeuvre mais il y a "Toffee-mocha"
> (
> > > http://www.the-toffee-project.org/index.php?page=87-test-
> > cases-test-results-toffee-mocha-1-0-32-asymmetric-
> > constant-packet-delay-feature
> > > )
> > >
> > > Le 2 mars 2017 à 18:13, David Neto  a écrit :
> > >
> > >> Salut la liste,
> > >>
> > >> J'ai un sujet actuel sur lequel je trouve plein d'outils, appliances
> ou
> > >> projets opensource et j'aimerais avoir vos avis.
> > >>
> > >> L'idée est de pouvoir simuler la latence induite par un déménagement
> de
> > >> serveurs de plusieurs pays d’Europe vers Paris.
> > >>
> > >> Je ne peux pas mettre de boitier en coupure physique des serveurs pour
> > >> simuler cette latence.
> > >>
> > >> L'idéal serait d'avoir un agent à utiliser sur les serveurs à tester
> > >> (exécutable, binaire, tool à installer, ... qui permette de faire
> > varier la
> > >> latence des paquets)
> > >>
> > >> Merci de votre aide.
> >
> > Un petit coup de tc¹ sinon ?
> >
> >
> > ¹ https://linux.die.net/man/8/tc
> >
> >
>
>
> --
> *David NETO*
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement,

Guillaume BARROT

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

Re: [FRnOG] [TECH] Utilisation chambres orange sur domaine privé

2017-03-07 Par sujet Josselin Lecocq 

Bonjour,

> Bref, pas si simple que ça en a l'air.

Dans la pratique, je doute fort qu'Orange (ou ses sous-traitants), lors 
d'un contrôle terrain, aille jusqu'à vérifier dans ses archives si les 
infrastructures en domaine privé sont sa propriété ou non. Dans de 
nombreux cas, ils doivent même l'ignorer.


Et ça donnerait lieu à tellement de conflits interminables qu'il leur 
est sans doute plus simple d'ignorer les déploiements de FON en domaine 
privé.


En tous cas, sur les campus universitaires, ça fait bien longtemps que 
les universités et écoles se sont appropriées les fourreaux PTT / FT 
pour le passage de leurs propres câbles optiques. Et à priori, ça ne 
pose problème à personne.



Josselin Lecocq
Quantic Telecom


Le 07/03/2017 à 15:11, Alexandre Archambault a écrit :

Le 07/03/2017 à 13:17, David Ponzone a écrit :

Petite question simple pour nos experts du tirage de FON: sur un site où il y a 
une chambre de tirage principal (avec un sigle PTT sur la plaque), et des 
sous-chambres, chacune desservant un bâtiment, peut-on librement utiliser ces 
chambres et les fourreaux pour tirer de la FON entre les bâtiments ?


Petite question : les infras en question ont été posées en quelle année
? Avant ou après 1973 ?

Car avant 1973, tout ce qui a été posé par l'Administration, y compris
sur domaine privé, lui revient (cf. arrêt Lescot du Conseil d'Etat en
date du 1er mars 1967, l'accessoire suit le principal, et donc pas de
prescription acquisitive pour les infras d'accueil & cables établis en
domaine privatif).

Après 1973, le racco privatif (y compris les infras d'accueil) est
transféré à la charge des proprios, qui étaient tenus de souscrire un
contrat d'entretien. Dans pas mal de cas l'Administration puis FT a
dealé l'entretien gratos contre une retrocession des infras.

Pour ce qui est du domaine public, le déclassement ayant eu lieu à l'été
1996, dans le meilleur des cas la prescription acquisitive sur les
infras sur domaine privatif transférées à FT^h^h^h^pardon Orange ne peut
jouer qu'à partir de 2026.

Bref, pas si simple que ça en a l'air.





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

Re: [FRnOG] [TECH] Utilisation chambres orange sur domaine privé

2017-03-07 Par sujet David Ponzone 
Alec,

Est-ce que tu peux aussi expliquer le dernier paragraphe, parce que je ne 
comprends pas le rapport avec le domaine public.
C’est ce qui est passé du privé au public (après 73) et qui pourra revenir dans 
le privé ? Pas avant 2026 ?

Merci!


> Le 7 mars 2017 à 15:11, Alexandre Archambault  a écrit :
> 
> Le 07/03/2017 à 13:17, David Ponzone a écrit :
>> Petite question simple pour nos experts du tirage de FON: sur un site où il 
>> y a une chambre de tirage principal (avec un sigle PTT sur la plaque), et 
>> des sous-chambres, chacune desservant un bâtiment, peut-on librement 
>> utiliser ces chambres et les fourreaux pour tirer de la FON entre les 
>> bâtiments ?
> 
> Petite question : les infras en question ont été posées en quelle année
> ? Avant ou après 1973 ?
> 
> Car avant 1973, tout ce qui a été posé par l'Administration, y compris
> sur domaine privé, lui revient (cf. arrêt Lescot du Conseil d'Etat en
> date du 1er mars 1967, l'accessoire suit le principal, et donc pas de
> prescription acquisitive pour les infras d'accueil & cables établis en
> domaine privatif).
> 
> Après 1973, le racco privatif (y compris les infras d'accueil) est
> transféré à la charge des proprios, qui étaient tenus de souscrire un
> contrat d'entretien. Dans pas mal de cas l'Administration puis FT a
> dealé l'entretien gratos contre une retrocession des infras.
> 
> Pour ce qui est du domaine public, le déclassement ayant eu lieu à l'été
> 1996, dans le meilleur des cas la prescription acquisitive sur les
> infras sur domaine privatif transférées à FT^h^h^h^pardon Orange ne peut
> jouer qu'à partir de 2026.
> 
> Bref, pas si simple que ça en a l'air.
> 
> 
> -- 
> Alec,
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Utilisation chambres orange sur domaine privé

2017-03-07 Par sujet David Ponzone 
Ah j’avais oublié l’expert juridique :)

Bon, c’est une belle galère quoi, et j’imagine qu’il n’y a pas de moyen de 
savoir dans quel cas on est. 
Donc concrètement, on squatte et on croise les doigts :)

> Le 7 mars 2017 à 15:11, Alexandre Archambault  a écrit :
> 
> Le 07/03/2017 à 13:17, David Ponzone a écrit :
>> Petite question simple pour nos experts du tirage de FON: sur un site où il 
>> y a une chambre de tirage principal (avec un sigle PTT sur la plaque), et 
>> des sous-chambres, chacune desservant un bâtiment, peut-on librement 
>> utiliser ces chambres et les fourreaux pour tirer de la FON entre les 
>> bâtiments ?
> 
> Petite question : les infras en question ont été posées en quelle année
> ? Avant ou après 1973 ?
> 
> Car avant 1973, tout ce qui a été posé par l'Administration, y compris
> sur domaine privé, lui revient (cf. arrêt Lescot du Conseil d'Etat en
> date du 1er mars 1967, l'accessoire suit le principal, et donc pas de
> prescription acquisitive pour les infras d'accueil & cables établis en
> domaine privatif).
> 
> Après 1973, le racco privatif (y compris les infras d'accueil) est
> transféré à la charge des proprios, qui étaient tenus de souscrire un
> contrat d'entretien. Dans pas mal de cas l'Administration puis FT a
> dealé l'entretien gratos contre une retrocession des infras.
> 
> Pour ce qui est du domaine public, le déclassement ayant eu lieu à l'été
> 1996, dans le meilleur des cas la prescription acquisitive sur les
> infras sur domaine privatif transférées à FT^h^h^h^pardon Orange ne peut
> jouer qu'à partir de 2026.
> 
> Bref, pas si simple que ça en a l'air.
> 
> 
> -- 
> Alec,
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Utilisation chambres orange sur domaine privé

2017-03-07 Par sujet Alexandre Archambault 
Le 07/03/2017 à 13:17, David Ponzone a écrit :
> Petite question simple pour nos experts du tirage de FON: sur un site où il y 
> a une chambre de tirage principal (avec un sigle PTT sur la plaque), et des 
> sous-chambres, chacune desservant un bâtiment, peut-on librement utiliser ces 
> chambres et les fourreaux pour tirer de la FON entre les bâtiments ?

Petite question : les infras en question ont été posées en quelle année
? Avant ou après 1973 ?

Car avant 1973, tout ce qui a été posé par l'Administration, y compris
sur domaine privé, lui revient (cf. arrêt Lescot du Conseil d'Etat en
date du 1er mars 1967, l'accessoire suit le principal, et donc pas de
prescription acquisitive pour les infras d'accueil & cables établis en
domaine privatif).

Après 1973, le racco privatif (y compris les infras d'accueil) est
transféré à la charge des proprios, qui étaient tenus de souscrire un
contrat d'entretien. Dans pas mal de cas l'Administration puis FT a
dealé l'entretien gratos contre une retrocession des infras.

Pour ce qui est du domaine public, le déclassement ayant eu lieu à l'été
1996, dans le meilleur des cas la prescription acquisitive sur les
infras sur domaine privatif transférées à FT^h^h^h^pardon Orange ne peut
jouer qu'à partir de 2026.

Bref, pas si simple que ça en a l'air.


-- 
Alec,


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

Re: [FRnOG] [TECH] Utilisation chambres orange sur domaine privé

2017-03-07 Par sujet David Ponzone 
Merci à tous les 2 pour cette clarification


> Le 7 mars 2017 à 14:30, Sébastien Lesimple  
> a écrit :
> 
> C'est cela, et ca vaut aussi pour l'adduction, qui appartiens au
> propriétaire du bâtiment.
> Voilà, je crois qu'il n'y a rien a rajouter.
> 
> On 07/03/2017 13:43, Ducassou Laurent wrote:
>> Zone privé, domaine privé...
>> 
>> En cas de désaturation avec fourreau cassé en domaine privé Orange
>> laisse ça à la charge du proprio du terrain/bâtiment. Chez nous la
>> politique est :
>> - Voie publique : iBLO RCA
>> 
>> - Domaine Cadastrale Privé : On est chez nous...
>> 
>> 
>> Le 07/03/2017 à 13:17, David Ponzone a écrit :
>>> Petite question simple pour nos experts du tirage de FON: sur un site
>>> où il y a une chambre de tirage principal (avec un sigle PTT sur la
>>> plaque), et des sous-chambres, chacune desservant un bâtiment,
>>> peut-on librement utiliser ces chambres et les fourreaux pour tirer
>>> de la FON entre les bâtiments ?
>>> 
>>> 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/

Re: [FRnOG] [TECH] Utilisation chambres orange sur domaine privé

2017-03-07 Par sujet Sébastien Lesimple 
C'est cela, et ca vaut aussi pour l'adduction, qui appartiens au
propriétaire du bâtiment.
Voilà, je crois qu'il n'y a rien a rajouter.

On 07/03/2017 13:43, Ducassou Laurent wrote:
> Zone privé, domaine privé...
>
> En cas de désaturation avec fourreau cassé en domaine privé Orange
> laisse ça à la charge du proprio du terrain/bâtiment. Chez nous la
> politique est :
> - Voie publique : iBLO RCA
>
> - Domaine Cadastrale Privé : On est chez nous...
>
>
> Le 07/03/2017 à 13:17, David Ponzone a écrit :
>> Petite question simple pour nos experts du tirage de FON: sur un site
>> où il y a une chambre de tirage principal (avec un sigle PTT sur la
>> plaque), et des sous-chambres, chacune desservant un bâtiment,
>> peut-on librement utiliser ces chambres et les fourreaux pour tirer
>> de la FON entre les bâtiments ?
>>
>> 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/

RE: [FRnOG] [TECH] Passage en domaine et licence microsoft Windows

2017-03-07 Par sujet Joël DEREFINKO 
Pour répondre à la question précédente, à ma connaissance non, les CAL des 
serveurs "non-DC" ne peuvent pas être prises en comptes comme CAL d'accès au 
domaine.
Sauf erreur, ces serveurs étant des serveurs applicatifs, leurs CAL sont 
"réservées" pour l'accès applicatif si d'aventure il était édité par MS.

Joël

-Message d'origine-
De : Duchet Rémy [mailto:r...@duchet.eu] 
Envoyé : lundi 6 mars 2017 20:33
À : Nathan TUTARD ; Joël DEREFINKO 
; Stéphane Karges 
Cc : frnog-t...@frnog.org
Objet : RE: [FRnOG] [TECH] Passage en domaine et licence microsoft Windows

Le nombre de CAL est indiqué sur les licences, ou a défaut sur le contrat Open .
Pour ouvrir un contrat Open, il faut minimum 5 articles, d’où, bien souvent,  1 
licence serveur + 5 CAL. Mais ce n'est pas une règle fixe.
Concernant Exchange , SQL et les autres produit, cela dépends des 
fonctionnalités pour chacun).
Il existe une licence SQL qui permet, par exemple, un nombre illimité 
d'utilisateur.  


-Message d'origine-
De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de 
Nathan TUTARD
Envoyé : lundi, 6 mars 2017 18:43
À : Joël DEREFINKO ; Stéphane Karges 

Cc : frnog-t...@frnog.org
Objet : Re: [FRnOG] [TECH] Passage en domaine et licence microsoft Windows

Merci à tous pour vos réponses. En les CALs n'ont pas été achetées en même 
temps que les DCs... du coup je me retrouve avec 4 DC 2012 server donc 20 CALs 
d'après ce que vous me dites. Donc il va falloir que je commande des CALs en 
plus.

Du coup si j'ai admettons 2 serveurs d'applications sous windows server 2012, 
leurs CALs comptent aussi ? Je précise que ces derniers ne sont pas DC.

Merci pour vos réponses!


Le 06/03/2017 à 18:31, Joël DEREFINKO a écrit :
> Bonjour,
>
> En gros, il faut, au-delà des licences Windows Server
> - X CAL pour les utilisateur : X = nombre d'utilisateurs moins les CAL 
> incluses dans la licence Windows, 5 de mémoire; Si tu as 2 DC, tu as 
> 10 CAL
>
> Et par la suite
> - X CAL Exchange (une par utilisateur humain ayant une boite). Pas de CAL 
> pour les boites génériques par exemple.
> - Y CAL SQL Server : attention, seulement si les utilisateurs se connectent 
> en direct à la BDD : si tu branche un site web sur le SQL Server, une seule 
> CAL est nécessaire.
>
> Evidemment il a va de meme pour "le reste" (sharepoint, etc...)
>
> Joël
>
> -Message d'origine-
> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la 
> part de Stéphane Karges Envoyé : lundi 6 mars 2017 17:43 À : Nathan 
> TUTARD  Cc : frnog-t...@frnog.org Objet : Re: 
> [FRnOG] [TECH] Passage en domaine et licence microsoft Windows
>
> hello,
>
> après ca depends du package que tu as tu a certain serveur qui on deja un 
> nombre de CAL.
>
> Stéphane
>> Le 6 mars 2017 à 17:06, Nathan TUTARD  a écrit :
>>
>> Salut la liste,
>>
>> J'ai un gros doute et ne trouvant pas de détails explicite sur ma 
>> demande, je la poste ici.
>>
>> J'ai un passage en domaine de prévu dans mon entreprise cependant il 
>> n'a pas été prévu de licence associées à ce passage en domaine. De 
>> mémoire, il fallait des CAL de mise en domaine par PC ou 
>> utilisateurs. Mon collègue me soutient que non aucune licence n'est 
>> nécessaire.
>>
>> Quelqu'un peut-il me confirmer ou infirmer les dires de mon collègues?
>> Par la même occasion où achetez vous les CAL pour vos entreprises?
>>
>>
>> Merci d'avance,
>>
>> Nathan
>>
>>
>> ---
>> 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] Utilisation chambres orange sur domaine privé

2017-03-07 Par sujet Ducassou Laurent 

Zone privé, domaine privé...

En cas de désaturation avec fourreau cassé en domaine privé Orange 
laisse ça à la charge du proprio du terrain/bâtiment. Chez nous la 
politique est :

- Voie publique : iBLO RCA

- Domaine Cadastrale Privé : On est chez nous...


Le 07/03/2017 à 13:17, David Ponzone a écrit :

Petite question simple pour nos experts du tirage de FON: sur un site où il y a 
une chambre de tirage principal (avec un sigle PTT sur la plaque), et des 
sous-chambres, chacune desservant un bâtiment, peut-on librement utiliser ces 
chambres et les fourreaux pour tirer de la FON entre les bâtiments ?

Merci!


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



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

[FRnOG] [TECH] Utilisation chambres orange sur domaine privé

2017-03-07 Par sujet David Ponzone 
Petite question simple pour nos experts du tirage de FON: sur un site où il y a 
une chambre de tirage principal (avec un sigle PTT sur la plaque), et des 
sous-chambres, chacune desservant un bâtiment, peut-on librement utiliser ces 
chambres et les fourreaux pour tirer de la FON entre les bâtiments ?

Merci!


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

Re: [FRnOG] [TECH] Comment interroger zen.spamhaus.org (et autres RBL) correctement.

2017-03-07 Par sujet Landry Minoza 
Si tu ne veux pas faire de ton résolveur un résolveur récursif complet, tu
as toujours la possibilité de créer une « stub zone » pour zen.spamhaus.net,
ce qui t’évitera de transmettre les requêtes à ton FAI, Google, OpenDNS…
tout en limitant la maintenance nécessaire pour « suivre » les NS de
SpamHaus.
De plus, si ta machine filtrante est sous Unix, tu peux « rapprocher » et
spécialiser un cache DNS pour elle et éviter de pourrir celui de ton
serveur MS en installant un Unbound local avec une forward-zone vers ton
serveur résolveur DNS central pour le "." et des stub-zone pour les DNSBL.

2017-03-06 22:04 GMT+01:00 Michel Py :

> >> Michel Py a écrit :
> >> Comme je doutais un peu des services to mon forwarder DNS, j'ai mis un
> >> forwarder conditionnel pour zen.spamhaus.org et çà aide mais pourtant
> >> il y en a encore un peu qui passe au travers des mailles du filet.
>
> > Willy MANGA a écrit :
> > Pas possible/souhaitable d'avoir un résolveur correct en interne qui
> ferait lui même ce travail au lieu de passer par un forwarder ?
>
> C'est Microsoft DNS; impossible de changer pour un tas de raisons
> politiques. Se passer d'un forwarder çà rend tout très lent, en plus j'en
> entends hurler ce aller directement sur les root-servers c'est pas une
> bonne idée. Comme forwarder j'ai essayé ceux de mon FAI, le public de
> Google et OpenDNS, pas vraiment concluant en ce qui concerne le spam qui
> passe au travers.
>
> Donc en ce moment j'utilise OpenDNS comme forwarder, et 4 des serveurs de
> Spamhaus comme forwarder pour la zone zen.spamhaus.net.
> Si quelqu'un a une meilleure idée...
>
> Michel.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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