Instradamento asimmetrico: cause ed effetti?

Mi capita di imbattermi in clienti che hanno ciò che definisco "routing asimmetrico" nelle loro reti. Detto semplicemente, hanno due gateway sulla stessa sottorete IP. I client sono configurati per puntare a un gateway (ovvero 172.16.1.1) ma esiste un altro dispositivo (ovvero 172.16.1.2) che si collega e si dirige verso un punto. Principalmente ho visto questo tipo di configurazione quando ci sono 2 diversi tipi di connessioni WAN: 1 connessione Internet e 1 connessione MPLS aziendale.

Personalmente non sono attratto dal suddetto tipo di progettazione della rete: ogni sottorete deve avere un solo gateway. Dal mio punto di vista, lo scenario sopra riportato può creare alcuni problemi per i client, poiché inviano un pacchetto al gateway predefinito (172.16.1.1) e tali pacchetti vengono quindi inoltrati all'altro router (172.16.1.2) e quando ricevono risposta a, raggiungono il cliente semplicemente passando attraverso 172.16.1.2. I clienti dovrebbero o dovrebbero aspettarsi che i pacchetti di risposta provengano dal 172.16.1.1, o sbaglio qui?

Sarei felice di avere le tue opinioni e opinioni tecniche su questo problema.

Consiglierei di esaminare i protocolli di ridondanza del primo hop come HSRP o VRRP.

In realtà, avere due gateway può essere un ottimo progetto di rete, perché se un router dovesse guastarsi, l'altro router potrebbe subentrare in modo piuttosto fluido. Tuttavia, come sapete, non è facile effettuare questa transizione se è necessario effettuare una riconfigurazione manuale di ciascun client su una sottorete.

Protocolli come HSRP (o VRRP se si dispone di dispositivi non Cisco) consentono di avere due (o più) router (o switch L3) su una sottorete che condividono un singolo indirizzo IP. Avrai il tuo primo router con un indirizzo di .2, il secondo con un indirizzo di .3 e un "indirizzo IP virtuale" di .1 di cui entrambi i router sono a conoscenza attraverso la configurazione. Quando il router primario si guasta, il secondario è in grado di rilevare questo e assumere l'indirizzo IP virtuale, il che significa che i tuoi client devono solo avere .1 configurato come gateway e sei pronto per partire.

In termini di progettazione del routing, ciò dipenderebbe in gran parte dalla configurazione corrente. È possibile che entrambi i gateway conducano allo stesso limite di Internet, nel qual caso potresti non avere problemi. Il routing asimmetrico può essere negativo, principalmente perché si rischia che i pacchetti vengano consegnati nell'ordine sbagliato, ma di nuovo dipende molto dalla topologia di cui si sta parlando.

Molti principi di progettazione implicano ciò che ho appena detto. Ti suggerisco di ricercare entrambi i protocolli e di determinare ciò che è meglio per il tuo ambiente. Se stai utilizzando Cisco Gear, HSRP è un metodo ampiamente utilizzato e ben compreso per risolvere questo problema.

L'intera Internet è basata sul routing asimmetrico, quindi è molto comune. I clienti sono interessati all'interfaccia su cui ricevono il pacchetto e alla fonte del pacchetto, non a quale router glielo ha passato su quell'interfaccia.

Il routing asimmetrico può tuttavia diventare problematico quando sono coinvolti dispositivi che tengono traccia dello stato (in particolare i firewall) e NAT, ma per quanto ne so non è il caso nel tuo esempio.

I client di rete identificano i flussi di traffico in base alla combinazione di 4 valori:

• Indirizzo di partenza
• Porta di origine
• Indirizzo di destinazione
• Porto di destinazione

Per ogni diversa connessione i 4 valori sopra formano una combinazione diversa che viene utilizzata per abbinare i pacchetti di risposta al flusso corretto. Come puoi vedere, il gateway o l'indirizzo dell'hop successivo non sono inclusi nell'elenco e quindi al client non importa se un pacchetto ritorna attraverso lo stesso gateway utilizzato per inviare i suoi pacchetti. Pertanto, i client di rete non si preoccupano del routing assimmetrico non appena possono ricevere il traffico dall'estremità remota. In realtà, TCP / IP è stato progettato originariamente per supportare il routing assimmetrico.

Tuttavia, se ci concentriamo su dispositivi intermedi di rete, il routing assimmetrico non è tollerato non appena si utilizza qualsiasi dispositivo / tecnologia che necessita di vedere tutti i pacchetti in una connessione per fornire una determinata funzionalità. Ad esempio: NAT, firewall con stato o alcuni ottimizzatori WAN. Il routing assimmetrico in tale scenario causerebbe la mancata fornitura della funzionalità prevista o, peggio ancora, la caduta dei pacchetti rendendo impossibile la comunicazione.

Sono d'accordo con le risposte prima di me, ma devo aggiungere qualcosa: se ci sono filtri su uno dei gateway o su qualsiasi hop che passa attraverso solo 1 dei 2 gateway, è probabile che sorgano problemi! (gli hop che vengono passati attraverso entrambi i gateway, ad esempio la macchina di origine, la macchina di destinazione e tutti gli hop "comuni a entrambi i percorsi gateway", non riguardano i seguenti scenari)

Ad esempio, se A invia pacchetti a B tramite gateway1 e i pacchetti restituiscono tramite gateway2, è molto probabile che il pacchetto di risposta venga eliminato se gateway2 sta eseguendo il filtro (poiché quel gateway non ha visto il pacchetto di connessione iniziale, quindi non ' t expecta reply, quindi se il dest / port del pacchetto di risposta è generalmente filtrato, sarà filtrato.)

(Esistono, ovviamente, molti scenari simili)

Altre due aree in cui i percorsi asimmetrici possono causare problemi sono: 1. Rilevamento MTU: se l'MTU più piccolo dei due percorsi differisce, il rilevamento del percorso MTU dell'endpoint potrebbe comportare una delle due MTU più grandi, che a sua volta comporterà la caduta di pacchetti di dimensioni massime. Ad esempio, se un percorso passa attraverso un tunnel VPN e l'altro no, il tunnel VPN avrà un MTU più piccolo. il ping funzionerà benissimo, ma il trasferimento di file di grandi dimensioni avrà esito negativo in modo coerente. 2. La risoluzione dei problemi di connettività sarà più difficile se uno dei due percorsi è interrotto ma l'altro no. Il buon vecchio "traceroute" non sarà affatto di aiuto, in quanto non sarà in grado di rilevare i punti intermedi del percorso inverso, a meno che non sia esercitato da entrambi i lati della connessione, che richiede un canale di gestione fuori banda ...