RE: [linux_var] DHCP con 2 gateway

[<lucky@luckyluke.org>]

On Tue, 4 May 2010 02:42:25 -0700, "Usuelli, Marco"
<M.Usuelli@interroll.com> wrote:

...a quanto pare hai destinazioni diverse sulle due rotte, e questo ti
semplifica la vita.

> googlando un po' vediamo che mi dite se nel dhcpd.conf setto:
> 
> option-routers B, A;
> option static-routes [MPLS traffic], A; [MPLS traffic], B;
> 
> in questo modo il default gateway è B ma il traffico MPLS "dovrebbe"
> essere instradato su A (option static-routes con peso maggiore) mentre
> tutto il traffico restante (non MPLS) va su B (default gateway)
questo è assolutamente corretto, anche se come ti hanno già fatto notare
occhio ai client dhcp: se l'impostazione del default gateway via dhcp
funziona (ovviamente) sempre bene, non tutti acquisiscono correttamente le
route statiche più specifiche. I già citati Windows ne erano un esempio,
ma
è una vita che non ho più provato a mandare route statiche a client dhcp
windowsiani, magari all'alba del terzo millennio hanno imparato a usare
dhcp :D

> se crolla A la seconda static route (peso minore) gestisce l'MPLS
traffic correttamente su B (secure gateway)
"crolla A" non è un concetto di cui il routing IP sia al corrente. Devi
occuparti tu in qualche maniera di far sparire la route più specifica dai
client (ad esempio col sistema
modifico-dhcpd-riavvio-attendo-scadenza-lease)

> se crolla B l'option static-routes continua instradare il traffico MPLS
su
> A mentre il secondo gateway (A) dovrebbe ripiazzare B per il traffico
> internet.
idem come per il caso precedente.

> cosa ne pensate ? 
che stringi stringi si torna sempre al caso di usare i due router (A e B)
in maniera "semplice", ognuno per il suo uplink, e di giocare in qualche
maniera (conf dhcpd e riavvio dello stesso?) con le tabelle di routing dei
client.
Tieni a mente che lo stack TCP/IP instrada il traffico. E basta. Nel senso
che non si preoccupa di vedere se i pacchetti sono arrivati a destinazione
e quindi non agisce di conseguenza... come dicevo sopra sei tu a dover
modificare le righe della tabella routing dei client.

Posta la condizione di partenza sui due router (cioè che lavorano in
maniera "stupida" e non intraprendono azioni in caso di failover) hai solo
due casistiche a disposizione:

- lasciare le cose come stanno e modificare secondo necessità la tabella
routing dei client (esempi di cui sopra, strada più semplice e che ti
consiglio)

- mettere un altro router in mezzo tra (A,B) e la lan e farlo usare come
default gw alla lan, facendogli inoltre verificare lo stato delle rotte
(tramite ping ad esempio) e facendogli modificare la SUA tabella di
routing
in caso di necessità. Ovviamente se questo nuovo router è "uno solo" hai
introdotto un altro single-point-of-failure, quindi sarebbe meglio fossero
due in failover (tipo l'HSRP di cisco o CARP+pfsync di pf (OpenBSD,
FreeBSD) e similari).
Tra i prodotti opensource il posto migliore dove guardare penso sia il già
citato pfSense (basato su freebsd e pf, con integrato CARP+pfsync), se no
ci sono tonnellate di prodotti commerciali (tra gli altri ti segnalo
l'Italiano www.endian.it, basato su linux[*]. Questa è la strada meno
semplice e più costosa in generale (tempo, hardware), ma con un certo
investimento porta i risultati migliori (in termini di disponibilità del
sistema per i client).

[*] occhio che sul sito trovi anche la versione community (gratuita,
opensource) ma non include il supporto all'HA che è invece presente nelle
versioni commerciali. Ne ho in giro un po' e vanno bene anche se
sinceramente non ho mai provato di persona configurazioni ridondate.

--
Luca Lesinigo

-- 
Per cancellare l'iscrizione: <talking-unsubscribe at ml.linuxvar.it>
Archivi web e configurazione: http://ml.linuxvar.it/ml/