Routing con collegamento WAN separato per i backup

10

Abbiamo due data center geograficamente separati. Ci stiamo preparando ad implementare una nuova connessione WAN (dark cloud) che verrebbe utilizzata solo per il traffico di backup. I server avranno due schede NIC (produzione e backup) ma qual è il modo migliore per garantire che il traffico di produzione e backup non si mescoli? Al momento stiamo solo usando percorsi statici per raggiungere la WAN, ma stiamo cercando di implementare BGP tra il nostro SP e noi stessi. Internal RP è un mix di EIGRP e OSPF. I core sono Cisco 6500 e i router WAN saranno presto aggiornati agli ASR.

Suggerimenti sulle soluzioni? Routing basato su criteri (PBR)? VRFs?

Diagramma di rete

cisco routing backups

— Peter
fonte

Senza conoscere ulteriori dettagli, non vedo come la miscelazione del traffico di backup attraverso il collegamento principale tra controller di dominio e viceversa sia un problema? Supponendo che la LAN del server principale e la relativa LAN del traffico di backup siano diverse sottoreti, possono essere pubblicizzate sui due collegamenti inter-DC con metriche di instradamento diverse. Non vedo come puoi mescolarli accidentalmente? Puoi usare VRF e VLAN, ma questo sembra troppo complesso quando puoi semplicemente cambiare la metrica del percorso. Mi sto perdendo qualcosa?

— jwbensley,

Al momento è un requisito aziendale che rimangano separati. Dobbiamo anche garantire che i backup non eseguano il failover o provino a bilanciare il carico sui collegamenti di produzione.

— Peter,

Ah OK, beh, non è ancora troppo difficile usare metriche di percorso diverse e pubblicizzare un solo percorso per ogni sottorete per prevenire lo scenario di failover indesiderato. I VRF ora ora diventano una soluzione semplice e diretta qui come menziona ioshint.

— jwbensley,

9

Supponendo che le due NIC sui server vengano utilizzate per separare il traffico di produzione e di backup, utilizzare i VRF. Questa è la migliore tecnica di separazione del traffico che esista. Per una maggiore scalabilità (non sei sicuro di averne bisogno in base al diagramma), lancia MPLS / VPN nel mix, funziona su Cat 6500 e ASR.

— ioshints
fonte

L'uso di due schede NIC richiede la creazione e la manutenzione di tabelle di routing sui server. A meno che qualcuno non conosca alcuni trucchi, io no?

— Peter,

Sì. Dovresti impostare percorsi nei server per puntare le sottoreti di backup dall'interfaccia di backup. Se questo è un compito troppo scoraggiante, potresti sempre fare alcune cose interessanti con le metriche. Supponendo che i server di backup si trovino sulla propria sottorete ... ma anche in questo caso la soluzione MPLS lo presuppone. Se non si trovano sulla propria sottorete e non si dispone di un / 32 per i server di backup, penso che il routing basato su criteri potrebbe essere l'unica opzione.

— bigmstone,

Dove c'è volontà, c'è un trucco;) Usa / 16s sui server e / 24s nei router. Proxy ARP eseguirà il routing per te;)

— ioshints

1

Per gli IGP, non puoi semplicemente utilizzare la regolare regolazione metrica? EIGRP: basta manipolare il ritardo e per OSPF il costo. Una volta che colpisce il core BGP, non puoi usare i farmaci BGP. Per la mia compagnia (intuizione finanziaria) so che è quello che facciamo. Abbiamo un feed A e un feed B. Un feed avrà metriche interne migliori di B. Una volta colpito il nostro core BGP, è praticamente quello che ho elencato sopra.

— Michael Moore
fonte

0

Un'altra opzione che potrebbe dare maggiore flessibilità è usare QoS e semplicemente PbR in base alle code, se lo si progetta correttamente si ottiene anche il failover automatico dal primario al backup, ma non viceversa.

In questo modo è possibile scegliere di condividere o non condividere qualsiasi collegamento o router con una modifica della politica.

— LapTop006
fonte