RE: [FRnOG] [TECH] Re: connecter des machines à des ports POE+
> Stéphane Rivière a écrit : > Ce qui explique pourquoi c'est pas si simple de faire un bon client POE "home > made", bien respectueux de > la norme... Parce que dans le doute, le switch POE ne balance pas la sauce... Absolument. Le temps ou on utilisait les paires 4-5 et 7-8 sans standard ou était le plus ou le moins c'était dangereux, mais avec un switch récent aucun risque. Avec un injecteur POE je me méfierais car certains sont passifs et d'autres ont un voltage propriétaire, mais avec un switch récent pas. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] Légalité et légitimité de la "De-Auth attack" (Air Marshal) de Meraki
>> Michel Py a écrit : >> Mon cas d'usage : >> - Ce n'est pas un lieu public. >> - Les voisins les plus proches sont à 300 mètres. >> - Il est interdit d'avoir un mobile personnel. >> - Interdit d'avoir une radio. >> - Interdit d'avoir un appareil photo. >> - Interdit d'avoir une clé USB non approuvée. >> Et j'en passe. Si on pique quelqu'un qui fait du tethering, il aura de la >> chance si çà ne lui coute que son emploi. > Raphael Jacquot a écrit : > ton cas d'usage n'est pas "le client de l'hotel" mais "l'employé dans une > boite qui se prends pour la CIA" ? Oui, ou qui est l'agent d'un gouvernement étranger ou d'un concurrent. En plus de çà, la bande wifi à 2.4 Ghz et les fréquences de la plupart des téléphones DECT c'est banni pour des raisons techniques : on ne veut pas d'interférence avec l'outillage qui s'en sert aussi. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] sflow sur Arista
On Thu, Sep 27, 2018, at 08:11, Radu-Adrian Feurdean wrote: > Tu n'a pas du passer par l'etape Brocade, qui avait exactement la meme > limitation pour le sflow. L'idee etait d'activer les sFlow surtous les > ports d'un edge, y compris les ports backbone. Ca marchait dans la > plupart de cas. Pour detailler un peu : Le fait d'activer le sflow sur toutes les interfaces edge implique une cretaine "discipline" dans l'archi, et a aussi quelques inconvenients. - Melanger sur un meme port physique edge et core = misere. Donc pas le backbone sur une porte de collecte. - les liens purement core - pas de sflow - le point d'entree dans le reseau pour le traffic qui est destine a l'exterieur (sur internet) peut ne pas avoir les informations concernant la partie AS. Il faut enrichir la donnee via un autre moyen, apres l'export sflow. - pas envie de savoir ce qui se passe quand ton reseau est un peu trop heterogene, genre des constructeurs qui utilisent divers types de *flow (Aieee melanger Cisco avec Brocade). - il est parfois necessaire de re-penser ou est la bordure du reseau afin d'avoir des stats corrects (c'etait le cas dans $job[-3] et $job[-2]) - dans des scenarios type MPLS avec du pop(label pour aggregate)-lookup-push(label pour more specific) -> encore une fois, misere si le in et/ou le out sont sur des interfaces avec du sflow. Vu comme ca, le netflow (mem en mode "sampled") a l'air d'etre tombe du pays des bisounours :) -- R-A.F. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] sflow sur Arista
Re, On 27/09/2018 12:43, Arnaud Fenioux wrote: Je n'ai pas eu de probleme pour les champs que tu mentionnes... As tu vérifié que tu as toutes les infos dans les paquets sFlow que tu recois (avec wireshark or sflowtool https://github.com/sflow/sflowtool) ? J'ai le même setup sur mon arista, modulo j'utilise l'interface de management pour envoyer mes flows, interface de management qui est dans une vrf séparée. Je vais essayer sans car pour le moment je ne vois pas d'information bgp avec sflowtool. Je dérive sur pmacct, si ca peut aider d'autres lecteurs : Le PEER_SRC_AS n'est pas toujour correct (si asymetrie de trafic), j'ai préféré générer le peers.map a avec mactopeer (un wrapper napalm) : https://github.com/pierky/mactopeer Oui c'est vrai. Merci pour le lien. Concernant pmacct, la doc n'est plus du tout a jour sur pmacct.net mieux vaut se baser sur https://github.com/pmacct/pmacct/wiki (et encore...) je comptais en parler avec Paolo au FRnOG. En effet mieux vaudrait virer toute doc de pmacct.net car c'est confusant. Parlons lui en :) Last but not least, j'ai rédigé un bout de doc sur pmacct / sfacct + influxdb + grafana avec l'aide de @CorsoAlexandre : http://afenioux.fr/blog/article/pmacct-sfacct-influxdb-grafana Marrant on a fait plus la moins même chose. Perso j'utilise bien sur pmacct/sfacct comme collecteur. Historiquement j'utilisais un exporter vers influxdb (avec de l'amqp au milieu). Mais maintenant j'ai fait un exporter prometheus qui scale mieux. Grafana pour la visualisation bien sur, mais je note superset que je ne connaissais pas et qui l'air bien sexy. -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Légalité et légitimité de la "De-Auth attack" (Air Marshal) de Meraki
Bonjour, On Wed, 26 Sep 2018 23:29:29 +0200 Jérôme Nicolle wrote: > > C'est du gros bullshit çà. Ce qu'ils veulent, c'est forcer les > > clients à utiliser leur WiFi payant au lieu d'utiliser leur tether ou Bon, pour ceux qui veulent vraiment, on peut aussi "tether" : - via l'USB, - via BT et la, pas de soucis avec les DeAuth d'AirMarshal et autres du meme genre... ;) "Si il y a un probleme, c'est qu'il y a une solution" ;) Paul --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Opérateurs/hébergeurs : Quel IPAM/CMDB utilisez-vous ?
Le 2018-09-27 13:58, Olivier MORFIN a écrit : Bonjour, Oui je test en ce moment Netbox... c'est un produit vraiment intéressant. Le truc c'est que même s'il est déjà bien fourni, il manque tout de même des choses dedans (comme la gestion des groupes GLBP, les VXLAN, Etc.) @+ Le mer. 26 sept. 2018 à 17:33, Alexandre DERUMIER a écrit : netbox est pas mal https://github.com/digitalocean/netbox Propose un patch ;-) Cdlt, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Opérateurs/hébergeurs : Quel IPAM/CMDB utilisez-vous ?
Bonjour, Oui je test en ce moment Netbox... c'est un produit vraiment intéressant. Le truc c'est que même s'il est déjà bien fourni, il manque tout de même des choses dedans (comme la gestion des groupes GLBP, les VXLAN, Etc.) @+ Le mer. 26 sept. 2018 à 17:33, Alexandre DERUMIER a écrit : > netbox est pas mal > > https://github.com/digitalocean/netbox > > > - Mail original - > De: "Olivier MORFIN" > À: "frnog-tech" > Envoyé: Mercredi 26 Septembre 2018 11:46:19 > Objet: [FRnOG] [TECH] Opérateurs/hébergeurs : Quel IPAM/CMDB utilisez-vous > ? > > Bonjour à tous, > Je lance un petit sondage auprès des opérateurs/hébergeurs pour savoir > quel > IPAM/CMDB utilisez vous ? Si vous utilisez un produit développé maison, ça > m’intéresse aussi de le savoir, ça me permettra de justifier l'embauche > d'un dev dans ma société :) > > Merci. > Olivier > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] sflow sur Arista
Dans le même esprit que ce que Arnaud à fait, j’ai aussi produit une stack avec PMACCT : http://www.pragma-innovation.fr/cas-dusage-telemetrie-ip/ En Front j’utilise superset (https://github.com/apache/incubator-superset), en backend influxdb va bien pour de petit besoin mais scale difficilement, j’utilise clickhouse (Yandex). Attention à mettre un Kafka entre ton ingest et ton backend, sinon tu risques aussi d’avoir de petits soucis. A voir en fonction du nombre de messages à traiter par seconde. Et comme toujours avec les systèmes et les open-sources, attention aux compatibilités notamment Kafka qui a changé son API, je déconseille la 2.0.0 pour l’instant ! Je vois avec plaisir que le sujet est toujours chaud et que nous devrions avoir de bonnes discussions pour le prochain FRnOG :-) ! Matt. Matthieu Texier, Founder, PRAGMA SECURITY/INNOVATION. Mob: +33 6 85 83 66 89. > On 27 Sep 2018, at 12:43, Arnaud Fenioux wrote: > > Je n'ai pas eu de probleme pour les champs que tu mentionnes... > As tu vérifié que tu as toutes les infos dans les paquets sFlow que tu > recois (avec wireshark or sflowtool > https://github.com/sflow/sflowtool) ? > > J'utilise aussi le lookup par pmacct, car il me donne plus d'info dans > certains cas, je donne la conf, si ca peut servir : > coté arista : > ``` > sflow sample > sflow destination 10.11.12.13 > sflow source-interface Loopback0 > sflow run > sflow extension bgp > > router bgp > neighbor 10.11.12.13 description PMACCT > neighbor 10.11.12.13 update-source Loopback0 > neighbor 10.11.12.13 route-reflector-client > # eviter add-path avec pmacct, ca marchait mal dans mes tests > no neighbor 10.11.12.13 additional-paths send any > ``` > > sfacctd.conf : > ``` > ! we need all of this to get the peer_map working (even if we do not > setup a BGP session) > bgp_daemon: true > bgp_daemon_ip: 10.11.12.13 > bgp_daemon_as: x > bgp_daemon_max_peers: 10 > bgp_peer_src_as_map: /etc/pmacct/peers.map > bgp_peer_src_as_type: map > > ! sfacctd populate 'src_as', 'dst_as', 'peer_src_as' and 'peer_dst_as' > primitives from information in bgp > ! 'longest' behaves : networks_file < sFlow/NetFlow < <= BGP > sfacctd_as: longest > sfacctd_net: longest > ``` > > Je dérive sur pmacct, si ca peut aider d'autres lecteurs : > Le PEER_SRC_AS n'est pas toujour correct (si asymetrie de trafic), > j'ai préféré générer le peers.map a avec mactopeer (un wrapper napalm) > : https://github.com/pierky/mactopeer > Concernant pmacct, la doc n'est plus du tout a jour sur pmacct.net > mieux vaut se baser sur https://github.com/pmacct/pmacct/wiki (et > encore...) je comptais en parler avec Paolo au FRnOG. > > Last but not least, j'ai rédigé un bout de doc sur pmacct / sfacct + > influxdb + grafana avec l'aide de @CorsoAlexandre : > http://afenioux.fr/blog/article/pmacct-sfacct-influxdb-grafana > > Arnaud > On Thu, Sep 27, 2018 at 11:53 AM Raphael Mazelier wrote: >> >> >> Bonjour, >> >> Merci pour ces retours constructifs. >> >> Je peux comprendre la logique même si cela me complique la vie dans le >> cas présent. >> >> En attendant en appliquant la configuration tel que présenté par Arnaud >> il me manque les informations as_src, as_dst et as_path :/ J'ai >> l'interface out donc c'est presque bon. >> >> >> Je me demande s'il n'y a pas un bug sur ces modèles en particulier. >> Dans le pire des cas je vais faire le boulot par pmactt en peerant mais >> c'est moins propre. >> >> Merci à tous. >> >> PS : je suis impatient de voir Paolo IRL, car online il est vraiment top. >> >> -- >> Raphael Mazelier >> >> >> >> On 26/09/2018 23:49, Matthieu Texier wrote: >>> Bonjour Raphael, >>> >>> Je me permets d’intervenir dans la discussion ayant quelques années de >>> pratique sur ces sujets. >>> >>> La “best practice” veut que l’on configure netflow ou sflow ingress sur >>> tous les ports de la machine. Cette "best practice" est essentiellement due >>> au fait que tu ne dois pas, à priori, configurer ton netflwo/sflow par >>> rapport aux résultats finals qui tu attends. Il faut le configurer pour que >>> tu es une vue fidèle de ton trafic dans tout ton routeur. La raison cachée >>> de cette best practice est qu’un routeur fait son IP lookup sur son port >>> ingress (calcul de la best route et port de sortie, etc ..). Demander à un >>> routeur, sur son port de sortie de savoir sur quel port le paquet est entré >>> est souvent (pour ne pas dire toujours) compliqué (d’autant plus lorsque tu >>> fais du link bundling). >>> >>> C’est le travail du collecteur de te donner les vues qui t’intéresse et qui >>> pourra, grace a cette best practice, te donner les vues auxquelles tu >>> n’aurais peut-être pas pensée initialement. C’est en particulier vrai >>> lorsque tu te sers de tes flow pour la detection d’anomalies. >>> >>> J’avais fait une petite video sur le sujet il y a quelques années à >>> l’assemblée FranceIX: https://www.youtube.com/watch?v=Vds3ibaCpIU
Re: [FRnOG] [TECH] sflow sur Arista
Je n'ai pas eu de probleme pour les champs que tu mentionnes... As tu vérifié que tu as toutes les infos dans les paquets sFlow que tu recois (avec wireshark or sflowtool https://github.com/sflow/sflowtool) ? J'utilise aussi le lookup par pmacct, car il me donne plus d'info dans certains cas, je donne la conf, si ca peut servir : coté arista : ``` sflow sample sflow destination 10.11.12.13 sflow source-interface Loopback0 sflow run sflow extension bgp router bgp neighbor 10.11.12.13 description PMACCT neighbor 10.11.12.13 update-source Loopback0 neighbor 10.11.12.13 route-reflector-client # eviter add-path avec pmacct, ca marchait mal dans mes tests no neighbor 10.11.12.13 additional-paths send any ``` sfacctd.conf : ``` ! we need all of this to get the peer_map working (even if we do not setup a BGP session) bgp_daemon: true bgp_daemon_ip: 10.11.12.13 bgp_daemon_as: x bgp_daemon_max_peers: 10 bgp_peer_src_as_map: /etc/pmacct/peers.map bgp_peer_src_as_type: map ! sfacctd populate 'src_as', 'dst_as', 'peer_src_as' and 'peer_dst_as' primitives from information in bgp ! 'longest' behaves : networks_file < sFlow/NetFlow < <= BGP sfacctd_as: longest sfacctd_net: longest ``` Je dérive sur pmacct, si ca peut aider d'autres lecteurs : Le PEER_SRC_AS n'est pas toujour correct (si asymetrie de trafic), j'ai préféré générer le peers.map a avec mactopeer (un wrapper napalm) : https://github.com/pierky/mactopeer Concernant pmacct, la doc n'est plus du tout a jour sur pmacct.net mieux vaut se baser sur https://github.com/pmacct/pmacct/wiki (et encore...) je comptais en parler avec Paolo au FRnOG. Last but not least, j'ai rédigé un bout de doc sur pmacct / sfacct + influxdb + grafana avec l'aide de @CorsoAlexandre : http://afenioux.fr/blog/article/pmacct-sfacct-influxdb-grafana Arnaud On Thu, Sep 27, 2018 at 11:53 AM Raphael Mazelier wrote: > > > Bonjour, > > Merci pour ces retours constructifs. > > Je peux comprendre la logique même si cela me complique la vie dans le > cas présent. > > En attendant en appliquant la configuration tel que présenté par Arnaud > il me manque les informations as_src, as_dst et as_path :/ J'ai > l'interface out donc c'est presque bon. > > > Je me demande s'il n'y a pas un bug sur ces modèles en particulier. > Dans le pire des cas je vais faire le boulot par pmactt en peerant mais > c'est moins propre. > > Merci à tous. > > PS : je suis impatient de voir Paolo IRL, car online il est vraiment top. > > -- > Raphael Mazelier > > > > On 26/09/2018 23:49, Matthieu Texier wrote: > > Bonjour Raphael, > > > > Je me permets d’intervenir dans la discussion ayant quelques années de > > pratique sur ces sujets. > > > > La “best practice” veut que l’on configure netflow ou sflow ingress sur > > tous les ports de la machine. Cette "best practice" est essentiellement due > > au fait que tu ne dois pas, à priori, configurer ton netflwo/sflow par > > rapport aux résultats finals qui tu attends. Il faut le configurer pour que > > tu es une vue fidèle de ton trafic dans tout ton routeur. La raison cachée > > de cette best practice est qu’un routeur fait son IP lookup sur son port > > ingress (calcul de la best route et port de sortie, etc ..). Demander à un > > routeur, sur son port de sortie de savoir sur quel port le paquet est entré > > est souvent (pour ne pas dire toujours) compliqué (d’autant plus lorsque tu > > fais du link bundling). > > > > C’est le travail du collecteur de te donner les vues qui t’intéresse et qui > > pourra, grace a cette best practice, te donner les vues auxquelles tu > > n’aurais peut-être pas pensée initialement. C’est en particulier vrai > > lorsque tu te sers de tes flow pour la detection d’anomalies. > > > > J’avais fait une petite video sur le sujet il y a quelques années à > > l’assemblée FranceIX: https://www.youtube.com/watch?v=Vds3ibaCpIU > > > > Pour ce qui est du software et de la collecte: l’open source PMACCT offre > > de nombreuses options intéressantes. Paolo Lucente mon ami et partenaire > > (auteur du SW viendra au prochain FRnOG en parler). Il sera disponible > > aussi pour répondre aux questions et moi aussi :-). > > > > My 2 cents, > > Matthieu. > > --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] sflow sur Arista
Bonjour, Merci pour ces retours constructifs. Je peux comprendre la logique même si cela me complique la vie dans le cas présent. En attendant en appliquant la configuration tel que présenté par Arnaud il me manque les informations as_src, as_dst et as_path :/ J'ai l'interface out donc c'est presque bon. Je me demande s'il n'y a pas un bug sur ces modèles en particulier. Dans le pire des cas je vais faire le boulot par pmactt en peerant mais c'est moins propre. Merci à tous. PS : je suis impatient de voir Paolo IRL, car online il est vraiment top. -- Raphael Mazelier On 26/09/2018 23:49, Matthieu Texier wrote: Bonjour Raphael, Je me permets d’intervenir dans la discussion ayant quelques années de pratique sur ces sujets. La “best practice” veut que l’on configure netflow ou sflow ingress sur tous les ports de la machine. Cette "best practice" est essentiellement due au fait que tu ne dois pas, à priori, configurer ton netflwo/sflow par rapport aux résultats finals qui tu attends. Il faut le configurer pour que tu es une vue fidèle de ton trafic dans tout ton routeur. La raison cachée de cette best practice est qu’un routeur fait son IP lookup sur son port ingress (calcul de la best route et port de sortie, etc ..). Demander à un routeur, sur son port de sortie de savoir sur quel port le paquet est entré est souvent (pour ne pas dire toujours) compliqué (d’autant plus lorsque tu fais du link bundling). C’est le travail du collecteur de te donner les vues qui t’intéresse et qui pourra, grace a cette best practice, te donner les vues auxquelles tu n’aurais peut-être pas pensée initialement. C’est en particulier vrai lorsque tu te sers de tes flow pour la detection d’anomalies. J’avais fait une petite video sur le sujet il y a quelques années à l’assemblée FranceIX: https://www.youtube.com/watch?v=Vds3ibaCpIU Pour ce qui est du software et de la collecte: l’open source PMACCT offre de nombreuses options intéressantes. Paolo Lucente mon ami et partenaire (auteur du SW viendra au prochain FRnOG en parler). Il sera disponible aussi pour répondre aux questions et moi aussi :-). My 2 cents, Matthieu. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] sflow sur Arista
On 27/09/2018 08:47, Romain Degez wrote: Huhu, pour le coup moi je suis passé par ladite étape Brocade ;-) Sûrement pour ça que ça m'a pas gêné plus que ça. J'avoue ne pas avoir eu cette chance... Remarquez qu'il y a une certaine continuité logique entre brocade et arista. Ceci expliquant peut être cela :) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Légalité et légitimité de la "De-Auth attack" (Air Marshal) de Meraki
Bonjour, Le Code des postes et des communications électroniques dispose clairement « Sont prohibées l'une quelconque des activités suivantes : l'importation, la publicité, la cession à titre gratuit ou onéreux, la mise en circulation, l'installation, la détention et l'utilisation de tout dispositif destiné à rendre inopérants des appareils de communications électroniques de tous types, tant pour l'émission que pour la réception » https://www.legifrance.gouv.fr/affichCodeArticle.do?cidTexte=LEGITEXT06070987=LEGIARTI24506235 Le texte est plus général qu'un simple brouilleur RF puisqu'il parle de n'importe quoi permettant à "rendre inopérant", même si on pourrait discuter du fait que l'AP n'est pas "destiné" exclusivement à rendre inopérant les autres réseaux wifi mais a pour principale fonction d'être un AP, donc le produit Meraki est globalement autorisé mais je pense a priori que ladite fonctionnalité reste interdite... Pour ce qui concerne la lutte contre les Rogue APs, 802.1x permet déjà depuis longtemps de garantir que l'authentification soit mutuelle (mais c'est très peu utilisé, tout le monde utilise une PSK (ou un réseau ouvert) + portail captif...) -- Adrien - Mail original - De: "Jérôme Nicolle" À: frnog@frnog.org Envoyé: Mercredi 26 Septembre 2018 18:04:10 Objet: [FRnOG] [MISC] Légalité et légitimité de la "De-Auth attack" (Air Marshal) de Meraki Bonjour la liste, La FCC a condamné un hôtel pour avoir utilisé une fonctionnalité similaire à Meraki Air Marshal, consistant à bloquer tout autre réseau WiFi sur une zone couverte par l'envoi de De-Auth forgées. D'après l'hôtelier et l'équipementier, la raison derrière se blocage est purement sécuritaire : c'est un moyen efficace de lutter contre des Rogue AP. Ça peut aussi être un moyen de désengorger la bande radio, dans un soucis de qualité de service. Problème (et justification de l'amende) : ça empêche les personnes sur zone d'utiliser leurs hot-spots personnels (modem dédié ou téléphone mobile en tethering WiFi, mais ça marcherait en câble ou Bluetooth). J'ai trois questions (doubles) sur ce sujet, pour lesquelles j'aimerais avoir vos avis : * Dans un domaine privé, et par souci de sécurité, considérez vous cette fonction utile ou au moins légitime ? De quelles menaces prémuni-t-elle efficacement l'exploitant du réseau WiFi aggressif ? * Quelle est la légalité (au moins en France) d'une telle fonction ? Est ce qu'un tel équipement peut ne serait-ce qu'être certifié pour commercialisation ? * Existe-t-il un moyen, autre que 802.11w trop rarement disponible, pour se prémunir d'une telle attaque ? Est ce que c'est susceptible d'être impossible avec WPA3 ? Merci d'avance pour vos contributions ! @+ -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Légalité et légitimité de la "De-Auth attack" (Air Marshal) de Meraki
On 09/26/2018 07:49 PM, Michel Py wrote: > Mon cas d'usage : > - Ce n'est pas un lieu public. > - Les voisins les plus proches sont à 300 mètres. > - Il est interdit d'avoir un mobile personnel. > - Interdit d'avoir une radio. > - Interdit d'avoir un appareil photo. > - Interdit d'avoir une clé USB non approuvée. > > Et j'en passe. Si on pique quelqu'un qui fait du tethering, il aura de la > chance si çà ne lui coute que son emploi. ton cas d'usage n'est pas "le client de l'hotel" mais "l'employé dans une boite qui se prends pour la CIA" ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: connecter des machines à des ports POE+
Le 27/09/2018 à 10:14, David Ponzone a écrit : Oui mais toujours aucun risque. Tout à fait. Ce qui explique pourquoi c'est pas si simple de faire un bon client POE "home made", bien respectueux de la norme... Parce que dans le doute, le switch POE ne balance pas la sauce... -- Stéphane Rivière Ile d'Oléron - France --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: connecter des machines à des ports POE+
Oui mais toujours aucun risque. Enfin, si quelqu’un a déjà eu une carte réseau d’un constructeur réputé grillée par un switch POE d’un constructeur réputé, qu’il se lève maintenant ou se taise à jamais :) Le PD doit appliquer une résistance précise entre certains fils. Si le PSE ne détecte pas cette résistance, il sait que le PD n’est pas POE-compliant, et donc il envoie pas la sauce. > Le 27 sept. 2018 à 09:47, Stéphane Rivière a écrit : > >> Le PoE est envoyé sur les PIN qui ne sont pas utilisé pour de >> l'ethernet, risque proche de zero, il sont pas cablés sur les devices. > > Sauf si device 1 Gbps non POE... > > -- > Stéphane Rivière > Ile d'Oléron - France > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Re: connecter des machines à des ports POE+
Le PoE est envoyé sur les PIN qui ne sont pas utilisé pour de l'ethernet, risque proche de zero, il sont pas cablés sur les devices. Sauf si device 1 Gbps non POE... -- Stéphane Rivière Ile d'Oléron - France --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] sflow sur Arista
bonjour Raphael Les infos sont en lignes sur la partie publique sur notre site….tout est clair et transparent https://www.arista.com/en/um-eos/eos-section-46-1-sflow-conceptual-overview#ww1152186 "46.1.2 Arista sFlow Implementation Arista switches provide a single sFlow agent instance that samples ingress traffic from all Ethernet and port channel interfaces. Pascal > Le 27 sept. 2018 à 08:46, Arnaud Fenioux a écrit : > > Salut Raphael, > > On a migré tout le réseau d'HOPUS.net avec du Arista (boxes > 7280SR-48C6 et chassis 7508N) et ca tourne super bien! > La cli est tres (trop...) IOS-XE like, mais l'import des prefix-list > par http/https/scp est un plaisir (surtout avec un "refresh ip > prefix-list" en schedule), > il ne manque plus que je le support de RTR pour RPKI/ROA :) > > Pour le sFlow, on ne fait que du ingress... mais pense a activer les > extentions BGP et enlever l'ECMP multipath-relax (ECMP sur des AS-PATH > différents mais de meme longeur, ca complique les stats sFLOW avec des > PEER_DST_ASN à 0) : > > sflow extension bgp > router bgp 44530 > maximum-paths 4 ecmp 4 > no bgp additional-paths receive > no bgp bestpath as-path multipath-relax > > A part ca, le tac est vraiment efficace et réactif, ils ne posent pas > des questions pour faire perdre du temps comme d'autres constructeurs > (pas de noms!) et généralement donnent la solution/workaround en 24h. > > Arnaud > On Thu, Sep 27, 2018 at 8:11 AM Radu-Adrian Feurdean > wrote: >> >> On Wed, Sep 26, 2018, at 22:24, Raphael Mazelier wrote: >>> J'essaye de faire du sflow. Et pour le moment je m’aperçois d'un truc >>> très moche, c'est que je n'arrive pas à avoir de sample en egress d'une >> >> Tu n'a pas du passer par l'etape Brocade, qui avait exactement la meme >> limitation pour le sflow. L'idee etait d'activer les sFlow surtous les ports >> d'un edge, y compris les ports backbone. Ca marchait dans la plupart de cas. >> >> >> --- >> 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] sflow sur Arista
On Thu, Sep 27, 2018 at 8:11 AM Radu-Adrian Feurdean < fr...@radu-adrian.feurdean.net> wrote: > On Wed, Sep 26, 2018, at 22:24, Raphael Mazelier wrote: > > J'essaye de faire du sflow. Et pour le moment je m’aperçois d'un truc > > très moche, c'est que je n'arrive pas à avoir de sample en egress d'une > > Tu n'a pas du passer par l'etape Brocade, qui avait exactement la meme > limitation pour le sflow. L'idee etait d'activer les sFlow surtous les > ports d'un edge, y compris les ports backbone. Ca marchait dans la plupart > de cas. Huhu, pour le coup moi je suis passé par ladite étape Brocade ;-) Sûrement pour ça que ça m'a pas gêné plus que ça. ++ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] sflow sur Arista
Salut Raphael, On a migré tout le réseau d'HOPUS.net avec du Arista (boxes 7280SR-48C6 et chassis 7508N) et ca tourne super bien! La cli est tres (trop...) IOS-XE like, mais l'import des prefix-list par http/https/scp est un plaisir (surtout avec un "refresh ip prefix-list" en schedule), il ne manque plus que je le support de RTR pour RPKI/ROA :) Pour le sFlow, on ne fait que du ingress... mais pense a activer les extentions BGP et enlever l'ECMP multipath-relax (ECMP sur des AS-PATH différents mais de meme longeur, ca complique les stats sFLOW avec des PEER_DST_ASN à 0) : sflow extension bgp router bgp 44530 maximum-paths 4 ecmp 4 no bgp additional-paths receive no bgp bestpath as-path multipath-relax A part ca, le tac est vraiment efficace et réactif, ils ne posent pas des questions pour faire perdre du temps comme d'autres constructeurs (pas de noms!) et généralement donnent la solution/workaround en 24h. Arnaud On Thu, Sep 27, 2018 at 8:11 AM Radu-Adrian Feurdean wrote: > > On Wed, Sep 26, 2018, at 22:24, Raphael Mazelier wrote: > > J'essaye de faire du sflow. Et pour le moment je m’aperçois d'un truc > > très moche, c'est que je n'arrive pas à avoir de sample en egress d'une > > Tu n'a pas du passer par l'etape Brocade, qui avait exactement la meme > limitation pour le sflow. L'idee etait d'activer les sFlow surtous les ports > d'un edge, y compris les ports backbone. Ca marchait dans la plupart de cas. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] sflow sur Arista
On Wed, Sep 26, 2018, at 22:24, Raphael Mazelier wrote: > J'essaye de faire du sflow. Et pour le moment je m’aperçois d'un truc > très moche, c'est que je n'arrive pas à avoir de sample en egress d'une Tu n'a pas du passer par l'etape Brocade, qui avait exactement la meme limitation pour le sflow. L'idee etait d'activer les sFlow surtous les ports d'un edge, y compris les ports backbone. Ca marchait dans la plupart de cas. --- Liste de diffusion du FRnOG http://www.frnog.org/
