Newsgroup: it.comp.os.linux.sys
Titolo: Zebra, Quagga, Vyatta & Cisco

Come da subject, secondo voi, tra i 4, cosa è meglio?
Zebra è perennemente in beta,
Quagga è in stable
Vyatta è in stable e sembra anche molto potente
Cosa consigliereste da piazzare in produzione in sostituzione ad una
coppia di cisco 2800 in BGP?
(E soprattutto, perchè consigliereste X al posto di Y)
Qualche controindicazione?
Qualche vantaggio (oltre al fatto che un server linux ultracarrozzato
costa sempre meno di un cisco entrylevel)?

 costa sempre meno di un cisco entrylevel)?
Il fatto di poterci scriptare alla bisogna (es: io uso un nullrouting 
annunciato BGP da un quagga, per ottemperare al blacklisting per-IP del 
CNCPO. Scriptare la generazione del config-file di quagga e richiamarne 
il reload č senza dubbio piů facile che scrivere uno script che metta 
direttamente le mani "live" sulla configurazione di un router, 
aggiungendo o togliendo delle rotte...).
Per il resto, un route server č una bestia piuttosto stupida. Che giri 
in un router oppure in un server poco cambia...

 in un router oppure in un server poco cambia...
In termini di risorse invece?
So che le route tables girano tutte in RAM, quindi un bel 2GB o 4GB
dovrebbe
essere più che abbondante per ottenere tutta la full-route.
Come processore invece? Un dualcore Xeon 2.33 o 2.66 può andare?
Considera che le linee saranno relativamente piccole (se vuoi in
privato ti do ulteriori dettagli)
Vorrei evitare di mettere in piedi qualcosa di sottostimato già
dall'inizio e doverci metter mano
dopo poco tempo.
Tnx.

 Come processore invece? Un dualcore Xeon 2.33 o 2.66 può andare?
E' una attività che può richiedere tanta RAM. Dal punto di vista della 
CPU le risorse sfruttate son ridicole. Basterebbe probabilmente un P3 
500MHz a starci dietro, indipendentemente dalla quantità di rotte 
(d'altra parte, il numero di AS è pur limitato superiormente :-D ).

 (d'altra parte, il numero di AS è pur limitato superiormente :-D ).
Ok per il processore, quindi vado per il dualcore più piccolo, il 2.33.
Per la ram, io credo che 2GB possano bastare, il tecnico mi ha detto che
per esperienza personale si riescono a far stare delle fullroute in 512MB 
sui cisco 2811/2821 (quelli che dovevo comprare io)

 coppia di cisco 2800 in BGP?
Io ho esperienze con Quagga (su freebsd, alcuni anni fa) e, per il BGP, non
ho avuto particolari problemi.
Qualche rognuccia c'era con OSPF e interfacce tun o tap, ma credo che si
stata in qualche maniera risolta.
Ad ogni buon conto, i vantaggi di operare su una piattaforma open sono
innumerevoli, a partire dalle capacità di debugging e di scripting
che in IOS ovviamente non esistono.
Sulle performance, beh, mi pare ovvio che un server moderno rompa
le corna a un 7200, viste le CPU in gioco.
C'è da dire che l'IOS ha molte più feature di quelle che ha quagga, a 
quanto dicono coloro che fanno routing *serio* (i router quagga che usavamo
all'epoca facevano cose abbastanza semplici, per cui personalmente non ho
notato la differenza)

 ai limiti delle CPU.
Porprio ieri aprlavo con Marco di Vyatta e dintorni e mi ha segnalato
un paio di paper interessanti, basati sul suo lavoro di tesi:
http://www.tnt.dist.unige.it/index.php?option=com_remository&Itemid=46&func=select&id=64

 abbastanza semplici, per cui personalmente non ho notato la differenza)
Ecco, quali sono queste features?
Se sono features utilizzate solo da AT&T o SeaBone o Cogent su transiti 
internazionali, be, chissenefrega (parlo nel mio caso ovviamente)
Ma se tali features che quagga non ha rientrano in features utilizzate
durante ordinaria amministrazione, be allora potrebbe essere un problema.
Non avendo mai lavorato con BGP, non saprei neppure quale possa essere
l'ordinaria amministrazione oltre al fatto di forzare una data
destinazione tramite un dato peering anzichè quello di default, ma credo 
che questa cosa quagga la faccia senza troppi problemi
(altrimenti, non saremmo nemmeno qui a parlarne IMHO).
Io al momento devo:
1) importare la fullroute da due peering mediante eBGP.
2) far comunicare i due router tra loro mediante iBGP[1]
3) attivare VRRP per avere ridondanza in caso di guasto ad un router.
4) firewallare la rete locale direttamente sui due router e fare anche 
QoS mediante HTB e la sua banda garantita/picco tramite shorewall.
[1] iBGP mi serve perchè avendo le linee connesse solo ad un singolo 
router (linea1->router1, linea2->router2) nel caso il path migliore per 
arrivare su XXX fosse quello mediante router2 ed in quel momento VRRP 
fosse attivo su router1, router1 deve poter reinstradare le richieste 
mediante router2. Mi han detto che serve iBGP. Ed io mi fido :)
Al momento esporto solo una singola allocazione assegnatami dal RIPE,
quindi dubito fortemente mi possa servire OSPF, credo che sia
sufficiente esportare staticamente la singola route..
O sbaglio?

 sua banda garantita/picco tramite shorewall.
Non dovresti avere problemi di sorta.