Routerboard Pinga mais não tenho acesso diretamente

[marconipcd]

Olá pessoal,

Estou migrando minha rede bridge para OSPF são 8 Rbs que estão todas em linha, praticamente todas elas tem a mesma configuração, exceto duas stx que fecham um enlace entre a central e outra base, todas tem um interface bridge para loopback declarada como passiva, as interfaces que se comunicam via OSPF estão como broadcast, existe também um servidor hotspot configurado em todas elas, todas tem redes distintas para clientes, enfim, ta tudo funcionando perfeitamente, mais vem acontecendo alguns fenomenos que tenho observado, queria compartilhar com todos, como tenho resolvido e saber se alguem tem passado por isso, as vezes umas das rbs não consegue pegar as rotas da rb principal, mais reconhece de todas as outras, quando isto acontece não adianta somente eu desabilitar a instancia do ospf, apagar as networks e interfaces e configurar tudo novamente, tenho que alterar o ip da rb ai habilito a instancia novamente e tudo volta a funcionar, outro questão que na verdade é uma dúvida é que depois que habilito o ospf entre elas, eu consigo pingar todas elas tanto pelos ips normais quanto pelo ip de loopback, porém só consigo acessar diretamente da minha maquina a rb principal e mais nenhuma outra, gostaria de saber se mais alguem já passou por um dos problemas citados acima: vale lembrar que todas elas estão rodando a versão 5.20 e firmeware também esta atualizado 2.41 de todas elas e também verifiquei que nas rbs que apresentaram problema de não reconhecer rotas esta com alguns bad blocks teria alguma coisa haver??


Agradeço desde já, a quem possa me dar uma luz!

[HPNetwork]

Na rb de saida para a internet vc configurou para ela distribuir a rota padrao para as rbs internars?
Pois pelo que eu entendi acho que vc nao fez isso. Mais para ter certeza vc teria que passar as config do seu ospf.

[marconipcd]

Na rb de saida para a internet vc configurou para ela distribuir a rota padrao para as rbs internars?
Pois pelo que eu entendi acho que vc nao fez isso. Mais para ter certeza vc teria que passar as config do seu ospf.

Olá HPNetwork, agradeço desde já pelo interesse em ajudar e pela resposta, a minha rb central está sim distribuindo a rota default, tanto é que nas oturas rb tudo esta funcionando normalmente, abaixo segue as configurações de cada uma delas:

RB Central(Firewall)

/routing ospf instance
set [ find default=yes ] distribute-default=always-as-type-1 redistribute-other-ospf=as-type-1 redistribute-static=as-type-1 router-id=172.0.0.1
/routing ospf interface
add interface=loopback network-type=broadcast passive=yes
add interface=RADIO network-type=broadcast
add interface=LINK100MB network-type=broadcast passive=yes
add interface=LOJA network-type=broadcast passive=yes
add interface=CONTROLE network-type=broadcast passive=yes
add interface=CABO network-type=broadcast passive=yes
/routing ospf nbma-neighbor
add address=172.0.1.6 disabled=yes
add address=172.0.1.2 disabled=yes
add address=172.0.1.3 disabled=yes
add address=172.0.1.4 disabled=yes
add address=172.0.1.5 disabled=yes
/routing ospf network
add area=backbone network=172.0.0.1/32
add area=backbone network=172.17.1.0/29




RB BASE01 RB2

/routing ospf instance
set [ find default=yes ] router-id=172.0.0.2
/routing ospf interface
add interface=loopback network-type=broadcast passive=yes
add interface="ether1 - Link Servidor" network-type=broadcast
add interface="ether3 -Link PTP01-03 (SXT5HnD)"
/routing ospf network
add area=backbone network=172.0.0.2/32
add area=backbone network=172.17.1.0/29
add area=backbone network=172.17.2.0/29




a configuração da RB BASE01 RB2 é a mesma configuração das demais depois dela, só mudando as interfaces e respectivas faixas de ips estabelecidas, fecha vizinhança pra todas, porém as vezes quando reinicio uma ou outra fica sem fechar e sem receber as rotas das demais, a resolução bem deselegante desse problema tenho mostrado no post inicial e embora eu consiga pingar todas elas não consigo acessa-las do meu computador exceto a RB Central, que é o Firewall, agradeço mais uma vez a todos..

[trober]

abaixo segue as configurações de cada uma delas

Boa tarde.

Recomendo ao colega exportar as configurações usando a opção compact[1][2]. Dessa forma, ficará mais fácil para outros colegas analisarem suas configurações.

Também recomendo usar endereços de loopback que não violem o RFC1918[3], conforme recomendado em outro tópico[4] sobre o assunto.

[1] https://under-linux.org/f143/restaur...24/#post605439
[2] http://wiki.mikrotik.com/wiki/Manual...Compact_Export
[3] http://tools.ietf.org/html/rfc1918
[4] https://under-linux.org/f343/ospf-da...51/#post618154

Saudações,

Trober

[marconipcd]

Boa tarde.

Recomendo ao colega exportar as configurações usando a opção compact[1][2]. Dessa forma, ficará mais fácil para outros colegas analisarem suas configurações.

Também recomendo usar endereços de loopback que não violem o RFC1918[3], conforme recomendado em outro tópico[4] sobre o assunto.

[1] https://under-linux.org/f143/restaur...24/#post605439
[2] http://wiki.mikrotik.com/wiki/Manual...Compact_Export
[3] http://tools.ietf.org/html/rfc1918
[4] https://under-linux.org/f343/ospf-da...51/#post618154

Saudações,

Trober

Obrigado pela resposta Trober, já exportei novamente as regras, quanto ao Endereço de loopback estarem violando a RFC1918, fora deste padrão(ainda não li realmente sobre a RFC1918, mais lerei.. hehehe), você acha que isso pode esta causando algum dos problemas que citei?

[trober]

Obrigado pela resposta Trober, já exportei novamente as regras, quanto ao Endereço de loopback estarem violando a RFC1918, fora deste padrão(ainda não li realmente sobre a RFC1918, mais lerei.. hehehe), você acha que isso pode esta causando algum dos problemas que citei?

De forma genérica, não deveria causar problemas. Entretanto, por eu não saber como estão outros filtros e regras de firewall, nos seus ativos, pode, na existência desses, apresentar problemas.

Segundo o RFC1918, o endereço 172.0.0.0 é público, uma vez que os endereços privados, de mesma classe, iniciam em 172.16.0.0 e terminam em 172.31.255.255, ou seja 172.16.0.0/12. É uma boa prática filtrar endereços privados para que não "vazem" para uma rede pública, e que endereços que não são detidos por você, não acessem seus ativos.

Analogicamente falando, é um postura igual a filtros de bogon.

Analisando seu código, agora compactado, vi que na RB-Central, você não anunciou a interface e rede de acesso externo. Só para confirmar, essa RB que é sua saída para a internet. Correto?

Saudações,

Trober

[marconipcd]

Só para confirmar, essa RB que é sua saída para a internet. Correto?

Sim, antes dessa rb Central tenho uma Outra que Faz um Balanceamento PCC e estão conectadas e a Rb Central existe um rota default para rb Balanceamento, quanto as regras da Rb Firewall específicamente configurações do "firewall" são:

/ip firewall address-list
add address=69.171.247.0/24 disabled=yes list=facebook
add address=66.220.153.0/24 disabled=yes list=facebook
add address=192.168.20.10 list=excessao
add address=192.168.20.5 list=excessao
/ip firewall connection tracking
set generic-timeout=3m tcp-established-timeout=10m tcp-syncookie=yes
/ip firewall filter
add chain=input dst-port=801 protocol=tcp
add chain=input dst-port=10001 protocol=tcp
add chain=input dst-port=10002 protocol=tcp
add chain=input dst-port=15000 protocol=tcp
add chain=input dst-port=36456 protocol=tcp
add chain=input dst-port=36567 protocol=tcp
add chain=input dst-port=36570 protocol=tcp
add chain=input dst-port=37466 protocol=tcp
add chain=input dst-port=47611 protocol=tcp
add chain=input dst-port=27888 protocol=udp
add chain=input dst-port=28888 protocol=udp
add action=drop chain=forward comment="BLOQUEIO DO FACEBOOK" content=facebook in-interface=LOJA protocol=tcp src-address-list=!excessao
add action=drop chain=forward src-address-list=bloqueado
/ip firewall mangle
add action=mark-connection chain=prerouting comment=FACEBOOK dst-address-list=facebook dst-port=80 new-connection-mark=conn_facebook protocol=tcp
add action=mark-packet chain=postrouting comment="dscp->12) => [packet_speedr_HIT]" new-packet-mark=packet_speedr_HIT passthrough=no src-address=192.168.20.13
add action=mark-packet chain=postrouting comment="dscp->10 => [packet_speedr_HIT]" dscp=10 dst-address=192.168.20.13 new-packet-mark=packet_speedr_HIT passthrough=no
add action=jump chain=prerouting comment=" PG CORTE" jump-target=hotspot
/ip firewall nat
add chain=srcnat protocol=ospf
add action=masquerade chain=srcnat comment=COMPARTILHAMENTO out-interface=LINK100MB src-address=0.0.0.0/0
add action=dst-nat chain=hotspot comment="PG CORTE PARA HOSTPOT + RADIUS" packet-mark=bloqueado protocol=tcp to-addresses=192.168.20.13 to-ports=89
add action=dst-nat chain=dstnat comment="CREMOSINHO - REDIRECIONAMENTO IP VALIDO" dst-address=192.10.2.2 protocol=udp to-addresses=172.0.1.7
add action=dst-nat chain=dstnat dst-address=192.10.2.2 protocol=tcp to-addresses=172.0.1.7
add action=dst-nat chain=dstnat comment="JOSE ALBERTO DE LUNA BORGES - REDIRECIONAMENTO IP VALIDO" dst-address=10.10.0.2 protocol=tcp to-addresses=192.8.210.2
add action=dst-nat chain=dstnat dst-address=10.10.0.2 protocol=udp to-addresses=192.8.210.2
add action=dst-nat chain=dstnat comment="WJV COMPANY - IND. E COM. LTDA. - REDIRECIONAMENTO IP VALIDO" dst-address=11.11.0.2 protocol=tcp to-addresses=20.20.0.2
add action=dst-nat chain=dstnat dst-address=11.11.0.2 protocol=udp to-addresses=20.20.0.2
add action=dst-nat chain=dstnat comment="STANDALONE DIGITAL - REDIRECIONAMENTO IP VALIDO" dst-address=12.12.0.2 protocol=tcp to-addresses=192.168.20.14
add action=dst-nat chain=dstnat dst-address=12.12.0.2 protocol=udp to-addresses=192.168.20.14
add action=dst-nat chain=dstnat comment="SANTO ANTONIO MOTOS LTDA - REDIRECIONAMENTO IP VALIDO" dst-address=13.13.0.2 protocol=tcp to-addresses=192.5.125.2
add action=dst-nat chain=dstnat dst-address=13.13.0.2 protocol=udp to-addresses=192.5.125.2
add action=dst-nat chain=dstnat dst-address=14.14.0.2 protocol=tcp to-addresses=192.168.20.13
add action=dst-nat chain=dstnat comment="REDIRECIONAMENTO - MARCONI" dst-address=19.19.0.2 protocol=tcp to-addresses=192.168.20.13


Agradeço mais uma vez as informações!

[trober]

É possível um convívio harmonioso[1] entre OSPF e NAT, mas requer alguns cuidados.

A regra que destaco abaixo, que é uma porção do seu script, talvez seja um problema.

 /ip firewall nat add chain=srcnat protocol=ospf

OSPF não deve ser "mascarado". Quando for fazer NAT na interface que tem OSPF em execução, o ideal é definir explicitamente a faixa de endereços (source address) dos clientes, excluindo assim, implicitamente, seus endereços de enlace.

Você também precisa anunciar seus endereços de WAN, no OSPF (network). Somente na RB-Central você anunciará a rota padrão (as-type-1).

[1] https://under-linux.org/f343/sequenc...49/#post624208

Saudações,

Trober

[marconipcd]

OSPF não deve ser "mascarado". Quando for fazer NAT na interface que tem OSPF em execução, o ideal é definir explicitamente a faixa de endereços (source address) dos clientes, excluindo assim, implicitamente, seus endereços de enlace.

a referida regra foi justamente uma tentativa de resolver este problema, tinha colocado ela em todas as rbs, mais pra ser sincero, não vi nenhuma mudança antes e depois de configura-la, então acho que poderia desabilita-la, o que acha?

Você também precisa anunciar seus endereços de WAN, no OSPF (network). Somente na RB-Central você anunciará a rota padrão (as-type-1).

Eu anuncie em network no OSPF meu endereço WAN, a dúvida é se a Interface WAN deve continuar passiva, como atualmente esta ou não??


Obrigado mais uma vez, pela paciência e empenho em tentar me ajudar Trober, cada dia estou aprendendo um pouquinho mais com este forum, graças a Pessoas como você!

[trober]

a referida regra foi justamente uma tentativa de resolver este problema, tinha colocado ela em todas as rbs, mais pra ser sincero, não vi nenhuma mudança antes e depois de configura-la, então acho que poderia desabilita-la, o que acha?

Pode apagar. Em versões antigas do MikroTik RouterOS era necessário fazer uma tratativa ao protocolo OSPF, colocando uma exceção na regra mais ao topo (0 - zero). Atualmente não é mais necessário.

Eu anuncie em network no OSPF meu endereço WAN, a dúvida é se a Interface WAN deve continuar passiva, como atualmente esta ou não??

Sim. Interfaces que não "conversam OSPF", devem ser declaradas como passivas.

Não vejo sua WAN declarada em network, conforme seu código original.

/routing ospf network
add area=backbone network=172.0.0.1/32
add area=backbone network=172.17.1.0/29

Obrigado mais uma vez

Espero ter ajudado.

Saudações,

Trober

[marconipcd]

Não vejo sua WAN declarada em network, conforme seu código original.

Na verdade não estava adicionei depois de seu conselho, já adicionei aqui e retirei aquela regra de todas as outras rbs, só mais uma dúvida a Rb principal só deve distribuir somente as rotas default?? ou também as conectadas e outros tipo de rotas OSPF?

Só mais uma dúvida, como falei no inicio, eu consigo pingar através do endereço de loopback todas as rbs, diretamente do meu computador que esta ligado a interface que conversa atraves do OSPF, porem não consigo acessa-las, eu deveria poder também ? ou é normal só pingar?

Agradeço mais uma vez pela respostas e também pela paciência em minhas dúvidas!

obs.: em todas as outras rbs eu não tenho nenhum tipo de filtro, somente nat masquerade no firewall, da mesma forma que existe na Rb Central.

[trober]

só mais uma dúvida a Rb principal só deve distribuir somente as rotas default?? ou também as conectadas e outros tipo de rotas OSPF?

Somente a RB que está mais ao extremo (link) da sua rede que irá distribuir a rota padrão. Tem um post[1] meu explicando isso.

Não redistribua rotas conectadas. Tem outro post[2] meu que explica o perigo de anunciar as rotas conectadas.

Só mais uma dúvida, como falei no inicio, eu consigo pingar através do endereço de loopback todas as rbs, diretamente do meu computador que esta ligado a interface que conversa atraves do OSPF, porem não consigo acessa-las, eu deveria poder também ? ou é normal só pingar?

Por padrão seu computador não é um roteador que "conversa" OSPF, logo, ele precisa é "conversar" com uma interface passiva, como qualquer outra estação. Veja exemplo em outro post[3].

obs.: em todas as outras rbs eu não tenho nenhum tipo de filtro, somente nat masquerade no firewall, da mesma forma que existe na Rb Central.

Tenha cuidado com esse mascaramento, conforme comentei em post anterior. Para não errar, faça NAT só em interface passiva ao OSPF. No source address não pode ter endereços de enlaces.

Agradeço mais uma vez pela respostas e também pela paciência em minhas dúvidas!

Estamos aí

Complementando, recomendo a leitura de tópicos sobre redundância[1] circular[3], com uso de OSPF.

Mesmo que sua rede seja "linear", as recomendações lá contidas são válidas, funcionais e endossadas[2] por outros usuários que obtiveram êxito na implementação.

Faça os testes de laboratório antes da implementação do OSPF em produção. Há que já fez implementação não tão correta, em ambiente de produção, apesar de orientado insiste no erro[2], e acha que é um bug que não[4] existe.

[1] https://under-linux.org/f343/ospf-da...51/#post618154
[2] https://under-linux.org/f343/ospf-qu...45/#post640420
[3] https://under-linux.org/f343/ospf-da...51/#post618582
[4] https://under-linux.org/attachments/...pf-30-days.jpg

Saudações,

Trober

[HPNetwork]

Vc esta com alguns equivocos na sua rede. Primeiro que vc não poderia usar a classe de rede 172.0.0.0 em sua rede privada pois a mesma e publica, vc soh pode user da 172.16.0.0 ateh a 172.32.0.0 entende. isso e um dos pontos e o segundo eh que vc soh pode distribuir a rota default uma unica vez, e nao redistribuir em todas as rbs, pois assim vc deixa o ospf "louco", quando vc redistribui a rota default vc esta dizendo para as outras rbs onde esta a saida para a internet, isso a grosso modo, e se vc faz isso para todas vc dis que tem mais que uma rota de saida, assim ele ira chegar a um determinado tempo e ira se perder no caminho.
se quiser uma consultoria é soh me add no msn. [email protected]. att.

[marconipcd]

segundo eh que vc soh pode distribuir a rota default uma unica vez, e nao redistribuir em todas as rbs

Realmente só quem esta distribuindo é a RB central, mesmo assim muito Obrigado pela dica HPNetwork

vc não poderia usar a classe de rede 172.0.0.0 em sua rede privada pois a mesma e publica, vc soh pode user da 172.16.0.0 ateh a 172.32.0.0 entende

Entendi sim, e já modifiquei todos os Ips de Loopback das minhas rbs que estão Roteadas, porém surgiu outra dúvida, 172.32.0.1-172.32.0.8 é uma area, umas das 4 de toda a rede, na RB central eu Posso colocar mais de um Ip de Loopback, por Ex.: 172.32.0.1- para primeira Area
172.31.0.1- para segunda Area
172.30.0.1- para terceira Area
172.29.0.1- para quarta Area

só por questão de organização mesmo, ou teria que ser minhas 27 RBs todas na mesma faixa?

Faça os testes de laboratório antes da implementação do OSPF em produção. Há que já fez implementação não tão correta, em ambiente de produção, apesar de orientado insiste no erro[2], e acha que é um bug que não[4] existe.

Acabei de montar uma estrutura tentando simular meu ambiente de produção aqui na Bancada, segui todas as Dicas que Foram descritas em Todo Tópico até agora e funcionou redondo, muito legal, consigo pingar e acessar todas as rbs em linha que liguei e configurei o OSPF, vou estudar mais um pouco as modificações que terei que fazer no ambiente de produção para implementa-las e depois vou postar aqui o resultado final, gostaria de Agradecer a trober e HPNetwork pelas dicas e respostas e por toda Paciência que tiveram nas minhas dúvidas.

Uma dica pra quem ta começando agora: Planejar é preciso!!! pensar no futuro, senão vai sofrer igual estou sofrendo, kkkkkkkkkkk 1000 cliente, distribuidos em 10 bases e 24 rbs toda em Bridge, broadcast Terrível, mais 1 Base estou quase terminando...heheheh

[trober]

só por questão de organização mesmo, ou teria que ser minhas 27 RBs todas na mesma faixa?

Você pode usar endereços de loopback sequencialmente, pois com um único comando no nmap, você avalia se todas as RBs estão operacionais

Acabei de montar uma estrutura tentando simular meu ambiente de produção aqui na Bancada, segui todas as Dicas que Foram descritas em Todo Tópico até agora e funcionou redondo, muito legal, consigo pingar e acessar todas as rbs em linha que liguei e configurei o OSPF,

Fico feliz pelo seu êxito

Saudações,

Trober

[marconipcd]

Olá pessoal, como prometi voltar com o resultado das implementações em ambiente de produção, quero dizer que funcionou perfeitamente, todas as Rbs roteadas, consigo pingar e acessar todas elas, em todas tem hotspot configurado autenticando via radius, tudo fucionando redondo, porém(lá vem mais um.. hehehe) surgiu um efeito colateral para todo o resto da rede, num sei bem se teve haver com o OSPF ou esta sendo uma mera conhecidencia, antes da minha RB Central eu Tenho outra RB Balanceamento PCC que fazia alguns NAT com Ips Válidos para MInha RB Central que por Sua Vez agora Deveria Repassa-los pra uma RB que Por sua Vez repassava para um IP Privado de um cliente, tenho também outros NAT no meu Balanceamento pra outros clientes que estão conectados em outras Rbs que ainda Estão em Bridge, só que parou tudo, não ta funcionando nenhum dos NAT, o OSPF teve alguma Influência nisso? mesmo sem a RB Balanceamento esta Roteada? Agradeço desde já!

[marconipcd]

Pessoal, implementei agora a RB Balanceamento no OSPF, seguindo a seguinte estrutura:




mais o problema dos Redirecionamentos continua! o interessante é que todas as outras rbs eu consigo fazer o nat perfeitamente para um cliente, até de um ip Privado para Outro ip Privado, porém da primeira Rb(Balanceamento) o NAT não funciona, as configuração estão praticamente identicas em todas, exceto as Regras de PCC na primeira RB e a Segunda RB(Firewall) não esta mais distribuindo ROTA Default agora esse é o Papel da Primeira RB realmente, exceto o NAT1:1 tudo esta funcionando perfeitamente, alguem sugere alguma modificação para resolver este probleminha?? será que alguem passou por isso?

[HPNetwork]

Vc faz nat entre as rbs? vc tem algum nat entra a rb pcc e a de firewall??

[marconipcd]

Pessoal,consegui botar pra funcionar! Na verdade nao sei bem qual era o problema, mais acabei refazendo toda a configuração do pcc ai funcionou tudo 100% tudo mesmo e pro meu propósito foi somente divulgar a rede privada do meu cliente na Rb que ele esta conectado e fazer um redirecionamento direto da R b que faz o balanceamento. Agradeço a todos mais um vez!

[trober]

Pessoal,consegui botar pra funcionar!

Que boa notícia

Na verdade nao sei bem qual era o problema, mais acabei refazendo toda a configuração do pcc ai funcionou tudo 100% tudo mesmo e pro meu propósito foi somente divulgar a rede privada do meu cliente na Rb que ele esta conectado e fazer um redirecionamento direto da R b que faz o balanceamento.

Compara os exports anteriores com os atuais, para mitigar o erro.

Agradeço a todos mais um vez!

Estamos aí

Saudações,

Trober