Wiki BPF - Contribuições do(a) usuário(a) [pt-br]

CDN Peering e PNI - Brasil

2019-02-26T23:04:54Z

Uesleycorrea: /* Peerings - Sessões Bilaterais */

===Introdução===
Esta página contém informações úteis para operadores de redes e ISPs com relação à solicitação de servidores de CDNs, estabelecimento de uma sessão Bilateral em algum dos IXs ou para a solicitação de PNIs nos Datacenters aonde ASNs, geralmente grandes geradores de conteúdos, estão presentes.

É importante destacar que as informações aqui apresentadas (ex: tráfego necessário para solicitar servidores de CDN) mudam de forma bastante dinâmica e de acordo com as regras próprias estabelecidas pelos próprios geradores de conteúdo, portanto este guia serve como referência para o momento que ele foi escrito ou atualizado pela última vez.

Um recomendação importante a ser feita é que antes de fazer a solicitação de servidores de CDN ou de um PNI por exemplo, é importante realizar uma avaliação detalhada do tráfego que o seu ASN troca com os ASNs desses geradores de conteúdo. Ferramentas como NetFlow e [https://www.peeringdb.com/ PeeringDB] auxiliam bastante. Cerifique-se que você atende à TODOS os requisitos antes de fazer a solicitação, principalmente se possui a quantidade de mínima de tráfego para ser elegível. Esses servidores somente são enviados aos ISPs no caso das empresas de CDN verificarem que eles trazem benefícios para ambos CDN e ISP, caso contrário dificilmente serão enviados. Hospedar e manter um servidor de CDN é algo que demanda recursos do provedor como espaço em rack, portas de switch e principalmente um consumo razoável de energia elétrica por isso uma avaliação criteriosa é bastante importante antes de realizar a solicitação.

Outro detalhe imprescindível na hora de solicitar um servidor de CDN, Peering por Sessão Bilateral ou PNI é o IPv6. Devido à crescente importância deste protocolo algumas CDNs hoje em dia tem colocado restrições caso você não seja capaz de estabelecer uma sessão IPv6 com eles.Além disso caso você possua IPv6 em seu backbone porém ainda não está distribuindo para os usuários residencias e possui apenas CGNAT44 a maioria das grandes CDNs já possuem suporte completo à IPv6 portanto uma parte significativa do seu tráfego poderia estar fluindo preferencialmente em IPv6 ao invés de estar passando por equipamentos que fazem o GGNAT a um custo computacional maior além de ter a identificação do usuário facilitada em caso de uma solicitação baseada no Marco Civil da Internet.

A maioria das CDNs exigem que as informações sobre o ASN solicitante estejam atualizadas no PeeringDB portanto antes de solicitar é uma boa prática conferi-las.

Você pode acessar o URL a seguir para entender melhor o funcionamento de sessões Peering: [[Modelos_Interconexão]]

''Última atualização - 17/12/2018''
===CDNs===
As CDNs, normalmente baseadas em critérios próprios, definem condições em que um servidor pode ser enviado para ser instalado dentro do backbone de um ISP para otimizar a entrega de conteúdo para o usuário final. Isso é vantajoso para a CDN que melhora a qualidade na entrega do conteúdo, para o usuário final e também para ISP pois além de economizar no uso dos links de upstream são capazes de prover uma melhor experiência para seus usuários.

O tráfego atual de referência para solicitação de servidores de algumas CDN está na faixa dos 5 Gbps, porém existem condições que isso pode ser flexibilizado à depender da região e da disponibilidade de outros Trânsitos IP presentes serem capazes de distribuir aquele conteúdo. Via de regra em uma grande cidade ou região populosa é bastante provável que o valor de referência não seja flexibilizado pelas CDNs.
====Akamai (AANP)====
*Banda mínima: 2.5 Gbps
*Solicitação/Portal: https://www.akamai.com/us/en/products/network-operator/akamai-network-partnerships.jsp
*Documentação: https://www.akamai.com/us/en/multimedia/documents/akamai/akamai-accelerated-network-partner-aanp-faq.pdf
*PeeringDB: https://www.peeringdb.com/net/2
====Facebook (FNA)====
*Banda mínima: 5 Gbps
*Email: fna@fb.com
*PeeringDB: https://www.peeringdb.com/net/979
====Google (GGC)====
*Banda mínima: 3 Gbps
*Informações: https://peering.google.com/#/options/google-global-cache
*Solicitação: http://isp.google.com/iwantpeering
*Instalação: https://www.gstatic.com/isp/docs/ggc-installation.pdf
*Troubleshooting: https://cloud.google.com/cdn/docs/support
*Portal: https://isp.google.com/dashboard/
*PeeringDB: https://www.peeringdb.com/net/433<nowiki/>https://www.peeringdb.com/net/4319
====Netflix (OCA)====
*Banda mínima: 5 Gbps (SP, RJ, RS e CE) e 2 Gbps (demais Estados)
*Solicitação: https://openconnect.netflix.com/en/request/
*Instalação: https://openconnect.netflix.com/deploymentguide.pdf
*Troubleshooting: https://openconnect.netflix.com/en/faq/
*Portal: https://my.oc.netflix.com/
*PeeringDB: https://www.peeringdb.com/net/457

==== Azion (ANA) ====
* Banda mínima: 4 Gbps (Seletiva)
* Email: cdn@azion.com / peering@azion.com
* Informações: https://www.azion.com.br/developers/peering/
* PeeringDB: https://www.peeringdb.com/net/14511

==== SourceForge.Net ====
* Banda mínima: 150Mbps
* Hardware por conta do provedor, com 8TB de disco no mínimo.
* Email: staff@sourceforge.net
* Informações: https://sourceforge.net/p/forge/documentation/Join%20as%20a%20Mirror/

==== Microsoft ====
* Banda mínima: 2 Gbps (Seletiva) / 5 GB downloads por dispositivos com Win10. (Restritivo)
* Email: ispnode@microsoft.com
* Informações: https://peering.azurewebsites.net/Peering/Caching
* PeeringDB: http://as8075.peeringdb.com/

===Peerings - Sessões Bilaterais===
É possível também solicitar diretamente à alguns ASNs o estabelecimento de uma sessão bilateral através de algum dos IX onde ambos os ASNs estejam presentes (para saber mais consulte [[Modelos_Interconexão]]). Em alguns casos existe um tráfego mínimo para estabelecimento desta sessão.

Na maioria dos casos os prefixos anunciados para os Route Servers são os mesmos anunciados na sessão bilateral, porém existem também casos onde isso pode ser diferente o que justifica o estabelecimento da sessão ou ainda para permitir ao ASN um melhor controle sobre os anúncios para cada um desses ASNs.Por padrão a sessão é estabelecida na mesma VLAN do ATM v4 e v6, a não ser que exista alguma motivação para que seja estabelecida através de uma VLAN Bilateral.

Também existem casos de conteúdos como a Microsoft que anunciou recentemente a saída dos Route Servers, portanto em casos como esses é necessário estabelecer uma sessão bilateral para que exista troca de tráfego direta entre ambos os ASNs.

Antes de solicitar o estabelecimento de uma sessão bilateral através do IX recomenda-se deixar a configuração pronta no seu roteador para agilizar o processo.

A listagem não exaustiva abaixo apresenta alguns ASNs que são conhecidos por estabelecerem sessões bilaterais no IX-SP:
====Akamai====
*Email: peering@akamai.com e peering-tix@akamai.com
*PeeringDB: https://www.peeringdb.com/net/2
====Microsoft====
*Email: peering@microsoft.com
*Solicitação: http://www.microsoft.com/peering
*PeeringDB: [http://as8075.peeringdb.com/][https://www.peeringdb.com/net/694 http://as8075.peeringdb.com/]

==== Hurricane Electric ====
* Email: peering@he.net
* Email NOC: noc@he.net (após sessão estar ativada)
* Informações: http://he.net/peering.html
* PeeringDB: https://www.peeringdb.com/net/291
A Hurricane Electric oferece também Trânsito IPv6 gratuito através de sessão bilateral. Para solicitar envie um email para ipv6@he.net

====LinkedIn====
*Email: peering@linkedin.com
*PeeringDB: https://www.peeringdb.com/net/4231
====CloudFlare====
*Email: peering@cloudflare.com
*PeeringDB: https://www.peeringdb.com/net/4224
====CDNetworks====
*Email: peering@cdnetworks.com
*PeeringDB: https://www.peeringdb.com/net/1372

==== Azion ====
* Banda mínima: 150 Mbps (Seletiva)
* Email: peering@azion.com / noc@azion.com
* PeeringDB: https://www.peeringdb.com/net/14511

==== Twitch TV ====
* Email: noc@twitch.tv
* Contato: https://noc.twitch.tv/
* PeeringDB: https://www.peeringdb.com/asn/46489
* Política: Seletiva

==== Oath/Yahoo ====
* Email: peering-requests@oath.com
* Informações: https://peering.oath.com/policy
* PeeringDB: https://www.peeringdb.com/asn/10310/
* Política: Seletiva

==== Netflix ====
* Banda Minima: 3Gbps
* Email: peering@netflix.com
* PeeringDB: <nowiki>https://www.peeringdb.com/net/457</nowiki>

===PNIs - Private Network Interconnection===
PNIs são interconexões privadas realizadas diretamente entre dois ASNs sem o intermédio de um terceiro (entenda PNI em: [[Modelos_Interconexão]]). Geralmente é um ''cross-connect'' ou ''golden-jumper'' entre os racks das duas empresas em um mesmo Datacenter onde ambas estejam presentes.No [https://www.peeringdb.com/ PeeringDB] é possível verificar os Datacenters que as CDNs estão presentes e onde existe possibilidade de solicitar um PNI olhando na seção "Private Peering Facilities".

Uma das vantagens de um PNI é a de por se tratar de uma conexão direta não esta suscetível à possíveis problemas causados por exemplo na matriz de um IX aonde ambos ASN já trocam tráfego. Além disso por se tratar de uma conexão dedicada a banda toda disponível na porta é dedicada àquele tráfego entre os dois ASNs aliviando assim outras portas de peering para outros tipos de tráfegos.

Algumas CDNs embora grandes optam por não disponibilizar a modalidade de interconexão através de PNI restringindo assim à troca de tráfego através do IX ou através de um servidor de CDN que é instalado dentro do backbone do ISP.

Normalmente envolve um custo que é o do ''cross-connect'' ou ''golden-jumper'' que pode ser pago por uma das partes ou dividido igualmente entre ambas.

A listagem abaixo contém as informações em quais Datacenters é possível ter um PNI com algumas dessas CDNs:
====Facebook====
*Email: peering@fb.com
*Datacenters: Equinix-SP2, Equinix-SP4 e Equinix-RJ1
*PeeringDB: https://www.peeringdb.com/net/979
*Informações: https://wiki.brasilpeeringforum.org/images/4/4e/Peer-pni-parameters-facebook.pdf
====Google====
*Informações: https://peering.google.com/#/options/peering
*Solicitação: http://isp.google.com/iwantpeering
*Datacenters: Equinix-SP2 (através de transporte), Equinix-SP4, Level 3 - Cotia e Level 3 - Rio de Janeiro.
*PeeringDB: https://www.peeringdb.com/net/433<nowiki/>https://www.peeringdb.com/net/4319
==== Netflix ====
* Banda Mínima: 3Gbps
* Email: peering@netflix.com
* Informações: https://openconnect.netflix.com/en/guidelines/
* Datacenters: Equinix-SP2, Equinix-RJ1, NIC-JD, Commcorp Porto Alegre-PAE1, ETICE-Fortaleza
* PeeringDB: https://www.peeringdb.com/net/457

==== Azion ====
* Banda mínima: 5 Gbps
* Email: peering@azion.com / noc@azion.com
* Informações: https://www.azion.com.br/developers/peering/
* Datacenters: Ascenty Campinas, Commcorp-BSA2, Commcorp-FNS1, Commcorp-PAE1, Equinix-SP3, Level 3 - Cotia, GVT - Curitiba, Globenet - Fortaleza, NIC-JD, PIX Adylnet-PAE, PIX G8 - São Paulo, PIX Vogel - Porto Alegre, Tascom - Salvador
* PeeringDB: https://www.peeringdb.com/net/14511
==== Twitch TV ====
* Banda mínima: 2.5 Gbps
* Email: noc@twitch.tv / interconnection@twitch.tv
* Contato: https://noc.twitch.tv/
* Datacenters: Equinix-SP2, Level 3 - Cotia, Level 3 - Rio de Janeiro
* PeeringDB: https://www.peeringdb.com/asn/46489
[[Categoria:Interconexão]]

Concentradores PPPoE com IPv6

2018-12-16T11:34:07Z

Uesleycorrea:

== Introdução ==
Nesse artigo, falaremos sobre como configurar concentradores PPPoE habilitando o suporte ao IPv6.

==Revisão do conceito de PPPoE==
PPPoE é o acrônimo de '''Point-to-Pont Protocol over Etherne'''t e foi um protocolo popularizado na época do boom da Internet Banda Larga no Brasil pela facilidade de gerência e facilidade de processo '''AAA''' (Autenticação, Autorização e Accounting). Nesse ínterim, muitos provedores e operadores que vinham de redes nativamente com IP Fixo amarrado ao MAC Address e também implementações baseadas em Captive Portal (hotspot) migraram para o PPPoE pois esse também reduzia a quantidade de broadcast circulando pela rede devido a ser um modelo de implementação baseado em protocolo ponto a ponto.

== Revisão do conceito de IPv6 ==
O IPv6 é um protocolo Internet criado para resolver alguns problemas inerentes ao protocolo IPv4 como: falta de endereços disponíveis a todos os dispositivos (gerando quebra do modelo fim-a-fim), fragmentação de pacotes no caminho (gerando alto custo computacional nos roteadores que encaminham milhares de pacotes constantemente), dificuldade na criptografia dos dados (por conta da quebra do modelo fim-a-fim e bloqueio do protocolo ICMP) entre outros problemas. Possui '''128 bits''' de capacidade de endereçamento contra '''32 bits''' do protocolo anterior. Trabalha com o conceito de blocos de endereçamento e não mais endereços únicos.

== IPv6 para Usuários Finais ==
No âmbito do conceito de entrega para usuários finais, existem algumas '''BCOP's''' (Boas Práticas Operacionais) que determinam que um assinante no cenário residencial deve receber um bloco /56 para uso interno e um assinante empresarial receberia um /48 para uso interno. Além disso, como estamos tratando de PPPoE é necessário também um bloco de endereçamento /64 para endereçar o túnel PPPoE. Não vamos nos ater aos conceitos básicos de endereçamento IPv6, mas vamos falar apenas que um /64 é o mínimo bloco de endereçamento a ser manipulável e todos os demais blocos são múltiplos de 8 desse /64. Exemplo: um /56 tem 8 bits a menos que um /64. Assim sendo, um /56 possui 256 redes /64 inclusas.

Resumindo: Precisamos para cada assinante residencial de 1 /64 para o túnel e 1 /56 para prefix-delegation (bloco que será entregue para a rede interna do assinante, visto que IPv6 não necessita de NAT).

== Documentação ==
É de extrema importância o planejamento e a documentação de uso de prefixos. Enquanto no IPv4 tínhamos uma escassez (que nos ensinou a ser econômicos), no IPv6 temos fartura. Porém, essa fartura pode atrapalhar no planejamento. Geralmente costumamos indicar o '''PHPIPAM''' (http://phpipam.net) para documentação (lembrando que é opensource e vale a pena contribuir com esse trabalho). Já no PHPIPAM, você pode documentar e separar os seus blocos em frações de trabalho. Um exemplo clássico de concentrador para 1024 assinantes segue abaixo:
{| class="wikitable"
|+Tabela de Relação de Prefixos a Serem entregues por Concentrador
!Prefixo a ser entregue
!Tamanho
!Quantidade de Clientes
!Tamanho do Prefixo Necessário
|-
|Túnel
|/64
|1024
|/54
|-
|Prefix-Delegation
|/56
|1024
|/46
|}

== Concentrador RouterOS ==
Para o concentrador PPPoE RouterOS, necessitaremos criar os pools conforme definido no nosso projeto e após, indicá-los no profile usado pelo nosso Serviço PPPoE. Usaremos para esse fim, o prefixo de documentação 2001:db8::/32. É necessário certificar-se de que há rota de saída e de entrada para os pools escolhidos em cada concentrador.
[[Arquivo:IPv6 Pool.png|miniaturadaimagem|centro]]

Nessa tela, temos a possibilidade de cadastrar os pools que serão usados pelo nosso profile PPPoE para a entrega de prefixos para os clientes que conectarem. Para fazer o cadastro de cada pool, basta utilizar o botão '''(+)''' localizado no canto superior esquerdo da tela e inserir os dados conforme o seu projeto. Lembrando que o campo '''''Prefix Length''''' refere-se ao tamanho do prefixo que será entregue ao usuário (/64 ou /56 dependendo do objetivo do bloco cadastrado).

[[Arquivo:Tela de Profiles.png|miniaturadaimagem|centro]]Já nessa tela ('''PPP->Profiles->"Profile Desejado"'''), relacionaremos os prefixos previamente configurados aos campos: '''''Remote IPv6 Prefix Pool''''' para o Pool de Tunel e o '''''DHCPv6 PD Pool''''' para o Pool de Prefix-Delegation.[[Arquivo:IPv6 Yes.png|miniaturadaimagem|centro]]

Na mesma tela anterior, porém na aba '''Protocols''', devemos marcar o box '''''Use IPv6''''' com a opção '''''yes'''''.

Apenas seguindo esses passos, nosso concentrador PPPoE RouterOS estará pronto para entregar prefixos IPv6 aos clientes.

== Concentrador Accel-PPP ==
Para o concentrador Accel-PPP é necessário configurar no arquivo '''''accel-ppp.conf''''' que pode estar em /etc/ ou em outra pasta referenciada na compilação do software. Vamos aos testes!

[[Arquivo:Allow.png|miniaturadaimagem|centro]]Na sessão PPP, deve-se usar a opção '''''ipv6=allow'''''. Essa opção permite que se a CPE do assinante tenha suporte ao IPv6, ela vai receber também as informações referentes à essa pilha IP.[[Arquivo:Pool.png|miniaturadaimagem|centro]]

Nessa sessão, é mandatório inserir os dados referentes aos nossos pools. Usamos aqui na primeira linha o pool de '''''Túnel''''' e na segunda, o pool de '''''Prefix-Delegation''''' (assim como usamos o exemplo do RouterOS).

[[Arquivo:DNS.png|miniaturadaimagem|centro]]

E aqui, inserimos os '''''DNS's''''' a serem entregues ao cliente, um em cada linha.
[[Arquivo:Conectados.png|miniaturadaimagem|centro]]

E essa tela é a saída suprimida do comando '''''accel-cmd show sessions''''' (os dados intermediários dos endereços foram removidos para sigilo).

== Considerações finais ==
Não menos importante que a implantação, cuidar da segurança da sua rede IPv6 é de altíssima importancia. Cuide sempre de firewall e de isolamento de redes de gerência fazendo o controle de forma simples e segura. E vamos seguindo em prol de um mundo IPv6-Only!

Autor: '''Uesley Corrêa'''
[[Categoria:IPv6]]
[[Categoria:Edge]]
[[Categoria:Capacitação]]

2018-12-15T12:47:26Z

Uesleycorrea: Criou página com '== Introdução == Nesse artigo, falaremos sobre como configurar concentradores PPPoE habilitando o suporte ao IPv6. ==Revisão do conceito de PPPoE== PPPoE é o acrônimo de...'

== Introdução ==
Nesse artigo, falaremos sobre como configurar concentradores PPPoE habilitando o suporte ao IPv6.

==Revisão do conceito de PPPoE==
PPPoE é o acrônimo de Point-to-Pont Protocol over Ethernet e foi um protocolo popularizado na época do boom da Internet Banda Larga no Brasil pela facilidade de gerência e facilidade de processo AAA (Autenticação, Autorização e Accounting). Nesse ínterim, muitos provedores e operadores que vinham de redes nativamente com IP Fixo amarrado ao MAC Address e também implementações baseadas em Captive Portal (hotspot) migraram para o PPPoE pois esse também reduzia a quantidade de broadcast circulando pela rede devido a ser um modelo de implementação baseado em protocolo ponto a ponto.

== Revisão do conceito de IPv6 ==
O IPv6 é um protocolo Internet criado para resolver alguns problemas inerentes ao protocolo IPv4 como: falta de endereços disponíveis a todos os dispositivos (gerando quebra do modelo fim-a-fim), fragmentação de pacotes no caminho (gerando alto custo computacional nos roteadores que encaminham milhares de pacotes constantemente), dificuldade na criptografia dos dados (por conta da quebra do modelo fim-a-fim e bloqueio do protocolo ICMP) entre outros problemas. Possui 128 bits de capacidade de endereçamento contra 32 bits do protocolo anterior. Trabalha com o conceito de blocos de endereçamento e não mais endereços únicos.

== IPv6 para Usuários Finais ==
No âmbito do conceito de entrega para usuários finais, existem algumas BCOP's (Boas Práticas Operacionais) que determinam que um assinante no cenário residencial deve receber um bloco /56 para uso interno e um assinante empresarial receberia um /48 para uso interno. Além disso, como estamos tratando de PPPoE é necessário também um bloco de endereçamento /64 para endereçar o túnel PPPoE. Não vamos nos ater aos conceitos básicos de endereçamento IPv6, mas vamos falar apenas que um /64 é o mínimo bloco de endereçamento a ser manipulável e todos os demais blocos são múltiplos de 8 desse /64. Exemplo: um /56 tem 8 bits a menos que um /64. Assim sendo, um /56 possui 256 redes /64 inclusas.

Resumindo: Precisamos para cada assinante residencial de 1 /64 e 1 /56.

== Documentação ==
É de extrema importância o planejamento e a documentação de uso de prefixos. Enquanto no IPv4 tínhamos uma escassez (que nos ensinou a ser econômicos), no IPv6 temos fartura. Porém, essa fartura pode atrapalhar