Newsgroup: it.comp.os.linux.sys
Titolo: Due interfacce, lo stesso IP.

Vediamo se riesco a spiegarmi.
Ho due server (siano radagast ed olorin) che sono PDC e BDC di un dominio
windows con samba, e fanno anche altre cosucce sparse (web, db, proxy, ...)
equamente distribuite tra loro.
Siccome comunicano spesso tra loro (sync LDAP, mount di share NFS, ...)
mi è venuta la grande idea di aggiungergli una bella scheda di rete giga
e collegarle con un cavo incrociato; ovviamente i due server sono a
10 centimetri uno dall'altro.
Onde evitare quelle che vedevo come complicazioni ho assegnato ad entrambe
le schede lo stesso indirizzo IP, con la differenza che la scheda principale
ha:
  iface eth0 inet static
        address 10.27.1.2
        netmask 255.255.0.0
        network 10.27.0.0
        broadcast 10.27.255.255
        gateway 10.27.1.254
mentre la seconda scheda ha:
  iface eth1 inet static
        address 10.27.1.2
        netmask 255.255.255.255
        up route add -host 10.27.1.3 eth1
Ad una prima analisi una cosa molto semplce come questa sembrava funzionare
perfettamente, ma approfondendo un pelo ho scoperto che le cose non stavano
proprio così.
Alcuni protocolli (che io mi sia accorto, LDAP con OpenLDAP, proxy con squid)
non riuscivano a comunicare; la spiegazione che mi sono dato è che
probabilmente olorin interroga il server LDAP di radagast sulla eth1
(usando il cavo cross), ma radagast risponde attraverso eth0, cosicchè il
sequencer TCP di olorin che si vede arrivare un pacchetto su eth0 dice
``che d'è?''. Non ho abilitato log_martian, ma credo che sarebbe stato
divertente...
A questo punto mi sono chiesto: ma se è un problema di questo tipo, perchè non
abilitare il proxy_arp su *eth0* (insisto, zero) di modo che anche le
interfacce eth1 possano essere visibili alla rete normale (eth0)?
In questa maniera funziona tutto, peccato che in una sede la rete ha avuto
un paio di giorni di malfunzionamenti strani (non è che tutti si chiedevano:
ma allora chi cazzo è 10.27.1.2? 00:40:F4:EB:C8:CE o 00:11:09:95:16:2E?), ma
ora tutto funziona perfettamente. Ero in ferie, non posso aver toccato nulla.
;)
Inoltre ho fatto l'esperimento presso una altra sede, dove avevo
inavvertitamente abilitato il forwarding (ip_forward) sulle due macchine, ed
è stato divertente vedere una sorta di fault tolerance dei poveri, nel
senso che le richieste dei vari client passavano random attraverso uno dei
server verso l'altro... ma anche qui mi hanno segnalato una masnada
di problemi.
So che sono un'ignorante, so che sto sbagliando qualcosa, ma: non capisco,
cosa stò sbagliando... ;(((
Grazie.
-- 
  Ho ancora la forza di starvi a raccontare
  le mie storie di sempre, di come posso amare		(F. Guccini)

         netmask 255.255.255.255
con questa netmask?
prova su una con:
   iface eth1 inet static
         address 10.27.1.2
         network 10.21.1.0
         broadcast 10.27.1.3
         netmask 255.255.255.252
e sull'altra con:
   iface eth1 inet static
         address 10.27.1.1
         network 10.21.1.0
         broadcast 10.27.1.3
         netmask 255.255.255.252
ma secondo me avrai ancora casini e faresti meglio ad asegnare loro ip
su una rete diversa.
Ciao, Micky
-- 
What's this hash prompt on my terminal mean?
Micky Del Favero  -  System Manager  &  BOFH

 Il fatto che due interfacce di rete non possono avere lo stesso IP.
falso, vedi il modulo bonding

 ha:
senti un po', se vuoi parallelizzare più schede di rete devi usare il
modulo bonding, ed associare a bond0 le interacce eth0 e eth1. Leggiti
la documentazione.
E comunque nel tuo design devi fare un'altra cosa: le due schede a
gigabit non devi metterle in cross, devi farle passare per gli switch.
Se hai solo uno switch non puoi fare faul tolerance, se ne hai di più,
magari con spanning tree, sei ok.
Se le metti incrociate ti freghi perché crei due segmenti ethernet
distinti, quindi avresti una fault tolerance che invece di pararti il
culo ti chiude in un mondo a parte.

 Il fatto che due interfacce di rete non possono avere lo stesso IP.
Mah, no, non è detto.
Che sia una scelta ``pittoresca'' posso anche capire, che non sia
possibile credo proprio non sia vero, o perlomeno non ne vedo il motivo...
nel senso che alla fin fine è un volgare problema di routing, e nulla
più.
Ad ogni modo, forse sto sbagliando lo strumento, nel senso che
probabilmente non è il proxyarp lo strumento giusto per questa cosa.
Mi chiedo se non sia l'advanced routing, ad esempio:
 
http://lartc.org/howto/lartc.rpdb.multiple-links.html
semplicemente definendo esplicitamente che quello che arriva per eth1 deve
tornare per eth1 e idem per eth0.
Ad ogni modo, per rispondere ad ottavio, non mi interessa il bonding, nel
senso che non mi interessa definire politiche di fault tolerance o
duplicare le prestazioni, voglio solo collegare le due macchine tra loro,
e mi sono incaponito a farlo con lo stesso IP. ;)

 tornare per eth1 e idem per eth0.
Con iproute ed iptables puoi fare più o meno quel che vuoi.
(e ovviamente l'affermazione che due interfacce non possono avere lo stesso
ip è palesemnte falsa, soprattutto in virtù del fatto che l'operazione ti è
tranquillamente riuscita. :))
La doamnda che sorge spontanea è però: c'è un motivo ben preciso per
complicarsi così la vita? :)

 complicarsi così la vita? :)
Autolesionismo? ;)
Non so, sinceramente ogni altra soluzione non mi piace, e a essere sinceri
se anche usassi IP diversi per le due interfacce dovrei comunque
abilitare il forwarding, se non in qualche caso il masquerading, a quel
punto usare una soluzione o l'altra non mi fa molta differenza...
Poi sinceramente provare cose nuove ogni tanto non fa male... magari non
su server in produzione, ma questa è un'altra storia. ;)))

Mandi! Ottavio Campana
  In chel d? si favelave...
OC> senti un po', se vuoi parallelizzare più schede di rete devi usare il
OC> modulo bonding, ed associare a bond0 le interacce eth0 e eth1. Leggiti
OC> la documentazione.
Si, per la cronaca ormai vendono switch managed che costano una pippa e che
fanno loro il bonding, quindi non dovrei manco toccare la configurazione
delle macchine linux... ma non è quello che voglio fare. ;)
-- 
  Ho ancora la forza di non tirarmi indietro, [...]
  di far la conta degli amici andati e dire ``ci vediam pi? tardi''
							(F. Guccini)

Mandi! Micky
  In chel d? si favelave...
M> secondo me se gli assegnavi un indirizzo diverso solo per loro i
M> problemi erano molti meno (ho 5 setup del genere, qui...).
...il problema è che poi avrei effettivamente indirizzi diversi, dovrei
definire nuove registrazioni in DNS, dovrei giocare con il forwarding per
alcune cose... resterebbe una soluzione non perfettamente pulita...
(ovviamente, sempre de gustibus, ...)
-- 
  ma l'impresa eccezionale, dammi retta
  e` essere normale					(L. Dalla)

 abilitare il forwarding, se non in qualche caso il masquerading, a quel
Perché dovresti?


> abilitare il forwarding, se non in qualche caso il masquerading, a quel
M> Perch? dovresti?
Perchè alcuni servizi (pensa ai virtual host o ai certificati ssl) richiedono
match esatto tra risoluzione forward e reverse, e qunidi o faccio qualche
giochetto con il dns oppure devo mascherare tutto di modo che escano con
l'IP (e l'hostname) corretto.
Che poi esistano altre cose che non so per fare questo, è un'altra storia...
;)))
-- 
  Berlusconi: "Da oggi sono a dieta"
  Il Paese lo ? gi? da 4 anni			(Il Ruggito del Coniglio)

Mandi! Davide Bianchi
  In chel d? si favelave...
DB> Il fatto che due interfacce di rete non possono avere lo stesso IP.
Quotarne uno per educarne cento! ;)
La cosa funzione perfettamente, e la soluzione è di una semplicità
disarmante:
	echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
[la soluzione mi è arrivata dalla lista lartc, vedere:
 
http://mailman.ds9a.nl/pipermail/lartc/2006q3/019625.html
e risposta]
Sostanzialmente è che con rp_filter (che debian abilita giustamente di
default) si evita che pacchetti possano tornare da una interfaccia da dove
non sono partiti, ma se non si abilita l'arp_filter linux risponde alla
richieste di arp su *tutte* le interfacce, e quindi la condizione precedente
necessariamente scatta, ovvero sega traffico a seconda di come le
apparecchiature di rete hanno registrato la tabella ARP.
Abilitato questo, linux impara a rispondere ale richieste arp solo all'
interfaccia da dove sono venute, e la cosa finisce li. ;)
-- 
  Donna ti voglio cantare, donna sei luce, donna sei cenere
  donnai sei ansia, donnai sei danza
  e a volte nuvola sei...				(A. Branduardi)