UniFi chega ao Hacker News após uma correção de half-bridge PPPoE de 5 Gbps

A UniFi chegou ao Hacker News depois que a ArcBox Labs afirmou que um dispositivo OpenWrt separado levou sua conexão PPPoE de 5 Gbps além de um persistente gargalo do gateway. O resultado desafia uma expectativa básica em torno de hardware de rede premium. Um gateway com várias portas rápidas ainda pode ficar aquém quando um protocolo legado sobrecarrega seu caminho de processamento de pacotes.

A ArcBox afirma que seu UDM Pro Max teve dificuldade para se aproximar da velocidade total da conexão do escritório. Sua solução alternativa transfere a sessão PPPoE para um Banana Pi BPI-R4 Pro executando OpenWrt. O gateway UniFi então recebe o endereço IPv4 público por DHCP e continua a lidar com roteamento, regras de firewall, redirecionamento de portas e acesso remoto.

Isso parece uma divisão de trabalho limpa. No entanto, o projeto acrescenta outro dispositivo, scripts personalizados, entradas estáticas de vizinhos e um novo caminho de recuperação. A discussão no Hacker News também contestou várias alegações da publicação original, especialmente sua descrição do uso de PPPoE entre provedores americanos.

A história importante, portanto, não é um único teste de velocidade. É um conflito entre a promessa de um gateway integrado e o hardware especializado exigido para o processamento de pacotes em velocidades multigigabit. O resultado da ArcBox sugere que transferir uma função para fora do gateway pode restaurar o desempenho. Ele não estabelece que toda implantação UniFi deva adotar a mesma arquitetura.

A publicação no Hacker News expôs um gargalo restrito, mas caro

A ArcBox mudou onde o PPPoE é executado, não como o restante da rede UniFi opera.

PPPoE, ou Point-to-Point Protocol over Ethernet, encapsula tráfego PPP dentro de quadros Ethernet e frequentemente autentica um assinante de banda larga. Esse processo acrescenta uma etapa de encapsulamento e desencapsulamento entre a conexão de internet e o trabalho normal de roteamento do gateway.

O protocolo acrescenta uma combinação de oito bytes de cabeçalhos PPPoE e PPP. Esse pequeno aumento no tamanho do quadro não é o principal problema de desempenho. A questão maior é o processamento repetido de pacotes necessário para estabelecer e manter a sessão.

A ArcBox informou que seu escritório usava um serviço PPPoE de 5 Gbps atrás de um UDM Pro Max. Segundo seu relato técnico, o gateway nunca se aproximou da velocidade contratada e apresentou sinais de pressão na CPU. A empresa também afirmou que a carga afetava a estabilidade operacional.

Os números publicados descrevem uma lacuna maior em diversos gateways UniFi. A ArcBox diz que os resultados do UDM Pro e do UDM SE normalmente ficam entre 1.200 e 1.500 Mbps com PPPoE. Ela posiciona o UDM Pro Max entre 1.400 e 1.800 Mbps, enquanto o Enterprise Fortress Gateway supostamente alcança entre 1.400 e 2.400 Mbps.

Essas são observações da ArcBox, não benchmarks controlados de terceiros. A publicação não apresenta uma matriz completa de testes com tamanhos de pacotes, contagens de conexões, versões de firmware, medições de latência ou dados brutos reproduzíveis. Os leitores devem tratar cada faixa como um relato de campo.

Um resultado se destaca. A ArcBox afirma que o UniFi Cloud Gateway Fiber pode exceder 5.000 Mbps porque seu system-on-chip inclui aceleração PPPoE. As especificações publicadas pela Ubiquiti listam 5 Gbps de throughput de IDS e IPS para o gateway, embora esse número não verifique de forma independente o teste PPPoE da ArcBox.

O contraste cria a tensão central do artigo. A especificação agregada de roteamento de um produto não garante desempenho equivalente para todos os protocolos WAN. O hardware pode mover tráfego IP comum rapidamente, mas desacelerar quando o PPPoE direciona o trabalho por um caminho menos acelerado.

A própria Ubiquiti reconhece a limitação mais ampla. Sua orientação sobre velocidade descreve o PPPoE como intensivo em CPU e alerta que ele pode reduzir o throughput em comparação com DHCP ou um endereço estático.

A mesma orientação diz que o Threat Management e as Smart Queues podem reduzir o throughput em até 30%. Inspeção profunda de pacotes, regras de firewall, filtros de conteúdo e VPNs podem acrescentar mais pressão. Esses recursos competem pelos mesmos recursos de processamento que uma conexão PPPoE ocupada já consome.

Isso não significa que o PPPoE sempre limita gateways UniFi às faixas da ArcBox. Carga de trabalho, firmware, tamanho de pacote, serviços ativados e projeto de teste são todos relevantes. Mas mostra por que um benchmark bem-sucedido de LAN ou DHCP não pode resolver uma disputa de desempenho de PPPoE.

A reação no Hacker News ampliou essa distinção. Alguns participantes reconheceram o gargalo a partir de suas próprias conexões europeias de fibra. Outros contestaram a caracterização ampla do artigo de que o PPPoE é comum nas principais redes americanas de fibra e cabo.

Essa discordância importa porque delimita o problema atendido. O PPPoE continua relevante onde os provedores o exigem, mas não é uma explicação universal para serviços multigigabit lentos. Os usuários precisam identificar seu protocolo WAN antes de considerar a solução alternativa da ArcBox.

Por que um núcleo de gateway rápido ainda pode perder em velocidades multigigabit

Hardware multinúcleo não divide automaticamente uma sessão PPPoE entre todos os núcleos disponíveis.

Um roteador processa várias etapas para cada pacote. Ele recebe o quadro, reconhece o protocolo, remove ou adiciona encapsulamento, aplica decisões de roteamento e firewall, realiza tradução de endereços e encaminha o resultado.

Sistemas modernos aceleram partes desse caminho por meio de mecanismos dedicados. Esses componentes podem contornar o processamento caro em software para fluxos já estabelecidos. Quando um protocolo fica fora desse caminho acelerado, a CPU de uso geral precisa executar mais trabalho.

A ArcBox argumenta que essa é a fraqueza central que afeta seu UDM Pro Max. Seu relato diz que uma única sessão de banda larga frequentemente mantém o processamento PPPoE concentrado em um núcleo de CPU. Núcleos extras continuam úteis para outros serviços, mas não elevam automaticamente o limite desse caminho específico de processamento.

Isso explica um resultado de monitoramento que, de outra forma, seria confuso. Um gateway pode mostrar utilização total moderada da CPU enquanto um núcleo atinge seu limite. A conexão então deixa de escalar, mesmo que o dispositivo pareça ter capacidade agregada não utilizada.

A taxa de pacotes é importante além da largura de banda. Um fluxo de pacotes pequenos exige mais decisões por pacote do que a mesma largura de banda transportada em pacotes maiores. Portanto, um único número de teste de velocidade não consegue descrever todas as cargas de trabalho reais.

Recursos de segurança e gerenciamento de tráfego tornam esse limite menos previsível. A Ubiquiti afirma que ativar regras de QoS desabilita o offloading de hardware no gateway. Sua documentação de QoS estima uma redução de velocidade de 24 a 45% para tráfego acima de 1 Gbps, dependendo do modelo e das condições.

Isso cria uma escolha desconfortável para operadores. Eles podem buscar o maior número possível de throughput ou manter recursos que inspecionam, classificam e moldam o tráfego. A melhor configuração depende de se a prioridade é velocidade bruta de transferência, controle de latência, visibilidade ou segurança.

A solução da ArcBox evita que o gateway UniFi execute a etapa PPPoE. Ela não faz desaparecer todos os custos de processamento de pacotes. O gateway ainda lida com suas responsabilidades posteriores após receber o endereço público.

Essa separação é importante. Um roteador convencional colocado antes da UniFi poderia terminar o PPPoE e realizar tradução de endereços de rede. A UniFi então ficaria atrás de um endereço privado, produzindo double NAT, a menos que o sistema upstream oferecesse um modo de passthrough apropriado.

O double NAT pode complicar conexões de entrada, redirecionamento de portas, algumas redes privadas virtuais e a solução de problemas. Ele também pode tornar menos claro qual dispositivo controla o estado voltado ao público. A ArcBox queria descarregar o PPPoE sem abrir mão do endereço público no limite da UniFi.

O projeto de half-bridge visa precisamente essa lacuna. O dispositivo OpenWrt mantém a sessão voltada ao provedor, mas transfere o endereço IPv4 atribuído para o gateway downstream. A UniFi continua a enxergar esse endereço em sua interface WAN.

Esse arranjo se assemelha aos recursos de IP passthrough encontrados em alguns equipamentos de provedores. O repositório da ArcBox diz que os usuários não precisam do projeto quando seu terminal de rede óptica ou modem já suporta Advanced DMZ, IP Passthrough ou um modo comparável.

Portanto, o mecanismo resolve um problema restrito de sistemas. Ele separa a terminação PPPoE da propriedade do endereço público, evitando uma segunda camada de NAT. Isso é mais específico do que simplesmente colocar outro roteador à frente.

O half-bridge PPPoE move o trabalho difícil sem mover o IP público

O half-bridge funciona ao separar a propriedade da sessão da propriedade do endereço, uma separação que interfaces comuns de gateway raramente expõem.

Na arquitetura da ArcBox, o dispositivo OpenWrt conecta-se ao provedor e estabelece a sessão PPPoE. Ele autentica, recebe o endereço IPv4 atribuído e torna-se responsável por adicionar ou remover a encapsulação PPPoE.

Os scripts então removem esse endereço da interface PPP local. O OpenWrt disponibiliza o endereço ao gateway UniFi por DHCP em uma interface física downstream. Portanto, a WAN da UniFi recebe o endereço atribuído pelo provedor, em vez de um endereço de sub-rede privada.

O tráfego que retorna da internet ainda chega pela sessão PPPoE. O dispositivo de offload precisa determinar que o destino pertence à sua porta downstream. Em seguida, ele encaminha o tráfego para a UniFi, em vez de usar o endereço localmente.

A ArcBox publicou a implementação em um repositório de código aberto. O projeto usa um acionador hotplug do OpenWrt, um script shell principal, configuração DHCP, comportamento de proxy ARP e regras de filtragem de pacotes para coordenar a transferência.

Um script hotplug é executado quando a interface PPPoE fica online. Esse projeto orientado a eventos é importante porque as sessões do provedor podem se reconectar e receber um endereço diferente. A configuração precisa repetir a transferência sempre que o estado da WAN muda.

O repositório suporta entre uma e três instâncias PPPoE. Seu exemplo usa um Banana Pi BPI-R4 Pro e uma configuração dual-WAN, embora a ArcBox diga que outro hardware compatível com OpenWrt pode funcionar depois que os nomes das interfaces forem ajustados.

Segundo a ArcBox, esse arranjo excedeu 5.000 Mbps em seus testes. O repositório faz uma alegação mais ampla de que hardware adequado pode entregar mais de 3.000 Mbps por vários gateways UniFi. Nenhuma das alegações recebeu uma replicação independente publicada com equipamento equivalente.

O hardware do dispositivo de offload continua crucial. Transferir o PPPoE de um processador com baixo desempenho para outro processador fraco apenas deslocaria o gargalo. A plataforma selecionada pela ArcBox inclui um system-on-chip MediaTek voltado a redes e projetado para encaminhamento acelerado.

O OpenWrt descreve o offloading de fluxo por hardware como uma forma de enviar tráfego elegível por um mecanismo de processamento de pacotes, em vez do caminho completo de firewall, intensivo em CPU. Seu guia de offloading também alerta que o suporte de hardware varia conforme a plataforma.

Esse alerta impede uma generalização fácil. “Executa OpenWrt” não significa “acelera PPPoE a 5 Gbps”. Drivers, suporte do chipset, versão do firmware, topologia de rede e recursos ativados determinam se o caminho rápido realmente lida com o tráfego.

A descarga de fluxos também pode entrar em conflito com o controle de tráfego. O OpenWrt observa que a descarga por hardware é incompatível com alguns recursos de qualidade de serviço, incluindo o Smart Queue Management. Os operadores podem ganhar throughput, mas perder acesso ao tratamento de pacotes que reduz a latência relacionada ao congestionamento.

A transferência do IP público introduz outro comportamento incomum. A ArcBox afirma que a resolução de endereços do UniFi exigiu entradas de vizinhança estáticas no OpenWrt para uma comunicação confiável. O Address Resolution Protocol, ou ARP, associa um endereço IPv4 ao endereço Ethernet de um dispositivo no enlace local.

A ArcBox caracteriza as entradas adicionais como uma solução alternativa para o comportamento do UniFi. Essa descrição continua sendo a interpretação do autor do projeto. A Ubiquiti não validou publicamente a implementação nem aceitou a caracterização da ArcBox nos materiais citados.

Os scripts também adicionam dependências operacionais que um gateway integrado evita. Uma reconexão PPPoE, alteração de endereço, mudança de nome de interface, problema na ordem de inicialização ou alteração de firewall pode interromper a transferência. O monitoramento deve abranger ambos os dispositivos e o estado entre eles.

O design é inteligente porque preserva o papel útil do gateway. É complicado porque o endereço público parece pertencer ao dispositivo downstream, enquanto a sessão do provedor termina upstream. As equipes de suporte e os futuros administradores precisam entender essa divisão.

A Solução Desafia a Promessa de Gateway Integrado do UniFi

O verdadeiro adversário não é UniFi versus OpenWrt, mas simplicidade integrada versus desempenho especializado de processamento de pacotes.

O apelo do UniFi se baseia, em parte, na consolidação. Os administradores podem gerenciar switching, acesso sem fio, roteamento, visibilidade de tráfego e segurança por meio de uma interface consistente. Adicionar um equipamento PPPoE externo enfraquece essa vantagem, mesmo quando o gateway UniFi continua no controle.

A abordagem da ArcBox não substitui o firewall nem o controlador do UniFi. Ela introduz uma camada frontal especializada para um protocolo. Essa distinção explica por que o projeto pode atrair usuários que desejam manter sua configuração existente e o comportamento do endereço público.

A solução alternativa também expõe os limites dos rótulos de produto. “Pro”, “Max” e “Enterprise” sugerem capacidade crescente, mas a aceleração específica de protocolo não necessariamente segue a mesma hierarquia. A ArcBox argumenta que algumas plataformas de maior nível não têm o caminho de hardware relevante.

Essa afirmação exige verificação modelo a modelo. Os nomes dos chipsets, por si só, não descrevem todas as otimizações no firmware, nos drivers ou no software de processamento de pacotes. Ainda assim, a diferença relatada entre a capacidade de roteamento comum e o throughput PPPoE é consistente com o próprio alerta da Ubiquiti sobre a demanda de CPU.

O Cloud Gateway Fiber oferece o contraexemplo mais claro dentro da mesma família de produtos. A Ubiquiti lista interfaces duplas compatíveis com WAN de 10 gigabits e throughput de 5 Gbps para IDS e IPS. A ArcBox afirma que esse modelo também ultrapassa seu limite de 5 Gbps para PPPoE.

Se repetível, esse resultado sugere que a seleção de hardware pode resolver o problema dentro do ecossistema UniFi. Alguns usuários podem preferir migrar para um gateway com a aceleração necessária em vez de manter uma half-bridge externa.

Outros já possuem gateways caros ou precisam de recursos associados a outro modelo. Para eles, inserir um dispositivo de descarga dedicado pode ser menos disruptivo do que substituir o equipamento central. O cálculo envolve mais do que o throughput máximo.

O OpenWrt representa outra rota, não um concorrente uniforme. Um administrador poderia substituir completamente o roteamento UniFi por um sistema OpenWrt, uma distribuição de firewall dedicada ou outro roteador que apresente bom desempenho com PPPoE. Essa opção abre mão de partes diferentes da experiência integrada.

Uma mudança do lado do provedor oferece o resultado mais limpo. IP sobre Ethernet baseado em DHCP remove a carga de PPPoE do gateway do cliente. No entanto, os assinantes geralmente não podem determinar a arquitetura de acesso do provedor, e a disponibilidade da migração varia conforme a rede.

A discussão no Hacker News destacou essa variação geográfica. Um comentarista relatou um serviço de fibra simétrico de 4 Gbps que usa PPPoE e uma VLAN nos Países Baixos. Outros comentaristas disseram que a Xfinity não usa PPPoE e contestaram a referência do artigo original ao AT&T Fiber.

Essas objeções são substanciais. A rede de cabo da Xfinity não deve ser apresentada como uma implementação representativa de PPPoE. A correção não invalida o problema medido pela ArcBox, mas enfraquece a tentativa do post de descrever quão amplamente a solução alternativa se aplica.

A distinção entre tecnologia de acesso e tecnologia de sessão do assinante também merece cuidado. Fibra, cabo e DSL descrevem arquiteturas físicas ou de enlace, enquanto os provedores podem escolher diferentes sistemas de autenticação e atribuição de endereços acima delas. Uma conexão de fibra pode usar PPPoE, mas fibra não implica PPPoE.

Essa nuance muda a questão de compra. Um assinante multi-gigabit não deve perguntar apenas se um gateway tem portas de 10 gigabits. O comprador também precisa perguntar se o dispositivo acelera o protocolo WAN exigido pelo provedor enquanto executa os recursos de segurança desejados.

As especificações de hardware raramente tornam essa resposta evidente. Os números de throughput publicados podem refletir roteamento, IDS e IPS, desempenho de VPN ou tamanhos de pacote cuidadosamente definidos. O desempenho PPPoE pode permanecer sem documentação.

O trabalho da ArcBox pressiona os fornecedores a publicar resultados específicos por protocolo. Um gateway anunciado para conexões multi-gigabit deveria divulgar limites significativos com PPPoE, DHCP, identificação de tráfego, prevenção contra ameaças e QoS. Caso contrário, os compradores descobrem a limitação após a implantação.

O Que a Afirmação de 5 Gbps Ainda Não Estabelece

A ArcBox publicou uma implementação útil e um resultado plausível, mas não um benchmark completo que comprove desempenho universal.

A incerteza mais importante é a reprodutibilidade. O artigo apresenta faixas de velocidade e um limite atingido com sucesso, mas não fornece dados brutos suficientes para comparar latência, perda de pacotes, utilização de CPU, tamanhos de pacote ou desempenho sustentado.

Um resultado de teste de velocidade pode refletir o servidor selecionado, a capacidade do cliente, a contagem de conexões paralelas e as condições de rota. Testes de navegador em velocidades multi-gigabit também podem ficar limitados pelo cliente. Uma avaliação convincente incluiria várias ferramentas e geração de tráfego controlada em cargas de trabalho repetíveis.

O desempenho com pacotes pequenos merece testes separados. Alcançar 5 Gbps com pacotes grandes não garante a mesma capacidade de pacotes por segundo para tráfego DNS, chamadas de voz, jogos ou tráfego de ataque. Essas cargas de trabalho podem pressionar os caminhos de encaminhamento de forma diferente.

Os resultados de upload e download também devem aparecer separadamente. O encapsulamento e o desencapsulamento seguem direções diferentes, enquanto o comportamento de filas e drivers pode ser assimétrico. Um único número de destaque combinado oculta essas distinções.

O limite de segurança precisa ser examinado. O UniFi ainda recebe o endereço IPv4 público e executa o firewall, segundo a ArcBox. No entanto, o dispositivo OpenWrt continua diretamente envolvido em todos os pacotes da internet e executa scripts com controle sobre interfaces e filtragem.

Isso torna a manutenção de software no dispositivo de descarga parte do modelo de segurança da rede. Os administradores devem atualizar o OpenWrt, revisar os scripts, restringir o acesso de gerenciamento e verificar os padrões do firewall. O dispositivo não é apenas um cabo transparente.

O repositório usa a licença AGPL-3.0 e expõe sua configuração para inspeção. O código público melhora a auditabilidade, mas a publicação por si só não constitui uma revisão de segurança. As equipes de implantação continuam responsáveis por entender os comandos e suas consequências.

O comportamento em caso de falha é outra questão em aberto. Os operadores precisam saber o que acontece quando o PPPoE reconecta, a renovação DHCP falha, o endereço público muda ou o UniFi inicializa antes do dispositivo de descarga. Um design rápido que exige reparo manual após interrupções rotineiras tem um custo operacional diferente.

O IPv6 também exige tratamento separado. A explicação publicada se concentra fortemente na transferência do IPv4 público. Os provedores podem fornecer IPv6 por meio de delegação de prefixo vinculada à sessão PPP, e o caminho de delegação downstream precisa de sua própria validação documentada.

O multi-WAN aumenta o espaço de estados. O repositório da ArcBox suporta várias sessões, mas o failover exige mais do que colocar múltiplas interfaces online. A seleção de rotas, as verificações de integridade, o comportamento do endereço de origem, o encaminhamento de portas e a recuperação de sessões devem permanecer consistentes.

A solução alternativa de vizinhança estática é particularmente importante. O estado ARP manual pode resolver um problema específico de conectividade, mas também cria outra dependência em relação à identidade da interface e às mudanças de endereço. Testadores independentes devem verificar se todas as versões compatíveis do UniFi precisam do mesmo ajuste.

A descarga por hardware introduz concessões de recursos. O OpenWrt alerta que caminhos acelerados podem contornar o processamento necessário para alguns sistemas de QoS. Os usuários devem confirmar se sua contabilização, modelagem ou inspeção de tráfego desejada continua disponível no dispositivo de descarga.

O gateway UniFi ainda executa seus próprios serviços após a transferência. Se Threat Management, DPI ou QoS já limitarem o gateway abaixo da velocidade-alvo, a descarga PPPoE não removerá esse segundo gargalo. Cada estágio de processamento precisa de medição isolada.

Também não há compromisso oficial de compatibilidade. A Ubiquiti pode alterar o comportamento de DHCP, ARP ou WAN em uma versão futura. O OpenWrt pode alterar o comportamento de interfaces ou firewall. Os scripts da ArcBox precisariam então de manutenção.

Nenhuma dessas questões torna o conceito insustentável. Elas definem a diferença entre uma implantação bem-sucedida em laboratório ou escritório e uma arquitetura de rede geralmente sustentável. O projeto é mais forte como uma proposta de engenharia testável.

A interpretação mais segura é restrita. A ArcBox afirma ter deslocado o processamento PPPoE de um UDM Pro Max, mantido o endereço IPv4 público no UniFi e ultrapassado 5 Gbps usando um BPI-R4 Pro. A replicação independente ainda é necessária antes de tratar esse resultado como uma solução universal.

Três Sinais Decidirão se a Solução do Hacker News se Sustenta

Benchmarks independentes, evidências operacionais e a resposta do fornecedor determinarão se a descarga por half-bridge se tornará um padrão duradouro.

O primeiro sinal são testes reproduzíveis. Outros usuários precisam publicar resultados usando o mesmo gateway UniFi, um dispositivo OpenWrt comparável e um serviço PPPoE documentado de 5 Gbps ou mais rápido.

Testes úteis devem identificar versões de firmware, tamanhos de pacote, recursos de segurança habilitados, hardware do cliente e métodos de teste de velocidade. Eles devem informar ambas as direções, carga de CPU por núcleo, latência sob carga e recuperação após interrupção de sessão.

Uma replicação bem-sucedida reforçaria a afirmação central da ArcBox de que a terminação PPPoE é a restrição determinante. Resultados materialmente mais baixos ou instáveis sugeririam que o ambiente original se beneficiou de condições não capturadas no artigo.

O segundo sinal é a evidência de implantações mais longas. Uma half-bridge precisa sobreviver a reconexões do provedor, alterações de endereço, atualizações de software e ciclos de energia sem intervenção manual. Vários meses de operação revelariam mais do que outra captura de tela de throughput máximo.

Os operadores devem acompanhar o comportamento de concessões DHCP, a estabilidade do ARP, a delegação IPv6, o failover multi-WAN e o acesso remoto. Eles também devem documentar se atualizações do UniFi alteram a configuração estática de vizinhança necessária.

Uma operação estável levaria o projeto de uma solução alternativa interessante a um padrão de infraestrutura repetível. Trabalho frequente de recuperação tornaria a substituição do gateway ou o passthrough de IP pelo provedor mais atraentes.

O terceiro sinal é a resposta da Ubiquiti. A empresa poderia publicar benchmarks específicos de PPPoE, esclarecer quais gateways incluem aceleração ou melhorar o tratamento por software em modelos sem hardware dedicado.

Especificações claras ajudariam os compradores a associar um gateway ao seu provedor. Melhorias de firmware poderiam elevar o desempenho, mesmo que não consigam reproduzir um mecanismo de aceleração desenvolvido para esse fim. O silêncio deixaria os testes da comunidade como a principal fonte de orientação.

Os lançamentos de hardware também importam. Se futuros gateways UniFi incluírem aceleração PPPoE de forma consistente, o half-bridge se tornará uma ponte entre gerações de produtos. Se o suporte continuar limitado, a terminação externa poderá permanecer um projeto prático para conexões exigentes.

O debate no Hacker News já melhorou a história ao separar o mecanismo técnico válido de um contexto de mercado exagerado. Os exemplos de ISPs da ArcBox mereciam correção, enquanto sua arquitetura continua disponível para inspeção e testes.

Esse é o padrão correto para avaliar este projeto. Não o adote porque uma manchete diz “5 Gbps”, nem o descarte porque o PPPoE é incomum em partes dos Estados Unidos.

Primeiro, confirme que o provedor exige PPPoE. Em seguida, meça o gateway com seus recursos reais de segurança e tráfego ativados. Por fim, compare esses resultados com um teste de half-bridge controlado e documente como a rede se recupera de falhas.

Para leitores que acompanham a discussão no Hacker News, a próxima contribuição útil não é mais um argumento sobre se o PPPoE deveria existir. É um benchmark reproduzível que mostre onde está o gargalo, quais recursos permanecem com o offloading e se o projeto com dois dispositivos continua estável.