[GTER] PPPoE Offload Hw

Márcio Elias Hahn do Nascimento marcio at sulonline.net
Mon Jul 6 08:20:32 -03 2015


 

Aproveitando o gancho do Rubens e desviando ligeiramente o foco do
tópico, pergunto a quem está utilizando os routers da UBNT como BRAS com
PPPoE. 

Qual a quantidade de tuneis? Qual a banda? E está usando
Offloading do protocolo? 

Tenho um ER8-Pro na borda, mais ainda não
coloquei nada em PPPoE nele, no entanto o fato do offloading me tenta a
isso. 

---

Att 

Márcio Elias Hahn do Nascimento
(48) 8469-1819 /
3524-0700 - marcio at sulonline.net
INOC-BR: 52977*100
GERÊNCIA DE RECURSOS
DE TIC - Sul Internet [2] 

 [2] 

Em 06/07/2015 00:03, Rubens Kuhl
escreveu: 

> 2015-07-05 20:29 GMT-03:00 Roberto Alcântara
<roberto at eletronica.org>:
> 
>> Senhores, Estou precisando de um projeto
p/ conclusão de curso e gostaria de ouvir as opiniões técnicas sobre a
idéia de um hardware para PPPoE offload. Uma busca básica mostra que
hardware para PPPoE offload já existe [1], mas para DSLANs (e devem
haver roteadores que fazem o serviço em hardware). No entanto, nunca vi
ninguém dos provedores pequenos e médios utilizando nada parecido.
> 
>
Mas há, por causa do suporte do Edgerouter da UBNT à offload PPPoE,
>
introduzido na versão 1.5.0 (a última versão stable é a 1.7.0, que
>
adicionou também offload de GRE).
> 
>> O fato de tornar algo
inerentemente stateless (IP) em statefull (PPPoE) traz alguns
inconvenientes e outras vantagens, como já muito discutido na lista. Um
dos principais inconvenientes é o overhead de processamento, limitando a
quantidade de pps consideravelmente. O objetivo do projeto seria
minimizar overhead do tráfego em sessões PPPoE já estabelecidas, sem
modificar muita coisa na estrutura já existente. A idéia não é
substituir totalmente o concentrador/roteador, e sim reduzir o overhead
do PPPoE apenas (escopo limitado no momento). Em um cenário hipotético
de provedor que utiliza uma Cloudcore, este equipamento seria mantido
como roteador (mas sem precisar executar controle de banda, por
exemplo). Um equipamento adicional seria necessário (ex. RB450 ou um SoC
rodando um pppoe server) para tratar as requisições PPPoE e negociar os
IDs das sessões, autenticar, conversar com radius, etc. A interface por
onde chega o tráfego dos clientes seria movida p/ o acelerador. A saída
do acelerador seria conectada ao roteador. Nesta mesma rede estaria o
concentrador PPPoE (ou em uma interface adicional). O equipamento
monitoraria os frames e, enquanto não houvesse uma sessão estabelecida,
encaminharia-os para o concentrador PPPoE normalmente. Uma vez
estabelecida a sessão, o equipamento assumiria, controlaria a banda da
sessão e encaminharia os datagramas, desencapsulados, p/ o roteador, à
exceção dos pacotes de controle ppp. Um problema que precisaria de
tratamento seria o timeout no concentrador, já que após o
estabelecimento da sessão novos frames não chegariam até ele. O que mais
vocês veem como impeditivo ou complicador na proposta? A implementação
nem é a questão agora, mas o engine seria implementado em um fpga.
Também não há planos de tornar isso comercial, mais fácil virar
opensource ;)
> 
> Algumas das formas de criptografia talvez
impossibilitem essa arquitetura
> dupla...
> 
> ... sobre FPGA, era
exatamente o cerne do Unisphere, depois Juniper série
> E, depois
integrado aos outros produtos da Juniper; me parece bastante
> factível
implementar o processamento do PPPoE num gate array.
> 
> Rubens
> --
>
gter list https://eng.registro.br/mailman/listinfo/gter [1]



Links:
------
[1] https://eng.registro.br/mailman/listinfo/gter
[2]
http://www.sulinternet.net



More information about the gter mailing list