[GTER] MAC PON x MAC PPPoE na OLT Fiberhome

Fri Jan 18 10:57:54 -02 2019

Antes de mais nada:
 -> PPP é coisa do CAPETA!
O cara que toma decisões técnicas em uma empresa que inicia uma rede
zerada, sem legado(nem operacional nem administrativo), e escolhe iniciar
com PPP tem que apanhar!

Feito o desabafo, vamos lá:

Broadcast não é problema. É algo normal. Previsto dentro dos protocolos do
IP e Ethernet.
Broadcast STORM é um PROBLEMA, ele só acontece porque tem alguma coisa que
foi feita errada ou foi deixado de fazer...

Numa rede PPP também se tem Broadcast! Broadcast L2, mas é broadcast.
Assim como numa rede DHCP, o processo de discovery é iniciado em broadcast
(o PADI eu tenho certeza, e acho que o PADR também.)

E tanto em ambientes PPP quanto no DHCP(e até IP estático), seus ativos de
rede podem ser configurados para redirecionar e filtrar esse pacotes
broadcast.
Exemplos?
 - Com DHCP, presumindo que teu(s) server(s) ou relay(s) de DHCP só estão
no centro da rede, não faz sentido que os requests de DHCP sejam
encaminhados para qualquer outro lugar que não o centro da rede, correto? E
no PPPoED é a mesma coisa.
Isso é até uma questão de segurança. Em WISP, client isolation já faz isso.
E no FTTx isso é intrínseco do PON.

- Falando de Broadcast de ARP, em um ambiente de proxy-arp, quem vai ter
que responder as resposta de quem?
  - CPE cliente vai ter que responder "Who-has?" de outras CPEs clientes?
    NÃO
  - CPE cliente vai ter que responder "Who-has?" dos Gateways/DHCP-servers?
    SIM
  - Gateways/DHCP-Servers vai ter que responder "Who-HAs?" dos CPEs cliente?
    SIM, e vai responde as perguntas que são para ele, e para todos os
demais hosts na rede(por isso Proxy-ARP).

Então, o que tem que se fazer é ajustar os seus ativos para que isso seja
assim.
Pode ser feito com MAC-ACL manualmente, automagicamente de maneira
scriptada.
Ou com protocolos e features de equipamentos que podem te ajudar com isso.

Um lance que eu SEMPRE DIGO sobre IPoE:
Cá no Brazil ISPs acham que IPoE é coisa nova... Mas isso é coisa nova só
para ISPs mesmo!
Em redes corporativas maiores protocolos e recursos como:
-802.1x, com vlan dinâmica e shapping dinâmico são amplamente usadas em
redes wifi corporativas.
-DCHP Snooping, DCHP Option 82, IP Source Guard, em uma rede corporativa
grande, se você não utilizar, você fica louco em pouquinho tempo.

Resumo da ópera?
 * Colocar uma rede para rodar dum jeito que "tá funcionando" é uma coisa...
   Ligar o equipamento e deixar ele na configuração baunilha vai
funionaAaAar...
 * Colocar uma rede para funcionar do jeito correto, é outra!
   E para colocar "do jeito correto" tem que ter um trabalhinho extra tanto
em PPP quanto em IPoE.

Em qui, 17 de jan de 2019 às 23:23, Lista <lista.gter at gmail.com> escreveu:

> @Douglas,
> Grato pela suas explicações, entretanto vejo uma questão no aumento desta
> rede, a  volumetria de trafego sendo gerado neste segmento conforme vai
> crescendo, broadcast storm lá nas alturas.
> Uma solução para isto, e talvez melhor do que uma tecnica bem legada , hj
> seria o uso do PPPOE, isto resolve seu problemas de comunicação na mesma
> porta, mas ok, entendi, vc talvez seja fã do dhcp, mande com mascara /32, e
> ta feito.
>
>
> Em segunda-feira, 7 de janeiro de 2019, Douglas Fischer <
> fischerdouglas at gmail.com> escreveu:
>
> >  Então senhor lista.gter
> >
> > Na verdade não é especificamente para FTTx, e sim, para qualquer tipo
> > tecnologia de rede que simule barramento.
> > Isso inclui Rádio, FTTx, Docsis, Metro Ethernet...
> >
> >
> > Nos equipamento de L2 configura-se features que façam com que os clientes
> > só consigam conversar com o Gateway.
> >    Isso pode ser feito por exemplo com:
> >      - MAC-ACL.
> >      - Private-Vlan.
> >      - Client Isolation no Wireless.
> >      - E nos casos de FTTX, isso é inerente ao protocolo,
> >        pois cliente não enxerga cliente diretamente(estando na mesma
> porta
> > PON).
> >
> > No Gateway ativa-se a função de Proxy-ARP para IPv4 e
> > NeighborDiscoveryProxy para IPv6.
> >
> > Em uma explicação muito sucinta, o que o Proxy-ARP e NDP fazem é 'mentir'
> > as associações entre endereço L3(IPv4 e IPv6) e L2(Mac-Address).
> > Ou seja:
> > digamos que o cliente Zézinho está na mesma porta PON do cliente
> Joãzinho,
> > e digamos que eles tenham pego os IPs:
> > - Zézinho - 200.160.0.8
> > - Joãozinho - 200.160.0.10
> > Ambos com o Gateway 200.160.0.1
> >
> > Digamos que eles queirm fazer um acesso Peer-to-Peer entre eles.
> >  - O TP-Link do Zézinho vai mandar um "Who has 200.160.0.10? tell
> > 200.160.0.8"
> >  - E a mesma coisa vai acontecer com o TP-Link do Joãozinho, mandando
> "Who
> > has 200.160.0.8? tell 200.160.0.10"
> > Mas, como eles não se falam diretamente, o Roteadores eles nunca vão
> > receber esses pacotes, e nunca vão responder.
> >
> > Ou seja:
> > Desse jeito eles não vão conseguir conversar entre si.
> >
> > Como resolver isso?
> > Ativando Proxy-ARP e Neighbor Discovery Protocol.
> > Aí oque o Gateway faz?
> > Ele responde os ARP-Requests mentindo que o MAC do 200.160.0.8 e o do
> > 200.160.0.10 é o MAC dele mesmo...
> >
> > Assim as comunicações Unicast do 200.160.0.8 para o 200.160.0.10 ele vai
> > mandar para o MAC do Gateway, que vai reencaminhar para o 200.160.0.10.
> >
> > P.S.: Uma questão de semântica que ajuda bem a entender é que "Proxy" em
> > inglês significa procurador. Alguém que representa o outro.
> >
> >
> >
> > Essa solução de Proxy-ARP foi e é bastante usada em Campus LAN em alguns
> > cenários que exigem alguma segurança.
> >
> > Existem implementações mais requintadas de Proxy-ARP em que o Gateway, ao
> > invés de responder com o próprio MAC as perguntas de ARp-Request, ele
> > responde com um MAC para cada IP daquele segmento em que ele é o
> Proxy-ARP.
> > Já ví isso sendo usado em ambientes de Firewall de Datacenter em
> > comunicação Leste-Oeste por exemplo...
> >
> >
> >
> >
> > Em sáb, 5 de jan de 2019 às 01:54, Lista <lista.gter at gmail.com>
> escreveu:
> >
> > > @DouglasFiaher, fiquei um tanto quanto curioso na relação do uso de
> proxy
> > > -arp para fttx, poderia me explicar um pouco mais sobre o uso de tal
> > > emprego?
> > > Obg
> > >
> > > Em quinta-feira, 20 de dezembro de 2018, Rafael Lemos <
> > > rafael at telemulti.net>
> > > escreveu:
> > >
> > > > Eu estava querendo acreditar que não precisava sacrificar mais
> algumas
> > > > madrugadas.
> > > >
> > > > Mas já vi que se não me debruçar, não rola.
> > > >
> > > > Mesmo assim agradeço a atenção de vocês!
> > > >
> > > > Boas festas e felicidades para usted e os teus!
> > > >
> > > > Em qui, 20 de dez de 2018 às 11:41, Lucas Willian Bocchi <
> > > > lucas.bocchi at gmail.com> escreveu:
> > > >
> > > > > Bom, então o primeiro mac você já tem, que seria o mac do
> equipamento
> > > de
> > > > > acesso. Se esse equipamento funcionar como uma bridge, você pode
> ver
> > a
> > > > > tabela de learning dela e tentar achar o mac associado a porta. Só
> > que
> > > > como
> > > > > cada porta tem mais de um mac, vai ficar complicado. Provávelmente
> tu
> > > vai
> > > > > conseguir essa informação só lá no lado do cliente, e olhe lá.
> > > > > --
> > > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > > >
> > > >
> > > >
> > > > --
> > > > Atenciosamente,
> > > >
> > > > Rafael Alves Lemos
> > > > Telemos Multimídia LTDA
> > > > 61 - 98559290
> > > > www.telemulti.net
> > > > --
> > > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > > >
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> >
> >
> > --
> > Douglas Fernando Fischer
> > Engº de Controle e Automação
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação