Re: [FRnOG] BGP announces RFC1918
Hello, On Wed, 14 Nov 2007 08:16:25 +0100 David Ramahefason [EMAIL PROTECTED] 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 Du temps de ma vie Oleane, je prenais effectivement en compte les AS et AS-macro pour creer automatique des as-path-filter... Ca evite les gens qui s'improvisent transit sur des liens 2MBps ;) Si qq'un est interesse, je dois aussi pouvoir retrouver un bout de script de l'epoque... mais gare a la poussiere ! :) Paul --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] BGP announces RFC1918
Ah bin ca faisait longtemps qu'on avait pas eu de sujet de fond. Ca me semble en être un :) Discutons, discutons... En ce qui me concerne, je trouve assez irresponsable de pas documenter son routage dans un IRR... a mon sens, c'est le seul référenciel dispo et objectif. Pour notre core, on fait ceinture/bretelles: - Inbound ACLs Bogons + 1918, rafraichies selon convenance - outbount ACLs qui ne laissent sortir que les paquets qu'on source dans notre supernet - max-prefix Par contre, ce qu'on ne fait pas, c'est filtrer sur la base de préfixes IRR de l'AS-Set avec lequel on peere... j'ai peur que ca fasse trop d'entrées à scanner. Greg On Nov 13, 2007, at 10:34 PM, Michael Hallgren wrote: 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 [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
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] 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/
