[GTER] MAC PON x MAC PPPoE na OLT Fiberhome

Douglas Fischer fischerdouglas at gmail.com
Mon Jan 21 09:58:31 -02 2019 

PPP é o legado do legado que influenciou o legado!

Vamos lembrar de como eram os legados da redes?
- E3, E2, E1, DS0 fracionados.
 - Frame-Relay, x.25.
 - ISDN PRI e BRI.
 - Dial-UP
 - PPPoE, PPPoA(quem lembra desse tempo da BrT?)


O protocolo que andava tranquilamente por cima de todas elas era o maldito
PPP.
E assim a decisão de se usar PPP era quase óbvia.

As grandes que hoje usam PPP em FTTx é por conta de legado, principalmente
de Sistema.
Mas se pudessem, tenho certeza que não usariam(não é à toa que tem grande
migrando FFTx para IPoe).

E mesmo as que usaram PPP com DSL e FTTx, não cometem a burrice de jogar o
controle de banda para cima do PPP.




E hoje vejo por aí que as pessoas saem implantando redes sem legado em PPP
por motivos como:
- "Na empresa que eu trabalhava era PPP, então vou fazer igual..."
- "Eu ouvi falar que todo mundo usa PPP, então vou usar PPP também..."
- "Todos os vídeos que ví na internet que ensinam PPP, nunca ví nenhum
vídeo desses Youtubers falando desse tal de IPoE."

Essa decisão tem que ser mais embasada do que achismos e vídeos da Internet!




Em sex, 18 de jan de 2019 às 23: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
>


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

More information about the gter mailing list