In che modo anycast garantisce la consegna affidabile di pacchetti IP per lo stesso indirizzo IP in luoghi diversi?

1

Con anycast, sarebbe possibile avere lo stesso indirizzo IP in più località del mondo, senza la necessità di un proxy o VPN che inoltra i pacchetti alla sua destinazione finale.

Se si usasse lo spoofing IP per cambiare l'indirizzo IP sorgente ad esempio 6.7.8.9, normalmente non si sarebbe in grado di ricevere solo i pacchetti di risposta per questo indirizzo IP, poiché il protocollo Gateway Border determina un percorso differente per il pacchetto di risposta che normalmente non sarà in grado di intercettare.

Che cosa fa anycast in modo da poter ricevere in modo affidabile pacchetti IP destinati a questo particolare indirizzo IP? Poiché i percorsi più brevi su cui si basa BGP possono cambiare, quale meccanismo garantisce che quando si invia una richiesta nella posizione C che ha l'indirizzo IP 6.7.8.9, si riceverà l'intera risposta alla posizione C e non si riceverà una risposta anche con alcuni pacchetti consegnati nella posizione A che ha l'indirizzo IP 6.7.8.9 e altri pacchetti consegnati nella posizione B che ha anche l'indirizzo IP 6.7.8.9?

Per DNS potrebbe non essere importante, ma Anycast viene anche utilizzato da CloudFlare per la rete di content delivery, che sarebbe HTTP (S) su TCP e non solo pacchetti UDP.

Come su questo scenario: i server A e B hanno lo stesso indirizzo IP con anycast. Il server B si connette a un server esterno molto vicino al server A e molto lontano dal server B, poiché il server A è più vicino, la risposta verrà reindirizzata al server A, non è sempre possibile instradare questo tipo di richieste torna al server B, dal momento che il server B ha avviato la connessione al server esterno?

    
posta Jomad 08.08.2016 - 01:37
fonte

1 risposta

1

È contro-intuitivo, ma vari provider hanno parlato delle loro esperienze nel corso degli anni e risalendo fino a 2 decenni hanno dimostrato che Anycast era almeno altrettanto stabile e spesso più stabile anche per il traffico TCP / HTTP di Unicast.

Perché è questo-

In prima approssimazione Internet è suddiviso tra provider di connettività backbone Tier x, endpoint aziendali e ISP che servono l'ultimo miglio. Queste parti scambiano traffico attraverso accordi di peering o accordi di transito. Gli accordi di peering sono meno costosi e hanno senso quando c'è un flusso significativo di traffico in entrambe le direzioni. Gli accordi di transito sono più costosi e esistono dove c'è uno squilibrio nel flusso di traffico.

Un'assistenza molto significativa va nella pianificazione dei punti di presenza per gli endpoint aziendali da cui verranno fatti gli annunci Anycast e quindi negli accordi di peering e transito con cui il traffico degli utenti che passa dagli ISP raggiungerà tali endpoint in modo meno costoso , dove il costo è misurato sia finanziariamente che topologicamente.

Cioè, questi accordi sono idealmente strutturati in modo tale che ci sarà un percorso globale di costo minimo preferito per ogni singolo cliente a un POP specifico, con un ripiego più costoso (in termini topologici e finanziari) di rotte globali verso altri POP.

Quindi la magia non è necessariamente in Anycast e BGP ma in questi accordi di peering e transito. Questi consentono a Anycast e BGP di ottimizzare le decisioni del percorso locale per fornire stabilità topologica globale durante le vite di sessioni TCP rilevanti (di solito al massimo minuti).

Si parla di grandi attori globali come Google che giocano in backbone, endpoint e ISP che eseguono la loro replica di stato TCP magia proprietaria tra POP, ma non è il caso comune. Il caso comune è che gli architetti di rete costruiscono deliberatamente accordi che ottimizzano per la stabilità globale.

    
risposta data 08.08.2016 - 04:25
fonte

Leggi altre domande sui tag