O que faz: mostra a foto atual do ASN — identidade (nome, numero, maintainers, tags) e um resumo da Higiene. E somente leitura: a edicao fica no painel Cadastro e o detalhe dos checks no painel Operacao.

Por que importa: e a tela de entrada para conferir, num relance, quem e o ASN e se ele esta saudavel, antes de mergulhar em cada modulo.

Ganho de governanca: um ponto unico e confiavel de consulta rapida, sem risco de editar algo sem querer.

O que faz: cria ou edita o registro local do ASN — identidade, maintainers (mntner) e tags. E a fonte de verdade local que alimenta os checks de Higiene e os demais modulos.

Por que importa: dado consistente aqui (nome certo, maintainer certo) eleva o score e evita retrabalho; dado errado se propaga para IRR, PeeringDB e relatorios.

Ganho de governanca: um cadastro unico e rastreavel, base para automatizar o resto com seguranca.

O que e: um placar de 0 a 100% que mede o quanto o ASN esta "em ordem". Ele soma varios checks objetivos sobre inventario, contatos, IRR, RPKI, PeeringDB e GeoFeed. Nao e nota de prova — e um checklist vivo de conformidade.

Como o placar e calculado: cada check recebe um estado, e o score e a porcentagem de checks validos sobre o total (hoje 17 checks em 6 modulos, todos com o mesmo peso). Subir o score = transformar amarelo e vermelho em verde.

Os tres estados (a parte que mais importa):

• valid (verde): comprovado e conforme — conta para o score.
• needs review (amarelo): pendencia — falta preencher ou confirmar. Nao e erro, mas nao pontua.
• invalid (vermelho): ausente ou em conflito — e o que derruba o score e o que voce ataca primeiro.

O que cada modulo verifica (e por que importa):

• Inventario: o ASN existe na base local — a ancora de todo o resto.
• Contatos (tecnico, abuse, NOC, peering): quem e acionado em incidente ou abuso. Abuse desatualizado = reclamacao que nunca chega a voce.
• IRR (source, AS-SET, aut-num, objetos RPKI invalidos): seus upstreams montam o filtro de rota a partir disso. Objeto ausente ou invalido = prefixo filtrado e rota que nao propaga.
• RPKI (publish-only, ROAs, horario): o ROA assina qual ASN pode originar cada prefixo. Sem ROA, o bloco fica exposto a sequestro de rota; "publish-only" e o modo seguro, que nao altera politica BGP.
• PeeringDB (AS-SET, prefix-limits): IXPs e peers usam para montar a sessao e o limite de prefixos. Divergencia trava ou derruba o peering.
• GeoFeed (URL, entradas, limite 5 MB): a geolocalizacao correta dos seus blocos — exatamente o que o submenu GeoFeed trata.

Como usar no dia a dia: nao e obrigatorio cravar 100%. Ataque o vermelho primeiro (erro real), depois o amarelo (pendencia). O ganho de governanca e ter, numa tela so, uma foto auditavel de quao publicavel e confiavel o seu ASN esta.

O que e: um placar de prontidao do ASN frente as 4 acoes MANRS (a norma de fato para seguranca de roteamento) e a itens do BCOP do NIC.br. E uma lente separada do score de Higiene: aqui o foco e roteamento seguro.

As 4 acoes MANRS: Filtering (filtrar rotas suas e de clientes), Anti-spoofing (BCP 38/SAV, nao deixar sair IP de origem falsa), Coordination (contato tecnico/NOC atualizado no RIR e no PeeringDB) e Global Validation (publicar suas rotas em IRR e ROAs em RPKI para terceiros validarem).

Como ler: verde = pronto, amarelo = pendencia, vermelho = ausente. A "Cobertura ROA" cruza, offline, suas rotas (route/route6) com as ROAs: aponta rota sem ROA (ficaria Unknown/Invalid), rota mais especifica que o maxLength (ficaria Invalid) e ROA com maxLength permissivo demais (RFC 9319, convida hijack por more-specific).

Por que importa: e o checklist que upstreams, IXPs e o Desafio BCOP 2026 do NIC.br usam para medir um ASN saudavel. Filtering vira "valid" quando voce tem AS-SET + route objects: geramos o prefix-list (de SAIDA) por bgpq4 em Cisco/Huawei VRP8/JunOS/BIRD para colar no router. A Acao 2 (Anti-spoofing) vira "valid" quando voce registra a evidencia do CAIDA Spoofer (IPv4+IPv6) abaixo. Em Bogons (referencia) ha o filtro de ENTRADA (nega bogons + seus prefixos) pronto para download.

O que e: um loop de roteamento faz o pacote quicar entre roteadores; cada salto reduz o TTL ate zerar (ICMP Time Exceeded) — a "morte por TTL". No traceroute, aparece como os mesmos hops se repetindo sem nunca chegar ao destino.

Como testar: rode traceroute -n -m 40 <alvo> (ou mtr -n --report <alvo>) e cole a saida abaixo, ou deixe um proxy / o scripts/route_loop_probe.py enviar automaticamente.

Por que importa: traz fidelidade real (teste de dentro da rede) e cobre com precisao a metrica "Routing loops" do Qrator. Cada ASN tem seu historico aqui; no futuro, proxies dentro de cada rede alimentam o dash global.

O que faz: lista os contatos do ASN por papel — tecnico, abuse, NOC e peering — com origem e status de validacao.

Por que importa: o contato de abuse e o canal por onde chegam as denuncias (spam, ataque, IP comprometido); tecnico e NOC tratam da operacao; peering cuida dos acordos. Contato desatualizado = incidente que nao chega a voce e reputacao do bloco em risco.

Boa pratica: use e-mail de papel (noc@, abuse@), nao pessoal — assim nao depende de uma unica pessoa.

Ganho de governanca: responsabilidade clara e resposta rapida a incidentes.

O que faz: guarda os dados da empresa do ASN — nome, site, endereco, redes sociais e CNPJ.

Sincronizacao: site/endereco/aka/redes sociais espelham a Org no PeeringDB (vem no import e poderao ser escritos de volta na Etapa 3). O CNPJ e local — o PeeringDB nao tem esse campo; a fonte oficial e o Registro.br.

O que faz: concentra os objetos de roteamento. No IRR voce mantem os objetos RPSL (route/route6, as-set, aut-num, mntner, person, role); em RPKI, os ROAs planejados. O modo e publish-only — publica e edita objetos, sem alterar politica BGP.

Por que importa: seus upstreams e IXPs montam o filtro de prefixos a partir do IRR — rota sem objeto route/route6, ou fora do AS-SET, costuma ser barrada e nao propaga. O ROA assina qual ASN pode originar cada prefixo; sem ROA, o bloco fica exposto a sequestro de rota (route hijack).

RPSL e RPKI: o IRR fala RPSL, a linguagem dos objetos (RFC 2622); o RPKI usa ROA (RFC 9582) e os roteadores aplicam Route Origin Validation (RFC 6811). O AS-SET aceita nome hierarquico (ex.: AS65000:AS-CUSTOMERS).

Ganho de governanca: rotas que propagam de forma previsivel e origem comprovada — menos filtragem indevida e menos vulnerabilidade.

O que faz: publica ROAs (autorizam seu ASN a originar seus prefixos) com um Krill proprio, sob o Registro.br (modelo delegado).

Bootstrap (uma vez): gere o Child Request aqui, cole no painel Registro.br (Titularidade → ASN → Configurar RPKI), traga o Parent Response. Idem Publisher Request → Repository Response (Publicacao Remota).

ROA minimal (RFC 9319): maxLength = tamanho do prefixo. Maior habilita sequestro de sub-prefixo; menor invalida o anuncio.

Tempo (~1h): apos criar/alterar ROA, validadores levam ate ~1h para enxergar (o IRR/RADB so revalida ROA a cada 1h).

Ganho de governanca: RPKI e IRR conversando — as ROAs saem dos mesmos prefixos que voce ja registra no IRR.

O que faz: mostra o perfil publico do ASN no PeeringDB (AS-SET, limites de prefixo IPv4/IPv6, presenca em IXPs) e aponta divergencias com o seu inventario.

Por que importa: peers e IXPs consultam o PeeringDB para montar a sessao e definir o prefix-limit. AS-SET divergente do IRR, ou prefix-limit baixo demais, trava ou derruba o peering; alto demais enfraquece a protecao contra vazamento de rota.

Ganho de governanca: perfil publico coerente com o IRR — peering aprovado mais rapido e com menos suporte manual.

O que faz: edita localmente os campos da Rede do PeeringDB (AS-SET do IRR, tipo, escopo, trafego, protocolos, looking glass, politica) e o menu Configuration (Allow IXP Update / Notify).

Allow IXP Update: autoriza o IXP a manter seus registros de netixlan via o IX-F member export. Notify On IXP Update: avisa por e-mail quando um import IX-F mudar seus dados.

Sincronizacao: aqui e local; escrever de volta no PeeringDB (PUT) e a Etapa 3.

O que e: a Organization API key (com permissao READ-WRITE em net/org) que o PeeringDB te deu. E por organizacao — vale para este ASN e qualquer outro da MESMA org. Para um ISP de outra org, selecione o ASN dele e cole a key daquela org.

Seguranca: a key fica so no servidor, cifrada em repouso (Fernet, chave derivada do session_secret) e NUNCA aparece de volta aqui — so o status. Sem ela, o "Enviar ao PeeringDB" da erro 400.

O que faz: escreve de volta no PeeringDB (PUT) os campos da Rede e da Organizacao que voce editou aqui e que diferem do PeeringDB. Direcao unica: inventario → PeeringDB.

Seguranca: "Pre-visualizar" so mostra o diff (nao escreve nada). "Enviar" exige ASN_PLATFORM_ENABLE_EXTERNAL_WRITES=true e a org API key com permissao de escrita no .env. CNPJ e geocode nunca saem. POC e netixlan ficam para a proxima etapa.

O que faz: resume a capacidade de cada integracao externa (TC IRR, PeeringDB, RPKI/Krill, provedores de GeoIP) e em que modo ela esta — leitura, publish-only ou escrita habilitada.

Por que importa: deixa explicito o que e seguro por padrao (read-only / publish-only) e o que exige credencial ou ativacao para escrever de fato, evitando acao destrutiva sem querer.

Ganho de governanca: transparencia sobre o que o sistema pode tocar no mundo externo — mudanca consciente e auditavel.