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

Responder a