Re: [FRnOG] [ALERT] Test de la robustesse de la liste
On dirait bien :) Comme quoi les vieilles technos sont bien faites. On Tue, Mar 5, 2024 at 5:11 PM Stephane Bortzmeyer wrote: > Est-ce qu'elle marche quand Facebook et Instagram sont en panne ? > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Alexis Savin --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [MISC] SDN et la neutralité du réseau
Bonjour, Pour revenir à la notion de neutralité, il me semble, d'après mes lectures, qu'openflow et le concept de sdn en général sont plus destinés à gérer des flux backbones (où dans tous les cas la notion de neutralité est toute relative) et pas forcément du trafic public (internet). L'effet sur la neutralité de l'internet me paraît donc relativement faible. L'exemple de qui me vient à l'esprit est un papier de Google ( http://www.wired.com/wiredenterprise/2012/04/going-with-the-flow-google/) sur leur utilisation d'openflow, principalement utilisé pour gérer les lourds flux applicatifs et de réplication. Le trafic public, autrement dit le trafic internet reste géré de façon classique. Je vois mal openflow être utilisé frontalement sur des réseaux publics. L’intérêt me semble limité pour un trafic disparate. Cordialement. 2013/3/26 Stephane Bortzmeyer bortzme...@nic.fr On Mon, Mar 25, 2013 at 07:19:42PM +0100, Olivier Cochard-Labbé oliv...@cochard.me wrote a message of 24 lines which said: 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… D'autres techniques permettent de faire cela, par exemple FlowSpec http://www.bortzmeyer.org/5575.html. Je dirais que c'est comme la QoS, tout dépend de qui l'utilise (réseau privé ? Ouvert au public ?) et comment. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Résolution d'un nombre important d'adresses IP
Bonjour, Un truc vraiment tout simple qui répond bien au besoin exprimé : GeoIP-1.4.8-1.1.fc16.x86_64.rpm. Usage: geoiplookup [-d custom_dir] [-f custom_file] [-v] [-i] ipaddress|hostname Sinon http://search.cpan.org/~borisz/Geo-IP-1.40/lib/Geo/IP.pm pour ceux qui apprécient Perl. Ou bien encore http://www.team-cymru.org/Services/ip-to-asn.html qui fournit pas mal de services utiles. Bref, il y a du choix ;-) Cordialement. 2012/9/18 XF theiemsolut...@gmail.com Merci pour ces quelques réponses J'ai oublié de préciser que nous privilégions les solutions non payantes (oui mon SOC est radin ;-) Je vais regarder du côté des RIR pour parfaire la base de donnée existante Cordialement, Xavier -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Solarus Envoyé : mardi 18 septembre 2012 20:13 À : frnog@frnog.org Objet : Re: [FRnOG] [TECH] Résolution d'un nombre important d'adresses IP Le 18/09/2012 19:57, XF a écrit : L’inconvénient c’est que la base de donnée est statique et nous nous retrouvons avec pas mal d’adresses non résolues. Si ce n'est que ça, vous pouvez alimenter votre base de données avec les infos whois fournies par les RIR. Vous trouverez ainsi à quel opérateur et donc quel pays est attribué un préfixe. La plupart du temps c'est beaucoup plus à jour que les bases GeoIP. (exemple des AS français détectés comme russes ou américains) My 2 cents. Solarus. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [TECH] Detecter DDos outils et null-router sur quagga
2012/9/8 Emmanuel Thierry m...@sekil.fr Bonjour, Le 6 sept. 2012 à 15:06, Frederic Dhieux a écrit : Oui, iptables s'écroule quand on commence à mettre beaucoup de règles à la suite Est-ce qu'on a une idée du beaucoup en question ? 100 ? 1000 ? 1 ? C'est très dépendant de la façon de coder les règles et de la machine. 100 règles codées sans réelle optimisation peuvent déjà poser problème là où un petit millier, optimisé passera tout seul. Reste qu'un pare-feu implémentant plusieurs centaines de règles reste une aberration. Cordialement. --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Detecter DDos outils et null-router sur quagga
Bonjour, Concernant le null routing, il y a de très bon exemples sur l'internet. Il faut bien noter qu'il existe deux pratiques : * blacklister une/plusieures sources * blacklister une destination La première est relativement complexe à mettre en place sur une petite infrastructure car nécessite la mise en place de l'URPF (Unicast Reverse Path Forwarding). La seconde est utilisée en désespoir de cause, il s'agit de sacrifier une IP (le client attaqué), pour sauver les autres. Un peu de doc ici : http://www.cisco.com/web/about/security/intelligence/ipv6_rtbh.html Dans le cas évoqué, iptable parait quand même plus adapté. Quand à la détection, c'est pour le coup bien plus complexe. Je n'ai pas connaissance d'un produit non commercial fournissant ce service. Les technologies les plus connues sont sans doute celles de cisco et d'arbornetworks. Autrement, il existe des services cloud pour se prémunir de ce genre d'attaque. Verisign propose quelque chose de sympa, mais encore difficilement accessible financièrement. Si aucune de ces solutions ne convient, il reste l'analyse statistique du trafic via des scripts / programmes développés en internes. Mais pour le coup, concernant la mitigation, pas de solution miracle, avoir de gros tuyaux et de gros équipements de filtrage, ou bien, encore, souscrire une offre chez un transitaire ou verisign. En espérant que ces infos vous seront utiles. Cordialement. 2012/9/6 Dominique Rousseau d.rouss...@nnx.com Le Thu, Sep 06, 2012 at 12:37:44PM +0100, Antoine Durant [ antoine.duran...@yahoo.fr] a écrit: Bonjour, J???aimerais connaitre les outils que vous utilisez pour détecter les attaques DDoS. Dans un premier temps j???aimerais tester des outils libre/open source. Que mettez vous en prod sur vos jolis réseaux ?? Pas très facile. Si tu connais le profil habituel de ton trafic, détecter les écarts sur les mesures de débit/pps des interfaces, et crier si y'a « 10 fois plus que d'habitude » Sur un routeur linux quagga, comment vous faites pour null-router une IP qui est méchante avec une machine du réseau ( a part débrancher le routeur :-D) ?? Ca dépend de ce que tu veux faire. Si c'est protéger la machine qui peut traiter le volume de trafic réseau, mais pas les requetes applicatives que ça induit, iptables conviendra bien. Sur la machine, parcequ'on peut supposer qu'il y a déjà un parefeu dessus, ce qui n'est probablement pas le cas (et ça serait pas vraiment une bonne idée) du routeur. Si tu veux préserver le reste du réseau, la route vers null0 comme mentionné ailleurs est une meilleure solution. Ca rend l'ip en question injoignable (mais bon, a priori, elle l'est déjà), et ça évite de saturer le reste du réseau, c'est contenu dans le routeur. Mieux, si ton/tes transitaires proposent des communautés ad-hoc, tu peux même leur dire de null-router le trafic à destination de l'ip concernée au niveau de leurs routeurs. -- 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/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Bonjour, Un grand classique, surement déjà vécu par beaucoup ici. Et malheureusement peu d'options efficaces. Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Cela peut permettre de désengorger ses liens et de ne pas impacter toute une plateforme. Bon courage. 2011/12/26 Charles Delorme fr...@suricat.net Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel ( 213.30.147.224/27) et global crossing (217.156.140.224/27) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Oui, il faut bien comprendre que de toute façon, le service est down mais que l'attaque impacte toute une plateforme, down elle aussi du coup. Ce qui inclus dans l'exemple, les services mail notamment qui pourtant ne sont pas visés initialement. Comme dit précédemment, la priorité est de désengorger les tuyaux, restaurer le maximum de service, puis enfin, voir comment stopper l'attaque, ou attendre la fin. 2011/12/26 Damien Fleuriot m...@my.gd Bah oui mais du coup il va se couper le service tout seul, certes seulement vers l'IP cible mais l'attaque aura réussi. Vu que la plupart du trafic semble être de l'UDP 80, est-ce qu'il aurait pas plus rapide de dropper ça par ses upstreams ? On 12/26/11 12:33 PM, Alexis Savin wrote: Il ne s'agit pas de bloquer les sources, mais le trafic à destination de l'ip attaquée, le temps que l'attaque cesse. La priorité lors d'une attaque comme celle-ci est de désengorger ses tuyaux pour rétablir le plus de services possible. 2011/12/26 Damien Fleuriot m...@my.gd mailto:m...@my.gd S'agissant très probablement d'IPs spoofées, je le vois mal blackholer 200k /32 générées aléatoirement ? Nan parce qu'au bout d'un moment le routeur upstream va en avoir marre, déjà, et ensuite au bout d'un moment ça va bloquer des vrais clients légitimes qui auront eu la malchance que leur IP soit générée :o On 12/26/11 12:27 PM, Alexis Savin wrote: Bonjour, Un grand classique, surement déjà vécu par beaucoup ici. Et malheureusement peu d'options efficaces. Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Cela peut permettre de désengorger ses liens et de ne pas impacter toute une plateforme. Bon courage. 2011/12/26 Charles Delorme fr...@suricat.net mailto:fr...@suricat.net Bonjour, Le père Noël nous a gâté et nous subissons au Sénat une attaque par déni de service depuis dimanche matin 7h heure locale. La très grosse majorité des paquets est en udp/80 à destination de nos deux liens, completel ( 213.30.147.224/27 http://213.30.147.224/27) et global crossing (217.156.140.224/27 http://217.156.140.224/27) et aussi un peu en udp/53. Nous tentons d'établir une liste d'adresses sources mais vous vous doutez qu'elle varie beaucoup. Les supports des deux opérateurs sont bien sûr prévenus. Si en plus certains d'entre vous ont la possibilité de bloquer au moins le traffic en udp/80 qui passerait par vos réseaux vers chez nous, ceci nous pemettrait de respirer un peu. Tout avis en la matière sera le bienvenu. Je passe par cette adresse mail perso car pour l'instant nos accès sont saturés. Merci beaucoup et joyeux Noël à tous :-) Charles Delorme --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- -=HADESIS=- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité EPITA 2010 / Integra -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Flow spec, c'est bien beau, mais tant que le client ne peut pas activer seul le filtrage il est difficile de l'exploiter de façon efficace, les attaquant étant généralement très réactifs et les services opérateurs lents à la détente... Enfin, quels sont les opérateurs à l'exploiter réellement ? Et à le proposer à leurs clients ? 2011/12/26 Texier, Matthieu mtex...@arbor.net Voila un réponse qui me semble faire preuve d'expérience :-) ! Sans compter que nos amis attaquants font souvent preuve d'une malice certaine et emmenant les administrateurs réseaux dans une direction afin de masquer une autre action mené en parallèle au niveau L7. Les attaques sont de plus en plus polymorphe. A bon entendeur ... Enfin, moi ce que je dis … je suis un peu vieux pour toutes ces choses la ! Du reste ma mémoire flanche un peu, je ne me rappelle plus bien comment activer flow spec sur tous les routeurs de nos chers industriels ? On Dec 26, 2011, at 2:35 PM, Thomas Mangin wrote: Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
Si tu as des exemples à citer, je pense que nombre d'entre nous sera preneur, ne serait-ce qu'à titre informatif. 2011/12/26 Texier, Matthieu mtex...@arbor.net C'est pour cela qu'il me semble sain de s'appuyer sur une offre de service opérateur spécialisé qui donne un engament de SLA associé. Des opérateurs proposent ce type de service et s'appuient pour cela sur une structure type SoC mettant à disposition des outils et des experts dans le domaine. Les outils sont toujours intéressants pour nourrir le débat technique … mais ils ne font pas tout … fort heureusement ! On Dec 26, 2011, at 2:58 PM, Alexis Savin wrote: Flow spec, c'est bien beau, mais tant que le client ne peut pas activer seul le filtrage il est difficile de l'exploiter de façon efficace, les attaquant étant généralement très réactifs et les services opérateurs lents à la détente... Enfin, quels sont les opérateurs à l'exploiter réellement ? Et à le proposer à leurs clients ? 2011/12/26 Texier, Matthieu mtex...@arbor.net Voila un réponse qui me semble faire preuve d'expérience :-) ! Sans compter que nos amis attaquants font souvent preuve d'une malice certaine et emmenant les administrateurs réseaux dans une direction afin de masquer une autre action mené en parallèle au niveau L7. Les attaques sont de plus en plus polymorphe. A bon entendeur ... Enfin, moi ce que je dis … je suis un peu vieux pour toutes ces choses la ! Du reste ma mémoire flanche un peu, je ne me rappelle plus bien comment activer flow spec sur tous les routeurs de nos chers industriels ? On Dec 26, 2011, at 2:35 PM, Thomas Mangin wrote: Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] Attaque en déni de service en cours
J'avais vaguement entendu parler de ce genre d'offre, il me semble d'ailleurs qu'il existe d'autres acteurs que Prolexic. Cependant, je trouve dommage de devoir re-router son trafic vers un tiers (de confiance ?) jouant le rôle d'intermédiaire. Implémenter une solution plus ou moins automatisée à base de flow spec et de remote black-hole ne serait pas bien complexe. Malheureusement, les opérateurs n'offrent pas, ou trop peu, les interfaçages nécessaires (certes, bien plus complexes à implémenter de façon sécurisée de leur côté). Reste que cela est bien dommage, les ddos impactant toute la chaine, travailler de concert serait, me parait-il, plus opportun que de confier notre trafic à d'autres. 2011/12/26 Breton, Oliver olivier.bre...@level3.com Bonjour, Je publie très rarement sur la liste mais pour répondre à la question d'Alexis, sachez que Level 3 propose une solution de protection DDoS très efficace puisque c'est celle de notre partenaire Prolexic. Il y a deux types d'offres : reroutage DNS en urgence (lors d'une activation en cours d'attaque) ou une solution pérenne de mitigation des flux au travers des tunnels GRE des routeurs client. Ne souhaitant pas me faire taxer de pub commerciale sur la liste, je ne m'étendrais pas mais n'hésitez pas à me consulter hors liste pour toute info complémentaire ou présentation du service. Olivier BRETON Envoyé de mon iPad2 Le 26 déc. 2011 à 15:22, Alexis Savin alexis.sa...@gmail.com a écrit : Si tu as des exemples à citer, je pense que nombre d'entre nous sera preneur, ne serait-ce qu'à titre informatif. 2011/12/26 Texier, Matthieu mtex...@arbor.net C'est pour cela qu'il me semble sain de s'appuyer sur une offre de service opérateur spécialisé qui donne un engament de SLA associé. Des opérateurs proposent ce type de service et s'appuient pour cela sur une structure type SoC mettant à disposition des outils et des experts dans le domaine. Les outils sont toujours intéressants pour nourrir le débat technique … mais ils ne font pas tout … fort heureusement ! On Dec 26, 2011, at 2:58 PM, Alexis Savin wrote: Flow spec, c'est bien beau, mais tant que le client ne peut pas activer seul le filtrage il est difficile de l'exploiter de façon efficace, les attaquant étant généralement très réactifs et les services opérateurs lents à la détente... Enfin, quels sont les opérateurs à l'exploiter réellement ? Et à le proposer à leurs clients ? 2011/12/26 Texier, Matthieu mtex...@arbor.net Voila un réponse qui me semble faire preuve d'expérience :-) ! Sans compter que nos amis attaquants font souvent preuve d'une malice certaine et emmenant les administrateurs réseaux dans une direction afin de masquer une autre action mené en parallèle au niveau L7. Les attaques sont de plus en plus polymorphe. A bon entendeur ... Enfin, moi ce que je dis … je suis un peu vieux pour toutes ces choses la ! Du reste ma mémoire flanche un peu, je ne me rappelle plus bien comment activer flow spec sur tous les routeurs de nos chers industriels ? On Dec 26, 2011, at 2:35 PM, Thomas Mangin wrote: Cela dépend surtout du profil de l'attaque. Pour un UDP flood sur un serveur web, un fournisseur qui peux ajouter un filtre flowspec sur ses connections EBGP ça aide surement beaucoup. Face a une attaque sur le L7 - la vie devient très dure ... Thomas On 26 Dec 2011, at 13:08, Texier, Matthieu wrote: L'ideal de ce genre de situation serait d'avoir souscrit à un service de détection et de mitigation d'attaque auprès de ses fournisseurs d'accès Internet. Le blackhole BGP étant techniquement une approche valide mais donnant raison aux attaquants. BGP flow spec n'est applicable que rarement sur les attaques distribuées ou à base d'IP spoofées. Je n'ai bien peur que seul un boitier de mitigation placé dans l'infrastructure du carrier ne puisse vous sortir de cette situation sans casse. Cordialement, Matthieu. On Dec 26, 2011, at 1:29 PM, Thomas Mangin wrote: On 26 Dec 2011, at 11:27, Alexis Savin wrote: Quelques techniques sont pourtant intéressantes à étudier, la plus intéressante étant celle du remote triggered black-hole pour peu que l'opérateur le supporte (http://tools.ietf.org/html/rfc5635). Au cas ou vous auriez rate la présentation - puisque c'est d'actualité. http://perso.nautile.fr/prez/fgabut-flowspec-frnog-final.pdf Thomas --- Liste de diffusion du FRnOG http://www.frnog.org/ Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité Cheers Matt. Matthieu Texier Consulting engineer EMEA mtex...@arbor.net +33 6 85 83 66 89 -- Alexis
[FRnOG] Re: Retours d'utilisation SFP+ 10G DWDM 80Km
Bonjour, Merci à tous pour vos feedback en privé. Pour ceux qui seraient intéressés par les quelques réponses : Il s'avère que cette option ne semble pas fiable et que peu la conseille. Il vaut donc mieux opter pour une autre technologie plus éprouvée. À bientôt. 2011/9/20 Alexis Savin alexis.sa...@gmail.com Bonjour à tous. Je travaille actuellement sur le déploiement d'une fibre boire entre 2 de nos sites, fibre que nous pensions éclairer à l'aide de SFP+ 10G DWDM colorés portant à 80 Km. J'ai récemment entendu dire que ces connectiques existaient bel et bien, mais depuis peu de temps et qu'elles n'étaient pas très fiables (du vraisemblablement à des soucis de dissipation de chaleur). Je me suis alors vu conseiller des connectiques XFP. Aussi, j'aimerai bien avoir quelques retour d'expérience. Certains d'entre vous on-t-il eu l'occasion de déployer de tels connecteurs SFP+ ? Si oui, rencontrez vous quelques soucis de performance et/ou de fiabilité ? Merci d'avance de vos retours. -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité
Re: [FRnOG] Global Crossing en panne
Bonjour, Idem, perte des sessions BGP et donc des liaisons directes. Plus de transit vers GLBX via Cogent. Le tout à partir de 17h10 et pendant 15-20 min. Ticket ouvert chez eux également. 2011/9/21 Frédéric Dhieux frede...@syn.fr Bonjour, On a constaté un souci sur un port de transit GBLX sur SFR Netcenter de notre côté également, la session BGP est tombée à 17:11 et remontée à 17:21. Entre 2 on a des gens qui ont fait le tour du globe pour se perdre dans le réseau de GBLX on ne sait où. Ticket ouvert de notre côté chez eux. Frédéric Le 21/09/2011 17:37, Damien [Abstergo] a écrit : Bonjour à tous, Est-ce que certains d'entre vous ont également constatés une panne de 17h10 à 17h30 de Global Crossing ? Je soulève la question, car le support indique qu'ils n'ont eu aucune panne et aucune remontée de clients ... Je me suis permis de mater quelques trucs réseau et Nerim semblent aussi avoir eu une grosse coupure ... http://stats.nerim.net/nav/**internet/globalcrossing/http://stats.nerim.net/nav/internet/globalcrossing/ @+ Damien --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/ -- -=HADESIS=- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité EPITA 2010 / Integra
[FRnOG] Retours d'utilisation SFP+ 10G DWDM 80Km
Bonjour à tous. Je travaille actuellement sur le déploiement d'une fibre boire entre 2 de nos sites, fibre que nous pensions éclairer à l'aide de SFP+ 10G DWDM colorés portant à 80 Km. J'ai récemment entendu dire que ces connectiques existaient bel et bien, mais depuis peu de temps et qu'elles n'étaient pas très fiables (du vraisemblablement à des soucis de dissipation de chaleur). Je me suis alors vu conseiller des connectiques XFP. Aussi, j'aimerai bien avoir quelques retour d'expérience. Certains d'entre vous on-t-il eu l'occasion de déployer de tels connecteurs SFP+ ? Si oui, rencontrez vous quelques soucis de performance et/ou de fiabilité ? Merci d'avance de vos retours. -- Alexis Savin Ingénieur Systèmes/Réseaux/Sécurité
