Comportamento da área 0 do OSPF dividido - O que acontece?

Para tornar minha pergunta o mais simples possível, montei um cenário rápido:

1. A área 0 abrange dois data centers com vários roteadores / redes em cada um.

2. A área 0 possui dois ABRs conectados à área 1 que se conectam ao mesmo roteador na área 1. Uma área 0,1 ABR está em cada data center. Esses ABRs também são roteadores WAN, portanto são usados ​​para interconectar os datacenters também na área 0. A área 1 é uma área padrão.

3. A área 0 fica particionada (dividida) devido ao (s) link (s) WAN / MAN entre os data centers em queda.

Veja o diagrama:

Com base na leitura do OSPFv2 RFC e em muitas outras informações na Internet, assumo o seguinte:

A. Um backbone particionado atua como duas áreas separadas 0 e eles não sabem mais um do outro.

B. Cada área 0 é totalmente funcional para roteamento dentro da área dentro de sua própria partição.

C. A funcionalidade entre cada área 0 e a área 1 é totalmente funcional. A área 1 obtém resumos da área 0 de cada partição e os resumos da área de envio 1 do ABR em cada partição da área 0. As rotas externas de cada partição da área 0 também inundam a área 1, juntamente com os LSAs do tipo 4 para ASBRs.

D. Os roteadores na área 0 A não conseguem acessar as redes na área 0 B e vice-versa porque não há um link virtual através da área 1. Como não há um link virtual, nenhuma informação de roteamento da área 0 A será compartilhada com a área 0 B que um ABR aprende na área 1 (e vice-versa).

Estou correto ou estou entendendo mal alguma coisa? Minhas suposições são baseadas no comportamento do vetor distância / horizonte dividido entre as áreas. No desenho rápido que fiz, isso significa que R1 inundará os resumos da área 0 para a área 1, que R4 aprenderá na área 1, mas R4 assumirá que a área 0 à qual está diretamente conectada é a única área 0, por isso ganhou ' nem pense em enviar qualquer informação de roteamento desses resumos "de volta à área 0".

Obviamente, esse não é o comportamento desejado para um design funcional, mas se estou entendendo corretamente, é assim que quero que minha rede falhe se meus dois datacenters perderem a conectividade entre si. Eu herdei um domínio OSPF de área única e quero dividir todos os roteadores de sites da filial em uma área separada para que, se a área 0 for dividida, o tráfego entre os datacenters não atravessará os links da WAN do site da filial pelos roteadores conectados aos dois dados. centros.

Também faço redistribuição de OSPF para BGP e não quero um ASBR em um datacenter que redistribua rotas de redes no outro datacenter, se seu único caminho para elas exigir o trânsito de uma filial dual em um link lento.

Obrigado por qualquer insight.

Depois de analisar minuciosamente o RFC, tenho certeza de que o comportamento esperado que mencionei no meu post é preciso.

O roteamento dentro da área dentro de cada área (área 1, área 0 (a) e área 0 (b)) funcionará conforme o esperado.

Os resumos da área 0 ainda serão inundados na área 1 de cada partição da área 0, fornecendo à área 1 todas as informações de roteamento necessárias para ambas as partições da área 0.

Os resumos da área 1 ainda serão inundados pelas partições da área 0 da área 1, permitindo que as duas partições da área 0 saibam sobre as rotas da área 1.

A área 1 não enviará resumos da área 0 de volta à área 0, portanto, as partições da área 0 divididas não se conhecerão mais e não tentarão transitar pela área 1 para se conectarem (a menos que um link virtual através da área 1 seja criado).

Esse é o meu comportamento desejado para um cenário de falha com base nas minhas circunstâncias. Se todos os links redundantes entre meus datacenters ficarem inativos ou precisar executar certos tipos de manutenção, não quero que o tráfego do datacenter para o datacenter (principalmente backups / replicação externa) sature meus links WAN do site da filial. Eu poderia aplicar o policiamento nos links da WAN para o tráfego de trânsito entre os datacenters, mas o pouco de largura de banda que eu poderia fornecer para esse tráfego seria inútil - e isso exigiria que minha equipe mantivesse mais configurações.

Se alguém tiver alguma dúvida sobre isso, sinta-se à vontade para comentar e tentarei encontrar as respostas.

Eu acho que você está correto. O ponto principal é o ABR (R1 e R4), pois eles decidem a inundação entre as áreas e trocam informações sobre a área na área principal. No entanto, a ideia pode ser mais fácil de entender. No RFC2328:

3.1 A espinha dorsal do sistema autônomo

O backbone OSPF é a Área 0 OSPF especial (geralmente escrita como Área 0.0.0.0, pois os IDs de área OSPF são tipicamente formatados como endereços IP). O backbone OSPF sempre contém todos os roteadores de borda de área. O backbone é responsável por distribuir informações de roteamento entre áreas que não são do backbone. O backbone deve ser contíguo. No entanto, não precisa ser fisicamente contíguo; a conectividade de backbone pode ser estabelecida / mantida através da configuração de links virtuais.

3.7 Partições de áreas

No entanto, para manter o roteamento completo após a partição, um intervalo de endereços não deve ser dividido entre vários componentes da partição de área. Além disso, o backbone em si não deve particionar. Se isso acontecer, partes do sistema autônomo ficarão inacessíveis. As partições de backbone podem ser reparadas através da configuração de links virtuais (consulte a Seção 15).

Portanto, sabemos que um sistema autônomo OSPF pode ter apenas uma área de backbone. Com base no cenário que você apresentou, depois que a área do backbone é dividida, não é mais um sistema autônomo OSPF, mas dois sistemas autônomos OSPF [Área 0 (a), Área 1] e [Área 0 (b), Área 1]. Portanto, ambos os sistemas autônomos possuem informações de roteamento da Área 1, que é o comportamento que você deseja.

Em resumo, o ABR não passará LSAs do tipo 3 para nenhuma outra área, a menos que seja recebido sobre a área 0. Portanto, neste caso, R1 ou R4 estão recebendo os LSAs do tipo 3 da área de divisão 0 e não os repassam para area0s ou qualquer outra área. Esta é a prevenção de loop original do OSPF.

Obrigado, Madhu