[FRnOG] [BIZ] Acces Internet dans plusieurs DC en Europe

[Vincent Gillet]

Bonjour,

Afin fin d'assurer notre connectivité de Management (out-of-Band) on cherche
un fournisseurs d'acces internet pour monter notre ipsec.

Plutot que demander à chaque DC (dont c'est pas le métier), il est plus facile
de poser la question ici et en français.

Me contacter en privé si besoin.

. ip : une ipv4 (/31 connecté)
. Débit : 10Mb/s
. media : 1G-LX
. spécificité : avoir une connectivité indépendant de Zayo AS6461/AS8218.

Sites concernés :

. France Nice Euclyde
. France Marseille Jaguar MRS1
. France Montpellier Databank
. France Toulouse Databank

. Italie Milan Irideos Via-Caldera
. Italie Milan Data4 Via Monzoro
. Italie Milan ML2
. Italie Milan ML5
. Italie Milan Aruba Ponte San Pietro

. Allemagne Berlin IPB
. Allemagne Berlin NTT BER1

. Belgique Bruxelles : Interxion
. UK Londres : Telehouse West

Cordialement.


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

RE: [FRnOG] [TECH] Couverture Antenne 4G sur pylône mutualisé

[Vincent Gillet]

Salut Laurent,

Merci pour ce retour.

Le pylone actuel Orange fait de la 4G en 800, 1800 et 2100.

Je ne connais pas les fréquences utilisées par Free dans la simulation sur le
pylone Orange.

Sur le nouveau pylone envisagé, Free a prévu du 4G en 700, 1800 et 2600.
Cela semble couvrir les fréquences similaires à celle d'Orange.

Vincent.

> Salut Vincent,
> 
> C'est pas parce que Free utilise le pylône d'orange qu'il utilise la BTS 
> d'orange.
> Utiliser le pylône est juste une commodité pour ne pas mettre des antennes 
> partout.
> Donc il peut y avoir une différence de techno entre les deux opérateurs.
> 
> Ensuite t'as les fréquences qui sont pas les mêmes.
> Entre du 700/800 Mhz ou du 2.6Ghz, c'est pas pareils sur la portée ni sur le 
> comportement à l'intérieur des bâtiments.
> Les fréquences élevée traversent moins bien les mur mais on obtiens de très 
> bonne perf si la bande de fréquence de l'opérateur est importante.
> Les fréquences plus basse passe mieux les murs et porte plus loin mais est 
> plus sujette à saturation et en plus, pour les fréquences proche des 700, 
> parfois, ça fait déconner la TNT.
> 
> En gros, les opérateurs ont tendance à mettre du 2.6Ghz en zone urbaine et 
> des 700/800Mhz en zone rurale.
> Mais pour ça, il faut qu'ils disposent de ces fréquences or ça, ça dépend de 
> ce qu'ils ont acheté à l'ARCEP.
> 
> Laurent
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org  De la part de Vincent 
> Gillet
> Envoyé : mardi 29 septembre 2020 15:52
> À : frnog@frnog.org
> Cc : v...@berce.fr
> Objet : [FRnOG] [TECH] Couverture Antenne 4G sur pylône mutualisé
> 
> J'ai une question sur les antennes mobiles (BTS).
> Cela ne concerne pas "Internet" mais je pense le sujet assez technique pour 
> avoir sa place ici.
> 
> Contexte
> 
> Free a été désigné en 2019 pour couvrir une zone grise en Sarthe.
> 5 points de la commune sont à couvrir par 3 opérateurs (obligation prévue 
> dans le décret, ça ne se discute pas. :-)) Ces points sont actuellement bien 
> couverts par Orange en 4G grâce à une antenne à proximité (pylône 2286421, 
> référence ANFR) :
> . Orange dit avoir une couverture "satisfaisante" sur ces points, . une 
> mesure réalisée avec l'appli "Openbarres" montre un niveau de réception OK 
> (-105 dBm environ), . un test de débit en 4G sur ces points affiche un débit 
> moyen de 50 Mb/s.
> 
> Free a fait une simulation pour utiliser ce pylône existant (propriété 
> d'Orange).
> Le résultat de l'étude est négatif : les 5 points ne seront pas suffisement 
> couverts.
> 
> Question
> 
> Une antenne 4G existe sur le pylône Orange.
> Qu'est-ce qui peut expliquer que la couverture serait bien moindre avec une 
> BTS similaire exploitée par Free ?
> 
> Free n'a donné aucune information sur les données de la simulation :
> . quelle hauteur,
> . quel azimut,
> . quelle technologie ?
> 
> Juste une conclusion : "C'est pas bon !" :-)
> 
> Je ne suis pas compétent sur le hertzien ni sur la pose d'antennes/pylône.
> J'ai supposé que Free pourrait se poser à la même hauteur et même azimut que 
> l'antenne Orange (qui donne satisfaction).
> Il me semble qu'il y a une contrainte sur la distance entre 2 BTS. Cette 
> distanciation est sans doute possible sur ce pylône.
> 
> Objectif
> 
> L'objectif est bien d'avoir des opérateurs supplémentaires sur la zone.
> Réutiliser des infrastructures existantes est mieux que la construction d'un 
> nouveau pylône de 36 m (paysage...).
> L'infrastructure existante est déjà équipée d'un signal 4G identique.
> Il est donc possible de travailler avec des mesures réelles plutôt que des 
> simulations.
> 
> Des avis ?
> 
> 
> ---
> 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/

[FRnOG] [TECH] Couverture Antenne 4G sur pylône mutualisé

[Vincent Gillet]

J'ai une question sur les antennes mobiles (BTS).
Cela ne concerne pas "Internet" mais je pense le sujet assez technique pour 
avoir sa place ici.

Contexte

Free a été désigné en 2019 pour couvrir une zone grise en Sarthe.
5 points de la commune sont à couvrir par 3 opérateurs (obligation prévue dans 
le décret, ça ne se discute pas. :-))
Ces points sont actuellement bien couverts par Orange en 4G grâce à une antenne 
à proximité (pylône 2286421, référence ANFR) :
. Orange dit avoir une couverture "satisfaisante" sur ces points,
. une mesure réalisée avec l'appli "Openbarres" montre un niveau de réception 
OK (-105 dBm environ),
. un test de débit en 4G sur ces points affiche un débit moyen de 50 Mb/s.

Free a fait une simulation pour utiliser ce pylône existant (propriété 
d'Orange).
Le résultat de l'étude est négatif : les 5 points ne seront pas suffisement 
couverts.

Question

Une antenne 4G existe sur le pylône Orange.
Qu'est-ce qui peut expliquer que la couverture serait bien moindre avec une BTS 
similaire exploitée par Free ?

Free n'a donné aucune information sur les données de la simulation :
. quelle hauteur,
. quel azimut,
. quelle technologie ?

Juste une conclusion : "C'est pas bon !" :-)

Je ne suis pas compétent sur le hertzien ni sur la pose d'antennes/pylône.
J'ai supposé que Free pourrait se poser à la même hauteur et même azimut que 
l'antenne Orange (qui donne satisfaction).
Il me semble qu'il y a une contrainte sur la distance entre 2 BTS. Cette 
distanciation est sans doute possible sur ce pylône.

Objectif

L'objectif est bien d'avoir des opérateurs supplémentaires sur la zone.
Réutiliser des infrastructures existantes est mieux que la construction d'un 
nouveau pylône de 36 m (paysage...).
L'infrastructure existante est déjà équipée d'un signal 4G identique.
Il est donc possible de travailler avec des mesures réelles plutôt que des 
simulations.

Des avis ?


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

Re: [FRnOG] [ALERT] Neo HS ?

[Vincent Gillet Neotelecoms]

Le feu éteint, on explique un peu plus :

Suite à la coupure électrique partielle à TH2, les 2 routeurs de coeur
fonctionnaient sur 3 pattes :

. 1 chassis a completement reloadé.
. 1 chassis a éteint 50% des slots mais la RE a continué.

Lorsque le courant est revenu, certains slots n'ont pas redémarré seuls.
Pourquoi ... mystère encore à ce jour.
Un reload en cli a permis de tout relancer  pendant 1 heure.

Vers 11h45, d'autres trucs sont partis en sucette au niveau de la commutation.
Interfaces UP mais genre trou noir  dont le trafic de notre IT, téléphonie, 
DMZ, ...

On a pris la décision de reload completement le chassis.
Depuis ça marche mieux :-)

Voila les faits.
Si vous voulez d'autres explications, c'est demain.
On paye un coup. Je mets un ciré. Amenez vos tomates :-)

Vincent.

> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de
> Cédric Lévêque
> Envoyé : jeudi 19 septembre 2013 12:27
> À : frnog@frnog.org
> Objet : RE: [FRnOG] [ALERT] Neo HS ?
> 
> Support Neo débordé, tout le traffic via Neo disparait dans la nature.
> 
> Neo HS !
> 
> -Message d'origine-
> De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de
> Raphael Mazelier Envoyé : jeudi 19 septembre 2013 12:11 À : frnog@frnog.org
> Objet : [FRnOG] [ALERT] Neo HS ?
> 
> Suite au problème à TH2, toutes ce qui passait via Néo partait dans le wrap.
> On a shuté. Le support est non joignable. Il y a t'il des gens qui constate
> la même chose ?
> 
> --
> Raphael Mazelier
> 


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

[FRnOG] [MISC] Bear'n geek

[Vincent Gillet]

Juniper, Neo Telecoms et Intexan organisent un beer event technique Juniper le
mercredi 29 mai au pub O'Sullivans. Ce sera l'occasion de partager les
expériences techniques avec des experts switching, sécurité et routage, dans
une ambiance conviviale.
 
Cette soirée est réservée aux équipes techniques (ex ou futur geek accepté :-).

Elle sera animée par un quizz sur les technos Juniper avec un iPad mini à
gagner pour le meilleur.

Il reste quelques places disponibles.
Inscription obligatoire (sinon ce sera grenadine'n geek en terrasse)

http://www.neotelecoms.com/fr/evenements/beer-event-technique-juniper

Vincent.


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

Re: [FRnOG] [MISC] - France-ix en region

[Vincent Gillet]

jer...@ceriz.fr disait :

> Non, ce n'est pas l'objet. C'est plus une question de pragmatisme
> technique et économique : la centralisation crée de la fragilité et
> consomme de la BP pour des allers-retours inutiles. Tout l'inverse du
> peering, dès lors qu'on reconnait l'intérêt de peerer en région.

Le but ici est de joindre simplement en peering des opérateurs qui sont à Paris.
Ne pas chercher plus loin.

Les acteurs locaux peuvent peerer en région avec ou sans IX.
Ils sont ravis d'éviter Paris.
C'est souvent ainsi que se monte un IX.

Je ne pense pas que cette initiative va empêcher les acteurs locaux de
s'échanger du trafic. On ne poursuit pas le meme but.

Des opérateurs d'une même région pourront constater le trafic
échangé et monter une interco locale (privée ou ix) car
ils auront vu que "ca vaut le coup" (prix, RTD, redondance, ...).
On a pas la même vision de la poule et l'oeuf !

Vincent.


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

Re: [FRnOG] [MISC] - France-ix en region

[Vincent Gillet]

Hello,

L'offre est destinée aux villes dans lesquelles il n'y a aucun point d'échange
local.

Il n'y a pas intéret à faire celà à Marseille, Lyon ou Toulouse. Je crois
même que Neotelecoms ne le propose pas sur ces villes.

A Besancon, Nantes ou Clermont Ferrand, c'est ça "ou rien".

Un petit opérateur qui veut commencer à faire du peering va probablement
trouver plus de peer (payant ou gratuit) sur le France-ix que sur le LAN du 
datacenter.

France-ix n'a pas vocation a avoir la même capillarité en France que Neo.
Cette offre est destinée à apporter ce point d'échange dans des villes où
France-ix n'a pas d'intéret à s'installer ou pas d'interco avec un IX local.

France-ix a une offre de revendeur adaptée à cela. 

C'est un peu "la continuité térritoriale" :-)

V


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

[FRnOG] [JOBS] Ingé réseau 15 ans d'expérience

[Vincent Gillet]

Bonjour,

Je cherche à changer de poste.

Domaines de compétence :
. Responsable de production réseau (WDM, IP, MPLS),
. Gestion de projet,
. Routage (Peering, BGP, IGP),
. Approche Multiconstructeur (Cisco, Juniper, Huawei, Foundry, Ekinops),
. Monitoring (IP, WDM, systeme) et outils de production,
. Systèmes Linux

Actuellement en CDI. Disponible à partir de septembre/octobre 2012.
Zone géographique : Paris

CV disponible sur demande.

Vincent.


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

Re: [FRnOG] [TECH] Nom de la ville et/ou coordonées géographiques dans rDNS

[Vincent Gillet]

Bonjour,

J'avais fait le script qui fait les reverses chez Opentransit/FT.
C'était l'occasion de faire les records "LOC" en meme temps.

J'étais déçu de voir qu'aucun d'outil utilisait ce RFC pour faire des
traceroutes graphiques (par exemple).

Le nom de la villes dans le PTR est bien plus utilisé bien que non normalisé.

Voila mon retour d'expérience d'un carrier, pas un FAI.
Les records LOC semblent toujours en place depuis 10 ans !

V


> Il y a plusieurs FAI Français qui incorporent le nom de la ville (ou partie) 
> ou le département, ou des coordonnées dans leurs PTR. Par exemple:
> anancy-151-1-215-34.w83-194.abo.wanadoo.fr
> mor91-1-89-82-22-219.dsl.club-internet.fr
> 
> J'aimerais bien lire les gens qui ont fait ce genre de chose (ainsi que ceux 
> qui y ont pensé et ne l'on pas fait).
> 
> - Avantages / inconvénients ?
> - Est-ce qu'il y a des papiers ou des présentations ?
> - Efforts de standardisation ? (pour l'instant on dirait que tout
>   le monde fait son truc dans son coin)
> - Conséquences sur DNS en prod.
> 
> etc...
> 
> Merci,
> Michel.


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

Re: [FRnOG] GBLX / ORANGE

[Vincent Gillet]

jer...@ceriz.fr disait :

> Le 17/01/11 20:04, Vincent Gillet a écrit :
> > C'est le cas de Sprint, UUNET, ATT, NTT, C&W, Telefonica, DTAG et Telia
> > dans une moindre mesure (ils étaients low-cost pour moi à une époque !).
> > Ces opérateurs ont un intéret similaire à Opentransit :
> > . Garder une bonne qualité avec les autres,
> > . Ne pas pousser à la consommation
> > . Ne pas tirer les prix vers le bas.
> 
> Tiens ça me rappelle une histoire entre trois opérateurs de téléphonie
> mobile en France. Comment ils avaient appelé ça ? Entente illicite, non ?
> 
> (note: prendre telia de haut, comment c'est trop has-been !)

Normal, je suis has-been dans le peering. Je te dis comment ca a été perçu.
Il n'y a pas entente ou plutot il y a entente entre tous les gens faisant du
peering entre eux.

> Des eyeballs qui ont DEJA payé leur FAI pour être connecté à TOUT Internet.

Ils sont connectés a tout internet avec plus ou moins de qualité selon qu'il
soient chez toto ou titi.
Tout comme vous n'avez pas la meme chose chez Castorama, Bricorama ou
Bricodepot ou GMF, Groupama et MMA pour les services.

> Il est là, le foutage de gueule : se faire payer aux deux bouts, c'est
> pas de l'Internet, c'est un comportement qui mérite un depeering pur et
> simple.

Là, on s'éloigne des sujets techniques.

> Là dessus, je suis tout à fait d'accord avec le banner de megamachin :
> "ça rame ? prends un vrai FAI."

Alleluia.

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

Re: [FRnOG] GBLX / ORANGE

[Vincent Gillet]

sxp...@sxpert.org disait :

> Et on peut donc supposer que l'entité légale 3215 paye au tarif du marché le 
> dit traffic à l'entité légale 5511 j'imagine ?
> Dans le cas contraire l'autorité de la concurrence pourrait se montrer 
> fortement intéressée par le sujet...

Il n'y a pas d'entité légale et donc pas de vente.

BGP est une vue technique.

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

Re: [FRnOG] GBLX / ORANGE

[Vincent Gillet]

D'une manière générale, OTI possede des peerings de qualité avec des
opérateurs similaires :

. Historique
. Non low-cost

C'est le cas de Sprint, UUNET, ATT, NTT, C&W, Telefonica, DTAG et Telia
dans une moindre mesure (ils étaients low-cost pour moi à une époque !).
Ces opérateurs ont un intéret similaire à Opentransit :
. Garder une bonne qualité avec les autres,
. Ne pas pousser à la consommation
. Ne pas tirer les prix vers le bas.

Les autres opérateurs de transit plus "low-cost" (la liste est facile a faire
!) se voient "baladés" pour les upgrades de peering car il n'y a pas d'intéret
mutuel. C'est la base du peering.

Remarquez ici, que je ne parle pas de l'utilisateur final. Je parle de
l'intéret de l'Entreprise, mon ex employeur !

Pour Opentransit, je confirme que 3215 représentait moins de 50% du volume de
5511.

Je considère comme Raphael que la connectivité a un prix.
Si un content veut joindre des eyesballs, il sait comment se connecter et a
quel prix.

Libre a lui de décider de joindre ses clients (car les eyesballs font son
revenu) d'une maniere "non adaptée" puis de s'en plaindre 

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

Re: [FRnOG] le traffic de youtube: gratuit ou presque ?

[Vincent Gillet NEOTELECOMS]

> >Free et SFR semblent peerer avec google/youtube je pense que ca doit  
> >etre
> >gratuit pour google. FT semble passer par Telia est ce que telia est  
> >leur
> >transitaire ?
> 
> Yep, la relation n'est pas defini (whois -h whois.ripe.net) pour  
> AS5511 ou AS3215 avec AS15169 mais je doute sérieusement que Telia  
> soit le transitaire de FT.
> Si c'est le traceroute que tu vois ca veux surement dire que FT vois  
> google par la car c'est un peer de Telia.
> Ca pourrait aussi etre que c'est mieux pour les deux reseaux comme ca  
> (capacite, etc.).

Le route serveur de AS5511 suffit a voir que FT passe par Telia et/ou L3 selon
le bon vouloir de Google (et la place sur les tuyaux :-)

Opentransit (et le RBCI) refuse de faire un peering avec google car non
conforme aux criteres, mais surtout de mon point de vue, cela ne peut que
amener plus de trafic vers les end-users ... et pas de revenu evidement.

On en revient au thread initial "payer à l'usage".

Ayant quitté Opentransit, je peux parler plus librement de mon point de vue,
mais le devoir de réserve demeure ;-) 

> >Bientot comme le suggère l'article il va falloir payer pour peerer
> >avec google/youtube ;)
> 
> A moins qu'il y ai eu un gros changement de politique chez Google, je  
> ne le pense pas.
> Pour un Eyeball Google est normalement le deuxieme plus gros peer  
> (apres Akamai).
> Mais comme Google est tres secretif, rien n'est impossible.

C'est le deuxieme plus gros CDN ... pas le plus gros peer.
Le trafic eyeball-eyball diminue mais reste encore supérieur à celui de
google/akamai.

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

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

[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] Parlons d'IPv6

[Vincent Gillet - Opentransit]

> équipementier n'a pas d'offre sérieuse de routeurs/fw/lb IPv6, mon ISP
> n'offre pas d'IPv6 et je n'ai pas envie de l'embêter (j'attends qu'il
> me l'offre sans quémander), je n'ai pas d'opérateur de transit, le

Depuis qu'opentransit propose de l'ipv6 en dual-stack à tous ses clients, on
est passé 1 clients en 2003 (Renater) a plus d'une dizaine aujourd'hui.

Je ne m'attendais pas à une croissance, mais finalement les clients qui
voient l'option "Do you want native ipv6" dans le contrat cochent l'option
et disent à leurs techos de s'y mettre.

Cela ne fait pas de trafic pour autant, mais améliore la connectivité
v6 (remplace les tunnels) et démocratise v6 avec des petits opérateurs qui
ne se seraient pas posés la question si l'option n'était pas proposée.

Même si on est loin du end-user et content, je trouve important que v6
devienne accessible aux opérateurs/ISP aussi facilement que v4.
Lorsque la migration devra arriver a marche forcée, les opérateurs auront
déjà des notions de v6. Pour le SI c'est idem. Chez Orange, peu d'appli
sont prévues pour le v6. Le fait d'avoir une offre v6 officielle permet de
faire évolué cela ... tout doucement comme dans toute grosse boutique.

Depuis 5 ans, les ipv6 pour Opentransit sont allouées par un outils "non
officiel". Pour faire intégrer cela dans l'outils "Corporate" c'est des années
de travail, mais c'est le même outil qui servira pour les blocks DSL.

Dans un groupe comme Orange, j'estime que moins de 10% des gens qui
touchent à l'IP connaissent aussi ipv6. Il faut que cela augmente.
Rendre le service "disponible officiellement" va dans ce sens.

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

Re: [FRnOG] Meilleurs solution technique => Backbone Internet dans MPLS

[Vincent Gillet - Opentransit]

> Pas besoin de mettre le backbone internet dans un VRF... vous mettez ca
> uniquement dans address-family ipv4 (native).
> Les VPN MPLS sont annonces en MPBGP dans address-family vpnv4.  RSVP et TE 
> tunnels pour la qualite de service
> a travers le core pour les clients VPN.  les VPN MPLS resent toujours dans
> leurs VRF sauf en cas de "route leak" fait expres.
> 
> Comme ca on peut fournir un service MPLS VPN ou EoMPLS pseudowire pour des
> clients a travers le backbone, et se servir du meme backbone pour le
> trafic internet "normal".

C'est tout a fait ainsi que tourne le réseau international
de FT/Orange (Opentransit, pas Equant/OBS) depuis 6 ans.

Internetv4+v6 en IP, le reste en MPLS, mais pas de RSVP ni TE pour le moment.

Y'a toujours des "illuminés" qui poussent à mettre Internet dans une VRF,
mais pour le moment, on résiste !

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

Re: [FRnOG] Rupture ou depeering Cogent <-> Orange ?

[Vincent Gillet - Opentransit]

[EMAIL PROTECTED] disait :

> Bonjour la liste,
> J'ai des choses bizarres depuis des accès clients Orange jusqu'à mes serveurs
> par Cogent.
> Des traceroute qui vont tourner aux états unis, des services indisponibles, 
> etc ...
> 
> Quelqu'un aurait des infos sur une nouvelle engueulade entre FT et Cogent ?

MAx prefix ... g .. en cours.

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

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

[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] stm-1 vs lan2lan

[Vincent Gillet - Opentransit]

[EMAIL PROTECTED] disait :

> J'avais souri en lisant récemment:
> 
> > > A l'heure actuelle quelle est la version optimale et stable d'IOS pour 
> > > cette
> > > carte ?
> 
> > J'envoye ce type d'info en privé !!
> 
> 
> Je continue d'être étonné que la paranoïa/peur/psychose subsiste à tel point 
> que
> les gens ne se permettent de critiquer... que si la cible n'est pas
> explicitement nommée:

Mon patron me gronde si j'en parle. C'est simple.

24 heures apres avoir parlé d'un gros caca sur une carte 8x10GE, j'avais
le coup de fil d'un collegue me disant "t'aurais pas du car  blablabla".

Comme tout salarié, j'essaye de respecter les consignes de celui qui me paie.
Parfois je ne suis pas d'accord.
J'agis selon un compromis entre les deux.

> Peut-on espérer relever le niveau en réclamant que chacun poste avec ses
> couilles ?

Non en ce qui me concerne, car j'ai les couilles au chaud chez FT et je
suis les consignes données par celui qui me nourri, dans la limite de ma 
conscience ou
de l'intéret général.

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

Re: [FRnOG] Migration vers sup720-3BXL

[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] Re: [FRnOG] R éseau Orange depuis 30 minutes

[Vincent Gillet - Opentransit]

[EMAIL PROTECTED] disait :

> J'ai réussi à avoir une réponse de FT dans la nuit sur le problème. Voila
> leur message :
> 
> Nous avons eu un incident de routage sur le réseau Opentransit à Paris.
> Nous avons dû reloader une carte 10G sur un de nos routeur à Paris.
> L'incident a été résolu à 18h12 utc

Je suis agréablement surpris que cette info (exacte) arrive jusqu'au end-user 
!!!

Quand une carte 8 10GE pars en vrille, ca fait du dégat ...
Vive les CRS (comme dirait Sarko :-)

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

Re: [FRnOG] Wanadoo / Orange SMTP

[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] Wanadoo / Orange SMTP

[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] [OT] Contact Transit FT

[Vincent Gillet - Opentransit]

[EMAIL PROTECTED] disait :

> Bonjour,
> 
> Je chercher a acheter du trafic FT (AS 3215) et/ou OpenTransit (AS 5511) sur
> le site de Redbus à Courbevoie.

Pas de chance, ni 3215 ni 5511 ne sont présent à RedBus.
Il faudrait donc une boucle locale pour les joindre 

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

Re: [FRnOG] Problème FT

[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

[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/

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

[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/

[FRnOG] GLC-T sur Catalyst

[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: [FRnOG] Re: [FRnOG] Con tent Delivery Network (CDN) à la francaise

[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 R&D
:-).
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

[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] Content Deliver y Network (CDN) à la francaise

[Vincent Gillet - Opentransit]

[EMAIL PROTECTED] disait :

> S'ils prennent la peine d'installer les serveurs chez le FAI, pourquoi 
> les faire payer ?

Car le modèle de business change et on ne désire pas faire transporter
le traffic "pour rien".
Certes le End-user paie, mais pour un fournisseur de contenu, je
considère que c'est ce dernier qui a besoin de s'approcher du end-user.
Donc je désire le faire payer.

"installez votre CDN au cul de tous les DSLAM et on en reparle".
Si le CDN veut installer des boites chez l'ISP pour s'approcher de
l'abonné, il doit payer.
Faute de quoi, il passera pas un lien de peering/transit qui ne lui est
pas dédié et qui pourra saturé si l'ISP le désire.

> En ce qui concerne un CDN franco-francais, pourquoi pas, mais Akamai est 
> déjà bien présent en France et sur du contenu franco-francais.

ho oui ... si ce n'est trop.

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

Re: [FRnOG] Peering Cogent

[Vincent Gillet - Opentransit]

Bonjour,

> Après cette brêve présentation, voici une question qui me turlupine.
> D'après ce que je vois un peu partour sur le Net, Cogent a des petits
> soucis de Peering, et surtout une politique "peering" assez particulière.
> Après avoir eu un bref contact, on m'affirme que les soucis de peering sur
> le territoire français font partis du passé ...
> 
> Quelques-uns d'entre vous auraient-ils une expérience à me faire partager
> à ce niveau ?

Evidement pas mal de chose sont confidentielles sur ce sujet épineux.

Tout ce que je peux vous dire est qu'à ce jour, Cogent n'a pas de
peering avec FT  mais FT <> la France :-)

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

Re: [FRnOG] Cogent / FT

[Vincent Gillet]

[Merci de ne pas me rentrer dedans tout de suite :-)]

> Il y a aussi la facon legerement plus propre: tirer un cable vers un 
> autre client cogent dans le meme colo qui a un AS (et donc qui peut 
> joindre FT via son autre transit) et poser des routes statiques vers 
> 3215 (cela tient evidemment tant que le sens FT -> OT -> Sprint -> Verio 
> -> Cogent marchera).

A priori, FT continuera à faire suivre les paquets à Cogent par son
fournisseur de Transit qu'est Sprint.

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

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

[Vincent Gillet - Opentransit]

> "sont ils compliant ?"
> 
> Oui mais sur quels critères ? assez de bande passante ? Ou le fait de 

Sur les criteres que l'opérateur publie.

> gagner en qualité de route ? Il faut penser à la clientèle qui par moment à 
> des besoins pour accèder des réseaux
> qui ne sont pas de la taille d'un ISP Historique.

Ceci est aussi considéré.

Lorsque un ISP est "border line" sur certains criteres, on se base aussi
sur des criteres hors peering policy :

. Qui sont les transiteurs,
. Avec qui a-t-il déjà un peering (dans le opérateur de taille similaire).
. Comment est il joignable pour le moment.
. Est-ce que l'opérateur a des chances d'atteindre le critere manquant dans les
6 mois

Selon tout cela on estime que "ca vaut le coup" ou pas.

La premiere question est tout de meme celle des critères.

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

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

[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] Que se passe t-il ?

[Vincent Gillet - Opentransit]

[EMAIL PROTECTED] disait :

> On ne se demande pas du tout, au contraire :-)
> 
> > Il est écrit dans l'article que PROXAD est également concerné par le
> > problème, quelqu'un a t'il plus d'informations la dessus ou est-ce
> > simplement ce cher Octave qui en rajoute vis a vis de son interlocuteur
> > au Journal du Net ?
> 
> Il n'y a aucun problème particulier de mail entre notre site (connecté
> également via Free/Proxad) et Wanadoo.

En effet, je n'ai rien entendu dire concernant cela.
Il n'y a non plus aucun probleme de peering entre Free et FT
(il y a eu ... c'est sur :)

> Il faut prendre les déclarations d'OVH avec un gros grain de sel,
> le but d'Octave étant clairement de forcer la main à FT pour avoir
> un peering. Je ne suis pas sûr qu'il y arrive comme cela, les
> ficelles sont un brin trop grosses et les déclarations d'Octave
> complètement invérifiables.

... Il parait qu'il y a un service de com chez FT  On demande aux
techos de ne pas interférer. On obtempère !

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

Re: [FRnOG]

[Vincent Gillet - Opentransit]

[EMAIL PROTECTED] disait :

> 
> 
> 
> Bonjour,
> 
> 
> Salut tt le monde, je voudrais faire un reset d'un pocket multicom (un petit
> routeur RNIS), mais comment faire. Je recherche aussi de la doc sur des
> switch AVAYA P333R, T et P332G, merci d'avance

De mémoire, Tu mets un cable droit (ou croisé, je ne sais plus) entre les
2 ports RJ45 (RNIS et Reseau), puis tu allumes la bete. Il est reprend
alors sa config d'usine. Reste plus qu'à mettre le cable console fourni
pour mettre l'IP désirée et rebooter.

V

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

Re: [FRnOG] BGP et MD5

[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] BGP et MD5

[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:
> 
> 
> 
> qui explique assez bien le probleme.
> 
> le bulletin Cisco est ici:
> 
> 
> 
> 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] OpenTransit

[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
---

[FRnOG] Politique de peering France Telecom

[Vincent Gillet]

Pour information, la politique de peering de l'as domestique de France
Telecom est désormais public :

http://www.parix.net/Politique-peering-FT-AS3215.pdf

Vincent.

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

Re: [FRnOG] EBGP pour transporter prefixes v4 et V6

[Vincent Gillet]

> D'accord avec Raph : je me vois mal mettre des route-map en inbound juste
> pour forcer le next-hop ipv6 pour les NLRI transportés dans
> l'address-family ipv6 d'une session BGP4+ montée sur du v4.

Pour l'EBGP, je suis convaincu.
La question est plus pour l'IBGP (ou le next-hop n'est pas un problème).

Vincent.

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

Re: [FRnOG] EBGP pour transporter prefixes v4 et V6

[Vincent Gillet]

[EMAIL PROTECTED] disait :

> Personnellement je trouve qu'avec deux protocoles de niveau 3 différents,
> il me paraît naturel de maintenir deux groupes de sessions différentes
> pour le BGP. Si les préfixes IPv6 sont échangés au moyen de sessions
> BGP qui fonctionnent en IPv4, cela veut dire que la bonne marche de
> ces sessions (et donc du réseau IPv6) va dépendre entre autres de
> l'IGP IPv4 (notamment pour l'iBGP).

C'est plutot dans l'autre sens que ca me pose probleme :-)
Pas casser V4 !!!

> Or je ne vois pas pourquoi le réseau IPv6 devrait dépendre du fonctionnement
> du réseau IPv4, même si le réseau physique est le même.

Pour un cisco ou Juniper, cela ne change pas grand chose.
Tout cela est géré par un seul process.
Si l'interface ou le routeur plante, BGP ou pas, ca ne change rien.

Si le process BGP se gauffre, idem.

La seul différence est la stabilité des sessions IBGP.
A ce jour, les IBGP sont plutôt stables. Les instabilités sont plutot aux
EBGP et l'IGP.

l'IBGP ne touche pas aux next-hop qui pose probleme avec les EBGP dual.
Donc pourquoi doubler le nombre de session IBGP.

Lorsque on a 50 sessions IBGP en full mesh, ca fait doubler : 100.

Du coté exploitabilité, les gens sont habitués à une séparation v4 et
v6. Un mélange n'aide pas.

Enfin, point à considérer : l'IGP est commun.
ISIS (je sais pas les autres) transporte les prefixes V4 et V6 ensemble
avec le même chemin et le même calcul SPF (TLV différent).
IGP commun  > IBGP commun ??

> J'aurais plutôt tendance à déconseiller de "fusionner" les deux BGP.

Y'a du pour, y'a du contre  pas facile de choisir.
On peut toujours faire un lab, mais en prod, c'est souvent très
différent et on ne voit pas les problèmes d'exploitations afférents.

Je pense qu'une liste V6 serait plus adaptée pour avoir des retours
d'expérience.

En tout cas, merci dejà de vos commentaires.

Vincent.

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

Re: [FRnOG] EBGP pour transporter prefixes v4 et V6

[Vincent Gillet]

[EMAIL PROTECTED] disait :

> > Vincent Gillet écrit:
> > Quel est le best-practice des opérateurs 100% dual-stack
> 
> Aux Etat-Unis je n'en connais aucun.
> 
> > tant en ce qui concerne I que EBGP ?
> 
> Séparation complète entre v4 et v6 (différents routeurs). Le traffic
> v6 ne représente pas grand chose, un vieux routeur peut s'en occuper
> aujourd'hui presque tout le temps.
> 
> A mon avis, faut être fou pour faire courir des risques à
> l'infrastructure v4; c'est très facile de mettre un routeur à genoux avec
> v6, même quelque chose de relativement puissant comme un 7500. En tant
> que performance v6, il n'y a pratiquement aucune différence entre un
> 3640 et un 7500 avec RSP2. Même avec un RSP8 et un VIP2-50 j'ai mis un
> 7507 à genoux avec quelques malheureux mégabits de v6. Juniper résiste
> un peu mieux (un M40 peut encaisser un OC-192 de trafic v6); à part à
> la maison je ne mélange pas v4 et v6 dans le même routeur.

Il y a tout de même maintenant une dizaine d'opérateurs dual-stack, et
avec des oc48 

Le probleme est qu'une double infra coute cher.
Sur un seul pop, c'est faisable.
Lorsque on a 50 pops et que la trans coute ... C'est pas évident.
Pour le moment, on a déjà le V6 dédié. on cherche à faire un merge avec
V4 sans mettre en péril . Pas évident.

Vincent.

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

Re: [FRnOG] EBGP pour transporter prefixes v4 et V6

[Vincent Gillet]

[EMAIL PROTECTED] disait :

> On ne peut pas à ma connaissance transporter des routes IPv6 dans une
> session BGP IPv4 et inversement.

Transporter des routes V6 dans une session V4, pas de probleme ...
J'ai fait. Il y a même quelques année, il était pas possible de faire
autrement car BGP ne savait que cracher dans du v4 ...

Ca marche aussi bien sur Juniper que Cisco, mais y'a un soucis de
next-hop !!

Vincent.

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

Re: [FRnOG] EBGP pour transporter prefixes v4 et V6

[Vincent Gillet]

[EMAIL PROTECTED] disait :

> On Thu, Oct 30, 2003 at 09:09:58AM +0100,
>  Vincent Gillet <[EMAIL PROTECTED]> wrote 
>  a message of 32 lines which said:
> 
> > Dans ce cas, cela casse un postulat que j'avais en tête :
> > Il n'est pas possible de monter plus d'une session BGP entre 2 routers
> > possédant le même Router-ID.
> 
> En effet, ce postulat est faux. Ici, nous voyons trois sessions avec
> le même routeur (deux points d'échange différents en v4 plus une
> session v6) :

Argh  j'aurais mis ma tête à couper que c'était dans un RFC de BGP4 :-((

Je viens de chercher et évidement, je ne retrouve pas cette info !!

Autre question donc :

Quel est le best-practice des opérateurs 100% dual-stack tant en ce qui
concerne I que EBGP ?

. Une session V4, un session V6 ?
  Ca fait les sessions en double IMO
. Une session qui transporte les 2 ?
  Ca semble plus simple aux premiers abords, surtout pour l'IBGP.
  Peut être est-ce moins robustes (genre update v6 foireu qui plante la
  sessions, donc la connectivité v4 aussi)

Vincent.

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

Re: [FRnOG] EBGP pour transporter prefixes v4 et V6

[Vincent Gillet]

[EMAIL PROTECTED] disait :

> > Vincent Gillet écrit:
> > Jouons avec le dual-stack :-)
> > Est-ce que qq'un a déjà fait de l'EBGP V4+v6 sur Cisco ou Juniper ?
> 
> Oui moi.
> 
> > Si la session est montée sur le /30 de l'ipv4, quell
> > next-hop est positionné pour les prefixes V6 transmis ?
> 
> C'est pas comme ça que dual-stack marche. Personne n'utilise le format "compatible" 
> ::I.P.v.4. Si le même routeur est utilisé pour v4 et v6, il est déclaré comme deux 
> voisins différents, un pour v4 et un pour v6. L'adresse v6 peut avoir (6to4, 
> inhabituel) ou pas (ipv6ip) une relation avec l'adresse v4. Une configuration 
> dual-stack ne connecte pas les mondes v4 et v6 ensemble, simplement permet 
> d'utiliser l'un ou l'autre.

Merci pour ces infos.

Dans ce cas, cela casse un postulat que j'avais en tête :
Il n'est pas possible de monter plus d'une session BGP entre 2 routers
possédant le même Router-ID.

Est-ce que ceci est exact ?

Dans le cas des sessions V4 et V6 en parallèle, les 2 sessions utilisent bien de même
"BGP Identifier".

Vincent

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

[FRnOG] EBGP pour transporter prefixes v4 et V6

[Vincent Gillet]

Jouons avec le dual-stack :-)

Est-ce que qq'un a déjà fait de l'EBGP V4+v6 sur Cisco ou Juniper ?

Si la session est montée sur le /30 de l'ipv4, quel next-hop est
positionné pour les prefixes V6 transmis ?

Juniper semble positionner un next-hop "::l.ip.v4" pas trop apprécié par
le Cisco en face (rejete l'update pour cause de next-hop pas connu).

Est-il obligatoire de mettre une route-map out (ou équivalent Juniper) pour
remettre un next-hop "accetable" ?

Je suppose que les ISP dual-stack avec clients BGP doivent déjà s'être posé
ce genre de question ...

Merci,

Vincent.

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

Re: [FRnOG] Probleme OpenTransit

[Vincent Gillet]

[EMAIL PROTECTED] disait :

> Bonjour
> 
> Quelqu'un est au courant du probleme de ce matin semble-t-il chez
> opentransit ? de 9h30 à 11h30
> 
> Certain site depuis France Telecom (google, lambdanet) n'etait pas
> accessible.

Je ne peux pas trop en parler, mais une mauvaise manip couplée à des
nombreux concours de circonstance a fait "mal fonctionner" une session
BGP avec un de des plus gros peer (histoire de next-hop BGP).

Probleme assez complexe à trouble shooté  Si j'ai plus d'info, je
vous en ferais part.

Vincent.

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

Re: [FRnOG] BGP RouteServer

[Vincent Gillet]

[EMAIL PROTECTED] disait :

> > Comme les sessions de AS12670 et AS8921 sont aussi down, j'imagine qu'un 
> > problème du même genre leur arrive possiblement.
> 
> En parlant de l'AS8921, je cherche un n° de téléphone direct qui marche
> pour les joindre, car leur session BGP IPv6 est down depuis quelques
> semaines et donc leur sTLA n'est plus annoncé...

A la réunion, j'ai cru comprendre que FRNOG avait un route-server v6, mais :

zebra> sh ipv6 bgp 
No BGP network exists

Sur le site Web, je n'ai rien trouvé.

V

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

Re: [FRnOG] Transit FT et Catalyst 3550

[Vincent Gillet]

[EMAIL PROTECTED] disait :

> > Bonjour
> > 
> > - Quelqu'un sait si FT vend du transit dans un centre de colocation pour ne
> > pas avoir les frais de construction de ligne ?
> > (Parix c'est uniquement du peering ? ils y vendent du transit aussi ?)
> 
> Qui peut me confirmer que FT est bien raccordé de mannière opérationnel
> au SFINX ?

Je ne crois pas.
En tout cas, ce n'est pas le réseau Opentransit (IP international de FT).

Vincent.

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

[FRnOG] Juniper et transfix sur E1.

[Vincent Gillet]

Hello all,

J'essaye de faire fonctionner une interface E1 d'un Juniper
sur une LS transfix de FT livré en 1920 sur un ETCD BMD
(le modem de FT).

En framing g704, je n'arrive à obtenir qu'un yellow Alarm ...
... comme si le BMD ne savait pas interpreter le tramage émis
par le Juniper.

En "unframed", pas de probleme.

Si vous avez un exemple de config, you are welcome !!

Merci.

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

[FRnOG] Cable X21/V11

[Vincent Gillet]

Puisque il semble qu'on puisse utiliser cette liste
pour demander des petites choses :

Je cherche un cable croisé X21 (DB15 Male/Male) d'une longeur quelconque.
Est-ce que qq'un aurait cela dans un placard poussiéreux ???

Merci.

Vincent.

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