Re: [FRnOG] [MISC] GS - opérateur
Bonjour, Ce n'est pas une blague: tous les DC de Colt sont carrier neutral, stratégie depuis 2012. Sent from my iPhone On 25 oct. 2014, at 21:58, Raphael Mazelier r...@futomaki.net wrote: Est-ce que quelqu'un connaît d'autres DC ayant ce genre de politique vertueuse ? A mon sens les DCs d'Iliad sont très carrier neutral. Et DC4 devrait être encore mieux selon certaines sources (cross connect encore moins cher...) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/ [Colt Disclaimer] This email is from an entity of the Colt group of companies. Colt Group S.A., K2 Building, Forte 1, 2a rue Albert Borschette, L-1246 Luxembourg, R.C.S. B115679. Corporate and contact information for our entities can be found at http://colt.net/uk/en/Colt-Group-of-Companies/index.htm. Internet communications are not secure and Colt does not accept responsibility for the accurate transmission of this message. Content of this email or its attachments is not legally or contractually binding unless expressly previously agreed in writing by Colt --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] GS - opérateur
Bonjour, Ce n'est pas ce qu'on m'a répondu le jour où j'ai posé la question (mars 2013) : Pour répondre à votre question sur les autres opérateurs acceptés dans les datacenters COLT, seul OBS est accueilli sauf pour celui des Ulis où SFR est en cours de connexion. Par conséquent, toutes demandes de liaisons Internet, Lan2Lan, VPN...etc devra se faire via COLT, OBS ou SFR (Datacenter Les Ulis). Et quand le prix d'un lien intersite proposé par Colt vers/depuis son site est 3 fois le prix du marché... De mon côté ce n'était qu'une demande pour voir, mais je pense qu'il faut vous mettre d'accord dans votre équipe commerciale ;) Cordialement, Frédéric Le 26/10/14 08:26, Fedotova, Claire Svetlana Four a écrit : Bonjour, Ce n'est pas une blague: tous les DC de Colt sont carrier neutral, stratégie depuis 2012. Sent from my iPhone On 25 oct. 2014, at 21:58, Raphael Mazelier r...@futomaki.net wrote: Est-ce que quelqu'un connaît d'autres DC ayant ce genre de politique vertueuse ? A mon sens les DCs d'Iliad sont très carrier neutral. Et DC4 devrait être encore mieux selon certaines sources (cross connect encore moins cher...) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/ [Colt Disclaimer] This email is from an entity of the Colt group of companies. Colt Group S.A., K2 Building, Forte 1, 2a rue Albert Borschette, L-1246 Luxembourg, R.C.S. B115679. Corporate and contact information for our entities can be found at http://colt.net/uk/en/Colt-Group-of-Companies/index.htm. Internet communications are not secure and Colt does not accept responsibility for the accurate transmission of this message. Content of this email or its attachments is not legally or contractually binding unless expressly previously agreed in writing by Colt --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] GS - opérateur
On Sat, 2014-10-25 at 16:46 +0200, Sylvain Vallerot wrote: On 25/10/2014 12:47, Clement Cavadore wrote: On Sat, 2014-10-25 at 12:43 +0200, slesimple wrote: Propriété de DRT, en leasing par EQX. Alors pourquoi ca ne s'appelle pas Equinix PA5 par exemple ? PA2 et PA3 sont sur la propriété de DRT mais je crois que les installations appartiennent à Equinix (pas certain). Equinix loue uniquement les murs à DRT. Toute l'infrastructure est conçue et opérée par Equinix. Les installations appartiennent à Equinix. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] GS - opérateur
On Sat, 2014-10-25 at 18:05 +0200, Sylvain Vallerot wrote: Mais bon, nous voilà assez loin de GS qui eux aussi semblent open sur la venue d'opérateurs et le développement d'interco. On voit bien la différence de positionnement et là où la neutralité joue. Equinix a toujours été open sur la venue d'opérateurs et le développement d’interconnexion. Si Equinix n'était pas open, le campus PA2/PA3 ne serait pas le datacenter avec la plus forte densité réseau derrière Telehouse 2. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] GS - opérateur
Et l'equipe comnerciale (ils ne sont pas au courant de tout:) doit répondre ceci: nous avons, Verizon, Zayo (ex-neo), BT, OBS - dans les DC de Colt en France Je ne vous parle pas de l'Europe Forcement, c'est l'equipe de fiber survey et DCS qui negocient pour les carriers... L'équipe commerciale est la dernière à être au courant, peut-être de notre faute, nous allons y remédier. Excusez -nous:) Sent from my iPhone On 26 oct. 2014, at 10:58, Frederic Dhieux frede...@syn.fr wrote: Bonjour, Ce n'est pas ce qu'on m'a répondu le jour où j'ai posé la question (mars 2013) : Pour répondre à votre question sur les autres opérateurs acceptés dans les datacenters COLT, seul OBS est accueilli sauf pour celui des Ulis où SFR est en cours de connexion. Par conséquent, toutes demandes de liaisons Internet, Lan2Lan, VPN...etc devra se faire via COLT, OBS ou SFR (Datacenter Les Ulis). Et quand le prix d'un lien intersite proposé par Colt vers/depuis son site est 3 fois le prix du marché... De mon côté ce n'était qu'une demande pour voir, mais je pense qu'il faut vous mettre d'accord dans votre équipe commerciale ;) Cordialement, Frédéric Le 26/10/14 08:26, Fedotova, Claire Svetlana Four a écrit : Bonjour, Ce n'est pas une blague: tous les DC de Colt sont carrier neutral, stratégie depuis 2012. Sent from my iPhone On 25 oct. 2014, at 21:58, Raphael Mazelier r...@futomaki.net wrote: Est-ce que quelqu'un connaît d'autres DC ayant ce genre de politique vertueuse ? A mon sens les DCs d'Iliad sont très carrier neutral. Et DC4 devrait être encore mieux selon certaines sources (cross connect encore moins cher...) -- Raphael Mazelier --- Liste de diffusion du FRnOG http://www.frnog.org/ [Colt Disclaimer] This email is from an entity of the Colt group of companies. Colt Group S.A., K2 Building, Forte 1, 2a rue Albert Borschette, L-1246 Luxembourg, R.C.S. B115679. Corporate and contact information for our entities can be found at http://colt.net/uk/en/Colt-Group-of-Companies/index.htm. Internet communications are not secure and Colt does not accept responsibility for the accurate transmission of this message. Content of this email or its attachments is not legally or contractually binding unless expressly previously agreed in writing by Colt --- 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] GS - opérateur
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/10/2014 11:32, Nicolas DEFFAYET wrote: On Sat, 2014-10-25 at 18:05 +0200, Sylvain Vallerot wrote: Mais bon, nous voilà assez loin de GS qui eux aussi semblent open sur la venue d'opérateurs et le développement d'interco. On voit bien la différence de positionnement et là où la neutralité joue. Equinix a toujours été open sur la venue d'opérateurs Ne mélangeons pas :) et le développement d’interconnexion. Mon expérience dit le contraire : refus d'accueillir un GIX indépendant, délais interminables pour des devis de fibre, MRC excessives sur des circuits aux qualités très moyennes, conditions d'arrivées de câble changeantes et ingérables, GIX aux tarifs cassés (pour ne pas dire un gros mot)... Mais je suis ravi de cette politique et je vous appelle cette semaine pour avoir des tarifs orientés vers les coûts pour le passage de câbles 24 brins de racke/salle à rack/salle, vous allez pouvoir me faire changer d'avis ;) Et si vous me faites changer d'avis il y aura probablement bientôt une offre sympa de MMR sans pertes sur PA2 gérée par un opérateur d'opérateurs neutre. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlRNKaIACgkQJBGsD8mtnRGvMgD+J8VDa/sbysHDmUczjsMSIhK7 Xei6jQxP4ynBQZvJCFsBAIA3KaoTjOggnkeN8OzcO1CD3esk25AduBbWC8usuZSl =oP8i -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] GS - opérateur
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 26/10/2014 14:49, Fedotova, Claire Svetlana Four wrote: Et l'equipe comnerciale (ils ne sont pas au courant de tout :) Zut vos commerciaux ne savent pas que vos DC sont carrier neutral. Heureusement c'est à présent de notoriété publique et je vais vous contacter en privé pour obtenir une liste de POPs à Paris. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iF4EAREIAAYFAlRNKxUACgkQJBGsD8mtnRGibwD/dAUJ08cwyLpblGAy/H6XOZdc GvalIu8TRfQo6neJBosA/iXx2Mb8kK2DM6LV8c29qKGUKyTRuD3DmdqZE/Cy5R2J =IOhX -END PGP SIGNATURE- --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Auth PPP/CHAP Fibre Orange et Mikrotik
Bonjour la liste, J'essaye actuellement de me débarrasser de la liveboiboite fibre pour la remplacer par un Mikrotik CRS125-24G-1S et je fais face à un problème un peu étrange. Je précise que je garde le convertisseur fibre =ethernet Huawei qu'Orange donne parce que j'aime bien les services secrets Chinois et surtout que je n'ai aucune idée de comment setup une fibre monobrin sur le CRS (ni si c'est possible). Mais le problème n'est pas là. Le discovery ppp passe bien sans souci, mais je me fais systématiquement jeter lors de l'authentification CHAP. Je précise que j'ai bien vérifié 50 fois le couple user/mdp hein :) J'ai remarqué deux différences dans les paquets CHAP Response qu'envoient la Livebox et le CRS : - Le challenge (normal) - Le nombre d'octets de bourrage à la fin du paquet Je m'explique. Normalement un paquet CHAP Response a cette tête : - 1 octet Code : ici 2 = Response - 1 octet ID : ici 1 mais on s'en fout - 2 octet Length CHAP : dans mon cas 32 = La taille du paquet CHAP - 1 octet Longueur Challenge : dans mon cas 16 - 16 octets Challenge - Le reste c'est le Name CHAP, donc l'ID. Chez Orange c'est quelque chose comme fti/xxx donc 11 octets On a bien 1+1+2+1+16+11 = 32. La RFC 1994 dit que tout ce qui suit la longueur Length précisé dans l'en-tête du paquet doit être ignoré, or la différence est précisément après. Mon CRS ajoute 4 octets 0x00 à la fin (après les 32 octets) alors que la LB n'en met que deux. Est-ce qu'il est possible que ce genre de différence soit à l'origine du problème? Si non est-ce que vous avez déjà eu ce genre de problème? Pour info : voici ma conf PPPoE sur le CRS : /interface pppoe-client add ac-name= add-default-route=yes allow=pap,chap default-route-distance=1 dial-on-demand=no disabled=no interface=internet-orange keepalive-timeout=60 \ max-mru=1492 max-mtu=1492 mrru=disabled name=pppoe-orange password=xxx profile=default service-name= use-peer-dns=yes user=fti/rwh2y29 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Auth PPP/CHAP Fibre Orange et Mikrotik
Pas que je pense que ton message est à sa place sur FRnOG, mais bon, tant qu’on est là: tu tentes bien de monter le PPP sur le VLAN 835 ? Le 26 oct. 2014 à 18:15, Nathan delhaye cont...@nathan-delhaye.fr a écrit : Bonjour la liste, J'essaye actuellement de me débarrasser de la liveboiboite fibre pour la remplacer par un Mikrotik CRS125-24G-1S et je fais face à un problème un peu étrange. Je précise que je garde le convertisseur fibre =ethernet Huawei qu'Orange donne parce que j'aime bien les services secrets Chinois et surtout que je n'ai aucune idée de comment setup une fibre monobrin sur le CRS (ni si c'est possible). Mais le problème n'est pas là. Le discovery ppp passe bien sans souci, mais je me fais systématiquement jeter lors de l'authentification CHAP. Je précise que j'ai bien vérifié 50 fois le couple user/mdp hein :) J'ai remarqué deux différences dans les paquets CHAP Response qu'envoient la Livebox et le CRS : - Le challenge (normal) - Le nombre d'octets de bourrage à la fin du paquet Je m'explique. Normalement un paquet CHAP Response a cette tête : - 1 octet Code : ici 2 = Response - 1 octet ID : ici 1 mais on s'en fout - 2 octet Length CHAP : dans mon cas 32 = La taille du paquet CHAP - 1 octet Longueur Challenge : dans mon cas 16 - 16 octets Challenge - Le reste c'est le Name CHAP, donc l'ID. Chez Orange c'est quelque chose comme fti/xxx donc 11 octets On a bien 1+1+2+1+16+11 = 32. La RFC 1994 dit que tout ce qui suit la longueur Length précisé dans l'en-tête du paquet doit être ignoré, or la différence est précisément après. Mon CRS ajoute 4 octets 0x00 à la fin (après les 32 octets) alors que la LB n'en met que deux. Est-ce qu'il est possible que ce genre de différence soit à l'origine du problème? Si non est-ce que vous avez déjà eu ce genre de problème? Pour info : voici ma conf PPPoE sur le CRS : /interface pppoe-client add ac-name= add-default-route=yes allow=pap,chap default-route-distance=1 dial-on-demand=no disabled=no interface=internet-orange keepalive-timeout=60 \ max-mru=1492 max-mtu=1492 mrru=disabled name=pppoe-orange password=xxx profile=default service-name= use-peer-dns=yes user=fti/rwh2y29 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Auth PPP/CHAP Fibre Orange et Mikrotik
As-tu essayé de faire le dial pppoe over vlan 835 sur l'interface ethernet sur lequel l'ONT est connecté ? De souvenir Orange utilisait ce vlan en comparaison du VPi/VCi qui est 8/35 sur leur liaison ADSL Bien cordialement, Florian Le 26 oct. 2014 à 18:18, Nathan delhaye cont...@nathan-delhaye.fr a écrit : Bonjour la liste, J'essaye actuellement de me débarrasser de la liveboiboite fibre pour la remplacer par un Mikrotik CRS125-24G-1S et je fais face à un problème un peu étrange. Je précise que je garde le convertisseur fibre =ethernet Huawei qu'Orange donne parce que j'aime bien les services secrets Chinois et surtout que je n'ai aucune idée de comment setup une fibre monobrin sur le CRS (ni si c'est possible). Mais le problème n'est pas là. Le discovery ppp passe bien sans souci, mais je me fais systématiquement jeter lors de l'authentification CHAP. Je précise que j'ai bien vérifié 50 fois le couple user/mdp hein :) J'ai remarqué deux différences dans les paquets CHAP Response qu'envoient la Livebox et le CRS : - Le challenge (normal) - Le nombre d'octets de bourrage à la fin du paquet Je m'explique. Normalement un paquet CHAP Response a cette tête : - 1 octet Code : ici 2 = Response - 1 octet ID : ici 1 mais on s'en fout - 2 octet Length CHAP : dans mon cas 32 = La taille du paquet CHAP - 1 octet Longueur Challenge : dans mon cas 16 - 16 octets Challenge - Le reste c'est le Name CHAP, donc l'ID. Chez Orange c'est quelque chose comme fti/xxx donc 11 octets On a bien 1+1+2+1+16+11 = 32. La RFC 1994 dit que tout ce qui suit la longueur Length précisé dans l'en-tête du paquet doit être ignoré, or la différence est précisément après. Mon CRS ajoute 4 octets 0x00 à la fin (après les 32 octets) alors que la LB n'en met que deux. Est-ce qu'il est possible que ce genre de différence soit à l'origine du problème? Si non est-ce que vous avez déjà eu ce genre de problème? Pour info : voici ma conf PPPoE sur le CRS : /interface pppoe-client add ac-name= add-default-route=yes allow=pap,chap default-route-distance=1 dial-on-demand=no disabled=no interface=internet-orange keepalive-timeout=60 \ max-mru=1492 max-mtu=1492 mrru=disabled name=pppoe-orange password=xxx profile=default service-name= use-peer-dns=yes user=fti/rwh2y29 --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Auth PPP/CHAP Fibre Orange et Mikrotik
Oui, je suis bien sur le VLAN 835. Et le CRS trouve bien le BAS en face, la négo se fait bien en PPP. Le lien monte, mais au moment de s'authentifier via CHAP, le handshake se fait bien (je vois bien passer les paquets), mais le BAS me répond que ma réponse d'authentification est invalide. Le 26 octobre 2014 18:28, David Ponzone david.ponz...@gmail.com a écrit : Pas que je pense que ton message est à sa place sur FRnOG, mais bon, tant qu’on est là: tu tentes bien de monter le PPP sur le VLAN 835 ? Le 26 oct. 2014 à 18:15, Nathan delhaye cont...@nathan-delhaye.fr a écrit : Bonjour la liste, J'essaye actuellement de me débarrasser de la liveboiboite fibre pour la remplacer par un Mikrotik CRS125-24G-1S et je fais face à un problème un peu étrange. Je précise que je garde le convertisseur fibre =ethernet Huawei qu'Orange donne parce que j'aime bien les services secrets Chinois et surtout que je n'ai aucune idée de comment setup une fibre monobrin sur le CRS (ni si c'est possible). Mais le problème n'est pas là. Le discovery ppp passe bien sans souci, mais je me fais systématiquement jeter lors de l'authentification CHAP. Je précise que j'ai bien vérifié 50 fois le couple user/mdp hein :) J'ai remarqué deux différences dans les paquets CHAP Response qu'envoient la Livebox et le CRS : - Le challenge (normal) - Le nombre d'octets de bourrage à la fin du paquet Je m'explique. Normalement un paquet CHAP Response a cette tête : - 1 octet Code : ici 2 = Response - 1 octet ID : ici 1 mais on s'en fout - 2 octet Length CHAP : dans mon cas 32 = La taille du paquet CHAP - 1 octet Longueur Challenge : dans mon cas 16 - 16 octets Challenge - Le reste c'est le Name CHAP, donc l'ID. Chez Orange c'est quelque chose comme fti/xxx donc 11 octets On a bien 1+1+2+1+16+11 = 32. La RFC 1994 dit que tout ce qui suit la longueur Length précisé dans l'en-tête du paquet doit être ignoré, or la différence est précisément après. Mon CRS ajoute 4 octets 0x00 à la fin (après les 32 octets) alors que la LB n'en met que deux. Est-ce qu'il est possible que ce genre de différence soit à l'origine du problème? Si non est-ce que vous avez déjà eu ce genre de problème? Pour info : voici ma conf PPPoE sur le CRS : /interface pppoe-client add ac-name= add-default-route=yes allow=pap,chap default-route-distance=1 dial-on-demand=no disabled=no interface=internet-orange keepalive-timeout=60 \ max-mru=1492 max-mtu=1492 mrru=disabled name=pppoe-orange password=xxx profile=default service-name= use-peer-dns=yes user=fti/rwh2y29 --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Nathan Delhaye 06 69 27 64 25 0805 696 494 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] GS - opérateur
On Sun, 2014-10-26 at 18:04 +0100, Sylvain Vallerot wrote: Et si vous me faites changer d'avis il y aura probablement bientôt une offre sympa de MMR sans pertes sur PA2 gérée par un opérateur d'opérateurs neutre. Une MMR sans perte cela n'existe pas, la seule façon de ne pas avoir de perte c'est un cable d'un seul morceau de bout en bout. Hors par définition dans une MMR, tu fait la jonction d'une cable venant d'un client A avec un cable venant d'une client B à l'aide d'un patch. Il y a aucun modèle de câblage parfait: MMR: + flexibilité + délai de mise en oeuvre d'un circuit rapide en raison du précablage + limitation au maximum du volume de cables dans le datacenter + un seul cable dans la baie client permet de connecter différents point dans le datacenter + point de demarc simple: le patch-panel dans la baie client - attenuation introduite par les différents points de coupures Câblage point à point direct (ce qui se fait sur Telehouse 2): + pas d'atténuation introduite sous réserve d'avoir un cable d'un seul morceau - délai de mise en oeuvre longs car pour chaque circuit il faut tirer un nouveau cable - grand volume de cables dans le datacenter - un cable par circuit dans la baie client Quasiment tous les datacenters récents utilisent un système de MMR (pour ceux utilisant la notion de 2 demi-circuits avec patch) ou d'ODF (pour ceux utilisant la notion d'un seul circuit complet mais qui est coupé par des ODF). D'ailleurs les points de coupures sur les circuit fibre ne sont pas spécifique au datacenters, les opérateurs proposant de la fibre noire ont le même problème. -- Nicolas DEFFAYET --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Auth PPP/CHAP Fibre Orange et Mikrotik
Trouvé sur un forum lafibre.info (ça vaut ce que ça vaut…): J'ai réussi à me passer de la Livebox avec le routeur MikroTik RouterBOARD RB2011UAS-RM. Pour se faire : • J'ai connecté Eth2 à l'ONT et dans l'interface j'ai renommé en Eth2-Orange MTU 1492, L2 MTU 1598, max L2 LTU 4074 • J'ai ensuite créé un VLAN avec VLAN ID 835 sur l'interface Eth2-Orange, que j'ai nommé Eth2-Orange-VLAN835 (sans cocher Use Service Tag) / MTU 1492, L2 MTU 1594 • J'ai créer une liaison PPPoE sur l'interface Eth2-Orange-VLAN835, que j'ai nommé WAN-PPPoE / MTU 1492, Max MRU 1480 • dans IP Firewal, Filters Rules : modifier pour InInterface : WAN-PPPoE • dans IP Firewal, onglet Nat : modifier pour Out Interface : WAN-PPPoE « Donc, à part le « Use Service Tag » , je vois mal ce qui peut coincer chez toi…. Le 26 oct. 2014 à 18:33, Nathan delhaye cont...@nathan-delhaye.fr a écrit : Oui, je suis bien sur le VLAN 835. Et le CRS trouve bien le BAS en face, la négo se fait bien en PPP. Le lien monte, mais au moment de s'authentifier via CHAP, le handshake se fait bien (je vois bien passer les paquets), mais le BAS me répond que ma réponse d'authentification est invalide. Le 26 octobre 2014 18:28, David Ponzone david.ponz...@gmail.com a écrit : Pas que je pense que ton message est à sa place sur FRnOG, mais bon, tant qu’on est là: tu tentes bien de monter le PPP sur le VLAN 835 ? Le 26 oct. 2014 à 18:15, Nathan delhaye cont...@nathan-delhaye.fr a écrit : Bonjour la liste, J'essaye actuellement de me débarrasser de la liveboiboite fibre pour la remplacer par un Mikrotik CRS125-24G-1S et je fais face à un problème un peu étrange. Je précise que je garde le convertisseur fibre =ethernet Huawei qu'Orange donne parce que j'aime bien les services secrets Chinois et surtout que je n'ai aucune idée de comment setup une fibre monobrin sur le CRS (ni si c'est possible). Mais le problème n'est pas là. Le discovery ppp passe bien sans souci, mais je me fais systématiquement jeter lors de l'authentification CHAP. Je précise que j'ai bien vérifié 50 fois le couple user/mdp hein :) J'ai remarqué deux différences dans les paquets CHAP Response qu'envoient la Livebox et le CRS : - Le challenge (normal) - Le nombre d'octets de bourrage à la fin du paquet Je m'explique. Normalement un paquet CHAP Response a cette tête : - 1 octet Code : ici 2 = Response - 1 octet ID : ici 1 mais on s'en fout - 2 octet Length CHAP : dans mon cas 32 = La taille du paquet CHAP - 1 octet Longueur Challenge : dans mon cas 16 - 16 octets Challenge - Le reste c'est le Name CHAP, donc l'ID. Chez Orange c'est quelque chose comme fti/xxx donc 11 octets On a bien 1+1+2+1+16+11 = 32. La RFC 1994 dit que tout ce qui suit la longueur Length précisé dans l'en-tête du paquet doit être ignoré, or la différence est précisément après. Mon CRS ajoute 4 octets 0x00 à la fin (après les 32 octets) alors que la LB n'en met que deux. Est-ce qu'il est possible que ce genre de différence soit à l'origine du problème? Si non est-ce que vous avez déjà eu ce genre de problème? Pour info : voici ma conf PPPoE sur le CRS : /interface pppoe-client add ac-name= add-default-route=yes allow=pap,chap default-route-distance=1 dial-on-demand=no disabled=no interface=internet-orange keepalive-timeout=60 \ max-mru=1492 max-mtu=1492 mrru=disabled name=pppoe-orange password=xxx profile=default service-name= use-peer-dns=yes user=fti/rwh2y29 --- Liste de diffusion du FRnOG http://www.frnog.org/ -- Nathan Delhaye 06 69 27 64 25 0805 696 494 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Level3 Colocation down depuis plus de 9h30 (Pour pas que cela passe inaperçue)
Bonsoir la liste, je confirme également cette panne et surtout l'inacceptable longueur quand à la reprise du service (de 22h00 à 9h15). _Défaillances imputables à LEVEL3 :_ 1. Le datacenter de LEVEL3 n'a pas su disposer d'un service électrique continu sur *au moins une voie d'alimentation électrique* durant plus de 11h ce contrairement aux dispositions contractuelles. 2. La dépose d'une signalisation auprès de LEVEL3 n'a pas été satisfaisante puisque la cellule UK censée être active 24h/24 et 7j/7 n'a pas opéré sont rôle de manière continue et à grandement retardé la prise en compte de l'incident, donc sa résolution. Le NOC US de LEVEL 3 nous a explicitement indiqué qu'il n'était pas en mesure de contacter le NOC UK en charge des Datacenters EMEA malgré plusieurs tentatives... 3. L'indisponibilité d'un Onduleur dans un Datacenter ne devrait jamais générer la perte simultanée des 2 voies d'alimentation électrique, ce qui laisse supposer (sans preuves suffisantes dans l'immédiat) que : * soit le dimensionnement de l'infrastructure électrique est en défaut car le report du besoin énergétique global sur la voie restante est supérieur à la capacité de l'onduleur de cette même voie d'alimentation électrique. * soit les 2 voies d'alimentation électrique sont branchées sur le même onduleur ce qui contreviendrait à toutesles dispositions prises actuellement dans le métier et qui représenterait un grave manquement aux obligations auxquelles un hébergeur est soumis. La remise en cause d'une partie de leur organisation sur leurs offres d'hébergement va devoir commencer... on est en 2014. -- - Fournisseur d'infrastructures communicantes pour opérateurs et entreprises exigeantes - Bruno VELUET Directeur Général Tel : +33 (0)1 81 80 50 02 Fax : +33 (0)1 81 80 50 09 Web : www.leonix.fr 35 rue des Jeûneurs 75002 Paris Le 25/10/2014 07:37, Jerome SCHEVINGT a écrit : Bonjour, Pour pas que cela passe inaperçue: Depuis hier soir 22h, il n'y a plus d'électricité dans des cages Level3 a Globalswitch Clichy coupant un grand nombre de rack (ex Global Crossing). Après 5 heures de coupure déjà, il n'y avait aucune intervention de technicien pour voir ce qui ce passe. Après 8h30 de coupure enfin un élément: The European NOC has reported that the Uninterruptible Power Supply (UPS) has failed. The hardware vendor has been engaged and has dispatched a specialist to the site to assist with investigations with no ETA available at this time. Sérieux j'entends des remarque sur Telehouse II, mais alors Level3 ont peu classer dans qu'elle catégorie ? j'aurais jamais imaginé qu'aujourd'hui on puisse supporter une coupure de ce type dans un grand datacenter parisien (meme si Level3 est autonome chez Globalswitch) Cordialement Jérôme SCHEVINGT --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] Level3 Colocation down depuis plus de 9h30 (Pour pas que cela passe inaperçue)
Bonsoir la liste, je confirme également cette panne et surtout l'inacceptable longueur quand à la reprise du service (de 22h00 à 9h15). _Défaillances imputables à LEVEL3 :_ 1. Le datacenter de LEVEL3 n'a pas su disposer d'un service électrique continu sur *au moins une voie d'alimentation électrique* durant plus de 11h ce contrairement aux dispositions contractuelles. 2. La dépose d'une signalisation auprès de LEVEL3 n'a pas été satisfaisante puisque la cellule UK censée être active 24h/24 et 7j/7 n'a pas opéré sont rôle de manière continue et à grandement retardé la prise en compte de l'incident, donc sa résolution. Le NOC US de LEVEL 3 nous a explicitement indiqué qu'il n'était pas en mesure de contacter le NOC UK en charge des Datacenters EMEA malgré plusieurs tentatives... 3. L'indisponibilité d'un Onduleur dans un Datacenter ne devrait jamais générer la perte simultanée des 2 voies d'alimentation électrique, ce qui laisse supposer (sans preuves suffisantes dans l'immédiat) que : * soit le dimensionnement de l'infrastructure électrique est en défaut car le report du besoin énergétique global sur la voie restante est supérieur à la capacité de l'onduleur de cette même voie d'alimentation électrique. * soit les 2 voies d'alimentation électrique sont branchées sur le même onduleur ce qui contreviendrait à toutesles dispositions prises actuellement dans le métier et qui représenterait un grave manquement aux obligations auxquelles un hébergeur est soumis. La remise en cause d'une partie de leur organisation sur leurs offres d'hébergement va devoir commencer... on est en 2014. -- - Fournisseur d'infrastructures communicantes pour opérateurs et entreprises exigeantes - Bruno VELUET Directeur Général Tel : +33 (0)1 81 80 50 02 Fax : +33 (0)1 81 80 50 09 Web : www.leonix.fr 35 rue des Jeûneurs 75002 Paris Le 25/10/2014 07:37, Jerome SCHEVINGT a écrit : Bonjour, Pour pas que cela passe inaperçue: Depuis hier soir 22h, il n'y a plus d'électricité dans des cages Level3 a Globalswitch Clichy coupant un grand nombre de rack (ex Global Crossing). Après 5 heures de coupure déjà, il n'y avait aucune intervention de technicien pour voir ce qui ce passe. Après 8h30 de coupure enfin un élément: The European NOC has reported that the Uninterruptible Power Supply (UPS) has failed. The hardware vendor has been engaged and has dispatched a specialist to the site to assist with investigations with no ETA available at this time. Sérieux j'entends des remarque sur Telehouse II, mais alors Level3 ont peu classer dans qu'elle catégorie ? j'aurais jamais imaginé qu'aujourd'hui on puisse supporter une coupure de ce type dans un grand datacenter parisien (meme si Level3 est autonome chez Globalswitch) Cordialement Jérôme SCHEVINGT --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Auth PPP/CHAP Fibre Orange et Mikrotik
On 26/10/2014 18:15, Nathan delhaye wrote: Le discovery ppp passe bien sans souci, mais je me fais systématiquement jeter lors de l'authentification CHAP. Pour info, j'ai un setup similaire, mais avec un routeur OpenBSD. Cela a fonctionné directement, sans bidouille particulière. Par contre, bizarrement, le débit (surtout en upload) est catastrophique si je ne passe pas par la livebox. Ton retour d'XP sur ce point m'intéresse. -- Simon --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [JOBS] Poste Ingénieur Support réseau et sécurité
BE FREE Networks, société de services spécialisée dans le déploiement de solutions télécom pour les opérateurs, les collectivités locales et les acteurs de la santé recherche pour renforcer ses équipes un ingénieur support réseau et sécurité confirmé. Le poste à pourvoir est basé à Paris, le salaire est négociable selon le niveau d'expérience. La personne recherchée participera à des missions de support, dingénierie, daudit pour des clients entreprise, des collectivités locales ou des acteurs de santé en France. Il dépendra de léquipe support. La personne recherchée devra posséder une parfaite connaissance et une expérience significative dans les domaines suivants: · Exploitation dinfrastructures réseaux et sécurité, · Ingénierie réseaux IP, · système et sécurité. Des connaissances et une expérience sur le BroadBand Acces (GPON, FTTH) serait un plus Les compétences suivantes seront grandement appréciées: - Maitrise de langlais - Connaissance des solutions des constructeurs Huawei, Cisco, Alcatel Des déplacements nationaux peuvent être envisagés. Si vous vous reconnaissez dans ce descriptif, que vous êtes rigoureux, motivé, autonome, que vous faites preuve dinitiative et avez envie de travailler dans une entreprise à taille humaine n'hésitez pas à nous envoyer votre CV à recrutem...@befree.fr Christian Oudot LOGO BFN * 18-20 rue Brulefer 93100 Montreuil Fixe+33 174 734 130 Mob. +33 671 252 787 Fax +33 174 734 137 www.befree.fr http://www.befree.fr/ ü Afin de contribuer au respect de l'environnement merci de n'imprimer ce mail qu'en cas de nécessité.
Re: [FRnOG] [TECH] WIFI public
Bonjour la liste, Il y a quelque temps j'ai contacté la CNIL sur le sujet de la conservation des logs lors du déploiement d'un hotspot. J'en ai retenu que les informations qui sont a conserver lorsque l'on met ce type de réseau en place sont les suivants: - L'adresse MAC de l'équipement qui se connecte - L'heure et la date de connection- Le protocole utilisé- L'adresse IP du site consulté Il faut bien conserver ces données durant 1 an afin de pouvoir les mettre à disposition lors d'un contrôle. La loi indique qu'il faut bien conserver les données techniques de l'équipement. Il n'est pas nécessaire de connaitre l'identitée de la personne qui exploite le hotspot. Donc, pas besoin de sauvegarder le SMS ou le mail.En ce qui concerne l'utilisation frauduleuse d'Internet, un bon firewall associé à un filtrage applicatif devrait bloquer le P2P et un filtrage de contenu pourra bloquer l'accès aux Newsgroups ainsi qu'aux sites qui proposent des contenus en téléchargement. Ca a aussi l'avantage d'éviter qu'un utilisateur prenne toute la bande passante... Roger Le Vendredi 24 octobre 2014 15h47, Julien Schafer j.scha...@actilogie.com a écrit : Bonjour la liste Je m'interroge sur les obligations éventuelles (que je ne connaitrais pas) lorsque l'on met à disposition un accès Internet au public (WIFI en pleine rue en l'occurrence). Je sais qu'il y a l'obligation de conservation des logs durant 1 an mais est-ce tout ? J'ai tendance à penser qu'un portail captif + validation des comptes par SMS ou mail + archivage des logs devrait suffire mais je préfère être certain. Par ailleurs y a-t-il des best practices dans ce genre ce cas (je pense par exemple à un filtrage pertinent pour ne pas télécharger les pubs et cie afin que la bande passante soit vraiment utilisée utilement, mettre des règles de QoS pour qu'un utilisateur ne dégrade pas l'ensemble du service - en faisant du P2P ou en téléchargeant massivement par exemple etc) ? Merci d'avance pour vos avis ou vos retours d'expérience. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] WIFI public
Roger, tu déconnes. Et la neutralité du net alors! Le 26 oct. 2014 à 23:15, Roger Leclerc roger_lecl...@yahoo.fr a écrit : Bonjour la liste, Il y a quelque temps j'ai contacté la CNIL sur le sujet de la conservation des logs lors du déploiement d'un hotspot. J'en ai retenu que les informations qui sont a conserver lorsque l'on met ce type de réseau en place sont les suivants: - L'adresse MAC de l'équipement qui se connecte - L'heure et la date de connection- Le protocole utilisé- L'adresse IP du site consulté Il faut bien conserver ces données durant 1 an afin de pouvoir les mettre à disposition lors d'un contrôle. La loi indique qu'il faut bien conserver les données techniques de l'équipement. Il n'est pas nécessaire de connaitre l'identitée de la personne qui exploite le hotspot. Donc, pas besoin de sauvegarder le SMS ou le mail.En ce qui concerne l'utilisation frauduleuse d'Internet, un bon firewall associé à un filtrage applicatif devrait bloquer le P2P et un filtrage de contenu pourra bloquer l'accès aux Newsgroups ainsi qu'aux sites qui proposent des contenus en téléchargement. Ca a aussi l'avantage d'éviter qu'un utilisateur prenne toute la bande passante... Roger Le Vendredi 24 octobre 2014 15h47, Julien Schafer j.scha...@actilogie.com a écrit : Bonjour la liste Je m'interroge sur les obligations éventuelles (que je ne connaitrais pas) lorsque l'on met à disposition un accès Internet au public (WIFI en pleine rue en l'occurrence). Je sais qu'il y a l'obligation de conservation des logs durant 1 an mais est-ce tout ? J'ai tendance à penser qu'un portail captif + validation des comptes par SMS ou mail + archivage des logs devrait suffire mais je préfère être certain. Par ailleurs y a-t-il des best practices dans ce genre ce cas (je pense par exemple à un filtrage pertinent pour ne pas télécharger les pubs et cie afin que la bande passante soit vraiment utilisée utilement, mettre des règles de QoS pour qu'un utilisateur ne dégrade pas l'ensemble du service - en faisant du P2P ou en téléchargeant massivement par exemple etc) ? Merci d'avance pour vos avis ou vos retours d'expérience. --- 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] WIFI public
Hello la liste, J'ai peut-être mal compris mais il me semble que le plus important est bien la conservation de l'identité de la personne. Imaginer un utilisateur utilisant un accès Wi-Fi public pour commettre un acte répréhensible par les lois. Les services de l'état vont vouloir retrouver la personne physique. Ils vont faire une requête au propriétaire de l'application utilisée (site web, etc), celle-ci fournira l'adresse IP public, l'opérateur fournira le propriétaire et celui devra ensuite fournir le coupable. Comment est-ce possible si l'identité n'est pas connue ? (concernant l'adresse mac, elle peut être usurpée, un coup de ifconfig et c'est réglé) Peut être que je me trompe, dans ce cas, merci de m(nous)'éclairer :) ++ Sylvain Le 26 octobre 2014 23:15, Roger Leclerc roger_lecl...@yahoo.fr a écrit : Bonjour la liste, Il y a quelque temps j'ai contacté la CNIL sur le sujet de la conservation des logs lors du déploiement d'un hotspot. J'en ai retenu que les informations qui sont a conserver lorsque l'on met ce type de réseau en place sont les suivants: - L'adresse MAC de l'équipement qui se connecte - L'heure et la date de connection- Le protocole utilisé- L'adresse IP du site consulté Il faut bien conserver ces données durant 1 an afin de pouvoir les mettre à disposition lors d'un contrôle. La loi indique qu'il faut bien conserver les données techniques de l'équipement. Il n'est pas nécessaire de connaitre l'identitée de la personne qui exploite le hotspot. Donc, pas besoin de sauvegarder le SMS ou le mail.En ce qui concerne l'utilisation frauduleuse d'Internet, un bon firewall associé à un filtrage applicatif devrait bloquer le P2P et un filtrage de contenu pourra bloquer l'accès aux Newsgroups ainsi qu'aux sites qui proposent des contenus en téléchargement. Ca a aussi l'avantage d'éviter qu'un utilisateur prenne toute la bande passante... Roger Le Vendredi 24 octobre 2014 15h47, Julien Schafer j.scha...@actilogie.com a écrit : Bonjour la liste Je m'interroge sur les obligations éventuelles (que je ne connaitrais pas) lorsque l'on met à disposition un accès Internet au public (WIFI en pleine rue en l'occurrence). Je sais qu'il y a l'obligation de conservation des logs durant 1 an mais est-ce tout ? J'ai tendance à penser qu'un portail captif + validation des comptes par SMS ou mail + archivage des logs devrait suffire mais je préfère être certain. Par ailleurs y a-t-il des best practices dans ce genre ce cas (je pense par exemple à un filtrage pertinent pour ne pas télécharger les pubs et cie afin que la bande passante soit vraiment utilisée utilement, mettre des règles de QoS pour qu'un utilisateur ne dégrade pas l'ensemble du service - en faisant du P2P ou en téléchargeant massivement par exemple etc) ? Merci d'avance pour vos avis ou vos retours d'expérience. --- 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] Auth PPP/CHAP Fibre Orange et Mikrotik
2014-10-26 18:15 GMT+01:00 Nathan delhaye cont...@nathan-delhaye.fr: Bonjour la liste, J'essaye actuellement de me débarrasser de la liveboiboite fibre pour la remplacer par un Mikrotik CRS125-24G-1S et je fais face à un problème un peu étrange. Je précise que je garde le convertisseur fibre =ethernet Huawei qu'Orange donne parce que j'aime bien les services secrets Chinois et surtout que je n'ai aucune idée de comment setup une fibre monobrin sur le CRS (ni si c'est possible). Mais le problème n'est pas là. Le discovery ppp passe bien sans souci, mais je me fais systématiquement jeter lors de l'authentification CHAP. Je précise que j'ai bien vérifié 50 fois le couple user/mdp hein :) J'ai remarqué deux différences dans les paquets CHAP Response qu'envoient la Livebox et le CRS : - Le challenge (normal) - Le nombre d'octets de bourrage à la fin du paquet Je m'explique. Normalement un paquet CHAP Response a cette tête : - 1 octet Code : ici 2 = Response - 1 octet ID : ici 1 mais on s'en fout - 2 octet Length CHAP : dans mon cas 32 = La taille du paquet CHAP - 1 octet Longueur Challenge : dans mon cas 16 - 16 octets Challenge - Le reste c'est le Name CHAP, donc l'ID. Chez Orange c'est quelque chose comme fti/xxx donc 11 octets On a bien 1+1+2+1+16+11 = 32. La RFC 1994 dit que tout ce qui suit la longueur Length précisé dans l'en-tête du paquet doit être ignoré, or la différence est précisément après. Mon CRS ajoute 4 octets 0x00 à la fin (après les 32 octets) alors que la LB n'en met que deux. Est-ce qu'il est possible que ce genre de différence soit à l'origine du problème? Si non est-ce que vous avez déjà eu ce genre de problème? Salut, Même si cela ne réponds pas à la question (désolé, je n'ai jamais creusé moi-même dans le détails du protocole), je peux te dire que monter le PPP d'une fibre orange sur un pfsense fonctionne bien, et cela sans option/tunning particulier. Une idée pourrait donc être de faire un autre test avec un pfsense (c'est du freeBSD, donc tu vas pouvoir vérifier tranquillement ce que tu veux dans les paquets échangés) et cela te permettra peut-être de vérifier ton hypothèse. NB: l'utilisation que je décris est avec un abonnement Zen Fibre (particulier) qui a depuis été transformé en abo pro fibre 200M. Et bien entendu, il s'agit de PPP sur l'interface VLAN 835. -- Florent --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] WIFI public
On Sunday 26 October 2014 23:35:25 Sylvain Tgz wrote: Hello la liste, J'ai peut-être mal compris mais il me semble que le plus important est bien la conservation de l'identité de la personne. «(…) il semble que la conservation des données ne garantisse pas l’identification de l’utilisateur, c’est-à-dire la connaissance de son état civil. En effet, le décret du 24 mars 2006 n’a pas retenu l’hypothèse consistant à demander aux exploitants de cybercafés, d’hôtels ou de bars qui offrent une connexion Wi-Fi, de relever l’identité de leurs clients. Il prévoit seulement la conservation des données permettant l’identification. (…) » https://www.cdse.fr/wifi-et-conservation-des-donnees.html voir aussi: http://www.globenet.org/No-log-les-logs-et-la-loi.html Et aussi le Guide juridique pour les opérateurs locaux et les collectivités de l'arcep: http://www.arcep.fr/uploads/tx_gspublication/guide-juridique-crip2007.pdf Imaginer un utilisateur utilisant un accès Wi-Fi public pour commettre un acte répréhensible par les lois. Les services de l'état vont vouloir retrouver la personne physique. Ils vont faire une requête au propriétaire de l'application utilisée (site web, etc), celle-ci fournira l'adresse IP public, l'opérateur fournira le propriétaire et celui devra ensuite fournir le coupable. Comment est-ce possible si l'identité n'est pas connue ? (concernant l'adresse mac, elle peut être usurpée, un coup de ifconfig et c'est réglé) Peut être que je me trompe, dans ce cas, merci de m(nous)'éclairer :) Tu ne trompes pas, il est trivial de masquer une adresse MAC et c'est un des arguments qui rendait la loi assez inefficace avant même qu'elle soit votée. De même qu'il avait été annoncé que l'hadopi ne pourrait rien contre l'usage de VPNs et déplacerait les usages de bittorrent et p2p vers streaming et téléchargement direct. Mais même sans avoir à spoofer de MAC, tu achètes un adaptateur usb wifi, tu vas te connecter chez macdo depuis le parking et tu fais ton acte répréhensible et puis tu détruis l'adaptateur wifi et tu t'en débarasses et voila. Dans le cas d'un abonnement résidentiel et d'hadopi ce n'est même pas la personne qui commets l'acte qui est inquiétée mais le titulaire de l'abonnement internet. ++ Sylvain --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] WIFI public
Ok, la loi exige :'( Et qu'en est-il des sanctions prévues pour non-flicage de connexion internet ? Si on met une machinbox en wifi ouvert (et à priori sans log) dans un lieu public et que quelqu'un s'en sert pour uploader du pédonazi, on risque quoi ? --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] WIFI public
Pierre Colombier a écrit : Ok, la loi exige :'( Et qu'en est-il des sanctions prévues pour non-flicage de connexion internet ? Si on met une machinbox en wifi ouvert (et à priori sans log) dans un lieu public et que quelqu'un s'en sert pour uploader du pédonazi, on risque quoi ? Rien, tant que Macdo continue de le faire. Seul problème : un mauvais arrangement coûte presqu'aussi cher qu'un bon procès, et toutes ces lois à la con qui ne servent à rien en fait servent à quelque chose : engraisser les avocats. Comme beaucoup d'autre choses, c'est un système à 2 vitesses : quand tu as du pognon pas de problème, quand tu n'en a pas et qu'un connard avec un képi qui ne sait rien faire d'autre que de réciter le règlement décide de te faire chier, c'est toi qui trinques. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
