Ho sentito il termine "route server" e "specchio" gettati qui intorno. Cosa sono e perché dovrei preoccuparmene?
Ho sentito il termine "route server" e "specchio" gettati qui intorno. Cosa sono e perché dovrei preoccuparmene?
Risposte:
(Nota che questi due termini sono spesso usati in modo intercambiabile, il che può creare confusione.)
Uno specchio è di solito un sito Web (spesso CGI) che si interfaccia con i router di proprietà e gestiti da un singolo ISP o altro operatore di rete. Il più delle volte sono accessibili al pubblico, ma potrebbero esserci casi in cui non lo sono. Lo specchio fornisce una vista (sotto forma di sito Web) in una tabella BGP di un router particolare nella rete di un operatore. Spesso, le implementazioni dello specchio includeranno anche altre utilità, come la capacità di eseguire un traceroute verso una destinazione come se fosse eseguito dal router dell'operatore di rete stesso. Gli occhiali da vista sono utili perché forniscono una prospettiva nella tabella BGP a monte. Level3, un noto vettore di primo livello negli Stati Uniti ha uno specchio disponibile qui. Questi sono strumenti di risoluzione dei problemi ampiamente utilizzati.
Il termine "route server" si è evoluto per significare due cose diverse, che verranno spiegate entrambe. Qui sto definendo due "sottotipi" di route server che dovrebbero rendere più chiara la distinzione. Queste definizioni sono mie e sono usate solo per cercare di dissipare ogni possibile confusione. In realtà, il server di route pubblico viene anche comunemente indicato come "route collector" o "route-views server" (quest'ultimo proveniente dal progetto di visualizzazioni della route dell'Università dell'Oregon ).
Si tratta di sistemi (di solito router, ma ne esistono alcuni che eseguono demoni di routing open source) accessibili al pubblico, spesso tramite Telnet, ed è anche possibile eseguire ping, traceroute e "show ip bgp" (ci sono anche un paio di Juniper instrada i server là fuori, non preoccuparti!) comandi. La differenza tra un server di route pubblico e uno specchio (a parte una LG con un CGI elegante) è che un'ampia varietà di reti (inclusi alcuni carrier di livello uno) esegue il peer con un server di route, quindi c'è un quadro "complessivo" di quali prefissi provengono da quali ASN. La politica di autorizzazione dei comandi varia da server di route a route server. Ecco un elenco di server di route IPv4 . Hanno anche una pagina separata con i server di instradamento IPv6.route server , si può pensare allo specchio come a un frontend per un route server, indipendentemente dal fatto che il route server stesso sia accessibile pubblicamente o privatamente.
Non riesci a far funzionare uno specchio su un server di route pubblico?
Puoi, ma in genere le persone che gestiscono gli occhiali da vista sono quelle che possono permettersi di operare e mantenere i server su cui girano gli occhiali. Con un server di route pubblico, tutto ciò di cui hai bisogno è un router (o un server che esegue un demone di routing open source), una buona politica AAA e alcune persone che sono disposte a darti feed BGP. È anche importante notare che alcuni operatori di rete ospitano anche server di route accessibili al pubblico e potresti persino imbatterti in alcuni operatori che eseguono un route server oltre a uno specchio.
Questa versione del route server è leggermente diversa. Sui tessuti di peering condivisi presso IXP, la barriera d'ingresso per un'organizzazione per iniziare il peering è inferiore. Hai una sola porta (che IXP ti vende) connessa alla LAN peering IXP e ti viene assegnato un indirizzo IP da IXP. Ora puoi scrutare con chiunque altro sul tessuto; contrastare questo con un PNI, che implica una connessione fisica dedicata separata tra te e un'altra entità. Con una connessione alla LAN di peering di un IXP, a parte il fatto che la tua singola porta è il collo di bottiglia, devi configurare manualmente le sessioni eBGP con chiunque desideri scrutare. Questo si chiama interconnessione bilaterale- c'è una sessione tra te e il peer, e solo tu e gli annunci di scambio tra pari. Se l'IXP ha molti membri, questo può diventare ingombrante. In questo caso, un server di instradamento viene in genere distribuito presso l'IXP per essere lo "sportello unico" per un'organizzazione con cui impostare una sessione eBGP al fine di ricevere prefissi da chiunque sia stato analizzato con il server di instradamento. Questo si chiama interconnessione multilaterale . Una sessione BGP tra te e il server di instradamento e ricevi gli annunci di tutti gli altri che si confrontano anche con il server di instradamento.
Alcune organizzazioni faranno affidamento sulle sessioni eBGP del server di instradamento, mentre altre lo utilizzeranno come backup dei peerings eBGP esistenti sul fabric IXP. La maggior parte degli IXP disporrà di route server ridondanti e suggerisce che le organizzazioni eseguano il peering con entrambi se eseguono il peering con i server di route.
Il peering multilaterale tramite route server presenta sfide interessanti per quanto riguarda BGP. Un server di route stesso è un oratore eBGP, tuttavia devono esserci considerazioni specifiche per un server di route e un peering BGP multilaterale. Alcune di queste regole rimandano alla riflessione sulla rotta iBGP, e in effetti ci sono molte somiglianze. Ci sono stati lavori recenti per standardizzare i comportamenti di un server di route quando si tratta di queste caratteristiche specifiche. Vale la pena notare i seguenti avvertimenti:
È importante ricordare due distinzioni per quanto riguarda l'implementazione del server di route IXP:
In genere, gli operatori IXP distribuiranno demoni di routing open source come route server. Esistono tre opzioni popolari:
Quagga, in particolare bgpd . Funziona su Linux e BSD. È stato il più lungo e probabilmente ha la maggior parte delle informazioni disponibili. Nel corso degli anni ci sono state diverse forcelle di Quagga, tra cui un treno con sviluppo sponsorizzato da EuroIX , un treno sviluppato dal gruppo di routing open source (che più mira a migliorare la funzionalità IGP con OSPF e ISIS) e Quagga-RE (Release Ingegneria) treno che ha caratteristiche sperimentali. Google ha anche creato il proprio fork di Quagga. Quagga bgpd supporta sia IPv6 che IPv4, tuttavia la maggior parte degli operatori IXP (e persino alcuni manutentori di Quagga) sconsigliano di utilizzare il treno Quagga "mainline" per far funzionare un server di rotta in un IXP.
UCCELLO . Funziona su Linux e BSD. BIRD ha guadagnato un po 'di popolarità grazie alla sua stabilità e al suo potente linguaggio e capacità di filtraggio, oltre al suo ottimo sistema di programmazione. Ci sono stati un paio di confronti pubblicati e test di scala tra Quagga e BIRD. Nel complesso, BIRD tende a essere più stabile e non è suscettibile alla CPU e alla memoria come Quagga. Sia BIRD che Quagga sono comunque single thread, ma questo è intenzionale. Inoltre, sebbene BIRD supporti sia IPv4 che IPv6, richiede due diversi processi (binari compilati) per IPv4 e IPv6.
OpenBGPD . Solo BSD . OpenBGPD è l'unico demone BGP open source multi-thread disponibile. È noto per essere abbastanza stabile sotto carico, tuttavia il supporto TCP MD5 è piuttosto scarso.
Oltre ai demoni open source, Cisco offre anche un'implementazione di route server per IOS-XE , che funziona sulla piattaforma ASR. Al momento della stesura di questo documento, Juniper non offre un'implementazione di route server sul proprio hardware o sistema operativo, ma ciò potrebbe cambiare in futuro.
In termini di valutazione di un demone di routing open source, per quanto riguarda la gestione della memoria e l'architettura, si può tranquillamente supporre che BIRD> OpenBGPD> Quagga, tuttavia, secondo quanto riferito, anche la piattaforma ASR e IOS-XE sono molto più scalabili rispetto all'open opzioni del demone sorgente disponibili.
Spero che questo faccia luce sui server di instradamento / sugli occhiali in generale.