ARGOMENTO:

Salve,
nelle spiegazioni ed anche negli esercizi col packet tracer (per esempio il 6.4.2.4 che metto in allegato) viene effettuata la sommarizzazione delle rotte utilizzando il metodo descritto nel corso trovare i bit uguali nelle varie rotte candidate (quelle che dovrebbero puntare alla stessa interfaccia d'uscita) e quindi estrarre il net id (summarizzato) e la nuova netmask.
Questo algoritmo consente di ottenere una nuova rete che contenga tutte le reti di partenza ma non e' detto che la rete ottenuta contenga unicamente le reti di partenza, difatti nell'esempio allegato le rotte 2001:db8:5f73:a/64
2001:db8:5f73:b/64
2001:db8:5f73:c/64
2001:db8:5f73:d/64
vengono aggregate, utilizzando l'algoritmo ormai noto, in 2001:db8:5f73:8::/61 .
Osservo che di questa nuova aggregazione fanno parte anche spazi di indirizzamento non realmente implementati per esempio: 2001:db8:5f73:0::/64,2001:db8:5f73:1::/64,2001:db8:5f73:6::/64,2001:db8:5f73:7::/64, e che eventuali paccchetti legittimamente ruotati verrebbero scartati nei successivi passi di routing, questo modo genera inutile traffico icmp, oltretutto qualcuno facendo un design non molto intelligente della rete potrebbe attribuire quegli indirizzi non realmente utilizzati ad altre regioni.
Mi chiedo: non e' che per aggregare le rotte si dovrebbe meglio dire che le rotte di una tabella di istradamento possono essere aggregate se (e solo se) puntano alla stessa interfaccia di uscita (and) sono contigue (and) ed esauriscono tutto lo spazio indirizzi ottenuto usando l'algoritmo ormai molto noto?

Per assurdo esagero e genero un paradosso: utiizzando il ragionamento che ritengo poco accurato cosa mi impedirebbe (se non il buon senso) di aggregare queste due net 192.1.1.0/24 con 192.1.255.0/24 ottenendo la 192.1.0.0/16 e conseguentemente esaurendo uno spazio di 65534 indirizzi host mentre in realta' quelli reali sarebbero solamente 510?

roberto ulisse ha scritto: Mi chiedo: non e' che per aggregare le rotte si dovrebbe meglio dire che le rotte di una tabella di istradamento possono essere aggregate se (e solo se) puntano alla stessa interfaccia di uscita (and) sono contigue (and) ed esauriscono tutto lo spazio indirizzi ottenuto usando l'algoritmo ormai molto noto?

Ciao Roberto, la domanda è interessantissima davvero, perchè pone l'accento su alcuni aspetti che magari ad una prima analisi possono risultare sfuggenti in fase di studio del routing, sebbene in realtà i parametri stringeti da te pensati non siano affatto condizione necessaria. Per spiegarmi, mi avvarrò di tre topologie analizzate dal punto di vista di un ipotetico R1.

Prendiamo la prima parte:
possono essere aggregate se (e solo se) puntano alla stessa interfaccia di uscita


Come puoi vedere, potrei raggiungere la 192.168.0.0/22 sia uscendo dalla 0/0 che dalla 0/1. Scrivendo entrambe le rotte statiche su R1, a pari distanza amministrativa, il router bilancerebbe il traffico dividendolo sui due link.

Passiamo alla seconda:
sono contigue
Sebbene la contiguità possa sembrare un altro requisito sine qua non, pensa al seguente scenario:



Tralasciando l'avere delle /24 sulle punto-punto, il concetto è che, dal punto di vista di R1, continua ad essere possibile, e soprattutto valido, il poter raggiungere la 192.168.0.0/22 attraverso la FA0/0, a prescindere da come poi sia distribuito lo spazio più avanti.


Terzo punto (che risponde tanto quanto alla domanda con lo scenario IPv6):
ed esauriscono tutto lo spazio indirizzi ottenuto



Anche qui in realtà non sorge alcun problema nel momento in cui decido di sommarizzare la rete 192.168.0.0/22 senza aver implementato la 192.168.2.0/24
Il punto è che banalmente, se quella rete non esiste, non darà alcun problema. Se poi il dubbio fosse: ma se provassi a contattare l'host 192.168.2.25, arriverei magari inutilmente fino ad R4. Vero, però anche qui un paio di considerazioni: vanno considerati quelli che sono i benefici magari in termini di performance routing o di carico di lavoro della macchina (RAM occupata, CPU etc.) Ovviamente, con 5 reti non si ha assolutamente alcun vantaggio, ma se si pensa a scenari con migliaia di rotte in tabella, il vantaggio c'è eccome. Detto questo, contattare un host inesistente non è di per sè un grande problema. Anche perchè se non esistono, chi vorrà mai dialogare con le macchine della 192.168.2.0/24? Pensate poi all'utilizzo delle default: praticamente, qualche router inoltra il traffico a prescindere: nel caso, scarterà qualcuno più avanti

Non mi sono spiegato bene ed ho forse usato i termini con troppa liberta' quindi resettiamo e mettiamo un po d'ordine.
Oggetto della discussione e' l'algoritmo descritto nel corso ed utilizzato nell'esercizio col packet tracer messo in allegato nell'apertura di questo topic.
Detto algoritmo dovrebbe rispondere all'esigenza RIDURRE LE RIGHE DELLA TABELLA DI ROUTING in modo da ridurre il carico di lavoro della cpu dei router per l'operazione di lookup ed io aggiungerei anche per semplificare la lettura della stessa tabella, altro fatto che noi assumiamo implicitamente e' che per ogni pacchetto in analisi i risultati di istradamento devono essere gli stessi.
Quindi io vedo almeno questi due come vincoli di progetto di un algoritmo che semplifichi queste benedette tabelle.
Se siamo daccordo su questi punti allora le mie considerazioni fatte sono esatte.
Tu del resto nell'ultima parte del tuo intervento mi dai ragione e cito testualmente cio' che scrivi:

ma se provassi a contattare l'host 192.168.2.25, arriverei magari inutilmente fino ad R4. Vero, però anche qui un paio di considerazioni: vanno considerati quelli che sono i benefici magari in termini di performance routing o di carico di lavoro della macchina (RAM occupata, CPU etc.)


mi dai atto che con l'algoritmo descritto nel corso ed utilizzato con successo nell'esercizio sposti solamente il carico di lavoro dalla cpu di un router alla cpu di un'altro router piu' a valle che dovra' droppare il pacchetto, quindi HAI SOLO SPOSTATO IL JOB DA UNA CPU AD UN'ALTRA quali benefici? questo modo di semplificare quindi non da nessun vantaggio in termini di carico elaborativo per le cpu dei router perche' sposta il carico da un router ad un'altro (piu' a valle) mentre aumenta il traffico inutile.
Gli esempi che hai fatto nella prima parte del tuo intervento e le considerazioni che hai fatto non sono attinenti a quanto volevo esprimere inizialmente, forse non mi sono spiegato bene la prima volta, spero sia piu' chiaro adesso.
Quindi per tornare a noi ed all'esercizio col packet tracer ti invito a riflettere anche sul fatto che se gli spazi di indirizzi non utilizzati e cioe': 2001:db8:5f73:0::/64,2001:db8:5f73:1::/64,2001:db8:5f73:6::/64,2001:db8:5f73:7::/64 venissero utilizzati in altre regioni della rete visibili dal router dove si fa la summarizzazione secondo il criterio descritto nel corso e raggiungibili dal router (con le tabelle originali e non semplificate) attraverso la ::/0 dopo la semplificazione deto traffico verrebbe droppato.

Il problema di droppare il traffico "senza terminazione" fu uno dei motivi che porto' all'introduzione dell'analizzatore selezioni entranti nella ormai antica centrake di commutazione Siemens SMN/CC.
Detto hardware aveva il compito di analizzare tutte le selezioni entranti e tra le tante cose doveva abbattere tutte le connessioni entranti che avrebbero preso l'occupato piu' avanti.
Quindi e' storia vecchia ed era (ma ritengo lo sia ancora) buona pratica per la salvaguardia dei carichi elaborativi ed i carichi trasmissivi bloccare a monte e non far propagare traffico inutilmente.

Molto pragmaticamente tornando all'esercizio 6.4.2.4 del modulo 2 veniva richiesto di semplificare la tabella di routing e 'esercizio indica esplicitamente di fare cosi:

Part 1: Calculate a Summary Route for R1
When summarizing an IPv6 address, look at the prefix to determine where the address ends. In this case, a /64 ends at the fourth segment.

a. List the first four segments of each of the networks. Because the first three segments have the identical hexadecimal digits, there is no need to write them in binary. The fourth segment is different (:A, :B, :C, and : D); therefore, write the 16 bits for each in binary. Count the left-most matching bits to determine the prefix for the summary route.

2001:DB8:5F73:0000000000001010
2001:DB8:5F73:0000000000001011
2001:DB8:5F73:0000000000001100
2001:DB8:5F73:0000000000001101
b. In the fourth segment, the network addresses have the first 13 bits in common. Therefore, the summarized prefix is the 48 bits from the first three segments, plus the 13 bit from the fourth segment (or /61).

c. Copy the matching bits and fill in the remaining bits with zeros to determine that the summarized network address is 2001:0DB8:5F73:8::/61.


e facendo cosi prendi il 100% del punteggio e l'esercizio avalla un metodo ed un concetto a mio parere sbagliato,
io invece ritengo molto piu' giusto fare cosi:
aggregare
2001:DB8:5F73:0000000000001010
2001:DB8:5F73:0000000000001011
ottenendo
2001:DB8:5F73:0000000000000000/63
e poi aggregare
2001:DB8:5F73:0000000000001100
2001:DB8:5F73:0000000000001101
ottenendo
2001:db8:5f73:0000000000001100/63
in questo modo si riducono le righe della routing table ( le quattro righe si ridurrebbero a due, la meta') ma non si indirizzerebbe inutilmente traffico ai livelli inferiori sovraccaricando mezzi trasmissivi cpu ed inoltre .....omissis .... e' sufficiente gia solo quello che ho scritto per capire il vantaggio, tutto e' piu' ordinato e chiaro.

Scopo della sommarizzazione è (siamo tutti daccordo) quello di ridurre la grandezza delle tabelle di routing (con i benefici annessi).

Rispondo però punto per punto:

roberto ulisse ha scritto: altro fatto che noi assumiamo implicitamente e' che per ogni pacchetto in analisi i risultati di istradamento devono essere gli stessi.

Anche qui non è affatto vero, si può andare in bilanciamento come detto prima.

roberto ulisse ha scritto: Quindi per tornare a noi ed all'esercizio col packet tracer ti invito a riflettere anche sul fatto che se gli spazi di indirizzi non utilizzati e cioe': 2001:db8:5f73:0::/64,2001:db8:5f73:1::/64,2001:db8:5f73:6::/64,2001:db8:5f73:7::/64 venissero utilizzati in altre regioni della rete visibili dal router dove si fa la summarizzazione secondo il criterio descritto nel corso e raggiungibili dal router (con le tabelle originali e non semplificate) attraverso la ::/0 dopo la semplificazione deto traffico verrebbe droppato.

Vero, tuttavia la questione riguarderebbe una cattiva progettazione. Progettazione di un piano di indirizzamento gerarchico e sommarizzazione sono sempre intimamente legate. Si deve comunque tenere presente che esiste la regola del longest match (lo dico per completezza, il problema di progettazione resterebbe).

roberto ulisse ha scritto: quindi HAI SOLO SPOSTATO IL JOB DA UNA CPU AD UN'ALTRA

Beh, anche qui in realtà, considerando il funzionamento delle macchine Cisco, non è nemmeno un problema di CPU (le macchine lavorano infatti con il CEF quando devono inoltrare traffico). Il reale vantaggio consiste nella riduzione delle tabelle e nella riduzione delle eventuali update di routing (che richiederebbero CPU per l'elaborazione, invio di un maggior numero di update etc). Si stima genericamente molto più preziosa tale risorsa che non un pò di bandwidth sul link. Vero anche che possono esistere casi differenti per situazioni differenti, ma serebbero discussioni più indicate al design ed alla progettazione che non al funzionamento della sommarizzazione in sè (scopo dell'esercizio in oggetto). Dopodichè, invito comunque alla seguente riflessione: se gli host non esistono, non esistono, e dunque difficilmente ci si troverà effettivamente ad instradare traffico verso tali macchine. Si pensi anche ad esempio ad una rete /24 da 254 host teorici ove ne siano realmente presenti solo 10, o fossero pure presenti tutti, immagina siano semplicemente spenti: non è un problema instradare pacchetti per gli altri 244 fino al router che detiene tale network. Se poi in rete ci fosse traffico verso host fantasma (totalmente inesistenti), il problema non sarebbe la sommarizzazione, sarebbe qualcos'altro.


Parlando invece dell'operazione da te svolta sulle /63 è ovviamente matematicamente corretta:
La sommarizzazione delle reti ha però come dicevo prima intimamente a che fare con una progettazione accurata di un piano di indirizzamento gerarchico. Tuttavia, la conclusione nel dire che l'esercizio avalla un metodo sbagliato o trarre le conclusioni di cui sopra viene forse dal non aver ben presenti i punti di cui sopra. E' chiaro che con le 2 /63 non si avrebbe alcuna informazione "falsa" sull'instradamento (per inciso, se fossero solamente due righe di tabella di routing saremmo daccordo sulla maggiore accuratezza delle informazioni, 1 o 2 righe non spostano nulla, meglio dunque l'accuratezza), ma la tua domanda non verteva puramente sulla matematica, ma sulle implicazioni generali della sommarizzazione. Ebbene, quelle implicazioni vanno scartate. Dipende dai benefici che si vuole ottenere.

tu hai scritto:"
roberto ulisse ha scritto:
Quindi per tornare a noi ed all'esercizio col packet tracer ti invito a riflettere anche sul fatto che se gli spazi di indirizzi non utilizzati e cioe': 2001:db8:5f73:0::/64,2001:db8:5f73:1::/64,2001:db8:5f73:6::/64,2001:db8:5f73:7::/64 venissero utilizzati in altre regioni della rete visibili dal router dove si fa la summarizzazione secondo il criterio descritto nel corso e raggiungibili dal router (con le tabelle originali e non semplificate) attraverso la ::/0 dopo la semplificazione deto traffico verrebbe droppato.

Vero, tuttavia la questione riguarderebbe una cattiva progettazione. Progettazione di un piano di indirizzamento gerarchico e sommarizzazione sono sempre intimamente legate. Si deve comunque tenere presente che esiste la regola del longest match (lo dico per completezza, il problema di progettazione resterebbe)." e qui che volevo arrivare, difatti la mia obiezione e' che nell'esercizio si sarebbe dovuta (ed era possibilissimo ed anche piu' semplice) proporre una soluzione in modo da non dover fare riferimento a considerazioni sul design e sulla progettazione della rete a noi al momento sconosciute, del resto l'argomento dell'esercizio era la summarizzazione oppure in alternativa invece di proporre una soluzione che dovesse trovare giustificazioni in considerazioni sul design bastava scegliere range di indirizzi delle reti da summarizzare differenti.
Del resto tu stesso adduci le mie stesse stesse motivazioni di cui sopra per supportare in un'altro contesto una tua tesi e scrivi:" Vero anche che possono esistere casi differenti per situazioni differenti, ma serebbero discussioni più indicate al design ed alla progettazione che non al funzionamento della sommarizzazione in sè (scopo dell'esercizio in oggetto).", quindi tu stesso affermi che nello scopo dell'esercizio cose connesse al design ad alla progettazione della rete dovrebbero essere fuori dallo scopo dell'esercizio. e qui c'e' quello che volevo dire all'inizio.

A supporto di quanto detto prima ti cito una frase che ho scritto all'apertura del topic: oltretutto qualcuno facendo un design non molto intelligente della rete potrebbe attribuire quegli indirizzi non realmente utilizzati ad altre regioni. quindi immaginavo esistessero questioni connesse al design che influenzano il modo di summarizzare, ma lo scopo dell'esercizio doveva essere un'altro.