3 sub-redes, 2 áreas OSPF - isso funcionará?

Ocorrerão problemas se eu tiver uma topologia envolvendo 3 sub-redes e duas áreas OSPF em que uma sub-rede esteja na ÁREA 0 e as outras duas sub-redes estejam na ÁREA 1?

Por exemplo:

[area 1, subnet 1]---[ABR #1]---[area 0, subnet 2]---[ABR #2]---[area 1, subnet 3]

— O MÉDICO
fonte

três roteadores diferentes? Se assim for, por favor incluir detalhes para que a área das ligações entre os roteadores estão em OSPF ligações coloca em uma única área, e as áreas devem corresponder em ambos os lados do link.

— Mike Pennington

@ Mike Pennington - você também está procurando as declarações de rede OSPF nos ABRs? Estou falando de uma configuração sem links virtuais btw.

— O MÉDICO

Sim, existem 3 roteadores diferentes, como a seguir: [rede 1 da área 1, sub-rede 1] --- [roteador nº 1] --- [rede da área 0, sub-rede 2, dispositivo final 1] --- [roteador nº 2] --- [rede da área 0, sub-rede 2, dispositivo final # 2] --- [roteador # 3] --- [rede da área 1, sub-rede 3]

— THE DOCTOR

Respostas:

Em relação à questão de dividir a área 1 no backbone (área 0):

[área 1, sub-rede 1] --- [ABR # 1] --- [área 0, sub-rede 2] --- [ABR # 2] --- [área 1, sub-rede 3]

[área 1, sub-rede 1] --- [Roteador # 1] --- [área 0, sub-rede 2, dispositivo final # 1] --- [Roteador # 2] --- [área 0, sub-rede 2, dispositivo final # 2] --- [Roteador # 3] --- [área 1, sub-rede 3]

Resposta curta: não há problema com sua proposta ...

Resposta longa:

Até a resposta de Peter, que argumenta que reutilizar números de área é um design inadequado, não oferece prova de que este seja um design inadequado; se você examinar os hiperlinks que ele usou, não há explicação de consequências indesejáveis para esse design. Além disso, o argumento de que você pode ter problemas para conectar R1 e R3 fica aquém, pois o link R1 para R3 pode ser legitimamente configurado na Área 0 ou na Área 1, dependendo do tráfego que você deseja transportar. As dificuldades que ele menciona são um falso dilema.

No RFC 2328, a Seção 3.7 OSPF permite explicitamente o uso de áreas descontínuas que não sejam backbone (que são chamadas de "partições de área", abaixo):

    OSPF does not actively attempt to repair area partitions.  When
    an area becomes partitioned, each component simply becomes a
    separate area.  The backbone then performs routing between the
    new areas.  Some destinations reachable via intra-area routing
    before the partition will now require inter-area routing.
    ...  Also, the backbone itself must not partition.

Portanto, se você usa a Área 1 descontente proposta é apenas uma questão de gosto ... algumas pessoas acham ilógico usar a configuração em seu diagrama; essas pessoas podem sugerir que você mantenha os números da área OSPF juntos ... para que você precise alterar [área 1, sub-rede 3] no roteador # 3 para [área 3, sub-rede 3]. Outras pessoas não vêem problema em reutilizar a Área 1, já que os números de área OSPF são significativos apenas localmente para o roteador que originou o OSPF.

De qualquer maneira, devemos admitir que o OSPF é um protocolo notavelmente flexível; independentemente de escolher um lado ou outro neste debate.

— Mike Pennington
fonte

Para sua informação, este projeto (área descontínua 1) está em uso na produção em determinadas redes militares. Uma unidade implantada em um site remoto que se conectará novamente ao ABR do site de hub via DMVPN recebe um roteador com uma configuração padrão. No máximo, eles mudarão um ou dois endereços IP no roteador. É questionável se essa é a "melhor prática", mas funciona e é fácil para os não especialistas implantarem.

@ user2668 A política militar de alto nível não promove isso nas redes de produção. Embora organizações "especiais" (observe as orelhas de coelho) tendam a fazer o que querem, quando querem, essa certamente não é a norma. Posso dizer, com certeza, que existem filiais que promovem area 0projetos únicos de OSPF exclusivamente, para limitar a complexidade do projeto.

— Ryan Foley

Isso funcionará, mas seria uma má escolha de design (IMHO), a menos que você tenha um motivo específico para fazê-lo.

Consulte esta discussão: IDs de área duplicados do OSPF

Melhores práticas do OSPF

Atualização # 1 :

Por uma questão de completude, eu zombei dessa situação usando dyanmips. A plataforma era Cisco 3725s executando o IOS ver 12.4 (15) T13.

R1 (lo0 1.1.1.1, f0 / 0 10.12.0.1) <-> R2 (lo0 2.2.2.2, f0 / 0 10.12.0.2, f0 / 1 10.23.0.2) <-> R3 (lo0 3.3.3.3, f0 / 0 10.23.0.3).

As interfaces de loopback de R1 e R3 foram colocadas na área 1, todas as outras interfaces estão na área 0.

Os pings foram feitos (por exemplo, R3 # ping ip 1.1.1.1 source 3.3.3.3) entre as caixas R1 e R3, confirmando a conectividade.

Na minha opinião, eu ainda evitaria essa arquitetura. Mike faz pontos perfeitamente válidos (e o teste confirma) que isso funciona. As áreas OSPF são ferramentas úteis para controlar a propagação de rotas e reduzir o tamanho do banco de dados de estado do link do roteador - mas também funcionam (pelo menos para mim) para documentar que eu pretendo que "essa" parte da rede seja separada da arquitetura "daquele" parte da rede por algum motivo.

Se, no futuro, você decidir conectar R1 a R3 e estiver usando a mesma área #, você teve sorte e salvou muitos problemas com a alteração de números de área ou com o uso de links virtuais. Talvez esse seja um argumento a favor do uso de dois IDs de área (0 e 1) em qualquer lugar - mas, novamente, você não pretendia originalmente que R1 e R3 pudessem se comunicar diretamente. dar de ombros

É uma questão de estilo e preferência pessoal - parece não haver razão técnica para que isso não funcione e nunca pretendi representar de outra maneira.

Atualização # 2

Adicionando um diagrama de conexões não-ascii art - desenhado linearmente e como um triângulo. O que se pretende entre R1 e R3? Area1 deveria ser contígua ou separada?

insira a descrição da imagem aqui

— Peter
fonte

O raciocínio é reduzir a quantidade de tráfego OSPF que ocorre entre diferentes partes do AS. Examinei todos os seus links e não sei se perdi alguma coisa, mas por que é uma má escolha de design para o propósito que mencionei?

— O MÉDICO

@ Peter, além da resposta de Richard Burt , não consigo encontrar nada nos seus links que sugira que áreas descontínuas não relacionadas ao backbone sejam um problema ... e a resposta de Richard foi refutada pela resposta de Russ White à mesma pergunta . O link que você mencionou apontando para as melhores práticas de configuração da área OSPF não diz nada sobre uma área descontínua que eu poderia encontrar. Você poderia elaborar um pouco mais sobre a resposta?

— quer

@ Mike Pennnington - Não há nenhuma razão técnica para você não usar áreas OSPF descontínuas, mas existem muitas práticas. Manter seu ambiente e solucionar problemas, entre outros. Como os comentários no seu código, não é necessário, mas facilita muito a sua vida mais tarde.

— Peter

@ Peter, esse é exatamente o ponto, você não provou que é menos claro ... só porque você não gosta, não o torna um problema para o resto do mundo ... neste momento, estou começando a ouvir que você não tem nenhuma evidência para apoiar seu argumento

— Mike Pennington

Você faz áreas para limitar os domínios de broadcast; se você faz a área 1 e a área 1 prime, depende de uma separação física, pois as áreas 1s não podem viver no mesmo roteador ou o domínio de inundação dobra. Se você possui as áreas 1 e 2, pode ter um roteador com áreas e área 0 e dobrar o domínio do SPF. Você só tem mais flexibilidade de comprar sem usar o mesmo número. Talvez não megatons mais, mas ainda depening em seu specfic topologia você pode criar alguns problemas

— fredpbaker

Bem, você normalmente precisa usar links virtuais para conversar com a área 0 através de uma área diferente da não área 0 ou conectar 2 partes da área 0 através de uma área diferente de zero. Portanto, os links virtuais não se aplicam. Você pode ter uma área não contigiosa se não for a área 0, mas, como sugerido acima, não é realmente uma boa ideia. Dito isto, a topologia proposta funcionará sem links virtuais.

— fredpbaker
fonte