OSPF + PPPoE descentralizado + redução de saltos [mikrotik]

Gostaria de pedir uma ajuda de vocês sobre um probleminha que estou tendo em montar um projeto....


Estou tentando otimizar a rede do provedor de internet onde trabalho,
Temos ao todo 14 POPs e dentro do pops alguns equipamentos interligados entre si com /30.
As torres não se interligam entre si, mas sim são todas apontadas para uma torre central com P2P individual e esse separado por vlan (L2)

Temos alguns painéis nos POPs para conectar os clientes e o servidor PPPoE está em cada Painel. O painel vai até o radius e autentica o cliente que consegue sair por rotas default até a borda e para voltar temos rotas estáticas de classes /27 definidas na borda.

Está tudo funcionando, porém, dá um trabalho um pouco chato de ter que criar as rotas estáticas e além disso estamos desperdiçando IP utilizando os /27, coisa que não se pode fazer hoje em dia.

Nesse caso, estamos planejando dinamizar o endereçamento estático e também logo,precisaremos alterar a forma de roteamento. A idéia é deixar tudo OSPF com várias areas separadas uma da outra (uma área por POP) e deixar o tipo dela [tottaly] NSSA pois no painel, onde fica o servidor PPPoE, gostariamos de deixar ele anunciar os clientes (nesse caso /32) conectados através da marcação do "redistribute connected routes"

Isso já testei e está funcionando corretamente, testado em bancada e no simulador. As rotas não estão adentrando uma área na outra, pois não há sentido de fazer isso, uma vez que para fazer a interarea, precisa-se passar pela borda, pois é onde todos estão conectados e dessa forma não aumentando a tabela de roteamento dos equipamentos do POP que normalmente são de baixa capacidade para poder receber rotas individuais de todos os nossos clientes.

Como o roteador de borda é muito mais poderoso do que as RB que temos nas torres, não há problema dele concentrar as rotas dos clientes e mais o BGP (creio eu)

O problema é que além de tudo, estamos com um problema de muitos saltos para chegar até a borda. Nossos clientes muitas vezes precisam dar mais de 6 saltos só para chegar até ao roteador de borda, pois como falei, eles vao pela rota default até chegar a borda. Isso incomoda pois parece ser uma rede não otimizada.

Gostaria de usar VPLS para fazer um tunel para chegar da borda até o Painel e dessa forma poder entregar apenas 1 salto do painel até a borda, otimizando o fluxo.

Gostaria de dicas sobre como posso implementar tal cenário.

Já estou ciente de utilizar MTU compativel com o que eu preciso para tudo funcionar no MPLS e não fragmentar/descartar pacotes, porém, não é esse o problema maior. O problema maior é que não sei exatamente como fazer o tráfego dos clientes cruzarem pelo tunnel, uma vez que o servidor PPPoE fica no painél.

Agradeço demais a ajuda e peço desculpas se me prolonguei.
Obrigado por serem open source!

Citação:

---

Postado originalmente por Arthur Bernardes

Principal detalhe que faltou: O desenho/topologia da rede! :)

---

Vou fazer um desenho no visio do core + duas torres, só pra dar a entender várias áreas e entender como está o restante.
Entendendo isso, se entende a rede inteira

Bom dia ploquets!

Bem, realmente realizar procedimentos de engenharia de tráfego e network design que tenham como objeto fim a otimização da rede são de extrema importância para se obter resultados como melhor desempenho, maior disponibilidade e redução do número de incidentes tangenciando quase a zero na camadas de distribuição e backbone da rua rede de transmissão/NGN/telecomunicações.

Com base no que eu entendi da sua topologia e explicação por você explicada seus 14 Pop's são conectadas diretamente a seu Pop Central onde está sua RB de borda e nenhum desses 14 Pop's possuem conexão entre si exceto a comunicação ponto-a-ponto com endereçamento IPv4 com prefixo/30 atribuído a cada interface VLAN.

Seria uma topologia estrela correto?Meu entendimento está correto?

Bem caso meu entendimento da sua topologia esteja correto, segue abaixo minhas considerações:

1 - A utilização de um protocolo de roteamento dinâmico como o OSPF só é recomendado para quando se possui diversas opções de caminhos de roteamento na sua rede como topologia full-mesh, partial-mesh, hierárquica distribuída(árvore) e anel ou em casos extremos onde a volume de endereços IP é alto ou o esquema de endereçamento IP é extremamente complexo mesmo com uso de técnicas de subnet, VLSM e sumarização de rotas através do uso do CIDR ou como já mencionado em redes há presença geográfica extensa e onde a distribuição e topologia lógica entre os POP's possuem uma complexa malha de comunicão com uso de comutação e roteamento rendundante.

No seu caso, existe somente um único link de comunicação entre seu roteador de borda e qualquer outro POP existente, ou seja, se esse linkfalha a comunicação é interrompida, não fazendo sentido usar um protocolo de roteamento dinâmico como OSPF pois não existe manipulação de rotas a fazer ou caminhos alternativos a serem ativados automaticamente. Essa topologia é denominada pela Cisco como uma rede STUB. Nesse caso as melhores práticas recomendam o uso de rota default definida manualmente no PE(provider edge) qual o cliente está conectado (no seu caso RB torre/AP - PPPoE) e uso de rota estática sumarizada com prefixo do cliente e definida manualmente no roteador mais próximo conectado ao roteador PE e apontando a sua direção.

Resumidamente, seria continuar usando as rotas estáticas /27 qual você já está usando. (os clientes continuam recebendo os /32 para evitar disperdício de endereços, porém no seu borda será tratado a rota sumarizada de cada pop e o /32 de cada cliente será tratado localmente por cada POP e sua RB. Pois isso economiza o uso de recursos desnecessário de hardware do seu roteador de borda como memória e processamento, pois caso redistribua as rotas /32 individualmente sem sumarização, isso irá aumentar a quantidade de rotas na tabela de roteamento, consecutivamente, mais entradas a serem comparadas pelo roteador no processo de decisão de roteamento, e consecutivamente, aumento da latência e se for analisar do ponto de vista de roteamento, a entrega do pacote acorre da mesma forma usando uma única rota sumarizada ou usando as entradas individuais de cada /32 de cliente que possuí).

O uso do OSPF no seu caso só iria consumir memória e processamento e do ponto de vista técnico ou de engenharia não traria benefício algum. O único benefício aparente que teria seria do ponto de vista adminisstrativo, que seria não ter de configurar as rotas estáticas dos pops, porém se analisar o tempo entre adicionar uma rota estática e configurar o ospf pra cada pop que tiver que ativar chegará a conclusão que irá gastar muito menos tempo configurando uma única rota estática.

2 - Não é recomendado pelas melhores práticas ativar um protocolo IGP em um roteador executando função de ASBR(Autonomous System Border Router) e qual está executando um protocolo EGP com o BGP. Os analistas de rede frequentemente se esquecem de usar comandos como passive-interface ou de desativar o processo OSPF para as interfaces conectadas a ASN's externos e redes fora da sua administração. Dando margem sérias falhas de segurança da rede. Recomenda-se usar dois equipamentos separados, um para o EGP e outro para rodar o EGP.

3-O uso de MPLS no seu caso na minha opinião vale a pena se dar o trabalho de configuração. A tecnologia MPLS é ótima, mas é recomendado também para casos de redes complexas e empresas que fazem uso de redes multi-serviços principalmente com tecnologias MSAN.

Lembro que as minhas recomendações foram feitas com base no que entendi ser sua topologia e que é um ponto de vista particular. Podendo cada profissional optar por usar o esquema que melhor lhe agrada ou lhe seja útil. O intuíto é de somente lhe dar um direcionamento para se pensar nas consequências ao se utilizar o cenário qual foi exposto e se esse trará resultados benéficos reais ou se na realidade irá trazer benefício algum.

Espero ter ajudado com o ponto de vista!

Cordialmente

Rafael Themístocles
[Consultor em Redes e Telecomunicações/NGN Network Project Engineer]
http://www.telmetrics.com.br
E-mail: [email protected]
[email protected]
Skype: rafaelthemistocles
Whatsapp: (11)9-5962-2128

Citação:

---

Postado originalmente por ploquets

Gostaria de pedir uma ajuda de vocês sobre um probleminha que estou tendo em montar um projeto....


Estou tentando otimizar a rede do provedor de internet onde trabalho,
Temos ao todo 14 POPs e dentro do pops alguns equipamentos interligados entre si com /30.
As torres não se interligam entre si, mas sim são todas apontadas para uma torre central com P2P individual e esse separado por vlan (L2)

Temos alguns painéis nos POPs para conectar os clientes e o servidor PPPoE está em cada Painel. O painel vai até o radius e autentica o cliente que consegue sair por rotas default até a borda e para voltar temos rotas estáticas de classes /27 definidas na borda.

Está tudo funcionando, porém, dá um trabalho um pouco chato de ter que criar as rotas estáticas e além disso estamos desperdiçando IP utilizando os /27, coisa que não se pode fazer hoje em dia.

Nesse caso, estamos planejando dinamizar o endereçamento estático e também logo,precisaremos alterar a forma de roteamento. A idéia é deixar tudo OSPF com várias areas separadas uma da outra (uma área por POP) e deixar o tipo dela [tottaly] NSSA pois no painel, onde fica o servidor PPPoE, gostariamos de deixar ele anunciar os clientes (nesse caso /32) conectados através da marcação do "redistribute connected routes"

Isso já testei e está funcionando corretamente, testado em bancada e no simulador. As rotas não estão adentrando uma área na outra, pois não há sentido de fazer isso, uma vez que para fazer a interarea, precisa-se passar pela borda, pois é onde todos estão conectados e dessa forma não aumentando a tabela de roteamento dos equipamentos do POP que normalmente são de baixa capacidade para poder receber rotas individuais de todos os nossos clientes.

Como o roteador de borda é muito mais poderoso do que as RB que temos nas torres, não há problema dele concentrar as rotas dos clientes e mais o BGP (creio eu)

O problema é que além de tudo, estamos com um problema de muitos saltos para chegar até a borda. Nossos clientes muitas vezes precisam dar mais de 6 saltos só para chegar até ao roteador de borda, pois como falei, eles vao pela rota default até chegar a borda. Isso incomoda pois parece ser uma rede não otimizada.

Gostaria de usar VPLS para fazer um tunel para chegar da borda até o Painel e dessa forma poder entregar apenas 1 salto do painel até a borda, otimizando o fluxo.

Gostaria de dicas sobre como posso implementar tal cenário.

Já estou ciente de utilizar MTU compativel com o que eu preciso para tudo funcionar no MPLS e não fragmentar/descartar pacotes, porém, não é esse o problema maior. O problema maior é que não sei exatamente como fazer o tráfego dos clientes cruzarem pelo tunnel, uma vez que o servidor PPPoE fica no painél.

Agradeço demais a ajuda e peço desculpas se me prolonguei.
Obrigado por serem open source!

---

Citação:

---

Postado originalmente por Arthur Bernardes

Principal detalhe que faltou: O desenho/topologia da rede! :)

---

Anexo 61788

Segue a topologia da rede.

Seguindo as informações dadas pelo amigo Rafael, estariamos usando o OSPF para otimizar a entrega dos IPs. Entregando para o cliente /32 e deixando praticamente todo o AS disponivel para entrega sob demanda, dispensando alocar /27 para um determinado painel (AP). Com o roteamento dinâmico, visamos ganhar IPs e também economizar dor de cabeça no roteamento.

Realmente, utilizando OSPF (conforme eu escrevi na topologia) é criada uma rota para cada cliente (/32) e isso aumenta consideravelmente o tamanho da tabela routing, porém, não sei de outra maneira (sem sumarização, sem perda de IPs) para fazer funcionar.

O objetivo do MPLS seria de reduzir a quantidade de saltos na rede, fazendo com que o cliente salte direto do AP para a borda por dentro do tunel VPLS. Na topologia em que enviei (onde os AP5M da Intelbras estão como bridge) não é exatamente como está hoje. Atualmente eles estão em modo roteado e também são considerados como hops para chegar até a borda. Mas eu sei que pra implementar MPLS todos os equipamentos no caminho deverão suportar o MPLS, logo, como os Intelbras não suportam, eles precisam ficar em bridge. Isso vale também para o OSPF.


Minha alternativa por enquanto, afim de evitar saltos, foi transformar a RB750 (conforme topologia) em um SW. Atribuir um IP para ela somente afim de monitoria e configuração.

Dessa forma, ao invés de um /29 entre a CCR e os P2P, deixaríamos um /27 entre todos os equipamentos ( CCR, P2P 1 , P2P 2, RB750, e todos os APs ) e quando o cliente se conectasse no AP, o cliente poderia saltar direto do AP para a CCR pois estariam pertencendo a mesma classe.

Não sei se o broadcast gerado no /27 causaria problemas, mas para evitar broadcast também utilizamos NBMA configurado na interface de cada equipamento do POP, afim de diminuir as mensagens de hello trocadas entre eles. O Designated Router do OSPF nesse caso (dentro dessa área totally NSSA) ficou sendo a CCR.

Enfim, estou colocando meus pontos de vista para ver o que pode ser feito afim de atingir os seguintes goals:

- Entregar IPs de forma efetiva /32, não necessitando alocar uma classe /27 inteira por AP [sem contar na perda de 2 IPs a cada segregação de classe]

- Diminuir saltos do cliente até a borda

- Se usando MPLS, poder vender também, a partir desse momento, tuneis VPLS para clientes que desejassem fazer Lan2Lan de forma mais efetiva do que o EoIP.

Muito obrigado pela ajuda desde já!

Pessoal se temos OSPF na rede porque ter VLAN?
podemos descentralizar ou centralizar os NAS's
o que nao faz sentido disso tudo ao meu modo de ver é VLAN + OSPF
se usa OSPF faz VPLS
se usa rede em roteamento statico faz VLAN e acabou nao tem o que inventar

mas manda ai ploquets a topologia da sua rede

Citação:

---

Postado originalmente por flavioleonel

Pessoal se temos OSPF na rede porque ter VLAN?
podemos descentralizar ou centralizar os NAS's
o que nao faz sentido disso tudo ao meu modo de ver é VLAN + OSPF
se usa OSPF faz VPLS
se usa rede em roteamento statico faz VLAN e acabou nao tem o que inventar

mas manda ai ploquets a topologia da sua rede

---

Não entendi o que tem a ver o OSPF com VLAN.
O intuito da vlan é de separar os POPs, ao invés de usar vários IPs na mesma interface, é criada interfaces vlan e feita a segregação e o OSPF é de dinamizar as rotas.

VLAN e VPLS são duas coisas completamente diferentes ao meu ver.
VLAN é pra segregar a rede em camada 2 adicionado tag separando os dominios de broadcast. Já o VPLS é um tunel a ser feito, tipo uma VPN.

A topologia:
Anexo 61789

Amigo,
Faz uma Vlan para cada Painel ou POP e coloca um único concentrador PPPoE, antes do seu BGP. Resolve seu problema.

Citação:

---

Postado originalmente por agbcao

Amigo,
Faz uma Vlan para cada Painel ou POP e coloca um único concentrador PPPoE, antes do seu BGP. Resolve seu problema.

---

Dessa forma da pra fazer.
Criando um concentrador PPPoE posso na borda, indicar a rota de todo o AS que eu quero alocar pros clientes (e nesse caso não seria uma rota por cliente) e no concentrador PPPoE eu teria vários tuneis VPLS para que se possa conseguir atingir o objetivo de sair da rede com 1 salto.

Porém, o que eu queria tentar fazer com que, no cenário atual, eu conseguisse criar um tunel em camada 2 (utilizando o VPLS) , simulando uma conexão direta do AP (que é o PPPoE server atual) com a borda, fazendo com que a borda e o AP encaminhassem o trafego dos clientes para o tunel e dessa forma eu teria somente 1 salto.

O problema até agora está em implementar o VPLS dentro de áreas STUB ou Not So Stub Area (NSSA), porque quando eu tento fazer trafego fluir por dentro do tunel, quando a area é stub, não estou conseguindo e não sei porque.

E se as áreas não forem stub, as rotas de todos os clientes se propagarão dentro de toda minha nuvem, ou seja, todas as minhas RB750 e todos meus APs terão a rota de todos os meus clientes, coisa que eu não quero.

E usar a sumarização vai me impedir de poder entregar os /32 pros clientes, uma vez que eu vou ser obrigado a alocar uma parte do AS (sendo /27, /26 etc. etc.) para fazer a sumarização... e nisso vou disperdiçar muitos IPs, pois nem sempre todos os clientes do painel estarão conectados e os IPs vao precisar ficar alocados lá pra sempre, pois estarão incluidos no /27 ou /26 ou etc.... e além disso, perco 2 IPs por cada range alocado, um para a network e outro para o broadcast.

Entendi. Como falei para você acima, você teria apenas um salto antes do seu Roteador de borda. O próximo salto já seria ele. O túnel que você quer criar é a Vlan. Não é necessário criar este túnel vpls. Caso necessite, utilize faixas de ips privados para estruturar sua rede interna.

Citação:

---

Postado originalmente por agbcao

Entendi. Como falei para você acima, você teria apenas um salto antes do seu Roteador de borda. O próximo salto já seria ele. O túnel que você quer criar é a Vlan. Não é necessário criar este túnel vpls. Caso necessite, utilize faixas de ips privados para estruturar sua rede interna.

---

Desse jeito já está.. para conseguir 1 salto com a VLAN, eu tive que deixar o POP inteiro em /27 (poderia ser /28, mas quis deixar com margem para escalabilidade) e dessa forma todos os equipamentos pertencem a mesma rede. O problema é fazer isso com enlaces entre os equipamentos em /30. Se ficarem em /30, entao cada enlace é considerado como 1 salto. Ou seja, se eu tiver 5 enlaces /30 para chegar da borda até o painel, eu terei 5 saltos.

O problema de deixar tudo na mesma rede é porque gera broadcast.... e isso é ruim para o desempenho da rede.

Gostaria de permanecer com a rede roteada em /30 e através de um tunel L2 tornar transparente todos esses enlaces /30 até a borda.

Daria para fazer com EoIP, mas o EoIP tem muitas vezes 80% menos de desempenho do que o VPLS... por isso a insistencia no VPLS.

Voce sabe quando uma VPLS caiu o que acontece com seu PPPOE ?
Amigo voce quer complicar seu cenário, para nada ?

Citação:

---

Postado originalmente por maxibelo

Voce sabe quando uma VPLS caiu o que acontece com seu PPPOE ?
Amigo voce quer complicar seu cenário, para nada ?

---

Pra nada?

Como pra nada?

Poder vender VPLS para nossos clientes (VPN L2 de alto desempenho)....
Se o PPPoE funcionar dentro do VPLS, já vamos ter esse tipo de serviço para vender.

Além disso, ter um pseudo-cabo (pseudowire) fazendo a conexão do Painel até a borda em camada 2 vai deixar o tráfego melhor.

E outra, não tem motivos para cair o VPLS.

Se cair o VPLS vai ser porque um dos equipamentos da nuvem MPLS parou de funcionar.... e se isso ocorrer, também afetaria qualquer cenário, não importando se está com VPLS ou não.

Quanto tempo vc levaria para subir um cliente com vlan caso seu pop tenha desligado?
E em rede com OSPF, MPLS e VPLS quanto seria esse tempo?
Quer um conselho se tem uma rede com varios saltos com 5.8 +-, vende VPLS nao..!! (nao conheco a sua estrutura mais não uma topologia ideal para seu caso)

Eu sou um bosta, mais gosto de saber o porque aquilo acontece e de que forma isso acontece, o que podera acontecer dali pra frente..!!
Então antes de implementar na pratica, primeiro tente absorver alguns pre-requisitos, porque o dia que der problema vc vai ficar louco!!
SEMPRE E BUG DO MK.!!!
O telmetrics praticamente de deu uma consultoria 0800.

Citação:

---

Postado originalmente por maxibelo

Eu sou um bosta, mais gosto de saber o porque aquilo acontece e de que forma isso acontece, o que podera acontecer dali pra frente..!!
Então antes de implementar na pratica, primeiro tente absorver alguns pre-requisitos, porque o dia que der problema vc vai ficar louco!!
SEMPRE E BUG DO MK.!!!
O telmetrics praticamente de deu uma consultoria 0800.

---

Tambem pretendemos vender isso para clientes de fibra...
Então, não se trata só de fechar VPLS entre clientes do radio.
Além disso, temos praticamente 99% da rede em 5.8

Vamos ser realistas, vender serviço nobre com 5.8, esquece..!!
Desculpa a franqueza nas é a realidade, nao vale a pena sofrer com isso no seu cenário..!! (pode dar certo sim e eu estar errado, ate porque nao conhece sua rede).
Desculpa se nao te ajudei..!!