[GTER] MAC PON x MAC PPPoE na OLT Fiberhome

Douglas Fischer fischerdouglas at gmail.com
Fri Jan 11 11:52:06 -02 2019


Me chama para participar de um projeto desse!

É um sonho fazer algo assim acontecer!

Em qua, 9 de jan de 2019 às 15:34, Pablo R. Ferretti <cco at velloznet.com.br>
escreveu:

> Douglas eu também acho !
>
> Sim é possível e praticável, utilizar uma SuperVlan agregando
> vlan's provisionadas na OLT compartilhando um mesmo host L3 como gateway,
> como também
> é possível utilizar essa SuperVlan como um DHCPv4 / DHCPv6 Server
> utilizando um
> pool local ou relay, minha preferencia é de utiliza-lo como relay,
> utilizando um agente externo
> como o Kea-Dhcp, que faz a lease e reserva de host em mysql, utilizando
> alguns
> hooks disponíveis para compra no site do desenvolvedor é possível
> armazenar o log-legal
> atendendo o marco civil, e também prover autenticação utilizando o
> Option82 "circuit-id" para IPv4
> e o Option18 para IPv6.
>
> # vale lembrar... isso em OLT ZTE no software ZXR10 Versão 1.2.5P3 em
> diante.
>
> Att.
>
>
> 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: Terça-feira, 8 de janeiro de 2019 17:18:49
> Assunto: Re: [GTER] MAC PON x MAC PPPoE na OLT Fiberhome
>
> 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
> --
> 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



More information about the gter mailing list