Homem monta um pequeno provedor de internet em casa para entender como funciona uma rede GPON e comemora: “foi muito divertido construir”

Usuário do Reddit montou um laboratório GPON em casa e encontrou dificuldades com ONTs, TR-069, documentação e ajuste de MTU.

Um usuário do Reddit resolveu montar um pequeno laboratório de rede em casa para entender, na prática, como funciona a infraestrutura GPON usada por provedores de internet via fibra óptica. O projeto não tinha a intenção de virar uma operadora real, mas acabou reproduzindo parte da lógica usada por ISPs, com OLT, ONT, splitter óptico, roteador MikroTik e gerenciamento remoto.

O resultado foi um rack compacto, montado apenas para estudo, capaz de alimentar uma ONT com internet por fibra. Segundo o autor da publicação, a rede funcionou bem durante os testes. A parte mais trabalhosa, porém, não foi ligar os equipamentos. Foi entender por que uma rede GPON é tão diferente de uma rede Ethernet comum.

Durante o processo, ele encontrou documentação limitada, diferenças de comportamento entre ONTs de fabricantes diferentes, problemas envolvendo TR-069 e uma falha de MTU que só foi identificada após análise de pacotes com tcpdump.

My tiny ISP
by
u/Apprehensive-Net-323 in
HomeNetworking


 

Um rack pequeno para simular uma rede de provedor

my tiny isp v0

A lista de equipamentos inclui uma OLT VSOL V1600GS-R, um roteador MikroTik hEX, um conversor de mídia TP-Link MC220L, um splitter óptico 1:8, um atenuador óptico de 10 dBm, uma ONT ZTE F6201B e um Raspberry Pi R3S usado para monitoramento e execução de aplicações em Docker.

Tudo foi instalado em um rack modular Mod10 impresso em 3D.

A OLT é o equipamento central do projeto. Em uma rede GPON, ela fica do lado da operadora e controla a comunicação com os equipamentos ópticos dos clientes. O modelo usado pelo autor, a VSOL V1600GS-R, é uma OLT compacta de uma porta PON, com uplink 10GE e suporte a divisão óptica de até 1:64, segundo a própria VSOL.

Na outra ponta fica a ONT, que recebe o sinal óptico e entrega conexão de rede ao usuário final.

No laboratório, o autor usou a rede apenas como ambiente separado de testes. A rede principal da casa dele continua em outro rack.

GPON não se comporta como Ethernet comum

A primeira surpresa relatada pelo autor foi a dificuldade de encontrar documentação realmente útil sobre o processo.

Ele afirma que há vídeos ensinando a configurar OLTs parecidas, mas muitos seguem uma lógica de comandos prontos: faça isso, depois aquilo, e a conexão passa a funcionar. Para quem quer entender o que cada etapa faz, esse tipo de conteúdo deixa lacunas.

A diferença aparece porque GPON não é apenas “Ethernet pela fibra”.

Em uma rede Ethernet tradicional, o administrador costuma lidar com portas, VLANs, DHCP, roteamento e regras de firewall em um cenário mais direto. Em uma rede GPON, entram outros elementos: OLT, ONU, ONT, perfis de serviço, autenticação do equipamento óptico, parâmetros específicos do fabricante e gerenciamento remoto.

O autor diz que esperava algo simples: conectar um cabo a uma porta com servidor DHCP e obter internet. O laboratório mostrou que o caminho era menos óbvio.

Quatro ONUs para entender as diferenças

Para aprender mais, o usuário comprou quatro ONUs de marcas e modelos diferentes.

O teste mostrou que equipamentos compatíveis com GPON podem exigir configurações diferentes. Segundo ele, alguns modelos precisam ser tratados de maneira específica, mesmo quando cumprem a mesma função básica dentro da rede.

Esse ponto ajuda a explicar uma prática comum entre provedores: a homologação de poucos modelos de ONTs e ONUs.

Quando uma operadora escolhe equipamentos padronizados, ela reduz variáveis no suporte, consegue prever melhor o comportamento dos dispositivos e facilita o gerenciamento remoto. Também pode negociar lotes maiores com fornecedores.

Para o usuário final, isso normalmente aparece como uma limitação: nem sempre é simples trocar a ONT da operadora por outro modelo comprado por fora. Para o provedor, essa padronização reduz problemas técnicos.

TR-069 foi uma das partes mais complicadas

Outro trecho relevante do relato envolve o TR-069, também conhecido como CWMP. O protocolo é usado para comunicação entre equipamentos instalados no cliente e um servidor de autoconfiguração, chamado ACS.

Na prática, ele permite que um provedor configure, monitore e atualize remotamente equipamentos compatíveis.

No laboratório, o autor usou o GenieACS, uma solução aberta para gerenciamento TR-069. O próprio projeto descreve o GenieACS como um ACS leve e de código aberto para provisionamento e gerenciamento de dispositivos compatíveis com TR-069.

A parte problemática é que suporte ao protocolo não significa comportamento idêntico.

Segundo o autor, ONTs compatíveis com TR-069 não expõem necessariamente os mesmos parâmetros, com os mesmos nomes, nem aceitam as mesmas formas de configuração. Alguns fabricantes também implementam parâmetros proprietários, cuja documentação não costuma ser pública.

Ele compara os dados expostos pela ONT a uma estrutura de chaves e valores. Algumas informações podem ser apenas leitura. Outras podem ser alteradas e aplicadas para modificar o comportamento do equipamento.

Esse ponto foi um dos aprendizados centrais do projeto: mesmo quando existe um padrão, cada fabricante pode adicionar camadas próprias.

Uma ONT só conectou com credenciais encontradas em documento externo

O caso mais curioso envolveu a ONT ZTE F6201B mostrada no rack.

Segundo o autor, ela só conseguiu se conectar ao servidor GenieACS depois que ele configurou usuários e senhas fixos encontrados em um documento publicado no Scribd. Quando ele criava suas próprias credenciais, a ONT simplesmente não estabelecia conexão.

Essa informação vem do relato do usuário e não deve ser tratada como uma regra geral para o modelo. Ainda assim, ela ilustra o tipo de obstáculo que pode aparecer em testes com equipamentos de operadora.

O problema não estava em ligar a fibra ou criar uma rede básica. Estava em fazer um equipamento específico se comportar como esperado em um ambiente controlado por ele.

O problema de MTU que exigiu tcpdump

A mesma ONT também apresentou um problema relacionado ao MTU.

Segundo o autor, a falha impedia a conexão adequada. Para entender o que estava acontecendo, ele precisou capturar o tráfego com tcpdump no servidor e analisar os pacotes.

A solução foi criar uma regra mangle no firewall para limitar o TCP MSS a 1360 bytes.

Esse detalhe mostra por que o projeto foi além de um rack visualmente curioso. O autor precisou investigar um problema real de rede, encontrar o ponto de falha e aplicar uma correção específica.

MTU e MSS são conceitos conhecidos por administradores de rede, mas costumam aparecer de forma invisível para o usuário comum. Quando há fragmentação, encapsulamento ou ajuste incorreto, serviços podem falhar sem uma mensagem clara de erro.

A documentação da OLT também não resolveu tudo

Segundo o relato, o autor precisou solicitar a documentação da OLT por e-mail.

O material chegou em um arquivo DOCX, mas não ajudou tanto quanto ele esperava. O documento serviu como referência básica, mas não eliminou a necessidade de pesquisa adicional.

Esse ponto reforça uma das conclusões do projeto: a parte prática de uma rede GPON pode ser pouco documentada para quem está fora do ecossistema de provedores.

Manuais públicos muitas vezes informam especificações, portas, capacidade e recursos. A rotina real de provisionamento, compatibilidade, modelos de ONT e ajustes finos tende a depender de documentação fornecida a integradores, provedores ou parceiros.

O aprendizado foi maior que o hardware

No fim, o ponto mais interessante do relato não é o tamanho do rack nem a lista de peças.

A história funciona porque mostra a distância entre “ter os equipamentos” e “entender a rede”.

O autor conseguiu montar uma pequena infraestrutura GPON funcional, mas o processo exigiu pesquisa, testes com ONUs diferentes, análise de pacotes, ajustes de MSS e tentativa de entender parâmetros que não estavam bem documentados.

Para quem trabalha com redes, o relato é um lembrete de que fibra óptica residencial não se resume ao cabo. Existe uma camada de provisionamento, autenticação, gerenciamento remoto e compatibilidade que quase nunca aparece para o usuário final.

Para quem acompanha hardware e infraestrutura, o projeto também mostra como homelabs podem ir além de servidores domésticos e NAS. Neste caso, o laboratório recriou uma parte do caminho que leva a internet por fibra até clientes reais, mas em uma escala pequena o suficiente para caber em um rack impresso em 3D.

Você também deve ler!

Entusiasta monta em casa uma rede de 10 Gb inspirada em infraestruturas de empresas

Postado por
Editor-chefe no Hardware.com.br/GameVicio Aficionado por tecnologias que realmente funcionam. Segue lá no Insta: @plazawilliam Elogios, críticas e sugestões de pauta: william@hardware.com.br
Siga em:
Compartilhe
Deixe seu comentário
Assine nossa Newsletter
Assine nossa newsletter e receba nossa seleção de conteúdo sobre tecnologia, games, IA e internet em seu email.
Veja também
Publicações Relacionadas
Img de rastreio
Localize algo no site!