Le migliori pratiche per il sito con doppio homing con due ISP?

Sono abbonato a due ISP, uno veloce costoso e uno economico ma più lento. Usano diverse tecnologie, via cavo e ADSL, quindi non c'è molto di un singolo punto di errore e tutte le mie apparecchiature di comunicazione sono alimentate da un UPS.

Gli ISP nel Regno Unito scendono in modo abbastanza casuale. Per molti anni non ho ancora incontrato un momento in cui entrambi i miei ISP sono diminuiti contemporaneamente, quindi chiaramente la strategia a due ISP è utile se si desidera un accesso ininterrotto alla rete qui.

Il problema tuttavia è come organizzare la rete del tuo sito per sfruttare questa disponibilità migliorata. Molti ISP non ti consentono di eseguire i tuoi protocolli AS e di routing, quindi sei principalmente bloccato con la suddivisione del routing statico tra i due tubi di uscita per destinazione. Questo è tutt'altro che geniale e richiede un intervento manuale quando un ISP lascia cadere la faccia del pianeta. Con l'aiuto di numerosi script gestisco le interruzioni dell'ISP con ragionevole successo e non molto sforzo, ed è diventato business come al solito. Non è eccezionale però. Sembra che manchi qualche tecnologia.

1. C'è un modo migliore, in generale?
2. Esiste un modo migliore solo per IPv6 (ho uno stack doppio su un ISP e potrei effettuare il tunneling sull'altro)? Sarebbe un chiaro vantaggio per IPv6.

Che tipo di attrezzatura hai collegato ai fornitori? Se si tratta di un dispositivo Cisco, è possibile utilizzare SLA IP per eseguire il ping di una destinazione come 8.8.8.8 sull'ISP primario. Non appena si ottiene un failover di risposta sull'altra route statica. Esempio di configurazione:

! ISP1
ip route 0.0.0.0 0.0.0.0 x.x.x.x track 1
! ISP2
ip route 0.0.0.0 0.0.0.0 y.y.y.y 250
ip sla 1
icmp-echo 8.8.8.8 source-interface <ISP1_interface>
frequency 3
timeout 1000
ip sla schedule 1 life forever start-time now

Potrebbe essere necessario inserire una route statica per 8.8.8.8 su ISP1 per uscire sempre da quel percorso. Ovviamente se usi davvero 8.8.8.8 scegli un altro IP perché altrimenti non avrai raggiungibilità se ISP1 scende.

!x.x.x.x is next-hop to ISP1
ip route 8.8.8.8 255.255.255.255 x.x.x.x

Potresti voler indagare se è disponibile un provider LISP . LISP è un protocollo che può rendere un sito indipendente dagli ISP upstream a cui si connette. Ottieni uno o più indirizzi IP dall'ISP LISP e li instradano ovunque tu sia connesso. È una tecnica di tunneling, ma con molte funzioni interessanti. Puoi controllare il bilanciamento del carico sia in entrata che in uscita sui collegamenti, puoi eseguire il multihoming IPv6 senza dover ricorrere a hack come NPT66 (traduzione prefisso). Potresti persino spostarti dall'altra parte del pianeta senza cambiare gli indirizzi IP ;-)

Uso LISP da solo e la mia rete dell'ufficio ha un blocco di / 26 IPv4 e un / 48 blocco di indirizzi IPv6 indipendenti dagli upstream (una connessione via cavo UPC con un indirizzo IPv4 dinamico e una connessione DSL Solcon con un indirizzo IPv4 statico e un blocco statico di indirizzi IPv6). Un Cisco 1841 esegue LISP in ufficio e utilizza qualsiasi collegamento disponibile per connettersi al resto di Internet. Finché funziona un collegamento, il mio ufficio è collegato usando i suoi indirizzi.

Informativa completa : gestisco il mio ISP basato su LISP nei Paesi Bassi, quindi sono di parte. LISP è comunque un protocollo interessante :-)

Nel multi-homing IPv6 con indirizzi aggregati del provider, ogni host nella rete otterrà un prefisso di indirizzo da ciascuno dei provider. La selezione dell'indirizzo di origine dello stack host / dell'applicazione (RFC6724) e la scelta della coppia SA / DA (RFC6555) determina quale uscita viene utilizzata.

Vale a dire la scelta dell'host / dell'applicazione dell'indirizzo di origine seleziona quale link di uscita viene utilizzato. Varie implementazioni lo fanno in vari modi, e nessuno lo fa molto bene al momento.

La rete utilizza il routing dipendente dall'indirizzo di origine per inoltrare il traffico all'uscita corretta. (Altrimenti BCP38 (filtro di ingresso) avrebbe lasciato cadere un pacchetto inviato con l'indirizzo sorgente dell'ISP B all'ISP A). Vedi http://tools.ietf.org/html/draft-troan-homenet-sadr-01 Abbiamo un'implementazione in OpenWRT. Ma può anche essere implementato abbastanza bene su qualsiasi router che supporti il ​​routing basato su criteri.

Un'applicazione dovrebbe essere abbastanza intelligente da modificare la connessione (scegliere un'altra coppia SA / DA) quando la connessione corrente non riesce. Non lo è. Nel frattempo, la nostra raccomandazione è di impostare la durata del prefisso dell'indirizzo del collegamento in errore su 0, il che significa che le nuove connessioni non useranno quell'indirizzo.

Q1. È possibile installare un router / firewall che supporti il ​​multihoming. In termini di software libero, pfSense è perfetto. http://www.pfsense.org/ . I documenti pfSense si riferiscono a questo come Multi-WAN. http://doc.pfsense.org/index.php/Multi-WAN_2.0

Utilmente, pfSense ha il failover automatico e il bilanciamento del carico.

Quello che ho scoperto è che un piccolo numero di app Web non funziona quando sei multihomed. Le app Web sono generalmente siti finanziari, come le banche. Per qualche motivo, i programmatori di app Web a volte pensano che sia OK testare la sicurezza sulla base dell'indirizzo IP. Per gli utenti che necessitano di questo accesso, è possibile prenotare un indirizzo IP per il proprio computer e creare una "regola LAN" in pfSense per utilizzare sempre un determinato gateway e non l'altro per quell'indirizzo IP.

Trovo che questo funzioni abbastanza bene per la combinazione di modem via cavo e modem ADSL.

Q2. Non vi è alcun motivo per cui il multihoming non funzioni in IPv6 e IPv4. Detto questo, pfSense non ha una versione completamente supportata che gestisce correttamente IPv6. La versione attuale di pfSense è 2.0x. Una volta rilasciato 2.1, pfSense avrà un buon supporto IPv6 e includerà il multihoming.

È possibile configurare un server remoto / VPS in un data center affidabile e quindi impostare tunnel VPN dal router al server remoto su ciascun ISP. Ora il tuo router di casa potrebbe instradare i pacchetti su questi tunnel in base a un rapporto di larghezza di banda e quindi il server remoto può instradare il traffico tra il resto di Internet.

Lo svantaggio è che ti verranno addebitati costi aggiuntivi di CPU, archiviazione e larghezza di banda per il server remoto.

Il vantaggio è che è possibile utilizzare l'intera larghezza di banda fornita da entrambi i provider pur avendo un'opzione di failover per l'affidabilità.

Ho usato OpenWRT con Multiwan ( http://wiki.openwrt.org/doc/uci/multiwan ) per qualche tempo a casa per multihome tra il mio DSL e ISP via cavo. Ha funzionato abbastanza bene. Non lo consiglierei come soluzione aziendale, ma va bene per SOHO e configurazioni domestiche.