Como fornecer failover para diversidade de espaço T1


9

Rede de Failover 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.

Respostas:


7

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.


5
Boa resposta. Se ele usa o bfd, ele pode fazer o failover bem rápido, embora você precise ter certeza de que os seus T1s estão funcionando perfeitamente antes de ir para cá ... Os T1s gostam de coletar erros, o que pode provocar agitações se os temporizadores do bfd estiverem muito baixos
Mike Pennington

4
@MikePennington +1 para BFD. No entanto, eu sempre gosto de salientar (porque isso me incomodou pessoalmente) que a partir da era ISR G2, o BFD pode exigir uma atualização de licenciamento, dependendo da sua versão do IOS. Consulte este white paper da Cisco para obter mais informações.
Brett Lykins

A chave para mim é que você apontou que as rotas estáticas têm precedência sobre a dinâmica, então usarei isso para minha vantagem. Pesquisarei se essas caixas oferecerão suporte ao EIGRP e o implementarei, se houver. Obrigado!
Bote Man

11
A distância administrativa entra em jogo quando um roteador conhece a mesma rota no RIB e precisa decidir entre eles. Em seu ambiente isolado, você não precisará de um gateway padrão em nada além de seus servidores; seus roteadores terão conhecimento completo de como chegar a todo o resto. Na melhor das hipóteses: quando (não se) houver uma falha no link, você nem perceberá.
Ryan Foley

11
@BoteMan Não tenho muita certeza do que está do outro lado da linha DSL. Se for controlado pelo seu ISP, você ainda precisará de uma rota padrão no R1 para chegar ao exterior. Se você controlar o que estiver do outro lado da linha DSL, sim, cada roteador deverá ter conhecimento completo de todas as outras rotas e seus servidores poderão acessar a linha DSL.
Ryan Foley
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.