Perché un router hardware funziona meglio di un router Linux con specifiche migliori (RAM e CPU)?

44

Ho un CentOS 6.3 minimo, a 64 bit che funge da gateway con 4 NIC (1 Gbps), ognuna collegata insieme per il traffico pubblico e l'altra per il privato, che esegue NATing. Ha 6 GB di RAM e 4 core logici. Lo usiamo da due anni senza problemi.

Non ho alcuna esperienza con i router hardware, ma ho sentito che hanno meno RAM e CPU e usano dischi flash. Come può un box con una configurazione hardware bassa funzionare meglio (come in, gestire più connessioni simultanee) di un computer con più RAM e CPU?

Quali sono i fattori limitanti, oltre a IOS, che utilizzano metodi diversi per gestirlo?

linux router packetloss

— Gene blu
fonte

5

Le implementazioni nell'hardware sono più veloci quindi il firmware è più veloce del software per la stessa soluzione.

— mdpc,

3

Le "specifiche migliori" che menzioni sono irrilevanti per il lavoro da svolgere. Ci sono altre proprietà che contano davvero.

— ndim,

Ok, quindi ... da quello che hai scritto, dovrei supporre che il tuo Centos sia una macchina virtuale? A parte le ottimizzazioni di rete speciali per le macchine virtuali, sia su hypervisor che sul lato guest, le macchine virtuali sono generalmente note per non essere buone in questo tipo di ruolo ... per l'utilizzo come router / firewall, si consiglia sempre il bare metal !

— lapidato il

Stai effettivamente instradando 1 Gbps di traffico come suggerito dalla tua configurazione? Puoi usare un dumper per spostare una pala piena di sabbia. 6 GB di RAM e 4 core non saranno praticamente mai toccati per un router, è possibile risparmiare elettricità e spazio su rack utilizzando una piccola macchina Intel Atom per fare questo lavoro.

— Bert,

64

ASIC .

Invece di utilizzare una CPU generica e un software specifico per l'attività, è possibile saltare il software e fare in modo che il silicio gestisca direttamente l'attività.

L'hardware di rete ad alte prestazioni utilizza ASIC al posto del software per le attività computazionalmente pesanti (ma relativamente logicamente semplici) di qualcosa come il confronto di un indirizzo IP con un'enorme tabella di routing Internet, il controllo di una tabella CAM per una decisione di commutazione o il controllo di un pacchetto rispetto a un ACL . Ciò fa un'enorme differenza nella velocità di tali operazioni sensibili al tempo, fornendo un vantaggio significativo rispetto a una CPU per tutti gli usi.

— Shane Madden
fonte

1

mentre sono d'accordo con shane, sceglierei iptables in esecuzione su un server generico su un dispositivo ogni giorno. nella mia azienda, iptables in esecuzione su fedora è più veloce, più flessibile, più semplice da configurare, meno tassazione su CPU e memoria, più veloce da avviare e molto più economico del nostro Cisco Asa.

— rvh,

@rvh: per il firewalling o solo il routing?

— mveroone,

2

e nel complesso, "velocità" è un termine piuttosto lento qui. Sono sicuro che ci sono molte situazioni in cui un PC può ancora eseguire un'operazione "velocemente" come una HW, o forse ha una durata costante più lunga rispetto a HW. Ma si riduce davvero alla stabilità e al "bang for your buck" - stai ancora acquistando meno RAM / CPU con un'appliance, ma ne ricava di più e fa solo ciò di cui ha bisogno per ottenere stabilità

— Colin Godsey,

Questa risposta è errata per ommission. Anche solo gridare "ASIC" è un po 'ingenuo poiché la maggior parte dei router che usano NAT usano CPU generiche, a meno che non stiamo andando a prestazioni estreme. Anche in realtà i router hardware-NAT hanno limiti più forti sul numero di connessioni simultanee. Ciò che l'OP sperimenta è una configurazione errata e l'uso di un sistema operativo che non soddisfa l'attività.

— dualizzato il

@dualed most routers that do NAT use general purpose CPUsSì, questa è un'affermazione vera, ma ignora il fatto che molti di questi dispositivi scaricano operazioni specifiche su chip dedicati (come chiarisce una lettura della mia risposta completa sopra). Non pensare al NAT e al tracciamento delle connessioni (che, concordo, non si verificano negli ASIC nei dispositivi moderni), pensa alla tabella di routing e al passaggio a offload.

— Shane Madden

12

Un router dedicato di fascia alta è in grado di superare le prestazioni di un PC con una CPU più veloce e più RAM perché può eseguire più routing nell'hardware.

È la stessa ragione per cui uno switch Gigabit Ethernet da $ 60 può sovraperformare un PC da $ 2.000 con 4 schede GigE a due porte che fungono da switch Ethernet. L'interruttore è costruito da zero per essere un interruttore.

— David Schwartz
fonte

3

E poiché il router dedicato è in esecuzione su un disco flash, ci sono meno parti mobili che si guastano in momenti inopportuni.

— cpt_fink,

3

Non sono proprio sicuro che tu abbia ragione. Ho creato una protezione anti-DDOS di base per un'azienda con cui ho lavorato sulla base di netmap ( info.iet.unipi.it/~luigi/netmap ) e si è comportata molto bene anche su hardware normale (1 Gb / se veramente pieno o 11 M pacchetti / sec). Esiste anche una versione di openswitch per netmap su quel sito che può inoltrare pacchetti 3M / sec su hardware "normale", non conosco alcun interruttore economico (500 $) che possa farlo, ma potrei sbagliarmi.

— XzKto

2

@XzKto Un tipico switch GigE a 5 porte economico ($ 60) può inoltrare i pacchetti tra tutte le combinazioni di porte alla massima velocità del filo. Di solito usano una barra trasversale piena e non bloccante.

— David Schwartz

@XzKto Ciò che intendeva David è, a differenza del PC che gestirà la velocità "fino alla velocità effettiva delle sue interfacce", lo switch fa se per ogni combinazione di porta a porta. È possibile fare in modo che host1 parli con host2 e da 3 a 4, e ciascuna connessione in modalità full duplex e velocità massima . Non puoi batterlo. (e per più soldi, più porte, ancora più facile capire perché è più veloce). E per il router, è un po 'simile: l'hardware sarà in grado di reindirizzare più velocemente del software, in quanto può reindirizzare non appena ha abbastanza informazioni (il tuo router Linux lo farà ad ogni livello, ma arrivarci sarà già più lento)

— Olivier Dulac,

11

"Altro che IOS"?

IOS fa quasi la differenza. CentOS è un sistema operativo generico. È progettato per funzionare abbastanza bene in una vasta gamma di scenari, utilizzando una vasta gamma di diverse configurazioni hardware. D'altro canto, IOS è ottimizzato per gestire solo il tipo di carichi di lavoro che ci si aspetterebbe da un dispositivo di rete, utilizzando i tipi di hardware molto specifici che si potrebbero trovare nelle apparecchiature Cisco.

Sapere esattamente quale hardware stai programmando ti porterà molto lontano in termini di prestazioni rispetto alla compatibilità.

— Ryan Ries
fonte

3

+1. A ciò si aggiunge il fatto che Cisco dispone delle risorse tecniche e del know-how per sostituire il software con l'hardware quando necessario. In altre parole, se una determinata operazione è più lenta di quella che vorrebbe nel software, può impegnarsi a progettare un ASIC, aggiungere istruzioni alle unità di elaborazione esistenti o creare un modulo hardware per velocizzarlo. I tavoli si ribaltano in maniera schiacciante a favore delle prestazioni quando si ha il lusso di controllare sia il software che l'hardware.

— Giustino

Funziona anche in entrambi i modi. Neanche l'hardware deve affrontare casi rari e complessi. Li lancia semplicemente al software. Cicli di routing? Non cercare di capire in hardware come gestirli.

— MSalters

4

Sia il software che l'hardware hanno qualcosa da dire. Ho il confronto tra Intel e TP-Link NIC (che utilizza un chip Realtek nel suo cuore) su hardware server generico, nonché software appositamente costruito e generico nel routing.

Dal punto di vista hardware, se l'ASIC di bordo è in grado di gestire il traffico IP, il carico del processore può essere inferiore e quindi più veloce. Ho notato che i due chip NIC INtel integrati comunicano direttamente tramite DMA, ignorando la CPU principale nella gestione dell'inoltro di pacchetti; nel frattempo il chip Realtek si interrompe ogni volta che arriva un pacchetto.

Dal lato software, se il software è progettato per essere utilizzato nel routing, può essere reso più efficiente. Ho usato sia pfSense + PF (un FreeBSD modificato destinato ad essere usato come router) sia Ubuntu 12.04 + iptables generico come software di routing e il primo cambia chiaramente il traffico molto più velocemente. (Ubuntu 14.04 è ora quasi altrettanto veloce, grazie ai nuovi nftables nel kernel Linux 3.13.)

Tuttavia, il router dedicato presenta un grosso svantaggio: non può svolgere molto altro che cambiare il traffico e non può essere virtualizzato. Il mio attuale router perimetrale è una macchina virtuale all'interno del mio cluster ESXi con Ubuntu 14.04 e funge anche da sistema di rilevamento delle intrusioni e bilanciamento del carico.

3

AFAIK, è il sovraccarico di un sistema operativo generico; indipendentemente dalla velocità delle connessioni, i pacchetti vengono gestiti pacchetto per pacchetto nel contesto del kernel, aumentando la latenza e la tensione sul sistema. Credo che sia già stato spiegato nelle altre risposte meglio di quanto potessi fare.

Detto questo, ci sono promettenti nuove tecnologie "ish" in aumento in popolarità e fattibilità che potrebbero creare un concorrente più formidabile dai sistemi Linux in questo e in altri aspetti; cioè InfiniBand

Dai un'occhiata alle seguenti domande e risposte su StackOverflow: come viene implementato il bypass del kernel TCP

Ulteriori letture:

— ILMostro_7
fonte

2

Di solito è a causa della mancanza di configurazione di stack / dispositivi di rete out-of-box in Linux. In quasi il 90% dei casi il traffico di rete viene elaborato dalla CPU0 mentre gli altri sono inattivi. Se risolverai questa differenza di problema con i router hardware non sarà così drastico come potresti pensare. È necessario impostare almeno RSS o RPS (distribuzione di elaborazione dei pacchetti basata su driver / stack tra le CPU).

Se ti interessa davvero le prestazioni del tuo router linux e hai abbastanza tempo, ti consiglio di leggere questo articolo nel blog packagecloud (c'è anche un articolo sulla trasmissione di pacchetti).

Se dovessi dare un'occhiata alla distribuzione e pensi che guardare while sleep 1; do cat $some_file_in_procfs; done, la valutazione della maschera della CPU e la smp_affinityscrittura manuale siano noiosi, probabilmente avrai trovato il mio progetto per animali netutils-linux estremamente utile.

— strizhechenko
fonte