Eseguiamo esclusivamente router / firewall OpenBSD per servire FogBugz On Demand. A meno che tu non stia operando in un ruolo di transito e non abbia bisogno di un throughput pps estremamente elevato che l'hardware appositamente costruito e il software integrato possono fornire, OpenBSD su hardware solido sarà una soluzione più gestibile, scalabile ed economica.
Confronto di OpenBSD con IOS o JUNOS (nella mia esperienza):
vantaggi
- Il firewall pf non ha eguali in termini di flessibilità, configurazione gestibile e integrazione in altri servizi (funziona perfettamente con spamd, ftp-proxy, ecc.). Gli esempi di configurazione non rendono giustizia.
- Ottieni tutti gli strumenti di un * nix sul tuo gateway: syslog, grep, netcat, tcpdump, systat, top, cron, ecc.
- Puoi aggiungere strumenti se necessario: iperf e iftop l'ho trovato molto utile
- tcpdump. È stato detto abbastanza.
- Configurazione intuitiva per i veterani di Unix
- Perfetta integrazione con la gestione della configurazione esistente (cfengine, puppet, script, qualunque cosa).
- Le funzionalità di prossima generazione sono gratuite e non richiedono moduli aggiuntivi.
- L'aggiunta di prestazioni è economica
- Nessun contratto di supporto
svantaggi
- IOS / JUNOS semplifica il dump / caricamento di un'intera configurazione. In assenza di strumenti di gestione della configurazione, saranno più facili da implementare una volta scritta la configurazione.
- Alcune interfacce semplicemente non sono disponibili o stabili su OpenBSD (ad esempio, non conosco schede ATM DS3 ben supportate).
- I dispositivi Cisco / Juniper dedicati di fascia alta gestiranno pps più elevati dell'hardware del server
- Nessun contratto di supporto
Finché non stai parlando di router backbone in un ambiente simile a un ISP o di router edge che si interfacciano con connessioni di rete specializzate, OpenBSD dovrebbe andare bene.
Hardware
La cosa più importante per le prestazioni del router sono le schede di rete. Una CPU veloce verrà rapidamente sopraffatta da un carico moderato se si hanno schede di rete di merda che si interrompono per ogni singolo pacchetto che ricevono. Cerca almeno schede NIC gigabit che supportano la mitigazione / coalescenza degli interrupt. Ho avuto fortuna con i driver Broadcom (bge, bnx) e Intel (em).
La velocità della CPU è più importante che nell'hardware dedicato, ma non è qualcosa di cui preoccuparsi. Qualsiasi moderna CPU di classe server gestirà una tonnellata di traffico prima di mostrare qualsiasi sforzo.
Prendi una CPU decente (più core non aiutano ancora molto, quindi guarda GHz crudo) buona RAM ECC, un disco rigido affidabile e uno chassis solido. Quindi raddoppiare tutto ed eseguire due nodi come cluster CARP attivo / passivo. Dall'aggiornamento 4.5 di pfsync puoi eseguire active / active, ma non l'ho provato.
I miei router funzionano fianco a fianco con i nostri sistemi di bilanciamento del carico in configurazioni 1U a doppio nodo. Ogni nodo ha:
- Chassis Supermicro SYS-1025TC-TB (schede di rete Intel Gigabit integrate)
- CPU Xeon Harpertown Quad Core 2GHz (i miei bilanciatori di carico utilizzano i core multipli)
- RAM registrata ECC Kingston da 4 GB
- NIC add-in Intel Gigabit a doppia porta
Sono stati solidi fin dalla distribuzione. Tutto ciò è eccessivo per il nostro carico di traffico, ma ho testato un throughput fino a 800 Mbps (limitato alla NIC, la CPU era per lo più inattiva). Facciamo un forte uso delle VLAN, quindi anche questi router devono gestire molto traffico interno.
L'efficienza energetica è fantastica poiché ogni chassis 1U ha un singolo alimentatore da 700 W che alimenta due nodi. Abbiamo distribuito router e bilanciatori su più chassis in modo da poter perdere un intero chassis e avere un failover praticamente continuo (grazie pfsync e CARP).
Sistemi operativi
Alcuni altri hanno menzionato l'uso di Linux o FreeBSD invece di OpenBSD. La maggior parte dei miei server sono FreeBSD, ma preferisco i router OpenBSD per alcuni motivi:
- Una maggiore attenzione alla sicurezza e alla stabilità rispetto a Linux e FreeBSD
- La migliore documentazione di qualsiasi sistema operativo Open Source
- La loro innovazione è incentrata su questo tipo di implementazione (vedi pfsync, ftp-proxy, carp, vlan management, ipsec, sasync, ifstated, pflogd, ecc., Tutti inclusi nella base)
- FreeBSD ha più versioni dietro la porta di pf
- pf è più elegante e gestibile di iptables, ipchains, ipfw o ipf
- Processo di installazione / installazione più snello
Detto questo, se hai familiarità con Linux o FreeBSD e non hai il tempo di investire, è probabilmente un'idea migliore andare con uno di loro.