Newsgroup: it.comp.reti.cisco
Titolo: Aiuto per rotte

Ciao a tutti,
mi date il vostro parere su qual'è il miglior modo per risolvere un problema di 
bilanciamento di rotte, mi spiego meglio:
la sede A e la sede B sono collegate tra loro in tre modi differenti:
1) via FrameRelay con un PVC diretto
2) un tunnel punto punto ipsec attraverso internet su rete Wind
3) un tunnel punto punto ipsec attraverso internet su rete Fastweb
Tutto l'instradamento gira via EIGRP (tutti gli apparati coinvolti sono dei 2811 
-per la FrameRelay- e dei 1801 -per i tunnel- con dei 3750 o 4510 -come centro 
stella-) e fortunatamente le reti sono tre reti private distinte:
-dati: 172.16.0.0
-fonia:10.16.0.0
-erp:10.30.0.0
All'inizio le comunicazioni erano solo "dati" perciò si usava solo la FrameRelay 
(i tunnel erano di backup).
Successivamente si è migrata la fonia su IP (con i 2 call manager su una sede 
sola ). A quel punto ho forzato le rotte della fonia attraverso la FrameRelay 
con "ip route 10.16.x.x" sulla seriale lasciando transitare i dati sul tunnel.
Ora mi viene chiesto di far girare la rete del gestionale sul tunnel wind 
attualmente inutilizzato.
Pensavo di utilizzare le route-map con il comando "next-hop" e rimuovere anche 
le istruzioni "ip route" che ho forzato per la fonia. Questo perchè vorrei 
cercare di lasciar fare il più possibile a eigrp e vorrei evitare le eccezioni 
di "ip route" fatte a manona.
Come altro posso fare ? Quali sono i metodi consigliati da Cisco in questi casi ?
Grazie in anticipo.
Rizio
-- 
Si vis pacem para bellum

Un'altra idea che mi viene, ma io stesso la trovo un po' stupida, è
quella di avere TRE istanze di EIGRP, annunciando su ciascuna una sola
rete e mettendo in "passive-interface" le interfacce dove NON vuoi che
passi quella rete.
In alternativa al "passive interface", potresti riuscire a "pesare" 2
strade in modo da avere un percorso "primario" ed uno di BackUp per
ciascuna rete (da verificare - in questo momento non ho tempo per
approfondirlo, ma poi ci guardo e ti faccio sapere).
So che non è molto - ci penso ancora su ...
Claudio

 Claudio
Grazie mille a priori,


Il 13/12/10 16:15, Rizio ha scritto:

Ciao Rizio,
credo che tu possa a fare a meno di usare le route-map;
ho messo un po' insieme le tue informazioni che hai fornito nello schema 
ipotetico seguente... non è detto sia giusto ma spero serva a chiarire 
la mia proposta.
sede a 4500 fa1/1: - 2800-FrameRelay PVC - 2800  FONIA		
sede a 4500 fa1/2: - 1801-vpnTunnell via wind - 1801 ERP
sede a 4500 fa1/3: - 1801-vpnTunnell via fastweb - 1801 DATI
sede a
vlan 31 dati a  
172.16.1.0/24
vlan 32 fonia a 
10.16.1.0/24
vlan 33 erp a   
10.30.1.0/24
sede b
vlan 31 dati b  
172.16.2.0/24
vlan 32 fonia b 
10.16.2.0/24
vlan 33 erp b   
10.30.2.0/24
Prendiamo in esame la sede a.
Il 4500 è eigrp neighbor dei tre router (2801 framerelay, 1801 wind, 
1801 fastweb) e annuncia loro tutte e tre le subnet dati, fonia, erp.
Con il comando offset-list (forse Claudio nel post precedente si 
riferiva a questo) puoi rendere più o meno preferibile  ognuna delle 
rotte in relazione all'interfaccia di ingresso del pacchetto EIGRP 
Update, e quindi a seconda del neighbor, a condizione che sia presente 
una subnet dedicata tra il 4500 e ognuno dei router 2801 e 1801.
Se i router WAN sono tutti sulla stessa subnet questa soluzione non è 
applicabile e diventa necessario l'uso delle route-map.
La sintassi prevede
offset-list <access-list> <in|out> <peso-aggiunto-in-delay> <interfaccia>
Ecco un esempio:
access-list 7 remark rotte dati...
access-list 7 permit 172.16.0.0 0.0.255.255
access-list 8 remark rotte fonia...
access-list 8 permit 10.16.0.0 0.0.255.255
access-list 9 remark rotte erp....
access-list 9 permit 10.30.0.0 0.0.255.255
router eigrp 99
offset-list 7 in 6 fastethernet 1/1
(cioè alla rotta che matcha l'acl 7 proveniente dalla interfaccia 
fast1/1 è aggiunto un  eigrp delay + 6)
offset-list 7 in 3 fastethernet 1/2
(cioè alla rotta che matcha l'acl 7 proveniente dalla interfaccia 
fast1/2 è aggiunto un  eigrp delay + 3)
offset-list 7 in 0 fastethernet 1/3
( un offset uguale a zero significa che la metrica viene lasciata 
intatta e risulta quindi preferibile rispetto alle altre)
!con queste tre regole il 4500,  per raggiungere la rete dati della sede 
b,  preferirà il percorso attraverso la fast1/3 e la vpn fastweb .
!Se cadesse la vpn di fastweb, allora userà la vpn wind e per ultimo il 
framerelay pvc, il percorso meno preferibile, la cui rotta è 
caratterizzata dall'offset più alto.
offset-list 8 in 0 fastethenet 1/1
offset-list 8 in 3 fastethernet 1/2
offset-list 8 in 6 fastethernet 1/3
!stesso discorso applicato alla fonia che deve utilizzare il framerelay pvc
offset-list 9 in 6 fastethernet 1/1
offset-list 9 in 0 fastethernet 1/2
offset-list 9 in 3 fastethernet 1/3
!stesso discorso per traffico erp che userà la vpn wind.
Ora prendiamo in esame il 4500 e la rotta dati sede b. Presuppongo che 
il valore di variance sia lasciato a 1, il default.
Alla fine avresti nella topology table dell'eigrp tre percorsi 
possibili, via frame relay, via tunnell wind, via tunnell fastweb, ma 
nella routing table una sola rotta verso il 1801 che governa il tunnell 
vpn in fastweb.
Stessa configurazione nel 3750 della sede b.
buon lavoro! :-)

 vlan 33 erp a   
10.30.1.0/24
Credo pero' che il Branch abbia:
-vlan X per i dati (pc utenti)
-vlan Y per la voce (telefoni voip)
Rizio confermi?
Questa cosa complicherebbe un po' rispetto alla soluzione di Marco
(G.) perche' gli utenti dalla vlan X avrebbero bisogno di inviare e
ricevere dati sia sul collegamento dati che sul collegamento erp,
immagino che lo spostamento sul tunnel dell'erp serva a velocizzare
l'applicazione gestionale togliendola da un link congestionato.
Quindi la mia proposta sarebbe:
-offset lists sui branch
-policy routing su HQ  (altrimenti il ritorno verso i branch non
seguirebbe la nostra logica)

Un paio di accorgimenti per farti meno male:
-verifica che il comando "bandwidth" sia applicato su tutte le
interfacce, e' molto importante per la metrica eigrp, sopratutto sui
tunnel non e' detto che il default vada bene
-guardati molto bene le metriche sui Branch, cerca di usare gli offset
in modo da avere un feasible successor, cosi' che se ti cade un link,
la convergenza del traffico avviene in "sub second", senza che la
rotta vada in active.
-quando fai le prove, cerca di fare tutto in test,  ogni volta che
configuri un offset, eigrp resetta la neighborship con un bel
"resync", il che non e' esattamente simpatico in produzione
-se fai policy routing nell'HQ, cerca sempre di metterci un track, in
modo che se ti casca una linea, non fai blackholes
HTH
Marco Rizzi
--
Marco Rizzi
home: 
http://rizzitech.blogspot.com

 buon lavoro! :-)
Grazie mille, ho già cominciato a leggere la doc che ho trovato, sono solo in 
dubbio riguardo alla tua frase "sono tutti sulla stessa subnet".
Grazie mille della risposta esaustiva.


 Marco Rizzi
Grazie dei consigli e delle correzioni.


 Rizio


Rizio, secondo me è proprio come dici tu. Le route-map sono potenti, 
utilissime, a volte obbligatorie, in molti casi; con le offset puoi 
modificare le metriche e niente di più.
Sarebbe interessante simulare l'architettura di Rizio in dynamips...ci 
vorrebbe solo un po' di tempo a disposizione...che manca sempre:-)


Se vuoi avere un traffico bilanciato e fare in modo che il traffico erp 
passi per lo stesso link nei due sensi senza dover usare il policy routing 
direi che non hai alternativa.
Per eigrp due subnet due link, tre subnet tre link :-)
Piuttosto quello che non mi chiaro è quale organizzazione interna deve avere 
un azienda che dedica degli host all'erp e degli host a tutto il resto, o 
quando si parla di erp ci si riferisce solo a server?
Ciao,
         Tosh. 

          Tosh. 
Ciao e grazie anche del tuo parere.


 spero di avere chiarito qualche riga sopra.
Si si, sei stato chiaro, sono io che mi ero dimenticato quel particolare del 
port-channel.
Grazie


 direi che non hai alternativa.
Questo ï¿œ assolutamente vero...ma per trasportare la stessa vlan dalla 
sede a alla b servirebbe un servizio di trasporto layer 2 su una vpn 
sito to site?

 Non si può definire il next hop al posto dell'interfaccia ?
Erroneamente non tenevo conto della necessità di controllare il 
percorso di ritorno dei pacchetti, come giustamente rilevato da Tosh nel 
post precedente: se voglio che la comunicazione tra
server erp sede a <-----> client erp sede b
passi solo attraverso un determinato link, devo fare source based routing.
Quindi il discorso che faceva Marco R. mi sembra molto sensato:
* uso delle offset-list nel routing eigrp del 3750 sede b
* uso di Policy Based Routing (quindi route-map) sul 4500 sede a
ciao


Intendevo dire che eigrp (come qualunque altro protocollo di routing), 
lavorando per prefissi, funziona perfettamente nel distribuire il traffico 
quando questo � gi� separato logicamente, come immagino sia il caso del voip 
della nostra discussione, i telefoni in una sottorete dedicata di una sede, 
il callmanager in una sottorete dedicata dell'altra sede.
Se i client sono in una unica sottorete, anche se i server fossero 
posizionati in mille sottoreti diverse eigrp non riuscir� a separare il 
traffico delle applicazioni nella direzione server-to-client (la pi� 
importante) perch� vede una unica destinazione, quindi al massimo bilancia 
tutto il malloppo su pi� link, ma non separer� mai i flussi dati da quelli 
erp.
Per fare ci� devi usare policy routing.
Detto questo Rizio ci ha spiegato che non intendeva fare una cosa del genere 
ma separare il traffico server-to-server dal resto (se ho capito bene), ma 
vale lo stesso discorso, o segrega i server in una sottorete dedicata in 
entrambe le sedi oppure deve usare il policy routing.
Ciao,
        Tosh.
 


Tosh, grazie mille della spiegazione.

 ciao
Ok, perciò le route-map non riesco proprio a togliermele dalle scatole :(
Va bene, grazie a tutti. Ora comincio a fare qualche prova controllata poi fra 
qualche gg vi allineo sugli sviluppi.
Per ora grazie mille a tutti, siete sempre preziosissimi


 poi fra qualche gg vi allineo sugli sviluppi.
A questo punto ï¿œ evidente che devi usare EIGRP + route-map. Ultima cosa:
un link molto interessante di Cisco in cui il policy-based routing viene 
integrato al tracking. Forse ti farï¿œ comodo! Buon lavoro!
http://www.cisco.com/en/US/tech/tk364/technologies_configuration_example09186a0080211f5c.shtml

 
http://www.cisco.com/en/US/tech/tk364/technologies_configuration_example09186a0080211f5c.shtml
 
Grazie mille, giï¿œ stampato e pronto sul tavolo da leggere :)


Cominciamo con i primi problemi :(
Come mai non funziona secondo voi così:
interface Vlan100
  description VOIP
  ip address 10.31.6.2 255.255.0.0
  ip policy route-map FORCE_ROUTING_VOIP
  standby 100 ip 10.31.6.1
  standby 100 preempt
!
access-list 101 permit ip any 10.16.0.0 0.0.255.255
!
route-map FORCE_ROUTING_VOIP permit 10
  match ip address 101
  set ip next-hop 10.0.7.1 !IP DI UNA DELLE DUE ETHERNET DEL 2811
La logica dovrebbe essere che tutti i pacchetti in ingresso nella vlan voip 
diretti verso la sede B dovrebbero usare come next hop il 2811 WAN.
Dove sto sbagliando ?



ciao Rizio,
vista cosi'  ad occhio, dovrebbe funzionare.
Assicurati che:
-la acl abbia dei match ( sh ip access-list 101 )
-il next hop sia raggiungibile (un bel ping)
-hsrp che vedo configurato sia active su quella macchina ( sh
standby )
altro per ora non mi viene in mente.


 Marco Rizzi
Grazie di tutto
