Newsgroup: it.comp.os.linux.sys
Titolo: Network Failover

Domanda probabilmente banale
ma a cui non riesco a dare una risposta.
Ho due sk di rete, una collegata alla lan, una a
un cavo cross.
lan ip: 192.168.77.x eth0
ip cross: 172.16.7.x eth1
mettiamo che il cavo cross si rompa,
io vorrei che la mia linux box fosse così
intelligente da instradare il traffico
per la 172.16.7.x sulla lan in modo
da raggiungere l'altra macchina.
come posso fare?
ho provato con
route add -net 172.16.7.x metric 3 dev eth0
ma niente da fare, la macchina, giustamente, tenta
di mandare fuori i pacchetti sulla eth1.
ciao e grazie anticipatamente!

 da raggiungere l'altra macchina.
cioè, vediamo se ho capito bene:
tu hai una macchina che fa da gateway tra due lan (chiamiamole A e B).
se B va giù, tu vuoi che i pacchetti per B passino attraverso A?
se fosse cosi' non si puo' fare.
ma probabilmente ho capito male.
forse invece hai due indirizzamenti IP sopra una unica lan. non che
cambi molto, ma qui qualcosa si puo' fare.
fammi sapere che caso e'?

> fammi sapere che caso e'?
no, non sono gateway.
ho due macchine con due sk di rete ciascuna.
una sk di rete è collegata alla lan,
l'altra con un cavo cross all'altra macchina.
io vorrei che se si rompe il cavo
tutti i pacchetti che avrebbero dovuto passare
di lì mi vengano girati tramite la lan.
spero di essermi spiegato.

 se fosse cosi' non si puo' fare.
Dipende dalla topologia della rete, ma di suo non c'e' motivo per cui A, a
fronte della caduta di B, non ne acquisisca l'indirizzo di rete su cui
arrivano i pacchetti destinati al gateway.
-- 
Per rispondermi, sostituisci a nomecognome il mio nome e cognome
To reply me, substitute nomecognome with my real name and surname

 di mandare fuori i pacchetti sulla eth1.
Devi prima abbattere eth1.
Se vuoi un recupero automatico, in seguito devi rialzare eth1, provare se
funziona ed eliminare il route. (altrimenti riabbassare eth1).
Come soluzione è un po' agricola. ma tutto dipende da cosa vuoi fare.
-- 
| /
| \Byte - Andrea Briganti - kbyte(aaattt)
despammed.com
CSLug member: 
http://cslug.linux.it
 - JID: 
kb...@jabber.linux.it
***Se la montagna viene da te e non sei Maometto: corri che ?? una frana!

 
e' proprio quello che volevo sapere: la topologia della rete.

 di lì mi vengano girati tramite la lan.
io metterei  (anche se non è proprio economico di solito) le 2
interfacce in bonding via switch con 2 vlan. una la chiamo eth0 e
l'altra eth1. se cascasse anche una interfaccia fisica, lui
reinstraderebbe tutto sull'altra.
una soluzione piu' semplice non mi viene in mente.

 Come soluzione è un po' agricola. ma tutto dipende da cosa vuoi fare.
Ricordati di arare e seminare tutti e due i campi.
Anche B, se arriva un pacchetto da lan invece che da cavo incrociato,
deve sapere che la route e' cambiata, per raggiungere A e rispondergli.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net

 da raggiungere l'altra macchina.
Con un protocollo di rete dinamico?
-- 
Lorenzo Vaina, MCP

 Con un protocollo di rete dinamico?
tipo?
puoi indirizzarmi da qualche parte?

 Come soluzione è un po' agricola. ma tutto dipende da cosa vuoi fare.
quindi potrei benissimo farmi uno
script che verifichi quando va giù l'altro ip,
in quel caso tiro giù l'interfaccia, faccio girare
tutto sulla lan e mi mando una mail.
molto agricola ma speriamo sia efficace...
il recupero automatico meglio di no :)

Sette wrote:

No.
Non certo per cattiveria, soltanto perché li conosco bene sotto Windows, ma
riguardo a Linux non ne so nulla :-(
Però mi sento di consigliarti di investire una mezz'ora su google, cercando
RIP (Routing Information Protocol) e sue implementazioni in Linux. È un
protocollo basato su vettori di distanza, adatto per reti piccole; fa quel
che ti serve: adegua il routing alla topologia attuale della rete.
Tieni presente che parlando di un protocollo di routing, per rete piccola si
intende una decina di sottoreti; diversamente è rarissimo che serva e
questo è il motivo per cui su Linux ora come ora non so nemmeno se è
supportato ma trattandosi di un protocollo standard per IP lo darei per
scontato. Ad ogni modo spesso si usa l'instradamento manuale perché una
maggior complessità non serve, però è adatto anche per due computer.
-- 
Lorenzo Vaina, MCP

 RIP (Routing Information Protocol) e sue implementazioni in Linux.
[cut]
guarda:
http://www.quagga.net/
http://www.zebra.org/
ciao
Gabriele

Lorenzo Vaina wrote:
RIP 
Ho trovato anche BIRD (
http://directory.fsf.org/BIRD.html
).
Il Net-3 howto parla di due demoni che implementano il routing dinamico:
routed (per RIP) e gated (per RIP e OSPF). L'indirizzo (uno dei molti) è:
http://www.docmirror.net/it/linux/howto/misc/NET-3-HOWTO/NET-3-HOWTO-5.html
più o meno a metà pagina (fai una ricerca a testo libero per "routed").
Dice tra l'altro: "Il programma `routed' di solito fa parte delle
distribuzioni di Linux, oppure si può trovare incluso nel pacchetto
`NetKit' descritto all'inizio." (Ma io l'inizio non l'ho letto).
A questo punto, installare un pacchetto che lo contiene (dalla propria
distibuzione) e poi fare man routed mi sembra la via più semplice.
Ultima osservazione riguardo ai protocolli: RIP: te lo consiglio, ha
capacità ben superiori a quelle che ti servono ma è semplice e va bene.
BGP: oggi è stata la prima volta che l'ho sentito nominare. OSPF: lascialo
pure stare; va bene, per carità, ma è davvero complesso e richiede una
lunga configurazione, è adatto a reti enormi, anche con centinaia di
sottoreti, anelli e percorsi alternativi multipli, può servire anche due
soli computer ma sarebbe come prendere il Concorde per andare dal Colosseo
ai Fori Imperiali.
Curiosità: cercando i termini "RIP Linux" ho trovato anche una pagina degli
appunti di informatica libera di Daniele Giacomini, che inizia così:
RIP, che di solito sta per rest in peace («riposa in pace») è il nome di una
serie di sistemi GNU/Linux e FreeBSD di emergenza, da avviare attraverso
dischetti o CD di dimensioni ridotte. In tal caso, il nome è da leggere, un
po' ironicamente, come Recovery is possible.
-- 
Lorenzo Vaina, MCP