Come fornire il failover per la diversità spaziale T1

Ho ereditato una rete piccola, insulare e dedicata che è essenzialmente priva di problemi, quindi naturalmente voglio migliorarla :-) Ho ridotto la mia conoscenza della rete e il buon senso da qualche parte intorno a 2 a 3 su una scala da 1 a 10 dopo aver letto post di networking qui. Per chiarezza, ho incluso i router pertinenti nel mio diagramma.

Attualmente c'è un mix di circa 6-8 Cisco 2800 e 2900 in ogni campus con schede vocali per un'applicazione dedicata fatta in casa, usando percorsi statici per ottenere pacchetti tra i 2 campus. Stanno eseguendo c2801-spservicesk9-mz.124-3g su R1 e R2 e c2800nm-adventerprisek9-mz.124-15.t3 su R3 e R4.

Questa è una rete fissa e invariata che serve solo questa applicazione dedicata. Nessun desktop o laptop che va e viene, solo i router Cisco collegati tramite mux in fibra di terze parti in una topologia ad anello in ogni campus con un paio di macchine server connesse (parte degli "altri nodi").

A un certo punto, il cliente ha deciso che sarebbe stata una buona idea installare un secondo T1 tra R2 e R3 per ridondanza. Sulla base dei miei test, l'instradamento statico non ha modo di utilizzare quel secondo T1. Anche con AD / metrica su una route secondaria verso il nuovo T1, solo il router il cui T1 ha fallito lo sa, ma gli altri router in quel campus non lo sanno.

Stavo pensando di utilizzare gli oggetti di tracciamento IP dopo aver letto queste soluzioni qui per mantenere le cose semplici e ridurre al minimo i problemi con la rete. Poi ho letto dove EIGRP è il modo preferito di gestirlo.

Ma se il routing dinamico è la strada da percorrere, deve essere implementato in modo da non interrompere il servizio. Questo è tutto remoto per me e mi richiederebbe di organizzare un tecnico locale in caso di perdita di connettività durante la riconfigurazione. Speriamo che con una rete così piccola e immutata questa interruzione possa essere minimizzata.

Quindi dovrei cercare come utilizzare oggetti di tracciamento ip o EIGRP per realizzare questo routing di failover T1?

EDIT: ecco i percorsi attualmente configurati per R4. Sono abbastanza fiducioso che ci sia un po 'di cruft qui, ma ho provato esattamente una volta a semplificarlo e ho fatto un passo indietro quando ho fatto un piccolo errore e ho perso la connettività con Campus B. Le interruzioni sono un grande no-no. Ho deciso di partire abbastanza bene da solo fino a quando non ho escogitato un approccio migliore.

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

La configurazione del percorso per R3 è semplice:

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

Grazie.

Questa è una rete fissa e invariata che serve solo questa applicazione dedicata.

Penso che stai scoprendo che questo è raramente la norma con le reti, anche con reti immutabili; quindi, perché sei qui chiedendo come automatizzare questo. Alla fine, viene online un altro link che richiede di riprogettare tutti i tuoi sforzi precedenti. Questo è, per definizione, qual è lo scopo di un protocollo di routing. È per assicurarsi di non dover usare percorsi statici ovunque!

Sulla base dei miei test, l'instradamento statico non ha modo di utilizzare quel secondo T1.

È possibile impostare una sorta di SLA IP in grado di mantenere il sistema in esecuzione così com'è, pur consentendo il failover in caso di Old T1interruzione.

Un esempio di questo tipo di configurazione per R4 potrebbe essere qualcosa del genere.

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

_{versione modificata della configurazione di esempio firewall.cx .}

Ma, come stai rapidamente scoprendo, è il modo meno che ideale per farlo. L'automazione con EIGRP è probabilmente la soluzione migliore in quanto hai tutto l'hardware Cisco.

Ma se il routing dinamico è la strada da percorrere, deve essere implementato in modo da non interrompere il servizio.

Se si configura EIGRP insieme ai percorsi statici. Verranno create relazioni di vicinato EIGRP e le tabelle di routing verranno popolate con percorsi verso le diverse posizioni. Non dovrebbe verificarsi alcuna interruzione perché i router disporranno di una tabella di routing completamente popolata con le conoscenze su come raggiungere le altre sottoreti.

Ricorda, una volta che tutto è configurato e funziona senza intoppi con EIGRP e routing statico, continuerai a utilizzare i tuoi percorsi statici fino a quando non li rimuovi. Fatto correttamente, non dovresti nemmeno notare un blip nel flusso del traffico.

Confronta le tue configurazioni precedenti con una configurazione EIGRP di esempio per 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

Di solito è così semplice per una rete così piccola.