[GTER] Entrega de IPv4 Fixo /32

Andre Almeida andre at bnet.com.br
Fri Mar 24 12:09:51 -03 2017 

Opa, entendi sim!

Acho até que consegui fazer, a unica coisa que me agarrou aqui foi o OSPF
ter esse problema de redistribuiçao das rotas estáticas quando em áreas
NSSA.

Só que o que eu estava planejando seria entregar mesmo um /32 pro cliente,
mas sem a necessidade do /24 no framed-ip-route.

Então acho que vou ter que fazer com iBGP mesmo.

Mas só pra você entender o cenário bem completinho, seria isso aqui:

1) Concentrador cria o tunel do cliente, solicitando os atributos do radius

2)  Radius manda um IP privado ao tunel e junto, manda dois atributos que
serão instalados no concentrador, são eles:
                * Framed-IP-Route
                * Mikrotik-Rate-Limit

3)  O concentrador aplicará a rota estática do primeiro atributo e aplicará
a queue do segundo atributo

4)  O OSPF (no caso isso que está me perturbando no momento) redistribuirá
a rota estática /32 até as bordas de rede

5) A CPE do cliente terá um túnel PPPoE ativo com um IP Privado, entretanto
receberá tráfego do /32 publico, devido a rota previamente instalada e
redistribuída.

6) Na CPE do cliente vou criar um DHCP para entregar esse /32 ao cliente

7) Para gateway do cliente, vou utilizar um IP de network ou de broadcast
de outro segmento
          * Pelo fato de IP não fazer diferença pra ninguém, posso usar ele
em todas as CPEs. Só o cliente vai enxergar ele e não vai atrapalhar esse
outro segmento. Nisso eu não preciso utilizar 2 IPs por cliente.

8) Ainda criei uma regra de mangle pra incrementar o TTL de pacotes ICMP
echo request em 2. Para ficar liso e ficar "mais transparente".

9) Devido a esse DHCP entregar somente um IP, o lease time deixei alto e um
script de limpar os leases no startup. Se o cliente trocar de device, basta
reiniciar a CPE
      Obs. Acho que a NET faz isso... pq tem que reiniciar o modem deles
pra quando se troca o dispositivo.

Objetivos alcançados:
Mantive o PPPoE como entrega (queue é aplicada)
Não preciso habilitar NAT na CPE
Cliente não vê o PPPoE, isso fica transparente à ele
Cliente fica com o IP Publico e FIXO direto em sua própria interface
Mantive a gerencia da CPE em camada 3
Cliente não precisa me informar MAC para obter o IP Fixo.


Acho que consegui finalizar.

O grande lance na CPE Mikrotik, foi coloca o IP de gateway na ether de
entrega ao cliente, tendo o Network o IP publico dele.
Nesse caso a RB cria a rota dinamicamente conectada para o IP do cliente:

/ip address add address=aaa.bbb.ccc.ddd/32 network=zzz.yyy.xxx.www

Onde:
aaa.bbb.ccc.ddd = Item 7 da lista acima
zzz.yyy.xxx.www = IP Publico do cliente, mesmo do framed-ip-route


Att,

Andre H. de Almeida


Em 24 de março de 2017 10:48, Danilo Bedani <dbedani at gmail.com> escreveu:

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

More information about the gter mailing list