[GTER] MAC PON x MAC PPPoE na OLT Fiberhome

Douglas Fischer fischerdouglas at gmail.com
Mon Jan 21 19:04:05 -02 2019 

"Onde ficaria o controle de banda? Na porta da onu ou do switch onde o
cliente está ligado?"
EXATAMENTE!
E eles usam assim em redes DSL, onde quem faz esse controle é DS-LAN.
Usam isso em FTTx onde quem faz esse controle é a OLT.
E já vi gente trabalhando para fazer isso em via-rádio...


"E quando vc tem mais de um  serviço, exemplo, banda de 50 mega mais tv e
voz? Libera 70 mega e prioriza tv e voz em detrimento da banda larga?"
Se você tá fazendo Triple Play!, faça isso usando os recursos da OLT para
isso!
Cada fabricante implementa de um Jeito, alguns com formas mais facilitadas
e outras mais roots.
Mas no pior dos casos, Internet e TV andam em Vlans Separadas. Faça esse
controle em cada Vlan.


P.S.: Pelamor dos meus filhinho, não vão querer fazer isso na unha!
      Automatizem o processo!
      Não contratem sistema de gestão que não integra com a OLT!


Em seg, 21 de jan de 2019 às 15:52, Felipe Trevisan <fetrevisan at gmail.com>
escreveu:

> " 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."
>
> Onde ficaria o controle de banda? Na porta da onu ou do switch onde o
> cliente está ligado? E quando vc tem mais de um  serviço, exemplo, banda de
> 50 mega mais tv e voz? Libera 70 mega e prioriza tv e voz em detrimento da
> banda larga?
>
>
> abs,
>
>
> On Mon, Jan 21, 2019 at 10:50 AM Douglas Fischer <fischerdouglas at gmail.com
> >
> wrote:
>
> > 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
> > --
> > 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