Newsgroup: it.comp.os.linux.sys
Titolo: bonding non su link punto-punto

Un saluto al ng,
non so se l'oggetto è molto esplicativo, ma ho la necessità di fare,
dati due firewall con 3 interfacce di rete, un'aggregazione di banda tra
due lan da collegare assieme.
Il canale di trasmissione è sicuro, solo che non è un "punto-punto"
(cavo cross, fibra o altro punto-punto), ma è uno switch condiviso. Non
posso quindi usare, a meno di non dire totali castronerie, un normale
bonding, visto che non c'è certezza di chi parla dall'altro lato della
comunicazione.
Ho provato a mettere in piedi un "load balancing" tramite iproute e
funziona, ma non aggrega al 100% i canali o meglio, ad occhio, vede le
connessioni tcp e le fa passare sempre sullo stesso singolo canale.
Avete qualche idea di più?
Michele

 Avete qualche idea di più?
Non ho capito un apascio (cit.).

 Non ho capito un apascio (cit.).
:)
net1 (192.168.11.X) -- fw1 ( eth0: 192.168.11.1)-- eth1 & eth2 su switch
net2 (192.168.12.X) -- fw2 (eth0: 192.168.12.1)-- eth1 & eth2 su switch
eth1 e eth2 di entrambi i fw che indirizzamento ip voglio
le due reti devono parlarsi a 200 MBps (i fw hanno schede di rete a 100)
solo che non posso mettere un cavo cross tra le due apparecchiature,
ergo no bonding
Un po' meglio?

 ergo no bonding
?
Tu hai:
- fw1 connesso con due nic allo sw1
- fw2 connesso con due nic allo sw2
Vorresti mettere in bonding le due interfacce su entrambi i firewall
in modo che essi possano comunicare a 200mbit.
Giusto?
Se gli switch non sono managed e se non metti un cavo di 'stack' tra
i due switch � impossibile.
L'unica � che attacchi fw1 con fw2.
Se manca il cavo, non lo puoi sostituire lato software.

 Un po' meglio?
non ho capito granch�, ma spero sia cos�: tu hai due firewalls con 2 nic
ognuno. queste devono essere in bonding cos� da avere maggior banda.
la breve �: in linea pratica, non avrai mai 200mbit di banda. questo
perch� i link non funzionano con una divisione del carico tipo
round-robin (un frame a testa) ma con algoritmi vari di divisione del
carico che sfruttano di solito ip e mac address. quindi, se due host
parlano tra loro su un bonding, l'algoritmo sceglier� sempre uno dei due
canali. punto.
sempre in linea pratica, comunque, visto che di solito gli host sono pi�
di due, vedrai aumentare le performances.
il bonding possono essere fatti solo tra due endpoint. il che vuol dire
che due schede di rete di host diversi, cos� come due porte di due
switch diversi non possono essere messe in bonding.
lo stack, come ha suggerito Peregrino, unisce in modo logico due (o pi�)
switch che alla fine diventeranno ai fini pratici uno solo. questo ti
premette di fare bonding con due schede sullo stesso host e due switch
se ne hai bisogno, incrementando allo stesso tempo portata del link e
affidabilit�. il come si fa lo stack dipende dagli switch e dal
produttore. di solito � riservato per quelli di fascia medio-alta. per
farti un esempio, i cisco catalyst 3560 e 3750 sono praticamente la
stessa macchina, ma il secondo � stackable, il primo no. il costo � 3/4
(con un buon bid quasi la met�)

 
dimenticavo: una volta realizzato il bonding, dovrai creare 2
sottointerfacce con una vlan a testa o tutto il giochino salta.

 carico che sfruttano di solito ip e mac address.
Ci sono implementazioni con hashing a layer 4 che quasi ci arrivano...

 ergo no bonding
Ci sono tre modalità di bonding che non richiedono la "collaborazione"
dello switch: mode 1, mode 5 e mode 6.
Visto che parli di ip route, capisco, ora, che hai provato a fare balancing
a layer 3, ovvero su fw1 hai dato due rotte con ugual peso verso 
192.168.12.0/24
, una via eth1-fw2 e una via eth2-fw2, giusto?
Teini però conto che esiste il caching delle rotte, per cui, di fatto, una volta
che il router ha scelto uno dei due gateway per raggiungere un certo host, 
continuerà a usare quello.

 Se manca il cavo, non lo puoi sostituire lato software.
ovviamente con due switch, senza mezzo di comunicazione tra i due,
difficilmente riesco a far parlare i due fw :)
Michele

 portata del link e affidabilità.
Lo switch è uno all'interno del quale i connetti i miei "quattro cavi"
in "quattro porte".
A questo punto, la domanda potrebbe tramutarsi in: considerando il fatto
che il bonding non lo posso fare per i motivi di cui sopra e la
soluzione con iproute l'ho provata e anche se funzionante non fa proprio
al caso mio, conoscete qualcosa che lo potrebbe essere?
Grazie,
Michele

 raggiungere un certo host, continuerÃ  a usare quello.
Era proprio uno dei motivi per i quali, dopo svariate prove, ho lasciato
stare. Altro fattore, anche se non determinate, è il tempo di timeout
per il ricalcolo delle rotte, ed i vari ipv4/conf/gc_timeout non fa
proprio quello che gli si dice (non ho approfondito troppo)
Michele

 stare.
Hai per caso provato con mpath?


No.
Però ora sto trovando delle informazioni abbastanza contrastanti tra
loro. Da bugs.debian:
parlando di una patch per iproute, dove manca la documentazione di
mpath: "This has been removed from the kernel again because of complete
brokeness" e così via...
Poi c'è 
www.ssi.bg/~ja/
 dove vengono mantenute le varie patch, anche per
mpath.
Chi mai avrà ragione?
Esperienze?

 Esperienze?
No, io ricordavo l'esistenza di mpath, ma non l'ho mai usato, francamente.

 
www.ssi.bg/~ja/
Se può interessarti, la junmbo-patch kernelside si applica
perfettamente ai sorgenti 2.6.30 dai backports di lenny; se
e quando avrò un po' di tempo, proverò a patchare anche iproute
e a fare qualche test...

 tempo, proverò a patchare anche iproute e a fare qualche test...
No way, senza che nessuno ci perda tempo.

 Michele
Probabilmente non ho capito il tuo problema, per� se lo switch � managed 
puoi usare lo standard 802.3ad (LACP).
Non mi soffermo sul discorso throughput date che mi pare sia gi� stato 
trattato sulle altre risposte che hai ricevuto.