Re: [FRnOG] Moderation de la liste
phx a écrit : Bonjour, desole mais c'est quoi BBS et RTC ? Desole on doit aussi etre pas mal de jeunes :D Salut, Le BBS : bulletin board system. En gros c'est un panel de services comme l'était le minitel mais plus souvent géré par des particuliers (et oui pas besoin de payer de folles redevances à France Telecom). Pour se connecter au BBS il suffisait de composer le numéro de téléphone et l'on avait accès à un espace de téléchargement, un forum de discussion et éventuellement une boite de messagerie. Donc un espèce de minitel (l'utilisateur appel un service) mais avec l'esprit ouvert d'internet (le service n'était généralement pas facturé) ou des radio-amateurs (beaucoup de geek et d'amateurs de nouvelles technologies). Pour le RTC : Réseau Téléphonique Commuté. C'est l'acronyme courrament utilisé pour désigner le réseau de téléphone. Les abonnés sont liés via une paire de cuivre à central, et les centrals connectés entre eux. Il y a quelque temps, la commutation était réalisée par des opérateurs humains, on demandait par exemple le 22 à Asnière. Bien sur avec le temps, tout çà est devenu numérique et on entre en relation en quelques centaines de milisecondes. cheers, -- Antoine MUSSO DISIT/PROD/QFO/OUT mailto:[EMAIL PROTECTED] tél. 02 40 12 73 62 Post-scriptum La Poste Ce message est confidentiel. Sous réserve de tout accord conclu par écrit entre vous et La Poste, son contenu ne représente en aucun cas un engagement de la part de La Poste. Toute publication, utilisation ou diffusion, même partielle, doit être autorisée préalablement. Si vous n'êtes pas destinataire de ce message, merci d'en avertir immédiatement l'expéditeur.
Re: [FRnOG] Moderation de la liste
At 09:59 13/11/2007, Antoine Musso wrote: phx a écrit : Bonjour, desole mais c'est quoi BBS et RTC ? Desole on doit aussi etre pas mal de jeunes :D Salut, Le BBS : bulletin board system. En gros c'est un panel de services comme l'était le minitel mais plus souvent géré par des particuliers (et oui pas besoin de payer de folles redevances à France Telecom). Pour se connecter au BBS il suffisait de composer le numéro de téléphone et l'on avait accès à un espace de téléchargement, un forum de discussion et éventuellement une boite de messagerie. Donc un espèce de minitel (l'utilisateur appel un service) mais avec l'esprit ouvert d'internet (le service n'était généralement pas facturé) ou des radio-amateurs (beaucoup de geek et d'amateurs de nouvelles technologies). Pour le RTC : Réseau Téléphonique Commuté. C'est l'acronyme courrament utilisé pour désigner le réseau de téléphone. Les abonnés sont liés via une paire de cuivre à central, et les centrals connectés entre eux. Il y a quelque temps, la commutation était réalisée par des opérateurs humains, on demandait par exemple le 22 à Asnière. Bien sur avec le temps, tout çà est devenu numérique et on entre en relation en quelques centaines de milisecondes. RTC également utilisé comme acronyme a une race particuliere de BBS accessibles par minitel (et autre), basé sur du videotex (minitel oblige), censé etre plus convival et ouvert que le monde austere des BBS. Sans (ou avec peu de) surtaxe a la connexion, biensur. C'est de ce monde que sont originaire pas mal de vieux dinosaures du milieu (a coté de ceux qui ont d'abord trainé dans le milieu BBS :)) 'Spyou' - www.spyou.org - [EMAIL PROTECTED] ircnet.nerim.net - UIN : 6871374 Don't dream it, Be it. (RHPS) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [FRnOG] redondance réseau sur plusieurs sites
mmmouip mais dans ce cas quand l'interco est active ça risque de poser des problèmes non ? Le 13/11/07, Spyou [EMAIL PROTECTED] a écrit : S'il y'a les memes blocs annoncés des deux cotés avec des machines qui répondent pour toutes les IP (redondance complete de ce coté, donc), la perte de l'interco n'est qu'un moindre mal qui risque juste de degrader les perfs. 'Spyou' - www.spyou.org - [EMAIL PROTECTED] ircnet.nerim.net - UIN : 6871374 Don't dream it, Be it. (RHPS) --- Liste de diffusion du FRnOG http://www.frnog.org/ -- David Ramahefason - [EMAIL PROTECTED]
Re: [FRnOG] Re: [FRnOG] redondance réseau sur plusieurs sites
At 11:13 13/11/2007, you wrote: mmmouip mais dans ce cas quand l'interco est active ça risque de poser des problèmes non ? Ben .. non .. quand elle est active, l'IBGP réparti le trafic entre les deux pop en fonction des besoin et des envies. Si elle est down, tout ce qui rentre par un pop sors par ce meme pop et basta. Le seul soucis, c'est si les deux transitaires sont tres déséquilibré en entrant, ca risque de faire un pop qui crache beaucoup et l'autre qui se la coule douce. 'Spyou' - www.spyou.org - [EMAIL PROTECTED] ircnet.nerim.net - UIN : 6871374 Don't dream it, Be it. (RHPS) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Re: [FRnOG] redondance réseau sur plusieurs sites
Perso avoir 2 sites avec des machines qui répondent aux mêmes adresses ça me pose problème. Mais on sort du sujet initial. Le 13/11/07, Spyou [EMAIL PROTECTED] a écrit : At 11:13 13/11/2007, you wrote: mmmouip mais dans ce cas quand l'interco est active ça risque de poser des problèmes non ? Ben .. non .. quand elle est active, l'IBGP réparti le trafic entre les deux pop en fonction des besoin et des envies. Si elle est down, tout ce qui rentre par un pop sors par ce meme pop et basta. Le seul soucis, c'est si les deux transitaires sont tres déséquilibré en entrant, ca risque de faire un pop qui crache beaucoup et l'autre qui se la coule douce. 'Spyou' - www.spyou.org - [EMAIL PROTECTED] ircnet.nerim.net - UIN : 6871374 Don't dream it, Be it. (RHPS) --- Liste de diffusion du FRnOG http://www.frnog.org/ -- David Ramahefason - [EMAIL PROTECTED]
Re: [FRnOG] redondance réseau sur plusieurs sites
On Tue, 13 Nov 2007 08:17:03 +0100, Geoffroy RIVAT [EMAIL PROTECTED] said: intersite : bgp routeur 1 = bgp routeur 3 bgp routeur 2 = bgp routeur 4 Ou plutot que d'avoir deux interco separes (1-3 , 2-4), tu peux mettre les 4 routeurs sur un /29 sur l'interlan. Si en plus tu veux imperativement avoir deux liens pour raison de redondance/securite, tu fais de l'aggregation sur les 2 liens, comme ca ta bande passante inter-site double. Apres, c'est a toi de choisir si tu veux faire du full-BGP (tu partage la bande passante entre tes 2 sites) ou du default-route (chaque site avec sa route par default en local, l'interlan seulement pour rapatrier le trafic qui arrive sur le mauvais site ou pour le cas ou un des operateurs sont down). Pour ce qui est le fait d'annoncer des prefixes separes sur chaque site, l'idee n'est pas geniale. Au mieux tu annonces les prefixes de l'autre site avec as-path prepend (ou community pour que ton uplink le fait a ta place). Ca juste parce-que tu as des /24, probablement pas contigues. S'il s'agit des bloc qui peuvent etre aggreges, beaucoup de gens ici vont te detester jusqu'a la fin de tes jours si tu annonces chaque bloc separement. -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] redondance réseau sur plusieurs sites
Comme dit avant la perte du lien d'interco est la partie la moins triviale à gérer sur ton archi. Pour ce qui est d'annonces des morceaux de classes de part et d'autre, ca n'est pas trop l'usage sur les IXs. A la rigueur tu peux jouer sur les communautés de tes Upstream comme le disait quelqu'un dans les échanges précédents pour prépender vers certains/es IX's/destinations. Une solution à base de SLB (Server Iron / F5 ou autre) pourrait peut être fonctionner, vue qu'en cas de coupure de ton intersite tes 2 équipements passerait en master, jamais testé, mais je pense que ca devrait fonctionner. Par contre cela te fait un autre point de coupure dans le réseau, et la gestion de l'adressage s'en voit un peu modifiée. Le 13/11/07, Raymond Caracatamatere [EMAIL PROTECTED] a écrit : Merci à tous pour toutes ces réponses, la lumière commence à se faire. C'est vrai que cette problématique de redondance sur plusieurs sites est très interessante. Vous l'avez compris l'important pour moi est la continuité de service que je dois offrir. Donc avec un seul AS 2 routeurs sur chaques sites avec disons 1 opérateur sur chaques routeurs et 2 interlan pour y faire passer de l'ibgp, cela vous semble la meilleure solution ? Simplement on le sait tous, le réseau n'est jamais 100% fiable, que se passera t-il si jamais je perd l'interlan (même redondé) mon AS et l'ensemble de mes IP seront annoncés via les deux sites mais sans IBGP entre les deux sites quelles seront les conséquences ? Aussi vous semblez dire que l'on puisse annoncer des prefixes différents sur les deux sites (chose que je ne pensais pas possible) avec le même AS ? n'est ce pas mal ? certain d'entre vous le font ? l'ont fait ? Cela voudrait dire que ma salle 1 annonce 2 /24 et ma salle 2 annonce mon dernier /24 c'est possible? donc si je perds 1 salle l'autre continu de fonctionner et il me suffirai d'annoncer sur la salle restante les préfixes de la salle1 pour que le transit se fasse via l'interlan ? Merci encore de vos idées,et de votre forte expérience, cette échange est très enrichissant pour moi Le 13/11/07, Radu-Adrian Feurdean [EMAIL PROTECTED] a écrit : On Tue, 13 Nov 2007 08:17:03 +0100, Geoffroy RIVAT [EMAIL PROTECTED] said: intersite : bgp routeur 1 = bgp routeur 3 bgp routeur 2 = bgp routeur 4 Ou plutot que d'avoir deux interco separes (1-3 , 2-4), tu peux mettre les 4 routeurs sur un /29 sur l'interlan. Si en plus tu veux imperativement avoir deux liens pour raison de redondance/securite, tu fais de l'aggregation sur les 2 liens, comme ca ta bande passante inter-site double. Apres, c'est a toi de choisir si tu veux faire du full-BGP (tu partage la bande passante entre tes 2 sites) ou du default-route (chaque site avec sa route par default en local, l'interlan seulement pour rapatrier le trafic qui arrive sur le mauvais site ou pour le cas ou un des operateurs sont down). Pour ce qui est le fait d'annoncer des prefixes separes sur chaque site, l'idee n'est pas geniale. Au mieux tu annonces les prefixes de l'autre site avec as-path prepend (ou community pour que ton uplink le fait a ta place). Ca juste parce-que tu as des /24, probablement pas contigues. S'il s'agit des bloc qui peuvent etre aggreges, beaucoup de gens ici vont te detester jusqu'a la fin de tes jours si tu annonces chaque bloc separement. -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/ -- David Ramahefason - [EMAIL PROTECTED]
Re: Re: [FRnOG] redondance réseau sur plusieurs sites
On Tue, 13 Nov 2007 13:58:50 +0100, Raymond Caracatamatere [EMAIL PROTECTED] said: Aussi vous semblez dire que l'on puisse annoncer des prefixes différents sur les deux sites (chose que je ne pensais pas possible) avec le même AS ? n'est ce pas mal ? certain d'entre vous le font ? l'ont fait ? Si les prefixes peuvent etre agreges, c'est mal. Si ce n'est pas le cas (ca semble etre ton cas) ca n'a aucune importance. Cela voudrait dire que ma salle 1 annonce 2 /24 et ma salle 2 annonce mon dernier /24 c'est possible? donc si je perds 1 salle l'autre continu de fonctionner et il me suffirai d'annoncer sur la salle restante les préfixes de la salle1 pour que le transit se fasse via l'interlan ? Ce que j'ai fait: Les salles declarent uniquement leurs prefix avec network x.y.z.t. Au niveau de l'annonce vers l'upstream je mets en sortie une route-map qui laisse passer que des prefix a moi. Quand l'interlan marche, les deux salles annoncent tous les prefix (le prefix de l'autre salle etant recu via IBGP). Quand l'interlan tombe, la connexion IBGP tombe et les routeurs sur chaque site annoncent que leurs propres prefixes. Maintenant, vu que la redondance des liens est en train d'etre mise en place, je pense annoncer juste le super-net partout, les chances qu'un site soit totalement isole etant extremement faibles (quasi-nulles). Ca va aussi m'epargner les foudres des gens par ici. -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] redondance réseau sur plusieurs sites
Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu ne fais pas confiance à tes fournisseurs d'Interlan, tu peux aussi monter une interco IGP entre tes routeurs via un tunnel GRE en forcant l'établissement du tunnel par tes transits (annonce d'un plus spécifique sur chaque transit par exemple). Tu mets une bonne grosse métrique sur l'interface Tunnel pour t'assurer qu'elle sert de backup et le tour est joué. Pas très propre mais ca devrait fonctionner. David Ramahefason wrote: Comme dit avant la perte du lien d'interco est la partie la moins triviale à gérer sur ton archi. Pour ce qui est d'annonces des morceaux de classes de part et d'autre, ca n'est pas trop l'usage sur les IXs. A la rigueur tu peux jouer sur les communautés de tes Upstream comme le disait quelqu'un dans les échanges précédents pour prépender vers certains/es IX's/destinations. Une solution à base de SLB (Server Iron / F5 ou autre) pourrait peut être fonctionner, vue qu'en cas de coupure de ton intersite tes 2 équipements passerait en master, jamais testé, mais je pense que ca devrait fonctionner. Par contre cela te fait un autre point de coupure dans le réseau, et la gestion de l'adressage s'en voit un peu modifiée. Le 13/11/07, * Raymond Caracatamatere* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] a écrit : Merci à tous pour toutes ces réponses, la lumière commence à se faire. C'est vrai que cette problématique de redondance sur plusieurs sites est très interessante. Vous l'avez compris l'important pour moi est la continuité de service que je dois offrir. Donc avec un seul AS 2 routeurs sur chaques sites avec disons 1 opérateur sur chaques routeurs et 2 interlan pour y faire passer de l'ibgp, cela vous semble la meilleure solution ? Simplement on le sait tous, le réseau n'est jamais 100% fiable, que se passera t-il si jamais je perd l'interlan (même redondé) mon AS et l'ensemble de mes IP seront annoncés via les deux sites mais sans IBGP entre les deux sites quelles seront les conséquences ? Aussi vous semblez dire que l'on puisse annoncer des prefixes différents sur les deux sites (chose que je ne pensais pas possible) avec le même AS ? n'est ce pas mal ? certain d'entre vous le font ? l'ont fait ? Cela voudrait dire que ma salle 1 annonce 2 /24 et ma salle 2 annonce mon dernier /24 c'est possible? donc si je perds 1 salle l'autre continu de fonctionner et il me suffirai d'annoncer sur la salle restante les préfixes de la salle1 pour que le transit se fasse via l'interlan ? Merci encore de vos idées,et de votre forte expérience, cette échange est très enrichissant pour moi Le 13/11/07, *Radu-Adrian Feurdean* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] a écrit : On Tue, 13 Nov 2007 08:17:03 +0100, Geoffroy RIVAT [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] said: intersite : bgp routeur 1 = bgp routeur 3 bgp routeur 2 = bgp routeur 4 Ou plutot que d'avoir deux interco separes (1-3 , 2-4), tu peux mettre les 4 routeurs sur un /29 sur l'interlan. Si en plus tu veux imperativement avoir deux liens pour raison de redondance/securite, tu fais de l'aggregation sur les 2 liens, comme ca ta bande passante inter-site double. Apres, c'est a toi de choisir si tu veux faire du full-BGP (tu partage la bande passante entre tes 2 sites) ou du default-route (chaque site avec sa route par default en local, l'interlan seulement pour rapatrier le trafic qui arrive sur le mauvais site ou pour le cas ou un des operateurs sont down). Pour ce qui est le fait d'annoncer des prefixes separes sur chaque site, l'idee n'est pas geniale. Au mieux tu annonces les prefixes de l'autre site avec as-path prepend (ou community pour que ton uplink le fait a ta place). Ca juste parce-que tu as des /24, probablement pas contigues. S'il s'agit des bloc qui peuvent etre aggreges, beaucoup de gens ici vont te detester jusqu'a la fin de tes jours si tu annonces chaque bloc separement. -- Radu-Adrian Feurdean raf (a) ftml ! net --- Liste de diffusion du FRnOG http://www.frnog.org/ -- David Ramahefason - [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] redondance réseau sur plusieurs sites
Cédric BODIGUEL wrote: En cas de perte de l'interlan, le site1 ne recevra pas les prefixes du site2 par le eBGP (et vice versa). Il faudrait donc utiliser des routes statiques pour faire communiquer les 2 sites ou au moins pour établir le tunnel GRE. Je n'ai pas pas parlé d'eBGP, j'ai parlé de monter une adjacence IGP via une interface tunnel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] redondance réseau sur plusieurs sit es
Rh la solution à haute teneur en classe :) - je trouve la solution particulièrement interessante d'un point de vue esthétique (merci Jerome David), mais bon, se payer deux salles si c'est pour bricoler derrière, j'ai des doutes. En général, tu prends jamais un point à point pour relier 2 salles si c'est critique: tu constitue un anneau à partir de deux points à points achetés chez deux fournisseurs différents, ton IGP annoncera tes loopbacks BGP pour que quand une patte de l'anneau claque, le voisin iBGP soit encore intègre. Dis toi bien que si tu prends deux salles, l'idéal est de prendre un anneau fibre noire et de l'éclairer toi même, ce qui est simple si c'est du métro - le passif ne coute plus rien. Si tout ce que tu gagnes en ayant deux sales, tu le perds en prenant des liens pourris inter-salles, tu perds tout le bénéfice de ta redondance de site. Greg On Nov 13, 2007, at 3:25 PM, David Ramahefason wrote: Si le lien GRE fait partie de l'IGP ca doit pourvoir marcher. Le 13/11/07, Cédric BODIGUEL [EMAIL PROTECTED] a écrit :En cas de perte de l'interlan, le site1 ne recevra pas les prefixes du site2 par le eBGP (et vice versa). Il faudrait donc utiliser des routes statiques pour faire communiquer les 2 sites ou au moins pour établir le tunnel GRE. Cedric -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Jerome Fleury Envoyé : mardi 13 novembre 2007 14:55 À : David Ramahefason Cc : Raymond Caracatamatere; frnog@frnog.org Objet : Re: [FRnOG] redondance réseau sur plusieurs sites Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu ne fais pas confiance à tes fournisseurs d'Interlan, tu peux aussi monter une interco IGP entre tes routeurs via un tunnel GRE en forcant l'établissement du tunnel par tes transits (annonce d'un plus spécifique sur chaque transit par exemple). Tu mets une bonne grosse métrique sur l'interface Tunnel pour t'assurer qu'elle sert de backup et le tour est joué. Pas très propre mais ca devrait fonctionner. David Ramahefason wrote: Comme dit avant la perte du lien d'interco est la partie la moins triviale à gérer sur ton archi. Pour ce qui est d'annonces des morceaux de classes de part et d'autre, ca n'est pas trop l'usage sur les IXs. A la rigueur tu peux jouer sur les communautés de tes Upstream comme le disait quelqu'un dans les échanges précédents pour prépender vers certains/es IX's/destinations. Une solution à base de SLB (Server Iron / F5 ou autre) pourrait peut être fonctionner, vue qu'en cas de coupure de ton intersite tes 2 équipements passerait en master, jamais testé, mais je pense que ca devrait fonctionner. Par contre cela te fait un autre point de coupure dans le réseau, et la gestion de l'adressage s'en voit un peu modifiée. Le 13/11/07, * Raymond Caracatamatere* [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] a écrit : Merci à tous pour toutes ces réponses, la lumière commence à se faire. C'est vrai que cette problématique de redondance sur plusieurs sites est très interessante. Vous l'avez compris l'important pour moi est la continuité de service que je dois offrir. Donc avec un seul AS 2 routeurs sur chaques sites avec disons 1 opérateur sur chaques routeurs et 2 interlan pour y faire passer de l'ibgp, cela vous semble la meilleure solution ? Simplement on le sait tous, le réseau n'est jamais 100% fiable, que se passera t-il si jamais je perd l'interlan (même redondé) mon AS et l'ensemble de mes IP seront annoncés via les deux sites mais sans IBGP entre les deux sites quelles seront les conséquences ? Aussi vous semblez dire que l'on puisse annoncer des prefixes différents sur les deux sites (chose que je ne pensais pas possible) avec le même AS ? n'est ce pas mal ? certain d'entre vous le font ? l'ont fait ? Cela voudrait dire que ma salle 1 annonce 2 /24 et ma salle 2 annonce mon dernier /24 c'est possible? donc si je perds 1 salle l'autre continu de fonctionner et il me suffirai d'annoncer sur la salle restante les préfixes de la salle1 pour que le transit se fasse via l'interlan ? Merci encore de vos idées,et de votre forte expérience, cette échange est très enrichissant pour moi Le 13/11/07, *Radu-Adrian Feurdean* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] a écrit : On Tue, 13 Nov 2007 08:17:03 +0100, Geoffroy RIVAT [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] said: intersite : bgp routeur 1 = bgp routeur 3 bgp routeur 2 = bgp routeur 4 Ou plutot que d'avoir deux interco separes (1-3 , 2-4), tu peux mettre les 4 routeurs sur un /29 sur l'interlan. Si en plus tu veux imperativement avoir deux liens pour raison de redondance/securite, tu fais de l'aggregation sur les 2
Re: [FRnOG] redondance réseau sur plusieurs sites
Certes Greg, Mais murphy veille toujours et dans le cas particulier où l'interco flanche, si tu n'as pas pris de précaution/pensé à ce qu'il pourrait se passer, le fait d'avoir 2 salles ne te servira a rien sauf a foutre tes services en l'air. La solution de Jerôme est tricky mais intéressante, la mienne coûte plus cher en matériel, les deux doivent fonctionner et répondre au problème de perte d'une qui flanche interco entre les 2 sites. Et de ma petite expérience réseau, le c'est super redondant, ça ne plantera jamais ben je n'y souscris pas a 100% bien que les technos s'ameliorent, murphy veille toujours. Mon expérience actuelle ne fait que confirmer ce que j'avance, bug multiple sur du matériel redondant en anneau et tout et tout de la mort qui tue. David Le 13/11/07, Greg VILLAIN [EMAIL PROTECTED] a écrit : Rh la solution à haute teneur en classe :) - je trouve la solution particulièrement interessante d'un point de vue esthétique (merci Jerome David), mais bon, se payer deux salles si c'est pour bricoler derrière, j'ai des doutes. En général, tu prends jamais un point à point pour relier 2 salles si c'est critique: tu constitue un anneau à partir de deux points à points achetés chez deux fournisseurs différents, ton IGP annoncera tes loopbacks BGP pour que quand une patte de l'anneau claque, le voisin iBGP soit encore intègre. Dis toi bien que si tu prends deux salles, l'idéal est de prendre un anneau fibre noire et de l'éclairer toi même, ce qui est simple si c'est du métro - le passif ne coute plus rien. Si tout ce que tu gagnes en ayant deux sales, tu le perds en prenant des liens pourris inter-salles, tu perds tout le bénéfice de ta redondance de site. Greg On Nov 13, 2007, at 3:25 PM, David Ramahefason wrote: Si le lien GRE fait partie de l'IGP ca doit pourvoir marcher. Le 13/11/07, Cédric BODIGUEL [EMAIL PROTECTED] a écrit :En cas de perte de l'interlan, le site1 ne recevra pas les prefixes du site2 par le eBGP (et vice versa). Il faudrait donc utiliser des routes statiques pour faire communiquer les 2 sites ou au moins pour établir le tunnel GRE. Cedric -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Jerome Fleury Envoyé : mardi 13 novembre 2007 14:55 À : David Ramahefason Cc : Raymond Caracatamatere; frnog@frnog.org Objet : Re: [FRnOG] redondance réseau sur plusieurs sites Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu ne fais pas confiance à tes fournisseurs d'Interlan, tu peux aussi monter une interco IGP entre tes routeurs via un tunnel GRE en forcant l'établissement du tunnel par tes transits (annonce d'un plus spécifique sur chaque transit par exemple). Tu mets une bonne grosse métrique sur l'interface Tunnel pour t'assurer qu'elle sert de backup et le tour est joué. Pas très propre mais ca devrait fonctionner. David Ramahefason wrote: Comme dit avant la perte du lien d'interco est la partie la moins triviale à gérer sur ton archi. Pour ce qui est d'annonces des morceaux de classes de part et d'autre, ca n'est pas trop l'usage sur les IXs. A la rigueur tu peux jouer sur les communautés de tes Upstream comme le disait quelqu'un dans les échanges précédents pour prépender vers certains/es IX's/destinations. Une solution à base de SLB (Server Iron / F5 ou autre) pourrait peut être fonctionner, vue qu'en cas de coupure de ton intersite tes 2 équipements passerait en master, jamais testé, mais je pense que ca devrait fonctionner. Par contre cela te fait un autre point de coupure dans le réseau, et la gestion de l'adressage s'en voit un peu modifiée. Le 13/11/07, * Raymond Caracatamatere* [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] a écrit : Merci à tous pour toutes ces réponses, la lumière commence à se faire. C'est vrai que cette problématique de redondance sur plusieurs sites est très interessante. Vous l'avez compris l'important pour moi est la continuité de service que je dois offrir. Donc avec un seul AS 2 routeurs sur chaques sites avec disons 1 opérateur sur chaques routeurs et 2 interlan pour y faire passer de l'ibgp, cela vous semble la meilleure solution ? Simplement on le sait tous, le réseau n'est jamais 100% fiable, que se passera t-il si jamais je perd l'interlan (même redondé) mon AS et l'ensemble de mes IP seront annoncés via les deux sites mais sans IBGP entre les deux sites quelles seront les conséquences ? Aussi vous semblez dire que l'on puisse annoncer des prefixes différents sur les deux sites (chose que je ne pensais pas possible) avec le même AS ? n'est ce pas mal ? certain d'entre vous le font ? l'ont fait ? Cela voudrait dire que ma salle 1 annonce 2 /24 et ma salle 2 annonce mon dernier /24 c'est possible? donc si
Re: [FRnOG] redondance réseau sur plusieurs sit es
... nan mais t'as raison, je schématise un peu. Me souviens de certains mecs prévoyants qui avaient un double anneau européen, un coté chez EBone, l'autre chez KPN. Z'étaient contents quand le conglomérat des deux a fait faillite après de le rachat de l'un par l'autre. Greg PS: David: de ma petite expérience[...], qui tu crois duper ? ;) On Nov 13, 2007, at 6:13 PM, David Ramahefason wrote: Certes Greg, Mais murphy veille toujours et dans le cas particulier où l'interco flanche, si tu n'as pas pris de précaution/pensé à ce qu'il pourrait se passer, le fait d'avoir 2 salles ne te servira a rien sauf a foutre tes services en l'air. La solution de Jerôme est tricky mais intéressante, la mienne coûte plus cher en matériel, les deux doivent fonctionner et répondre au problème de perte d'une qui flanche interco entre les 2 sites. Et de ma petite expérience réseau, le c'est super redondant, ça ne plantera jamais ben je n'y souscris pas a 100% bien que les technos s'ameliorent, murphy veille toujours. Mon expérience actuelle ne fait que confirmer ce que j'avance, bug multiple sur du matériel redondant en anneau et tout et tout de la mort qui tue. David Le 13/11/07, Greg VILLAIN [EMAIL PROTECTED] a écrit : Rh la solution à haute teneur en classe :) - je trouve la solution particulièrement interessante d'un point de vue esthétique (merci Jerome David), mais bon, se payer deux salles si c'est pour bricoler derrière, j'ai des doutes. En général, tu prends jamais un point à point pour relier 2 salles si c'est critique: tu constitue un anneau à partir de deux points à points achetés chez deux fournisseurs différents, ton IGP annoncera tes loopbacks BGP pour que quand une patte de l'anneau claque, le voisin iBGP soit encore intègre. Dis toi bien que si tu prends deux salles, l'idéal est de prendre un anneau fibre noire et de l'éclairer toi même, ce qui est simple si c'est du métro - le passif ne coute plus rien. Si tout ce que tu gagnes en ayant deux sales, tu le perds en prenant des liens pourris inter-salles, tu perds tout le bénéfice de ta redondance de site. Greg On Nov 13, 2007, at 3:25 PM, David Ramahefason wrote: Si le lien GRE fait partie de l'IGP ca doit pourvoir marcher. Le 13/11/07, Cédric BODIGUEL [EMAIL PROTECTED] a écrit :En cas de perte de l'interlan, le site1 ne recevra pas les prefixes du site2 par le eBGP (et vice versa). Il faudrait donc utiliser des routes statiques pour faire communiquer les 2 sites ou au moins pour établir le tunnel GRE. Cedric -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Jerome Fleury Envoyé : mardi 13 novembre 2007 14:55 À : David Ramahefason Cc : Raymond Caracatamatere; frnog@frnog.org Objet : Re: [FRnOG] redondance réseau sur plusieurs sites Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu ne fais pas confiance à tes fournisseurs d'Interlan, tu peux aussi monter une interco IGP entre tes routeurs via un tunnel GRE en forcant l'établissement du tunnel par tes transits (annonce d'un plus spécifique sur chaque transit par exemple). Tu mets une bonne grosse métrique sur l'interface Tunnel pour t'assurer qu'elle sert de backup et le tour est joué. Pas très propre mais ca devrait fonctionner. David Ramahefason wrote: Comme dit avant la perte du lien d'interco est la partie la moins triviale à gérer sur ton archi. Pour ce qui est d'annonces des morceaux de classes de part et d'autre, ca n'est pas trop l'usage sur les IXs. A la rigueur tu peux jouer sur les communautés de tes Upstream comme le disait quelqu'un dans les échanges précédents pour prépender vers certains/es IX's/destinations. Une solution à base de SLB (Server Iron / F5 ou autre) pourrait peut être fonctionner, vue qu'en cas de coupure de ton intersite tes 2 équipements passerait en master, jamais testé, mais je pense que ca devrait fonctionner. Par contre cela te fait un autre point de coupure dans le réseau, et la gestion de l'adressage s'en voit un peu modifiée. Le 13/11/07, * Raymond Caracatamatere* [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] a écrit : Merci à tous pour toutes ces réponses, la lumière commence à se faire. C'est vrai que cette problématique de redondance sur plusieurs sites est très interessante. Vous l'avez compris l'important pour moi est la continuité de service que je dois offrir. Donc avec un seul AS 2 routeurs sur chaques sites avec disons 1 opérateur sur chaques routeurs et 2 interlan pour y faire passer de l'ibgp, cela vous semble la meilleure solution ? Simplement on le sait tous, le réseau n'est jamais 100% fiable, que se passera t-il si jamais je perd l'interlan (même redondé) mon AS et l'ensemble de mes IP seront annoncés via les deux sites mais sans IBGP entre les deux sites quelles seront les conséquences ?
[FRnOG] RE: [FRnOG] redondance réseau sur plusieurs sites
Bonjour, Je te conseille vivement d'établir une cahier de charge pour la résilience de ton réseau et même pour ta liaison BGP. Il y a beaucoup de solutions possible et vérification contre ledit cahier peut t'aider dans tous ces choix. On peut aussi formalise la CA en créant un 'failure matrix'. Dans la première colonne on liste tous le panne (simple pour commencer) et dans la second, on spécifie le comportement souhaitable de ton réseau. N'oubli pas possible impact sur des équipements en aval, firewall, load balancers, ISP/IDS etc. Est-ce que tu as besoin de traite les double pannes (normalement c'est n'est pas nécessaire mais c'est bien de définir un plan d'action en cas ou)? Pour BGP, - Quelle est utilité de BGP pour ton réseaux ? - Est-ce que tu a besoin de tout les routes ? - Si oui (je ne te crois pas .-) quelle est ta stratégie en cas de surcharge (ca vas arrive) ? - Si non - quelle visibilité du monde extérieur est raisonnable pour toi (en AS ou profondeur de path AS)? Les solutions standard on été déjà mentionné. De toute manier, il faut aussi crée et exécute une cahier de test pour tous le cas pris en charge dans ta matrice. Solution de redondance d'un Interlan via WAN sont toujours très délicates et nécessite beaucoup de test. Est-ce que c'est vraiment nécessaire dans ton cas ? Est-ce que les sites sont indépendantes ? (..CA !!). Cordialement Wlodek [excuse mon français, je traduit du Cro-Magnon] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Caracatamatere Sent: Tuesday, November 13, 2007 12:01 AM To: frnog@frnog.org Subject: [FRnOG] redondance réseau sur plusieurs sites --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] BGP announces RFC1918
Hello, j'en profite que la liste soit bien en éveil en ce moment. C'est probablement off-topic, mais y'a une discussion NANOG en cours sur le theme de est-ce normal que je reçoive des annonces de type RFC1918 sur nos upstreams. La réponse bien évidemment est NON, mais une petite expérimentation en cas réel, pour ceux qui ont l'ACL-Accounting, celle-ci est édifiante. Le but est pas de lancer le troll du siècle, mais plutôt de sensibiliser le filtrage des annonces: c'est censé être trivial, mais en fait pas du tout ! [EMAIL PROTECTED] access-list accounting ethernet 1/3 in Collecting ACL accounting for 1/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-1 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)1 (1 min) 48 (5 min) 110 (accum) 2132627 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)1 (1 min) 22 (5 min) 75 (accum) 290302 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)4 (5 min) 33 (accum) 148613 [EMAIL PROTECTED] access-list accounting ethernet 1/3 in Collecting ACL accounting for 1/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-2 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)0 (1 min)4 (5 min) 57 (accum) 1598758 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)1 (1 min)0 (5 min) 27 (accum) 312758 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min) 22 (accum) 167969 [EMAIL PROTECTED] access-list accounting ethernet 2/3 in Collecting ACL accounting for 2/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-3 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 4575 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 291 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 75 Greg VILLAIN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] BGP announces RFC1918
On Nov 13, 2007, at 6:56 PM, Greg VILLAIN wrote: Hello, j'en profite que la liste soit bien en éveil en ce moment. C'est probablement off-topic, mais y'a une discussion NANOG en cours sur le theme de est-ce normal que je reçoive des annonces de type RFC1918 sur nos upstreams. La réponse bien évidemment est NON, mais une petite expérimentation en cas réel, pour ceux qui ont l'ACL-Accounting, celle-ci est édifiante. Le but est pas de lancer le troll du siècle, mais plutôt de sensibiliser le filtrage des annonces: c'est censé être trivial, mais en fait pas du tout ! [EMAIL PROTECTED] access-list accounting ethernet 1/3 in Collecting ACL accounting for 1/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-1 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)1 (1 min) 48 (5 min) 110 (accum) 2132627 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)1 (1 min) 22 (5 min) 75 (accum) 290302 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)4 (5 min) 33 (accum) 148613 [EMAIL PROTECTED] access-list accounting ethernet 1/3 in Collecting ACL accounting for 1/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-2 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)0 (1 min)4 (5 min) 57 (accum) 1598758 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)1 (1 min)0 (5 min) 27 (accum) 312758 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min) 22 (accum) 167969 [EMAIL PROTECTED] access-list accounting ethernet 2/3 in Collecting ACL accounting for 2/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-3 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 4575 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 291 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 75 Greg VILLAIN Correction: s/announces/traffic/g dans le sujet et dans le corps du mail. Toutes mes confuses pour cette coquille. Greg VILLAIN --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] BGP announces RFC1918
Ben tu as donné la réponse :) C'est non ce n'est pas normal, mais comme tout le monde ne fait pas forcement attention ben faut filtrer ce que tu reçois, pour cela que je n'aime pas trop les max-prefix comme securité en peering. Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt :)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le truc est peut être de filtrer et forcer les personnes à mettre à jour leur records RIPE, ce que j'ai fais un temps. J'ai une moulinette sous la main pour ceux qui veulent pour la construction de filter list. Le 13/11/07, Greg VILLAIN [EMAIL PROTECTED] a écrit : On Nov 13, 2007, at 6:56 PM, Greg VILLAIN wrote: Hello, j'en profite que la liste soit bien en éveil en ce moment. C'est probablement off-topic, mais y'a une discussion NANOG en cours sur le theme de est-ce normal que je reçoive des annonces de type RFC1918 sur nos upstreams. La réponse bien évidemment est NON, mais une petite expérimentation en cas réel, pour ceux qui ont l'ACL-Accounting, celle-ci est édifiante. Le but est pas de lancer le troll du siècle, mais plutôt de sensibiliser le filtrage des annonces: c'est censé être trivial, mais en fait pas du tout ! [EMAIL PROTECTED] access-list accounting ethernet 1/3 in Collecting ACL accounting for 1/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-1 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)1 (1 min) 48 (5 min) 110 (accum) 2132627 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)1 (1 min) 22 (5 min) 75 (accum) 290302 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)4 (5 min) 33 (accum) 148613 [EMAIL PROTECTED] access-list accounting ethernet 1/3 in Collecting ACL accounting for 1/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-2 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)0 (1 min)4 (5 min) 57 (accum) 1598758 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)1 (1 min)0 (5 min) 27 (accum) 312758 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min) 22 (accum) 167969 [EMAIL PROTECTED] access-list accounting ethernet 2/3 in Collecting ACL accounting for 2/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-3 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 4575 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 291 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 75 Greg VILLAIN Correction: s/announces/traffic/g dans le sujet et dans le corps du mail. Toutes mes confuses pour cette coquille. Greg VILLAIN --- Liste de diffusion du FRnOG http://www.frnog.org/ -- David Ramahefason - [EMAIL PROTECTED]
Re: [FRnOG] BGP announces RFC1918
On Tue, Nov 13, 2007 at 07:39:07PM +0100, David Ramahefason wrote: Ben tu as donné la réponse :) C'est non ce n'est pas normal, mais comme tout le monde ne fait pas forcement attention ben faut filtrer ce que tu reçois, pour cela que je n'aime pas trop les max-prefix comme securité en peering. Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt :)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le truc est peut être de filtrer et forcer les personnes à mettre à jour leur records RIPE, ce que j'ai fais un temps. J'ai une moulinette sous la main pour ceux qui veulent pour la construction de filter list. pourquoi ne pas utiliser les bogon-filter, par exemple ? Le 13/11/07, Greg VILLAIN [EMAIL PROTECTED] a écrit : On Nov 13, 2007, at 6:56 PM, Greg VILLAIN wrote: Hello, j'en profite que la liste soit bien en éveil en ce moment. C'est probablement off-topic, mais y'a une discussion NANOG en cours sur le theme de est-ce normal que je reçoive des annonces de type RFC1918 sur nos upstreams. La réponse bien évidemment est NON, mais une petite expérimentation en cas réel, pour ceux qui ont l'ACL-Accounting, celle-ci est édifiante. Le but est pas de lancer le troll du siècle, mais plutôt de sensibiliser le filtrage des annonces: c'est censé être trivial, mais en fait pas du tout ! [EMAIL PROTECTED] access-list accounting ethernet 1/3 in Collecting ACL accounting for 1/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-1 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)1 (1 min) 48 (5 min) 110 (accum) 2132627 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)1 (1 min) 22 (5 min) 75 (accum) 290302 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)4 (5 min) 33 (accum) 148613 [EMAIL PROTECTED] access-list accounting ethernet 1/3 in Collecting ACL accounting for 1/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-2 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)0 (1 min)4 (5 min) 57 (accum) 1598758 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)1 (1 min)0 (5 min) 27 (accum) 312758 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min) 22 (accum) 167969 [EMAIL PROTECTED] access-list accounting ethernet 2/3 in Collecting ACL accounting for 2/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-3 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 4575 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 291 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 75 Greg VILLAIN Correction: s/announces/traffic/g dans le sujet et dans le corps du mail. Toutes mes confuses pour cette coquille. Greg VILLAIN --- Liste de diffusion du FRnOG http://www.frnog.org/ -- David Ramahefason - [EMAIL PROTECTED] -- Romain --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] BGP announces RFC1918
Le Tuesday 13 November 2007 19:39:07 David Ramahefason, vous avez écrit : J'ai une moulinette sous la main pour ceux qui veulent pour la construction de filter list. Bonjour, Je serait intéréssais par ta moulinette :) Merci d'avance. Cordialement, -- David CHANIAL --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] BGP announces RFC1918
Romain Tournier a écrit : On Tue, Nov 13, 2007 at 07:39:07PM +0100, David Ramahefason wrote: Ben tu as donné la réponse :) C'est non ce n'est pas normal, mais comme tout le monde ne fait pas forcement attention ben faut filtrer ce que tu reçois, pour cela que je n'aime pas trop les max-prefix comme securité en peering. Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt :)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le truc est peut être de filtrer et forcer les personnes à mettre à jour leur records RIPE, ce que j'ai fais un temps. J'ai une moulinette sous la main pour ceux qui veulent pour la construction de filter list. pourquoi ne pas utiliser les bogon-filter, par exemple ? Avec comme base, la liste officielle du CYMRU : http://www.cymru.com/Documents/bogon-list.html -- Ronnie Garcia r.garcia at ovea dot com --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] BGP announces RFC1918
Oui aussi :) Le 13/11/07, Ronnie Garcia [EMAIL PROTECTED] a écrit : Romain Tournier a écrit : On Tue, Nov 13, 2007 at 07:39:07PM +0100, David Ramahefason wrote: Ben tu as donné la réponse :) C'est non ce n'est pas normal, mais comme tout le monde ne fait pas forcement attention ben faut filtrer ce que tu reçois, pour cela que je n'aime pas trop les max-prefix comme securité en peering. Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt :)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le truc est peut être de filtrer et forcer les personnes à mettre à jour leur records RIPE, ce que j'ai fais un temps. J'ai une moulinette sous la main pour ceux qui veulent pour la construction de filter list. pourquoi ne pas utiliser les bogon-filter, par exemple ? Avec comme base, la liste officielle du CYMRU : http://www.cymru.com/Documents/bogon-list.html -- Ronnie Garcia r.garcia at ovea dot com --- Liste de diffusion du FRnOG http://www.frnog.org/ -- David Ramahefason - [EMAIL PROTECTED]
Re: [FRnOG] BGP announces RFC1918
http://www.netfacile.net/cgi-bin/bgp.cgi Le 13/11/07, David CHANIAL [EMAIL PROTECTED] a écrit : Le Tuesday 13 November 2007 19:39:07 David Ramahefason, vous avez écrit: J'ai une moulinette sous la main pour ceux qui veulent pour la construction de filter list. Bonjour, Je serait intéréssais par ta moulinette :) Merci d'avance. Cordialement, -- David CHANIAL -- David Ramahefason - [EMAIL PROTECTED]
RE: [FRnOG] BGP announces RFC1918
Suis d'accord, sauf que parfois (avec des peers tres riches en cust-routes) il est doulereux de filtrer par pfx et AS_PATH (AS-Set). Comme on le sais bien, le nombre de faux negatifs est parfois assez large quand on se base sur l'IRR... max-prefix a eviter si possible, je suis d'accord en principe pour des raisons operationelles. Il y a des schemes alternatifs : age d'un prefix ; avoir confiance d'un nouveau prefix avec un certain origin en fonction de son age et out-of-band info ; on peut imaginer un trust rating via LOCAL_PREF... Si cela interesse notre liste, discutons ? mh _ De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de David Ramahefason Envoyé : mardi 13 novembre 2007 19:39 À : Greg VILLAIN Cc : frnog@frnog.org Objet : Re: [FRnOG] BGP announces RFC1918 Ben tu as donné la réponse :) C'est non ce n'est pas normal, mais comme tout le monde ne fait pas forcement attention ben faut filtrer ce que tu reçois, pour cela que je n'aime pas trop les max-prefix comme securité en peering. Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt :)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le truc est peut être de filtrer et forcer les personnes à mettre à jour leur records RIPE, ce que j'ai fais un temps. J'ai une moulinette sous la main pour ceux qui veulent pour la construction de filter list. Le 13/11/07, Greg VILLAIN mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] a écrit : On Nov 13, 2007, at 6:56 PM, Greg VILLAIN wrote: Hello, j'en profite que la liste soit bien en éveil en ce moment. C'est probablement off-topic, mais y'a une discussion NANOG en cours sur le theme de est-ce normal que je reçoive des annonces de type RFC1918 sur nos upstreams. La réponse bien évidemment est NON, mais une petite expérimentation en cas réel, pour ceux qui ont l'ACL-Accounting, celle-ci est édifiante. Le but est pas de lancer le troll du siècle, mais plutôt de sensibiliser le filtrage des annonces: c'est censé être trivial, mais en fait pas du tout ! [EMAIL PROTECTED] access-list accounting ethernet 1/3 in Collecting ACL accounting for 1/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-1 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)1 (1 min) 48 (5 min) 110 (accum) 2132627 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)1 (1 min) 22 (5 min) 75 (accum) 290302 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)4 (5 min) 33 (accum) 148613 [EMAIL PROTECTED] access-list accounting ethernet 1/3 in Collecting ACL accounting for 1/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-2 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)0 (1 min)4 (5 min) 57 (accum) 1598758 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)1 (1 min)0 (5 min) 27 (accum) 312758 3: deny ip 172.16.0.0 0.15.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min) 22 (accum) 167969 [EMAIL PROTECTED] access-list accounting ethernet 2/3 in Collecting ACL accounting for 2/3 ... Completed successfully. ACL Accounting Information: Inbound: ACL ACL_IN_TRANSIT-PROVIDER-3 5: deny ip 192.168.0.0 0.0.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 4575 3: deny ip 172.16.0.0 0.15.255.255 http://0.15.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 291 1: deny ip 10.0.0.0 0.255.255.255 any log Hit count: (1 sec)0 (1 min)0 (5 min)0 (accum) 75 Greg VILLAIN Correction: s/announces/traffic/g dans le sujet et dans le corps du mail. Toutes mes confuses pour cette coquille. Greg VILLAIN --- Liste de diffusion du FRnOG http://www.frnog.org/ -- David Ramahefason - [EMAIL PROTECTED]
Re: [FRnOG] redondance réseau sur plusieurs sites
Hello, On Tue, 13 Nov 2007 14:55:18 +0100 Jerome Fleury [EMAIL PROTECTED] wrote: Si tu pars du principe que tu vas perdre l'interco iBGP parce que tu ne fais pas confiance à tes fournisseurs d'Interlan, tu peux aussi monter une interco IGP entre tes routeurs via un tunnel GRE en forcant l'établissement du tunnel par tes transits (annonce d'un plus spécifique sur chaque transit par exemple). Tu mets une bonne grosse métrique sur l'interface Tunnel pour t'assurer qu'elle sert de backup et le tour est joué. Pas très propre mais ca devrait fonctionner. Plus precisement, je dirai que ca fonctionne, puisque j'ai deja utilise cette solution ;) Dans la pratique, c'est un peu plus complexe, car si je reprends un schema que j'ai vu circule, avec deux operateurs sur le site 1, et deux operateurs sur le site 2, ca fait potentiellement 4 tunnels differents que l'on peut monter (Oui, on est redondant serieux ou bien on se la joue petit bras ;). Il faut ensuite reflechir sur les IP de depart/fin des tunnels (soit elles font partie des blocs annonces sur chaque site, soit ce soit les IPs d'interco avec l'uplink de chaque site - mais attention, certains filtres les annonces des blocs d'interco). Ensuite, il faut choisir le protocole que l'on passe la dedans (IGP, BGP, ...). Mais surtout : ne pas hesiter a tester tous les cas de pannes possibles !!! Sur certaines installations faites, nous avons passe plus de temps a definir tous les cas de ruptures possibles (liens, equipements), les comportements attendus theoriques, et les comportements reels observes pour la recette, par rapport au temps necessaire a la mise en place de la solution. Une chose que je n'ai pas testee, mais je ne crois pas que le constructeur C* la permette, c'est de monter le tunnel entre les deux sites sur des adresses IP virtuelles (HSRP/VRRP), ce qui simplifie largement la problematique des 4 tunnels mentionnes ci-dessus... Qq'un a une idee la-dessus ? Paul --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] BGP announces RFC1918
On 13/11/2007 19:39, David Ramahefason wrote: Ben tu as donné la réponse :) C'est non ce n'est pas normal, mais comme tout le monde ne fait pas forcement attention ben faut filtrer ce que tu reçois, pour cela que je n'aime pas trop les max-prefix comme securité en peering. Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt :)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le truc est peut être de filtrer et forcer les personnes à mettre à jour leur records RIPE, ce que j'ai fais un temps. J'ai une moulinette sous la main pour ceux qui veulent pour la construction de filter list. Le problème est le suivant : tu as un client transit BGP (client A) qui lui à plusieurs clients transit BGP également (clients 1, 2 et 3). Les clients 1, 2 et 3 ont leurs objets route à jour. Le client A recoit donc les routes de ces clients. Le client A va t'annoncer les routes des clients 1, 2 et 3 de façon légitime alors qu'il n'y aura pas d'objet route dans la base du ripe ayant comme origin AS-clientA pour les routes des clients 1, 2 et 3. Donc ce genre de filtre c'est bien mais un peu restrictif. Il faudrait à chaque fois aller plus loin en regardant : s'il n'y a pas d'objet route pour cet AS il faut regarder qui annonce cette route, si c'est l'AS en question : il faut que l'objet route soit créé. si c'est un autre AS, il faut vérifier que l'autre AS en question soit client transit de ton client, bref c'est gérable manuellement, mais automatiquement, bonjour le dev :-) Surtout que la base du ripe est une base déclarative pas super fiable parfois. Pour ta remarque sur le fait que tu n'aimes pas trop un max-prefix comme sécurité sur un peering, tu fais comment si t'as un gros peer qui t'envoie 3000 routes et qui peut varier assez régulièrement ? Bon généralement faut dire que les gens envoyant un nombre de route dans ces environs ne sont pas des boulets et n'envoient pas n'importe quoi non plus, je pense qu'on peut les faire confiance avec un max-prefix uniquement comme sécurité. -- Pierre-Yves --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] BGP announces RFC1918
On 13/11/2007 20:53, David Ramahefason wrote:
http://www.netfacile.net/cgi-bin/bgp.cgi
Ou bien de façon plus conventionnelle ;-)
07:50:12 [EMAIL PROTECTED]:~ {508}
$ grep rroute .bashrc
alias rroute='whois -h whois.ripe.net -i origin -T route'
(traduire : je veux les objets route ayant pour origin le paramètre)
avec un grep route par derrière on obtient juste la liste des routes
Sinon sympa l'outil ;-)
07:50:22 [EMAIL PROTECTED]:~ {509}
$ rroute as
% This is the RIPE Whois query server #1.
% The objects are in RPSL format.
%
% Rights restricted by copyright.
% See http://www.ripe.net/db/copyright.html
% Note: This output has been filtered.
% To receive output for a database update, use the -B flag.
% Information related to '193.0.0.0/21AS'
route:193.0.0.0/21
descr:RIPE-NCC
origin: AS
mnt-by: RIPE-NCC-MNT
source: RIPE # Filtered
% Information related to '193.0.12.0/23AS'
route:193.0.12.0/23
descr:RIPE-NCC
descr:Specific range for nameserver operations.
origin: AS
mnt-by: RIPE-NCC-MNT
source: RIPE # Filtered
% Information related to '193.0.18.0/23AS'
route: 193.0.18.0/23
descr: RIPE-NCC
origin: AS
mnt-by: RIPE-NCC-MNT
source: RIPE # Filtered
--
Pierre-Yves Maunier
---
Liste de diffusion du FRnOG
http://www.frnog.org/
Re: [FRnOG] BGP announces RFC1918
Ben on dit la même chose non ? Ok je n'ai pas précisé que pour les gros peers/Transit on étaient obligé de faire du max-préfix, mais en général les problèmes ne viennent pas d'eux, quoi que :p Le client A peut créer une AS-Macro non ?? ca sert a ca par exemple, mais je suis d'accord avec toi sur le fait que c'est très restrictif car beaucoup de peer n'ont pas leur RIPE objects à jour. David R. Le 14/11/07, Pierre-Yves Maunier [EMAIL PROTECTED] a écrit : On 13/11/2007 19:39, David Ramahefason wrote: Ben tu as donné la réponse :) C'est non ce n'est pas normal, mais comme tout le monde ne fait pas forcement attention ben faut filtrer ce que tu reçois, pour cela que je n'aime pas trop les max-prefix comme securité en peering. Je suis/étais assez partisan des filter-list basées sur les objet RIPE mais par chez nous ça ne fonctionne pas très bien (fonctionne trop bien plutôt :)) car beaucoup de personnes ne tiennent pas à jour leur RIPE objects, le truc est peut être de filtrer et forcer les personnes à mettre à jour leur records RIPE, ce que j'ai fais un temps. J'ai une moulinette sous la main pour ceux qui veulent pour la construction de filter list. Le problème est le suivant : tu as un client transit BGP (client A) qui lui à plusieurs clients transit BGP également (clients 1, 2 et 3). Les clients 1, 2 et 3 ont leurs objets route à jour. Le client A recoit donc les routes de ces clients. Le client A va t'annoncer les routes des clients 1, 2 et 3 de façon légitime alors qu'il n'y aura pas d'objet route dans la base du ripe ayant comme origin AS-clientA pour les routes des clients 1, 2 et 3. Donc ce genre de filtre c'est bien mais un peu restrictif. Il faudrait à chaque fois aller plus loin en regardant : s'il n'y a pas d'objet route pour cet AS il faut regarder qui annonce cette route, si c'est l'AS en question : il faut que l'objet route soit créé. si c'est un autre AS, il faut vérifier que l'autre AS en question soit client transit de ton client, bref c'est gérable manuellement, mais automatiquement, bonjour le dev :-) Surtout que la base du ripe est une base déclarative pas super fiable parfois. Pour ta remarque sur le fait que tu n'aimes pas trop un max-prefix comme sécurité sur un peering, tu fais comment si t'as un gros peer qui t'envoie 3000 routes et qui peut varier assez régulièrement ? Bon généralement faut dire que les gens envoyant un nombre de route dans ces environs ne sont pas des boulets et n'envoient pas n'importe quoi non plus, je pense qu'on peut les faire confiance avec un max-prefix uniquement comme sécurité. -- Pierre-Yves -- David Ramahefason - [EMAIL PROTECTED]
Re: [FRnOG] BGP announces RFC1918
On 14/11/2007 08:16, David Ramahefason wrote: Ben on dit la même chose non ? Ok je n'ai pas précisé que pour les gros peers/Transit on étaient obligé de faire du max-préfix, mais en général les problèmes ne viennent pas d'eux, quoi que :p Le client A peut créer une AS-Macro non ?? ca sert a ca par exemple, mais je suis d'accord avec toi sur le fait que c'est très restrictif car beaucoup de peer n'ont pas leur RIPE objects à jour. David R. Oui effectivement ;-) Le point sur lequel je suis d'accord et sur lequel je fait la même chose que toi : je force...euh...non, plutôt je suggère mes clients de créer leurs objets routes (si ce n'est déjà fait) avant que je mette à jour ma prefix-list. Tant que l'objet route n'existe pas, je filtre et ne l'annonce pas la route. (Valable pour les clients directs voulant annoncer un nouveau prefix sur leur AS). -- Pierre-Yves --- Liste de diffusion du FRnOG http://www.frnog.org/
