Re: [FRnOG] Configuration ATM Cisco sur DSLE France Telecom

[Rachid Zitouni]

Oam pvc manage ne vaut que si le modem ft reponds aux oam de ton
routeur d'acces. Au lancement de l'offre ft ce n'etait pas le cas.

Rachid


Le 24/01/09, Yann Granger a écrit :
> le routeur genere des OAM end to end, ca valide le PVC jusqu'a la
> terminaison ATM (routeur ou modem si modem ethernet).
>
> Yann
>
> 2009/1/24 
>
>>  Le ping ATM c'est déjà ce que l'on fait quand on est en résolution, mais
>> s'était dans une optique de pro activité, car dans ce cas certain ping IP
>> passe et cela suffit à tromper le monitoring pendant quelques temps.
>>
>> Pour revenir sur la commande oam-pvc manage elle valide la continuité de
>> cellules OAM jusqu'au modem ?
>>
>>
>>
>>
>>
>> Eric
>>
>>
>>
>> *De :* Yann Granger [mailto:yann.gran...@gmail.com]
>> *Envoyé :* samedi 24 janvier 2009 17:13
>> *À :* Cisco
>>
>> *Objet :* Re: [FRnOG] Configuration ATM Cisco sur DSLE France Telecom
>>
>>
>>
>> salut,
>>
>> La commande oam pvc manage permet de monitorer le PVC, c'est elle qui va
>> te
>> dire si ton interface est up/up ou up/down (si le PVC est HS)
>>
>> Pour verifier si tu as des pertes de traffic ATM (a cause du modem ou dans
>> le reseau) tu peux faire un ping ATM end to end depuis ton PE jusqu'au
>> modem.
>>
>>
>>
>> Pour le CBR, c'est quand meme une bonne idee en cas de saturation dans le
>> reseau FT, ton traffic CBR sera moins facilement discardé.
>>
>>
>>
>> Yann
>>
>> 2009/1/24 Cisco 
>>
>> Bonjour à tous !
>>
>>
>>
>> Chez nous par habitude nous utilisons la config suivant :
>>
>>
>>
>> interface ATM2/0.1 point-to-point
>>
>>   ip vrf forwarding CLIENT
>>
>>  ip address x.x.x.x x.x.x.x
>>
>>  ip rip advertise 15
>>
>>  atm route-bridged ip
>>
>>  pvc 1/1020
>>
>>   class-vc xDSL-05c
>>
>>
>>
>> Avec une vc-class associé
>>
>>
>>
>> vc-class atm xDSL-05c
>>
>>   vbr-nrt x x
>>
>>   encapsulation aal5snap
>>
>>
>>
>> D'après ce que tu dis si on se base sur les stas FT on pourrait mettre du
>> CBR mais concrètement quel serait le bénéfice ? Si j'ai bien compris cela
>> permets d'écouler les flux à débit constant sans vérification mais la
>> différence est elle sensible ?
>>
>>
>>
>> D'autres part je ne connaissais pas la commande oam-pvc manage on peut
>> s'en
>> servir pour identifier la perte de quelques cellules dans le cas d'un
>> modem
>> FT qui commence à partir en cahuète ?
>>
>>
>>
>>
>>
>>
>>
>> *De :* owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] *De la part de
>> * Frederic NGUYEN
>> *Envoyé :* vendredi 23 janvier 2009 23:31
>> *À :* frnog@frnog.org
>> *Objet :* Re: [FRnOG] Configuration ATM Cisco sur DSLE France Telecom
>>
>>
>>
>> Il y a une autre possibilité qui génère moins d'overhead:
>>
>> *configuration de l'interface principale:*
>>
>> interface ATM4/0
>>  description Collecte DSLE FT #Ref trunk de collecte
>>  no ip address
>>  atm sonet stm-1
>>  no atm ilmi-keepalive
>>  hold-queue 4096 in
>>
>>
>> *Ensuite, pour chaque nouveau lien, il faut configurer une sous-interface:
>> *
>>
>> interface ATM4/0.1 point-to-point
>>  description Client Delamortkitue #Ref client
>>  ip address x.x.x.x 255.255.255.252
>>  pvc 42/69 <-- vp/vc
>>   cbr 640  <--- FT livre du CBR (constant bit rate), autant en profiter
>>   oam-pvc manage <--- permet de voir si le VC est up/down, plus pratique
>> pour le troubleshooting et supervision
>>   encapsulation aal5mux ip  < on passe en IP over ATM directement ce
>> qui évite l'encapsulation Ethernet (sur des petits débits ça aide bien)
>>
>> 2009/1/15 Jean-Francois Monnet 
>>
>>Bonsoir la liste, Olivier,
>>
>>
>> On Thu, Jan 15, 2009 at 06:02:42PM +0100, Olivier CALVANO wrote:
>>
>> > Je tente ma chance: Je deviens un peu vieux et j'avoue ne pas avoir
>> touché
>> > dans ma carriere
>> > a de l'ATM 
>>
>>Pas grave. Tu n'as rien raté. MPLS now je crois :-)
>>
>>
>> > Quelqu'un pourrait m'aider en deux mots a comprendre comment configurer
>> mon
>> > cisco
>> > avec sa carte ATM PA-A3-OC3SMI afin qu'il cause avec le boitier RAD
>> Ace-2002
>> > de
>> > France Telecom et qui nous sert a recevoir quelques liens DSL ?
>>
>>Un exemple ici de lien DSLE, cote Cisco de collecte (72xx):
>>
>>interface ATM2/0.4 point-to-point
>> ip address w.x.y.z 255.255.255.252
>>  ip broadcast-address w.x.y.z'
>>   atm route-bridged ip
>>pvc SOMEWHERE 1/855
>>  vbr-nrt 2048 2048
>>
>>Il te faut le VP/VC (ici 1/855) de la liaison et le debit nominal
>> (ici 2048).
>>
>>++Jieff
>> --
>> Infosat SA - 132 rue Kennedy 76140 Petit Quevilly - France
>> Jean-Francois Monnet - GNU/Linux Projects - ji...@odie.mcom.fr
>>
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
>>
>>
>>
>>
>> --
>> Yann Granger
>> +44(0)7900 40 74 96
>>
>
>
>
> --
> Yann Granger
> +44(0)7900 40 74 96
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Configuration ATM Cisco sur DSLE France Telecom

[Rachid Zitouni]

Les routeurs d'acces permettent depuis longtemps de faire de
l'oversubscription sur leurs cartes atm (en vbr-nrt c'est sur et peut
etre aussi certainement en cbr).

Rachid


Le 26/01/09, Raphael Bouaziz a écrit :
> On Fri, Jan 23, 2009, Frederic NGUYEN wrote:
>> interface ATM4/0.1 point-to-point
>>  description Client Delamortkitue #Ref client
>>  ip address x.x.x.x 255.255.255.252
>>  pvc 42/69 <-- vp/vc
>>   cbr 640  <--- FT livre du CBR (constant bit rate), autant en profiter
>
> Le problème du CBR c'est qu'à moins de ne vendre que des accès
> à débit totalement garanti, l'interface du routeur va se retrouver
> vite pleine.
>
> Par exemple, 75 liaisons "2c75 S" configurées en CBR remplissent un
> STM-1 alors qu'elles ne représentent que 5,6 Mbit/s de débit garanti.
>
> D'ailleurs c'est la même chose pour le nrt-VBR.
>
> Il vaut mieux mettre de l'UBR+ (en prenant les valeurs PCR et MCR
> des STAS de France Télécom) qui permet à la fois de ne pas surprovisionner
> et de s'assurer que la somme des débits garantis est inférieure au
> débit de l'interface.
>
> --
> Raphael Bouaziz.
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Configuration ATM Cisco sur DSLE France Telecom

[Rachid Zitouni]

Je la refais ;-)
Si tu t'interfaces avec le modem ft et que tu actives oam-pvc manage
sur ton pvc, I'll y a des chances que ton pvc tombe down alors qu'I'll
etait up juste avant le config change. Si cela se passe effectivement
comme ca, c'est que le modem ft a drope tes oam.
Au fait pourquoi tu squizz pas le modem ft...?


Le 26/01/09, ci...@etbweb.net a écrit :
> Certes mais chez nous on avait maqueté le service policy output et ca ne
> marche pas trop bien avec l'ubr...
>
> Par contre je reviens sur l'oam-pvc manage c'est effectivement sympathique,
> une ligne où le modem FT est down fais tomber l'interface, je vais regarder
> si on peut en faire quelque chose avec la perte de cellule ...
>
>
>
> -Message d'origine-
> De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de
> Raphael Bouaziz
> Envoyé : lundi 26 janvier 2009 17:52
> À : frnog@frnog.org
> Objet : Re: [FRnOG] Configuration ATM Cisco sur DSLE France Telecom
>
> On Fri, Jan 23, 2009, Frederic NGUYEN wrote:
>> interface ATM4/0.1 point-to-point
>>  description Client Delamortkitue #Ref client
>>  ip address x.x.x.x 255.255.255.252
>>  pvc 42/69 <-- vp/vc
>>   cbr 640  <--- FT livre du CBR (constant bit rate), autant en profiter
>
> Le problème du CBR c'est qu'à moins de ne vendre que des accès
> à débit totalement garanti, l'interface du routeur va se retrouver
> vite pleine.
>
> Par exemple, 75 liaisons "2c75 S" configurées en CBR remplissent un
> STM-1 alors qu'elles ne représentent que 5,6 Mbit/s de débit garanti.
>
> D'ailleurs c'est la même chose pour le nrt-VBR.
>
> Il vaut mieux mettre de l'UBR+ (en prenant les valeurs PCR et MCR
> des STAS de France Télécom) qui permet à la fois de ne pas surprovisionner
> et de s'assurer que la somme des débits garantis est inférieure au
> débit de l'interface.
>
> --
> Raphael Bouaziz.
> ---
> 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] Meilleurs solution technique => Backbone Internet dans MPLS

[Rachid Zitouni]

On avait reussit a mettre l'internet dans un vpn mais avec une route
par defaut qui backhaul tout le traffic vers des gateway ip (non mpls
vpn) qui eux avaient les full route via differents transit/peering .
Ces gateway partagaient leurs routes avec des RR ip non mpls.
Les problematiques majeures : ibgp dans la vrf et ebgp dans la vrf
avec un as different du process global (as local par vrf).

Quand tu fournis du transit pour tes clients, c'est une autre histoire
mais en retail avec les features qui vont bien, pourquoi pas...

Autre chose : ce n'etait pas du cisco :-P



2009/2/5, Olivier CALVANO :
> Bonjour Messieurs,
>
> En pleine reflexion sur l'evolution de notre reseau, je profite de cette
> liste
> pour obtenir un peu d'aide sur la configuration a mettre en place.
>
> Alors pour résumer, j'ai deux Backbone:
>
> Un réseau MPLS avec un IGP: IS-IS et du MPBGP avec (exemple) en AS 65500
>
> Un reseau Internet composé de X routeur Cisco tous sur le même subnet /25
> (donc un lan etendu ethernet). Chaque routeur internet dispose d'une session
> BGP avec les autres (IBGP). Chacun de ses routeurs a aussi des sessions BGP
> Full Table avec differents opérateurs (Cogent, Interoute etc ..) Ce reseau
> est
> avec un AS unique 65500 (enfin un vrai numero AS)
>
> Mon objectifs est de n'avoir a terme qu'un seul backbone MPLS et de creer
> dans
> celui-ci un backbone Internet.
>
> La question est comment je fais cela en propre ;=) j'ai fait un test:
>
> - chaque routeur dans une VRF, la VRF etant sur le cisco coeur de reseau
> - Routage PE/CE en OSPF (car le core etant deja en BGP, il refusait de
> diffuser les routes)
> - une ip loopback a chaque CE
> - les sessions BGP entre chaque loopback
>
> evidement cela ne marche pas, car un CE ne peux pinguer une IP apprise en
> BGP et ce trouvant sur un autre CE (car le PE ne connait pas la full table)
>
> un traceroute donne:
>  CE1 => PE et la au lieu de renvoyer vers la loopback du CE2, il y a un
> unreachable
>  logique en routage ...
>
> J'ai essaye en faisant un tunnel gre entre les CE, ok cela marche mais bon
> c'est pas cool
> et propre comme soluce je pense !
>
> sinon je pensais faire la VRF au niveau du CE (cisco 7200), mais je sais pas
> si c'est faisable !
>
> Style VRF 1 => Cogent
> VRF 2 = Interoute
> etc et donc mettre l'interface qui relie le C7200 au coeur en
> MPLS/ISIS/MPBGP
> et mettre une session MPBGP entre tout les CE comme je le fais avec mes PE
> MPLS
>
>
> Alors messieurs, si vous voulez partager un peu de votre experience ;=)
> je vous en remercie d'avance
>
> Olivier
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/

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

[Rachid Zitouni]

Le fait de cloisoner les flux internet dans un vpn permet de garder ton plan
de routing igp pour tes flux iptv, voip En effet, je ne suis pas encore tout
a fait sure qu'avec bgp on arrive aux memes perf de convergence qu'en igp.
Si on veut mutualiser sur un PE multi service du l2vpn, l3vpn, multicast,
internet, voip, je crois qu'il n'est pas déraisonnable de cloisonner ses
flux internet dans un vpn.
Attention, je ne dis pas d'avoir la full route dans ta vrf internet mais
seulement un backhaul vers ton core internet
Et quand tu ne fais pas de transit/peering et que tu peux centraliser ta
sortie internet, ce core peut etre tres basique!
Si tu offres transit/peering c'est plus compliqué, mais pas irréalisable :-)



2009/2/6 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/
>
>

[FRnOG] Re: [FRnOG] Re: Re: [FRnOG] Re: Numericable : mauvai se techno ou mauvais réseau

[Rachid Zitouni]

Economiquement c 'est pas plus interessant dans certains cas de mettre un
switch vdsl plutot que de fibrer l'immeuble?
A la louche :

un immeuble de 25 logements sur 5 etages
a la louche au minimum 500m de fibres au total
si on optimise ca va bien chercher dans les 3 à 5 keuros non?
1 petit switch vdsl avec 25 modems alimentes par la paire de cuivre ca peut
etre economiquement plus interessant, non?
16Mbps, je pense qu'on a au moins le double de debit aujourd'hui pour ces
distances, non?

Rachid

Le 24 février 2009 07:06, Vivien GUEANT  a écrit :

> Jérôme Nicolle a écrit :
>
>> Ca me rapelle une affaire ou des entreprises s'étaient associées pour
>> couper l'arrivée FT, faire venir une fibre et mutualiser l'accès,
>> réparti derrière en VDSL (16Mbps à l'époque, j'avais monté du Zyxel).
>> Aux dernières nouvelles, il y avait un procès en cours entre FT et la
>> copropriété. C'était parti sur la dégradation de bien pour avoir
>> sectionné les cables de distribution pour les brasser proprement...
>>
>>
> Dans de nombreux immeubles, les paires téléphoniques appartiennent à
> l'immeuble et pas à FT.
>
> C'est pour cela que FT ne peut pas s'opposer à ce qu'un opérateur qui
> installe son DSLAM en bas de l'immeuble utilise la paire de cuivre de
> l'immeuble. Je pense à Erenis qui mettais un DSLAM en bas d'immeubles
> parisien et qui proposait du 100 Mb/s en VDSL2.
>
> Aujourd'hui suite aux rachat par Neuf-SFR les nouveaux immeubles ne sont
> plus en VDSL mais en Gpon ou P2P. Une migration des immeubles VDSL => FTTH
> est d'ailleurs en cours.
>
> Vivien.
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

[FRnOG] Re: [FRnOG] Re: Re: [FRnOG] Re: Numericable : mauvai se techno ou mauvais réseau

[Rachid Zitouni]

Tu oublies les optiques dans ton calcul et a ma connaisance un
deploiement fibre mm sont 5 a 10 fois plus cher qu'une distribution
cuivre et difficile de mutualiser dans des fourreaux dans un immeuble.
Vdsl2 avec des extensions proprietaires permet une bonne reutilisation
si la paire est bien twisted. Mais si I'll faut refaire la
distribution, le cuivre cat5 a 1 euro/m avec un switch a 10 euros par
port
Serait aussi une alternative possible.


Le 26/02/09, Bernard Dugas a écrit :
> Bonjour,
>
> Jérôme Nicolle wrote:
>
>> Quitte à tirer du câble, ce qui
>> coute quand même moins cher et demande de la main d'oeuvre moins
>> qualifiée que de la fibre.
>
> Les derniers câbles fibre FTTH sont plus petits, plus solides et moins
> chers que des câbles cuivre :-)
>
> Et les switches gigaSFP sont moins chers que du dsl...
>
> A bientôt,
> --
>   __Bernard DUGAS _
> |  IS Production s.a. Innovative Solutions Production |
> |  Technoparc Pays de Gex bernard.du...@is-production.com |
> |  30 Rue Auguste Piccard   Mob.: +33 615 333 770 |
> |  01630 St Genis Pouilly - FRANCE -Fax : +33 450 205 106 |
> |_|
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Re: [FRnOG] Re: Re: [FRnOG] Re: Numericable : mauvai se techno ou mauvais réseau

[Rachid Zitouni]

Le partage d'une fibre va faire des e-mules ;-)


Le 26/02/09, Steven Le Roux a écrit :
> 2009/2/26 Dominique Rousseau :
>> Le Thu, Feb 26, 2009 at 12:24:59AM +0100, Jérôme Nicolle [jer...@ceriz.fr]
>> a écrit:
>>> 2009/2/25 Xavier Niel :
>>> >
>>> > et la paire de cuivre il ne faut pas la repasser ? ;-)
>>> >
>>>
>>> Pas forcement, c'est ce que je suis en train de découvrir chez
>>> certains offices HLM par exemple, la distribution cuivre leur
>>> appartient. Dans ce cas, pour un déploiement rapide, le VDSL n'est pas
>>> inintéressant, surtout avec des composants qui gèrent ADSL2+ et VDSL2.
>>
>> Ouais, tiens, faudrait lancer une startup sur cette idée là.
>>
>>
>> --
>> Dominique Rousseau
>> Neuronnexion, Prestataire Internet & Intranet
>> 50, rue Riolan 8 Amiens
>> tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>>
> ça existe déjà : myIP
>
> mais c'est de la rentabilité rapide et presque abusive (desserte de
> tout un immeuble par 2 ou 3 lignes ADSL partagée par 50 foyers...)
>
> D'autant qu'en sortant, tu passes d'une ligne à l'autre sans affinité
> de session... génial...
>
>
> --
> Steven Le Roux
> Jabber-ID : ste...@jabber.fr
> 0x39494CCB 
> 2FF7 226B 552E 4709 03F0  6281 72D7 A010 3949 4CCB
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Parlons d'IPv6

[Rachid Zitouni]

>Pour conclure, est-il concevable de maintenir pour les box l'attribution
d'une
>IP publique dans les années à venir, voir dans un terme indéfini ?

je ne connais pas les limites actuelles des box pour le napt mais je ne
pense pas que le napt soit dimensionnantPar contre, si tu le fais un hop
plus loin, tu atteins vite les limites de napt (meme si tout le monde sait
que napt n'est pas limité a 64k entrees :-).

Le 19 mars 2009 23:25, Cedric A  a écrit :

>
> Bonjour à tous,
>
> C'est ma première contribution sur cette mailing liste et pour faire court
>  :
> Je suis un ingénieur système louant son âme aux auteurs (humour inside).
>
> Il me semble que les box constituent la majeur part des équipements
> terminaux
> dans les foyers. Ces box font généralement office de passerelle de service
> pour la VOD, la téléphonie, etc... en sus du routage de base. De mon point
> de
> vue de technicien, il me parait donc peu approprié de limiter
> potentiellement
> à un instant t les plages de port source disponibles pour ces équipements.
>
> Comme, à ma connaissance, les besoins d'interfaçage online concerneront à
> terme principalement des équipements "basiques"  (surf depuis un
> smartphone,
> nabaztag, webcams vidéo-surveillance, mise à jour de firmware pour
> console/appareil photo numérique/.., , etc.) ne nécessitant pas à priori
> une
> large disponibilité des plages de port source, ne serait-il pas plus
> pertinent de s'en tenir au rôle de plateforme de routage/NAT des box pour
> ces
> équipements ? D'autant que ces derniers impliquent globalement surtout du
> trafic sortant et que du port-forwarding suffit à contenter ceux amenés à
> fournir du service en ligne.
>
> Pour conclure, est-il concevable de maintenir pour les box l'attribution
> d'une
> IP publique dans les années à venir, voir dans un terme indéfini ?
>
> En espérant avoir quelque peu contribuer au schmilblick sans trop nourrir
> le
> troll, cordialement, Cédric.
>
> Le Jeudi 19 Mars 2009 17:42, Michel Py a écrit :
> > >> Michel Py écrit:
> > >> 1. Sur 100k utilisateurs, ils vont pas tous visiter
> > >> le même site en même temps.
> > >
> > > Dominique Rousseau écrit:
> > > Tous les pouetpouets webdeu avec des ajaxeries de
> > > partout, ça va faire des connexions à répétition.
> >
> > On est bien d'accord, et la liste des cochonneries ne peut que
> s'allonger.
> >
> > > Le/s comptes mail, que tu checkes toutes les minutes.
> >
> > Ca ce n'est pas si ennuyeux; POP et IMAP sur 60 secondes n'ont la
> > connection ouverte que 2 secondes quand il n'y a pas de nouveau mail.
> >
> > > Mais les Dailytube & co déploient des tresors
> > > d'imagination pour que les proxies ne cachent pas.
> >
> > C'est vrai aussi; ne pas oublier ceci-dit que je genre de chose est
> souvent
> > load-balancé sur plusieurs adresses IP, ce qui réduit le problème (le
> coté
> > serveur a également un pb avec le nombre de connections ouvertes).
> >
> > Et puis tous les machins plus ou moins utiles comme le frigo avec GigE
> qui
> > t'envoies un mail pour te dire que le lait est en train de tourner ne
> vont
> > probablement pas avoir toutes les gadgets-qui-font-joli-sur-l'écran d'un
> PC
> > utilisateur.
> >
> > > 1:1 c'est sans doute possible, mais à un moment
> > > la qualité de service en patira.
> >
> > Je pense qu'on ne dépassera pas ça, en effet. Et une solution NAT à
> 1:1
> > faut la regarder pour ce que c'est: de la merde à pas cher.
> >
> > Mais les grands nombres favorisent les ratios élevés; un jour ou l'autre
> il
> > va y avoir quelqu'un qui a été un peu lourd sur la Tsingtao qui va nous
> > mettre 1 million de PC sur un /24 (ça fait 3900:1).
> >
> > > Mais même 1000:1, si on regarde les choses comme ça, ça permet de NATer
> > > tout un tas de cochonneries en repoussant l'échéance du passage à ipv6.
> >
> > CQFD
> >
> > Michel.
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

Re: [FRnOG] Service IPTV en France

[Rachid Zitouni]

Je ne crois pas qu'on te file ici le detail du business plan des free,
neuf, bouygues ou autre pour arriver à 30/mois.
Mais vu les resultats ope, je crois que le calcul a été bon.
Entre les US et la france, la difference majeure viendrait du fait que
le nb d'abonnes moyen par CO est peut être inferieur
si tu prends l'echelle nationale. par contre pour les operateurs qui
s'interessent à une zone dense du pays, le resultat peut être proche
voire plus interessant. par contre, comme je ne connais pas les regles
d'attribution de licence aux US, tu peux imaginer que la concurrence y
soit plus forte donc un risque d'atteindre le seuil de rentabilité
moins rapidement. En france, le nb de licence est limite et le nb
d'abonnes moyen par CO est interessant (il y a de memoire des C0 de
100k abonnes à Paris!)
En fait, c'est toujours pareil : plus le ticket d'entree est eleve,
plus la part du gateau est importante:-)

la plupart des operateurs diffusent en ip multicast pour eviter de
transmettre un million de fois 2M :-)
A ce sujet, quelqu'un sait il si mpls multicast a vu le jour quelque part?

Rachid



Le 16 mai 2009 15:04, Robert Sitan  a écrit :
> Bonjour,
>
> Je discutais l'autre jour avec un ami américain des offres des FAI dans nos
> pays respectifs. Quand je lui ai parlé des offres "triple-play" en France,
> il était surpris comment c'est possible d'avoir les 3 services pour 30€/mois
> alors que ça coûterait au moins le double (voire le triple) aux Etats-Unis.
> Alors je me tourne vers vous pour avoir des éléments de réponse aux 2
> questions suivantes :
> 1) A quoi est dû le prix très acceptable de l'offre "triple-play" en France
> : concurrence entre FAIs, infrastructure déployée... ?
>
> 2) Comment se fait la distribution TVoIP en France ? J'imagine que toutes
> les chaînes ne sont pas diffusées à tous les utilisateurs en même temps.
> IMHO, ça serait à travers des serveurs caches (régionaux ?) auxquels sont
> diffusées toutes les chaînes et qui gèrent eux-mêmes les demandes des
> utilisateurs ?
>
> Si la réponse se trouve dans un thread précédent, merci de me l'indiquer.
>
>
> Cordialement,
>
> Robert
>
>
> 
> Insert movie times and more without leaving Hotmail®. See how.
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Erreur BGP !

[Rachid Zitouni]

Hello,

Peut être lié à la nego des capabilities bgp (rfc 3392)
Extrait :
   If a BGP speaker that supports a certain capability determines that
   its peer doesn't support this capability, the speaker MAY send a
   NOTIFICATION message to the peer, and terminate peering (see Section
   "Extensions to Error Handling" for more details).  The Error Subcode
   in the message is set to Unsupported Capability.  The message SHOULD
   contain the capability (capabilities) that causes the speaker to send
   the message.  The decision to send the message and terminate peering
   is local to the speaker.  If terminated, such peering SHOULD NOT be
   re-established automatically.

capability code 128-255 for private use :
http://www.iana.org/assignments/capability-codes/

Si tu fais un debug ip bgp update, tu pourras peut être faire le lien
avec ton message.

Si tu as d'autres messages, tu peux aussi utiliser le tool cisco
"error message decoder".

Sinon, il reste le tac...

HiH
Rachid


Le 5 juin 2009 23:39, Youssef
Bengelloun-zahr a écrit :
> Hello,
> Juste pour préciser, cette erreur est apparue pendant un incident avec SFR.
> Un des modules du routeur de coeur sur lequel est connecte la porte de
> collecte a pété un câble, cela a provoqué le flappe des sessions BGP entre
> mon AS et celui de SFR pendant plusieurs heures.
> En temps normal, cette erreur n'apparaît pas dans mes logs.
> Si c'est juste un bug, a priori sans impact, je ne vais pas prendre le
> risque de MAJ un IOS sur un routeur de coeur uniquement pour le plaisir de
> faire disparaître un bug ?!?
> Encore merci a tous pour vos réponses passées et futures.
> Bonne soirée.
> Y.
>
>> From: david...@euro-web.fr
>> To: frnog@frnog.org
>> Subject: Re: [FRnOG] Erreur BGP !
>> Date: Fri, 5 Jun 2009 18:55:29 +0200
>>
>> Le Friday 05 June 2009 16:31:21 Youssef Bengelloun-zahr, vous avez écrit :
>>> Pour la MAJ d'IOS, non : "If it works, don't touch it !
>>
>> But it does not work ?
>>
>>
>> --
>> David CHANIAL - Euro Web SARL
>> http://www.sd-france.com/
>> Conseil & Infogérance
>> Location de serveurs
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>>
>
> 
> Découvrez tout ce que Windows Live a à vous apporter !
---
Liste de diffusion du FRnOG
http://www.frnog.org/

[FRnOG] Config end of rack Vs top of rack

[rachid . zitouni]

Bonjour!

Avez vous déja regardé de près ce qui détermine le choix d'un design DC?

Ma compréhension est que deux design sont possibles :
1/ Installation top of rack
Dans ce cas les switchs sont installés en haut de la baie
Est ce qu'il ya une densité minimum de ports cuivre/fibre à respecter?
Quelle type de connectivité (6/6a/7) prévoir avec ses  
avantages/inconvenients en terme opérationnel et également de cout?
Est ce qu'il faut prévoir une connectivité 10G tout de suite? Je ne connais  
pas du tout l'état de l'art sur la partie serveurs mais côté accès en top  
of the rack je ne vois pas du tout hormis des switchs modulaires comment on  
peut faire)
Est ce que l'infra fibre FC san est différente d'une infra fibre lan au  
niveau de la baie?


2/end of row or mid of row
Dans ce cas, on peut vite se trouver en situation d'un cablage complexe si  
la dentité de port par baie augmente? A partir de quand?


hypothèses (non exhaustif) :
- Une baie fait 40U et peut accepter 100-160 ports cuivres et 24 ports  
fibres
- pas de contrainte energie et clim (ces contraites peuvent être discutées  
si vous avez une ou deux remarques la dessus)

- des switchs d'accès 10/100/1000 cuivre et une distrib 10G.

Merci!
Rachid

Re: [FRnOG] Config end of rack Vs top of rack

[Rachid Zitouni]

ça c'est de la reponse de hotline, bravo!
Tu peux me passer le niveau 2 stp?

Le 28 septembre 2009 18:54,   a écrit :
>
> - Original Message - From: 
> To: "Liste FRnoG" 
> Sent: Monday, September 28, 2009 6:34 PM
> Subject: [FRnOG] Config end of rack Vs top of rack
>
>
>> Bonjour!
>>
>> Avez vous déja regardé de près ce qui détermine le choix d'un design DC?
>>
>> Ma compréhension est que deux design sont possibles :
>> 1/ Installation top of rack
>> Dans ce cas les switchs sont installés en haut de la baie
>> Est ce qu'il ya une densité minimum de ports cuivre/fibre à respecter?
>> Quelle type de connectivité (6/6a/7) prévoir avec ses
>> avantages/inconvenients en terme opérationnel et également de cout?
>> Est ce qu'il faut prévoir une connectivité 10G tout de suite? Je ne
>> connais
>> pas du tout l'état de l'art sur la partie serveurs mais côté accès en top
>> of the rack je ne vois pas du tout hormis des switchs modulaires comment
>> on
>> peut faire)
>> Est ce que l'infra fibre FC san est différente d'une infra fibre lan au
>> niveau de la baie?
>>
>> 2/end of row or mid of row
>> Dans ce cas, on peut vite se trouver en situation d'un cablage complexe si
>> la dentité de port par baie augmente? A partir de quand?
>>
>> hypothèses (non exhaustif) :
>> - Une baie fait 40U et peut accepter 100-160 ports cuivres et 24 ports
>> fibres
>> - pas de contrainte energie et clim (ces contraites peuvent être discutées
>> si vous avez une ou deux remarques la dessus)
>> - des switchs d'accès 10/100/1000 cuivre et une distrib 10G.
>>
>> Merci!
>> Rachid
>>
>
> Je pense que vous trouverez vos réponses dans les fiches travaux electricité
> du site de leroymerlin.
>
> Cordialement
>
>
> PS: desole pour la blague mais...
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Switch en stack ou pas?

[Rachid Zitouni]

Hello,
Assez d'accord sur la solution virtuel châssis. Chez cisco il y a la gamme 
nexus 5k avec les modules nexus 2 k qui offre une bonne densité de ports et une 
couverture assez large pour les besoins de connectivité serveurs avec un 
upgrade a chaud possible ( issu) Pour simplifier ta distribution cuivre tu peux 
partir sur une distrib cuivre en top of rack et y placer tes nexus 2k. Pour la 
scalabilite, c'est 500 vlan en mst et 250 en pvst, 480 ports serveurs en lacp 
dans une certaine configuration sinon ce sera du teaming. Cote prix : bien 
remplit (480 ports) un virtuel châssis redonde coûte moins cher que 2 stack de 
la gamme 3750g  et maintenant 3750x. Cote management les deux solutions se 
valent sauf pour la supervision et le monitoring (XML vs snmp). Autre point : 
issu est en roadmap je crois sur la gamme 3750x a vérifier ...

A+
Rachid 

Le 17 mars 2011 à 22:04, "Fregate84"  a écrit :

> Les virtuals chassis c’est pas mal. 2 gros switch indépendant mais vu comme 
> un seul. Comme ca pas de spanning tree, tout en LACP …. Et une bonne 
> redondance. Bon par contre ca coute un peu plus chère que des swich en stack …
> 
>  
> 
> De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de 
> Raymond Caracatamatere
> Envoyé : jeudi 17 mars 2011 21:54
> À : frnog@frnog.org
> Objet : [FRnOG] Switch en stack ou pas?
> 
>  
> 
> Bonjour à tous,
> 
> Je dois réfléchir à une architecture réseau "très haute-disponibilité", et je 
> me pose des questions sur ce qu'il est mieux de faire au niveau des switchs.
> Il est indispensable de double attacher les serveurs pour la redondance 
> (utilisation aussi de bladecenter DELL M1000e), et j'aimerai avoir vos avis 
> sur les stack de switch.
> Avec 2x5 baies, je peux faire 2 stacks de 5 switchs par rangé de baie.
> 
> Les stacks c'est sexy car l'administration est sympa et simplifiée, et 
> surtout on peut utiliser le Pvlan (ou similaire) j'en suis fan et le LACP, 
> par contre les mises à jour de firmware c'est triste quand il faut couper 
> tout le stack ... ou bien quand tout ton stack à un soucis.
> D'après vos expériences, plutôt le stack ou plutôt les switchs seuls ?
> 
> Et le double attachement des serveurs plutôt en spanning-tree (cela me semble 
> très très moche) ou plutôt en teaming ?
> Il existe une solution miracle?
> 
> Si vous avez des idées pour faire balancer mon cœur :)
> 
> Merci beaucoup
> 
> Ray
> 
> 
> 

Re: [FRnOG] Chassis VS stack

[Rachid Zitouni]

Hello,

En fait tu auras certainement besoin des deux ;)

La techno stack (composé de 2 à 5 ou 6 chassis 1 ou 2U)pour la distribution 
cuivre en etage ===> 48 à 240 prises par étage pour une ou deux paires de 
fibres. 
et la techno chassis pour fédérer en fibre ===> chassis 1 ou 2U si tu n'as pas 
beaucoup d'etages sinon chassis modulaire plus ou moins gros.
C'est le modèle généralement mis en oeuvre en "campus".

Chez C, il y a la gamme 2960S (uplinks 1G/10G, acces cuivre 10/100/1000 PoE) 
mais il est limité en stack à 4 membres 
Pour le PoE faut juste faire attention aux consos des postes telephoniques 
(l'interoperabilité avec les switch est à prendre en compte si tu utilises des 
protocoles tels que CDP ou LLDP)

Côté fédé, cela va dépendre du niveau de redondance du fédérateur (simple ou 
double alims, nombres de fibres), du nombre de stack à aggréger, du protocole 
L1/L2 (SPT, Lacp...) de la taille de ta table de routage et dans une moindre 
mesure d'adresse mac, du protocole de routage supporté... 

HiH
Rachid 


Le 22 mars 2011 à 18:44, Youssef Ghorbal a écrit :

> Bonjour,
> 
> Je ne sais pas s'il s'agit du bon endroit pour poser la question
> parce qu'il s'agit d'un envirennement reseau type "campus" et non
> "operateur".
> Je suis entrain d'etudier la possibilite de remplacer les
> commutateurs de quelques batiements du "campus" et j'ai des
> propostions selon deux modeles :
> - Des commutateurs en chassis : le truc habituel, des cartes, alims
> consolidee etc
> - Des stacks 1U : un certain nombre de 1U stacke avec une notion de
> consolidation logicielle pour voir le truc comme un seul gros switch
> 
> Je suis assez familier avec les chassis mais ma seule experience avec
> les stack remonte un peu dans le temps et n'etait pas tres conculante
> (des Nortel de memoire)
> 
> Est ce que vous des retours du terrain sur des solutions en "stack",
> est ce que ca passe a l'echelle correctement (on parle de quelques
> centaines de prises) Quels types de problemes avez vous rencontrez
> dessus.
> 
> Merci de vos retours
> 
> Youssef Ghorbal
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
> 

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

Re: [FRnOG] Re: Chassis VS stack

[Rachid Zitouni]

Le châssis est tout aussi limite a mon sens:
La puissance des alims limite le nombre de port poe de façon plus ou moins 
importante suivant le besoin de puissance du device poe.
Le nombre de carte est également limite.
A mon sens le stack est plus souple de ce point de vue : tu as plus de 
puissance électrique disponible par port poe et d'un point de vue prix, si 
l'évolution du nombre de port est étalée sur plusieurs mois, en tenant compte 
de la durée d'amortissement de ton matériel, il n'est pas évident que le 
châssis soit moins couteux.

Merci
Rachid

Le 23 mars 2011 à 13:18, Sylvain Rutten  a 
écrit :

> Si tu brasses 400 à 800 prises je pense que la meilleur solution est un 
> châssis.
> Cela te coutera moins cher que de faire des stack. De plus une stack n'est 
> pas infini. Chez Cisco tu as une limite de 9 me semble t'il.
> Le fond de panier n'est pas non plus le même.
> Apres tu as un spof sur le châssis au niveau électrique mais les alims sont 
> généralement redondées et si tu fais bien les choses tu redondes aussi ta 
> carte de SUP.
> 
> Donc bon perso sur les locaux technique je prends du châssis 65xx et sur les 
> baies serveurs je stack du 3750.
> 
> -Message d'origine-
> De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de 
> Raphael Mazelier
> Envoyé : mercredi 23 mars 2011 12:36
> À : frnog@FRnOG.org
> Objet : Re: [FRnOG] Re: Chassis VS stack
> 
> Le 23/03/2011 11:55, Youssef Ghorbal a écrit :
>> 
>> Pour recentrer un peu le debat :)
>> Je ne suis pas a la recherche d'une marque ou d'un contrcuteur precis.
>> Ce qui m'interesse c'est de savoir si les gens qui ont mis en place la 
>> techno stack  recemment en sont content (ou pas) quels sont les 
>> avantages, les ecueils qu'ils ont rencontre. Est ce qu'ils ont ete 
>> confronte a des difficultes particulieres et se sont dis a un moment 
>> "avec des chassis on n'aurais pas eu ceci ou cela"
>> 
> La "techno stack" varie d'un constructeur à l'autre. donc c'est un peu 
> logique que l'on te parle de tel ou tel marque.
> D'ailleurs plutôt que stack vs chassis tu  devrais déjà commencer par te 
> poser la question de quel équipementier tu vas choisir et de l'organisation 
> de tes baies de brassage.
> 
> un avantage des stacks c'est par exemple tu peux faire un câblag  très court 
> (10cm) en intercallant un patch panel, un switch, un patch panel, un switch, 
> etc...
> c'est très propre.
> 
> en revanche pour une concentration de 800 ports je penses vraiment qu'il faut 
> commencer a utiliser des chassis, ne serait que pour l'installation de tout 
> les switchs.
> 
>> Le contexte est un contexte Campus, il s'agit de la couche d'acces 
>> avec Giga+PoE a la prise. avec une concentration de type 400 a 800 
>> prises par local technique.
>> 
>> Youssef
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 
> --
> Raphael
> ---
> 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] Re: [FRnOG] Rép : RE: [FRnOG] Re: Chassis VS stack

[Rachid Zitouni]

C'est un peu vrai :
Autant tes manager ne te reprocheront  que rarement le choix du leader.
Autant tous les autres te reprocheront souvent le choix du visionnaire, du 
challenger ou du nouvel entrant.
Le choix n'est donc que peu cornélien.

A+
Rachid



Le 23 mars 2011 à 22:00, Fabien Delmotte a écrit :

> Bonsoir,
> 
>>  ( Enfin Cisco on a beau dire mais c safe comme choix)
> 
> Effectivement si cela ne fonctionne pas on ne peut pas t'en tenir rigueur car 
> tu as pris le numéro 1.
> Cette phrase peut aussi révéler au choix :
>   Un manque de courage
>   Un manque de compétence
>   Un manque de connaissance de la compétition.
> 
> Fabien
> 
> 
> Le 23 mar 2011 à 20:37, Sylvain Rutten  a 
> écrit :
> 
>> Il faut aussi voir que l'avantage du châssis c'est que tu le fais évoluer 
>> plus simplement.
>> Tu changes ta carte de sup plus facilement que tout tes switchs de ta stack. 
>> (Quand tu commences une stack il faut resté dans la même gamme. 
>> 
>> Exemple : Si tu as besoins de faire des upgrades sur tes uplink Giga vers du 
>> 10 g tu remplaces ta carte par exemple même si des Switch 10 G existe aussi.
>> Tu veux faire évoluer ton fond de panier, idem. Tu passes à une carte 
>> supérieur.
>> Bref tu peux faire évoluer ton châssis au fil du temps suivant les besoins 
>> et à chaud pour pas mal de trucs.
>> Ta stack c'est déjà plus compliqué, tu arriveras beaucoup plus vite à un 
>> point de contention sur une stack que sur un châssis. (Pense aussi au CPU et 
>> la mem "On joue pas dans les même gammes)
>> Et c'est là que je ne te comprends pas. Quand tu as un châssis il t'en 
>> coutera moins cher de mettre une carte 48 ports que d'acheter un switch 
>> supplémentaire.
>> En plus les châssis Cisco on fais leurs preuves dans pas mal de boite et tu 
>> ne devrais pas à avoir trop de mal à te sourcé en matériel et pour des prix 
>> qui au final ne serons pas forcement délirant non plus. ( Enfin Cisco on a 
>> beau dire mais c safe comme choix)
>> 
>> Bref pour avoir les deux je préfère le châssis pour le brassage des locaux 
>> technique et la stack pour les baies serveurs.
>> Apres comme le disait Raf tous dépend de la construction de tes baies.
>> 
>> Une question : Ton réseau est destiné à qui au final ? Quel type de campus ?
>> 
>> Voila voila.
>> Apres 
>> 
>> -Message d'origine-
>> De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de 
>> Youssef Ghorbal
>> Envoyé : mercredi 23 mars 2011 18:09
>> À : frnog
>> Objet : Re: [FRnOG] Re: Chassis VS stack
>> 
>> 2011/3/23 Sylvain Rutten :
>> > Oui en plus je pense qu'il a les moyens le monsieur.
>> > VoIp en Giga, veux dire tel en Giga et ça c'est pas pour les pauvres.
>> > Donc bon je pense qu'il peut prendre du châssis 7613  avec des alims de 
>> > 6000W.
>> 
>> Non, le monsieur n'a pas vraiement les moyens. Le probleme est que par 
>> defaut il nous est impossible de prevoire quel sont les prises qui seront 
>> utilises pour les telephones et quels sont qui seront utilisee pour des 
>> postes. Si on commence a s'amuser a categoriser les prises, on n'est pas 
>> sorti de l'auberge. Prevoire des equipements en
>> FastEtehrnet+PoE pour telephones et d'autres en Giga pour les postes
>> n'est pas viable.
>> 
>> Le stack parait seduisant comme approche sur le papier. Ca permet de suivre 
>> de maniere plus fine l'evolution de prises brasses. Rajouter un chassis avec 
>> 1 carte 48 ports pour 10 prises ca fait mal au c**, mais rajouter un 48 
>> ports au stack c'est plus abordable.
>> 
>> Merci a tous pour vos reponses / suggestions. Je retiens le fait que le 
>> stack a pas mal evolue que ca peut etre une solution viable pour la couche 
>> d'acces, qu'il faut faire gaffe aux parametres tel que conso electrique et 
>> disspation en chaleur.
>> 
>> Youssef
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> ---
>> Liste de diffusion du FRnOG
>> http://www.frnog.org/
>> 

Re: [FRnOG] Re: Chassis VS stack

[Rachid Zitouni]

Sur Cisco, tu peux te connecter a tous les autres membres a partir du membre 
Maitre 
Mes 2 cents

Not sent from a crapy blackberry)

Le 28 mars 2011 à 13:05, David Ramahefason  a écrit :

> Dans le cas de vchassis Juniper ou Brocade le tout étant vu comme une seule 
> entité il ne te a qu une seule adresse de management
> 
> Le 28 mars 2011 12:41, "michel hostettler" 
>  a écrit :
> >
> > Bonjour,
> >
> > Une question technique relative aux commutateurs empilables. Un utilisateur 
> > pourrait-il SVP apporter une réponse ?
> >
> > Dans un ensemble de commutateurs empilables pouvez-vous joindre par IP l'un 
> > quelconque des commutateurs, sans que cela soit  le maître ? Par exemple, 
> > peut-on pinguer de manière individuelle les commutateurs ?
> >
> > En fait, nous devrions avoir une adresse IP pour l'ensemble, et une adresse 
> > IP pour chacun des parties. Est-ce le cas ?
> >
> > Cordialement,
> > Michel Hostettler
> >
> >
> > Guillaume ROUSSEAU a écrit :
> >
> >> Bonjour,
> >>
> >> S'il s'agit de concentrer 400 à 800 prises au même endroit et que tu choisi
> >> une solution de stack, il faut que tu fasse attention au fait que dans ce
> >> cas tous tes ports risques de ne pas être full mesher en  wirespeed (a 
> >> cause
> >> du fond de pannier). En plus il y a toujours une limite en terme de 
> >> stacking
> >> sur le nombre d'équipements stackés + si tu fait du shapping de flux les
> >> fonctionnalité ne sont parfois pas supporter en stacking. De mon coté j'ai 
> >> choisi des châssis brocade (pour ne pas les citer) qui
> >> offre en commutation des fonctionnalité sympa et une densité très correcte
> >> pour un prix compétitif par rapport à C :)
> >> Il faut prendre en compte également le niveau de service qui sera inferieur
> >> sur une solution stackée par rapport à une solution châssis + redondée plus
> >> fiable et plus efficace.
> >>
> >> Et éviter HP !
> >>
> >> Guillaume
> >>  
> >
> >
> >
> > ---
> > Liste de diffusion du FRnOG
> > http://www.frnog.org/
> >

[FRnOG] Re: dns blacklist

[Rachid Zitouni]

> Hello guys,
>
> Bouteille a la mer (oui, c'est le moment :-)
>
> Existe t'il une liste officielle pour mettre a jour regulierement une black
> list d'urls du genre update.microsoft.com ?
> N'y voyez aucune allusion, ce n'est qu'un example. Plus generalement, tous
> ces services qui utilisent le reseau public et qui se lancent independemment
> de l'OS et qui tentent des updates, des connexions a des annuaires ...etc..
> sans que l'usager ne fasse explicitement une action.
>
> PS: Pas de confusion, je ne cherche pas de blocklist pour gerer le spam.
>
> Rachid
>

Re: [FRnOG] Question routage /21 inter-pays

[Rachid Zitouni]

3/ (mieux pour votre futur TE :-)

Best
Rachid

Le 14 juillet 2008 15:13, Arnaud de Prelle <[EMAIL PROTECTED]> a écrit :

> Bonjour la liste,
>
> Le RIPE nous a alloué le mois passé un /21 dédié à nos sites de
> Bruxelles et du Luxembourg. Ce /21 est déjà annoncé tel quel depuis
> quelques semaines à nos upstreams (Colt + Verizon) de Bruxelles et sera
> annoncé tel quel à nos upstreams (EPT + Verizon) du Luxembourg dès ce
> mercredi.
>
>
> 4 Assignations ont été effectués dans ce /21:
> 1 /24 par pays (site) pour l'addressage réseau
> 1 /23 par site pour les différents services offerts
>
>
> Le problème est que si nous ne cassons pas ce /21 en les différents
> sous-réseaux définis ci-dessus nous allons faire face à quelques
> problèmes menant à des incohérences de routages.
>
>
> Un exemple parmi d'autres est le suivant:
>
> Nous avons des VPN's avec nos partenaires à Bxl ainsi que des backups de
> chacuns de ces VPN's au Luxembourg.
>
> Ces VPN's (après migration et renumérotation de notre réseau vers des
> IPs du /21) auront des endpoints définis dans ce /21.
>
> Ce qui veut dire qu'en fonction du chemin BGP, chaque VPN (ainsi que son
> backup) sera routés vers un site ou l'autre. Ce que nous ne voulons pas.
> Nous voulons que chaque type de VPN arrive vers son site respectif.
>
>
> La solution contournant le problème pourrait être l'une des suivantes:
>
> 1. Annoncer le /21 sur les deux sites, annoncer des sous-ranges de ce
> /21 sur chaque site et demander à nos upstreams d'aggréger et de router
> en conséquence vers chaque site. Ceci ne sera valable que pour Verizon
> car il est le seul à couvrir les deux sites.
>
> _Avantages_:
> - Transparent pour la table de routage globale. C'est l'upstream qui
> fait tout le travail.
>
> _Désavantages_:
> - Vérizon est le seul à couvrir les deux sites et donc la solution n'est
> pas implémentable.
>
> 2. Annoncer des sous-ranges du /21 sans aggrégation par nos upstreams
> sur chaque site et annoncer globalement le /21 avec une priorité moins
> élevée (prepending, MED, communities, etc).
>
> _Désavantages_:
> -  Etre mal vu de la communauté et risque de se faire filtrer du fait
> d'avoir découpé un /21.
> - Devoir utiliser des paramètres "avancés" de BGP pour contourner le
> problème avec le risque que nos upstreams ne suivent pas ou ne veuille
> pas nous suivre.
>
> 2. Faire des tunnels NxN entre Bruxelles et le Luxembourg sur les
> routeurs d'accès internet et router le traffic en fonction de la
> destination des assignations.
>
> _Avantages_:
> - Super clean vu de l'extérieur car seuls les /21 sont envoyés à nos
> upstreams.
>
> _Désavantages:
> - Création de beaucoup de tunnels, typiquement NxN ou N est le nombre de
> liens que nous avons avec nos upstreams (2 pour chaque upstream: main +
> shadow).
> - Routage statique
> - Gaspillage de bande passante car si un traffic devant arriver au
> Luxembourg arrive d'abord sur Bruxelles du fait d'un chemin optimal
> passant par Bruxelles, il y aura un gaspillage de 2x la bande passante
> requise par le flux sur Bruxelles.
>
> 3. Router le traffic via des liens L2 privés existant entre les deux sites
>
> _Avantages_:
> - Super clean vu de l'extérieur car seuls les /21 sont envoyés à nos
> upstreams.
> - Pas de gaspillage de bande passante internet.
>
> _Désavantages_:
> - Gaspillage de bande passante sur le lien privé.
> - Mix de traffic interne et externe rendant la solution non
> implémentable à cause de contraintes de confidentialité.
> => Possible si on achète de nouveaux liens privés mais augmentation des
> coûts non désirable.
>
> 4. Demander au RIPE de nous échanger ce /21 PA par deux /22 PA
> indépendants et les router chacuns indépendamment à partir de chaque site.
>
> _Désavantages_:
> - /21 est la plus petite allocation PA dans la zone RIPE.
> - Releasing de la range /21 et nouvelles demandes au RIPE (range PI
> /22?) avec risque que cela échoue.
>
>
> Que pensez-vous?
> Qu'auriez-vous implémenté?
> Y-a-t-il d'autres solutions?
>
> Merci d'avance pour vos suggestions, idées, commentaires,
> Arnaud.
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

[FRnOG] coax quality measurement tool

[Rachid Zitouni]

Hello,

Je recherche des infos sur les problematiques de qualite sur des
infrastructures coax installes en general en toplogie etoile pour fournir la
TV par cable.
Est ce qu'il existe un outil particulier qui peut servir de reflectometre
mais aussi permet de faire des tests d'ethernet over coax?
Cela permettrai de reutiliser ces infrastuctures pour fournir des services
IP sur ethernet over coax.
Il existe bien des outils qui jouent des tests sur des interfaces RJ et qui
permettent de valider l'installation des paires de cuivres.
Y aurait il selon vous la meme chose mais plus sur la partie coax ?

Merci d'avance,
Rachid

Re: [FRnOG] Filtrage d'URL via BGP shunt : quelle faisabilité ? (+ présentation)

[Rachid Zitouni]

Je ne comprends pas tres bien ou est le debat.
La demande de l'etat fait sens pour limiter au maximum ce business macabre.
Par ailleurs, pour la faisabilite, la question n'est pas qui doit pousser ce
controle mais comment.
Et, en ca, la reponse vient de l'etat : il vont maintenir et fournir une
liste noire
Apres, je ne vois pas ou est le probleme de filter cette liste pour les
operateurs ?
Pour l'etat, facile ensuite de verifier que la politique a ete ou non
appliquee

PS : Et puis pour ceux qui s'offusquent, la liberte s'est toujours arrete
pour les uns la ou a commence celle des autres.


A+

Le 28 juillet 2008 22:06, Radu-Adrian Feurdean<[EMAIL PROTECTED]> a écrit :

>
> On Mon, 28 Jul 2008 18:15:57 +0200, [EMAIL PROTECTED] said:
>
> > Je pense qu'il y a confusion entre contrôle parental (où l'activation est
> > optionnel) et filtrage obligatoire (imposé par la loi).
> >
> > Dans l'esprit des initiateurs du projet, le filtrage des contenus
> > pédopornographiques n'est pas là pour être soumis au bon vouloir de
> > l'utilisateur, fut-il majeur. Ce filtrage ne doit pas pouvoir être
> > désactivé comme peut l'être le contrôle parental. Or je ne connais
> > pas d'OS qui filtre en standard des contenus sans que ce filtrage
> > puisse être désactivé.
>
> Si l'etat se mele dans ce genre de choses (et malhereusement il le
> fait), le probleme qu'il faut se poser n'est plus "comment faire" (ce
> que l'etat demande), mais "a-t-il le droit de demander ca" ? Je dirai
> que le reponse est "NON", mais etant donne ce que les francais (la
> plupart d'entre eux) pensent,
> il semblerait que j'ai pas raison.
>
> > Il faudrait donc que la France impose aux auteurs et éditeurs de systèmes
> > d'exploitation de mettre en oeuvre des spécifications techniques de
> > filtrage et interdisent aux utilisateurs de les désactiver sur le
> territoire
> > français sous peine de poursuites. Et comme dans ce bas monde on ne peut
> se fier à
> > personne, il faudrait aussi traiter root comme un attaquant potentiel.
>
> La Chine, la Birmanie, la Coree du Nord, ils demandent aussi aux gens de
> faire des choses "bien" (d'apres eux).
>
> Quand "La France" (ou tout autre pays) "demande", c'est qu'il faut fuir
> ce pays pire que la peste.
>
> En plus, dire que "imposer un filtrage (des contenus pedophiles) c'est
> bien" em meme temps que dire "mais pas comme ca, un peu plus soft",
> c'est de la pure  inconscience. Si on se croit encore dans "le pays de
> la liberte et des drois de l'homme", faut accepter la liberte d'opinion
> et la liberte de la presse, et pour faire propre, ca va tres loin.
>
> [quelques autres commentaires sur la France auto-censures]
>
> Si implementer une filtration est la necessite absolue, meme en mepris
> du bon-sens, il faudra probablement aborder une strategie differente: au
> lieu de combattre le gouvernement dans ses essais de faire du n'importe
> quoi, l'aider, lui sugerer les solutions les plus debiles possible, et
> evidamment celles qui causent le plus de degats au niveau des
> utilisateurs. La correction me manquera pas d'arriver d'un facon ou
> autre.
>
> Et probablement qu'un jour le francais vont comprendre (eux aussi) que
> l'etat n'a pas "a demander". RIEN. JAMAIS.
>
>
> --
> Radu-Adrian Feurdean
>  raf (a) ftml ! net
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

Re: [FRnOG] Installation en datacenter

[Rachid Zitouni]

Si tu prevois une evolution rapide, prevois des etages d'acces, distribution
si besoin, d'aggreg et routage (multiplie par 2 ces 2 derniers si
redondance)
switch d'acces,distribution au cas ou : cisco 2xxx (2960 par ex.) ou hp
managed 2xxx (28xx)
switch d'aggreg niveau 2 only : idem voir cisco 35xx, 3750 ou hp35xx
pour ton uplink niveau 3 : tout depend de ta volumetrie : avec un 72xx, tu
verras venir :-)

Un dernier pour la route, evite d'avoir plus d'1 source pour tes switch, ca
t'evitera des noeuds au cerveau si tu veux faire un peu de redondance,.
HiH
Rachid


Le 28 juillet 2008 23:50, Thomas Andrieu<[EMAIL PROTECTED]> a
écrit :

> Bonjour tout le monde,
>
> Dans le mois qui suit on va déplacer nos serveurs dans une baie sur
> globalswitch. Pour le moment on n'a bossé que sur de gros réseaux avec des
> équipements lourds à base Cisco Catalyst, ou de Juniper,  on en arrive à
> avoir de moins en moins d'idées concernant les besoins en
> commutation/routage pour une petite infra.
>
> Sachant qu'on va déployer dans un premier temps 10 machines, que l'on va
> avoir notre propre AS et qu'on prévoit une augmentation assez rapide du
> nombre de machines, qu'est ce que vous recommanderiez comme équipements
> réseaux ?
> On est revendeur 3com, hp, cisco, juniper et nortel au niveau équipements
> réseaux, donc il y a le choix :)
>
> Merci d'avance pour vos réponses,
>
> Thomas Andrieu---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

Re: [FRnOG] coax quality measurement tool

[Rachid Zitouni]

>le catalogue Farnell contient un certain nombre d'appareils chez Fluke
>qui semblent pouvoir convenir.

Merci pour l'info Raphael,
J'ai effectivement repere un appareil assez complet chez fluke, le DTX 1800,
mais pas donne :-(

Pour la qualite, j'ai pense que si le coax existant permet d'afficher une
qualite de la CATV suffisamment bonne a l'oeil, alors on peut utiliser sans
risque les gammes de frequences inferieures (dc moins sujettes aux bruits et
a l'attenuation) pour faire passer la data sans risque, non ?

Les cablos sont en vacances, ou peut etre quelqu'un connait il une liste
pour poster sur ce sujet ?


Thx
Rachid

Le 21 juillet 2008 15:31, Raphaël Jacquot<[EMAIL PROTECTED]> a écrit :

> On Mon, 2008-07-21 at 15:25 +0200, Rachid Zitouni wrote:
> > Hello,
> >
> > Je recherche des infos sur les problematiques de qualite sur des
> > infrastructures coax installes en general en toplogie etoile pour
> > fournir la TV par cable.
> > Est ce qu'il existe un outil particulier qui peut servir de
> > reflectometre mais aussi permet de faire des tests d'ethernet over
> > coax?
> > Cela permettrai de reutiliser ces infrastuctures pour fournir des
> > services IP sur ethernet over coax.
> > Il existe bien des outils qui jouent des tests sur des interfaces RJ
> > et qui permettent de valider l'installation des paires de cuivres.
> > Y aurait il selon vous la meme chose mais plus sur la partie coax ?
> >
> > Merci d'avance,
> > Rachid
> >
> >
>
> le catalogue Farnell contient un certain nombre d'appareils chez Fluke
> qui semblent pouvoir convenir.
>
>

Re: [FRnOG] Les mystères de l'OSPF

[Rachid Zitouni]

http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml

HiH

Le 18 août 2008 18:24, Raymond Caracatamatere <
[EMAIL PROTECTED]> a écrit :

> Bonjour,
>
> Je viens de nouveau vers vous afin de connaitre votre avis sur un problème
> actuel que je rencontre avec le protocole OSPF.
>
> J'ai plusieurs équipements (CISCO ASA, LINUX QUAGGA ...) qui utilisent le
> protocole de routage dynamique OSPF, j'aimerais, sur le dernier Linux Quagga
> que j'incorpore à cette infrastructure, filtrer les routes que le Quagga
> reçoit du Cisco ASA, j'ai bien tenté les commandes sur le Quagga :
>
> area 0.0.0.0 import-list FILTRE-OSPF
> area 0.0.0.0 filter-list prefix FILTRE-OSPF in
>
> ou encore de créer une seconde zone pour la session OSPF entre ces deux
> équipements et appliquer un filtre sur le Cisco ASA :
>
> area 0.0.0.1 filter-list prefix FILTRE-OSPF in
>
> Je crois bien avoir essayé toutes les combinaisons possible, mais rien à
> faire le quagga recoit toujours toutes les routes du Cisco ASA (ce que je ne
> souhaite pas).
> Ai-je oublié une chose ou bien n'est-ce pas la bonne méthode pour filtrer ?
>
> Merci de vos lumières en tout cas !
>
> RAY
>
>

Re: [FRnOG] Les mystères de l'OSPF

[Rachid Zitouni]

Oui,
Pour resumer tres rapidement, je vois 2 possibilites :  ou on s'en
sort avec des aires avec des proprietes specifiques, la nssa no
summary permet de n'injecter qu une route pqr defaut et n'injecte dans
le backbone que certains lsa de l'aire nssa; ou bien on definit des
process differents (ospf ou autre) et on peut filtrer sur les
redistributions.

HiH


Le 18/08/08, David Wilde<[EMAIL PROTECTED]> a écrit :
> La phrase la plus pertinente de cette page web :
> "Filtering information with link-state protocols such as OSPF is a
> tricky business."
>
> :-)
>
> C'est parce que chacun des routeurs configuré avec OSPF construit
> d'abord une topologie du réseau entière : cette topologie devrait être
> identique sur tous les routeurs.  Ensuite les routeurs calculent les
> meilleurs chemins à partir de cette topologie.  Ce n'est pas comme RIP,
> par exemple, ou chaque routeur fait son choix à lui, sans savoir ce que
> font ses voisins.
>
> Bien sûr si quelques routeurs OSPF ont une vue différente des autres, il
> y aura un impact sur les chemins choisis (et éventuellement dans le pire
> des cas il pourrait y avoir des boucles ou des destinations qui ne sont
> plus joignable).
>
> Regards,
> David
>
>
> Rachid Zitouni a écrit :
>> http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094e9e.shtml
>>
>> HiH
>>
>> Le 18 août 2008 18:24, Raymond Caracatamatere
>> <[EMAIL PROTECTED]
>> <mailto:[EMAIL PROTECTED]>> a écrit :
>>
>> Bonjour,
>>
>> Je viens de nouveau vers vous afin de connaitre votre avis sur un
>> problème actuel que je rencontre avec le protocole OSPF.
>>
>> J'ai plusieurs équipements (CISCO ASA, LINUX QUAGGA ...) qui
>> utilisent le protocole de routage dynamique OSPF, j'aimerais, sur
>> le dernier Linux Quagga que j'incorpore à cette infrastructure,
>> filtrer les routes que le Quagga reçoit du Cisco ASA, j'ai bien
>> tenté les commandes sur le Quagga :
>>
>> area 0.0.0.0 <http://0.0.0.0> import-list FILTRE-OSPF
>> area 0.0.0.0 <http://0.0.0.0> filter-list prefix FILTRE-OSPF in
>>
>> ou encore de créer une seconde zone pour la session OSPF entre ces
>> deux équipements et appliquer un filtre sur le Cisco ASA :
>>
>> area 0.0.0.1 <http://0.0.0.1> filter-list prefix FILTRE-OSPF in
>>
>> Je crois bien avoir essayé toutes les combinaisons possible, mais
>> rien à faire le quagga recoit toujours toutes les routes du Cisco
>> ASA (ce que je ne souhaite pas).
>> Ai-je oublié une chose ou bien n'est-ce pas la bonne méthode pour
>> filtrer ?
>>
>> Merci de vos lumières en tout cas !
>>
>> RAY
>>
>>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] 900 jours avant la pénurie d'adresses IP V4 ?

[Rachid Zitouni]

A quand le cours d'indice ipv4 sur second life :-?

2008/8/25 Pierre Col | UbicMedia <[EMAIL PROTECTED]>

> Selon le JDNet - lire
> http://www.journaldunet.com/solutions/systemes-reseaux/actualite/900-jours-avant-la-penurie-d-adresses-ip.shtml-
>  "Le compte-à-rebours est lancé : d'ici 3 à 5 ans, les adresses IPv4 seront
> l'or numérique de l'Internet. La solution, l'adoption rapide d'IPv6.
> Toutefois, seulement 0,002% du trafic actuel passe par cette norme."
>
> Info ou intox ?
>
>
> --
> Pierre Col - Directeur Marketing et Business Développement
> [EMAIL PROTECTED]  - 04 78 54 29
> 08 - 06 11 78 29 01
> *UbicMedia* - 9 rue des Tuiliers - 69003 LYON - www.ubicmedia.com <
> http://www.ubicmedia.com/fr/> - www.pumit.com <
> http://www.pumit.com/?locale=fr>   <
> http://exemple.pumit.com/?locale=fr>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Re: [FRnOG] Conservation des logs, ou en est on réellement ?

[Rachid Zitouni]

>En tout état de cause un cyber-café, mais aussi un Starbuck Coffee ou une
municipalité mettant un accès wifi mis à disposition devrait >conserver
trace de l'identité de ses utilisateurs et être en mesure de dire à tout
moment lequel d'entre eux était derrière telle adresse >IP. Ceux qui ne le
font pas prennent de gros risques.

Un acces internet sur un reseau wireless ouvert ne permet jamais de savoir
qui se trouve derriere telle ou telle ip :-)
A commencer par les particuliers qui laissent leurs acces ouverts :
http://www.schneier.com/blog/archives/2008/08/terrorists_usin.html



Le 25 août 2008 16:53, Pierre Col | UbicMedia <[EMAIL PROTECTED]> a
écrit :

> Ronnie Garcia a écrit :
>
>> Un proxy *web*. L'Internet n'est il fait que de pages HTML ? ;)
>>
>
> Des délits peuvent être commis via le web, mais aussi par mail ou sur les
> newsgroups Usenet... Pour Archie et Gopher, on peut laisser tomber je pense
> :-)
>
> En tout état de cause un cyber-café, mais aussi un Starbuck Coffee ou une
> municipalité mettant un accès wifi mis à disposition devrait conserver trace
> de l'identité de ses utilisateurs et être en mesure de dire à tout moment
> lequel d'entre eux était derrière telle adresse IP. Ceux qui ne le font pas
> prennent de gros risques.
>
> --
> Pierre Col - Directeur Marketing et Business Développement
> [EMAIL PROTECTED]  - 04 78 54 29
> 08 - 06 11 78 29 01
> *UbicMedia* - 9 rue des Tuiliers - 69003 LYON - www.ubicmedia.com <
> http://www.ubicmedia.com/fr/> - www.pumit.com <
> http://www.pumit.com/?locale=fr>   <
> http://exemple.pumit.com/?locale=fr>
>
>
> ---
> Liste de diffusion du FRnOG
> http://www.frnog.org/
>
>

Re: [FRnOG] Choix technologique IPoA vs PPPoA

[Rachid Zitouni]

Hello,

La QoS avance (autre que SPQ) peut faire pencher la balance en faveur de
l'ipoa.
Cela peut devenir tres complique sur pppoa/oe/oaoe ...
La VoIP peut egalement pencher la balance en faveur de l'ipoa
La gestion du nombre de com supportes peut tres vite devenir un casse tete
...
L'aspect operationnel (provisionning) est clairement en faveur de ppp sauf
peut etre pour la partie post provisionning (snmp, troubleshooting et
maintenance dans le temps)
Ma cl : pppoX pour les soho et residentiel sans qos avancee avec max une com
voip et ipoX pour les services avances.
L'autre inconvenient : ppp n'est pas gere de la meme facon par tous les
vendeurs :-)

HiH
Rachid



Le 3 octobre 2008 16:28, daren crew <[EMAIL PROTECTED]> a écrit :

> Bonjour à tous,
>
> Quelqu'un aurait-il des informations qui pourraient faire pencher la
> balance entre IPoA et PPPoA/E, surtout dans les supports de type SHDSL...
>
> Avec le PPP, il est vrai que l'administration est on ne peut plus aisée...
> il suffit d'un RADIUS bien provisionné, et le tour est joué... c'est,
> semble-t-il, bien pour cela que nos amis opérateurs ont abandonné le
> reste...
>
> Mais qui dit session dit rupture possible, mauvais comportement de
> l'équipement de terminaison qui, par exemple, ne retente pas forcément de se
> connecter en cas de rupture (même en mode always on), MTU (pour le pppoe) et
> j'en passe.
>
> Avec l'IPoA, pas de session, donc pas les problèmes mentionnés
> précédemment, mais pas non plus d'authentification et donc pas de véritable
> contrôle simple du traffic et tout, ou presque est configuré de manière
> statique... donc en facilité de gestion, il y a mieux...
>
> Alors comment se décider... Dans le cas de particuliers, il reboot de temps
> en temps n'est pas forcément gênant, mais dans le monde des entreprises (et
> de la VoIP) ce n'est pas forcément ce qu'il y a de mieux. Et d'ailleurs,
> chez Nerim, comme chez Colt, à ma connaissance, pour leurs SDSL, ils
> n'utilisent pas de PPP mais pourquoi...
>
>
> J'ai tout d'abord pensé, outre les problèmes bien connus du PPP, aux
> performances...
> L'encapsulation ? Ce ne sont pas quelques octets de plus qui constituent
> une différence transcendante... ni même le temps de traitement, on a dépassé
> ce stade depuis des décénnies ;) la fragmentation liée à la MTU (en
> pppoe)... les routeurs modernes font avec...
>
> Alors quoi? Si quelqu'un en sait plus je suis preuneur
>
> Merci d'avance pour votre aide !
>
> Daren
>
> --
> Téléchargez le nouveau Windows Live Messenger ! Téléchargez Messenger,
> c'est gratuit ! 
>

Re: [FRnOG] Tunnel VPN / relier deux reseaux via internet

[Rachid Zitouni]

Solution low cost a creuser :
Un Tunnel ip/ip entre tes deux routeurs avec routage specifique de
petits blocs sur ces routeur pour router ces blocs au travers du
tunnel, avec proxy arp active sur le(s) interfaces lan de ces
routeurs.

Sinon pour etre tranquille : offres de vpn ethernet dispos chez tous
les bons carrier ;-)

HiH
Rachid


Le 09/10/08, Tobias Muller<[EMAIL PROTECTED]> a écrit :
> Bonjour,
>
> Nous sommes a la recherche d'une solution permettant de relier
> temporairement deux reseaux utilisant les memes ip publiques (hébergement
> internet) mais sur des sites physiques différents.
>
> J'ai d'un coté, un routeur qui annonce en BGP deux PI /24.
> De l'autre coté, un autre routeur qui annonce aussi en BGP un autre PI /23.
>
> Ces deux routeurs sont dans des datacenters différents et connectés a deux
> opérateurs
> différents.
>
> Nous allons abandonner le datacenter dans lequel nous avons les deux PI
> annoncés.
> Pour pouvoir migrer en douceur et surtout sans avoir a bouger tous les
> serveurs d'un seul coup, nous voulons pouvoir debrancher X machines du DC1
> et les
> rebrancher dans le DC2, tout en gardant les memes ip publiques pour les
> serveurs.
> D'autres machines peuvent rester dans DC1 en utilisant la meme classe au
> meme moment
> pendant ce temps.
>
> L'idée serait de faire un genre pont temporaire entre les deux reseaux le
> temps de bouger les serveurs. Une fois terminé, il n'y aura alors plus qu'un
> seul routeur qui annoncera directement les 3 PI.
>
> Autre contrainte, nous ne pouvons pas modifier la config IP des machines que
> nous bougeons, meme temporairement.
>
> J'avoue ne pas etre forcement clair !
>
> En gros :
>
> Routeur BGP 1
> Routeur BGP 1
>
> |
> |
> -
> --
>
> |
> |
>  Switch DC 1   VPN ?
> Switch DC 2
> (195.100.100.0/24)<->  (
> 195.100.100.0/24)
>
> |
> |
> --
> --
>
> Serveurs
> Serveurs
>
>
> Quelqu'un connait-il une solution permettant de faire cela ?
>
> Merci d'avance pour votre aide.
>
> Tobias MULLER
>
---
Liste de diffusion du FRnOG
http://www.frnog.org/

Re: [FRnOG] Choix technologique IPoA vs PPPoA

[Rachid Zitouni]

RAD c'est pour faire plus que du bi paires, l'offre 8M sdsl avec un trunking
atm sur le dslam et sur le cpe, non ?
dans tous les cas, si ils te mettent un RAD pour ce type de besoin, alors tu
vas peut etre devoir gerer des encapsulations differentes entre ton cpe et
ton routeur edge.
A propos, tu ne dis pas si ta livraison cote edge est atm ?
Dans ce cas, si tu fais du pppoe cote cpe, tu devras faire du pppoeoa cote
edge
Si tu fais de l'ipoe cote cpe, tu devras faires de l'ipoeoa cote edge.
Je dois dire que ppp ou ipox dans ce cas n'est pas la vraie question mais
plutot, est ce que tu t'accomoderas d'encap differentes aux deux extremites
( je me souviens d'une offre turbo dsl de ft avec une interface ethernet 10
half cote cpe et un pvc cote pe :-) ?
Oui, parce que le but d'une offre sdsl est bien d'offrir un debit
symetrique. Or, avec des encap differentes des deux cotes, le resultat est
que ton cpe ou ton router edge verront un debit different :-) Et si tu veux
faire de la QoS avancee, du reporting et tout ce qui s'en suit : ce sera un
bon exercice mais il y a plus simple entre nous.
Pour resumer tres vite :
Dans ton cas, je verifierais d'abord si on a une encap identique de chaque
cote puis dans un second temps, ppp ou ipox ...

HiH
Rachid




Le 13 octobre 2008 16:31, daren crew <[EMAIL PROTECTED]> a écrit :

> Merci à tous pour toutes ces bonne infos, surtout pour vos retour au niveau
> performances. Concernant l'acct et l'interfaçage RADIUS/DHCP, j'avais déjà
> pu mettre les doigts dans le camboui, et ça marchait plutôt bien.
>
> Le seul hic dans tout ça, sauf erreur de ma part, c'est que l'option 82
> n'est valable que si on maîtrise les liaisons de bout à bout (notamment
> DSLAM), mais ça n'est, à priori, pas disponible sur de la collecte FT, je me
> trompe?
>
> J'ai été très étonné de me voir fournir par FT un RAD (moi qui m'attendais
> à une arrivée brute ATM, et donc à pouvoir faire tout, ou presque, ce que je
> veux).
> J'avoue que je m'inquiète un peu car, le RAD ayant une terminaison ethernet
> et étant géré par FT, si je devais malgré tout utiliser du PPP, d'être
> contraint à utiliser du pppoe (et donc MTU réduite), à moins que le RAD gère
> la conversion...
> De plus, je ne sais pas si l'IPoA reste aussi interessant quand on ne
> maîtrise pas le circuit de A à Z.
>
> Quelqu'un a-t-il un retour sur la collecte SDSL FT sur RAD? Que pensez-vous
> de tout ça?
>
>
>
> --
> Date: Sun, 12 Oct 2008 13:47:16 +0200
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [FRnOG] Choix technologique IPoA vs PPPoA
> CC: frnog@frnog.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>
>
> Bien entendu que la liaison dhcp vers radius est possible, seulement c'est
> de notion de session qu'il est question. Pour avoir une info de début de
> session en dhcp, il suffit d'avoir un parser de log afin d'avoir ces
> informations. Le point négatif du DHCP est qu'il n'y a pas d'ACCT STOP.
>
> Le point que j'ai soulevé dans le mail ne concerne en aucun cas
> l'authentification choisie mais les informations sur un utilisateur à
> l'instant T.
>
>
> Le 10 octobre 2008 20:27, <[EMAIL PROTECTED]> a écrit :
>
>
> Je ne suis pas entièrement d'accord, on peut coupler la notion DHCP et
> RADIUS. Certains équipements (routeurs multi-services comme le 7750
> d'ALCATEL ou CISCO ou JUNIPER, ...) permettent de bloquer certaines requêtes
> DHCP et d'effectuer une requête radius et de les libérer, ou alors de faire
> une requête d'accounting dès qu'ils voyent passer ces requêtes. On peut
> alors bénéficier de l'authentification radius, basée sur des éléments du
> type MAC, OPTION82, ... et avoir des informations de début de session réel
> (lors du DHCP ACK renvoyé par le client quand il obtient une IP par
> exemple). Par contre la fin de session peut selon les équipements être
> aléatoire (en fonction de la durée des lease DHCP).
>
>
> Sinon de manière plus générale
> Jérôme HIEZELY
> [EMAIL PROTECTED]
>
> [EMAIL PROTECTED] a écrit sur 08/10/2008 14:49:43 :
>
> > Le retour du combat de l'IPoX vs PPPoX.
> >
> > PPPoX :
> >
> > * L'avantage de ce protocole est qu'il est lié à Radius, donc on a
> > un nombre important d'informations sur l'utilisateur à l'instant T :
> > On sait (si on a un accounting cohérent et un système de requêtage
> > intelligent) si un client est connecté, le moment de sa dernière
> > coupure (que ce soit à l'initiative de l'abonné ou celle de
> > l'équipement de collecte). On peut faire des stats de trafic sur les
> > tickets d'acct stop, dégager des comportements utilisateurs etc...
> >
> > * La gestion de déménagement d'abonné n'implique pas de changer des
> > informations d'authentification : dans le cas du ppp, il s'agit du
> > login qui fera foi, tandis qu'en DHCP, ce sera l'option 82 qui est
> > lié à l'interface physique du DSLAM, OLT, ou autre qui fera foi.
> > Donc en cas de déménagement, il faut aussi prendre en compte la
> > nouvelle option 82. En cas de déplacement de po

Re: [FRnOG] Choix technologique IPoA vs PPPoA

[Rachid Zitouni]

Dans tous les cas, si c'est pour creer une offre pour tes clients
entreprises, priveligies des encaps identiques de chaque cote.
Apres privelegies ipoX (dhcp ou static) a pppoX pour faire evoluer ton
service :-)

Le reste depend de tes propres equipements que tu auras a chaque extremite.


HiH
Rachid


Le 13 octobre 2008 18:17, daren crew <[EMAIL PROTECTED]> a écrit :

> Le truc c'est que la porte n'est pas encore livrée... et que j'essaye de
> référencer l'ensemble des possibilités.
>
> Le seul truc que je sais c'est qu'au niveau de la porte ils fournissent un
> RAD
> http://www.rad-france.fr/Article/0,6583,33987-Unite_terminaison_reseau_multiservice,00.html
>
> J'ai cru comprendre que FT nous offrait deux possibilités : livrer
> directement leurs CPE sur place qui feraient de l'ethernet soit
> terminaison classique modem de notre choix.
>
> Voilà le topo
>
>
>
> --
> Date: Mon, 13 Oct 2008 17:46:20 +0200
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
>
> Subject: Re: [FRnOG] Choix technologique IPoA vs PPPoA
> CC: frnog@frnog.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>
> RAD c'est pour faire plus que du bi paires, l'offre 8M sdsl avec un
> trunking atm sur le dslam et sur le cpe, non ?
> dans tous les cas, si ils te mettent un RAD pour ce type de besoin, alors
> tu vas peut etre devoir gerer des encapsulations differentes entre ton cpe
> et ton routeur edge.
> A propos, tu ne dis pas si ta livraison cote edge est atm ?
> Dans ce cas, si tu fais du pppoe cote cpe, tu devras faire du pppoeoa cote
> edge
> Si tu fais de l'ipoe cote cpe, tu devras faires de l'ipoeoa cote edge.
> Je dois dire que ppp ou ipox dans ce cas n'est pas la vraie question mais
> plutot, est ce que tu t'accomoderas d'encap differentes aux deux extremites
> ( je me souviens d'une offre turbo dsl de ft avec une interface ethernet 10
> half cote cpe et un pvc cote pe :-) ?
> Oui, parce que le but d'une offre sdsl est bien d'offrir un debit
> symetrique. Or, avec des encap differentes des deux cotes, le resultat est
> que ton cpe ou ton router edge verront un debit different :-) Et si tu veux
> faire de la QoS avancee, du reporting et tout ce qui s'en suit : ce sera un
> bon exercice mais il y a plus simple entre nous.
> Pour resumer tres vite :
> Dans ton cas, je verifierais d'abord si on a une encap identique de chaque
> cote puis dans un second temps, ppp ou ipox ...
>
> HiH
> Rachid
>
>
>
>
> Le 13 octobre 2008 16:31, daren crew <[EMAIL PROTECTED]> a écrit :
>
> Merci à tous pour toutes ces bonne infos, surtout pour vos retour au niveau
> performances. Concernant l'acct et l'interfaçage RADIUS/DHCP, j'avais déjà
> pu mettre les doigts dans le camboui, et ça marchait plutôt bien.
>
> Le seul hic dans tout ça, sauf erreur de ma part, c'est que l'option 82
> n'est valable que si on maîtrise les liaisons de bout à bout (notamment
> DSLAM), mais ça n'est, à priori, pas disponible sur de la collecte FT, je me
> trompe?
>
> J'ai été très étonné de me voir fournir par FT un RAD (moi qui m'attendais
> à une arrivée brute ATM, et donc à pouvoir faire tout, ou presque, ce que je
> veux).
> J'avoue que je m'inquiète un peu car, le RAD ayant une terminaison ethernet
> et étant géré par FT, si je devais malgré tout utiliser du PPP, d'être
> contraint à utiliser du pppoe (et donc MTU réduite), à moins que le RAD gère
> la conversion...
> De plus, je ne sais pas si l'IPoA reste aussi interessant quand on ne
> maîtrise pas le circuit de A à Z.
>
> Quelqu'un a-t-il un retour sur la collecte SDSL FT sur RAD? Que pensez-vous
> de tout ça?
>
>
>
> --
> Date: Sun, 12 Oct 2008 13:47:16 +0200
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: Re: [FRnOG] Choix technologique IPoA vs PPPoA
> CC: frnog@frnog.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>
>
> Bien entendu que la liaison dhcp vers radius est possible, seulement c'est
> de notion de session qu'il est question. Pour avoir une info de début de
> session en dhcp, il suffit d'avoir un parser de log afin d'avoir ces
> informations. Le point négatif du DHCP est qu'il n'y a pas d'ACCT STOP.
>
> Le point que j'ai soulevé dans le mail ne concerne en aucun cas
> l'authentification choisie mais les informations sur un utilisateur à
> l'instant T.
>
>
> Le 10 octobre 2008 20:27, <[EMAIL PROTECTED]> a écrit :
>
>
> Je ne suis pas entièrement d'accord, on peut coupler la notion DHCP et
> RADIUS. Certains équipements (routeurs multi-services comme le 7750
> d'ALCATEL ou CISCO ou JUNIPER, ...) permettent de bloquer certaines requêtes
> DHCP et d'effectuer une requête radius et de les libérer, ou alors de faire
> une requête d'accounting dès qu'ils voyent passer ces requêtes. On peut
> alors bénéficier de l'authentification radius, basée sur des éléments du
> type MAC, OPTION82, ... et avoir des informations de début de session réel
> (lors du DHCP ACK renvoyé par le client quand il obtient une IP par
> exemple). Par contre la fin de session peu