[GTER] Duvida arquitetura PTT

[Eduardo Schoedler]

Mikrotik só funciona com /31 se fizer gambiarra.
Infelizmente, dependendo do tipo de cliente que você tem, precisa usar
/30 mesmo.
Eu nem me arrisco a usar /127 com esses equipamentos.

--
Eduardo Schoedler


Em 29 de setembro de 2017 11:34, Lucas Willian Bocchi
<lucas.bocchi at gmail.com> escreveu:
> Perfeito! Faço isso aqui...
>
> Em 29 de setembro de 2017 11:15, Lista <lista.gter at gmail.com> escreveu:
>
>> pq não usar rf1918 ou endereçamento /31 invés de /30 para interfaces wan,
>> vc disponibiliza algum bloco de ip para seu cliente dedicado ou ele navega
>> pelo /30?
>>
>> Em 29 de setembro de 2017 10:44, Juliano Sathler <juliano at novonet.com.br>
>> escreveu:
>>
>> > Bom dia!
>> >
>> > Meu cenário é de links dedicados.
>> >
>> > Hoje usamos um /30 para a WAN de cada cliente, nem precisa falar quanto
>> IP
>> > estamos desperdiçando.
>> >
>> > Gostaria de manter cada cliente na sua VLAN porem compartilhando um bloco
>> > maior na WAN de forma a otimizar o uso de Ipv4.
>> >
>> > VLAN Translate cria um problema que é cliente falando com outro cliente,
>> > fiz uns testes aqui e isso não funcionou. Inclusive na apresentação do
>> PTT
>> > eles descartaram esta solução pelo mesmo motivo.
>> >
>> > Atenciosamente,
>> > Juliano Sathler
>> >
>> > -----Original Message-----
>> > From: gter [mailto:gter-bounces at eng.registro.br] On Behalf Of Douglas
>> > Fischer
>> > Sent: sexta-feira, 29 de setembro de 2017 09:10
>> > To: Grupo de Trabalho de Engenharia e Operacao de Redes <
>> > gter at eng.registro.br>
>> > Subject: Re: [GTER] Duvida arquitetura PTT
>> >
>> > Essa técnica que o Rubens citou é(se não me engano) a mais utilizada em
>> > ambientes IPoE(DHCP / nãoPPPoE).
>> >
>> > Seria esse o seu cenário @Juliano?
>> >
>> > Em 28 de setembro de 2017 20:18, Shine <eshine at gmail.com> escreveu:
>> >
>> > > No caso de Cisco, bridging domain + VLAN translation deve ser uma
>> > > saída que funciona para a maioria das situações. Acho que a super-vlan
>> > > do Huawei deve seguir o mesmo princípio, mas não tive chance de ler
>> > ainda sobre isso.
>> > >
>> > > Se os seus clientes usam portas dedicadas para eles, VLAN translation
>> > > simples deve ser viável, conforme o Romeu Medeiros apontou. Usa-se uma
>> > > VLAN para ser o "ATM". Como a amarração é feita no nível da porta
>> > > **acho** que não deve ser difícil achar um switch que execute essa
>> > tarefa.
>> > > No caso de usar trunking em uma única porta de dois clientes no mesmo
>> > > domínio de broadcast, acho que daí vai depender do fabricante fazer
>> > > uma recirculação interna, senão vai ter que usar alças de caixão
>> > > mesmo... uma idéia deselegante.
>> > >
>> > > A idéia do Rubens também é interessante, usa-se um proxy arp no
>> > > promiscuous e ele encaminharia os pacotes. Não e uma técnica escalável
>> > > para um IX, mas para um deployment menor seria uma boa saída também.
>> > > Nunca testei, mas se você já tiver o equipamento, por que não tentar?
>> > >
>> > >
>> > > Em 28 de setembro de 2017 11:27, Juliano Sathler
>> > > <juliano at novonet.com.br>
>> > > escreveu:
>> > >
>> > > > Bom dia!
>> > > >
>> > > >
>> > > >
>> > > > Galera tenho uma dúvida de como o PTT consegue ter a mesma sub-rede
>> > > > com cada participante tendo a sua VLAN especifica.
>> > > >
>> > > >
>> > > >
>> > > > Tenho um cenário onde esta topologia iria me ajudar a salvar muito
>> > > > Ipv4
>> > > que
>> > > > é usado na WAN dos clientes corporativos.
>> > > >
>> > > >
>> > > >
>> > > > Pensei inicialmente em private vlan, porem em teoria os
>> > > > participantes não poderiam falar com os demais por estarem em vlans
>> > > > distintas, porem todos falariam com o gateway.
>> > > >
>> > > >
>> > > >
>> > > > No huawei tem um conceito de super-vlan (que pelo o que eu li faria
>> > > > isso) porem no cisco não consegui encontrar algo parecido.
>> > > >
>> > > >
>> > > >
>> > > > Alguem teria uma sugestão?
>> > > >
>> > > >
>> > > >
>> > > > Atenciosamente,
>> > > >
>> > > > Juliano Sathler
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > 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
>> >
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter



-- 
Eduardo Schoedler