Re: [FRnOG] usb 3G+ pour les vacances

2009-07-09 Par sujet Vincent Gillet - Opentransit

Mon téléphone fait modem+3G fort bien mais impossible de prendre/emettre
un appel sans couper la session PPP.
(HTC Diamond.avec Orange).

Question : 
1/ Est-ce une limitation du téléphone/opérateur/Protocol3G ?
2/ Sans avoir data et voix en meme temps, j'aurais aimer que la session PPP
   ne tombe pas. C'est possible ?

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



Re: [FRnOG] Problèm e de peering avec Orange ?

2007-11-02 Par sujet Vincent Gillet - Opentransit
 Oui hier visiblement plusieurs de nos clients (chez orange) semblent
 avoir eut des problèmes à joindre nos serveurs sur Level3. Il n'est
 pas exclu qu'il y ait eut d'autres ISP touché.

Une fuite des routes de 3215 via un clients BGP de 3215 dont l'uplink
est 702  bref, de gros dommages collatéraux.

Suffit de jeter un oeil sur les outils RIS sur RIPE pour comprendre le
probleme.

Cet AS12696 a confondu 1er avril et 1er novembre :-|
Il a commencé à jouer le matin vers 6h du mat et est allé se coucher
vers 18h (a moins que 6h du mat soit la fin de la maintenance
et 18h le réveil pour corriger l'erreur :-)

Je pensais que Verizon était un exemple du genre sur le filtrage des
prefixes de ses clients pour justement éviter ces fuites.
Cela ne semble pas le cas !!!

D'apres moi, faute partagé entre 702, 12696 et 3215.
Un de ces 3 gus aurait du couper le BGP dès le probleme détecté.

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



Re: [FRnOG] Migration vers sup720-3BXL

2007-10-19 Par sujet Vincent Gillet - Opentransit
[EMAIL PROTECTED] disait :

 Bonjour à tous,
 
 Veuillez m'excuser si cette question est un peu hors sujet.
 
 Jusque là pour notre réseau nous utilisions des chassis cisco avec 
 sup2/msfc2. 
 Nécéssitant d'être capable de supporter plus de charge à l'avenir en terme de 
 pps et devant supporter le dépassement imminent des 256'000 routes, nous 
 allons upgrader dans quelques semaines nos routeurs vers des cartes 
 SUP720-3BXL
 
 Y a t'il des pré-requis pour cette carte ? au niveau chassis nous avons 
 pris 
 du 6506.

Si vous avez remplacé les Blower et les Power comme suggéré par Cisco,
pas de probleme. Sans cela, la SUP720 marchera 5 minutes puis le ROMMON
coupera le courant pour cause de hardware incompatible.

Nous avons fait cela chez FT il y a quelques années.

 A l'heure actuelle quelle est la version optimale et stable d'IOS pour cette 
 carte ?

J'envoye ce type d'info en privé !!

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



Re: [FRnOG] Wanadoo / Orange SMTP

2007-06-27 Par sujet Vincent Gillet - Opentransit
[EMAIL PROTECTED] disait :

 Le 27 juin 07 à 16:50, Will van Gulik a écrit :
 
 Et vu la clientele ciblé (le end-user et son pc zombie), ils ne  
 proposent pas de solution pour detourner le problème.

Etant donné que personne de Orange Mail ne répond, je vais tacher
de donner les infos que j'ai (en espérant ne pas me faire taper sur les
doigs, mais je considere qu'il n'y a rien de secret là dedans ...).

Cela évite aux gens compétents en SMTP de cherche l'erreur ou
devancer le probleme.

 Chez FT par contre, je ne suis pas certain qu'il y ait ce genre de  
 gestion de conf individualisée pour chaque Livebox. Ca ne  
 m'étonnerait pas tant que ça que le filtrage se fasse plus loin sur  
 les équipements réseaux.
 Ce qui est évidemment beaucoup moins élégant, et ingérable si chacun  
 commence à demander une exception. :)---

Le filtrage dans la livebox a été écarté car tout le monde n'est pas en
livebox.

Ce filtrage est en cours de mise en place sur les BAS. Il est déployé
par région. Cela commence cette semaine et se terminera en aout.
Un pilote a été nemé quelques mois sur un BAS. Il est concluant.

Les gens du SAV ont été informé il me semble.

Pas possible de mettre en place des exceptions car le filtrage est
global au BAS, non lié à la session de l'utilisateur.

1/ Ne rien me reprocher sur le mechanisme ni la méthode de mise en
   place. Je n'en suis pas responsable
2/ Je n'ai pas plus d'info que cela.
3/ A titre perso, je trouve que cette mise en place est une bonne chose
   pour la lutte anti-spam.

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



Re: [FRnOG] Wanadoo / Orange SMTP

2007-06-27 Par sujet Vincent Gillet - Opentransit
 Cela ne concerne que les abonnés Orange ou plus globalement tout les 
 non-dégroupés quelque soit le FAI ?

Orange only à ma connaissance. C'est sur les BAS dédié seulement.

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



Re: [FRnOG] Problème FT

2007-01-23 Par sujet Vincent Gillet - Opentransit
[EMAIL PROTECTED] disait :

 Depuis ce matin j'ai de gros problème de lenteur vers NYC depuis tous
 mes accès internet qui utilisent le réseau de France Telecom. Que ceci
 soit depuis Madagascar, de Paris ou d'ailleurs en France. Evidement
 tous convergent par les mêmes routes via Aubervilliers.
 
 Avez-vous des infos sur ce point?

Il n'y a aucun probleme au vu des graph transat du réseau de FT.
Pas de coupure, pas de graph anormaux.

Par contre, au niveau des peers il peut y avoir saturation  un peu
plus qu'hier et moins de demain :-)

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



Re: [FRnOG] RE : [FRnOG] RE : [FRnOG] Content Delivery Network (CDN) à la francaise

2006-12-09 Par sujet Vincent Gillet - Opentransit
[EMAIL PROTECTED] disait :

 Mais ce n'est pas le fond du problème. Le fond du problème c'est que tu
 as ton transit à Paris. Régionalise-le, en annonçant dans chaque région
 les IPs qui vont bien, et tu auras simplifié une partie de ton problème.

C'est tout a fait ce que fait FT.
Le transit de la région Alsace se fait sur Frankfurt.
Celui de la région nord sur Londres.

Cela économise pas mal de bande passante sur le point central de Paris
et a permis de faire des économies de surdimensionnement.
Les flux, tant internationaux que nationaux sont ainsi moins Paris
centrique.

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



[FRnOG] GLC-T sur Catalyst

2006-12-04 Par sujet Vincent Gillet - Opentransit
Etant donné que les pros de l'hébergement sont attentifs à Frnog, voila
une question technique pour eux 

Dans un Catalyst avec une carte 6724 (24 ports GE par SFP), est-il
possible de mettre un module SFP RJ45 (nommé GLC-T sauf erreur) qui
puisse faire du FE (et non du GE) ?
J'ai en effet des clients encore en FE qui me mobilisent un slot :-(

La lecture de
http://www.cisco.com/en/US/products/hw/modules/ps5455/products_device_support_table09186a0080446625.html#wp80210
semble dire que GLC-T sait faire 10/100/1000, mais seulement sur les
petits catalyst  pas les gros :-(

Vincent, qui a zero expérience en GE électrique :-)
---
Liste de diffusion du FRnOG
http://www.frnog.org/



Re: RE : [FRnOG] GLC-T sur Catalyst

2006-12-04 Par sujet Vincent Gillet - Opentransit
[EMAIL PROTECTED] disait :

  -Message d'origine-
  De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de
  Vincent Gillet - Opentransit
  Envoyé : lundi 4 décembre 2006 14:52
  À : frnog@frnog.org
  Objet : [FRnOG] GLC-T sur Catalyst
  
  Etant donné que les pros de l'hébergement sont attentifs à Frnog, voila
  une question technique pour eux 
  
  Dans un Catalyst avec une carte 6724 (24 ports GE par SFP), est-il
  possible de mettre un module SFP RJ45 (nommé GLC-T sauf erreur) qui
  puisse faire du FE (et non du GE) ?
  J'ai en effet des clients encore en FE qui me mobilisent un slot :-(
 
 Non, 1000 uniquement

Il semble en effet y avoir consensus d'apres les réponses reçues en
privée !!

Il ne me reste qu'à le rabattre sur le port 10/100/1000 de la SUP720 !!

Merci.

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



Re: [FRnOG] Re: [FRnOG] Con tent Delivery Network (CDN) à la francaise

2006-12-01 Par sujet Vincent Gillet - Opentransit
[EMAIL PROTECTED] disait :

 On Fri, Dec 01, 2006 at 11:21:55AM +0100, Jean-Francois Cousi wrote:
  En faisant exploser la Bande Passante moyenne par abonné, les services de 
  vidéo (ajouté au P2P) remettent en cause tout le modele économique des FAI 
  basé sur la mutualisation de la BP (mais c'est pareil pour les hébergeurs 
  qui fournissent 100Mb par serveur).
 
 En tant que site utilisateur averti, je voudrais apporter un point
 de vue différent :
 
   1) le développement de la bande passante consommée/fournie
  par utilisateur était -- et est encore -- prévisible.

En volume sans doute.
Prédir les flux de traffic n'est pas aussi évident.
Savoir si dans 1 ou 2 ans (car chez FT, c'est au moins sur ces
durées qu'on fait le dimensionnement) la croissance se fera :

. Par migration vers le Multicast
. Par CDN plus proche de l'abonné
. Par progres Techno avec du P2P plus intelligent
  (donc encore plus de traffic P2P et moins de CDN centralisé)
. Sans changement, juste croissance de l'existant

Cela change assez la manière dont je dois faire l'ingénierie de mon
réseau.

Dans tous les cas, il est vrai que la croissance du traffic est
prévisible.

   2) sur le P2P qui sature les réseaux. Même refrain, je
  rappelle que le P2P a longtemps été un produit d'appel
  quasiment explicite dans les pubs de FAI ADSL !

Pour autant que je regarde les pubs, le P2P n'a jamais été mis en avant.
Peu importe.

   3) sur la distribution de vidéo. Les technologies type
  multicast (voire anycast), sont sous développées et sous
  exploitées au niveau Internet, elles servent uniquement
  en interne chez les FAI pour les bouquets vidéo sur ADSL.
  C'est dommage et les FAI, qui ne proposent pas d'offre
  multicast, en sont très largement responsables. Le routage
  multicast ne passe pas bien à l'échelle d'Internet ?
  C'est vrai, mais si personne ne s'en sert, qui va
  travailler dessus ?

Chez FT, on y a jamais autant travaillé que maintenant (cela sort de RD
:-).
Sur que cela arrive un peu tard mais il est pas mal que face au mur on
commence à se dire que c'est une solution.

 - Ne rien faire, suivant le principe du Best effort (bienvenue
   chez IP). Les premiers contenus impactés sont ceux qui sont les
   plus consommateurs et malcommodes à gérer, la VoD d'abord, les
   téléchargements de vidéo ensuite. Si les sites de distribution
   de vidéo abusent autant que les FAI essaient de nous l'expliquer,
   ils seront les premiers pénalisés. Si des FAI meilleurs que les
   autres arrivent à gérer, tant mieux pour eux. C'est un problème
   de gestion de croissance de l'activité, certains sont bons,
   d'autres mauvais, et que les meilleurs gagnent.

C'est en effet la tendance. On laisse faire en connaissance de cause.

Il y a 3 ans, un lien d'edge (peering/client) saturé était le diable.
Maintenant, c'est la preuve qu'on sait gérer le business :-)

Je caricature un peu ...

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



RE: [FRnOG] Content Deliver y Network (CDN) à la francaise

2006-11-29 Par sujet Vincent Gillet - Opentransit
 mais si je comprends bien, le seul intéret pour un fournisseur d'accès de 
 refuser un peering gratuit, ou tout autre solution qui pourrait insiter une 
 aumentation de contenu c'est de se debarrasser du traffic qui pourrait lui 
 poser plus de soucis qu'il en a déjà avec le trafic inévitable ?

le seul intéret ... non ... on est pas dans un monde manichéen.

Un intéret est en effet d'éviter de rajouter du traffic et donc des
couts sans avoir de revenus.
Si le CDN ne paye pas le traffic, il aura tendance à ne faire aucune
effort technique ou commercial pour baisser le volume.

Si le cout augmente, il va reflechir à optimiser sa techno pour baisser
les couts. Tout le monde y gagnera.

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



Re: [FRnOG] Que se passe t-il ?

2005-02-17 Par sujet Vincent Gillet - Opentransit
[EMAIL PROTECTED] disait :

 c'est moi qui comate ou l'ont ségare du probléme des é-mails !?

yep.

 ici, nous devriont lâcher nos argumentaire pour des arangements 
 amiables, des gens d'OpenTransit

Si on ne peut pas trop causer de la polémique proprement dite
on peut en effet parler des arguments utilisés par un gros opérateur
historique pour le peering.

Par exemple en ce moment, les gros opérateurs EU essayent de publier des
peering policy.
Ils essayent aussi si possible d'utiliser des criteres similaires.

Chacun tente de les appliquer avec plus ou moins de succes.

Ce n'est sans doute pas idéal pour ceux qui pensent mériter un peering
et qui se le voient refusés/dépeerés. D'un autre coté, c'est bien un progres
par rapport au 100% subjectif d'il y a 5 ans.

Dans les peering comité auxlequels je participe depuis des années,
la question est désormais
sont ils compliant ?
plutot que
a votre avis  ?.

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



Re: [FRnOG] BGP et MD5

2004-04-22 Par sujet Vincent Gillet - Opentransit
Sir Jerome,

 Juniper  Cisco ont tous les deux publié des bulletins de sécurité relatifs a la 
 vulnerabilité
 de TCP au paquets spoofés.
 
 Le bulletin Juniper (disponible pour peu d'avoir un acces client a juniper.net) 
 renvoie sur ce
 lien:
 
 http://www.uniras.gov.uk/vuls/2004/236929/index.htm
 
 qui explique assez bien le probleme.
 
 le bulletin Cisco est ici:
 
 http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-ios.shtml
 
 D'une maniere generale la vulnerabilite affecte tous les stacks TCP.
 
 Les documents soulignent la vulnerabilité plus importante de BGP a cette faille car 
 BGP
 fonctionne sur des sessions TCP continues dans le temps, et cette vulnerabilite 
 permettrait de
 reinitialiser les sessions (je ne te detaille pas les consequences sur l'Internet 
 suite au
 damping des routes qui flappent, etc. tu connais tout ca).
 
 Toutefois, comme tu le soulignes, cela fait deja bien longtemps que BGP est 
 vulnerable a un
 nombre impressionnant d'attaques, sans que cela n'ait jamais gené personne. D'une 
 maniere
 generale, tout protocole de routage non authentifié est vulnerable a des attaques de 
 type
 spoofing (encore pire, un IGP link-state sur media partagé (ethernet) est encore plus
 vulnerable).
 Bref, les 'hackers de l'internet' ont beaucoup de failles plus interessantes a 
 exploiter sur
 les OS que celles qui consistent a attaquer les routeurs.
 
 Cela n'empeche que le mouvement de paranoia de ces derniers jours est finalement 
 plutot
 positif, car on ne peut nier l'utilité d'authentifier les sessions BGP.

C'est un peu la paranoia en effet.
D'un coté, on connait bien les limites et risques de TCP et BGP.

Les risques liés à MD5 sont bien moins connus (CPU hog) et l'overwork
pour les exploitants est aussi pas négligeable.

Je ne suis pas pour le déployer massivement, mais avec les peers qui le
demande.

Vincent.

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


Re: [FRnOG] BGP et MD5

2004-04-22 Par sujet Vincent Gillet - Opentransit
[EMAIL PROTECTED] disait :

 --On jeudi 22 avril 2004 15:20 +0200 Pascal Gloor [EMAIL PROTECTED] wrote:
 
  si on connait le port src/dst, on a effectivement un problème de securité
  car on a plus que 2^16 (65536) possibilités.
 
 Sachant que celui ci est bien souvent visible depuis un looking glass.

... les looking glass bien fait (qui sont la majorité tout de même)
cachent bien cette info.
Par contre, le probleme de la range des ports sources est bien réel.
Il me semble que des vendors tournent sur une cycle de 3 ou 4000 ports
TCP  au lieu d'utiliser le spectre de 32000 ou 64000  c'est un
peu dommage, mais laisse tout de même pas mal de temps pour tomber sur
la bonne combinaison.
Je suis tout a fait d'accord sur l'analyse de Pascal.

Vincent

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


Re: [FRnOG] OpenTransit

2004-04-20 Par sujet Vincent Gillet - Opentransit
[EMAIL PROTECTED] disait :

 At 10:45 20/04/2004, Pascal Gloor wrote:
 FT nous propose un bon prix pour du transit et je me demandais ce que vous 
 pensez (objectivement) de votre ex-AS-monopolitique :-)
 
 
 De maniere generale, FT a plutot toujours fourni des prestations de qualite 
 quand les gens sont capable d'y mettre le prix.
 
 Qu'ils te propose un bon prix ne me dise rien qui vaille :))

Il est frais mon poisson ... il est frais :-)

Vincent.

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