[GTER] MAC PON x MAC PPPoE na OLT Fiberhome
Felipe Trevisan
fetrevisan at gmail.com
Mon Jan 21 14:12:37 -02 2019
" 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
>
More information about the gter
mailing list