[GTER] Entrega de IPv4 Fixo /32

[Andre Almeida]

Digamos que exista um /27 sendo usado para infraestrutura.
Servidores, etc....

Esse /27 tem um IP de network e um de broadcast (que serão utilizados
somente para aquele segmento).


Esses dois IPs você poderia tranquilamente usar na CPE do cliente para ser
o IP do /32 que você vai entregar ao cliente.

O DHCP vai entregar mascara 255.255.255.255
Semelhante ao PPPoE.

O cliente precisa falar com esse gateway (que vai ser a CPE), mas após a
CPE, quando o pacote for encaminhado, não teria relevancia mais qual é o
gateway do cliente.
Por isso pensei em usar um IP de broadcast ou network de outro segmento,
que não vai fazer diferença nenhuma e você vai manter a coisa mais
"bonita". Tendo o gateway um IP púbico (non RFC 1918) nem CGNAT.

Fiz um lab aqui e funcionou.
Quando pluga a CPE no notebook (windows) ela recebe o /32 da CPE, com
mascara 255.255.255.255 e com gateway.

Como eu expliquei acima, todas as CPEs configuradas dessa maneira, vao
entregar o mesmo gateway ao cliente, esse mesmo IP broadcast ou network
pode ser usado em multiplos dispositivos. Desde que não interfiram.

Nem precisa ter rota pra ele na borda.

Att,

Andre H. de Almeida

Em 27 de março de 2017 09:44, Danilo Bedani <dbedani at gmail.com> escreveu:

> @Andre Almeida,
>
> sim, entendi.. o q nao ficou claro pra mim é como vc vai atribuir DHCP para
> o cliente, enviando um IP /32 de uma faixa com endereço de rede de outra?
>
> Supondo o IP 200.1.2.3/32 que vc vai enviar via DHCP para seu cliente..
> qual mascara e qual gateway vc vai enviar pra ele?
>
> 2017-03-25 1:02 GMT-03:00 Tiago SR <listas at tiagosr.com>:
>
> >  ---- On Fri, 24 Mar 2017 16:39:24 -0300 Paulo Henrique <
> > paulo.rddck at bsd.com.br> wrote ----
> >  > Opa,
> >  >
> >  > A unica vantagem que observei quanto os clientes do /32 ( /24 ) não
> >  > conseguirem se comunicar diretamente ( e nesse caso indiretamente
> > também )
> >  > é que não degradará a ultima milha de todos os demais clientes caso
> dois
> >  > clientes do mesmo segmento ethernet estiverem usando torrent ou algum
> > outro
> >  > protocolo que simplesmente consumará toda a banda do backbone entre os
> >  > clientes.
> >  > O problema é que as queues serão controladas no concentrador, e no
> caso
> >  > somente o upload de conexões tipo UDP que serão exauridos, isso por
> que
> > o
> >  > pacote não sera endereçado ao gateway mas sim ao segmento de rede
> local,
> >  > como pretende resolver esse pequeno detalhe ?
> >  >
> >  > Att.
> >
> > A única forma de algum pacote ser endereçado diretamente a outro endereço
> > no mesmo segmento de rede em aplicações normais (desconsiderando
> tentativas
> > de invasões) seria em comunicação P2P, como no Torrent, tanto em UDP,
> > quanto TCP ou qualquer outro protocolo L4, mas não conseguir se conectar
> a
> > um peer não é problema para todo cliente de Torrent que já vi e não
> conheço
> > outras aplicações P2P relevantes.
> >
> > De qualquer forma, eu estava fazendo testes aqui e é perfeitamente
> > possível substituir o /24 (ou qualquer outro tamanho) por /32, seja
> > estaticamente ou DHCP, PPPoE, etc., de forma que não ocorre então esse
> > isolamento entre clientes.
> >
> >  ---- On Fri, 24 Mar 2017 18:34:00 -0300 Andre Almeida <
> andre at bnet.com.br>
> > wrote ----
> >  > -------------------------quote--------------------
> >  > Também já tive ideia praticamente igual a essa e vejo essa falta de
> >  > comunicação entre clientes como uma vantagem, hehehe.
> >  > -------------------------quote--------------------
> >  >
> >  >
> >  > Como assim vantagem @Tiago SR?
> >  > E se um cliente quiser se comunicar com o outro? Não vai ter jeito
> > nunca ?
> >
> > Se isso for um problema, dá para possibilitar essa comunicação da forma
> > que já falei, usando /32, bem como acredito que com Proxy ARP também se
> > obtenha resultados nesse sentido.
> >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
>
> --
> Danilo Bedani
> dbedani at gmail.com
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>