Como fornecer failover para diversidade de espaço T1

Eu herdei uma rede pequena, insular e dedicada, que é essencialmente livre de problemas, então, naturalmente, eu quero melhorá-la :-) Eu reduzi meu conhecimento de rede e experimentei para algo entre 2 e 3 em uma escala de 1 a 10 depois de ler postagens de rede aqui. Eu incluí apenas os roteadores pertinentes no meu diagrama para maior clareza.

Atualmente, há uma mistura de aproximadamente 6-8 Cisco 2800 e 2900 em cada campus com placas de voz para um aplicativo caseiro dedicado, usando rotas estáticas para obter pacotes entre os dois campi. Eles estão executando c2801-spservicesk9-mz.124-3g no R1 e R2 e c2800nm-adventerprisek9-mz.124-15.t3 no R3 e R4.

Essa é uma rede fixa e imutável que serve apenas esse aplicativo dedicado. Não há desktops nem laptops indo e vindo, apenas os roteadores Cisco conectados por meio de muxes de fibra de terceiros em uma topologia em anel em cada campus com algumas máquinas de servidor conectadas (parte dos "outros nós").

Em algum momento ao longo do caminho, o cliente decidiu que seria uma ótima idéia instalar um segundo T1 entre R2 e R3 para redundância. Com base nos meus testes, o roteamento estático não tem como empregar o segundo T1. Mesmo com o AD / métrico em uma rota secundária para o novo T1, apenas o roteador cujo T1 falhou sabe disso, mas os outros roteadores nesse campus não.

Eu estava pensando em usar objetos de rastreamento de IP depois de ler essas soluções aqui para manter as coisas simples e minimizar o transtorno para a rede. Então eu li onde EIGRP é a maneira preferida de lidar com isso.

Mas se o roteamento dinâmico é o caminho a seguir, ele deve ser implementado de uma maneira que não interrompa o serviço. Tudo isso é remoto para mim e exigiria que eu providenciasse um técnico local para o caso de eu perder a conectividade durante a reconfiguração. Felizmente, com uma rede tão pequena e imutável, essa interrupção pode ser minimizada.

Então, eu deveria estar pesquisando como empregar objetos de rastreamento de IP ou EIGRP para realizar esse roteamento de failover T1?

EDIT: Aqui estão as rotas atualmente configuradas para o R4. Estou bastante confiante de que há algum problema aqui, mas tentei exatamente uma vez simplificá-lo e recuei quando cometi um pequeno erro e perdi a conectividade com o Campus B. As interrupções são um grande não-não. Decidi deixar bem o suficiente até pensar em uma abordagem melhor.

ip route 10.0.0.0 255.0.0.0 10.1.1.8
ip route 10.1.1.8 255.255.255.252 Serial0/3/0
ip route 192.168.30.0 255.255.255.0 Serial0/3/0
ip route 192.168.6.0 255.255.255.0 Serial0/3/0
ip route 192.168.8.0 255.255.255.0 FastEthernet0/0
ip route 10.0.2.128 255.255.255.192 192.168.31.2
ip route 10.2.160.0 255.255.255.0 192.168.31.2
ip route 192.168.254.0 255.255.255.0 192.168.31.2
ip route 192.168.6.0 255.255.255.0 192.168.8.11 110 name fallback
ip route 0.0.0.0 0.0.0.0 10.1.1.9
ip route 0.0.0.0 0.0.0.0 192.168.8.11 110 name fallback

A configuração da rota para o R3 é simples:

ip route 0.0.0.0 0.0.0.0 192.168.8.15
ip route 0.0.0.0 0.0.0.0 10.1.1.5 110

Obrigado.

Essa é uma rede fixa e imutável que serve apenas esse aplicativo dedicado.

Eu acho que você está descobrindo que isso raramente é a norma com redes, mesmo com redes imutáveis; portanto, por que você está aqui perguntando como automatizar isso. Eventualmente, outro link fica online e exige que você reengine todos os seus esforços anteriores. Esse é, por definição, qual é o objetivo de um protocolo de roteamento. É para garantir que você não precise usar rotas estáticas em todos os lugares!

Com base nos meus testes, o roteamento estático não tem como empregar o segundo T1.

Você pode configurar um tipo de SLA IP que possa manter o sistema funcionando como está e, ao mesmo tempo, permitir o failover no caso de falha do sistema Old T1.

Um exemplo desse tipo de configuração para o R4 seria algo parecido com isto.

R4(config)# ip sla 1
R4(config)# icmp-echo 10.1.1.9 source-interface Serial0/3/0
R4(config)# timeout 1000
R4(config)# threshold 2
R4(config)# frequency 3
R4(config)# ip sla schedule 1 life forever start-time now
R4(config)# track 1 ip sla 1 reachability
R4(config)# ip route 0.0.0.0 0.0.0.0 10.1.1.9 track 1
R4(config)# ip route 0.0.0.0 0.0.0.0 192.168.8.11 100

_{versão modificada da configuração de amostra firewall.cx .}

Mas, como você está descobrindo rapidamente, é a maneira menos do que ideal de fazer isso. Automatizar isso com o EIGRP é provavelmente a melhor opção, pois você possui todo o hardware da Cisco.

Mas se o roteamento dinâmico é o caminho a seguir, ele deve ser implementado de uma maneira que não interrompa o serviço.

Se você configurar o EIGRP em conjunto com suas rotas estáticas. Os relacionamentos com vizinhos do EIGRP serão construídos e suas tabelas de roteamento serão preenchidas com rotas para os diferentes locais. Nenhuma interrupção realmente deve ocorrer, porque seus roteadores terão uma tabela de roteamento totalmente preenchida com conhecimento de como acessar as outras sub-redes.

Lembre-se de que, quando tudo estiver configurado e funcionando sem problemas com o EIGRP e o roteamento estático, você ainda usará suas rotas estáticas até removê-las. Feito corretamente, você nem deve notar um pontinho no fluxo de tráfego.

Compare suas configurações anteriores com um exemplo de configuração EIGRP para R4.

R4(config)#router eigrp 1
R4(config-router)#no auto-summary
R4(config-router)#network 10.1.1.8
R4(config-router)#network 192.168.8.0

Geralmente é que simples para uma rede tão pequena.