+ Responder ao Tópico



  1. #1

    Padrão Transportar link por dentro da rede

    Boa tarde amigos do under, vou lançar meu cenário pra ver se tem solução melhor.

    Primeiro, uma fotinho confusa explicando mais ou menos o que to fazendo:
    Clique na imagem para uma versão maior

Nome:	         transport.png
Visualizações:	525
Tamanho: 	77,4 KB
ID:      	60616

    Na torre A, eu possuo clientes em paineis 5.8 e 2.4, os cabos vão ligados a uma CRS125, com as portas da 14 até a 24 sendo slave da ether13. A ether13 vai ligada na ether1 de uma CCR1009 que é onde os clientes autenticam. Nessa mesma torre, recebo 2 links (um dedicado e outro que recebo de um provedor "maiorzão e mais fodão" de uma cidade perto por eles usarem a minha torre). Faço balanceamento entre esses links na CCR1009, tudo certinho.

    Na torre B, tenho mais clientes, e o trafego é todo gerenciado na mesma CCR da torre A.

    A torre C, na realidade é um prédio em uma outra cidade. Como esse précio C não enxerga minha torre A, tive que usar a torre B que é em cima de um morro. Porém, ao invés de eu criar 2 PTPs entre a torre A e B (uma para transportar o trafego de clientes e outra para o link) vou melhorar o PTP que ja existe, e transportar o link "por dentro da rede dos clientes". Na torre B, na RB450G que tenho lá, vou transformar ela em um futuro próxima em uma NAS, e os clientes vão autenticar diretamente lá, e o balanceamento feito lá, para evitar de um cliente que está na torre B precisar fazer sua requisição para a torre A, para voltar pra lá pelo mesmo PTP e ir para a torre C até o link, e voltar tudo denovo até a A para novamente voltar para a B até o cliente. Bom, isso é só transformar a RB numa NAS que resolvo.

    Agora, para transportar o link, eu fiz com VLAN.
    Conforme vocês podem ver no desenho. O ponto C tem uma vlan na interface onde está o PTP. Essa vlan está em uma bridge com a interface que recebe o link. Para toda essa "história" ficar transparente para a CCR1009, eu resolvi criar uma vlan na ether13 da CRS125 (que é a porta master de onde está ligado o PTP que vem da torre B) e coloquei a vlan em uma bridge, junto com a porta ether10. A porta ether10 da CRS125, por sua vez, liguei na ether8 da CCR1009.

    Está funcionando direitinho, estou recebendo o link na ether8 da CCR1009 na torre A, que na realidade está sendo transportado até a torre C por uma VLAN.


    Eu nunca usei MPLS, e li pouco sobre o assunto, apesar de parecer ser bem simples a implementação. Usando VLAN ou MPLS eu vou criar um overhead de 32bits (4bytes) no trafego. Por isso fiquei imaginando se teria alguma vantagem em fazer esse transporte por MPLS, pois por VLAN é simplíssimo de implementar e vai utilizar, no final das contas, a mesma quantidade dado para fazer o serviço que faz. O MPLS só teria vantagem, se a implementação dele fosse mais "simples" para as routerboards processarem, gerando menos uso da CPU para fazer o mesmo serviço.

    Alguém sabe me dar uma idéia? Ou do jeito que fiz já é bom o suficiente?

  2. #2

    Padrão Re: Transportar link por dentro da rede

    VLAN é melhor e mais eficiente forma de encapsular pacotes. Sempre que puder usar VLAN, faça isso, como é o seu caso.

    Com MPLS, túnel VPLS, dá um pouco de trabalho com os MTUs, porque funciona sobre camada 3. Se não puder aumentar o MTU de todos equipamentos para mais de 1500, tem como fazer funcionar, mas não vai ficar tão bom quanto com VLAN.

    Se pode resolver um problema em nível Ethernet, faça-o assim. Trabalhe em nível IP apenas quando for a única forma.

  3. #3
    Avatar de infor3
    Ingresso
    Mar 2013
    Localização
    Piedade de Ponte Nova e Região
    Posts
    527

    Padrão Re: Transportar link por dentro da rede

    Se arede dele fosse roteada não seria melhor? pois não vai precisar de bagunça tanto assim

  4. #4

    Padrão Re: Transportar link por dentro da rede

    Citação Postado originalmente por infor3 Ver Post
    Se arede dele fosse roteada não seria melhor? pois não vai precisar de bagunça tanto assim
    Particularmente, eu prefiro que todos enlaces PTP do backhaul estejam em bridge, e apenas no roteador do POP dos pontos de acesso seja feito roteamento. Melhor ainda se os PTPs forem conectados a switches, e não aos roteadores, para que ao reiniciá-los não interrompa o tráfego dali em diante.

    Agora, colocar tudo em bridge, incluindo os pontos de acesso e o roteador (RB) do POP, com clientes autenticando centralizados sem nenhum tipo de túnel, isso é terrível. Coloque essas duas RB450G nos pontos C e B para autenticar logo e evite tragédias na sua rede, @inquiery. =)

    Vi agora que para funcionar não é preciso usar VLAN, já que as portas dos PTPs na RB450G do ponto B estão em bridge. Basta que a CCR e a RB450G do ponto C estejam em uma mesma faixa de rede e criar a rota. Mas dessa forma pode ocorrer ICMP redirect, e isso não é legal. Use a VLAN mesmo...

  5. #5

    Ingresso
    Oct 2014
    Localização
    MS
    Posts
    697
    Posts de Blog
    1

    Padrão Re: Transportar link por dentro da rede

    ICMP redirect é problema? @TsouzaR

  6. #6

    Padrão Re: Transportar link por dentro da rede

    Buenas @TsouzaR

    A questão de eu não ter a principio utilizado diretamente a bridge para alcançar o link no ponto C era porque eu queria isolar o link de lá dos clientes, pois a partir do ponto B até o A, eles vão trafegar no mesmo PTP, e dai os clientes teriam acesso direto ao link, o que seria potencialmente perigoso.

    Vou ver se faço isso essa madrugada já, de transformar a RB450G no ponto B em um NAS. A do ponto C não é necessário, pois ela ta lá só pra receber o link, não é uma POP de atendimento de clientes (não por enquanto pelo menos).

    A questão de eu rotear a rede e deixar o acesso até o link em uma rede separada, ainda assim continuaria o problema potencial dos clientes terem a capacidade de alcançar o link diretamente. Por isso necessito isolar esse trafego. A solução que me veio inicialmente foi VLAN e MPLS, optei por VLAN por ser simplíssimo de configurar e por que, no final das contas, acrescenta o mesmo overhead no trafego.

    Mas vou rotear a rede sim. A minha rede é pequena, mas vou fazer um OSPFzinho entre os poucos POPs que tem, e colocar um NAS em cada.

  7. #7

    Padrão Re: Transportar link por dentro da rede

    Citação Postado originalmente por berghetti Ver Post
    ICMP redirect é problema? @TsouzaR
    O grande problemas das redes bridge!!!!

  8. #8

    Padrão Re: Transportar link por dentro da rede

    Citação Postado originalmente por berghetti Ver Post
    ICMP redirect é problema? @TsouzaR
    Citação Postado originalmente por emilidani Ver Post
    O grande problemas das redes bridge!!!!
    Não é um problema tão grande, o roteamento vai funcionar normalmente, mas pelo que sei, cria um monte de conexões inúteis na rede (além de atrapalhar testes de ping e traceroute): o ponto B tem o A como gateway, mas 1 dos gateways do A é o C e todos estão na mesma rede. Quando uma conexão for aberta entre o ponto B e A, ocorrerá a notificação de redirect do ICMP e a mesma conexão será refeita do ponto B para o C.

    O maior problema mesmo de uma rede totalmente em bridge é o tráfego broadcast do ARP.

  9. #9

    Padrão Re: Transportar link por dentro da rede

    Minha rede é em bridge, por enquanto, mas não tenho problema com ARP. Cada cliente só tem um único caminho possivel, que é o gateway dele (a CCR1009). E o trafego de broadcast cai SEMPRE lá, e eu posso escolher bloquear o forward ou não daquele trafego. O trafego entre clientes é, portanto, impossível, por mais que possam estar na mesma subrede.

    Eu defino regras no mangle fazendo marcação para habilitar o trafego geral dentro da rede, com forward possível para qualquer porta, transformando assim um IP em específico num computador de gerência da rede.

  10. #10

    Padrão Re: Transportar link por dentro da rede

    Citação Postado originalmente por inquiery Ver Post
    Minha rede é em bridge, por enquanto, mas não tenho problema com ARP. Cada cliente só tem um único caminho possivel, que é o gateway dele (a CCR1009). E o trafego de broadcast cai SEMPRE lá, e eu posso escolher bloquear o forward ou não daquele trafego. O trafego entre clientes é, portanto, impossível, por mais que possam estar na mesma subrede.

    Eu defino regras no mangle fazendo marcação para habilitar o trafego geral dentro da rede, com forward possível para qualquer porta, transformando assim um IP em específico num computador de gerência da rede.
    A única forma de bloquear a comunicação entre os clientes a nível Ethernet é fazendo isso nos pontos de acesso (desativando o default-forward em MikroTik ou ativando o Client Isolation em Ubiquiti, por exemplo).

    O tráfego Ethernet só vai até o ponto de acesso do cliente (rádio, OLT, switch...), e dali segue diretamente até o destino, sem passar por roteador algum. Só passa em roteador se o tráfego for entre dispositivos conectados em portas diferentes que estão em bridge, aí é possível filtrar.

    E não pode bloquear o tráfego ARP, se não você para toda a rede. Ele começa a se tornar um problema quando tem muitos dispositivos no mesmo domínio de broadcast (que só é quebrado com VLAN ou roteamento), pois todo mundo vai ficar enviando para todo mundo pacotes perguntando qual o MAC que responde por tal IP, e aí vem a resposta, mesmo estando em faixas IP diferentes. Isso resulta em um tráfego considerável, que vai usar capacidade dos equipamentos que poderiam estar atendendo a demanda dos clientes, pior ainda se os enlaces estiverem ruins ou forem muito limitados em banda.

    O máximo que você está controlando na sua CCR, sem usar VLAN para cada ponto de acesso, é o tráfego IP, que também tem broadcast, mas é em maior parte necessário.

    Por isso ter tudo, pontos de acesso, enlaces do backhaul, e pior ainda se nessa lista ir o CPE, é tão mal. Você não consegue controlar facilmente a comunicação Ethernet, e isso uma hora ou outra vai causar problemas, principalmente se o CPE estiver em bridge, dando ao cliente acesso ao backhaul, ou ao menos aos outros clientes no mesmo ponto de acesso.