Eu tenho clientes que já EXIGIRAM ter seus prefixos anuciados dentro do nosso ASN. Justificativa: "Como estamos aqui mesmo, você anuncia e faz uma rota para baixo. E assim nos livramos de ter que colocar um serviço BGP funcionando"
Abs Em 24 de outubro de 2010 11:02, Herbert Faleiros <[email protected]>escreveu: > Vamos fazer um pequeno exercício prático com um certo prefixo nacional > para analisar questões como as citadas pelo autor deste thread (IRR e > RPKI): > > # whois 189.84.64.0 | grep -E 'inetnum|aut-num|owner': > inetnum: 189.84.64/20 > aut-num: AS28365 > owner: Openline Internet Ltda > > Tem IRR com origem correta registrado (curiosamente um proxy, na base > da NTTCOM): > > # whois -h whois.radb.net 189.84.64.0/20 | \ > grep -E '^(route|origin|source)' | tr -s ' ' | \ > sed -r 's/(source.+)$/\1\n/g' > > route: 189.64.0.0/11 > origin: AS8167 > source: RADB > > route: 189.84.64.0/20 > origin: AS28365 > source: NTTCOM > > route: 189.84.64.0/20 > origin: AS28362 > source: NTTCOM > > route: 189.84.64.0/20 > origin: AS8167 > source: LEVEL3 > > route: 189.84.64.0/20 > origin: AS22356 > source: PEGASUS > > > Vamos reforçar o último registro: > > route: 189.84.64.0/20 > origin: AS22356 > source: PEGASUS > > Base da Abranet (Pegasus), mas o prefixo está com origem no ASN da > Durand! O AS não era da Openline? > > > Vamos então analisar alguns LG's para ver quem está anunciando esse > prefixo (PTTMetro São Paulo): > > [cut] > 22356 28182 > 200.219.130.5 from 200.219.130.253 (200.219.130.253) > Origin IGP, localpref 100, valid, external > Community: 26162:22356 > Last update: Sat Oct 23 14:50:10 2010 > [cut] > 28182 > 200.219.130.169 from 200.219.130.169 (200.170.83.118) > Origin IGP, localpref 100, valid, external, best > Last update: Sat Oct 23 14:50:00 2010 > [cut] > > Estranho, 28182 anunciando um prefixo que não é dele? Cadê o 28365 como > origem? > > Vamos então analisar outro LG (Algar/CTBC): > > * 189.84.64.0/20 B 170 150 100 >200.225.199.90 > 10429 27715 22356 28182 I > B 170 150 100 >200.225.199.90 > 10429 27715 22356 28182 I > > A origem continua no 28182. > > Mais um LG (SCW): > > >show bgp ipv4 unicast 189.84.64.0/20 > > BGP routing table entry for 189.84.64.0/20, version 12311119 > Paths: (3 available, best #2, table Default-IP-Routing-Table) > Advertised to update-groups: > 2 5 > 22356 28182, (received & used) > 200.219.130.5 from 200.219.130.254 (200.219.130.254) > Origin IGP, localpref 100, valid, external > Community: 26162:22356 > 22356 28182, (received & used) > 200.219.130.5 from 200.219.130.253 (200.219.130.253) > Origin IGP, localpref 100, valid, external, best > Community: 26162:22356 > 16735 10429 27715 22356 28182, (received & used) > 200.225.196.104 from 200.225.196.104 (200.225.196.104) > Origin IGP, localpref 100, valid, external > Community: 16735:63000 > > Mesmo resultado do LG da Algar/CTBC. > > Vamos adiante então, análise de RIBs de projetos como RIS e Route Views: > http://whois.scw.net.br/ris?query=189.84.64.0%2F20 > > 28182 anunciando um prefixo que não é dele... > > Para quem quiser olhar diretamente via RIS: > http://www.ris.ripe.net/dashboard/189.84.64.0 > > E (ainda) para quem quiser olhar diretamente para o Route Views: > > # dig 0.64.84.189.asn.routeviews.org txt +short > "28182" "189.84.64.0" "20" > > 28182 anunciando um prefixo que não é dele... > > > Conclusões: > > * 28365 é o ASN da Openline, 189.84.64.0/20 é um prefixo da Openline. > * 28182 é o ASN da TeleSA, aparentemente upstream do 28365, mas > 189.84.64.0/20 *não é* um prefixo da TeleSA. > * 28365 tem IRR registrado na Pegasus, mas com origem incorreta (ASN da > Durand). > * 28365 tem proxy com origem correta (NTTCOM). > * 28182 (TeleSA) está anunciando um prefixo que não é dele! Qual é > mesmo o nome que dão para isso? > > IRR não fez absolutamente nenhuma diferença aqui, muito menos alertou > alguém (que um terceiro está anunciando um prefixo alheio) ou ainda > preveniu que essa série de erros ocorressem. > > Reforço: IRR não validou nenhuma origem, IRR não alertou ninguém e IRR > não evitou que isso ocorresse! Na verdade nem perceberam ainda o > problema. > > RPKI, que evitaria esse tipo de coisas (e não o IRR), ainda não tem > implementação em produção em nenhum roteador conhecido (então ainda > não dá para validar a origem). > > O autor deste thread levantou ainda questões tais como orientar e > adotar boas práticas, mas como em casa de ferreiro o espeto sempre é > de madeira (para não dizer outra coisa), dá para ver que o buraco é > mais em baixo. > > De quem é mesmo o 28182? E o que dizer então daquele "route" na > Pegasus com origem no ASN da Durand? Por que o IRR não evirou que essa > série de erros ocorressem? Cadê o "alarme" de sequestro (já que o > 28365 tem IRR)? Porque o gestor da Pegasus não notou esse erro > grotesco em sua base (ainda mais em um de seus downstreams)? Porque a > TeleSA (o gestor da Pegasus é o dono da TeleSA) está anunciando um > prefixo que não é seu? Porque o IRR não teve nenhum papel (zero mesmo) > neste relato prático que estou reportando? > > Sim, tem que orientar e adotar boas práticas, mas isso tem que começar > dentro de casa. > > -- > Herbert > _______________________________________________ > GT-AS mailing list > [email protected] > http://lists.abranet.org.br/mailman/listinfo/gt-as >
_______________________________________________ GT-AS mailing list [email protected] http://lists.abranet.org.br/mailman/listinfo/gt-as
