Re: [FRnOG] Re: Chassis VS stack
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 r...@netfacile.net 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 michel.hostett...@telecom-paristech.fr 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/
Re: [FRnOG] Re: Chassis VS stack
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 sylvain.rut...@rueducommerce.com 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
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 sylvain.rut...@rueducommerce.com 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 sylvain.rut...@rueducommerce.com: 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] Chassis VS stack
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] Switch en stack ou pas?
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 fregat...@free.fr 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
[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
Re: [FRnOG] Config end of rack Vs top of rack
ça c'est de la reponse de hotline, bravo! Tu peux me passer le niveau 2 stp? Le 28 septembre 2009 18:54, supp...@skiwebcenter.fr a écrit : - Original Message - From: rachid.zito...@gmail.com To: Liste FRnoG frnog@frnog.org 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] Erreur BGP !
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-zahrbengelloun_z...@hotmail.com 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/
Re: [FRnOG] Service IPTV en France
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 lmod...@hotmail.com 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] Parlons d'IPv6
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 ced...@systemac.homelinux.org 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] Meilleurs solution technique = Backbone Internet dans MPLS
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 v...@zoreil.com 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] Meilleurs solution technique = Backbone Internet dans MPLS
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 o.calv...@gmail.com: 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] Configuration ATM Cisco sur DSLE France Telecom
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 Bouazizrap...@noemie.org 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
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.netci...@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] Choix technologique IPoA vs PPPoA
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 port etc... la gestion via PPP est beaucoup plus flexible. * Le tunneling L2TP qui permet de très
Re: [FRnOG] Choix technologique IPoA vs PPPoA
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 peut selon les équipements être aléatoire (en fonction de la durée des lease DHCP). Sinon de manière plus
Re: [FRnOG] Tunnel VPN / relier deux reseaux via internet
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] 900 jours avant la pénurie d'adresses IP V4 ?
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] mailto:[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 ?
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] mailto:[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] Les mystères de l'OSPF
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] coax quality measurement tool
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] Filtrage d'URL via BGP shunt : quelle faisabilité ? (+ présentation)
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] Question routage /21 inter-pays
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] Re: dns blacklist
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
