OSPF tra Frame-Relay e ATM (FRF.8) - Pagina 2

MultiLayerGuy · 01-09-2003, 08:59

Guarda che l'eigrp è un protocollo di tipo hybrid che viene utilizzato al pari di BGP su più ASs.

Cmq sia una MAN altro non è che una WAN e come tale va trattatata nonostante la localizzazione "metropolitana".

In ogni caso per l'OSPF così come per tutti i protocolli di routing ti consiglio di guardare il sito CISCO e nella fattispecie la Guide relativa alla CCNP e al routing protocol.

Io lavoro sia con 75xx che cono 72xx CISCO ed inferiori quindi in linea di massima ho un'idea di ciò che si sta parlando.

Peccato che qui in Telecom l'OSPF venga utilizzato rarissimamente.

Se trovo un link specifico su OSPF ti faccio sapere. Saluti.

lucazzato · 01-09-2003, 13:04

si ma il problema non è sull'ospf ma sulla comunicazione in generale... anche inserendo tutte route statiche il traffico passa dagli atm in un senso... e cioè da ATM a FR (dal 7500 esce in atm passa attraverso una rete ATM e finisce in FR su un 2600)...
invece non va da FR all'ATM (ad esempio se provo a scaricare dal 7500 un file presente sulla rete del 2600 si blocca tutto... dopo due tre pacchetti dati inviati non arriva più l'ack)!!!

Boh

perchè in un senso si e nell'altro no???

perchè esistiamo???

dove andiamo???

queste sono le domande che ognuno di noi si pone!!!

Beh cmq sia sto nella merda!!!

bye

CH1CC0 · 01-09-2003, 13:30

Quote:

Originariamente inviato da MultiLayerGuy
Guarda che l'eigrp è un protocollo di tipo hybrid che viene utilizzato al pari di BGP su più ASs.

Cmq sia una MAN altro non è che una WAN e come tale va trattatata nonostante la localizzazione "metropolitana".

In ogni caso per l'OSPF così come per tutti i protocolli di routing ti consiglio di guardare il sito CISCO e nella fattispecie la Guide relativa alla CCNP e al routing protocol.

Io lavoro sia con 75xx che cono 72xx CISCO ed inferiori quindi in linea di massima ho un'idea di ciò che si sta parlando.

Peccato che qui in Telecom l'OSPF venga utilizzato rarissimamente.

Se trovo un link specifico su OSPF ti faccio sapere. Saluti.

Non per contraddirti, ma:
l'Eigrp è un protocollo di routing (hybrid) interno, al pari di RIP, RIP v2, IGRP, IS-IS ed OSPF. Solo che è, insieme a IGRP, un protocollo proprietario Cisco.
E' configurabile con sessioni separate (come gli AS del BGP), ma si tratta sempre di un protocollo interno.

Inoltre, da quello che so, non è vero che in Telecom si usi poco l'OSPF (conosco uno dei gestori della network e ne stavamo parlando proprio 2/3 gg fa che in telecom prediligono OSPF)...

CH1CC0 · 01-09-2003, 13:34

Quote:

Originariamente inviato da lucazzato
si ma il problema non è sull'ospf ma sulla comunicazione in generale... anche inserendo tutte route statiche il traffico passa dagli atm in un senso... e cioè da ATM a FR (dal 7500 esce in atm passa attraverso una rete ATM e finisce in FR su un 2600)...
invece non va da FR all'ATM (ad esempio se provo a scaricare dal 7500 un file presente sulla rete del 2600 si blocca tutto... dopo due tre pacchetti dati inviati non arriva più l'ack)!!!

Boh

perchè in un senso si e nell'altro no???

bye

Siccome ATM e Frame-relay lavorano in 2 modi diversi
ATM --> celle
FR --> pacchetti

Ci potrebbe essere qualche problema a livello di trasformazione packet-->cell?

O forse il 7500 si aspetta un "windowing" più grande...

Lo so che sto sparando, ma forse in mezzo a tante supposizioni ci può essere qualcosina di giusto...

Ps forse non ho visto bene, ma li hai postati i debug?

Cià

lucazzato · 01-09-2003, 16:19

no, non li ho più postati... sai che forse la storia del windowing non è male... come si fa a vedere le impostazioni della finestra del router 7500 e dei 2600... vedendo con lo sniffer ho visto che ogni tre pacchetti da 1514 byte arrivava un ack!!!

Se sai qualcosa in merito... beh grazie

CH1CC0 · 02-09-2003, 14:19

Prova a ridurre i pacchetti a meno di 1500byte...

è probabile che, con l'encapsulation (per trasformare il packet in cell o viceversa), si crei un problema di "giants" (pacchetti troppo grandi)...

Ora guardo come modificare il windowing (a memoria non me lo ricordo proprio

)

Cià

lucazzato · 02-09-2003, 14:29

si può essere, anche se dovrebbe fare tutto da solo, voglio provare voglio provare...

Ma penso che il window size si possa impostare solo su un pc... il router lavora fino al livello 3 no???
mentre la tecnica delle finestre a scorrimento fa parte del protocollo tcp!
Forse si pùo impostare solo sul pc...
un mio amico mi ha suggerito una chiave di windows2000 da modificare... tanto sono i pc che stabiliscono una comunicazione... quindi non dovrebbe essere sbagliato...
fatemi sapere se anche sul router bisogna impostare qualche parametro!!!

Grazie mille!!!

CH1CC0 · 02-09-2003, 16:12

Ora che mi ci fai pensare, hai perfettamente ragione.
Il windowing è un problema del tcp (layer 4).
Per la trasmissione di dati non hai assolutamente problemi... il problema è nell'invio di routing update da packet switching (2600 e FR) a cell switching (7500 e ATM).

Ricominciamo a pensare

lucazzato · 02-09-2003, 18:08

dopo prove e riprove ho constatato che un pò va un pò non va... a volte scarica a volte no... in tutte le direzioni... che rete di merda!!!!

come posso fare... come è possibile che la trasmissione di dati con ftp fa un pò come gli pare???

Qua centra l'ATM sicuramente.... ed io non so assolutamente una cicca di ATM... tranne qualche parametro da settare sui nodi... stupidaggini!!!

Beh grazie per l'aiuto e per ogni pensiero che vi viene in testa... fatemi sapere.

Io stasera stacco la spina e vado a ...

Ciao Ciao

lucazzato · 08-09-2003, 13:48

OSPF va.... chissà come ma va....

Avete capito bene... una mattina accendo le macchine come al solito...

va tutto (o quasi) da solo...
cavolo che i 7500 e i router cisco in generale siano forti lo sapevo... ma che risolvono i problemi da soli???

Non sto scherzando... ora vi spiego meglio...

se vi scaricate l'immagine che avevo postato all'inizio capirete meglio...

La sera precedente i signori dell'atm avevano smanettato sui nodi atm e ad un tratto, il mattino successivo, verfico che l 7500 aveva stabilito una connessione FULL con il RB2600... ma non con il RC2600... nel frattempo però l'RC2600 aveva anch'esso era in stato FULL verso l'RB2600.. (dalla topologia inizialmente postata avevo infatti inserito un altro link punto-punto tra l'RB2600 e l'RC2600), in questo stato la rete andava... perchè in ogni caso il 7500 raggiungeva l'RC2600 tramite l'RB..

mamma mia che casino, spero sia stato chiaro

...

ma non finisce qui... non era cmq corretto che il 7500 o l'RC2600, per inviarsi i pacchetti, instradassero i dati verso un link con una metrica più alta di quello che potevano realmente utilizzare!!!
Vedendo allora le differenze tra le configurazioni mi accorgo che sull'interfaccia atm del 7500 verso l'RB2600 c'è un mtu di 1500 mentre su quella verso l'RC2600 c'è un mtu di 1600...
modifico a 1500 ed ora tutti i link dei neighbor ospf sono FULL

.

ma mi chiedo... visto che il 7500 ha una porta atm perchè devo impostare l'mtu a 1500... non dovrebbero essere i nodi atm periferici (in figura "atm 2" e "atm 3") a occuparsi di frammentare correttamente il pacchetto???

Chissà cos'hanno cambiato quei tipi.... neanche loro lo sanno per quante prove hanno fatto... loro si stavano occupando del trasferimento dati da un lato all'altro della rete, ad esempio ftp o tftp, ed ancora ci sono molti problemi sotto questo aspetto....
Infatti succede che appena avviata la rete non ci siano problemi di trasferimento... riesco a fare il download e l'upload di un file tramite ftp... ma finito il primo tentativo al secondo va in tilt!!!
Come si ci fosse un buffer pieno... va in time-out!!!

Non sappiamo proprio come risolvere... non è un problema di connessione...ad Es. posso fare un ping lungo 3000 byte ed eseguirlo per 5000 volte da un punto all'altro della rete, nel frattempo visualizzare su un pc le immagini di un video server (che si trova sempre su un altro punto della rete) e non ci sono molti problemi (il ping non perde un pacchetto e il video server si vede discretamente)!!! purtroppo neanche l'tftp va bene... e questo esclude che si tratti solo di un problema "tcp" e non "udp"!!!

Pensate che debba configurare le policy sui router... tipo cir, bc, be, mincir.... etc???

Non mi va di incasinare di più le cose... questi tipi di argomenti si impostano già sui nodi atm.. e fra le altre cose penso proprio che sbaglino ad impostarli!!!

Vabbè per oggi vi ho annoiato abbastanza!!!
qui sotto ri-posto l'immagine della rete... sempre abbastanza semplificata (ma con l'aggiunta di un altro link Frame-Relay tra i due 2600).

Bye bye a tutti

lucazzato · 08-09-2003, 14:04

dimenticavo lo schizzo della rete!!!

01-09-2003, 13:04	#22
lucazzato Member Iscritto dal: Jun 2002 Messaggi: 34	si ma il problema non è sull'ospf ma sulla comunicazione in generale... anche inserendo tutte route statiche il traffico passa dagli atm in un senso... e cioè da ATM a FR (dal 7500 esce in atm passa attraverso una rete ATM e finisce in FR su un 2600)... invece non va da FR all'ATM (ad esempio se provo a scaricare dal 7500 un file presente sulla rete del 2600 si blocca tutto... dopo due tre pacchetti dati inviati non arriva più l'ack)!!! Boh perchè in un senso si e nell'altro no??? perchè esistiamo??? dove andiamo??? queste sono le domande che ognuno di noi si pone!!! Beh cmq sia sto nella merda!!! bye __________________ By Luca L3540 - TravelMate 280

01-09-2003, 16:19	#25
lucazzato Member Iscritto dal: Jun 2002 Messaggi: 34	no, non li ho più postati... sai che forse la storia del windowing non è male... come si fa a vedere le impostazioni della finestra del router 7500 e dei 2600... vedendo con lo sniffer ho visto che ogni tre pacchetti da 1514 byte arrivava un ack!!! Se sai qualcosa in merito... beh grazie __________________ By Luca L3540 - TravelMate 280

02-09-2003, 14:19	#26
CH1CC0 Senior Member Iscritto dal: Nov 2002 Città: Milano Messaggi: 5375	Prova a ridurre i pacchetti a meno di 1500byte... è probabile che, con l'encapsulation (per trasformare il packet in cell o viceversa), si crei un problema di "giants" (pacchetti troppo grandi)... Ora guardo come modificare il windowing (a memoria non me lo ricordo proprio ) Cià __________________ CiAO

02-09-2003, 14:29	#27
lucazzato Member Iscritto dal: Jun 2002 Messaggi: 34	si può essere, anche se dovrebbe fare tutto da solo, voglio provare voglio provare... Ma penso che il window size si possa impostare solo su un pc... il router lavora fino al livello 3 no??? mentre la tecnica delle finestre a scorrimento fa parte del protocollo tcp! Forse si pùo impostare solo sul pc... un mio amico mi ha suggerito una chiave di windows2000 da modificare... tanto sono i pc che stabiliscono una comunicazione... quindi non dovrebbe essere sbagliato... fatemi sapere se anche sul router bisogna impostare qualche parametro!!! Grazie mille!!! __________________ By Luca L3540 - TravelMate 280

02-09-2003, 16:12	#28
CH1CC0 Senior Member Iscritto dal: Nov 2002 Città: Milano Messaggi: 5375	Ora che mi ci fai pensare, hai perfettamente ragione. Il windowing è un problema del tcp (layer 4). Per la trasmissione di dati non hai assolutamente problemi... il problema è nell'invio di routing update da packet switching (2600 e FR) a cell switching (7500 e ATM). Ricominciamo a pensare __________________ CiAO

01-09-2003, 08:59	#21
MultiLayerGuy Bannato Iscritto dal: May 2003 Messaggi: 546	Guarda che l'eigrp è un protocollo di tipo hybrid che viene utilizzato al pari di BGP su più ASs. Cmq sia una MAN altro non è che una WAN e come tale va trattatata nonostante la localizzazione "metropolitana". In ogni caso per l'OSPF così come per tutti i protocolli di routing ti consiglio di guardare il sito CISCO e nella fattispecie la Guide relativa alla CCNP e al routing protocol. Io lavoro sia con 75xx che cono 72xx CISCO ed inferiori quindi in linea di massima ho un'idea di ciò che si sta parlando. Peccato che qui in Telecom l'OSPF venga utilizzato rarissimamente. Se trovo un link specifico su OSPF ti faccio sapere. Saluti.

02-09-2003, 18:08	#29
lucazzato Member Iscritto dal: Jun 2002 Messaggi: 34	dopo prove e riprove ho constatato che un pò va un pò non va... a volte scarica a volte no... in tutte le direzioni... che rete di merda!!!! come posso fare... come è possibile che la trasmissione di dati con ftp fa un pò come gli pare??? Qua centra l'ATM sicuramente.... ed io non so assolutamente una cicca di ATM... tranne qualche parametro da settare sui nodi... stupidaggini!!! Beh grazie per l'aiuto e per ogni pensiero che vi viene in testa... fatemi sapere. Io stasera stacco la spina e vado a ... Ciao Ciao __________________ By Luca L3540 - TravelMate 280

08-09-2003, 13:48	#30
lucazzato Member Iscritto dal: Jun 2002 Messaggi: 34	OSPF va.... chissà come ma va.... Avete capito bene... una mattina accendo le macchine come al solito... va tutto (o quasi) da solo... cavolo che i 7500 e i router cisco in generale siano forti lo sapevo... ma che risolvono i problemi da soli??? Non sto scherzando... ora vi spiego meglio... se vi scaricate l'immagine che avevo postato all'inizio capirete meglio... La sera precedente i signori dell'atm avevano smanettato sui nodi atm e ad un tratto, il mattino successivo, verfico che l 7500 aveva stabilito una connessione FULL con il RB2600... ma non con il RC2600... nel frattempo però l'RC2600 aveva anch'esso era in stato FULL verso l'RB2600.. (dalla topologia inizialmente postata avevo infatti inserito un altro link punto-punto tra l'RB2600 e l'RC2600), in questo stato la rete andava... perchè in ogni caso il 7500 raggiungeva l'RC2600 tramite l'RB.. mamma mia che casino, spero sia stato chiaro ... ma non finisce qui... non era cmq corretto che il 7500 o l'RC2600, per inviarsi i pacchetti, instradassero i dati verso un link con una metrica più alta di quello che potevano realmente utilizzare!!! Vedendo allora le differenze tra le configurazioni mi accorgo che sull'interfaccia atm del 7500 verso l'RB2600 c'è un mtu di 1500 mentre su quella verso l'RC2600 c'è un mtu di 1600... modifico a 1500 ed ora tutti i link dei neighbor ospf sono FULL . ma mi chiedo... visto che il 7500 ha una porta atm perchè devo impostare l'mtu a 1500... non dovrebbero essere i nodi atm periferici (in figura "atm 2" e "atm 3") a occuparsi di frammentare correttamente il pacchetto??? Chissà cos'hanno cambiato quei tipi.... neanche loro lo sanno per quante prove hanno fatto... loro si stavano occupando del trasferimento dati da un lato all'altro della rete, ad esempio ftp o tftp, ed ancora ci sono molti problemi sotto questo aspetto.... Infatti succede che appena avviata la rete non ci siano problemi di trasferimento... riesco a fare il download e l'upload di un file tramite ftp... ma finito il primo tentativo al secondo va in tilt!!! Come si ci fosse un buffer pieno... va in time-out!!! Non sappiamo proprio come risolvere... non è un problema di connessione...ad Es. posso fare un ping lungo 3000 byte ed eseguirlo per 5000 volte da un punto all'altro della rete, nel frattempo visualizzare su un pc le immagini di un video server (che si trova sempre su un altro punto della rete) e non ci sono molti problemi (il ping non perde un pacchetto e il video server si vede discretamente)!!! purtroppo neanche l'tftp va bene... e questo esclude che si tratti solo di un problema "tcp" e non "udp"!!! Pensate che debba configurare le policy sui router... tipo cir, bc, be, mincir.... etc??? Non mi va di incasinare di più le cose... questi tipi di argomenti si impostano già sui nodi atm.. e fra le altre cose penso proprio che sbaglino ad impostarli!!! Vabbè per oggi vi ho annoiato abbastanza!!! qui sotto ri-posto l'immagine della rete... sempre abbastanza semplificata (ma con l'aggiunta di un altro link Frame-Relay tra i due 2600). Bye bye a tutti __________________ By Luca L3540 - TravelMate 280 Ultima modifica di lucazzato : 08-09-2003 alle 14:02.

Strumenti
Mostra una versione stampabile Invia questa pagina per email