Re: [FRnOG] [TECH] Attaque Spamhaus/Cloudflare et les points d'échange
On Wed, 27 Mar 2013 22:23:19 +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote: D'abord, cela ne correspond pas à ce que je vois. Les statistiques publiques du DECIX et de l'AMS-IX ne montrent pas de pic de trafic particulier. (Ni le FranceIX, non cité par CloudFlare.) Gizmodo met la lumière sur l'immense exagération en vue de faire valoir un communiqué de presse de CloudFlare. http://gizmodo.com/5992652 Ce serait la version hollandaise du buzz Carambar. La conclusion de l'article suffit à tout commentaire : It was a Dutch problem, and that's it. Dutch ain't internet. Cordialement. -- Solarus www.ultrawaves.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaque Spamhaus/Cloudflare et les points d'échange
Pareil :) Bref j'ai bien mangé hier soir et le dessert était vraiment bon ! Rien vu de significatif pour la part. Raphael Le 28 mars 2013 à 09:33, Solarus sola...@ultrawaves.fr a écrit : On Wed, 27 Mar 2013 22:23:19 +0100, Stephane Bortzmeyer bortzme...@nic.fr wrote: D'abord, cela ne correspond pas à ce que je vois. Les statistiques publiques du DECIX et de l'AMS-IX ne montrent pas de pic de trafic particulier. (Ni le FranceIX, non cité par CloudFlare.) Gizmodo met la lumière sur l'immense exagération en vue de faire valoir un communiqué de presse de CloudFlare. http://gizmodo.com/5992652 Ce serait la version hollandaise du buzz Carambar. La conclusion de l'article suffit à tout commentaire : It was a Dutch problem, and that's it. Dutch ain't internet. Cordialement. -- Solarus www.ultrawaves.fr --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] SDN et la neutralité du réseau
Je reprend pour être plus clair (il faut être vigilant quand on poste sur FrNog les experts ont vite fait de nous rabaisser :)) Problématique : - Dans un environnement virtualisé (machine virtuelle) les caractéristiques réseaux (QoS, ACL, VLAN...) doivent pouvoir dynamiquement se déplacer dans le Datacanter (au grès de l'hyperviseur) Concept : - Rendre les équipements réseaux (virtual switch, switch physique, routeurs) plus bêtes (commutation, application de règles en remontant les flows) piloté par un composant applicatif plus intelligent / centralisé Implementation : - Nicira - Chaîne Openflow / Openvswitch / NOX | Beacon - ... Si tu prends les éléments de manière individuelle ou atomique cela ne constitue pas du SDN, c'est l'ensemble de la chaîne qui le constitue. Je te rejoins sur le fait que c'est un terme Marketing (Cloud ?) mais derrière cela adresse des contraintes de sécurité, de QoS et surtout, surtout d'exploitation. On peut toujours tout faire maison mais : 1) ce sera peut être plus coûteux 2) ce sera peut être plus difficile à maintenir et moins industrialisé Cela revient au débat, moi j'utilise un routeur Quagga parce que je me sens capable d'aller modifier le code du daemon BGP alors que je ne fais pas confiance au support et dans les produits des équipementiers (Juniper, Cisco...). Une question me vient à l'esprit, comment adresses tu ces problématiques (récentes ?) depuis plus de 10 ans ? Sachant que pour mener à bien ce genre de mission il faut aller taper dans le code du Virtual switch de l'hyperviseur (les switchs virtuels distribués n'ont pas 10 ans d'existences) ... Le sujet n'est pas simple quand tu es à l'interieur d'un DC maintenant si tu l'étend à plusieurs... -- Adrien Le 28 mars 2013 00:18, Gunther Ozerito gozer...@gmail.com a écrit : Et encore faux. Encapsuler du niveau 2 dans du niveau 3 n'est pas du SDN. Openflow et openstack non plus. Nvgre et vxlan non plus... Nexus 1000v et Openvswitch, toujours pas... Cloudstack quantum ? Non mais a la limite on se rapproche un peu si on scripte un peu autour de cet outil. Une machine sous Linux qui collecte les resultats de sondes ipsla, de stats netflow, les lsa ospf, les annonces bgp, qui mouline tout ca et qui se connecte en ssh sur des routeurs pour changer des ACL pour du PBR, ou des metriques de routage, la oui. Si en plus cette meme machine surveille des applications et change les politiques de routage en fonction du fonctionnement des ces applis, polée en SNMP par exemple, alors la on est tres proche du SDN. Encore une fois, c'est un terme marketing pour faire peur, mais c'est des technos connues depuis des années ! Le 25 mars 2013 21:42, Adrien Pestel pestoui...@gmail.com a écrit : Salut, Je ne l'ai pas forcément compris comme ça ou tout du moins ce n'est pas ce que j'en ai retenu. Je crois que la finalité c'est de dire aujourd'hui votre sécurité et plus largement le control plane est traité localement (dans votre switch physique, dans votre switch virtuel, vos routeurs...). Demain on vous propose de remonter le control plane dans des appliances et de gérer de manière transverse a à votre/vos DC la QoS et la sécurité. Ce sont principalement les problématiques liés à la virtualisation/cloud qui ont amené à ce genre de réflexion, car le réseau LAN gérer de manière traditionnelle trouve ses limites. Nicira (racheté par VMWare) propose une implémentation de ce type de modèle (des tunnels GRE de ce que j'en ai compris entres les hyperviseurs). Adrien Le 25 mars 2013 19:19, Olivier Cochard-Labbé oliv...@cochard.me a écrit : Bonjour, Il y a un truc qui semble être de plus en plus à la mode: le software-defined networking (SDN). J'ai donc regardé de plus prêt la solution OpenFlow et le concept du «flow» me fait tiquer. Si j'ai bien compris, dans un SDN on ne route plus un paquet en fonction de son IP de destination mais en fonction de plusieurs paramètres tel que: IP source, IP dest, TCP source, TCP dest, etc… Or la définition de la neutralité du réseau «exclut ... toute discrimination à l'égard de la source, de la destination ou du contenu de l'information transmise sur le réseau» (Wikipedia). J'ai donc comme l'impression qu'un SDN ne peut, par nature, être un réseau neutre. Est-ce que je me trompe ? 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] [MISC] SDN et la neutralité du réseau
Le SDN a été créé pour répondre à des problématiques datacenters où l’environnement est très dynamique (création de vm, déplacement de vm pour des raisons de load-balancing..). L'exploitation d'un tel réseau est très couteuse avec les outils actuels et pas du tout efficace. Donc oui à la base cette techno n'est pas destinée aux opérateurs ni aux Lan qui n'ont pas ce genre de problématique. En contrepartie, le SDN offre une nouvelle vision de l'architecture réseau qui a le mérite d'être élégante (je vous invite à regarder quelques vidéos dans les archives de l'ONF notamment celles de Scott Shenker en 2011 ou encore celle de Brandon Heller en 2012 pour mieux comprendre de quoi il est question car le SDN ce n'est pas SEULEMENT OpenFlow) Le SDN est donc rentré dans le monde du réseau par la porte des datacenters mais rien n'exclut que ce paradigme s'arrête là..Pendant l'ONF 2012, des talks étaient consacrés au monde de l'opérateur et de l'entreprise. Si les opérateurs adoptent de tels réseau, ils auront en théorie plus de contrôle et pourront -oui- porter atteinte à la neutralité des réseaux plus facilement Dans tous les cas on a le temps de voir venir la chose car la techno en est seulement à ses prémices dans l’écosystème du cloud. The Future of Networking, and the Past of Protocols - Scott Shenker : http://www.youtube.com/watch?v=YHeyuD89n1Y ONS 2012 - OpenFlow/SDN Introduction with Brandon Heller : http://www.youtube.com/watch?v=aq_IrsONfZw Archives ONF 2011 : http://opennetsummit.org/archives-october2011.html Archives ONF 2012 : http://opennetsummit.org/archives-april2012.html Le 28 mars 2013 09:55, Adrien Pestel pestoui...@gmail.com a écrit : Je reprend pour être plus clair (il faut être vigilant quand on poste sur FrNog les experts ont vite fait de nous rabaisser :)) Problématique : - Dans un environnement virtualisé (machine virtuelle) les caractéristiques réseaux (QoS, ACL, VLAN...) doivent pouvoir dynamiquement se déplacer dans le Datacanter (au grès de l'hyperviseur) Concept : - Rendre les équipements réseaux (virtual switch, switch physique, routeurs) plus bêtes (commutation, application de règles en remontant les flows) piloté par un composant applicatif plus intelligent / centralisé Implementation : - Nicira - Chaîne Openflow / Openvswitch / NOX | Beacon - ... Si tu prends les éléments de manière individuelle ou atomique cela ne constitue pas du SDN, c'est l'ensemble de la chaîne qui le constitue. Je te rejoins sur le fait que c'est un terme Marketing (Cloud ?) mais derrière cela adresse des contraintes de sécurité, de QoS et surtout, surtout d'exploitation. On peut toujours tout faire maison mais : 1) ce sera peut être plus coûteux 2) ce sera peut être plus difficile à maintenir et moins industrialisé Cela revient au débat, moi j'utilise un routeur Quagga parce que je me sens capable d'aller modifier le code du daemon BGP alors que je ne fais pas confiance au support et dans les produits des équipementiers (Juniper, Cisco...). Une question me vient à l'esprit, comment adresses tu ces problématiques (récentes ?) depuis plus de 10 ans ? Sachant que pour mener à bien ce genre de mission il faut aller taper dans le code du Virtual switch de l'hyperviseur (les switchs virtuels distribués n'ont pas 10 ans d'existences) ... Le sujet n'est pas simple quand tu es à l'interieur d'un DC maintenant si tu l'étend à plusieurs... -- Adrien Le 28 mars 2013 00:18, Gunther Ozerito gozer...@gmail.com a écrit : Et encore faux. Encapsuler du niveau 2 dans du niveau 3 n'est pas du SDN. Openflow et openstack non plus. Nvgre et vxlan non plus... Nexus 1000v et Openvswitch, toujours pas... Cloudstack quantum ? Non mais a la limite on se rapproche un peu si on scripte un peu autour de cet outil. Une machine sous Linux qui collecte les resultats de sondes ipsla, de stats netflow, les lsa ospf, les annonces bgp, qui mouline tout ca et qui se connecte en ssh sur des routeurs pour changer des ACL pour du PBR, ou des metriques de routage, la oui. Si en plus cette meme machine surveille des applications et change les politiques de routage en fonction du fonctionnement des ces applis, polée en SNMP par exemple, alors la on est tres proche du SDN. Encore une fois, c'est un terme marketing pour faire peur, mais c'est des technos connues depuis des années ! Le 25 mars 2013 21:42, Adrien Pestel pestoui...@gmail.com a écrit : Salut, Je ne l'ai pas forcément compris comme ça ou tout du moins ce n'est pas ce que j'en ai retenu. Je crois que la finalité c'est de dire aujourd'hui votre sécurité et plus largement le control plane est traité localement (dans votre switch physique, dans votre switch virtuel, vos routeurs...). Demain on vous propose de remonter le control plane dans des appliances et de gérer de manière transverse a à votre/vos DC la QoS et la sécurité. Ce sont principalement les problématiques
Re: [FRnOG] [MISC] SDN et la neutralité du réseau
Toujours pas ... Tu confonds SDN, Openflow, et les networks overlay ... c'est pas de bol quand même, suffit juste de lire les docs pour pas les confondre. *SDN* : possibilité donné dans un réseau de modifier les comportements de routing et de forwarding sur des critères normalement pas pris en compte par les protocoles standard. Ex : par defaut, on route sur la destination, BGP me donne des informations de reach de destination, qu'il compile pour alimenter la RIB, laquelle elle même impacte la FIB pour savoir par quelle interface vont sortir les paquets. Je veux faire du routage différencié en fonction de la source (toutes les IPs venant de mon DC01 : next-hop = toto, pour tout le reste, conforme à la RIB, next-hop = tata), avec au hasard du Policy Based Routing. Si en plus je pilote les ACLs de mon PBR avec un script qui par exemple va modifier ces entrées en fonction de la latence mesurée sur les liens = SDN. *application* : backbone, datacenter, ... *Openflow *: protocole en cours de standardisation pour échanger des infos entre un control plane externe, et un dataplane d'équipement réseau standard. Evite d'avoir à scripter pour passer des commandes en SSH sur les routeurs, et permet aussi de faire des trucs que les commandes CLI ne permettent pas (au hasard, injecter des infos directement dans la RIB ou la FIB, sans avoir de protocole dynamique). *application* : backbone, datacenter, ... SDN - openflow interop lab http://incntre.iu.edu/SDNlab : lancé en 2011 pour voir comment accoster les deux technos entre elles. Openstack Quantum, Nicira, etc : type de collecteurs partiellement ou totalement compatible Openflow, mais aussi avec des fonctionnalités propriétaires ou d'autres protocoles (netconf). VXLAN, NVGRE et nicira stt : techno de network overlay, consistant à encapsuler les trames ethernets dans des trames de niveau 3 (GRE ou UDP). Aucun rapport avec SDN, ce sont des technos qu'on peut éventuellement mettre en concurrence avec VPLS, L2TPv3, OTV, etc... Donc non le SDN c'est pas que pour de la virtualisation, et ce depuis longtemps, et c'est une notion qui existe depuis très longtemps dans le backbone (Performance Routing chez Cisco, Path Computation Elementhttp://en.wikipedia.org/wiki/Path_computation_elementdepuis des années à l'IETF). Juste pour bien comprendre, sans SDN, vous me direz comment vous injectez du trafic purement voix dans un MPLS TE entre deux sites distants, en assurant que le trafic non classifié voix au niveau DSCP ne passe pas dans le tunnel... Et non, ce n'est pas du tout compatible avec la neutralité du net, mais on s'en fout car on est dans la vraie vie, pas à Standford, et y a des contraintes réelles qui font qu'on doit bosser. Aller encore deux bullshits marketing pour bien se mélanger les pinceaux : trill et lisp. SDN ou pas ? Le 28 mars 2013 09:55, Adrien Pestel pestoui...@gmail.com a écrit : Je reprend pour être plus clair (il faut être vigilant quand on poste sur FrNog les experts ont vite fait de nous rabaisser :)) Problématique : - Dans un environnement virtualisé (machine virtuelle) les caractéristiques réseaux (QoS, ACL, VLAN...) doivent pouvoir dynamiquement se déplacer dans le Datacanter (au grès de l'hyperviseur) Concept : - Rendre les équipements réseaux (virtual switch, switch physique, routeurs) plus bêtes (commutation, application de règles en remontant les flows) piloté par un composant applicatif plus intelligent / centralisé Implementation : - Nicira - Chaîne Openflow / Openvswitch / NOX | Beacon - ... Si tu prends les éléments de manière individuelle ou atomique cela ne constitue pas du SDN, c'est l'ensemble de la chaîne qui le constitue. Je te rejoins sur le fait que c'est un terme Marketing (Cloud ?) mais derrière cela adresse des contraintes de sécurité, de QoS et surtout, surtout d'exploitation. On peut toujours tout faire maison mais : 1) ce sera peut être plus coûteux 2) ce sera peut être plus difficile à maintenir et moins industrialisé Cela revient au débat, moi j'utilise un routeur Quagga parce que je me sens capable d'aller modifier le code du daemon BGP alors que je ne fais pas confiance au support et dans les produits des équipementiers (Juniper, Cisco...). Une question me vient à l'esprit, comment adresses tu ces problématiques (récentes ?) depuis plus de 10 ans ? Sachant que pour mener à bien ce genre de mission il faut aller taper dans le code du Virtual switch de l'hyperviseur (les switchs virtuels distribués n'ont pas 10 ans d'existences) ... Le sujet n'est pas simple quand tu es à l'interieur d'un DC maintenant si tu l'étend à plusieurs... -- Adrien Le 28 mars 2013 00:18, Gunther Ozerito gozer...@gmail.com a écrit : Et encore faux. Encapsuler du niveau 2 dans du niveau 3 n'est pas du SDN. Openflow et openstack non plus. Nvgre et vxlan non plus... Nexus 1000v et Openvswitch, toujours pas... Cloudstack quantum ? Non mais a la limite on se rapproche
[FRnOG] [JOBS] SdV Recherche un administrateur réseau et telecom
SdV Plurimedia, hébergeur basé à Strasbourg recherche pour renforcer ses équipes un administrateur réseau et Telecom confirmé. Le poste à pourvoir est un CDI basé à Strasbourg, le salaire est négociable selon le niveau d'expérience. La personne recherchée participera à la gestion et à l'évolution de notre réseau IPv4/v6 (AS8839) sous la direction du directeur technique. La personne recherchée devra posséder une parfaite connaissance et une expérience significative dans les domaines suivants: - Architecture des réseaux (LAN,WAN,backbone IP) - Routage IPv4 et IPv6 (OSPF,BGP4+) - MPLS, MPLS-VPN - Sécurité et redondance des réseaux - Déploiement de réseau en datacenter. - Cisco IOS Les compétences suivantes seront grandement appréciées: - Maitrise de JUNOS - Maitrise de Linux - Connaissance des solutions des constructeurs Arbor networks, Fortinet - Connaissance des problématiques techniques liées à l'hébergement de sites à forte audience. Si vous vous reconnaissez dans ce descriptif, que vous êtes rigoureux et avez envie de travailler dans une entreprise à taille humaine n'hésitez pas à nous envoyer votre CV à sa...@sdv.fr Salim Gasmi --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [JOBS] SdV Recherche un administrateur réseau et telecom
je cherche ce genre de poste mais sur Rennes plutot, personne n'a quelques choses à me proposer? Le 28 mars 2013 15:09, Salim Gasmi sa...@sdv.fr a écrit : SdV Plurimedia, hébergeur basé à Strasbourg recherche pour renforcer ses équipes un administrateur réseau et Telecom confirmé. Le poste à pourvoir est un CDI basé à Strasbourg, le salaire est négociable selon le niveau d'expérience. La personne recherchée participera à la gestion et à l'évolution de notre réseau IPv4/v6 (AS8839) sous la direction du directeur technique. La personne recherchée devra posséder une parfaite connaissance et une expérience significative dans les domaines suivants: - Architecture des réseaux (LAN,WAN,backbone IP) - Routage IPv4 et IPv6 (OSPF,BGP4+) - MPLS, MPLS-VPN - Sécurité et redondance des réseaux - Déploiement de réseau en datacenter. - Cisco IOS Les compétences suivantes seront grandement appréciées: - Maitrise de JUNOS - Maitrise de Linux - Connaissance des solutions des constructeurs Arbor networks, Fortinet - Connaissance des problématiques techniques liées à l'hébergement de sites à forte audience. Si vous vous reconnaissez dans ce descriptif, que vous êtes rigoureux et avez envie de travailler dans une entreprise à taille humaine n'hésitez pas à nous envoyer votre CV à sa...@sdv.fr Salim Gasmi --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Attaque Spamhaus/Cloudflare et les points d'échange
Bonjour, On Thu, Mar 28, 2013 at 11:36:37AM +0100, Benjamin BILLON wrote: Je suis pas trop bien sur de comprendre, de mon côté je vois les ASN 1200 et 5659 annoncés par mes upstreams, mais les plages utilisées par LINX et AMSIX ne sont pas reçues (donc je suppose pas annoncées). AS1200 annonce 195.69.144.0/22 en no-export. Les IPs sur ces plages sont pourtant pingable, mais via les routes par défaut, via les upstreams présents sur ces IX. Il y a de fortes chances que les participants à ces IX ont la route dans leur IGP. Les bonnes pratiques sont de ne pas annoncer ces blocs, no-export ou pas, et de filter les éventuelles annonces qu'on pourrait recevoir pour eux. -- Bertrand Yvain http://www.IELO.net/ signature.asc Description: Digital signature
[FRnOG] [MISC] Liste de CIDR
Bonsoir, jespre crire sur la bonne liste. je cherche a savoir sil y a dautres sites qui maintienne des listes de plages dadresse IP il y a des sites que vous conseiller pour avoir ce genre de rsultats. https://www.countryipblocks.net/country_selection.php javais pour habitude de faire un drop de tout sauf la france. je me vois mal demander aux utilisateurs leur adresse IP sans arrt jai du ouvrir pour lallemagne et facebook. je me suis retrouv avec un utilisateur en contact sur facebook mais le site rpondait pas a cause du chemin. /var/log/apache2/access.log:69.171.224.113 - - [26/Mar/2013:22:06:07 +0100] GET /oc5/ HTTP/1.1 206 1494 - facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php) /var/log/apache2/access.log:69.171.224.112 - - [26/Mar/2013:22:06:09 +0100] GET /oc5/core/img/logo.png HTTP/1.1 206 6202 - facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php) /var/log/apache2/access.log:69.171.224.117 - - [26/Mar/2013:22:06:10 +0100] GET /oc5/core/img/logo.png HTTP/1.1 206 6202 - facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php) donc, jai ouvert le 80 sur le web, et bingo en moins de 24h. 1 tentative daccs non autoriser depuis Tawan. jai un fail2ban qui fait bien sont boulot mais jaime pas trop a que lon fouille comme a. je peux aussi faire des liste pour des drop. /usr/sbin/ipset -N taiwan nethash sh /home/celres/iptables/taiwan.sh /sbin/iptables -A INPUT -m set --match-set taiwan src -j DROP contenu de taiwan.sh #!/bin/bash ipset --add taiwan 1.34.0.0/15 ipset --add taiwan 1.160.0.0/12 ipset --add taiwan 1.200.0.0/16 ipset --add taiwan 27.51.0.0/16 (3573 lignes) ma question est simple peut on faire confiance aux listes CIDR ? http://pastebin.com/bN3yKJse du coup jai interdit taiwan et la chine. je nai pas accs aux diffrents switch sur le rseau. ladresse IP est directement visible du net (NAT, PAT, autre acronyme je sais pas) a me drange pas du tout mais faut un iptables drrire oblig au risque de ce faire attaquer a gogo en ssh. si vous avez un retour dexprience et/ou autres solutions.
Re: [FRnOG] [MISC] SDN et la neutralité du réseau
Et vous un standard et une proposition de norme … :-) Le 28 mars 2013 à 22:46, Adrien Pestel pestoui...@gmail.com a écrit : Et toi tu confonds un concept et un standard... Bonne lecture : https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf Adrien Le 28 mars 2013 11:58, Gunther Ozerito gozer...@gmail.com a écrit : Toujours pas ... Tu confonds SDN, Openflow, et les networks overlay ... c'est pas de bol quand même, suffit juste de lire les docs pour pas les confondre. *SDN* : possibilité donné dans un réseau de modifier les comportements de routing et de forwarding sur des critères normalement pas pris en compte par les protocoles standard. Ex : par defaut, on route sur la destination, BGP me donne des informations de reach de destination, qu'il compile pour alimenter la RIB, laquelle elle même impacte la FIB pour savoir par quelle interface vont sortir les paquets. Je veux faire du routage différencié en fonction de la source (toutes les IPs venant de mon DC01 : next-hop = toto, pour tout le reste, conforme à la RIB, next-hop = tata), avec au hasard du Policy Based Routing. Si en plus je pilote les ACLs de mon PBR avec un script qui par exemple va modifier ces entrées en fonction de la latence mesurée sur les liens = SDN. *application* : backbone, datacenter, ... *Openflow *: protocole en cours de standardisation pour échanger des infos entre un control plane externe, et un dataplane d'équipement réseau standard. Evite d'avoir à scripter pour passer des commandes en SSH sur les routeurs, et permet aussi de faire des trucs que les commandes CLI ne permettent pas (au hasard, injecter des infos directement dans la RIB ou la FIB, sans avoir de protocole dynamique). *application* : backbone, datacenter, ... SDN - openflow interop lab http://incntre.iu.edu/SDNlab : lancé en 2011 pour voir comment accoster les deux technos entre elles. Openstack Quantum, Nicira, etc : type de collecteurs partiellement ou totalement compatible Openflow, mais aussi avec des fonctionnalités propriétaires ou d'autres protocoles (netconf). VXLAN, NVGRE et nicira stt : techno de network overlay, consistant à encapsuler les trames ethernets dans des trames de niveau 3 (GRE ou UDP). Aucun rapport avec SDN, ce sont des technos qu'on peut éventuellement mettre en concurrence avec VPLS, L2TPv3, OTV, etc... Donc non le SDN c'est pas que pour de la virtualisation, et ce depuis longtemps, et c'est une notion qui existe depuis très longtemps dans le backbone (Performance Routing chez Cisco, Path Computation Elementhttp://en.wikipedia.org/wiki/Path_computation_elementdepuis des années à l'IETF). Juste pour bien comprendre, sans SDN, vous me direz comment vous injectez du trafic purement voix dans un MPLS TE entre deux sites distants, en assurant que le trafic non classifié voix au niveau DSCP ne passe pas dans le tunnel... Et non, ce n'est pas du tout compatible avec la neutralité du net, mais on s'en fout car on est dans la vraie vie, pas à Standford, et y a des contraintes réelles qui font qu'on doit bosser. Aller encore deux bullshits marketing pour bien se mélanger les pinceaux : trill et lisp. SDN ou pas ? Le 28 mars 2013 09:55, Adrien Pestel pestoui...@gmail.com a écrit : Je reprend pour être plus clair (il faut être vigilant quand on poste sur FrNog les experts ont vite fait de nous rabaisser :)) Problématique : - Dans un environnement virtualisé (machine virtuelle) les caractéristiques réseaux (QoS, ACL, VLAN...) doivent pouvoir dynamiquement se déplacer dans le Datacanter (au grès de l'hyperviseur) Concept : - Rendre les équipements réseaux (virtual switch, switch physique, routeurs) plus bêtes (commutation, application de règles en remontant les flows) piloté par un composant applicatif plus intelligent / centralisé Implementation : - Nicira - Chaîne Openflow / Openvswitch / NOX | Beacon - ... Si tu prends les éléments de manière individuelle ou atomique cela ne constitue pas du SDN, c'est l'ensemble de la chaîne qui le constitue. Je te rejoins sur le fait que c'est un terme Marketing (Cloud ?) mais derrière cela adresse des contraintes de sécurité, de QoS et surtout, surtout d'exploitation. On peut toujours tout faire maison mais : 1) ce sera peut être plus coûteux 2) ce sera peut être plus difficile à maintenir et moins industrialisé Cela revient au débat, moi j'utilise un routeur Quagga parce que je me sens capable d'aller modifier le code du daemon BGP alors que je ne fais pas confiance au support et dans les produits des équipementiers (Juniper, Cisco...). Une question me vient à l'esprit, comment adresses tu ces problématiques (récentes ?) depuis plus de 10 ans ? Sachant que pour mener à bien ce genre de mission il faut aller taper dans le code du Virtual switch de l'hyperviseur (les switchs virtuels distribués n'ont pas 10 ans
Re: [FRnOG] [MISC] Liste de CIDR
Bonjour, Je ne comprends pas ta problématique. Si tu ne veux pas que les gens accèdent, mets de l'authentification et un fail2ban. Sinon, hé bien tu es sur internet, c'est mondial :) Tu auras toujours du faux positif et du faux négatif dans ce type de listes, sans parler des VPN, des rebonds par des serveurs divers et variés... Cdt, Aurélien. Envoyé depuis mon fax satellitaire On 28 mars 2013, at 21:55, Tony Chambon tony.cham...@univ-paris8.fr wrote: Bonsoir, j'espère écrire sur la bonne liste. je cherche a savoir s'il y a d'autres sites qui maintienne des listes de plages d'adresse IP il y a des sites que vous conseiller pour avoir ce genre de résultats. https://www.countryipblocks.net/country_selection.php j'avais pour habitude de faire un drop de tout sauf la france. je me vois mal demander aux utilisateurs leur adresse IP sans arrêt j'ai du ouvrir pour l'allemagne et facebook. je me suis retrouvé avec un utilisateur en contact sur facebook mais le site répondait pas a cause du chemin. /var/log/apache2/access.log:69.171.224.113 - - [26/Mar/2013:22:06:07 +0100] GET /oc5/ HTTP/1.1 206 1494 - facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php) /var/log/apache2/access.log:69.171.224.112 - - [26/Mar/2013:22:06:09 +0100] GET /oc5/core/img/logo.png HTTP/1.1 206 6202 - facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php) /var/log/apache2/access.log:69.171.224.117 - - [26/Mar/2013:22:06:10 +0100] GET /oc5/core/img/logo.png HTTP/1.1 206 6202 - facebookexternalhit/1.1 (+http://www.facebook.com/externalhit_uatext.php) donc, j'ai ouvert le 80 sur le web, et bingo en moins de 24h. 1 tentative d'accès non autoriser depuis Taîwan. j'ai un fail2ban qui fait bien sont boulot mais j'aime pas trop ça que l'on fouille comme ça. je peux aussi faire des liste pour des drop. /usr/sbin/ipset -N taiwan nethash sh /home/celres/iptables/taiwan.sh /sbin/iptables -A INPUT -m set --match-set taiwan src -j DROP contenu de taiwan.sh #!/bin/bash ipset --add taiwan 1.34.0.0/15 ipset --add taiwan 1.160.0.0/12 ipset --add taiwan 1.200.0.0/16 ipset --add taiwan 27.51.0.0/16 (3573 lignes) ma question est simple peut on faire confiance aux listes CIDR ? http://pastebin.com/bN3yKJse du coup j'ai interdit taiwan et la chine. je n'ai pas accès aux différents switch sur le réseau. l'adresse IP est directement visible du net (NAT, PAT, autre acronyme je sais pas) ça me dérange pas du tout mais faut un iptables dérrière obligé au risque de ce faire attaquer a gogo en ssh. si vous avez un retour d'expérience et/ou autres solutions. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] SDN et la neutralité du réseau
OpenFlow is the first standard interface designed specifically for SDN Le 28 mars 2013 22:53, Kavé Salamatian kave.salamat...@univ-savoie.fr a écrit : Et vous un standard et une proposition de norme … :-) Le 28 mars 2013 à 22:46, Adrien Pestel pestoui...@gmail.com a écrit : Et toi tu confonds un concept et un standard... Bonne lecture : https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf Adrien Le 28 mars 2013 11:58, Gunther Ozerito gozer...@gmail.com a écrit : Toujours pas ... Tu confonds SDN, Openflow, et les networks overlay ... c'est pas de bol quand même, suffit juste de lire les docs pour pas les confondre. *SDN* : possibilité donné dans un réseau de modifier les comportements de routing et de forwarding sur des critères normalement pas pris en compte par les protocoles standard. Ex : par defaut, on route sur la destination, BGP me donne des informations de reach de destination, qu'il compile pour alimenter la RIB, laquelle elle même impacte la FIB pour savoir par quelle interface vont sortir les paquets. Je veux faire du routage différencié en fonction de la source (toutes les IPs venant de mon DC01 : next-hop = toto, pour tout le reste, conforme à la RIB, next-hop = tata), avec au hasard du Policy Based Routing. Si en plus je pilote les ACLs de mon PBR avec un script qui par exemple va modifier ces entrées en fonction de la latence mesurée sur les liens = SDN. *application* : backbone, datacenter, ... *Openflow *: protocole en cours de standardisation pour échanger des infos entre un control plane externe, et un dataplane d'équipement réseau standard. Evite d'avoir à scripter pour passer des commandes en SSH sur les routeurs, et permet aussi de faire des trucs que les commandes CLI ne permettent pas (au hasard, injecter des infos directement dans la RIB ou la FIB, sans avoir de protocole dynamique). *application* : backbone, datacenter, ... SDN - openflow interop lab http://incntre.iu.edu/SDNlab : lancé en 2011 pour voir comment accoster les deux technos entre elles. Openstack Quantum, Nicira, etc : type de collecteurs partiellement ou totalement compatible Openflow, mais aussi avec des fonctionnalités propriétaires ou d'autres protocoles (netconf). VXLAN, NVGRE et nicira stt : techno de network overlay, consistant à encapsuler les trames ethernets dans des trames de niveau 3 (GRE ou UDP). Aucun rapport avec SDN, ce sont des technos qu'on peut éventuellement mettre en concurrence avec VPLS, L2TPv3, OTV, etc... Donc non le SDN c'est pas que pour de la virtualisation, et ce depuis longtemps, et c'est une notion qui existe depuis très longtemps dans le backbone (Performance Routing chez Cisco, Path Computation Element http://en.wikipedia.org/wiki/Path_computation_elementdepuis des années à l'IETF). Juste pour bien comprendre, sans SDN, vous me direz comment vous injectez du trafic purement voix dans un MPLS TE entre deux sites distants, en assurant que le trafic non classifié voix au niveau DSCP ne passe pas dans le tunnel... Et non, ce n'est pas du tout compatible avec la neutralité du net, mais on s'en fout car on est dans la vraie vie, pas à Standford, et y a des contraintes réelles qui font qu'on doit bosser. Aller encore deux bullshits marketing pour bien se mélanger les pinceaux : trill et lisp. SDN ou pas ? Le 28 mars 2013 09:55, Adrien Pestel pestoui...@gmail.com a écrit : Je reprend pour être plus clair (il faut être vigilant quand on poste sur FrNog les experts ont vite fait de nous rabaisser :)) Problématique : - Dans un environnement virtualisé (machine virtuelle) les caractéristiques réseaux (QoS, ACL, VLAN...) doivent pouvoir dynamiquement se déplacer dans le Datacanter (au grès de l'hyperviseur) Concept : - Rendre les équipements réseaux (virtual switch, switch physique, routeurs) plus bêtes (commutation, application de règles en remontant les flows) piloté par un composant applicatif plus intelligent / centralisé Implementation : - Nicira - Chaîne Openflow / Openvswitch / NOX | Beacon - ... Si tu prends les éléments de manière individuelle ou atomique cela ne constitue pas du SDN, c'est l'ensemble de la chaîne qui le constitue. Je te rejoins sur le fait que c'est un terme Marketing (Cloud ?) mais derrière cela adresse des contraintes de sécurité, de QoS et surtout, surtout d'exploitation. On peut toujours tout faire maison mais : 1) ce sera peut être plus coûteux 2) ce sera peut être plus difficile à maintenir et moins industrialisé Cela revient au débat, moi j'utilise un routeur Quagga parce que je me sens capable d'aller modifier le code du daemon BGP alors que je ne fais pas confiance au support et dans les produits des équipementiers (Juniper, Cisco...). Une question me vient à l'esprit,
Re: [FRnOG] [MISC] SDN et la neutralité du réseau
Openflow n'est pas encore un standard, mais c'est une interface générique. Le mot standard en Français n'est pas équivalent à standard en anglais. Cette phrase doit se traduire : Open est la première interface générique pour les SDN. OpenFlow set considéré comme une des solutions possible pour le SDN et il y'a eu à ce sujet un BoF meeting à l'IETF en 2011. Pour une analyse plus complète de l'état de standardisation IETF d'openflow et des SDNs voir http://networkstatic.net/new-ietf-sdn-drafts/ Ceci dit le concept même de SDN c'est d'être capable d'implémenter sur son routeur des solutions non standard, voir de faire co-exister sur une même plateforme matérielle des approches compatible IPv4/v6 et des approches clean-slates (genre CCN). Kv Le 28 mars 2013 à 22:56, Adrien Pestel pestoui...@gmail.com a écrit : OpenFlow is the first standard interface designed specifically for SDN Le 28 mars 2013 22:53, Kavé Salamatian kave.salamat...@univ-savoie.fr a écrit : Et vous un standard et une proposition de norme … :-) Le 28 mars 2013 à 22:46, Adrien Pestel pestoui...@gmail.com a écrit : Et toi tu confonds un concept et un standard... Bonne lecture : https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf Adrien Le 28 mars 2013 11:58, Gunther Ozerito gozer...@gmail.com a écrit : Toujours pas ... Tu confonds SDN, Openflow, et les networks overlay ... c'est pas de bol quand même, suffit juste de lire les docs pour pas les confondre. *SDN* : possibilité donné dans un réseau de modifier les comportements de routing et de forwarding sur des critères normalement pas pris en compte par les protocoles standard. Ex : par defaut, on route sur la destination, BGP me donne des informations de reach de destination, qu'il compile pour alimenter la RIB, laquelle elle même impacte la FIB pour savoir par quelle interface vont sortir les paquets. Je veux faire du routage différencié en fonction de la source (toutes les IPs venant de mon DC01 : next-hop = toto, pour tout le reste, conforme à la RIB, next-hop = tata), avec au hasard du Policy Based Routing. Si en plus je pilote les ACLs de mon PBR avec un script qui par exemple va modifier ces entrées en fonction de la latence mesurée sur les liens = SDN. *application* : backbone, datacenter, ... *Openflow *: protocole en cours de standardisation pour échanger des infos entre un control plane externe, et un dataplane d'équipement réseau standard. Evite d'avoir à scripter pour passer des commandes en SSH sur les routeurs, et permet aussi de faire des trucs que les commandes CLI ne permettent pas (au hasard, injecter des infos directement dans la RIB ou la FIB, sans avoir de protocole dynamique). *application* : backbone, datacenter, ... SDN - openflow interop lab http://incntre.iu.edu/SDNlab : lancé en 2011 pour voir comment accoster les deux technos entre elles. Openstack Quantum, Nicira, etc : type de collecteurs partiellement ou totalement compatible Openflow, mais aussi avec des fonctionnalités propriétaires ou d'autres protocoles (netconf). VXLAN, NVGRE et nicira stt : techno de network overlay, consistant à encapsuler les trames ethernets dans des trames de niveau 3 (GRE ou UDP). Aucun rapport avec SDN, ce sont des technos qu'on peut éventuellement mettre en concurrence avec VPLS, L2TPv3, OTV, etc... Donc non le SDN c'est pas que pour de la virtualisation, et ce depuis longtemps, et c'est une notion qui existe depuis très longtemps dans le backbone (Performance Routing chez Cisco, Path Computation Elementhttp://en.wikipedia.org/wiki/Path_computation_elementdepuis des années à l'IETF). Juste pour bien comprendre, sans SDN, vous me direz comment vous injectez du trafic purement voix dans un MPLS TE entre deux sites distants, en assurant que le trafic non classifié voix au niveau DSCP ne passe pas dans le tunnel... Et non, ce n'est pas du tout compatible avec la neutralité du net, mais on s'en fout car on est dans la vraie vie, pas à Standford, et y a des contraintes réelles qui font qu'on doit bosser. Aller encore deux bullshits marketing pour bien se mélanger les pinceaux : trill et lisp. SDN ou pas ? Le 28 mars 2013 09:55, Adrien Pestel pestoui...@gmail.com a écrit : Je reprend pour être plus clair (il faut être vigilant quand on poste sur FrNog les experts ont vite fait de nous rabaisser :)) Problématique : - Dans un environnement virtualisé (machine virtuelle) les caractéristiques réseaux (QoS, ACL, VLAN...) doivent pouvoir dynamiquement se déplacer dans le Datacanter (au grès de l'hyperviseur) Concept : - Rendre les équipements réseaux (virtual switch, switch physique, routeurs) plus bêtes (commutation, application de règles en remontant les flows) piloté par un composant applicatif plus intelligent / centralisé Implementation :
Re: [FRnOG] [MISC] SDN et la neutralité du réseau
Il est clair que l'Open Networking Summit est un organisme de standardisation reconnu. Parce que Fuck les RFC, c'est ça ? http://www.1-4-5.net/~dmm/talks/sdn_is_an_architecture_wtc2012.pdf Slide programmable network architecture : les propositions d'extensions pour des protocoles existants sont TRES nombreuses pour le coup ... Le 28 mars 2013 22:46, Adrien Pestel pestoui...@gmail.com a écrit : Et toi tu confonds un concept et un standard... Bonne lecture : https://www.opennetworking.org/images/stories/downloads/white-papers/wp-sdn-newnorm.pdf Adrien Le 28 mars 2013 11:58, Gunther Ozerito gozer...@gmail.com a écrit : Toujours pas ... Tu confonds SDN, Openflow, et les networks overlay ... c'est pas de bol quand même, suffit juste de lire les docs pour pas les confondre. *SDN* : possibilité donné dans un réseau de modifier les comportements de routing et de forwarding sur des critères normalement pas pris en compte par les protocoles standard. Ex : par defaut, on route sur la destination, BGP me donne des informations de reach de destination, qu'il compile pour alimenter la RIB, laquelle elle même impacte la FIB pour savoir par quelle interface vont sortir les paquets. Je veux faire du routage différencié en fonction de la source (toutes les IPs venant de mon DC01 : next-hop = toto, pour tout le reste, conforme à la RIB, next-hop = tata), avec au hasard du Policy Based Routing. Si en plus je pilote les ACLs de mon PBR avec un script qui par exemple va modifier ces entrées en fonction de la latence mesurée sur les liens = SDN. *application* : backbone, datacenter, ... *Openflow *: protocole en cours de standardisation pour échanger des infos entre un control plane externe, et un dataplane d'équipement réseau standard. Evite d'avoir à scripter pour passer des commandes en SSH sur les routeurs, et permet aussi de faire des trucs que les commandes CLI ne permettent pas (au hasard, injecter des infos directement dans la RIB ou la FIB, sans avoir de protocole dynamique). *application* : backbone, datacenter, ... SDN - openflow interop lab http://incntre.iu.edu/SDNlab : lancé en 2011 pour voir comment accoster les deux technos entre elles. Openstack Quantum, Nicira, etc : type de collecteurs partiellement ou totalement compatible Openflow, mais aussi avec des fonctionnalités propriétaires ou d'autres protocoles (netconf). VXLAN, NVGRE et nicira stt : techno de network overlay, consistant à encapsuler les trames ethernets dans des trames de niveau 3 (GRE ou UDP). Aucun rapport avec SDN, ce sont des technos qu'on peut éventuellement mettre en concurrence avec VPLS, L2TPv3, OTV, etc... Donc non le SDN c'est pas que pour de la virtualisation, et ce depuis longtemps, et c'est une notion qui existe depuis très longtemps dans le backbone (Performance Routing chez Cisco, Path Computation Elementhttp://en.wikipedia.org/wiki/Path_computation_elementdepuis des années à l'IETF). Juste pour bien comprendre, sans SDN, vous me direz comment vous injectez du trafic purement voix dans un MPLS TE entre deux sites distants, en assurant que le trafic non classifié voix au niveau DSCP ne passe pas dans le tunnel... Et non, ce n'est pas du tout compatible avec la neutralité du net, mais on s'en fout car on est dans la vraie vie, pas à Standford, et y a des contraintes réelles qui font qu'on doit bosser. Aller encore deux bullshits marketing pour bien se mélanger les pinceaux : trill et lisp. SDN ou pas ? Le 28 mars 2013 09:55, Adrien Pestel pestoui...@gmail.com a écrit : Je reprend pour être plus clair (il faut être vigilant quand on poste sur FrNog les experts ont vite fait de nous rabaisser :)) Problématique : - Dans un environnement virtualisé (machine virtuelle) les caractéristiques réseaux (QoS, ACL, VLAN...) doivent pouvoir dynamiquement se déplacer dans le Datacanter (au grès de l'hyperviseur) Concept : - Rendre les équipements réseaux (virtual switch, switch physique, routeurs) plus bêtes (commutation, application de règles en remontant les flows) piloté par un composant applicatif plus intelligent / centralisé Implementation : - Nicira - Chaîne Openflow / Openvswitch / NOX | Beacon - ... Si tu prends les éléments de manière individuelle ou atomique cela ne constitue pas du SDN, c'est l'ensemble de la chaîne qui le constitue. Je te rejoins sur le fait que c'est un terme Marketing (Cloud ?) mais derrière cela adresse des contraintes de sécurité, de QoS et surtout, surtout d'exploitation. On peut toujours tout faire maison mais : 1) ce sera peut être plus coûteux 2) ce sera peut être plus difficile à maintenir et moins industrialisé Cela revient au débat, moi j'utilise un routeur Quagga parce que je me sens capable d'aller modifier le code du daemon BGP alors que je ne fais pas confiance au support et dans les produits des équipementiers (Juniper, Cisco...). Une question me vient à l'esprit,
