[GTER] Entrega de IPv4 Fixo /32

Paulo Henrique paulo.rddck at bsd.com.br
Fri Mar 24 16:39:24 -03 2017


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.

Em 24 de março de 2017 13:23, Tiago SR <listas at tiagosr.com> escreveu:

> Também já tive ideia praticamente igual a essa e vejo essa falta de
> comunicação entre clientes como uma vantagem, hehehe.
>
>
>  ---- On Fri, 24 Mar 2017 10:48:46 -0300 Danilo Bedani <dbedani at gmail.com>
> wrote ----
>  > @Andre Almeida,
>  >
>  > Pelo que entendi, a sua intenção é parecida com a ideia q tive:
>  >
>  > Colocar um mikrotik simples para o cliente, configurar um IP válido /24
> na
>  > LAN deste MK (ex. 200.1.2.1/24 ) e na wan fazer um PPPoE.
>  >
>  > Neste PPPoE, enviar um atributo de FRAMED-IP-ROUTE para o concentrador
> que
>  > receber esta conexao pppoe, apontando o /32 que vc designou para o
> cliente.
>  > Ex. 200.1.2.55.
>  >
>  > Este mesmo /24 seria segmentado em 253 /32, cada um para um cliente. O
> seu
>  > cliente configuraria na interface do equipamento dele o IP
> 200.1.2.55/24
>  > com gw 200.1.2.1, que esta na LAN do MK que vc colocou pra ele.
>  >
>  > Em termos de roteamento, o /24 não seria propagado, pois está na CPE do
>  > cliente.
>  >
>  > O seu concentrador iria propagar a rota estática do /32 (200.1.2.55)
> que vc
>  > atribuiu para o cliente e "roteou" através do tunnel pppoe criado na
> WAN do
>  > MK.
>  >
>  > Dessa maneira, para o roteador do cliente, na WAN existe um /24. Na CPE
> que
>  > vc colocou (MK), existe um roteamento estatico. No Seu concentrador
> PPPoE,
>  > existira uma rota estática para o /32 do cliente.
>  >
>  > O erro que prevejo, é se por exemplo vc configurar um segundo cliente no
>  > mesmo molde e atribuir 200.1.2.56, e este cliente tentar comunicação
> com o
>  > primeiro, que esta com 200.1.2.55.
>  >
>  > Para ambos os clientes, a WAN do roteador esta na subrede 200.1.2.0/24,
>  > portanto não haverá comunicação entre eles, por estarem isolados por um
> MK,
>  > que por sua vez possui um tunnel.
>  >
>  > Espero que tenha dado para entender...
>  >
>  > Danilo
>  >
>  >
>  >
>  > 2017-03-23 18:34 GMT-03:00 Andre Almeida <andre at bnet.com.br>:
>  >
>  > > @Danilo Bedani
>  > > ------------------------------------------------------------
>  > > ------------------------------------------
>  > > Imagine que 2 clientes querem se comunicar e ambos estão nesta rede
>  > > "virtual" com um /24... não irão se comunicar..
>  > > ------------------------------------------------------------
>  > > ------------------------------------------
>  > >
>  > > Acho que não teria problema.
>  > >
>  > > Vc se refere quando se usasse um DHCP Relay uma vlan com /24
> entregando /32
>  > > com um reply-only do arp ?
>  > >
>  > > Att,
>  > >
>  > > Andre H. de Almeida
>  > >
>  > >
>  > > Em 23 de março de 2017 15:45, Danilo Bedani <dbedani at gmail.com>
> escreveu:
>  > >
>  > > > Tenho a mesma demanda aqui Andre.. eu acredito que funcione sim, da
>  > > maneira
>  > > > como vc mencionou... não testei na pratica, mas pela lógica
> funcionará.
>  > > >
>  > > > Eu utilizo iBGP nos meus concentradores e eles já estão programados
> para
>  > > > propagar rotas estáticas.
>  > > >
>  > > > A unica precaução que tomaria, seria criar as redes "virtuais"
> menores
>  > > que
>  > > > /24, optando por utilizar /27 por exemplo.
>  > > >
>  > > > Imagine que 2 clientes querem se comunicar e ambos estão nesta rede
>  > > > "virtual" com um /24... não irão se comunicar..
>  > > >
>  > > > Danilo
>  > > >
>  > > > 2017-03-23 7:18 GMT-03:00 Osvaldo T Crispim Filho <
> osvaldotcf at gmail.com
>  > > >:
>  > > >
>  > > > > Accel-ppp com IPoE e IP unnumbered
>  > > > >
>  > > > > Do forum
>  > > > >
>  > > > > yes, accel may brings up vlans for you, this function is called
> "vlan
>  > > > > monitor", but it is utility function, to simplify your life
>  > > > > its function is monitoring some parent interface(s) and look if
> there
>  > > is
>  > > > > VLAN packets and automatically create and delete vlan interfaces
>  > > > > so it is useful if you have tons of vlans
>  > > > >
>  > > > > IP unnumbered is supported too, in such case customer gets IP with
>  > > mask,
>  > > > > but on server side accel creates /32 route and acts as arp proxy
>  > > > >
>  > > > >
>  > > > > Em 22/03/2017 10:24, "Andre Almeida" <andre at bnet.com.br>
> escreveu:
>  > > > >
>  > > > > > O framed-ip no radius não é o problema. Esse atributo usamos
> aqui
>  > > para
>  > > > os
>  > > > > > demais clientes. Normal, entregamos /32 pelo tunel PPPoE.
>  > > > > >
>  > > > > > O problema é que o IP do framed-ip vai para o tunel PPPoE,
> coisa que
>  > > > não
>  > > > > > vai direto pro cliente (no email incial eu destaquei que o
> cliente
>  > > nao
>  > > > > > gostaria de fechar o tunel).
>  > > > > >
>  > > > > > O DHCP Relay que o @Bruno Cabral sugere é interessante, pois vai
>  > > isolar
>  > > > > os
>  > > > > > clientes por CPE.
>  > > > > >
>  > > > > > Mas o problema é quando esse IP é fixo.
>  > > > > >
>  > > > > > Mas acho que estou chegando em uma solução.
>  > > > > >
>  > > > > >
>  > > > > > OBS. Alguém aqui já conseguiu redistribuir rotas estáticas no
> OSPF do
>  > > > > > Mikrotik tranquilamente? Funciona quando tira a rota e habilita
> ela
>  > > > > > novamente ?
>  > > > > >
>  > > > > > Eu notei aqui que quando o túnel cai a rota some e engraçado (e
> que
>  > > > > parece
>  > > > > > um bug) é que quando o tunel volta, a rota não é mais
> distribuída.
>  > > > > > Precisa forçar a instancia do OSPF a fechar novamente para ela
>  > > passar.
>  > > > > > Tipo, desabilitando a interface dentro do OSPF e habilitando
>  > > novamente
>  > > > > > Deveria ser algo dinamico. Tirou o tunel, perdeu a rota
> estática do
>  > > > > > framed-route, o OSPF pára de anunciar. Voltou o tunel, volta a
> rota
>  > > > > > estática do framed-route e o OSPF volta a anunciar. Mas pelo
> que vi
>  > > só
>  > > > > > funciona uma vez, depois que perder a rota ela nao volta mais a
> ser
>  > > > > > redistribuída via OSPF, ficando somente ela estática no
> concentrador.
>  > > > > >
>  > > > > >
>  > > > > > Att,
>  > > > > >
>  > > > > > Andre H. de Almeida
>  > > > > >
>  > > > > >
>  > > > > > Em 22 de março de 2017 08:17, Alan Mendes <alan at zuknet.com>
>  > > escreveu:
>  > > > > >
>  > > > > > > Aqui defino o framed-ip no radius e vai tranquilo.
>  > > > > > >
>  > > > > > >
>  > > > > > >
>  > > > > > >
>  > > > > > >
>  > > > > > >
>  > > > > > >
>  > > > > > > *ZUKNET NETWORKS LTDA. MEAlan Mendes Morais*
>  > > > > > > *Email:* alan at zuknet.com
>  > > > > > > *Tel:* 15 3376-9893
>  > > > > > >
>  > > > > > >
>  > > > > > > www.zuknet.com
>  > > > > > > http://as262333.peeringdb.com
>  > > > > > > http://bgp.he.net/AS262333
>  > > > > > >
>  > > > > > >
>  > > > > > > Em 21 de março de 2017 10:02, Andre Almeida <
> andre at bnet.com.br>
>  > > > > > escreveu:
>  > > > > > >
>  > > > > > > > Amigos, bom dia!
>  > > > > > > >
>  > > > > > > > Temos alguns clientes que possuem um serviço um pouco
>  > > > diferenciado, e
>  > > > > > que
>  > > > > > > > não querem usar PPPoE nos seus dispositivos.
>  > > > > > > >
>  > > > > > > > Mas não queremos desperdiçar IPv4 nesse momento delicado
> fazendo
>  > > > > > entrega
>  > > > > > > de
>  > > > > > > > /30 desnecessariamente.
>  > > > > > > >
>  > > > > > > > Pensei em alguma forma de entregar o /32 publico ao cliente.
>  > > > > > > >
>  > > > > > > > Como aqui utilizamos PPPoE para entregar o serviço, pensei
> em
>  > > fazer
>  > > > > > algo
>  > > > > > > > diferente:
>  > > > > > > >
>  > > > > > > > 1 ) Incluir no pacote um roteador Mikrotik (como CPE) para
> fazer
>  > > o
>  > > > > > PPPoE
>  > > > > > > > (esse tunel receberia um IP Privado)
>  > > > > > > > 2 ) Criar um atributo de Framed-route no Radius para ao
> logar,
>  > > > criar
>  > > > > > > > dinamicamente no concentrador a rota do IP Publico com
> gateway o
>  > > IP
>  > > > > > > Privado
>  > > > > > > > do PPPoE
>  > > > > > > > 3 ) No OSPF do Concentrador, distribuir rotas estáticas,
> para
>  > > > > > encaminhar
>  > > > > > > > essas rotas entregues pelo Radius às bordas.
>  > > > > > > >
>  > > > > > > > A partir dai, já dava pra começar a pensar em entregar o IP
>  > > Privado
>  > > > > > > > diretamente para o cliente.
>  > > > > > > >
>  > > > > > > > Pensei em separar um IP para ser gateway de todos esses
> clientes.
>  > > > > > > > Como assim? Seria o IP de gateway do cliente, ficaria
> visível
>  > > > apenas
>  > > > > > > para o
>  > > > > > > > cliente. Esse IP, mesmo público, poderia até mesmo ser o IP
>  > > network
>  > > > > ou
>  > > > > > > > broadcast de qualquer outro segmento, pois não seria
> utilizado
>  > > para
>  > > > > > > > destinos. Seria só para ficar mais "bonito" do que entregar
> um IP
>  > > > > > Publico
>  > > > > > > > com Gateway privado.
>  > > > > > > >
>  > > > > > > > E entregar um DHCP (ou dar a possibilidade de adicionar
>  > > > > estaticamente)
>  > > > > > um
>  > > > > > > > IP Publico /32 ao cliente.
>  > > > > > > > Dessa forma, o cliente só usaria 1 IP e não 4 IPs (que
> acontece
>  > > > > quando
>  > > > > > > > usamos um /30).
>  > > > > > > >
>  > > > > > > > O que vocês acham? Tem alguma outra forma de fazer isso
> usando
>  > > > PPPoE
>  > > > > > > quando
>  > > > > > > > no final das contas o PPPoE nao vai direto no equipamento do
>  > > > cliente?
>  > > > > > > >
>  > > > > > > > Alguém tem alguma sugestão? Várias cabeças sempre pensam
> melhor
>  > > que
>  > > > > > uma.
>  > > > > > > >
>  > > > > > > > Obrigado
>  > > > > > > >
>  > > > > > > > Andre Almeida
>  > > > > > > > --
>  > > > > > > > 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
>  > > > >
>  > > >
>  > > >
>  > > >
>  > > > --
>  > > > Danilo Bedani
>  > > > dbedani at gmail.com
>  > > > --
>  > > > gter list    https://eng.registro.br/mailman/listinfo/gter
>  > > >
>  > > --
>  > > gter list    https://eng.registro.br/mailman/listinfo/gter
>  > >
>  >
>  >
>  >
>  > --
>  > Danilo Bedani
>  > dbedani at gmail.com
>  > --
>  > gter list    https://eng.registro.br/mailman/listinfo/gter
>
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
:UNI><BSD:
Paulo Henrique.
Fone: (21) 37089388.



More information about the gter mailing list