Esta página contém as políticas de roteamento da Net&Com (AS263324), as quais poderão ser ajustadas ou  modificadas a qualquer momento. Caso possua qualquer dúvida relacionada às nossas políticas de roteamento, solicitamos que entre em contato com os nossos canais de atendimento conforme destacados a seguir.

• Para assuntos relacionados à política de roteamento e Peering: peering@netecom.com.br
• Para assuntos relacionados à rede: engenharia@netecom.com.br
• Para assuntos relacionados à abusos e SPAM: abuse@netecom.com.br

Tabela de Conteúdos

Política de roteamento para clientes de Trânsito IP da Net&Com

Para a segurança efetiva do roteamento de Internet, com ênfase na prevenção de incidentes de segurança  relacionados a route leaks, prefix hijack, spoofing, entre outros, a política de roteamento e demais práticas de segurança adotadas pela Net&Com para seus clientes de Trânsito IP observam as recomendações do RFC 7454 / BCP 194, BCP 38, BCP 185 e objetivos discutidos pelo Mutually Agreed Norms for Routing Security (MANRS).

Esta seção apresenta os critérios para a aceitação de anúncios originados pelo nosso cone de clientes, assim como outros requisitos para a sessão BGP com clientes diretos:

Regime de importação de prefixos de clientes

• A importação de rotas de clientes de Trânsito IP da Net&Com implementa uma validação por três camadas:
  • Validação e aceitação de rotas por RPKI com ROA valid e unknown, e descarte de anúncios com ROA invalid.
  • Validação e aceitação de apenas prefixos legítimos conforme registros correspondentes junto às bases de Internet Routing Registry (IRR).
  • Validação e aceitação de apenas rotas que apresentarem a relação correta de AS-Path, com filtros estabelecidos por meios de expressão regular.
• Serão descartados quaisquer anúncios recebidos que contiverem ROA invalid (RPKI).
• Serão descartados quaisquer anúncios recebidos que possuírem condições irregulares de acordo com as bases IRR (ex: RADB, TC, ALTDB, BBOI)
  • Campo “origin” do objeto “route/route6”, referente ao prefixo/anúncio recebido, precisa corresponder à organização legítima detentora daquele prefixo.
  • O ASN cliente, mencionado no campo origin do objeto “route/route6”, e referente a cada anúncio recebido, deverá possuir o objeto “aut-num” correto correspondente.
  • Este objeto “aut-num” deverá indicar que a Net&Com (AS263324) faz trânsito para aquele ASN cliente.
    • Ou seja, esperamos um mínimo de especificações RPSL nos campos “import/mpimport” e “export/mp-export” deste objeto “aut-num”, mencionando quais objetos “as-set” são envolvidos nesta relação de trânsito entre a Net&Com e o ASN cliente.
    • Os campos export/mp-export deverão mencionar o objeto as-set que o cliente utiliza para representar as redes de seu ASN ou as redes de seu ASN + cone de clientes, indicando a exportação destes as-sets para o AS263324 (Net&Com).
    • Os campos import/mp-import deverão informar que o cliente importa ANY do AS263324.
  • O ASN cliente precisa possuir um “as-set” do tipo geral, devendo este ainda estar mencionado no campo “IRR as-set/route-set” do cadastro deste ASN no site do PeeringDB.
    • Este objeto “as-set” geral deverá incluir como membros os demais objetos “as-set” necessários do ASN cliente, incluindo aquele(s) que denota(m) a relação de trânsito entre a Net&Com (AS263324) e o cliente.
  • Em caso de clientes diretos que façam trânsito para outros ASN, os quais, neste caso, seriam clientes indiretos da Net&Com, as mesmas exigências se fazem necessárias para a questão do IRR, incluindo objetos “route/route6”, “as-set”, “aut-num”, e a indicação do “as-set” geral de cada ASN cliente-indireto em seus respectivos cadastros no PeeringDB.
• Serão descartados quaisquer anúncios recebidos que contiverem uma lista de AS-Path irregular.
  • A Net&Com realiza filtros de AS-Path por meios de expressões regulares (regex) com base nas relações indicadas pelas regras “import/mp-import” e “export/mp-export” dos objetos “aut-num” referentes aos ASNs clientes ou conforme indicado pelas relações documentadas nos registros do IRR.
  • Cada ASN mencionado na lista do atributo AS_PATH do anúncio recebido precisa ser membro de um objeto “as-set” apropriado, e deverá haver uma relação recursiva até o AS263324 (Net&Com) para a evidência desta relação de trânsito pretendida.
• Serão descartados quaisquer anúncios recebidos que contiverem as seguintes irregularidades ou condições:
  • ASNs privativos: RFC6996 (64512-65534, 65535, 4200000000-4294967294, 4294967295), em qualquer lugar na lista de AS-Path.
  • ASNs reservados: RFC5398 (64496-64511, 65536-65551), em qualquer lugar na lista de ASPath.
  • IANA reservados: (65552-131071), AS0 (RFC7606) ou AS23456 (RFC4893), em qualquer lugar na lista de AS-Path.
  • ASNs de “Tier-1” oriundos de anúncios de downstreams: 174, 209, 286, 701, 702, 703, 1239, 1273, 1299, 2828, 2914, 3257, 3320, 3356, 3491, 3549, 3908, 3910, 4323, 4436, 5511, 5580, 6453, 6461, 6762, 6830, 6939, 7081, 8928, 12956, e outros, em qualquer lugar na lista de AS-Path.
  • Anúncios com excesso de communities atreladas (>30), desconsiderando aquelas que automaticamente adicionaremos às rotas.
  • Anúncios com excesso de AS-Path Prepending (>10).
  • Anúncios onde o primeiro ASN da lista (“leftmost”) for diferente do ASN do peer.
  • Anúncios do próprio bloco de prefixos da Net&Com (AS263324), exceto quando isto for autorizado para o ASN cliente.
  • Prefixos privativos ou declarados como “não redistribuir”, tais como RFC 1122, 1918, 2544, 3849, 3927, 4193, 4291, 5180, 5737, 6598 e outros.
  • (implícito) Anúncios que contiverem prefixos bogons, martians e ainda não alocados pelo IANA.
  • Prefixos referentes a LAN de IX / pontos de troca de tráfego com os quais o AS263324 possui conexões.
  • Rotas menos específicas que /16 (IPv4) serão validadas pela Engenharia da Net&Com antes de poderem ser aprovadas.
  • Rotas menos específicas que /32 (IPv6).
• A Net&Com aceitará anúncios que contiverem ASN privativo desde que estes ASN privativos tenham sido alocados/fornecidos pela Net&Com para a sessão BGP com o cliente.
  • Estes ASN privativos serão transparente e automaticamente removidos dos anúncios para as demais sessões BGP com as quais o AS263324 mantém (cone de clientes, redes de fornecimento de conteúdo, peering público, peering privado, trânsito IP).
• Embora os nossos filtros aceitem seus anúncios refletindo todo o espaço nas bases IRR (ex: /20 upto /24), solicitamos que, para cada anúncio a ser enviado para a Net&Com, haja um objeto “route/route6”  correspondente, e observando as demais condições supracitadas (regras do “aut-num”, “as-set”, e cadastro do PeeringDB).
  • Justificativa: alguns de nossos parceiros de Peering privado (PNI), como o Google, possuem esta exigência. Para você não perder os benefícios de uma experiência de navegação mais fluída para seus clientes, recomendamos que cada prefixo a ser anunciado possua um objeto “route/route6” correspondente.
• A Net&Com preservará e honrará todos os atributos atrelados às rotas aprovadas de clientes, incluindo MED, a codificação de métricas IGP no atributo MED (exceto para os casos de rotas do próprio AS263324),  communities e afins.
  • O MED será preservado, mas, como característica intrínseca do BGP, especificamente no que diz respeito ao processo de seleção das melhores rotas, ou seja, neste caso, para determinar por qual conexão o AS263324 encaminhará tráfego para o seu AS, os atributos LOCAL_PREF, AS_PATH e ORIGIN sempre terão precedência sobre o MED. Esteja atento quanto a este detalhe, caso queira usar o MED para fins de engenharia de tráfego.
  • Todas as communities serão preservadas, incluindo as de caráter informacional (origem geográfica, tipo de rota, etc.), exceto as communities e uso restrito da própria Net&Com.
• A Net&Com não implementa route dampening por padrão.
• Communities para serviços especiais estão disponíveis para clientes de trânsito IP da Net&Com, tais como o ajuste de AS-Path Prepending e/ou LOCAL_PREF por upstream de trânsito IP do AS263324, blackhole (RTBH) e UTRS.
• Rotas de prefixos IPv4 /32 e IPv6 /128 (após validação IRR + RPKI + regex) que incluírem a community de blackhole da Net&Com (26332:666) terão o seu atributo NEXT_HOP modificado para Null0/discard em todo o AS263324, e não apenas no roteador PE por onde o anúncio foi recebido.
  • A Net&Com repassará este anúncio, nestas condições, para que nossos upstreams também contribuam com o propósito e façam o blackhole de acordo.

Estas exigências da Net&Com visam o aumento da segurança do roteamento BGP para toda a Internet. Caso você tenha qualquer dificuldade quanto ao cumprimento destes requisitos, a nossa equipe coloca-se à sua inteira disposição para assessorá-lo em todas as ações necessárias para que o seu ASN seja ativado ou provisionado o mais prontamente possível, e todos sairão ganhando: a reputação do seu ASN será bastante aprimorada, e, juntos, passaremos a usufruir de uma Internet cada vez mais segura, disponível e confiável! Conte conosco!

Regime de exportação de rotas para clientes

• A Net&Com não repassará os seguintes anúncios para ASNs clientes:
  • Prefixos privativos ou declarados como “não redistribuir”, tais como RFC 1122, 1918, 2544, 3849, 3927, 4193, 4291, 5180, 5737, 6598 e outros.
  • Prefixos referentes a LAN de IX / pontos de troca de tráfego com os quais o AS263324 possui conexões.
  • (implícito) Prefixos bogons, martians e ainda não alocados pelo IANA.
  • Rota padrão / default: exceto quando solicitado pelo ASN cliente.
• A Net&Com repasssará os seguintes anúncios para ASNs clientes:
  • Rotas recebidas do próprio cone de clientes da Net&Com.
  • Rotas recebidas de sessões de peering privado (PNI).
  • Rotas recebidas de sessões de peering Cloud (Cloud Durand e Cloud Forte Telecom).
  • Rotas recebidas de sessões de peering público (IX).
  • Rotas (best path) recebidas de upstreams de trânsito IP da Net&Com.

Política de roteamento para clientes de Peering-Apenas da Net&Com

• A Net&Com disponibiliza um produto específico para clientes que desejam trocar tráfego no regime de Peering-apenas com o AS263324 e seu ecossistema de peerings.
• As mesmas regras de importação de rotas de clientes Trânsito IP aplicam-se para os clientes de Peering-Apenas, ou seja:
  • Validação de prefixos recebidos por RPKI, com descarte de ROA invalid.
  • Validação de prefixos recebidos conforme regularidades das bases IRR, incluindo objetos “route/route6”, “aut-num”, regras “import/mp-import” e “export/mp-export” do objeto “aut-num”, objetos “as-set”, e a presença do “as-set” geral no cadastro do ASN cliente no site do PeeringDB.
  • Validação da lista de AS-Path dos prefixos recebidos por meios de regex, o que obriga a consistência das especificações RPSL do objeto “aut-num” do ASN cliente.
• A Net&Com repassará para o ASN cliente apenas as seguintes rotas:
  • Rotas recebidas de sessões de Peering privado (PNI).
  • Rotas recebidas de sessões de Peering com a Cloud Durand e Cloud Forte Telecom.
  • Rotas recebidas de sessões com o IX.br.
• Controle de exportação de anúncios do ASN cliente para as sessões de Peering com os quais a Net&Com possui:
  • O ASN cliente poderá utilizar as nossas communities para informar quais de seus prefixos não deseja que o AS263324 exporte para o IX.br.
  • O ASN cliente poderá utilizar as nossas communities para fins de AS-Path Prepend para o IX.br.

Política de roteamento para clientes de Trânsito-Apenas da Net&Com

• A Net&Com disponibiliza um produto para clientes que desejam trocar tráfego no regime de Trânsito IP apenas.
• As mesmas regras de importação de rotas de clientes Trânsito IP aplicam-se para os clientes de Trânsito-Apenas, ou seja:
  • Validação de prefixos recebidos por RPKI, com descarte de ROA invalid.
  • Validação de prefixos recebidos conforme regularidades das bases IRR, incluindo objetos “route/route6”, “aut-num”, regras “import/mp-import” e “export/mp-export” do objeto “aut-num”, objetos “as-set”, e a presença do “as-set” geral no cadastro do ASN cliente no site do PeeringDB.
  • Validação da lista de AS-Path dos prefixos recebidos por meios de regex, o que obriga a consistência das especificações RPSL do objeto “aut-num” do ASN cliente.
• A Net&Com repassará para o ASN cliente apenas as seguintes rotas:
  • Rotas recebidas de sessões com upstreams de Trânsito IP.
• Controle de exportação de anúncios do ASN cliente para os upstreams de Trânsito IP da Net&Com:
  • O ASN cliente poderá utilizar as nossas communities para informar quais de seus prefixos não deseja que o AS263324 exporte para determinadas sessões de upstreams de Trânsito IP da Net&Com.
  • O ASN cliente poderá utilizar as nossas communities para fins de AS-Path Prepend para cada um de nossos upstreams de Trânsito IP desejados.

Requisitos para as sessões BGP com ASNs clientes dos produtos Trânsito IP, Peering-Apenas e Trânsito-Apenas

• A Net&Com implementa um limite máximo de prefixos a serem recebidos das sessões BGP de seus clientes.
  • Quando este limite é atingido, a sessão EBGP é derrubada e uma tentativa de autorecuperação correrá em intervalos de 30 segundos.
  • Este limite é negociado ou estabelecido durante o estágio de provisionamento da sessão EBGP com o ASN cliente.
  • Caso necessite ampliar o seu limite de envio de rotas para o AS263324, faça a solicitação formal junto ao nosso canal de atendimento.
• A Net&Com implementa um mecanismo de proteção para as sessões EBGP com ASNs clientes.
  • Recomendamos e reforçarmos primariamente o emprego de BGP TTL Security Hack (BTSH) / Generalized TTL Security Mechanism (GTSM).
  • Em adição ao BTSH/GTSM, a Net&Com recomenda o uso do TCP Authentication Option (TCP-AO), caso o equipamento do ASN cliente suporte esta facilidade.
  • Descontinuamos o uso da autenticação de sessões EBGP com MD5, mas este método poderá ser considerado no regime caso a caso.
• O suporte a BGP Graceful Shutdown poderá ser viável ou não para o seu caso, dependendo do seu  produto/regime de conexão com o AS263324.
• A Net&Com implementa automaticamente controle de antispoofing (uRPF Strict ou Feasible) sobre todo o tráfego oriundo das conexões com o seu cone de clientes.
  • Este é um esforço/iniciativa por parte da Net&Com para contribuir com a redução dos vetores de ataques de negação de serviço (DDoS) na Internet.
    • Se todos os Sistemas Autônomos (AS) da Internet implementassem mecanismos antispoofing, praticamente não existiriam ataques DDoS, ou pelo menos não nos moldes em que estes ataques são concebidos atualmente.
  • A Net&Com está alinhada com as recomendações e objetivos do MANRS para contribuir para a segurança da Internet. Mas o fato da Net&Com realizar o uRPF automaticamente para todo o tráfego recebido de seu cone de clientes não impede ou não inibe que seus clientes façam o mesmo trabalho.
    • A Net&Com recomenda que todos seus clientes implementem mecanismos
      antispoofing (ex: uRPF) em suas redes de Acesso. Faça a sua parte, e contribua para
      uma Internet cada vez mais segura!

Blackhole com a Net&Com

• A Net&Com disponibiliza uma Community que poderá ser utilizada especificamente para fins de Remote Triggered Black Hole Filtering (“blackhole”). Este serviço só possui validade para clientes Trânsito IP e Trânsito-Apenas.
• Rotas /32 (IPv4) e /128 (IPv6), após validadas pelos filtros da policy de importação, e que acompanharem a Community 26332:666, terão seu atributo NEXT_HOP automaticamente modificado para Null/discard.
• A Net&Com poderá repassar este anúncio, nestas condições, para upstreams de Trânsito IP que suportarem RTBH conosco.

Ajuste de AS-Path Prepend e Local-Preference

• A Net&Com disponibiliza communities para que possamos implementar automaticamente valores de atributo LOCAL_PREF diferenciados sobre as rotas recebidas de clientes para acomodar cenários de conectividade dual-homed com o AS263324.
• A Net&Com disponibiliza communities apropriadas para que clientes optem por realizar automaticamente AS-Path Prepend sobre os seus prefixos desejados através das sessões que mantemos com o IX.br e também para cada um de nossos upstreams de Trânsito IP, onde isto for desejado pelo cliente.

Ferramentas de autosserviço e suporte ao BGP

A Net&Com (AS263324) disponibiliza os seguintes serviços e ferramentas para auxiliar clientes e demais Sistemas Autônomos no diagnóstico de problemas, ou então a simples necessidade de verificação do BGP:

• Status Page: http://status.netecom.com.br/ (http://status.netecom.com.br/)
• Looking Glass: http://lg.netecom.net.br/ (http://lg.netecom.net.br/)
• Painel de monitoramento BGP: http://bgpview.netecom.com.br:3000 (http://bgpview.netecom.com.br:3000)
• Registro no PeeringDB: http://as263324.peeringdb.com/ (http://as263324.peeringdb.com/)
• Registros IRR (RADB) e especificações RPSL:
  • Objeto aut-num: AS263324
  • Objeto as-set: AS-NETECOM-ALL (membros AS-NETECOM e AS-NETECOM-CUSTOMERS)
  • Objeto role: AS263324 Network Operations Center
• Canais de suporte – caso necessite de ajuda, fale conosco:
  • Para assuntos relacionados à política de roteamento e peering: peering@netecom.com.br
  • Para assuntos relacionados à rede: engenharia@netecom.com.br
  • Para assuntos relacionados à abusos e SPAM: abuse@netecom.com.br
• Recursos didáticos de apoio: caso o ASN cliente precise compreender melhor as características e funcionamento do BGP, ou sobre algumas das práticas adotadas pela Net&Com na questão da segurança do roteamento de Internet, recomendamos a leitura dos seguintes recursos.
  • O mínimo que você precisa saber sobre o BGP (https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_o_BGP)
  • MANRS (https://wiki.brasilpeeringforum.org/w/MANRS)
  • O mínimo que você precisa saber sobre IRR (https://wiki.brasilpeeringforum.org/w/O_Minimo_que_Voce_precisa_saber_sobre_IRR)
  • PeeringDB – como se cadastrar e atualizar seus dados (https://wiki.brasilpeeringforum.org/w/PeeringDB_-_como_se_cadastrar_e_atualizar_seus_dados)

Communities Net&Com – AS263324

Presença da Net&Com em Pontos de Troca de Tráfego

A Net&Com está presente nos seguintes pontos de troca de tráfego. Para maiores informações sobre a nossa política de Peering, ou, desejando estabelecer uma conexão conosco, solicitamos para que entre em contato conosco através do e-mail peering@netecom.com.br. Consulte também os nossos registros no PeeringDB:  http://as263324.peeringdb.com/ (http://as263324.peeringdb.com/)

• IX.br (PTT.br) Fortaleza – PIX GLOBENET
• IX.br (PTT.br) Rio de Janeiro – PIX CBPF
• IX.br (PTT.br) Rio de Janeiro – PIX DURAND
• IX.br (PTT.br) Rio de Janeiro – PIX LINKFULL
• IX.br (PTT.br) São Paulo – PIX EQUINIX-SP1
• IX.br (PTT.br) São Paulo – PIX SAMMCCR