Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
On Wed, 2019-11-13 at 12:05 +0100, Radu-Adrian Feurdean wrote: > On Tue, Nov 12, 2019, at 16:16, Guillaume Barrot wrote: > > Donc pour résumer, annoncer des /24 parce que c'est plus simple, > > c'est le mal, mais maintenant que le RIPE ne va livrer que des /22 > > sous la forme de multiples /24 et /23, bon ok, c'est moche mais là > > on a pas le choix. > > C'est exactement ca. > > En gardant ta logique on arrive a des gens comme ca: > http://www.cidr-report.org/cgi-bin/as-report?as=AS39891=2.0 > > Donc je persiste, SI on a un besoin justifie pour desaggreger, il > faut penser avant le faire. Je plussoie. Ce n'est pas parce qu'on peut avoir des routeurs avec de grosses capacités, qu'il faut s'en foutre d'optimiser les choses. C'est avec ce genre de considérations, tu te retrouves avec une webapp slack ou Twitter qui te prend 12Go de RAM, et autres joyeusetés. On s'en fout, on a de la ressource, donc on n'optimise pas ? > > Du coup, il faut pas le faire pour les pauvres mecs qui ont encore > > des 6500-SUP7203BXL, mais si le RIPE te livre des /23-/24, là tu > > peux, et les > > Ce n'est pas le probleme aujourd'hui avec les 6500-SUP720-3BXL, c'est > le probleme demain avec d'autres equipements qui supportent 1M, 1.5M > voire meme 2M routes. > Et pour aller encore plus loin, en IPv6 ca se transpose en /48, et > la, ca risque d'etre la fete si tous les cretins se metent a annoncer > leurs /32-/29 en tant que /48. Re plussoiement. > > J'ai bon ? > > En le relisant, y a que moi qui trouve que ça devient du grand > > n'imp les échanges crypto-communistes ici ou bien ? > > Absolutement pas. > C'est comme proner le fait qu'uriner ou laisser son chien faire ses > autres besoins dans la rue c'est OK. Ne pas faire de la merde sur internet, ca devrait être une obligation. Et ce n'est pas un échange crypto-communiste, c'est juste du bon sens. Un peu comme: "Il ne faut pas prendre les gens pour des cons, mais ne jamais oublier qu'il est grandement possible qu'ils le soient". Clément --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
On Tue, Nov 12, 2019, at 16:16, Guillaume Barrot wrote: > Donc pour résumer, annoncer des /24 parce que c'est plus simple, c'est le > mal, mais maintenant que le RIPE ne va livrer que des /22 sous la forme de > multiples /24 et /23, bon ok, c'est moche mais là on a pas le choix. C'est exactement ca. En gardant ta logique on arrive a des gens comme ca: http://www.cidr-report.org/cgi-bin/as-report?as=AS39891=2.0 Donc je persiste, SI on a un besoin justifie pour desaggreger, il faut penser avant le faire. > Du coup, il faut pas le faire pour les pauvres mecs qui ont encore des > 6500-SUP7203BXL, mais si le RIPE te livre des /23-/24, là tu peux, et les Ce n'est pas le probleme aujourd'hui avec les 6500-SUP720-3BXL, c'est le probleme demain avec d'autres equipements qui supportent 1M, 1.5M voire meme 2M routes. Et pour aller encore plus loin, en IPv6 ca se transpose en /48, et la, ca risque d'etre la fete si tous les cretins se metent a annoncer leurs /32-/29 en tant que /48. > J'ai bon ? > En le relisant, y a que moi qui trouve que ça devient du grand n'imp les > échanges crypto-communistes ici ou bien ? Absolutement pas. C'est comme proner le fait qu'uriner ou laisser son chien faire ses autres besoins dans la rue c'est OK. -- R-A.F. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
> Guillaume Barrot a écrit : > mais si tu montes en 2019 un SP avec des équipements qui tiennent 750k > routes, là c'est bon, faut pas changer de métier. Absolument ! Darwin n'est pas loin, quelqu'un d'autre récupèrera les clients plus tard ! Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
Donc pour résumer, annoncer des /24 parce que c'est plus simple, c'est le mal, mais maintenant que le RIPE ne va livrer que des /22 sous la forme de multiples /24 et /23, bon ok, c'est moche mais là on a pas le choix. Du coup, il faut pas le faire pour les pauvres mecs qui ont encore des 6500-SUP7203BXL, mais si le RIPE te livre des /23-/24, là tu peux, et les 6500, ils prendront une default chez un transitaire pour ça. Et si tu le fais alors que tu aurais pu éviter de le faire, faut changer de métier, mais si tu montes en 2019 un SP avec des équipements qui tiennent 750k routes, là c'est bon, faut pas changer de métier. J'ai bon ? En le relisant, y a que moi qui trouve que ça devient du grand n'imp les échanges crypto-communistes ici ou bien ? Le lun. 11 nov. 2019 à 09:01, Radu-Adrian Feurdean < fr...@radu-adrian.feurdean.net> a écrit : > On Sun, Nov 10, 2019, at 19:51, Michel Py wrote: > > Sans vouloir entrer dans le débat d'annoncer des spécifiques (il y a > > des cas ou c'est justifié et d'autres non) > > D'accord, sauf que le faire en /24, juste parce-que c'est plus simple (ce > qui etait le cas cette fois), faut changer de metier. > -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
On Sun, Nov 10, 2019, at 19:51, Michel Py wrote: > Sans vouloir entrer dans le débat d'annoncer des spécifiques (il y a > des cas ou c'est justifié et d'autres non) D'accord, sauf que le faire en /24, juste parce-que c'est plus simple (ce qui etait le cas cette fois), faut changer de metier. --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
> Radu-Adrian Feurdean a écrit : Sans vouloir entrer dans le débat d'annoncer des spécifiques (il y a des cas ou c'est justifié et d'autres non) > Pareil, quand sun un investissement a 3-5 ans tu dois serieusement penser > lesquels des modeles va tenir - le 1M routes (certainement pas), 1M c'est en 2023 ou 2024, pour acheter aujourd'hui faut être fou. Si c'est en prod, le faire durer aussi longtemps que possible. > le 1.5M routes, le 2M routes ou faut-il aller sur un modele a 3-4M routes 1,5M ou 2M routes c'est un investissement viable. 1,5M c'est 10 ans de vie de plus, donc raisonnable d'investir dedans. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
On Sat, Nov 9, 2019, at 01:49, Guillaume Barrot wrote: > On est en 2019 les gars, avoir du respect pour les mecs qui ont des > routeurs au taquet à 800k routes, c'est très surfait. C'est avoir du respect vers tout le monde. Le probleme c'est qu'il n'est pas un cas isole, il y a des milliers de gens cimme ca. Dont certains qui administrent des /16, voir plus. Alors quand tu te trouves en face avec des de-cerebres qui annoncent plus de 1000 routes (100% en /24) pour moins de 20 aggregats (allocations du RIR local), tu commences a moins rire. Pareil, quand sun un investissement a 3-5 ans tu dois serieusement penser lesquels des modeles va tenir - le 1M routes (certainement pas), le 1.5M routes, le 2M routes ou faut-il aller sur un modele a 3-4M routes - tu commences a traiter de noms pas avouables en public tous les gens qui desaggregent en /24 juste parce-qu'intellectuellement ca demande le moins d'effort. > C'est le vrai monde ici, et le vrai monde, il route des paquets, il passe > pas 1h30 à regarder converger son Mikrotik... Donc tu proposes de tout casser en /24, parce-que cote routage ca ne change rien ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
On est en 2019 les gars, avoir du respect pour les mecs qui ont des routeurs au taquet à 800k routes, c'est très surfait. C'est le vrai monde ici, et le vrai monde, il route des paquets, il passe pas 1h30 à regarder converger son Mikrotik... Le jeu. 7 nov. 2019 à 18:49, Clement Cavadore a écrit : > On Thu, 2019-11-07 at 18:19 +0100, David Ponzone wrote: > > Purée, on vient de te dire de pas faire ça.T’as dû faire planter > > quelques 6500 en manque de RAM avec tes 4 routes en plus :) > > Surtout que, même si c'est déjà deux de trop, annoncer deux /23 aurait > été déjà un peu moins irrespectueux des autres, pour le même résultat. > On a déjà trop de more specific avec le même origin AS sur la DFZ, ce > n'est pas une raison pour en rajouter... > > -- > Clément Cavadore > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Cordialement, Guillaume BARROT --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
On 07/11/2019 19:36, David Ponzone wrote: > Sur Microtik, ça se script easy, sur Cisco ou autre, je sais pas. Je pense que ça doit pouvoir se faire avec des EEM. -- Alarig --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
Bonsoir, Un peu dans le même cas que toi, j'avais à l'époque limité le trafic sur le Tiers 2 en lui annonçant plusieurs communautés qui servaient chacune à modifier la localpref chez ses transitaires Tiers 1, afin que ceux-ci ne lui envoient pas le trafic. Par exemple : 3356:80 6453:80 5511:80 174:70. Après je ne sais pas trop dans quelle mesure c'est applicable à SFR, par exemple si il est possible que SFR supprime ou remplace ces communautés avant de réannoncer. Pour que les autres Tiers 2 n'envoient pas via leur peering SFR il y a peut-être moyen de faire en sorte que SFR n'annonce pas tes routes sur les IX/PNI, soit via communautés soit en négociant, mais j'imagine que c'est peu probable voir même un peu crade. Romain Le 07/11/2019 à 17:51, Eddy Minet a écrit : Merci à tous pour vos réponses. Donc si je comprends bien SFR aura toujours une localpref plus forte ? Pour répondre à Michel je prépende 2 fois, et pour le test j'ai aussi une communauté qui fait un double prepend au niveau de sfr. Donc les chemins via SFR terminent tous par SFRx3 et MON-ASx3. Et pour illustrer le problème, ci-dessous un exemple de show bgp sur le looking glass de Claranet France ou on voit qu'effectivement les chemin SFR on un localpref de 700 et Cogent un localpref de 500 et le best path est celui par SFR qui a 2 fois plus de sauts : Paths: (5 available, best #3) Advertised IPv4 Unicast paths to update-groups (with more than one peer): 0.2 0.10 Advertised IPv4 Unicast paths to peers (in unique update groups): 212.43.193.119 212.43.193.78 Path #1: Received by speaker 0 Not advertised to any peer 3356 174 210156 212.43.193.73 (metric 10) from 62.240.250.248 (212.43.193.73) Origin IGP, metric 0, localpref 500, valid, internal, group-best, add-path Received Path ID 1, Local Path ID 6, version 1158846854 Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 Originator: 212.43.193.73, Cluster list: 0.0.0.33 Path #2: Received by speaker 0 Advertised IPv4 Unicast paths to update-groups (with more than one peer): 0.10 Advertised IPv4 Unicast paths to peers (in unique update groups): 212.43.193.78 6453 174 210156 80.231.154.125 from 80.231.154.125 (66.110.10.96) Origin IGP, metric 0, localpref 500, valid, external, group-best, add-path Received Path ID 0, Local Path ID 13, version 1166475609 Community: 8975:507 8975:599 8975:12000 Origin-AS validity: not-found Path #3: Received by speaker 0 Advertised IPv4 Unicast paths to update-groups (with more than one peer): 0.2 0.10 Advertised IPv4 Unicast paths to peers (in unique update groups): 212.43.193.119 212.43.193.78 15557 15557 15557 210156 210156 210156 195.42.144.66 from 195.42.144.66 (93.17.144.218) Origin IGP, localpref 700, valid, external, best, group-best Received Path ID 0, Local Path ID 1, version 1166475609 Community: 8975:712 8975:799 Origin-AS validity: not-found Path #4: Received by speaker 0 Not advertised to any peer 3356 174 210156 212.43.193.73 (metric 10) from 212.43.193.78 (212.43.193.73) Origin IGP, metric 0, localpref 500, valid, internal Received Path ID 4, Local Path ID 0, version 0 Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 Originator: 212.43.193.73, Cluster list: 0.0.0.33 Path #5: Received by speaker 0 Not advertised to any peer 3356 174 210156 212.43.193.73 (metric 10) from 212.43.193.136 (212.43.193.73) Origin IGP, metric 0, localpref 500, valid, internal Received Path ID 1, Local Path ID 0, version 0 Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 Originator: 212.43.193.73, Cluster list: 0.0.0.33 Je précise aussi qu'effectivement, à notre echelle, le choix du transitaire se fait bcp plus sur le tarif que sur la matière dont il est constitué ;-) J'ignorais en tout cas qu'une préférence pouvait exister entre les tiers1 et tiers2. Du coup va falloir que je fasse un choix qui ne me conviendra forcément qu'à moitié avec la solution actuelle. Eddy -Message d'origine- De : frnog-requ...@frnog.org De la part de Michel Py Envoyé : jeudi 7 novembre 2019 15:52 À : Eddy Minet ; frnog-t...@frnog.org Objet : [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup Eddy Minet a écrit : Je suis en train de me casser la tête pour avoir un peer BGP SFR en rôle de « backup » et malgré le prépend qui est fait à la fois sur notre AS et sur celui de SFR j’ai toujours un gros pourcentage du traffic dessus. Tu prépends combien de fois ? Michel. --- 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] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
> David Ponzone a écrit : > sur Cisco ou autre, je sais pas. On peut avoir un bgp network > dependant d’un track sur Cisco ? J’ai la flemme de chercher. Avec EEM et tclsh on fait pas mal de choses. C'est un peu prise de tête quand on en fait pas souvent, mais c'est assez puissant. En plus de tickle shell il y a aussi les commandes de config. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
Un bête role Ansible sur une VM, avec une probe externe qui ping des IP qui vont bien dans ton réseau et qui trigger pour lancer les commandes kivonbien, ça devrait CloudSDWaniser comme il faut, je pense. Hugues AS57199 - AS50628 > On 7 Nov 2019, at 19:36, David Ponzone wrote: > > >> Le 7 nov. 2019 à 18:52, Hugues Voiturier a écrit >> : >> >> +1 >> >> Faudrait vraiment un permis d’être sur la DFZ, on en arrive à des trucs >> absurdes à base de désagrégation pour faire du failover. >> >> D’ailleurs, ça ne marchera juste pas, puisqu’Eddy dit qu’il veut éviter un >> impact en cas de coupure de son Backbone. >> >> Sauf que si tout rentre par Cogent, ça blackholera tout pareil… >> >> Du coup, inefficace, irrespectueux, le tout pour payer moins cher, c’est >> beau :) >> > > Faudrait une sorte de SDN qui fasse: > Si session iBGP tombe alors annonce X.X.X.X/23 en plus du /22 > Sur Microtik, ça se script easy, sur Cisco ou autre, je sais pas. > On peut avoir un bgp network dépendant d’un track sur Cisco ? J’ai la flemme > de chercher. > > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
> Le 7 nov. 2019 à 18:52, Hugues Voiturier a écrit : > > +1 > > Faudrait vraiment un permis d’être sur la DFZ, on en arrive à des trucs > absurdes à base de désagrégation pour faire du failover. > > D’ailleurs, ça ne marchera juste pas, puisqu’Eddy dit qu’il veut éviter un > impact en cas de coupure de son Backbone. > > Sauf que si tout rentre par Cogent, ça blackholera tout pareil… > > Du coup, inefficace, irrespectueux, le tout pour payer moins cher, c’est beau > :) > Faudrait une sorte de SDN qui fasse: Si session iBGP tombe alors annonce X.X.X.X/23 en plus du /22 Sur Microtik, ça se script easy, sur Cisco ou autre, je sais pas. On peut avoir un bgp network dépendant d’un track sur Cisco ? J’ai la flemme de chercher. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
+1 Faudrait vraiment un permis d’être sur la DFZ, on en arrive à des trucs absurdes à base de désagrégation pour faire du failover. D’ailleurs, ça ne marchera juste pas, puisqu’Eddy dit qu’il veut éviter un impact en cas de coupure de son Backbone. Sauf que si tout rentre par Cogent, ça blackholera tout pareil… Du coup, inefficace, irrespectueux, le tout pour payer moins cher, c’est beau :) Hugues AS57199 - AS50628 > On 7 Nov 2019, at 18:48, Clement Cavadore wrote: > > On Thu, 2019-11-07 at 18:19 +0100, David Ponzone wrote: >> Purée, on vient de te dire de pas faire ça.T’as dû faire planter >> quelques 6500 en manque de RAM avec tes 4 routes en plus :) > > Surtout que, même si c'est déjà deux de trop, annoncer deux /23 aurait > été déjà un peu moins irrespectueux des autres, pour le même résultat. > On a déjà trop de more specific avec le même origin AS sur la DFZ, ce > n'est pas une raison pour en rajouter... > > -- > Clément Cavadore > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
On Thu, 2019-11-07 at 18:19 +0100, David Ponzone wrote: > Purée, on vient de te dire de pas faire ça.T’as dû faire planter > quelques 6500 en manque de RAM avec tes 4 routes en plus :) Surtout que, même si c'est déjà deux de trop, annoncer deux /23 aurait été déjà un peu moins irrespectueux des autres, pour le même résultat. On a déjà trop de more specific avec le même origin AS sur la DFZ, ce n'est pas une raison pour en rajouter... -- Clément Cavadore --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
> Le 7 nov. 2019 à 18:05, Eddy Minet a écrit : > > Merci pour cette réponse je comprends mieux le principe. > > Je viens de mettre l'annonce du /22 sur SFR et les /24 sur Cogent. Du coup > c'est plus radical. > Purée, on vient de te dire de pas faire ça.T’as dû faire planter quelques 6500 en manque de RAM avec tes 4 routes en plus :) --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
Merci pour cette réponse je comprends mieux le principe. Je viens de mettre l'annonce du /22 sur SFR et les /24 sur Cogent. Du coup c'est plus radical. Eddy -Message d'origine- De : David Ponzone Envoyé : jeudi 7 novembre 2019 18:00 À : Eddy Minet Cc : Michel Py ; frnog-t...@frnog.org Objet : Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup > Le 7 nov. 2019 à 17:51, Eddy Minet a écrit : > > Merci à tous pour vos réponses. > > Donc si je comprends bien SFR aura toujours une localpref plus forte ? > > Pour répondre à Michel je prépende 2 fois, et pour le test j'ai aussi une > communauté qui fait un double prepend au niveau de sfr. > Donc les chemins via SFR terminent tous par SFRx3 et MON-ASx3. > > Et pour illustrer le problème, ci-dessous un exemple de show bgp sur le > looking glass de Claranet France ou on voit qu'effectivement les chemin SFR > on un localpref de 700 et Cogent un localpref de 500 et le best path est > celui par SFR qui a 2 fois plus de sauts : > > Paths: (5 available, best #3) > Advertised IPv4 Unicast paths to update-groups (with more than one peer): >0.2 0.10 > Advertised IPv4 Unicast paths to peers (in unique update groups): >212.43.193.119 212.43.193.78 > Path #1: Received by speaker 0 > Not advertised to any peer > 3356 174 210156 >212.43.193.73 (metric 10) from 62.240.250.248 (212.43.193.73) > Origin IGP, metric 0, localpref 500, valid, internal, group-best, > add-path > Received Path ID 1, Local Path ID 6, version 1158846854 > Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 > Originator: 212.43.193.73, Cluster list: 0.0.0.33 Path #2: > Received by speaker 0 Advertised IPv4 Unicast paths to update-groups > (with more than one peer): >0.10 > Advertised IPv4 Unicast paths to peers (in unique update groups): >212.43.193.78 > 6453 174 210156 >80.231.154.125 from 80.231.154.125 (66.110.10.96) > Origin IGP, metric 0, localpref 500, valid, external, group-best, > add-path > Received Path ID 0, Local Path ID 13, version 1166475609 > Community: 8975:507 8975:599 8975:12000 > Origin-AS validity: not-found > Path #3: Received by speaker 0 > Advertised IPv4 Unicast paths to update-groups (with more than one peer): >0.2 0.10 > Advertised IPv4 Unicast paths to peers (in unique update groups): >212.43.193.119 212.43.193.78 > 15557 15557 15557 210156 210156 210156 >195.42.144.66 from 195.42.144.66 (93.17.144.218) > Origin IGP, localpref 700, valid, external, best, group-best > Received Path ID 0, Local Path ID 1, version 1166475609 > Community: 8975:712 8975:799 > Origin-AS validity: not-found > Path #4: Received by speaker 0 > Not advertised to any peer > 3356 174 210156 >212.43.193.73 (metric 10) from 212.43.193.78 (212.43.193.73) > Origin IGP, metric 0, localpref 500, valid, internal > Received Path ID 4, Local Path ID 0, version 0 > Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 > Originator: 212.43.193.73, Cluster list: 0.0.0.33 Path #5: > Received by speaker 0 Not advertised to any peer > 3356 174 210156 >212.43.193.73 (metric 10) from 212.43.193.136 (212.43.193.73) > Origin IGP, metric 0, localpref 500, valid, internal > Received Path ID 1, Local Path ID 0, version 0 > Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 > Originator: 212.43.193.73, Cluster list: 0.0.0.33 Moi j’ai regardé chez Zayo et Orange, et je vois bien tes routes par Cogent. > Je précise aussi qu'effectivement, à notre echelle, le choix du > transitaire se fait bcp plus sur le tarif que sur la matière dont il est > constitué ;-) J'ignorais en tout cas qu'une préférence pouvait exister entre > les tiers1 et tiers2. En fait un Tiers-1, c’est un gros-gros international. Il a pas de transit parce qu’il pèse à lui tout seul au moins 5-10% d’Internet, donc il peer (PNI) avec les autres Tiers-1 et les gros CDN. Il gère ses PNI proprement pour jamais saturer, et il a rien à cirer de peerer localement avec des Tiers-2, parce que comme ça le club des Tiers-1 tient le reste du monde par les roubignoles. Ton Tiers-2 lui, il aime pas payer son transit, et les autres pareil, donc ils peerent au max localement et utilisent ces routes là en priorité, et comme ton traffic est certainement local à 90-95%, ben tu passes par là à chaque fois. En fait, tu serais certainement mieux avec 2 Tiers-2, mais c’est plus cher :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
> Le 7 nov. 2019 à 17:51, Eddy Minet a écrit : > > Merci à tous pour vos réponses. > > Donc si je comprends bien SFR aura toujours une localpref plus forte ? > > Pour répondre à Michel je prépende 2 fois, et pour le test j'ai aussi une > communauté qui fait un double prepend au niveau de sfr. > Donc les chemins via SFR terminent tous par SFRx3 et MON-ASx3. > > Et pour illustrer le problème, ci-dessous un exemple de show bgp sur le > looking glass de Claranet France ou on voit qu'effectivement les chemin SFR > on un localpref de 700 et Cogent un localpref de 500 et le best path est > celui par SFR qui a 2 fois plus de sauts : > > Paths: (5 available, best #3) > Advertised IPv4 Unicast paths to update-groups (with more than one peer): >0.2 0.10 > Advertised IPv4 Unicast paths to peers (in unique update groups): >212.43.193.119 212.43.193.78 > Path #1: Received by speaker 0 > Not advertised to any peer > 3356 174 210156 >212.43.193.73 (metric 10) from 62.240.250.248 (212.43.193.73) > Origin IGP, metric 0, localpref 500, valid, internal, group-best, > add-path > Received Path ID 1, Local Path ID 6, version 1158846854 > Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 > Originator: 212.43.193.73, Cluster list: 0.0.0.33 > Path #2: Received by speaker 0 > Advertised IPv4 Unicast paths to update-groups (with more than one peer): >0.10 > Advertised IPv4 Unicast paths to peers (in unique update groups): >212.43.193.78 > 6453 174 210156 >80.231.154.125 from 80.231.154.125 (66.110.10.96) > Origin IGP, metric 0, localpref 500, valid, external, group-best, > add-path > Received Path ID 0, Local Path ID 13, version 1166475609 > Community: 8975:507 8975:599 8975:12000 > Origin-AS validity: not-found > Path #3: Received by speaker 0 > Advertised IPv4 Unicast paths to update-groups (with more than one peer): >0.2 0.10 > Advertised IPv4 Unicast paths to peers (in unique update groups): >212.43.193.119 212.43.193.78 > 15557 15557 15557 210156 210156 210156 >195.42.144.66 from 195.42.144.66 (93.17.144.218) > Origin IGP, localpref 700, valid, external, best, group-best > Received Path ID 0, Local Path ID 1, version 1166475609 > Community: 8975:712 8975:799 > Origin-AS validity: not-found > Path #4: Received by speaker 0 > Not advertised to any peer > 3356 174 210156 >212.43.193.73 (metric 10) from 212.43.193.78 (212.43.193.73) > Origin IGP, metric 0, localpref 500, valid, internal > Received Path ID 4, Local Path ID 0, version 0 > Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 > Originator: 212.43.193.73, Cluster list: 0.0.0.33 > Path #5: Received by speaker 0 > Not advertised to any peer > 3356 174 210156 >212.43.193.73 (metric 10) from 212.43.193.136 (212.43.193.73) > Origin IGP, metric 0, localpref 500, valid, internal > Received Path ID 1, Local Path ID 0, version 0 > Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 > Originator: 212.43.193.73, Cluster list: 0.0.0.33 Moi j’ai regardé chez Zayo et Orange, et je vois bien tes routes par Cogent. > Je précise aussi qu'effectivement, à notre echelle, le choix du transitaire > se fait bcp plus sur le tarif que sur la matière dont il est constitué ;-) > J'ignorais en tout cas qu'une préférence pouvait exister entre les tiers1 et > tiers2. En fait un Tiers-1, c’est un gros-gros international. Il a pas de transit parce qu’il pèse à lui tout seul au moins 5-10% d’Internet, donc il peer (PNI) avec les autres Tiers-1 et les gros CDN. Il gère ses PNI proprement pour jamais saturer, et il a rien à cirer de peerer localement avec des Tiers-2, parce que comme ça le club des Tiers-1 tient le reste du monde par les roubignoles. Ton Tiers-2 lui, il aime pas payer son transit, et les autres pareil, donc ils peerent au max localement et utilisent ces routes là en priorité, et comme ton traffic est certainement local à 90-95%, ben tu passes par là à chaque fois. En fait, tu serais certainement mieux avec 2 Tiers-2, mais c’est plus cher :) --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
La localpref étant plus forte que le BGP Prepend, tous les gens qui reçoivent ton préfixe via un Peering (public ou privé) avec SFR ou un de ses transitaires préfèreront passer par ce lien plutôt que par Cogent. Donc, pour résumer, tu vas avoir du mal à utiliser SFR en backup, parce que la DFZ n’est pas faite pour ça. Hugues AS57199 - AS50628 > On 7 Nov 2019, at 17:51, Eddy Minet wrote: > > Merci à tous pour vos réponses. > > Donc si je comprends bien SFR aura toujours une localpref plus forte ? > > Pour répondre à Michel je prépende 2 fois, et pour le test j'ai aussi une > communauté qui fait un double prepend au niveau de sfr. > Donc les chemins via SFR terminent tous par SFRx3 et MON-ASx3. > > Et pour illustrer le problème, ci-dessous un exemple de show bgp sur le > looking glass de Claranet France ou on voit qu'effectivement les chemin SFR > on un localpref de 700 et Cogent un localpref de 500 et le best path est > celui par SFR qui a 2 fois plus de sauts : > > Paths: (5 available, best #3) > Advertised IPv4 Unicast paths to update-groups (with more than one peer): >0.2 0.10 > Advertised IPv4 Unicast paths to peers (in unique update groups): >212.43.193.119 212.43.193.78 > Path #1: Received by speaker 0 > Not advertised to any peer > 3356 174 210156 >212.43.193.73 (metric 10) from 62.240.250.248 (212.43.193.73) > Origin IGP, metric 0, localpref 500, valid, internal, group-best, > add-path > Received Path ID 1, Local Path ID 6, version 1158846854 > Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 > Originator: 212.43.193.73, Cluster list: 0.0.0.33 > Path #2: Received by speaker 0 > Advertised IPv4 Unicast paths to update-groups (with more than one peer): >0.10 > Advertised IPv4 Unicast paths to peers (in unique update groups): >212.43.193.78 > 6453 174 210156 >80.231.154.125 from 80.231.154.125 (66.110.10.96) > Origin IGP, metric 0, localpref 500, valid, external, group-best, > add-path > Received Path ID 0, Local Path ID 13, version 1166475609 > Community: 8975:507 8975:599 8975:12000 > Origin-AS validity: not-found > Path #3: Received by speaker 0 > Advertised IPv4 Unicast paths to update-groups (with more than one peer): >0.2 0.10 > Advertised IPv4 Unicast paths to peers (in unique update groups): >212.43.193.119 212.43.193.78 > 15557 15557 15557 210156 210156 210156 >195.42.144.66 from 195.42.144.66 (93.17.144.218) > Origin IGP, localpref 700, valid, external, best, group-best > Received Path ID 0, Local Path ID 1, version 1166475609 > Community: 8975:712 8975:799 > Origin-AS validity: not-found > Path #4: Received by speaker 0 > Not advertised to any peer > 3356 174 210156 >212.43.193.73 (metric 10) from 212.43.193.78 (212.43.193.73) > Origin IGP, metric 0, localpref 500, valid, internal > Received Path ID 4, Local Path ID 0, version 0 > Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 > Originator: 212.43.193.73, Cluster list: 0.0.0.33 > Path #5: Received by speaker 0 > Not advertised to any peer > 3356 174 210156 >212.43.193.73 (metric 10) from 212.43.193.136 (212.43.193.73) > Origin IGP, metric 0, localpref 500, valid, internal > Received Path ID 1, Local Path ID 0, version 0 > Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 > Originator: 212.43.193.73, Cluster list: 0.0.0.33 > > Je précise aussi qu'effectivement, à notre echelle, le choix du transitaire > se fait bcp plus sur le tarif que sur la matière dont il est constitué ;-) > J'ignorais en tout cas qu'une préférence pouvait exister entre les tiers1 et > tiers2. > > Du coup va falloir que je fasse un choix qui ne me conviendra forcément qu'à > moitié avec la solution actuelle. > > Eddy > > -----Message d'origine- > De : frnog-requ...@frnog.org De la part de Michel Py > Envoyé : jeudi 7 novembre 2019 15:52 > À : Eddy Minet ; frnog-t...@frnog.org > Objet : [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en > backup > >> Eddy Minet a écrit : >> Je suis en train de me casser la tête pour avoir un peer BGP SFR en >> rôle de « backup » et malgré le prépend qui est fait à la fois sur notre AS >> et sur celui de SFR j’ai toujours un gros pourcentage du traffic dessus. > > Tu prépends combien de fois ? > > Michel. > > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ > > --- > Liste de diffusion du FRnOG > http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
Merci à tous pour vos réponses. Donc si je comprends bien SFR aura toujours une localpref plus forte ? Pour répondre à Michel je prépende 2 fois, et pour le test j'ai aussi une communauté qui fait un double prepend au niveau de sfr. Donc les chemins via SFR terminent tous par SFRx3 et MON-ASx3. Et pour illustrer le problème, ci-dessous un exemple de show bgp sur le looking glass de Claranet France ou on voit qu'effectivement les chemin SFR on un localpref de 700 et Cogent un localpref de 500 et le best path est celui par SFR qui a 2 fois plus de sauts : Paths: (5 available, best #3) Advertised IPv4 Unicast paths to update-groups (with more than one peer): 0.2 0.10 Advertised IPv4 Unicast paths to peers (in unique update groups): 212.43.193.119 212.43.193.78 Path #1: Received by speaker 0 Not advertised to any peer 3356 174 210156 212.43.193.73 (metric 10) from 62.240.250.248 (212.43.193.73) Origin IGP, metric 0, localpref 500, valid, internal, group-best, add-path Received Path ID 1, Local Path ID 6, version 1158846854 Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 Originator: 212.43.193.73, Cluster list: 0.0.0.33 Path #2: Received by speaker 0 Advertised IPv4 Unicast paths to update-groups (with more than one peer): 0.10 Advertised IPv4 Unicast paths to peers (in unique update groups): 212.43.193.78 6453 174 210156 80.231.154.125 from 80.231.154.125 (66.110.10.96) Origin IGP, metric 0, localpref 500, valid, external, group-best, add-path Received Path ID 0, Local Path ID 13, version 1166475609 Community: 8975:507 8975:599 8975:12000 Origin-AS validity: not-found Path #3: Received by speaker 0 Advertised IPv4 Unicast paths to update-groups (with more than one peer): 0.2 0.10 Advertised IPv4 Unicast paths to peers (in unique update groups): 212.43.193.119 212.43.193.78 15557 15557 15557 210156 210156 210156 195.42.144.66 from 195.42.144.66 (93.17.144.218) Origin IGP, localpref 700, valid, external, best, group-best Received Path ID 0, Local Path ID 1, version 1166475609 Community: 8975:712 8975:799 Origin-AS validity: not-found Path #4: Received by speaker 0 Not advertised to any peer 3356 174 210156 212.43.193.73 (metric 10) from 212.43.193.78 (212.43.193.73) Origin IGP, metric 0, localpref 500, valid, internal Received Path ID 4, Local Path ID 0, version 0 Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 Originator: 212.43.193.73, Cluster list: 0.0.0.33 Path #5: Received by speaker 0 Not advertised to any peer 3356 174 210156 212.43.193.73 (metric 10) from 212.43.193.136 (212.43.193.73) Origin IGP, metric 0, localpref 500, valid, internal Received Path ID 1, Local Path ID 0, version 0 Community: 3356:2 3356:86 3356:502 3356:666 3356:2066 8975:515 8975:599 Originator: 212.43.193.73, Cluster list: 0.0.0.33 Je précise aussi qu'effectivement, à notre echelle, le choix du transitaire se fait bcp plus sur le tarif que sur la matière dont il est constitué ;-) J'ignorais en tout cas qu'une préférence pouvait exister entre les tiers1 et tiers2. Du coup va falloir que je fasse un choix qui ne me conviendra forcément qu'à moitié avec la solution actuelle. Eddy -Message d'origine- De : frnog-requ...@frnog.org De la part de Michel Py Envoyé : jeudi 7 novembre 2019 15:52 À : Eddy Minet ; frnog-t...@frnog.org Objet : [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup > Eddy Minet a écrit : > Je suis en train de me casser la tête pour avoir un peer BGP SFR en > rôle de « backup » et malgré le prépend qui est fait à la fois sur notre AS > et sur celui de SFR j’ai toujours un gros pourcentage du traffic dessus. Tu prépends combien de fois ? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
On 07/11/2019 15:52, Michel Py wrote: > Tu prépends combien de fois ? Il aura beau prependé autant de fois qu’il veut, vu que SFR fait du peering, la local-pref sera forcément supérieure. -- Alarig --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] RE: Multihoming BGP avec COGENT en principal et SFR en backup
> Eddy Minet a écrit : > Je suis en train de me casser la tête pour avoir un peer BGP SFR en rôle de « > backup » et malgré le prépend qui > est fait à la fois sur notre AS et sur celui de SFR j’ai toujours un gros > pourcentage du traffic dessus. Tu prépends combien de fois ? Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
