Ospf Dando Erro

[trober]

Ola amigo tudo bem?

100%!

Efetuei as configurações aqui de duas formas.
1) Usando 3 Rbs 450g e duas SXT.
Essa não deu certo pois as SXT não permite passar a rota formando o circulo não entendi por que.

Que estranho isso. Já fiz o teste formando círculo com 6 SXT no perímetro, com RB750 no extremo, e não tive problemas.

2) Usando as 3 Rbs 450g o circulo funcionou perfeito.

Que boa notícia

Muito obrigado, por tudo vou continuar estudando aqui pra entender bem esse OSPF, qualquer material sobre o protocolo que voce tiver ou onde posso ler sobre ele será muito util.

Mas uma vez aprendi bastante aqui.

Obrigado mais uma vez e tenha muito sucesso.

Fico contente em ter ajudado

Uma ótima semana para todos nós.

Saudações,

Trober

[salvato]

Vou efetuar um novo teste hoje, vou ver se não errei em nada ontem a noite rsrs
Vamos ver se depois de uma noite de sono mau dormida consigo resolver pois enquanto eu nao conseguir nao durmo direito rsrsr.

To achando que errei pois na Ether da SXT coloquei dois rangers de ip sendo 172.20.4.0/24 pra acesso nos pcs e 172.10.0.4/30 que fecharia o enlace junto com a RB 450g, pode ser ai o erro. Vou tentar eliminar uma das redes.

[salvato]

Mechendo agora pela manha percebi que o erro esta na comunicação entre as interfacas Ether das SXT uma não pinga a outra de jeito nenhum.
A WLAN pingam pois estao diretamentes conectadas, jas as extremidades as LANs de cada uma delas não consegui, não sei se minha configuração das WLAN estão erradas ja que a licença dela é level 3 e não funciona como AP

[trober]

Vou efetuar um novo teste hoje, vou ver se não errei em nada ontem a noite rsrs
Vamos ver se depois de uma noite de sono mau dormida consigo resolver pois enquanto eu nao conseguir nao durmo direito rsrsr.

É bom descansar

To achando que errei pois na Ether da SXT coloquei dois rangers de ip sendo 172.20.4.0/24 pra acesso nos pcs e 172.10.0.4/30 que fecharia o enlace junto com a RB 450g, pode ser ai o erro. Vou tentar eliminar uma das redes.

Exatamente. A faixa de endereços para clientes precisa estar em roteador que tenha pelo menos três interfaces, uma para cada sentido do círculo (portanto duas, uma horário e outra antihorário) e a terceira para atender os clientes. No caso do SXT, você resolve isso de outras (monstruosas) maneiras, mas não vamos considerar isso neste tópico.

"Viajando" um pouco, e pensando com analogia hidráulica, cada roteador participante da circularidade precisa ser uma conexão tipo "T" (aquelas de PVC), conforme segue abaixo:

.
.
.  --------------------------------------------------
. |                                                  |
. |                  OSPF CIRCULAR                   |
. |                                                  |
. |                                                  |
. |         rtr        rtr        rtr        rtr     |
.  --------  A  ------  B  ------  C  ------  D  ----
.          \   /      \   /      \   /      \   /
.            T          T          T          T
.            |          |          |          |
.          norte      leste       sul       oeste
.            |          |          |          |
.            |          |          |          |
.            |          |          |           ----------[rtr-cliente-C]
.            |          |          |
.            |          |          |
.            |          |           ---------------------[rtr-cliente-B]
.            |          |
.            |          |
.            |           --------------------------------[rtr-cliente-A]
.            |
.      [rtr-gateway]
.

Espero ter ajudado.

Saudações,

Trober

[trober]

...ja que a licença dela é level 3 e não funciona como AP

Se é Level 3, estabeleça comunicação num extremo como bridge, e no outro como station-bridge.

Saudações,

Trober

[salvato]

Resolvi aqui amigo.

O problema estava em umas regras que criaram dinamicamente no firewall, que o que me parece estava bloqueando a comunicação entre as interfaces WLAN e LAN das SXT, ao desabilitar essas regras, funcionou 100%, como voce mesmo tinha relatado perdendo no maximo dois pings quando desconectado algumas das extremidades da rota.

Agora vou resetar tudo reconfigurar do zero pra fixar bem na cabeça, e tambem estudar sobre o protocolo pra entender sua teoria, e poder identificar com eficacia possiveis erros futuros.

Mais uma vez obrigado.

[trober]

Agora vou resetar tudo reconfigurar do zero pra fixar bem na cabeça

Cara, na boa, larga tudo e vai almoçar, descansar um pouco, hehehe.

Depois continua. Existe vida lá fora

Brincadeiras a parte, fico feliz pelo sucesso que está tendo nos testes

Saudações,

Trober

[salvato]

kkkk ja me disseram dessa vida la fora, mas ontem assisti o filme "Os Vingadores " e queria so metade daquela tecnologia na minha casa kkkk

Abraço

[bugingang]

Parabéns Trober, vai ajudar muitos inclusive eu obrigado.

[trober]

Parabéns Trober, vai ajudar muitos inclusive eu obrigado.

Fico contente em ter ajudado

[salvato]

Opa tudo bem!
O eu ai di novo rs até as 2 da manha testando OSPF estudando e aprendendo rs
Bom com o OSPF tudo certo, agora uma duvida?
To tentando fazer as RB se comunicarem com meu MK-AUTH que fica junto a RB CENTRAL.
Eu navego na net mas nao consigo altenticar pelo mk-auth segundo o pedro pra funcionar precisa apenas pingar no mk-auth.
So que as RB que estao no OSPF nao pingam na rede da RB CENTRAL nem PINGAM NO MK-AUTH como fazer?

[trober]

Opa tudo bem!

Tudo beleza

O eu ai di novo rs até as 2 da manha testando OSPF estudando e aprendendo rs
Bom com o OSPF tudo certo...

Que boa notícia!

...agora uma duvida?
To tentando fazer as RB se comunicarem com meu MK-AUTH que fica junto a RB CENTRAL.
Eu navego na net mas nao consigo altenticar pelo mk-auth segundo o pedro pra funcionar precisa apenas pingar no mk-auth.
So que as RB que estao no OSPF nao pingam na rede da RB CENTRAL nem PINGAM NO MK-AUTH como fazer?

Cara, tem como resolver, mas precisamos de mais elementos.

Faz o seguinte: Elabore um diagrama da topologia, fazendo com que fique evidente a posição de MK-AUTH e RB-CENTRAL dentro da sua rede, assim como seus links de internet e demais RBs participantes da circularidade.

Assim, não corro o risco de dar uma dica improdutiva

[salvato]

Boa Tarde!
Montei um desenho aqui pra tentar esclarecer melhor como quero deixar minha estrutura.


Seguindo a ideia do desenho terei dois balances:
1) Balance com 3 links adsl - PTP enviando link com ip FIXO para balanc e 2;
2) Balance 2 Recebendo link do balance 1 e link dedicado 10 Mbps;
3 RB 450G (central) recebendo link do balance 2 e Ether 1 com mk-auth e Ether 2 com cache;
4)RB Central, enviando em PTP com OSPF nas interfaces para POP1 e POP2
5)RB 450G com servidor PPPOE, e recebendo link da CENTRAL com OSPF na interface

E é ai que o bicho pega, pois preciso que a RB que esta no POP enchergue la na central meu MK-AUTH.
Eu consigo acessar o MK-AUTH CONSIGO ACESSAR MEU CACHE, mas o teste de ping de dentro da RB não pinga nos servidores. O que impede minha autenticação por radius.

[ddllss]

Observa se nessas rb´s que não estão pingando no mk-auth; se dentro dela tem algum ip na mesma faixa do mk-auth..
exemplo:
mk-auth --> 172.100.10.1
rb que não pinga no mk-auth tem a mesma faixa em qualquer interface --> 172.100.10.10

[salvato]

Ola amigos, boa tarde!
Consegui resolver aqui.
Solução implantei o OSPF como aprendi com meu amigo "trober", após ter feito a configuração das RBs entrei no meu MK-AUTH e cadastrei um novo servidor só que no cadastro setei o IP da interface que esta no OSPF.
O resto foi só configuração de comunicação via RADIUS.

Agora uma pergunta ao "trober", la atras vimos que no OSPF pra funcionar temos que anunciar todas as redes que estão ativas na RB só que voce mesmo comentou que não podemos utilizar isso como regra, porque?

Pois quando anunciei no OSPF a rede do mk-auth e do meu cache funcionou tudo perfeito.

[trober]

Agora uma pergunta ao "trober", la atras vimos que no OSPF pra funcionar temos que anunciar todas as redes que estão ativas na RB só que voce mesmo comentou que não podemos utilizar isso como regra, porque?

Sim, pois há casos em que você não deseja anunciar alguma rede. Se fosse simplesmente para anunciar todas, era só redistribuir rotas conectadas; o que é um perigo, como já reforçou nosso colega Gamineiro.

Cada caso é um caso diferente e peculiar, e muita gente, inclusive eu, prefere declarar redes no OSPF não mão, lá em routing ospf networks.

Deseja um exemplo dessas peculiaridades? Leia um tópico[1] meu, aqui no Under-Linux, sobre "OSPF Blackhole Server"

Espero ter ajudado.

[1] https://under-linux.org/f97/redistri...o-ospf-153931/

Saudações,

Trober

[salvato]

Sim, pois há casos em que você não deseja anunciar alguma rede. Se fosse simplesmente para anunciar todas, era só redistribuir rotas conectadas; o que é um perigo, como já reforçou nosso colega Gamineiro.

Cada caso é um caso diferente e peculiar, e muita gente, inclusive eu, prefere declarar redes no OSPF não mão, lá em routing ospf networks.

Deseja um exemplo dessas peculiaridades? Leia um tópico[1] meu, aqui no Under-Linux, sobre "OSPF Blackhole Server"

Espero ter ajudado.

[1] https://under-linux.org/f97/redistri...o-ospf-153931/

Saudações,

Trober

Mais uma vez obrigado, vou ler sim abraço

[salvato]

Ola amigo olha eu qui di novo com uma duvidinha no ospf
Montei OSPF entre duas torres minha só que esta dando uma mensagem de erro no log e a conexao cai as mensagens são:

--- OSPFv2 neighbor 172.0.0.2: state change from Full to Down
(isso na RB 1)

--- OSPFv2 neighbor 172.0.0.1: state change from Full to init

--- OSPFv2 neighbor 172.0.0.1: state change from Full to 2-Way
(isso na RB 2)

Os clientes estao navegando nonguem reclama de queda de conexão por que acho que esta rapido e o cra nem percebe nao ser que esteja efetuando algum download

Como corrigir isso, e nesse caso é melhor mesmo OSPF ou criar uma vlan entre as torres?

[rafaeldsv]

Opa! Concluí aqui

Vamos a nomenclatura dos ativos:

rtr-internet: É o roteador (FreeBSD) que está conectado à internet. O único da rede toda que tem NAT. As redes previstas no RFC1918 estão sendo encaminhadas estaticamente para rtr-a. Eu poderia fazer OSPF no FreeBSD, mas não é o foco da demonstração.

rtr-a: Uma RB750G, ao norte do círculo, com três interfaces, sendo ether5 voltada para o servidor FreeBSD (nosso gateway com NAT). As ethernets de cada RB representam um segmento (perna) de rede. Veja que ether1 de rtr-a conversa com ether1 de rtr-b. Já a ether2 de rtr-b conversa com ether2 de rtr-c. E assim sucessivamente, para demonstrar, de forma mais didática, cada "perna" de rede (ou braço, vai do apelido que cada um prefere dar. Eu sou mais fã de "segmento").

rtr-b: Uma RB750G, ao leste do diagrama. Conversa com rtr-a e rtr-c.

rtr-c: Uma RB751G-2HnD, ao sul do diagrama. Conversa com rtr-b, rtr-d e também uma estação de teste, chamada wks-test, de endereço 192.168.140.5/24, simulando o extremo da rede, a ser provida com redundância.

rtr-d: Uma RB751G-2HnD, que desempenha o mesmo papel de rtr-b, só que do lado oeste do circuito, conversando com rtr-c e rtr-a.

wks-test: Uma estação de teste. Um notebook rodando PC-BSD. Tem endereço IP 192.168.140.5/24, e gateway 192.168.140.3.

Abaixo, o diagrama

 
.                              (200.200.200.2/30)
.                              [rtr-internet] 
.                              (192.168.250.1) 
.                                     | 
.                                     | 
.                                     | 
.                                     | 
.                               192.168.250.100 
.                                   ether5 (lo1 172.30.0.1) 
.               (172.17.4.1) ether4 [rtr-a] ether1 (172.17.1.1) 
.                            |                   | 
.                            |                   | 
.                            |                   | 
.                            |                   | 
.                            |                   | 
.                            |                   | 
.          (172.17.4.4) ether4                   ether1 (172.17.1.2) 
.(lo1 172.30.0.4) [rtr-d]                             [rtr-b] (lo1 172.30.0.2) 
.          (172.17.3.4) ether3                   ether2 (172.17.2.2) 
.                            |                   | 
.                            |                   | 
.                            |                   | 
.                            |                   | 
.                            |                   | 
.                            |                   | 
.               (172.17.3.3) ether3 [rtr-c] ether2 (172.17.2.3) 
.                                   ether5 (lo1 172.30.0.3) 
.                              (192.168.140.3) 
.                                     | 
.                                     | 
.                                     | 
.                                [wks-test] 
.                              (192.168.140.5) 
. 
. 
. 
. 
.
.
.
.
.
.
.

A circularidade funciona 100%. Desconecta de um lado, o lado oposto assume. Perde uma ou duas sequências ICMP, sendo quase imperceptível ao usuário final.

Aqui vai o código de rtr-a:

# rtr-a
# 
#
 
/interface bridge add name=loopback
 
/routing ospf instance set [ find default=yes ] distribute-default=always-as-type-1 router-id=172.30.0.1
 
/ip address add address=172.30.0.1/32 interface=loopback network=172.30.0.1
/ip address add address=172.17.1.1/29 interface=ether1
/ip address add address=172.17.4.1/29 interface=ether4
/ip address add address=192.168.250.210/24 interface=ether5
 
/ip dns set servers=192.168.250.1
 
/ip route add distance=1 gateway=192.168.250.1
 
/routing ospf interface add interface=loopback network-type=broadcast passive=yes
/routing ospf interface add interface=ether1 network-type=broadcast
/routing ospf interface add interface=ether4 network-type=broadcast
/routing ospf interface add interface=ether5 network-type=broadcast passive=yes
 
/routing ospf network add area=backbone network=172.30.0.1/32
/routing ospf network add area=backbone network=172.17.1.0/29
/routing ospf network add area=backbone network=172.17.4.0/29
 
 
 
 
/system identity set name=rtr-a
 
 
 
 
 
#

Aqui vai o código de rtr-b:

# rtr-b
#
#
 
/interface bridge add name=loopback
 
/routing ospf instance set [ find default=yes ] router-id=172.30.0.2
 
/ip address add address=172.30.0.2/32 interface=loopback network=172.30.0.2
/ip address add address=172.17.1.2/29 interface=ether1
/ip address add address=172.17.2.2/29 interface=ether2
 
 
/ip dns set servers=192.168.250.1
 
 
 
/routing ospf interface add interface=loopback network-type=broadcast passive=yes
/routing ospf interface add interface=ether1 network-type=broadcast
/routing ospf interface add interface=ether2 network-type=broadcast
 
 
/routing ospf network add area=backbone network=172.30.0.2/32
/routing ospf network add area=backbone network=172.17.1.0/29
/routing ospf network add area=backbone network=172.17.2.0/29
 
 
 
 
/system identity set name=rtr-b
 
 
 
 
 
#

Aqui vai o código de rtr-c:

# rtr-c
#
#
 
/interface bridge add name=loopback
 
/routing ospf instance set [ find default=yes ] router-id=172.30.0.3
 
/ip address add address=172.30.0.3/32 interface=loopback network=172.30.0.3
/ip address add address=172.17.2.3/29 interface=ether2
/ip address add address=172.17.3.3/29 interface=ether3
/ip address add address=192.168.140.3/24 interface=ether5
 
/ip dns set servers=192.168.250.1
 
 
 
/routing ospf interface add interface=loopback network-type=broadcast passive=yes
/routing ospf interface add interface=ether2 network-type=broadcast
/routing ospf interface add interface=ether3 network-type=broadcast
/routing ospf interface add interface=ether5 network-type=broadcast passive=yes
 
/routing ospf network add area=backbone network=172.30.0.3/32
/routing ospf network add area=backbone network=172.17.2.0/29
/routing ospf network add area=backbone network=172.17.3.0/29
/routing ospf network add area=backbone network=192.168.140.0/24
 
 
 
/system identity set name=rtr-c
 
 
 
 
 
#

Aqui vai o código de rtr-d:

# rtr-d
#
#
 
/interface bridge add name=loopback
 
/routing ospf instance set [ find default=yes ] router-id=172.30.0.4
 
/ip address add address=172.30.0.4/32 interface=loopback network=172.30.0.4
/ip address add address=172.17.3.4/29 interface=ether3
/ip address add address=172.17.4.4/29 interface=ether4
 
 
/ip dns set servers=192.168.250.1
 
 
 
/routing ospf interface add interface=loopback network-type=broadcast passive=yes
/routing ospf interface add interface=ether3 network-type=broadcast
/routing ospf interface add interface=ether4 network-type=broadcast
/routing ospf interface add interface=ether5 network-type=broadcast passive=yes
 
/routing ospf network add area=backbone network=172.30.0.4/32
/routing ospf network add area=backbone network=172.17.3.0/29
/routing ospf network add area=backbone network=172.17.4.0/29
 
 
 
 
/system identity set name=rtr-d
 
 
 
 
 
#

Observações importantes:

Lá em rtr-c, você ao ter o círculo fechado, você terá uma rota padrão ECMP (Equal Cost Multi Path), ou seja, com dois gateways de mesmo custo.

Outra coisa muito importante. O OSPF tem um tempo de convergência. Então não pense em ficar "fapando cabo" (hehehe) na porta, a cada 5 segundos, achando que terá convergência em tempo real. Detectar queda é instantâneo. Detectar retorno leva não menos que 10 segundos, tempo do Hello Interval. Aqui é entra a questão de atualização entre roteadores e tal, e a conversa vai longe, não sendo o propósito inicial desse tópico.

Para finalizar, funcionou aqui 100% e funciona em todos o provedores, prefeituras e mais um pool de cliente que tenho em produção

Espero ter sido útil o material a você e demais colegas do Under-Linux.

Saudações,

Trober

Trober tenho que agradecer pela excelente explicação, fiz agora em laboratório e o mesmo funcionou 100%, sou meio leigo mais tenho algum conhecimento.

Estou com duvida referente a loopback o por que dela?
Porque as ether da loopback,link que seria da ether 5 (rtr-a) ,nootebok que seria ether 5 (rtr-c ) tem que estar como passiva na interface da ospf.
Qual versão do Mikrotik que vc trabalha que é mais estável, precisa todos os routers esta na mesma versão?
Todos os ips que forem dos clientes que conectaram no router/RB, tenho que colocar a network da faixa do ip em ospf network? exp ( clientes ganharam o ip nessa faixa 172.16.x.x, preciso setar a network desse ip em ospf network que seria 172.16.x.0.?)

Obrigado deis de já.

[trober]

Trober tenho que agradecer pela excelente explicação, fiz agora em laboratório e o mesmo funcionou 100%, sou meio leigo mais tenho algum conhecimento.

Que boa notícia. Fico contente pelo êxito em seus testes. Também parabenizo-o por fazer teste em laboratório, antes de ir para produção.

Estou com duvida referente a loopback o por que dela?
Porque as ether da loopback,link que seria da ether 5 (rtr-a) ,nootebok que seria ether 5 (rtr-c ) tem que estar como passiva na interface da ospf.

A resposta está em outro post[1] meu, sobre OSPF.

Qual versão do Mikrotik que vc trabalha que é mais estável, precisa todos os routers esta na mesma versão?

Já respondido[1] também

Todos os ips que forem dos clientes que conectaram no router/RB, tenho que colocar a network da faixa do ip em ospf network? exp ( clientes ganharam o ip nessa faixa 172.16.x.x, preciso setar a network desse ip em ospf network que seria 172.16.x.0.?)

Sim[1].

Obrigado deis de já.

Beleza!

Desejo sucesso em sua implementação.

[1] https://under-linux.org/f343/ospf-qu...45/#post640420

Saudações,

Trober