[GTER] MAC PON x MAC PPPoE na OLT Fiberhome

Tue Jan 8 17:18:49 -02 2019

Muito interessante Pablo!

Fiquei aqui imaginando...
Nesse cenário, não ficaria muito distante de colocar a SuperVlan como
Elemento L3 de gateway da rede.
Alguém já tentou algo assim?

Em ter, 8 de jan de 2019 às 01:38, Pablo R. Ferretti <cco at velloznet.com.br>
escreveu:

> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>

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