[GTER] MAC PON x MAC PPPoE na OLT Fiberhome

Uesley Correa uesleycorrea at gmail.com
Sat Jan 19 08:48:29 -02 2019 

Douglas,

E é nova entre os ISP's Tupiniquins apenas. A NET por exemplo, roda sua
rede toda em cima de IPoE, a Tigo no Paraguay também. USA, Europa, Rússia,
Japão e outros rodam tudo em cima de IPoE também (redes grandes, pequenas
não tenho relato). Então é mais uma questão de cultura do que de alguém ser
"contra" o protocolo por simples desconhecimento do mesmo.

Att,

Uesley Corrêa - Analista de Telecomunicações
Instrutor Network Education
CEO Telecom Consultoria, Entrenamiento y Servicios
CEO Telecom Fiber Solutions


Em sex, 18 de jan de 2019 às 22:32, Lista <lista.gter at gmail.com> escreveu:

> Agora fiquei mais ainda intrigado com relação a sua afirmação sobre o
> PPPoE, por que deste ódio meu caro?
> Sobre o broadcast, concordo com a sua afirmação que em qualquer rede tem e
> SEMPRE haverá, porém vai de como limitamos os dominios de broadcast para
> uma melhor performance da rede.
>
> Entretanto, ainda assim vejo um flood no roteador principal que estará
> fazendo o proxy-arp dentro daquele segmento, e podendo sim ocorrer um
> broadcast storm, talvez impondo limites de storm, seria uma solução? não
> sei vai depender do tipo de rede, visto que isto poderia causar alguma
> baixa na performance em responder aos famosos "who has ?"
>
>
>
> Em sex, 18 de jan de 2019 às 11:47, Douglas Fischer <
> fischerdouglas at gmail.com> escreveu:
>
> > Antes de mais nada:
> >  -> PPP é coisa do CAPETA!
> > O cara que toma decisões técnicas em uma empresa que inicia uma rede
> > zerada, sem legado(nem operacional nem administrativo), e escolhe iniciar
> > com PPP tem que apanhar!
> >
> >
> >
> > Feito o desabafo, vamos lá:
> >
> > Broadcast não é problema. É algo normal. Previsto dentro dos protocolos
> do
> > IP e Ethernet.
> > Broadcast STORM é um PROBLEMA, ele só acontece porque tem alguma coisa
> que
> > foi feita errada ou foi deixado de fazer...
> >
> >
> > Numa rede PPP também se tem Broadcast! Broadcast L2, mas é broadcast.
> > Assim como numa rede DHCP, o processo de discovery é iniciado em
> broadcast
> > (o PADI eu tenho certeza, e acho que o PADR também.)
> >
> > E tanto em ambientes PPP quanto no DHCP(e até IP estático), seus ativos
> de
> > rede podem ser configurados para redirecionar e filtrar esse pacotes
> > broadcast.
> > Exemplos?
> >  - Com DHCP, presumindo que teu(s) server(s) ou relay(s) de DHCP só estão
> > no centro da rede, não faz sentido que os requests de DHCP sejam
> > encaminhados para qualquer outro lugar que não o centro da rede,
> correto? E
> > no PPPoED é a mesma coisa.
> > Isso é até uma questão de segurança. Em WISP, client isolation já faz
> isso.
> > E no FTTx isso é intrínseco do PON.
> >
> > - Falando de Broadcast de ARP, em um ambiente de proxy-arp, quem vai ter
> > que responder as resposta de quem?
> >   - CPE cliente vai ter que responder "Who-has?" de outras CPEs clientes?
> >     NÃO
> >   - CPE cliente vai ter que responder "Who-has?" dos
> Gateways/DHCP-servers?
> >     SIM
> >   - Gateways/DHCP-Servers vai ter que responder "Who-HAs?" dos CPEs
> > cliente?
> >     SIM, e vai responde as perguntas que são para ele, e para todos os
> > demais hosts na rede(por isso Proxy-ARP).
> >
> > Então, o que tem que se fazer é ajustar os seus ativos para que isso seja
> > assim.
> > Pode ser feito com MAC-ACL manualmente, automagicamente de maneira
> > scriptada.
> > Ou com protocolos e features de equipamentos que podem te ajudar com
> isso.
> >
> >
> > Um lance que eu SEMPRE DIGO sobre IPoE:
> > Cá no Brazil ISPs acham que IPoE é coisa nova... Mas isso é coisa nova só
> > para ISPs mesmo!
> > Em redes corporativas maiores protocolos e recursos como:
> > -802.1x, com vlan dinâmica e shapping dinâmico são amplamente usadas em
> > redes wifi corporativas.
> > -DCHP Snooping, DCHP Option 82, IP Source Guard, em uma rede corporativa
> > grande, se você não utilizar, você fica louco em pouquinho tempo.
> >
> >
> >
> > Resumo da ópera?
> >  * Colocar uma rede para rodar dum jeito que "tá funcionando" é uma
> > coisa...
> >    Ligar o equipamento e deixar ele na configuração baunilha vai
> > funionaAaAar...
> >  * Colocar uma rede para funcionar do jeito correto, é outra!
> >    E para colocar "do jeito correto" tem que ter um trabalhinho extra
> tanto
> > em PPP quanto em IPoE.
> >
> >
> >
> >
> > Em qui, 17 de jan de 2019 às 23:23, Lista <lista.gter at gmail.com>
> escreveu:
> >
> > > @Douglas,
> > > Grato pela suas explicações, entretanto vejo uma questão no aumento
> desta
> > > rede, a  volumetria de trafego sendo gerado neste segmento conforme vai
> > > crescendo, broadcast storm lá nas alturas.
> > > Uma solução para isto, e talvez melhor do que uma tecnica bem legada ,
> hj
> > > seria o uso do PPPOE, isto resolve seu problemas de comunicação na
> mesma
> > > porta, mas ok, entendi, vc talvez seja fã do dhcp, mande com mascara
> > /32, e
> > > ta feito.
> > >
> > >
> > > Em segunda-feira, 7 de janeiro de 2019, Douglas Fischer <
> > > fischerdouglas at gmail.com> escreveu:
> > >
> > > >  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
>

More information about the gter mailing list