CiscoForums.it

Ciao a tutti,
ho una domanda riguardo ad una rotta eigrp che si comporta in maniera davvero strana.
Ho un catalyst 4510R come centro stella che gestisce diverse vlan e tutti i collegamenti verso una coppia di 1801 che hanno dei tunnel (uno per ogni router attraverso 2 provider differenti) verso una sede remota. Questa sede remota è collegata anche attraverso una frame-relay punto-punto con un 2811 anch'esso collegato al 4510.
Una delle vlan ha ip 10.30.3.1 con netmak 255.255.255.0 e fino ad oggi l'ho dichiarata attraverso l'unico processo eigrp presente sui dispositivi cisco della lan.

Da stamattina, senza apparente motivo se nel processo eigrp è dichiarata quella net il routing risulta sbagliato. Risulta sbagliato perchè dalla sede remota per arrivare al 4510 passano attraverso una terza sede remota che non centra nulla con quella rete. Se toglo la dichiarazione di quella net dal processo del 4510 tutto torna a posto.

Potete aiutarmi a capire perchè ?
Grazie in anticipo
Rizio

Cerco di riassumere tutto in uno schema che allego.
Queste sono le impostazioi relative all'EIGRP e alle VLAN del 4510:

router eigrp 10
redistribute static
eigrp event-logging
network 10.0.7.0 0.0.0.3
network 10.0.8.0 0.0.0.3
network 10.31.0.0 0.0.255.255
network 172.30.199.0 0.0.0.31
network 172.30.200.0 0.0.0.63
network 172.30.250.0 0.0.0.255
network 172.30.254.0 0.0.0.31
network 172.31.0.0
!
!
interface Vlan2
ip address 172.31.6.1 255.255.0.0
!
interface Vlan9
ip address 172.30.254.30 255.255.255.224
!
interface Vlan10
ip address 172.30.200.62 255.255.255.192
!
interface Vlan11
ip address 10.30.3.1 255.255.255.0
!
interface Vlan98
description VLAN 98 vs F0 2811 WAN
ip address 10.0.7.2 255.255.255.252
!
interface Vlan99
description VLAN 99 vs F1 2811 WAN
ip address 10.0.8.2 255.255.255.252
!
interface Vlan100
ip address 10.31.6.1 255.255.0.0
!
interface Vlan199
ip address 172.30.199.30 255.255.255.224
!
interface Vlan250
ip address 172.30.250.254 255.255.255.0

al volo e senza leggere piu' di tanto...prsticamente ad istinto...

finalmente, un utente che posta con criterio. Anche con un grafico topologico con i controca**i. Complimenti.

Allora il tuo e' un problema di suboptimal routing, come lo chiama cisco. Imposta le sedi remote come stub. Nel processo EIGRP delle sedi remote aggiungi:
in questo modo, se la topologia di rete dovesse cambiare, le sedi remote non verranno querate dal DUAL in caso di un link ridondante, evitando cosi' di passare per es. dalla B per raggiungere la sede C partendo da A.

Buon W.E.

ciao!

ciao a tutti e due e grazie delle risposte.

@ZOT: Riguardo al "no auto-summary" perchè dici che il problema sia lì ? Tieni presente che il problema mi si è scatenato venerdì mattina senza apparente motivo e la configurazione eigrp non la cambiavo da tempo. Poi non potrei "summarizzare" perchè ho altre reti 10.x.x.x sparse per i router

@INTEL: Per lo stub routing credo sia un problema perchè gli altri router sono comunque proncipali per le sedi remote e a loro volta distribuiscono informazioni per cui il 4500 risulterebbe a sua volta uno "stub"... non sò (e grazie per i complimenti, senza quella mappa sarei perso )


Più che altro temo che il problema possa essere l'oggetto chiamato VPN-ITALY-01 che, pur avendo un corretto instradamento verso la vlan 11 temo abbia delle route map e dei nat moooolto vecchi che gli fanno cambiare politica di routing.
Ora indago meglio lì ed eventualmente vi ridisturbo.

Grazie di tutto intanto
Rizio

zot ha scritto:al volo e senza leggere piu' di tanto...prsticamente ad istinto...

Codice: Seleziona tutto

router eigrp 
no auto-summary

Avevi ragione !!!!!!!
Il problema era proprio lì !!! Sul fatto che NON c'era !!!
Nel 4500 centro stella della sede principale era attiva l'auto summarization con tutto quello che ne consegue !!!
Aggiunto il "no auto-summary" e la rotta 10.30.3.0 0.0.0.255 e tutto è andato a posto.

Grazie mille
Rizio

E' classico di reti che si evolvono e complicano senza uno studio approfondito iniziale......

zot ha scritto:E' classico di reti che si evolvono e complicano senza uno studio approfondito iniziale......

Si, sto cercando di rimettere un pò d'ordine dopo anni di evoluzione senza regole da parte di consulenti (bravissimi davvero, però ovviamente esterni) ed è un pò un bagno di sangue....
anche se ti dirò che sono stato "fregato" da un upgrade di ios in questo caso !
Ho un sistema di revisione delle config dei vari apparati di rete e ho verificato che in passato la voce "no auto-summary" c'era, poi, magicamente, quando ho fatto l'upgrade alla 12.2(54)SG1 me l'ha eliminata (probabilmente perchè in quella versione era di default) e io non me ne sono accorto !!!!
E' sempre una sbadataggine mia però mi fà un pò arrabbiare vedere che Cisco mi aiuta così !!!

In ogni caso grazie ancora dell'hint.
Rizio

Rizio ha scritto:
@INTEL: Per lo stub routing credo sia un problema perchè gli altri router sono comunque proncipali per le sedi remote e a loro volta distribuiscono informazioni per cui il 4500 risulterebbe a sua volta uno "stub"... non sò (e grazie per i complimenti, senza quella mappa sarei perso )

ehm no... per sede remota intendo proprio il router finale, che parla solo con l'hub. E' best practice cisco impostare suddetti router come stub. Vedo se riesco a spiegarmi meglio in base alla tua mappa:

per es:

Sede E, F e G etc. comunicano solamente con il loro HUB (confermi? almeno secondo la mappa). In questo caso, suddette sedi, impostandole come stub, non verranno mai querate dal dual quando c'e' un cambio topologico di rete (es. route flapping, cambio di rotta, interface up/down, etc.) e non propagano ulteriormente le query packets di EIGRP. Inoltre, non verranno mai usati come 'transit-network', come e' gia' successo a te.

Sono sicuro, che se farai una prova in un ambiente di test (es. GNS3) anche con solo 3-4 istanze router, il routing funzionera' anche senza disabilitare l'auto-summary. (sempre prendendo la tua rete come base). Disabilitare l'auto-summary non sempre e' buona cosa e vedendo la tua mappa (almeno dagli indirizzi riportati), l'indirizzamento mi pare abbastanza gerarchico da poterlo lasciare abilitato. A conferma di cio', come hai detto te:

Rizio ha scritto:... Tieni presente che il problema mi si è scatenato venerdì mattina senza apparente motivo e la configurazione eigrp non la cambiavo da tempo. ...

Probabilmente ci sara' stato qualche cambiamento topologico che ha triggerato un ricalcolo del routing. Le sedi remote non essendo impostate come stub sono state 'viste' da EIGRP come transit-network.

ciao!

intel ha scritto:Sede E, F e G etc. comunicano solamente con il loro HUB (confermi? almeno secondo la mappa). In questo caso, suddette sedi, impostandole come stub, non verranno mai querate dal dual quando c'e' un cambio topologico di rete (es. route flapping, cambio di rotta, interface up/down, etc.) e non propagano ulteriormente le query packets di EIGRP. Inoltre, non verranno mai usati come 'transit-network', come e' gia' successo a te.

Capisco, la logica non è sbagliata ma ci sono come implicazioni l'utilizzo delle frame-relay a cui alcune sedi sono collegate (es la sede B, la sede C e la sede J). perciò in realtà per quelle sedi in cui c'è uno sbocco in FR non mi dispiacerebbe se venissero usate come backup route in caso di guasto di una determinata connessione.

intel ha scritto:Sono sicuro, che se farai una prova in un ambiente di test (es. GNS3) anche con solo 3-4 istanze router, il routing funzionera' anche senza disabilitare l'auto-summary. (sempre prendendo la tua rete come base).

L'idea di fare una prova con GNS è buona, devo solo riuscire a raccimolare il tempo per mettere in piedi l'ambiente di test.
Riguardo all'auto-summary ormai ho risolto così, per ora va bene.

intel ha scritto:Probabilmente ci sara' stato qualche cambiamento topologico che ha triggerato un ricalcolo del routing. Le sedi remote non essendo impostate come stub sono state 'viste' da EIGRP come transit-network.

Si, probabilmente sarà così.... però se lo odio EIGRP quando fà così.

Rizio

Bella discussione....premetto che non ho molta esperienza di EIGRP (quando posso uso OSPF)e che non mi sono messo a calcolare le rotte e subnettig di Rizio, pero' ritengo stia proprio qua l'inghippo:

intel ha scritto: .............abbastanza gerarchico ..............

Se ho una struttura dove le gerachie sono rispetatte perfettamente allora e' cosa buona e giusta lasciare abilitato l'auto summary."Abbastanza" non e' sufficente a garantirsi sempre il miglior path possibile.Questo proprio per il fatto che dai link state EIGRP non eredita la caratteristica di conoscere TUTTA la tipologia di rete con relativi costi dei Link.

Lavorando con Cisco,spesso si e' costretti ad usare EIGRP e sono d'accordo che si debbano dichiarare gli stub router..ma nel caso del nostro amico i router VPN-ITALY-05 e VPN-ITALY-06 non potrebbero essere considerati degli stub...giusto?

eh zot.. io quei due router li considero stub, perche' a parte la connessione reciproca p2p, hanno solo il path verso l'hub. Non ha senso farli considerare da EIGRP come transit network... perche' se accadesse cio', tutto il traffico potrebbe passare per la FR.. e poi? Se si congestionasse? Probabilmente non so' spiegarmi io, qui' c'e' un draft a riguardo dello stub routing con EIGRP: http://www.cisco.com/en/US/docs/ios/12_ ... rpstb.html

anyway, ho detto "abbastanza gerarchico" perche' da quello che vedo dalla mappa, l'addressing mi pare corretto. Se poi ci sono appunti non visibili rispetto alla real-life, non posso saperlo ^_^

In ogni caso, non per portar sfiga (anzi, spero che non accada) ma credo che il problema di Rizio si ripresentera' al prossimo rilancio del DUAL. Unico modo imho e' impostare le sedi come stub e lasciare a default VPN-ITALY-01,02,03,04 e tutti quei router che ovviamente fanno da transito!


ciao!

P.S. Il summary e' un'altra feature che aiuta ad evitare le rotte in SIA (stuck in active) e lo scope limit delle query EIGRP che comportano il suboptimal routing (come nel caso di questo 3d).

P.P.S. bella discussione sì.. peccato che non c'e' una sezione only R&S

intel ha scritto:eh zot.. io quei due router li considero stub, perche' a parte la connessione reciproca p2p, hanno solo il path verso l'hub. Non ha senso farli considerare da EIGRP come transit network... perche' se accadesse cio', tutto il traffico potrebbe passare per la FR.. e poi? Se si congestionasse? .............................
.................... quello che vedo dalla mappa, l'addressing mi pare corretto. .............
..................
P.P.S. bella discussione sì.. peccato che non c'e' una sezione only R&S

Tralasciando il discorso di backup,impostandoli come stub, se il router I perdesse connettivita' verso l'HUB sarebbe tagliato fuori.
Non dovrebbe ,comunque, intervenire la metrica ad evitare il default e relativa congestione dei link FR?
Non e' che c'e' qualche link che ogni tanto "perde colpi" o parametri bandwidth e/o metric sballati e/o mancanti?
Ho guardato con piu' attenzione lo schema di Reizo,ma temo che manchino molti pezzi di "real life" .
Ribadisco che anche secondo me tutti i router "da cui non si puo' andare da nessuna parte" debbano essere dichiarati stub.
D'accordo che il no auto-summary potra' causare rotte in SIA ,ma abilitandolo,invece,(se non c'e' un progetto preciso dietro)si possono rischiare situazioni come quelle di Reizo o peggio.
In merito : http://www.cisco.com/en/US/tech/tk365/t ... fexternals
Si anche a me manca molto una sezione R&S ......secondo me andrebbero rifatte...

zot ha scritto:eh zot.. io quei due router li considero stub, perche' a parte la connessione reciproca p2p, hanno solo il path verso l'hub. Non ha senso farli considerare da EIGRP come transit network... perche' se accadesse cio', tutto il traffico potrebbe passare per la FR.. e poi? Se si congestionasse?

Non metterei in stub quei 2 router perchè ho creato apposta il tunnel p2p tra loro affinchè potessero "usarsi" reciprocamente in caso di caduta di un link del primo (guardandoci bene l'unica sede a cui torna comodo questo discorso è la sede J perchè è l'unica con 2 uscite verso la sede principale, se cadesse la sua FR verso la sede Principale potrebbe usare il Tunnel 8 attraversando l'altra sede per arrivare in sede)
Volendo oltretutto analizzare a fondo questo piccolo pezzo di rete c'è comunque un errore; tutti e due i tunnel della sede I e J sono intestati sullo stesso apparato in sede perciò se mi cadesse quello lascerei a piedi tutte e due le sedi, devo spostare uno dei 2 tunnel sul VPN-ITALY-01 altrimenti perdo ridondanza.... ma questo è un altro discorso (garzie comunque di avermi portato a questa considerazione, è davvero utile questa discussione).
Riguardo alla congestione della FR da J alla sede direi che possa valere lo stesso discorso no ? Perciò se dovessi mettere in stub un apparato al massimo potrei mettere quello della sede J che, paradossalmente ha 2 vie per raggiungere la sede principale ma se dovesse cade la linea sulla sede I questa non raggiungerebbe nè la sede principale nè J.
Da qui risulta che è perciò inutile permettere il transito attraverso J perchè avverrebbe solo in caso di erronea distribuzione di pesi EIGRP, corretto ? Confermate la mia ipotesi ? (sperando di essere riuscito a spiegarmi)

intel ha scritto:Tralasciando il discorso di backup,impostandoli come stub, se il router I perdesse connettivita' verso l'HUB sarebbe tagliato fuori.

Corretto, è la considerazione che mi ha portato al ragionamento di qui sopra.

intel ha scritto:Non dovrebbe ,comunque, intervenire la metrica ad evitare il default e relativa congestione dei link FR?

Perchè ? Non capisco ? In caso di congestione EIGRP se ne accorge ?
(scusate le domande stupide ma alcune lacune me le porto dietro a causa di un percorso formativo non propriamente "canonico")

intel ha scritto:Non e' che c'e' qualche link che ogni tanto "perde colpi" o parametri bandwidth e/o metric sballati e/o mancanti?

Riguardo a questo ho cercato di essere più diligente possibile, le uniche informazioni che mancano nello schema riguardo al bandwith sono perchè non ho io il router in gestione e non potendoci entrare non posso verificare

intel ha scritto:Ho guardato con piu' attenzione lo schema di Reizo,ma temo che manchino molti pezzi di "real life" .

A cosa ti riferisci ? Se posso integro volentieri per approfondire l'argomento che, personalmente, ritengo molto interessante.

intel ha scritto:D'accordo che il no auto-summary potra' causare rotte in SIA ,ma abilitandolo,invece,(se non c'e' un progetto preciso dietro)si possono rischiare situazioni come quelle di Reizo o peggio.

Il mio problema è nato proprio perchè non era abilitato, nel senso che un aggiornamento di IOS lo aveva impostato per default e nel cercare di risolvere un altro problema sono tornato alla versione precedente dell'ios (la 12.2.(53)SG1 che non l'aveva abilitato di default perciò mancava e mi venivano summarizzate in maniera errata.
Io non riesco a vederla come una features, sarò "all'antica" ma mi sembra corretto che ogni rotta venga dichiarata con la netmask che ha e senza essere summarizzata.

Rizio

Rizio ha scritto: Io non riesco a vederla come una features, sarò "all'antica" ma mi sembra corretto che ogni rotta venga dichiarata con la netmask che ha e senza essere summarizzata.

Rizio

ehm... concetto totalmente errato. Summarizzare porta ad avere una routing table piu' piccola, meno spreco di risorse, di update e soprattutto un'immagine di rete piu' "fluida". Una rete dietro summary che flappa non verra' mai ricalcolata da un segmento di rete dall'altra parte del network

Rizio ha scritto: Da qui risulta che è perciò inutile permettere il transito attraverso J perchè avverrebbe solo in caso di erronea distribuzione di pesi EIGRP, corretto ? Confermate la mia ipotesi ? (sperando di essere riuscito a spiegarmi)

EIGRP non sbaglia a distribuire la metrica. Se le sedi remote non sono impostate come stub ed il DUAL calcola in quel determinato momento che la rotta migliore e' passare attraverso una sede, l'unico modo per evitarlo e' appunto lo stub routing.

P.S. hai sbagliato a quotare ^_^

P.S. se imposti la sede I come stub, non viene tagliato fuori. Hai bisogno di ridondanza nella sede I e che passi da J oltre che dall'HUB? Basta lasciare a default J... (spero di essermi spiegato)

ciaoz

intel ha scritto:ehm... concetto totalmente errato. Summarizzare porta ad avere una routing table piu' piccola, meno spreco di risorse, di update e soprattutto un'immagine di rete piu' "fluida". Una rete dietro summary che flappa non verra' mai ricalcolata da un segmento di rete dall'altra parte del network

Questo è vero, non avevo pensato all'effetto flapping (da cui per altro sono colpito a causa di alcuni tunnel ballerini e che sto cercando di combattere con i keepalive sui tunnel come indicato in alcuni doc cisco)
Riguardo all'impegno di risorse ammetto che per come stiamo utilizzando la rete noi questo è un problema davvero marginale, soprattutto per le macchine che abbiamo a disposizione, sono tutte davvero poco impegnate, anzi, son proprio in ferie

Il problema del summarization nel mio caso ormai è senza soluzione perchè ho tutti i collegamenti punto-punto tra il centro stella (3750 o 4500) e i 2811 che gestiscono le FR delle varie sedi appoggiati su delle 10.0.x.x perciò se lascio la summarizzazione mi autocastro.... temo, corretto ?

intel ha scritto:EIGRP non sbaglia a distribuire la metrica. Se le sedi remote non sono impostate come stub ed il DUAL calcola in quel determinato momento che la rotta migliore e' passare attraverso una sede, l'unico modo per evitarlo e' appunto lo stub routing.

Capisco e posso essere d'accordo in linea di massima ed è per quello che sto cercando di mettere i pesi corretti su ogni tratta; vorrei che la topologia fosse cambiata solo nel momento in cui c'è un fault e non in caso di congestione. Ogni quanto vengono ricalcolate le rotte ?
(P.S. cosa intendi con DUAL ? )

intel ha scritto:P.S. hai sbagliato a quotare ^_^

Cacchio !!! Hai ragione, scusami se ho attribuito tutte le "colpe" a te Ho fatto un copia/incolla senza pensarci, scusatemi.

intel ha scritto:P.S. se imposti la sede I come stub, non viene tagliato fuori. Hai bisogno di ridondanza nella sede I e che passi da J oltre che dall'HUB? Basta lasciare a default J... (spero di essermi spiegato)

La sede I deve vedere J direttamente perchè usa servizi in quella sede (stiamo parlando di RDP perciò potrebbe passare dalla sede principale per averli ma sarebbe più "economico" (in termini di banda) arrivare direttamente a J. Tutti gli altri servizi li prende direttamente dalla sede principale perciò deve effettivamente vedere le 2 sedi direttamente (o per lo meno sarebbe più opportuno fosse così per il discorso di banda di cui sopra).
Ho capito bene cosa intendevi o ti ho risposto fischi per fiaschi ?
Cosa intendi

intel ha scritto:Basta lasciare a default J...

?
Mi confermi che I, impostato come stub router, non verrà mai attraversato per raggiungere la sede principale da J se a J cade la FR ? Perchè in questo caso torno al discorso di prima: mi torna utile I come transit network.

Rizio