[GTER] MAC PON x MAC PPPoE na OLT Fiberhome

Mon Jan 7 23:21:55 -02 2019

Boa noite!

Quando utilizamos DHCP entregando grandes blocos /22 ... /21 ... é necessário
desabilitar a segurança padrão da OLT para que permita a comunicação entre os
host's do mesmo bloco, e também aplicar ACL L3 realiza o bloqueio do trafego não permitido
de acordo com a politica e boas praticas, utilizando a feature de controle de banda
UPSTREAM que é nativo do protocolo GPON quem faz isso é o T-CONT, para o DOWNSTREAM
é utilizado o sistema de filas controlando o GEMPORT, podendo ser controle individual caso
utilize mais de um GEMPORT exemplo em aplicações triple-play, na OLT ZTE a sintax para desativar
a proteção é:

ZXAN(config)# security port-protect disable                     # desabilita a proteção global da OLT
ZXAN(config)# security usercommunication control enable         # habilita o controle de qual VLAN pode ter essa comunicação
ZXAN(config)# security usercommunication svlan 200 cvlan 200    # defini qual vlan está liberada
ZXAN(config)# interface supervlan 1                             # define qual supervlan irá gerenciar essas conexões
ZXAN(config-if)# !
ZXAN(config)# vlan 200
ZXAN(config-vlan)# supervlan 1
ZXAN(config-vlan)# !
ZXAN(config)#

Essa mesma configuração pode ser utilizada por exemplo para entregar um serviço de Clear-Channel, em uma vlan dedicada,
com suas configurações especificas. 

Pablo R. Ferretti

----- 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