Configurar vizinhança OSPF em um endereço IP secundário

Olá pessoal, espero que tenham tido um ótimo fim de semana.

Tenho que configurar a vizinhança OSPF entre meu MLS (switch multicamadas) e meu concentrador VPN por razões de redundância.

O problema é que o endereço IP público do concentrador VPN está na sub-rede de um endereço IP secundário do MLS, conforme ilustrado no seguinte diagrama:

Pelo que sei, o OSPF só envia pacotes hello pelo endereço IP primário. Isso significa que, mesmo que eu declare a rede 10.10.20.0 no OSPF e torne a interface ativa, o VPN não receberá nenhum pacote hello do OSPF.

Qual é a melhor maneira nesse caso de formar uma vizinhança entre esses dois dispositivos?

Obrigado desde já, tenham uma ótima semana!

Faça o VLAN de 10.10.20 assumir sua própria VLAN.

Acho que você precisa configurar o vizinho manualmente para isso funcionar. Mas será um design ruim.

Existem várias maneiras de fazer isso, mas aqui está como eu pessoalmente faço.

Eu uso ponto a ponto /30 em cada interface física entre cada roteador/dispositivo, e faço o OSPF funcionar nessas conexões. Depois coloco todas as sub-redes reais em uma interface agregada, e anuncio essa agregada no OSPF.

Para quem estiver passando pelo mesmo problema, aqui está como resolvi: mudei o endereço IP do concentrador VPN.
Agora ele tem um endereço IP da “sub-rede primária” para que possam se comunicar usando OSPF.

Estou tentando encontrar uma maneira de anunciar as “sub-rede VPN remota” usando OSPF. Alguém já fez isso em um concentrador VPN? Tentei usar interfaces de loopback para ver se anunciaria a sub-rede, mas parece que elas não são usadas pelo OSPF (não posso executar comandos “ip ospf” / “ospf” nas interfaces de loopback enquanto funciona nas interfaces gigabitethernet normais).

Talvez eu deva usar outro protocolo :/"},{

Ok, obrigado, não tinha considerado essa solução. Vou ver se consigo encontrar algo mais “orientado ao OSPF”.

Interessante. Isso é o que faço entre meus roteadores, mas para meus concentradores VPN pareceu um pouco estranho.

Os usuários se conectariam diretamente ao 10.10.20.2 (endereço IP público do VPN), mas o tráfego de retorno seria roteado para o endereço IP privado /30 do concentrador. Não tenho certeza de como o concentrador VPN lidaria com isso.

Mas talvez eu esteja me preocupando demais.

Obrigado a todos pela ajuda.

Se quiserem anunciar os pools de endereços VPN usando OSPF, podem conferir este outro post em que há a solução: https://www.reddit.com/r/Cisco/comments/1438v56/ospf_advertise_remote_vpn_address_pools_on_a/

Onde está configurado o OSPF no seu concentrador? Procure por route redistribution, network statements e prefix origination para a marca e modelo do seu concentrador. Tenho certeza de que está em algum lugar na hierarquia do OSPF.

~20 endereços IP secundários

… Nos informe como foi.

>A interface VLAN1 tem cerca de 20 endereços IP secundários

Alguém fez uma bagunça.

Configure um vizinho OSPF estático para ser preciso.

Para ser justo, fiz uma generalização que não era específica para concentradores VPN. Não trabalho muito com VPNs nesse escala, então pode valer a pena verificar mais a fundo.

Como o que?

A rede principal tem funcionado perfeitamente por anos. Isso foi configurado há muitos anos (não estava nesta empresa na época) e nunca tivemos problemas.

Temos muitos usuários/departamentos, então usamos muitas sub-redes privadas/públicas. Por isso decidiram usar endereços IP secundários em vez de criar muitas VLANs com políticas de segurança semelhantes.

Não é a melhor maneira, mas certamente é uma solução funcional e estável.

Bem, acho que foi configurado assim há muito tempo, quando tinha 2-3 endereços IP secundários no máximo. Mas, à medida que o uso de TI se tornou mais popular, tiveram que adicionar novas sub-redes uma a uma, o que nos levou ao que temos agora.

Mas não se preocupem, também usamos muitas VLANs :wink:

Como o que?

Como está sua situação de sessão OSPF alvo. Nos informe sua solução. Você tem uma implantação desconhecida.

Não há necessidade de ficar na defensiva. Certamente você reconhece que colocar todas as sub-redes na mesma VLAN não é uma prática recomendada. Tampouco é recomendado misturar espaço de endereçamento público e privado na mesma VLAN. Isso tornará qualquer tentativa de microsegmentação um pesadelo um dia. Usar VLAN1 não é a melhor prática. Provavelmente funcionou por anos, com requisitos mínimos além do simples funcionamento. Se de repente você tivesse requisitos para adicionar uma faixa para DHCP e precisasse de um ajudante, encontraria problemas, e, como você está vendo agora, adicionar roteamento dinâmico apresenta problemas. Existe uma razão pela qual as melhores práticas da indústria são consideradas melhores práticas.

Com certeza farei isso

Desculpe, mas os três pontinhos soaram um pouco duramente considerando que não tenho relação com a configuração atual da rede principal.

Obrigado pelo feedback e deixe-me dar alguns elementos para entender melhor nossa situação.

Primeiramente, não temos todas as sub-redes na mesma VLAN. São apenas sub-redes dos “USUÁRIOS”, mas além disso temos VLANs para IoT, WiFi, departamentos específicos, VoIP, gerenciamento, etc.

Não tenho certeza de qual seria o problema com DHCP. Usamos endereço helper e muitas vezes adicionamos novas faixas de DHCP sem dificuldades.

Mas concordo 100% com você que poderia e provavelmente deveria ser configurado de maneira diferente para parte dela. Infelizmente, como dito na minha mensagem anterior, a configuração foi feita há muito tempo, quando eu não estava presente. Mas estamos no processo de trocar alguns dispositivos da rede principal, então será uma boa oportunidade.

Endereço IP público do concentrador VPN está na sub-rede de um IP secundário

E

São apenas sub-redes “USUÁRIOS”

Essas duas afirmações não são congruentes. Novamente, não é necessário ficar na defensiva. Todos nós herdamos coisas assim e piores. Todos nós vimos por que não fazer essas coisas. Ninguém está zombando de você. Estamos analisando o design e dizendo … hrmm.