Newsgroup: it.comp.reti.cisco
Titolo: glbp

ciao a tutti
mi sono letto un po di roba sul glbp
però purtroppo si arriva sempre allo stesso risultato non si vive con 2
router che lavorano in load balancing, ma sempre un primario e un
secondario.
xkè?
qualkuno mi sa dire se è possibile avere 2 router primari con quel
protocollo?
ciao

 un secondario.
CUT
Non conoscevo glbp, ho trovato questo doc
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ft_glbp.htm
(perdona, non so usare tinyurl...)
e sembra invece che faccia proprio quello che ti serve, cioe' load sharing
tra router appartenenti allo stesso gruppo. Mi sembra di aver capito che i
router devono supportare mac-address multipli, ed il bilanciamento si
ottiene in virtu' del fatto che le risposte ARP vengono esaudite dal glbp
attivo inserendo di volta in volta i mac-address degli altri componenti del
gruppo.
Ciao
cronenberg
--
Il cielo stellato sopra di te, la legge morale dentro.
--------------------------------
Inviato via 
http://usenet.libero.it

allora nn ho proprio capito na mazza...
vabbè lo provo quando mi arrivano i router e che cisco me la mandi buona
"cronenberg" <video...@videodrome.videodrome> ha scritto nel messaggio
news:212Z211Z91Z2Y1...@usenet.libero.it...


 
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ft_glbp.htm
allora, tenendo presente anche il 3ad "2 router con lo stesso ip", vorrei
sottolineare un paio di cose.
I 2 problemi
lo scenario presenta 2 problemi da risolvere: - problema 1 la lan deve
usare entrambi i router (almeno fault tolerance, meglio load-balancing) -
problema 2 ho 2 linee verso internet e le voglio utilizzare entrambe
(almeno fault tolerance, meglio load-balancing)
il primo problema e' facilemte risolvibile con hsrp (un router attivo, uno
in stanby) o con glbp (2 o piu' router il load-balancing tra loro).
sicuramente la seconda soluzione e' cost-effective e scalabile.
il vero problema e' il 2.
una volta che uno dei due router ha ricevuto il traffico lo deve
instradare. qui toriamo ai soliti discorsi: o uso eigrp/ospf lato mio e
lato isp ed ottengo la soluzione cercata. se il mio isp non mi permette di
usare un processo di routing con uno dei suoi router devo cercare di
arrangiarmi, e le route map sono la sola cosa che mi puo' venire in aiuto.
il primo limite delle route map sta nel decidere quale traffico mandare su
una linea e quale su un'altra. sbagliare questa decisione potrebbe
significare una linea al 10% ed una al 90 %.
il secondo limite sta nelle risposte: se il firewall dietro ai due router
ha un ip della linea A, anche se i pacchetti escono dalla linea B le
risposte tornano dalla linea A, ho bilanciato solo in uscita (dando per
buona la route map).
questo e' risolvibile con il nat: tutto il traffico che esce da B viene
nattato con l'ip di B. ho fatto balancing in entrata ed in uscita (dando
per buona la route map).
ho realizzato il load balancing, ma sono ben lontano dal fault tolerance.
caso hsrp: un router attivo, uno in stanby. se il router attivo (quello
con la route map) si rompe tutto il traffico passa da B e non ci sono
problemi. se smette di funzionare la linea di A, la linea di B o il router
B e' un casino.
si rompe la HDSL di A: la serial 0/0.1 risulta cmq up (se va down vedi
caso successivo) ed il router A manda a B quel che dice la routemap, e
prova a fare uscire il suo traffico dalla seriale. timeout.
si rompe la ADSL PPoE di A: la ATM0/0.1 va down (se PPoA con Dialer1 e
questo restasse up ricadiamo nel
caso precedente), la default viene rimossa dalla tabella di routing, il
router A inoltra a B il traffico marcato dalla route map, destination
unreachable per quello che avrebbe dovuto instradare lui.
smette di funzionare la linea di B: sia una hdsl o una adsl, che la int
sia up o down, tutto il traffico che la route map su A manda a B va in
timeout o restituisce dest unreach
se smette di funzionare il router B, tutto il traffico reinstradato dalla
route map su A va su un ip che non risponde. il traffico e' perso.
nel caso di glbp, che ricordo fa load-balancing e fa ricevere un po' di
pacchetti ad A ed un po' a B la cosa si complica: ho bisogno di 2 route
map, una su A ed una su B, speculare. i pacchetti dalla lan vengono
ricevuti ora da A ed ora da B e quindi entrambi i router devono sapere che
tutto http passa da A e tutto ftp passa da B, ad esempio.
i casi presentati precedentementi nella situazione di rottura del router B
o della sua linea ricadono assolutamente identici su questo scenario, ma
per entrambi i router. se una sola cosa smette di funzionare meta'
traffico e' perso.
se non metto route map ne' nat ottengo load balancing in uscita (sempre
dimenticando egress filtering: dubito che inet (linea router B) lasci
passare sulla sua rete traffico con ip sorgente di albacom (linea router
A)) ma tutte le risposte tornano sulla line A e se quella non funziona e'
tutto fermo.
quindi torniamo al punto di partenza: senza un protocollo di routing (ospf
con l'isp o bgp multihomed) non posso sapere quale linea funziona e quale
no, ne' posso fare un corretto load-balancing in fail-over in entrata.
un mayhem prolisso.
-- 
 La mia prima misura anticoncezionale e' stata la preghiera.
 Cisco  FAQ: 
http://mayhem.oltrelinux.com/icrc
 SPP  wpage: 
http://www.spippolatori.com
 Key on 
pgp.mit.edu
 ID C7393613

...


 di poterci saltare fuori GLBP altrimenti č un po un problema..
Come ti ha gia' detto mayhem glbp lo puoi buttare dentro, ma io credo che
forse ti stai concentrando troppo su una questione particolare (il
bilanciamento), che forse inizialmente e' secondaria rispetto alla IMHO
primaria, cioe' il backup, ed alla corretta gestione del routing BGP, ed
alla scelta piu' calzante alle tue esigenze (ed al dimensionamento dei
router..) tra le tantissime opzioni che si possono avere in ambito
multihoming.


 saltare fuori GLBP altrimenti č un po un problema..
bgp e' buono ma non fantastico. con bgp puoi regolare (anche con le route
map+bgp) molto granularmente il load-balancing ed il backup in uscita,
senza alcun problema.
e certamente, se sei su deu isp, hai anche il backup in entrata gestito
correttamente (il bgp fa si che tutto il traffico diretto a te, se il tuo
isp A e' down ti arrivi tramite il tuo isp B). il load-balancing in
entrata lascia un po' a desiderare: sono gli altri AS ce decidono come
mandare il traffico a te, non tu che decidi come fartelo mandare.
se hai una connessione come quella descritta, glbp+bgp multihomed, hai
risolto il 99% dei tuoi problemi.
un mayhem gia' stanco


 > di poterci saltare fuori GLBP altrimenti è un po un problema..


 poterci saltare fuori GLBP altrimenti č un po un problema..
bgp e' buono ma non fantastico. con bgp puoi regolare (anche con le route
map+bgp) molto granularmente il load-balancing ed il backup in uscita,
senza alcun problema.
e certamente, se sei su deu isp, hai anche il backup in entrata gestito
correttamente (il bgp fa si che tutto il traffico diretto a te, se il tuo
isp A e' down ti arrivi tramite il tuo isp B). il load-balancing in
entrata lascia un po' a desiderare: sono gli altri AS ce decidono come
mandare il traffico a te, non tu che decidi come fartelo mandare.
se hai una connessione come quella descritta, glbp+bgp multihomed, hai risolto il 99%
dei tuoi problemi.
un mayhem gia' stanco


 
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t15/ft_glbp.htm
allora, tenendo presente anche il 3ad "2 router con lo stesso ip", vorrei

I 2 problemi















un mayhem prolisso.
