[GTER] MAC PON x MAC PPPoE na OLT Fiberhome

Tue Jan 8 17:17:02 -02 2019

@Henrique
Faz sentido!
Mas nesse cenário, você não vai ter nenhum elemento entre os dois clientes
para fazer qualquer tipo de controle de camada 3.
Uma ACL permitindo ou bloqueando algo que seja da política de segurança do
provedor.

E em ambientes aonde se há alguma preocupação com segurança, isso tende a
se tornar um impeditivo para esse cenário.

Em seg, 7 de jan de 2019 às 22:39, Henrique Marks <
henrique.marks at datacom.ind.br> escreveu:

> Para a comunicação do Zezinho com Joãozinho, numa rede Layer 2 GPON (que
> não é Ethernet...), não é melhor usar o modo TLS e permitir a comunicação
> entre diferentes clientes no mesmo, ou entre PONLinks ?
>
> Acho que é a solução mais adequada para a tecnologia. Não quer dizer que
> não se possa fazer na Ethernet. Em geral as OLTs tem funções nas duas redes
> mesmo, então pode-se fazer ocasionalmente, dos dois modos. Mas se você
> crescer sua rede L2 nas portas Ethernet, não vai querer que o Proxy ARP
> atue, por exemplo, no lado do Uplink da sua rede L2 (apenas no downlink, em
> direção a rede PON). Daí o uso de TLs ser mais interessante.
>
>
> ----- Mensagem original -----
> > De: "Douglas Fischer" <fischerdouglas at gmail.com>
> > Para: "Grupo de Trabalho de Engenharia e Operacao de Redes" <
> gter at eng.registro.br>
> > Enviadas: Segunda-feira, 7 de janeiro de 2019 11:51:47
> > Assunto: Re: [GTER] MAC PON x MAC PPPoE na OLT Fiberhome
>
> > 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
>
> --
> Dr. Henrique Marks
> henrique.marks at datacom.ind.br
> R. América, 1000 - Eldorado do Sul - RS
> CEP: 92990-000 - Brasil
> Fone: +55 51 3933 3000 - Ramal 3466
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

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