[GTER] MAC PON x MAC PPPoE na OLT Fiberhome
Lucas Willian Bocchi
lucas.bocchi at gmail.com
Wed Jan 9 08:34:36 -02 2019
Apesar de ser padrão, nem todo equipamento suporta isso (é igual RFC:
existe mas tem vendor que não segue). Por enquanto, o que eu uso e acho
funcional (em vários vendors, inclusive alguns bem tabajaras) é uma vlan
pra cliente corporativo que precisa de comunicação com os clientes finaisi,
inclusive os que estão na tua rede (sites, etc, etc), corporativos isolados
e residenciais isolados. Esse negócio de equipamento conversando dentro da
rede é um convite delicioso pra uma enorme botnet. Os clientes são muito
chatos, tem nego que usa 5460 ainda do tempo do wifi e nao quer trocar de
jeito nenhum por que funciona o equipamento. Pra quê trocar? Não é fácil.
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
>
More information about the gter
mailing list