gns3/dynamips e mac-address-table vuota

CCNA, CCNP, CCSP, CCVP, CCIE e tutti gli altri percorsi di certificazione Cisco.

Moderatore: Federico.Lagni

Rispondi
GOo
n00b
Messaggi: 10
Iscritto il: lun 16 nov , 2009 10:57 pm

Ciao a tutti,
sto preparando il 642-813 e tramite gns3 sto provando una semplice topology con alcuni switch 3725 (C3725-ADVIPSERVICESK9-M 12.4).
Ultimamente mi sono accorto che la mac-address-table di qualsiasi switch rimane vuota nonostante STP e CDP siano attivi e comunichino regolarmente (testato tramite wireshark).
Se invece attivo anche una sola SVI per switch con IP address assegnato e faccio un ping verso un altro switch, la mac-address-table viene popolata ma si svuota nel giro di una ventina di secondi nonostante l'assenza di TC (l'aging time è sempre impostato a 300!).
La tabella ARP rimane invece popolata per diversi minuti.
Può essere un bug di dynamips/gns3 o mi sfugge qualcosa?
Avatar utente
spazianiv
Cisco enlightened user
Messaggi: 130
Iscritto il: lun 18 feb , 2013 11:51 pm
Località: Svizzera

Se stai utilizzando 3725 è corretto, la mac address table si popola tramite traffico passante attraverso lo switch o quello a lui indirizzato in unicast o multicast di livello 3.

I mac address utilizzati invece per cdp ed stp sono multicast di livello 2 corrispondenti a protocolli di livello 2, che restano sul link pertanto lo switch non ha necessità di imparare i mac sorgenti che hanno generato quel traffico in quanto non è prevista una risposta unicast a quei messaggi. Si tratta di un'ottimizzazione del processo di apprendimento.

CCIEx3 #35471 R&S,SP,Sec - CCDE #2014::3
Network Engineer - Official Cisco Trainer
GOo
n00b
Messaggi: 10
Iscritto il: lun 16 nov , 2009 10:57 pm

spazianiv ha scritto:Se stai utilizzando 3725 è corretto, la mac address table si popola tramite traffico passante attraverso lo switch o quello a lui indirizzato in unicast o multicast di livello 3.

I mac address utilizzati invece per cdp ed stp sono multicast di livello 2 corrispondenti a protocolli di livello 2, che restano sul link pertanto lo switch non ha necessità di imparare i mac sorgenti che hanno generato quel traffico in quanto non è prevista una risposta unicast a quei messaggi. Si tratta di un'ottimizzazione del processo di apprendimento.
Ti ringrazio, tutto molto chiaro. Non capisco però perchè debba flushare MAC address appresi via traffico layer 3 (ping) soltanto dopo una decina di secondi invece che 300.

In ogni caso il dubbio sul corretto funzionamento della cam mi era sorto osservando dei problemi con una semplice topology di 4 switch (R1 ed R2 distribution-layer e R3 ed R4 access-layer), interconnessi in trunk con una sola VLAN (VLAN1) e con R1 come Root:

Codice: Seleziona tutto

R1--------R2
|  \    /  |
|    \/    |
|   x  \   x
R3        R4

x=Blocked
R1=Root
testato con wireshark:

* R1 invia BPDU di tipo PVST+ e 802.1D verso R2.
* R1 invia BPDU soltanto di tipo PVST+ verso R3 ed R4.
* R2 invia BPDU di tipo PVST+ e 802.1D verso R3.
* R2 invia BPDU soltanto di tipo PVST+ verso R4.

1. R4 riceve soltanto BPDU PVST+ e, non vedendosi arrivare BPDU 802.1D per più del maxage, comincia ad annunciarsi come root.
2. A questo punto R1 invia due (due!) BPDU di tipo 802.1D anche verso R4 e R3 per poi riprendere ad inviare loro soltanto BPDU PVST+.
3. R4 invia una TCN verso R1, con il risultato di avere Topology Change per tutto il tempo.
4. Si ritorna al punto 1. ad ogni scadenza del maxage.

Ho provato a dare shutdown e no shutdown a ogni link, senza successo. Ho anche ricreato la topology su host diversi, sempre con lo stesso risultato.
Utilizzando invece link di tipo non trunk gli switch si scambiano normalmente BPDU 802.1d senza creare problemi. Allo stesso modo non si verificano problemi con tre switch interconnessi in trunk a triangolo con BPDU scambiate correttamente sia in 802.1d che in PVST+. Quindi i problemi sembra sorgano con 4+ switch interconnessi in trunk anche se con più di quattro non ho ancora provato.
Ora è possibile che mi sfugga sempre qualcosa ma proprio non capisco perchè alcuni switch decidano di inviare soltanto BPDU PVST+ verso alcuni altri, in modo apparentemente arbitrario.
Nessuno ha avuto esperienze simili con gns3/dynamips?
GOo
n00b
Messaggi: 10
Iscritto il: lun 16 nov , 2009 10:57 pm

Allora credo di aver risolto. Questi sono i passaggi che ho dovuto fare perchè la topology STP rimanga "converged", con BPDU 802.1d e PVST+ correttamente inviate:

1. aggiungere una VLAN ai vlan database (va bene anche tramite vtp).
2. assegnare la nuova VLAN come nativa per tutti i trunk.
3. disabilitare STP per la VLAN 1. A questo punto gli switch cominceranno a floodare indefinitamente TCN BPDU.
4. riabilitare STP per la VLAN 1 e riassegnarla come nativa. Il flooding dei TCN terminerà e inizieranno a passare BPDU 802.1d e PVST+, come mi sarei aspettato fin dall'inizio.
5. volendo è possibile anche eliminare la VLAN aggiunta in precedenza e lasciare solo la VLAN1.

Fatti tutti questi passaggi ho finalmente una topology STP converged!

Quello che mi chiedo: E` un comportamento normale?
A prima vista mi pare di no e cmq trovo strano non aver trovato informazioni a riguardo ne sul forum ne sul sito di gns3.
Rispondi