+ Responder ao Tópico



  1. #1

    Red face 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!

  2. #2

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

    Citação Postado originalmente por Arthur Bernardes Ver Post
    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

  3. #3

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

    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 Ver Post
    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!

  4. #4

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

    Citação Postado originalmente por Arthur Bernardes Ver Post
    Principal detalhe que faltou: O desenho/topologia da rede!
    Clique na imagem para uma versão maior

Nome:	         MAPA REDE.jpg
Visualizações:	1804
Tamanho: 	241,9 KB
ID:      	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á!
    Última edição por ploquets; 24-11-2015 às 16:29.

  5. #5

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

    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

  6. #6

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

    Citação Postado originalmente por flavioleonel Ver Post
    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:
    Clique na imagem para uma versão maior

Nome:	         MAPA REDE.jpg
Visualizações:	737
Tamanho: 	241,9 KB
ID:      	61789
    Miniaturas de Anexos Miniaturas de Anexos Clique na imagem para uma versão maior

Nome:	         MAPA REDE.jpg
Visualizações:	489
Tamanho: 	189,3 KB
ID:      	61787  

  7. #7

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

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

  8. #8

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

    Citação Postado originalmente por agbcao Ver Post
    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.

  9. #9

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

    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.

  10. #10

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

    Citação Postado originalmente por agbcao Ver Post
    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.

  11. #11

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

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

  12. #12

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

    Citação Postado originalmente por maxibelo Ver Post
    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.

  13. #13

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

    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)

  14. #14

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

    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.

  15. #15

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

    Citação Postado originalmente por maxibelo Ver Post
    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

  16. #16

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

    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..!!
    Última edição por maxibelo; 30-11-2015 às 22:18.