UOL faz isso tambem, do contrario teria que subir um roteador (mesmo que virtual) para cada ASN que esta dentro do IDC deles. Agora... por qu enão? Preguiça?
Juliano Em 24/10/2010 11:02, Herbert Faleiros 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
