Case of Study CCNA Exploretion 2:Routing Protocols and Concepts

ciscoObiettivi

Realizzazione di una infrastruttura di rete per il Liceo Scientifico “Guglielmo Marconi” di Roma e la sua sede succursale di Frascati.

Scenario

Il Liceo Scientifico “Gugliemo Marconi” di Roma ha chiesto una consulenza alla Vostra Società per creare una infrastruttura di rete adatta ad ospitare i futuri studenti.

Le specifiche del progetto sono le seguenti:

  • La scuola dovrà ospitare Studenti,Docenti e Personale Amministrativo.
  • Per gli Studenti sono previste:
    1. 3 sezioni (A,B,C).
    2. ogni sezione sarà popolata da 5 classi (1°,2°,3°,4°,5°).
    3. gli studenti per classe saranno al massimo 20.
    4. Ogni sezione dovrà essere un indirizzamento indipendente.
  • Per i Docenti si prevede un numero massimo di 100.
  • Per il Personale Amministrativo non si supera il numero di 50 unità.
  • E’ necessario prevedere una server farm che a regime ospiterà 10 server per i servizi base (Mail Server,Web Server,FTP Server,DHCP Server…).
  • La scuola dovrà avere la possibilità di far accedere ad Internet i propri utenti.Bisognerà prevedere quindi la presenza di un collegamento verso l’ISP.
  • La sede distaccata di Frascati dovrà poter accogliere:
  • Una rete Studenti con 3 sezioni: D,E,F,per ogni sezione bisognerà ospitare 5 classi e ogni classe sarà formata da 20 studenti.
  • Una rete Docenti con un numero massimo di 100.
  • Il collegamento ad internet avverrà attraverso l’unico ISP disponibile.

Il collegamento principale tra le due sedi è realizzato a mezzo di una Fibra Ottica.

Si chiede di configurare gli apparati in modo tale che:

  • Le due reti abbiano connettività a mezzo del protocollo di routing OSPF.
  • Si preveda un collegamento di Backup che intervenga solo se si verifica un fault nel collegamento principale e/o nel protocollo di routing.
  • Si chiede di creare un piano di indirizzamento che faciliti l’annuncio di rotte sammarizzate.

Il Comitato tecnico del Liceo Scientifico richiede che venga presentata documentazione inerente al lavoro offerto.

La documentazione dovrà essere composta da :

  • Topologie logiche e fisiche.
  • Piani di indirizzamento.
  • Configurazione degli apparati che verranno messi in opera.

Case of Study CCNA Exploretion 1:Network Fundamentals

cisco

Case of Study CCNA Exploretion 1:Network Fundamentals

 

Obiettivi

Realizzazione di una infrastruttura di rete per il liceo scientifico “Guglielmo Marconi” di Roma.

Scenario

Il liceo scientifico “Guglielmo Marconi” di Roma ha chiesto una consulenza alla vostra società per creare una infrastruttura di rete adatta ad ospitare i futuri studenti.

Le specifiche del progetto sono le seguenti:

  • La scuola dovrà ospitare Studenti,Docenti e Personale Amministrativo.
  • Per gli Studenti sono previste:
    1. 3 sezioni (A,B,C).
    2. ogni sezione sarà popolata da 5 classi (1°,2°,3°,4°,5°).
    3. gli studenti per classe saranno al massimo 20.
    4. Ogni sezione dovrà essere un indirizzamento indipendente.
  • Per i Docenti si prevede un numero massimo di 100.
  • Per il Personale Amministrativo non si supera il numero di 50 unità.
  • E’ necessario prevedere una server farm che a regime ospiterà 10 server per i servizi base (Mail Server,Web Server,FTP Server,DHCP Server…).
  • La scuola dovrà avere la possibilità di far accedere ad Internet i propri utenti.Bisognerà prevedere quindi la presenza di un collegamento verso l’ISP.

Il Comitato tecnico del Liceo Scientifico richiede che venga presentata documentazione inerente al lavoro offerto.

La documentazione dovrà essere composta da :

  • Topologie logiche e fisiche.
  • Piani di indirizzamento.
  • Configurazione degli apparati che verranno messi in opera.

Funzionalità e Attributi di EIGRP

ciscoEGRP è un protocollo proprietario distance-vector con caratteristiche link-state ed include le seguenti caratteristiche:

-Una convegenza veloce
-Aggiornamenti parziali della tabella di Routing
-Diversi livelli di supporto rete
-L’uso delle comunicazioni multicast e unicast
-Supporto del VLSM

Neighbor table
Contiene gli indirizzi dei vicini router e l’interfaccia attraverso la quale
possono essere raggiunti.

Topology table
Contiene tutte le destinazioni pubblicate dai router vicini.

Routing table
Contiene i percorsi successivi dei router EIGRP.

Advertised Distance (AD)
E’nota anche come Reported Distance ed è il costo tra il prossimo router (next-hop) e la destinazione.

Feasible Distance (FD)
La minore metrica calcolata per raggiungere una rete destinazione
E’ il costo tra il router locale e il prossimo router (next-hop) più il next-hop router AD verso la destinazione rete.

Successor
Il router verso il quale devono essere inoltrati i pacchetti per raggiungere una certa rete.
Un successor è un router adiacente che ha un costo minimo percorso di una
destinazione (il più basso FD) che garantisce delle rotte senza loop.

Feasible successor (FS)
è un router di backup relativo ad una rotta già conosciuta e già associata ad un successor.
E’ un vicino che è più prossimo alla destinazione, ma non è il percorso a costo minimo;garantisce un ciclo senza topologia perché deve avere AD inferiore al FD del percorso attuale successore.Sono selezionati contemporaneamente come successori ma sono conservati nella tabella come backup per i percorsi successivi.
La tabella è in grado di mantenere più successori possibili per un destinazione.

Passive Route
Una rotta è considerata passiva quando il router non esegue il ricalcolo della rotta.

Active route
Una rotta è attiva quando è in fase di ricalcolo.

Login remoto ai demoni Quagga

Dovrete configurare i demoni in modo che ascoltino su tutte le interfacce e quindi impostare il controllo d’accesso nei rispettivi file di configurazione.Sotto Debian editate /etc/quagga/debian.conf per abilitare l’ascolto su tette le interfacce:

vtysh_enable=yes
zebra_options=" --daemon"
ripd_options=" --daemon"

Sotto Fedora,fate la stessa cosa nel file /etc/sysconfig/quagga

Aggiungete quindi le righe che seguono nei file di configurazione dei demoni(ripd.conf,zebra.conf,Quagga.conf),come in questo esempio relativo a zebra.conf

 

access-list localhost permit 127.0.0.1/32
access-list localhost deny any
access-list lan1 permit 192.168.1.0/24
access-list lan1 deny any
access-list lan2 permit 192.168.2.0/24
access-list lan2 deny any
!
line vty
access-class localhost
access-class lan1
access-class lan2

 

Cio abilita le l ogin solo da localhost e da due sottoreti locali.Ciascun Login ha la propria classe in modo da poterlo disabilitare commentando l’opportuna riga access-class.

 

Ora dovete riavviare Quagga.Sotto Debian usate questo comando:

# /etc/init.d/quagga restart

Sotto Fedora dovete riavviare ciascun demone separatamente:

# /etc/init.d/zebra restart
# /etc/init.d/ripd restart

Ora dovreste essere in grado di effettuare delle connessioni in telnet dalla LAN specificando un IP e una porta:

test@testpc:~$ telnet router 2601

Piccolissima nota vi chiederà una password,quella di default è disponibile all’interno del file Quagga.conf.I nomi in access-list, nel nostro esempio localhost,lan1 e lan2 sono arbitrari.L’esempio che è stato presentato è abbastanza complesso e controlla gli accessi a livello di sottorete.Potete semplificarlo inserendo tutto in un unica access-list:

 

access-list allowed permit 127.0.0.1/32
access-list allowed permit 192.168.1.0/24
access-list allowed permit 192.168.2.0/24
access-list allowed deny any
!
line vty
access-class allowed

 

 


1 … 31 32 33 34 35 … 38