Re: [FRnOG] [TECH] Questions Nexus 3000

[Frédéric GANDER]

> VTP sérieusement ? je n'envisage même pas que l'on puisse utiliser
> cela
> en prod; cela c'est toujours terminé en désastre par chez moi.
>

+

c'est une aberration d'activer ca par défaut en dehors du context entreprise 
voir pme et encore...
sur un catalyst c'est la première chose à déactiver


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

RE: [FRnOG] [MISC] Questions Nexus 3000

[Michel Py]

>> Michel Py a écrit :
>> mais j'ai pas le choix, impossible de changer le réseau de prod.
> Guillaume Barrot a écrit :
> Mets y le feu et touche l'assurance, ca sera plus rentable !

T'es pas le premier à y penser, mais le problème c'est qu'il faut plusieurs 
années pour refaire un site, donc le résultat des courses c'est que çà ferme, 
les investisseurs et les créanciers se disputent le pognon de l'assurance, que 
je cherche du taf, et que en plus les 500 collègues qui sont partis dans la 
même charrette se cotisent pour que je meure lentement et dans la douleur... 
Pas glop.

Michel.


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

Re: [FRnOG] [TECH] Questions Nexus 3000

[Guillaume Barrot]

Le jeu. 6 juil. 2017 à 22:49, Michel Py 
a écrit :

> mais j'ai pas le choix, impossible de changer le réseau de prod.
>
Mets y le feu et touche l'assurance, ca sera plus rentable !
-- 
Cordialement,

Guillaume BARROT

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

Re: [FRnOG] [TECH] C2E en carafe ce jour - qui a été touché ?

[Sylvain Vallerot]

On Thu, Jul 06, 2017 at 07:42:47PM +0200, Rudy G. wrote:
> Quel type d'impact ? aucune déconnexion dans notre parc cet après-midi, et
> rien de particulier sur la supervision non plus.

Genre coupures erratiques mais longues (dizaines de minutes à chaque fois)
toute l'après-midi, sur 12 des 13 agences à la fois. 1h47 de panne cumulées
sur la quasi totalité des VPN clients. Retour "magique" du service (pas de 
reset, pas de reboot) à chaque fois, donc un souci clairement quelque part
"au milieu".

L'an dernier on a eu droit à une saturation de la porte de collecte (même
pseudo-opérateur), c'était pas des coupures franches pareil, plutôt des
pertes et des latences aléatoires, il a fallu une quinzaine (à la louche) 
pour un retour à la normale.


> Ou qui indique que le défaut a disparu comme par magie juste avant qu'ils 
> cherchent à le localiser...

Bah de toutes façons ils ont pas de logs alors c'est rare qu'ils cherchent,
en général on nous remonte une probable maintenance chez Orange, jamais
vérifiée, jamais confirmée.

Bon, j'arrête, on est en TECH.

Mais je crois que la prochaine saison de Fargo va porter sur cet opérateur.

Merci pour les retours en tous cas, il semble bien que C2E ne soit pas
vraiment à blâmer pour les dégâts qu'on a subis aujourd'hui.

Bonne soirée,
S. Vallerot


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

RE: [FRnOG] [TECH] Questions Nexus 3000

[Michel Py]

> Raphael Mazelier a écrit :
> VTP sérieusement ? je n'envisage même pas que l'on puisse utiliser
> cela en prod; cela c'est toujours terminé en désastre par chez moi.

Jamais eu d'emmerdes à part les débuts de CatOS les bons vieux jours du 5500. 
Bon faut être 100% Cisco mais c'est mon cas.

> Non franchement l'automatisation des équipements réseaux ce n'est plus 
> optionnel.

Bah j'ai un petit réseau, quelques centaines de switches, principalement IOS 
mais encore du CatOS qui traine sur du 6500 / SUP1. VTP et PVST+ je sais que 
tout le monde dit que c'est de la daube mais j'ai pas le choix, impossible de 
changer le réseau de prod.

Michel.


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

Re: [FRnOG] [TECH] Questions Nexus 3000

[Erik Linder]

bonsoir

qq'un aurait un retour d'expérience sur les tests de perf sflow sur ces
N3k?

erik

2017-07-06 21:03 GMT+04:00 Guillaume Barrot :

> Pour ton probleme de vtp : Ansible.
> Pour l'autocommand : Ansible
>
> Pour le 40G sur cartes Intel : XL710 à la place de X710, ça devrait mieux
> marcher.
> Sinon, Mellanox, très bien aussi.
>
> Attention aux optiques en 40G, c'est chatouilleux.
> Pour du short range, le twinax, attention aux compatibilités actifs/passifs
> ... sinon c'est ... marrant :D
>
> Le 5 juillet 2017 à 22:48, Michel Py 
> a
> écrit :
>
> > Bonjour la liste,
> >
> > Je viens d'avoir des Nexus N3K-C3064PQ (pour pas cher, un peu plus de $1K
> > pièce).
> >
> > Il y a 2 trucs qui me gratouillent :
> >
> > - Pas de VTP client ou serveur (mode transparent seulement). Je trouve
> que
> > çà craint un peu, mais apparemment c'est sans espoir, est-ce que
> quelqu'un
> > a une meilleure idée que :
> > vlan 2
> > name toto
> > vlan 3
> > name tata
> >
> > - Pas de "autocommand"
> > user toto autocommand tclsh bootflash:toto.tcl <-- nope.
> >
> > Des idées ?
> >
> > Question bête : est-ce qu'il y a des problèmes particuliers avec le mode
> > 40G natif ?
> > (du genre les cartes Intel X710-QDA2 avec un stepping inférieur à B0 qui
> > marchent à 4x10G mais pas à 1x40G) ?
> > hardware profile portmode 48x10G+4x40G
> > Eth1/49 -- sfpAbsent 1 full 40G --
> > Eth1/50 -- sfpAbsent trunk full 40G --
> > Eth1/51 -- sfpAbsent 1 full 40G --
> > Eth1/52 -- sfpAbsent trunk full 40G --
> > Cà a l'air de marcher mais j'attends mes DAC du vendeurs d'optiques à 2
> > lettres.
> >
> > Michel.
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
>
>
> --
> Cordialement,
>
> Guillaume BARROT
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Questions Nexus 3000

[Raphael Mazelier]

On 06/07/2017 21:23, Michel Py wrote:



C'est pas un peu usine à gaz sur les bords pour remplacer deux commandes qui 
marchaient depuis la nuit des temps en IOS et que Cisco a pas jugé bon 
d'implémenter en NXOS ?



VTP sérieusement ? je n'envisage même pas que l'on puisse utiliser cela 
en prod; cela c'est toujours terminé en désastre par chez moi.


Non franchement l'automatisation des équipements réseaux ce n'est plus 
optionnel. En revanche ce qui est plus discutable c'est l'implémentation.


Sur les différentes gamme de nexus c'est assez disparate. (pour ne pas 
dire plus). Arista, Juniper et autre nouveau NOS sont bien plus avancé 
sur le sujet.


--
Raphael Mazelier


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

RE: [FRnOG] [TECH] Questions Nexus 3000

[Michel Py]

> Guillaume Barrot a écrit :
> Pour ton probleme de vtp : Ansible.
> Pour l'autocommand : Ansible

C'est pas un peu usine à gaz sur les bords pour remplacer deux commandes qui 
marchaient depuis la nuit des temps en IOS et que Cisco a pas jugé bon 
d'implémenter en NXOS ?

> Pour le 40G sur cartes Intel : XL710 à la place de X710, ça devrait mieux 
> marcher.

C'est ce que je voulais écrire. En dessous du stepping B0 j'ai eu des problèmes.

Michel.


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

RE: [FRnOG] [TECH] Fortinet et son WIFI legacy....

[Michel Py]

> Toussaint OTTAVI a écrit :
> Donc, de mon coté, je mets des firewalls qui font juste firewall. Et des AP 
> qui font juste AP, sur une patte
>  dédiée du FW (soit des AP pas chers pour les petites installs, soit des gros 
> avec un contrôleur dédié pour 
> les installs plus conséquentes). Bien évidemment, les AP sont en hauteur et 
> loin de tout autre équipement.

+1 à éviter les machins "tout-en-un".

Michel.

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

Re: [FRnOG] [TECH] C2E en carafe ce jour - qui a été touché ?

[Rudy G.]

- Mail original -
> De: "Sylvain Vallerot" 
> À: "Liste FRnoG" 
> Envoyé: Jeudi 6 Juillet 2017 16:25:35
> Objet: [FRnOG][TECH] C2E en carafe ce jour - qui a été touché ?

> Bonjour à tous,

Bonsoir,
 
> J'ai un gros client qui a été fortement impacté quasi tout le début
> d'après-midi sur ses liaisons d'agences,
> 
> le fournisseur des SDSL et fibres a imputé la faute sur la collecte C2E,
> 
> mais je m'étonne n'avoir rien vu sur le sujet ici, personne n'a rien vu ?

Quel type d'impact ? aucune déconnexion dans notre parc cet après-midi, et rien 
de particulier sur la supervision non plus.
 
> J'essaie de comprendre à quel régime de pseudo-transparence on est
> mangés par ledit fournisseur... le genre de fournisseur qui m'affirme
> avoir résolu des incidents par un reset de DSLAM une heure après que
> j'ai rebooté le routeur fibre !

Ou qui indique que le défaut a disparu comme par magie juste avant qu'ils 
cherchent à le localiser...
 
> Merci d'avance pour vos retours.
> 
> Bonne journée FRnog !
> Sylvain

Bonne soirée !

Rudy


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

Re: [FRnOG] [TECH] Questions Nexus 3000

[Guillaume Barrot]

Pour ton probleme de vtp : Ansible.
Pour l'autocommand : Ansible

Pour le 40G sur cartes Intel : XL710 à la place de X710, ça devrait mieux
marcher.
Sinon, Mellanox, très bien aussi.

Attention aux optiques en 40G, c'est chatouilleux.
Pour du short range, le twinax, attention aux compatibilités actifs/passifs
... sinon c'est ... marrant :D

Le 5 juillet 2017 à 22:48, Michel Py  a
écrit :

> Bonjour la liste,
>
> Je viens d'avoir des Nexus N3K-C3064PQ (pour pas cher, un peu plus de $1K
> pièce).
>
> Il y a 2 trucs qui me gratouillent :
>
> - Pas de VTP client ou serveur (mode transparent seulement). Je trouve que
> çà craint un peu, mais apparemment c'est sans espoir, est-ce que quelqu'un
> a une meilleure idée que :
> vlan 2
> name toto
> vlan 3
> name tata
>
> - Pas de "autocommand"
> user toto autocommand tclsh bootflash:toto.tcl <-- nope.
>
> Des idées ?
>
> Question bête : est-ce qu'il y a des problèmes particuliers avec le mode
> 40G natif ?
> (du genre les cartes Intel X710-QDA2 avec un stepping inférieur à B0 qui
> marchent à 4x10G mais pas à 1x40G) ?
> hardware profile portmode 48x10G+4x40G
> Eth1/49 -- sfpAbsent 1 full 40G --
> Eth1/50 -- sfpAbsent trunk full 40G --
> Eth1/51 -- sfpAbsent 1 full 40G --
> Eth1/52 -- sfpAbsent trunk full 40G --
> Cà a l'air de marcher mais j'attends mes DAC du vendeurs d'optiques à 2
> lettres.
>
> Michel.
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement,

Guillaume BARROT

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

Re: [FRnOG] [TECH] Fortinet et son WIFI legacy....

[Guillaume Barrot]

Techniquement, depuis plusieurs génération déjà, le low end Fortinet est en
SOC, donc pas d'ASIC.
Les premiers ASICs arrivent en général sur les modèles "centaines" (100D,
100E, etc..) mais tout ça se verifie dans leurs docs.

Idem, la regle "ça c'est géré par le CPU" est pas forcément valable pour
toute la gamme.
A partir du middle end, ils ajoutent un FPGA pour décharger du traitement
L7 par exemple.

Bref, faut se taper les docs pour savoir...

Le 6 juillet 2017 à 14:05, Abonnements Incal  a écrit :

> Par expérience sur les modèles FWF, j'ai pu constater quelques
> "incohérences" dans la config par défaut de la partie WIFI. En effet, ces
> modèles (FortiWIFI) intègrent la partie WIFI via un "Software Switch" (seul
> mode possible pour la gestion du WIFI interne) et est donc supporté par le
> CPU uniquement et non par l'ASIC. Malheureusement le CPU est là avant tout
> pour le GUI et toutes les fonctions non gérées par l'ASIC.
> Cela inclus aussi le PPPOE uniquement géré par le CPU, par exemple, tu ne
> pourras pas utiliser ce type de boitier en direct sur une ONT Orange en
> PPPOE, sous peine de saturer le CPU à 100% avec un débit maximum entre 150
> et 200Mbits.
>
> Bref, pour corriger ce souci, tu peux comme tu l'as fait, mettre des bornes
> externes de la marque qui te convient ou des FortiAP en mode "Local
> Bridge".
>
> Dernière chose, le Firmware 5.6 n'est actuellement pas conseillé en
> production.
>
>
>
> Le 5 juillet 2017 à 18:37, David Ponzone  a
> écrit :
>
> > Plutôt très content de Fortinet d’un point de vue FW/UTM, j’aurais aimé
> > avoir confirmation que les AP WIFI embarqués dans les UTM étaient connus
> > pour être des bouzes infâmes, et que ce n'’était moi qui avait mis une
> cage
> > de faraday autour par inadvertance….
> > Les clients se plaignent de décos intempestives et d’un débit pathétique.
> > On a mis une Ubiquiti à la place et les clients sont ravis.
> >
> > Donc AP Fortinet legacy (non-Meru) 10 fois moins bon qu’un AP Ubiquiti à
> > 70€ ?
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>



-- 
Cordialement,

Guillaume BARROT

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

Re: [FRnOG] [TECH] Contact orange pour téléphonie dans l'Orne (61)

[Jérôme Nicolle]

Vincent,

Contactes plutôt AZNetwork qu'Orange, ils déploient de la fibre autour
d'Alençon et devraient pouvoir packager ce genre de solutions.

@+

-- 
Jérôme Nicolle
+33 (0)6 19 31 27 14


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

Re: [FRnOG] [TECH] Contact orange pour téléphonie dans l'Orne (61)

[Vincent Duvernet]

Et non c'est pas Troll-di.

Envoyé depuis mon smartphone Sony Xperia™

 David Ponzone a écrit 

Wow, ça, même si on avait été vendredi, c’est du lourd lourd ça, un missile!

Vincent, appelle le 3901, ils vont t’aider.

...Ok je sors.

> Le 6 juil. 2017 à 18:09, Vincent Duvernet  a 
> écrit :
>
> Bonjour.
> J'ai un client qui utilise actuellement une téléphonie IP Cisco avec un IPBX. 
> Ils voudraient utiliser la box orange business afin de séparer le réseau data 
> et IP. Si transitent aujourd'hui sur des switches Cisco obsolètes.
>
> Ils ont appelé Orange qui ont ont pris note mais sans se déplacer pour 
> vérifier l'infrastructure du client. (surtout que pour le coup, il faudra au 
> minimum tirer un 2 ème réseau Ethernet pour la téléphonie.
>
> Ils ont pleins de lignes ADSL genre 6 ou 8.on ne sait pas 
> forcément qui va avec quoi et je pense que certaines ne sont plus nécessaires.
>
> Donc est ce qu'il y aurait quelqu'un de Orange prêt à prendre le dossier en 
> main ?
>
> Merci
>
> Vincent Duvernet
>
> Envoyé depuis mon smartphone Sony Xperia™
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Contact orange pour téléphonie dans l'Orne (61)

[David Ponzone]

Wow, ça, même si on avait été vendredi, c’est du lourd lourd ça, un missile!

Vincent, appelle le 3901, ils vont t’aider.

...Ok je sors.

> Le 6 juil. 2017 à 18:09, Vincent Duvernet  a 
> écrit :
> 
> Bonjour.
> J'ai un client qui utilise actuellement une téléphonie IP Cisco avec un IPBX. 
> Ils voudraient utiliser la box orange business afin de séparer le réseau data 
> et IP. Si transitent aujourd'hui sur des switches Cisco obsolètes.
> 
> Ils ont appelé Orange qui ont ont pris note mais sans se déplacer pour 
> vérifier l'infrastructure du client. (surtout que pour le coup, il faudra au 
> minimum tirer un 2 ème réseau Ethernet pour la téléphonie.
> 
> Ils ont pleins de lignes ADSL genre 6 ou 8.on ne sait pas 
> forcément qui va avec quoi et je pense que certaines ne sont plus nécessaires.
> 
> Donc est ce qu'il y aurait quelqu'un de Orange prêt à prendre le dossier en 
> main ?
> 
> Merci
> 
> Vincent Duvernet
> 
> Envoyé depuis mon smartphone Sony Xperia™
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

[FRnOG] [TECH] Contact orange pour téléphonie dans l'Orne (61)

[Vincent Duvernet]

Bonjour.
J'ai un client qui utilise actuellement une téléphonie IP Cisco avec un IPBX. 
Ils voudraient utiliser la box orange business afin de séparer le réseau data 
et IP. Si transitent aujourd'hui sur des switches Cisco obsolètes.

Ils ont appelé Orange qui ont ont pris note mais sans se déplacer pour vérifier 
l'infrastructure du client. (surtout que pour le coup, il faudra au minimum 
tirer un 2 ème réseau Ethernet pour la téléphonie.

Ils ont pleins de lignes ADSL genre 6 ou 8.on ne sait pas 
forcément qui va avec quoi et je pense que certaines ne sont plus nécessaires.

Donc est ce qu'il y aurait quelqu'un de Orange prêt à prendre le dossier en 
main ?

Merci

Vincent Duvernet

Envoyé depuis mon smartphone Sony Xperia™

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

[FRnOG] [TECH] C2E en carafe ce jour - qui a été touché ?

[Sylvain Vallerot]

Bonjour à tous,

J'ai un gros client qui a été fortement impacté quasi tout le début
d'après-midi sur ses liaisons d'agences,

le fournisseur des SDSL et fibres a imputé la faute sur la collecte C2E,

mais je m'étonne n'avoir rien vu sur le sujet ici, personne n'a rien vu ?

J'essaie de comprendre à quel régime de pseudo-transparence on est 
mangés par ledit fournisseur... le genre de fournisseur qui m'affirme
avoir résolu des incidents par un reset de DSLAM une heure après que 
j'ai rebooté le routeur fibre !

Merci d'avance pour vos retours.

Bonne journée FRnog !
Sylvain


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

Re: [FRnOG] [TECH] Fortinet et son WIFI legacy....

[David Ponzone]

Merci pour vos conseils mais rassurez-vous, je ne mets généralement que des AP 
dédiés :)
Il reste qu’il est intéressant de savoir pourquoi Fortinet ne peut pas sortir 
un UTM avec AP intégré à 1000-1500€ dont le WIFI marche aussi bien qu’un 
Technicolor à 50€ (c’est-à-dire convenablement).
Je crois qu’on a donc affaire à un hardware/software sérieusement moisi.

> Le 6 juil. 2017 à 13:48, Xavier Beaudouin  a écrit :
> 
> Hello,
> 
>> Donc, de mon coté, je mets des firewalls qui font juste firewall. Et des
>> AP qui font juste AP, sur une patte dédiée du FW (soit des AP pas chers
>> pour les petites installs, soit des gros avec un contrôleur dédié pour
>> les installs plus conséquentes). Bien évidemment, les AP sont en hauteur
>> et loin de tout autre équipement. Déformation radioamateur, sans doute ;-)
> 
> Non. Du bon sens. Un truc qui fait un truc le fait bien. Un machin qui fait 
> trop
> de choses, y tjrs un compromis coût / conso / commercialware a la con qui 
> fait chier.
> 
> Donc on as:
> - router
> - switch
> - firewall
> - ap 
> - nas
> 
> Ce qui fait absolument tout en un seul boitier... #fear (ou c'est pour Mme 
> Michu qui ne veux brancher qu'un machin).
> 
>> Aux gens qui me demandent pourquoi je ne mets pas de boitiers WiFi tout
>> intégrés comme les Dead-Box, je réponds que s'il suffisait de poser des
>> antennes par terre pour que çà fonctionne, TDF, Orange, SFR et autres
>> TowerCast ne se feraient sans doute pas ch*er à installer des pylônes de
>> plusieurs dizaines de mètres en haut de montagnes ;-)
> 
> +1 et tu peux ajouter aussi que c'est pour la même raison qu'on se fait 
>  a mettre des antennes sur les toits pour mieux recevoir
> 
> Déformation d'électronicien... :p
> 
> Xavier
> 
> 
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/


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

Re: [FRnOG] [TECH] Fortinet et son WIFI legacy....

[Abonnements Incal]

Par expérience sur les modèles FWF, j'ai pu constater quelques
"incohérences" dans la config par défaut de la partie WIFI. En effet, ces
modèles (FortiWIFI) intègrent la partie WIFI via un "Software Switch" (seul
mode possible pour la gestion du WIFI interne) et est donc supporté par le
CPU uniquement et non par l'ASIC. Malheureusement le CPU est là avant tout
pour le GUI et toutes les fonctions non gérées par l'ASIC.
Cela inclus aussi le PPPOE uniquement géré par le CPU, par exemple, tu ne
pourras pas utiliser ce type de boitier en direct sur une ONT Orange en
PPPOE, sous peine de saturer le CPU à 100% avec un débit maximum entre 150
et 200Mbits.

Bref, pour corriger ce souci, tu peux comme tu l'as fait, mettre des bornes
externes de la marque qui te convient ou des FortiAP en mode "Local Bridge".

Dernière chose, le Firmware 5.6 n'est actuellement pas conseillé en
production.



Le 5 juillet 2017 à 18:37, David Ponzone  a écrit :

> Plutôt très content de Fortinet d’un point de vue FW/UTM, j’aurais aimé
> avoir confirmation que les AP WIFI embarqués dans les UTM étaient connus
> pour être des bouzes infâmes, et que ce n'’était moi qui avait mis une cage
> de faraday autour par inadvertance….
> Les clients se plaignent de décos intempestives et d’un débit pathétique.
> On a mis une Ubiquiti à la place et les clients sont ravis.
>
> Donc AP Fortinet legacy (non-Meru) 10 fois moins bon qu’un AP Ubiquiti à
> 70€ ?
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] Fortinet et son WIFI legacy....

[Xavier Beaudouin]

Hello,

> Donc, de mon coté, je mets des firewalls qui font juste firewall. Et des
> AP qui font juste AP, sur une patte dédiée du FW (soit des AP pas chers
> pour les petites installs, soit des gros avec un contrôleur dédié pour
> les installs plus conséquentes). Bien évidemment, les AP sont en hauteur
> et loin de tout autre équipement. Déformation radioamateur, sans doute ;-)

Non. Du bon sens. Un truc qui fait un truc le fait bien. Un machin qui fait trop
de choses, y tjrs un compromis coût / conso / commercialware a la con qui fait 
chier.

Donc on as:
- router
- switch
- firewall
- ap 
- nas

Ce qui fait absolument tout en un seul boitier... #fear (ou c'est pour Mme 
Michu qui ne veux brancher qu'un machin).
 
> Aux gens qui me demandent pourquoi je ne mets pas de boitiers WiFi tout
> intégrés comme les Dead-Box, je réponds que s'il suffisait de poser des
> antennes par terre pour que çà fonctionne, TDF, Orange, SFR et autres
> TowerCast ne se feraient sans doute pas ch*er à installer des pylônes de
> plusieurs dizaines de mètres en haut de montagnes ;-)

+1 et tu peux ajouter aussi que c'est pour la même raison qu'on se fait 
 a mettre des antennes sur les toits pour mieux recevoir

Déformation d'électronicien... :p

Xavier


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

Re: [FRnOG] [TECH] Gérer le cas d'une rupture de liaison entre deux routeurs d'un même AS

[Clement Cavadore]

On Thu, 2017-07-06 at 12:59 +0200, Jérôme Nicolle wrote:
> Il faut toujours diversifier les fournisseurs pour éviter les risques
> économiques, juridiques ou humains intrinsèques à une relation
> commerciale entre deux boites.
> 
> L'analyse des plans est toujours nécessaire qu'il s'agisse d'un ou
> plusieurs fournisseurs. Le problème alors c'est quand certains
> fournisseurs refusent de transmettre des plans précis et réels, voir que
> les différences entre l'avant-vente et le réel sont trop importantes.

Exactement. J'ai eu le cas d'ailleurs: Offre pour deux paires de FON
entre $datacenterprivé et $datacenterneutral1 + $datacenterneutral2

Offre faite par un seul opérateur, lequel s'appuyait sur un autre
opérateur pour les segments terminaux, et sur son réseau pour le début
des FON. 

Bilan: une FON de $operateur1 croisait un segment de $operateur2, et ils
ne s'en étaient pas rendus compte. Moi si, car géographiquement, la FON
allant à l'ouest était livrée sur l'aile est du $datacenterprivé, et la
FON allant à l'est était livrée sur l'aile ouest => Ca croise !


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

RE: [FRnOG] [TECH] UCARP/VRRP avec Debian problème

[Sébastien 65]

Bon même en modifiant advskew identique sur les 2 nodes cela ne change rien. 
Avec ou sans preempt j'ai le même problème. D'ailleurs le preempt doit être 
configuré sur les 2 nodes ou uniquement 1 ?


Voici la conf du master :

  ucarp-vid 1
  ucarp-vip 10.0.0.1
  ucarp-password secret
  ucarp-advskew 1
  ucarp-advbase 1
  ucarp-master yes


Voici la conf du slave :

 ucarp-vid 1
 ucarp-vip 10.0.0.1
 ucarp-password secret
 ucarp-advskew 1
 ucarp-advbase 1
 ucarp-master no

...



De : frnog-requ...@frnog.org  de la part de Alarig Le 
Lay 
Envoyé : jeudi 6 juillet 2017 11:47:18
À : frnog@frnog.org
Objet : Re: [FRnOG] [TECH] UCARP/VRRP avec Debian problème

On jeu.  6 juil. 11:01:16 2017, Damien Fleuriot wrote:
> Si le fonctionnement de uCARP se base sur la même logique que le
> protocole CARP d'origine et sauf erreur de ma part, ça n'est pas tout
> à fait le principe :)
>
>
> CARP détermine le mastership comme suit :
> - avec preemption : machine qui s'advertise le plus fréquemment = master
> - sans preemption : machine qui s'advertise le plus fréquemment =
> master, sauf si un master existe déjà
>
>
> La fréquence d'advertisement est définie comme suit :
> - s'annoncer toutes les advbase secondes
> - la valeur de advskew permet d'affiner le délai d'annonce

Ne connaissant pas la configuration, je suis parti du principe que les
advbase étaient égaux et que seuls les advskew différaient, car c’est la
configuration la plus classique.
Si jamais ça ne suffit, on verra pour les trucs compliqués, mais c’est
pas la peine chercher à régler tous les paramètres du protocole quand on
en connaît aucun ;)

--
alarig

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

Re: [FRnOG] [TECH] Gérer le cas d'une rupture de liaison entre deux routeurs d'un même AS

[Jérôme Nicolle]

Plop,

Le 05/07/2017 à 20:38, Guillaume Barrot a écrit :
> Et là la jurisprudence Prosodie penche en faveur d'un fournisseur unique
> qui maîtrise parfaitement son tracé, mais tu peux aussi avoir 2
> fournisseurs si tu prends le temps d'analyser dans le détail les tracés.

Il faut toujours diversifier les fournisseurs pour éviter les risques
économiques, juridiques ou humains intrinsèques à une relation
commerciale entre deux boites.

L'analyse des plans est toujours nécessaire qu'il s'agisse d'un ou
plusieurs fournisseurs. Le problème alors c'est quand certains
fournisseurs refusent de transmettre des plans précis et réels, voir que
les différences entre l'avant-vente et le réel sont trop importantes.

Perso je pense que je vais en arriver à demander les bons de commandes
LGC-BLO, les permissions de voirie et les photos du chantier en plus des
plans, marre de me faire balader par des opérateurs d'infra certifiés
ISO-1664.

@+

-- 
Jérôme Nicolle
+33 (0)6 19 31 27 14


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

Re: [FRnOG] [TECH] Gérer le cas d'une rupture de liaison entre deux routeurs d'un même AS

[Clement Cavadore]

On Thu, 2017-07-06 at 11:45 +0200, David Ponzone wrote:
> Parce que se limiter à utiliser un /24 sur un site géographique, c’est 
> pas forcément gérable et ça peut être générateur de gaspillage.

Ou, plus simplement, parce que désaggréger (et donc générer deux routes
pour tous les routeurs du monde là où une seule serait suffisante) juste
à cause de problématiques d'architecture internes, c'est être un un peu
le voisin chiant, qui s'en fout que les autres soient emmerdés à cause
de tes choix.

Tu as un AS, il *faut* que tu t'assures qu'il soit tout le temps
connexe. Si ca doit passer par deux liaisons optiques entre tes deux
sites (ou une optique et un backup MPLS par exemple), just do it.

-- 
Clément Cavadore


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

Re: [FRnOG] [TECH] UCARP/VRRP avec Debian problème

[Alarig Le Lay]

On jeu.  6 juil. 11:01:16 2017, Damien Fleuriot wrote:
> Si le fonctionnement de uCARP se base sur la même logique que le
> protocole CARP d'origine et sauf erreur de ma part, ça n'est pas tout
> à fait le principe :)
> 
> 
> CARP détermine le mastership comme suit :
> - avec preemption : machine qui s'advertise le plus fréquemment = master
> - sans preemption : machine qui s'advertise le plus fréquemment =
> master, sauf si un master existe déjà
> 
> 
> La fréquence d'advertisement est définie comme suit :
> - s'annoncer toutes les advbase secondes
> - la valeur de advskew permet d'affiner le délai d'annonce

Ne connaissant pas la configuration, je suis parti du principe que les
advbase étaient égaux et que seuls les advskew différaient, car c’est la
configuration la plus classique.
Si jamais ça ne suffit, on verra pour les trucs compliqués, mais c’est
pas la peine chercher à régler tous les paramètres du protocole quand on
en connaît aucun ;)

-- 
alarig


signature.asc
Description: PGP signature

Re: [FRnOG] [TECH] Gérer le cas d'une rupture de liaison entre deux routeurs d'un même AS

[Alarig Le Lay]

On jeu.  6 juil. 11:25:43 2017, Mourad wrote:
> Bonjour,
> 
> Pourquoi le GRE over transitaire est si déconseillé ?

Parce que tu montes un tunnel, donc tu auras des soucis de MTU. En plus,
tu vas payer des transitaires pour du trafic qui est interne à ton AS.

-- 
alarig


signature.asc
Description: PGP signature

Re: [FRnOG] [TECH] Gérer le cas d'une rupture de liaison entre deux routeurs d'un même AS

[David Ponzone]

+1

La solution 1 me semble quand même plus moderne.
Il semble étrange d’avoir un problème avec une interco optique (1 tous les 3 
ans, à la limite).
Parce que se limiter à utiliser un /24 sur un site géographique, c’est pas 
forcément gérable et ça peut être générateur de gaspillage.



> Le 6 juil. 2017 à 11:35, Dominique Rousseau  a écrit :
> 
> Le Wed, Jul 05, 2017 at 06:20:33PM +, Aymeric Maure 
> [technopoli...@hotmail.com] a écrit:
> [...]
>> 
>> Quelle est la façon "propre" de faire cela ? Cad d'avoir deux sites
>> avec leur propres transit, habituellement connectés mais qui puissent
>> se comporter comme deux iles le temps que l'on répare ?
> 
> 1) redonder le lien entre les 2 sites, pour que "ca n'arrive pas"
> 2) rendre chaque "ile" autonome si jamais ça arrive quand même ; càd
> n'avoir a joindre que des ips publiques qui peuvent être annoncées
> localement sur l'un des sites.  (soit au minimum un /24 de chaque côté)
> Delà, soit tu désagrèges tes annonces, soit tu le fais sur 2 AS (ce qui
> de toute façon désagrège)
> 
> 
> -- 
> 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/


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

Re: [FRnOG] [TECH] Gérer le cas d'une rupture de liaison entre deux routeurs d'un même AS

[Dominique Rousseau]

Le Wed, Jul 05, 2017 at 06:20:33PM +, Aymeric Maure 
[technopoli...@hotmail.com] a écrit:
[...]
> 
> Quelle est la façon "propre" de faire cela ? Cad d'avoir deux sites
> avec leur propres transit, habituellement connectés mais qui puissent
> se comporter comme deux iles le temps que l'on répare ?

1) redonder le lien entre les 2 sites, pour que "ca n'arrive pas"
2) rendre chaque "ile" autonome si jamais ça arrive quand même ; càd
n'avoir a joindre que des ips publiques qui peuvent être annoncées
localement sur l'un des sites.  (soit au minimum un /24 de chaque côté)
Delà, soit tu désagrèges tes annonces, soit tu le fais sur 2 AS (ce qui
de toute façon désagrège)


-- 
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] [TECH] Gérer le cas d'une rupture de liaison entre deux routeurs d'un même AS

[Mourad]

Bonjour,

Pourquoi le GRE over transitaire est si déconseillé ?

Le 5 juillet 2017 à 22:43, Raphael Mazelier  a écrit :

>
>
>
>> Quelle est la façon "propre" de faire cela ? Cad d'avoir deux sites avec
>> leur propres transit, habituellement connectés mais qui puissent se
>> comporter comme deux iles le temps que l'on répare ?
>>
>
> Comme l'a justement dit Guillaume ce cas ne doit pas arriver. Ton ibgp ne
> doit pas casser.
>
> Soit tu prend deux AS distincts/indépendants et qui donc peuvent vivre
> leurs vies (et cela peut faire sens), soit tu redondes tes liens
> correctement.
>
> Évidement le soucis c'est que tu n'as pas les même @IP des deux cotés,
> (c'est plutôt sain comme pratique pour la redondance), mais je conçois que
> cela peux poser problème. (a part si tu veux anycaster certain services
> mais c'est un autre sujet).
>
> Après si tu veux conserver un seul AS et que tu n'as pas de vrai budget
> fibres tu peux tenter des trucs étranges/sales :
>
> Tu peux par exemple annoncer ton superblock des deux cotés et choisir un
> sous block par site, originate que du site en question en ebgp et ibgp, de
> sorte qu'en cas de split brain chaque site n'annonce que le superblock et
> son sous-block. Et tu retombe dans le cas ou tu dédie des plages
> spécifiques à chaque site, donc autant les rendre complètement indépendants
> et demander un 2eme ASn.
>
> Les vrais questions que tu dois te poser en tout cas : à quoi sert ton
> multi-site actuel ? full redondance ? aucune dépendance entre les sites ?
> n'as tu vraiment pas de budget pour une lambda ou dark ? (parce que c'est
> franchement peu cher en RP).
>
>
> PS : tu peux aussi en effet faire du backup sur GRE (j'ai déjà fait en
> désespoir de cause entre paris et nyc *fear*) mais c'était vraiment un
> palliatif temporaire.
>
>
>
> --
> Raphael Mazelier
>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>

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

Re: [FRnOG] [TECH] UCARP/VRRP avec Debian problème

[Damien Fleuriot]

2017-07-05 17:22 GMT+02:00 Alarig Le Lay :
> On mer.  5 juil. 14:53:24 2017, Sébastien 65 wrote:
>> Bonjour,
>>
>>
>> Je m'arrache les cheveux depuis ce matin sur le fonctionnement de
>> UCARP et/ou Keepalived sur Debian 9...
>>
>>
>> J'explique : Si Debian1 tombe l'IP VIP bascule bien sur Debian2, en
>> revanche lorsque Debian1 est de nouveau UP, il récupère l'IP de
>> Debian2 (je voudrais éviter cette bascule).
>
> Matin,
>
> Tu as mis quel advskew sur chaque machine ? Si Debian1 a un advskew plus
> faible, c’est normal qu’il reprenne le lead vu qu’il est prioritaire.
>
> Si tu veux éviter que ça revienne sur Debian1, il faut avoir le même
> advskew sur les deux machines.
>
> --
> alarig



Si le fonctionnement de uCARP se base sur la même logique que le
protocole CARP d'origine et sauf erreur de ma part, ça n'est pas tout
à fait le principe :)


CARP détermine le mastership comme suit :
- avec preemption : machine qui s'advertise le plus fréquemment = master
- sans preemption : machine qui s'advertise le plus fréquemment =
master, sauf si un master existe déjà


La fréquence d'advertisement est définie comme suit :
- s'annoncer toutes les advbase secondes
- la valeur de advskew permet d'affiner le délai d'annonce


Le délai de bascule est, sauf erreur :
- 3x advbase
ou
- 3x advbase + distortion de advskew
En tout état de cause plus le advbase est élevé et plus le délai de
bascule le sera également.



Ensuite, pour récupérer le mastership après une bascule, c'est géré
par la Preemption.

Scénario 1, sans preemption.
Machine A, advbase 1, advskew 20
Machine B, advbase 1, advskew 40

Machine A tombe, Machine B devient master.
Machine A revient, Machine B reste master.


Scénario 2, avec preemption.
Machine A, advbase 1, advskew 20, preempt
Machine B, advbase 1, advskew 40, preempt (ou pas)

Machine A tombe, Machine B devient master.
Machine A revient, Machine A preempt l'actuel master parce que son
advbase + advskew est plus faible.



Le man de ucarp documente (mal) le flag -P , qui touche à la preemption :
http://manpages.ubuntu.com/manpages/zesty/man8/ucarp.8.html


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

Re: [FRnOG] [TECH] Fortinet et son WIFI legacy....

[Toussaint OTTAVI]

Le 05/07/2017 à 18:56, David Ponzone a écrit :

Parmi les problèmes les plus fréquents, c'est avec Apple et aussi des clients 
qui basculent dans arrêt entre 2.4 et 5 GHz.


... ou des clients qui ne savent pas "roamer" correctement entre des AP 
5 GHz et des AP 2.4 GHz (par exemple, les terminaux portables 
Datalogic). Workaround : bloquer le terminal ou le réseau sur une seule 
bande de fréquence.



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

Re: [FRnOG] [TECH] Fortinet et son WIFI legacy....

[Toussaint OTTAVI]

Le 05/07/2017 à 18:37, David Ponzone a écrit :

Plutôt très content de Fortinet d’un point de vue FW/UTM, j’aurais aimé avoir 
confirmation que les AP WIFI embarqués dans les UTM étaient connus pour être 
des bouzes infâmes, et que ce n'’était moi qui avait mis une cage de faraday 
autour par inadvertance….


Je n'ai jamais testé Fortinet, mais j'ai fait le même constat chez 
SonicWALL. Les firewalls sont en général placés dans des baies, dans des 
locaux plus ou moins dédiés, et ce sont rarement des endroits opportuns 
pour une bonne couverture. Par ailleurs, je me rappelle avoir passé pas 
mal de temps sur des phénomènes assez étranges de débits qui se 
cassaient la gueule même en filaire lorsque le WiFi était utilisé. Les 
boitiers étaient en plastique, et je pense que la carte électronique 
"ramassait" des ondes radio (phénomène bien connu des radioamateurs, 
dont les effets peuvent être d'autant plus spectaculaires que les 
niveaux de puissance augmentent.)


Donc, de mon coté, je mets des firewalls qui font juste firewall. Et des 
AP qui font juste AP, sur une patte dédiée du FW (soit des AP pas chers 
pour les petites installs, soit des gros avec un contrôleur dédié pour 
les installs plus conséquentes). Bien évidemment, les AP sont en hauteur 
et loin de tout autre équipement. Déformation radioamateur, sans doute ;-)


Aux gens qui me demandent pourquoi je ne mets pas de boitiers WiFi tout 
intégrés comme les Dead-Box, je réponds que s'il suffisait de poser des 
antennes par terre pour que çà fonctionne, TDF, Orange, SFR et autres 
TowerCast ne se feraient sans doute pas ch*er à installer des pylônes de 
plusieurs dizaines de mètres en haut de montagnes ;-)



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