[GTER] Entrega de IPv4 Fixo /32

[Andre Almeida]

Vou explicar melhor, com exemplo:

Voce possui o bloco 189.100.96.0/22 para seu AS.

Voce pegou esse bloco e dividiu em alguns segmentos de rede que você
preferiu.

digamos que 189.100.96.0/27 ficou alocado para servidores.

Então, desse /27 vc tem dois IPs "sobrando", que só vão ser utilizado para
esse segmento.


Vc poderia pegar o IP 189.100.96.31 e usar como gateway daquele seu
cliente, la na CPE dele.
Não precisa ter rota pra esse IP apontando pra lá pra CPE do cliente.

No exemplo acima, não tem nenhum serviço nem nada rodando nesse
ip 189.100.96.31. Logo ele é descartável pra rede (menos para o /27 que o
usa como broadcast).

Seu cliente, receberá por exemplo, o IP 189.100.99.250 (que pertence ao seu
bloco /22) mas não faz parte do segmento /27 inicial.

Vc criaria um DHCP na CPE do cliente, pra ele entregar os seguintes
atributos:

IPv4: 189.100.99.250
Mascara: 255.255.255.255
Gateway: 189.100.96.31
DNS: os DNS do ISP

Na CPE Mikrotik, vc adicionaria na ether:
/ip address add address=189.100.96.31 network=189.100.99.250


Pronto, voilà.

O pacote seria encaminhado ao tunel PPPoE (que possui IP privado RFC 1918)
mas quando o pacote fosse encaminhado, não ficaria nenhum vinculo com o IP
de gateway que o cliente usou.

Aos destinos, ficaria somente o IP 189.100.99.250 aparecendo. E quanto
tentassem falar com ele, a borda saberia que a rota estaria atrás do tunel
PPPoE (com IP Privado) e chegaria na CPE que faria o encaminhamento correto.

OBS. CLARO QUE NAO PODE TER NAT!!! hehehe
* Desculpe a NET (Claro S.A.) por ter usado um bloco deles como exemplo.
rsrsrs

Att,

Andre H. de Almeida


Em 27 de março de 2017 10:53, Andre Almeida <andre at bnet.com.br> escreveu:

> 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
>>
>
>