Il blog sull'informatica

Spesso mi è capitato di avere a che fare con degli switch Cisco Catalyst 3750 configurati in Stack. Grazie a questa configurazione, due o più switch vengono visti, a livello logico, come un unico commutatore. Ciò significa che a tutto lo stack può essere associato un unico indirizzo IP di management.

Ma dove sta l'inghippo? Semplice: nel caso in cui si utilizzino dei sistemi di monitoraggio della rete (ad esempio nagios), il semplice ping non è sufficiente ad indicare che tutti gli switch di uno stack funzionano correttamente. Infatti, se uno di essi si guastasse, lo stack continuerebbe ad esistere e quindi ad essere raggiungibile a livello IP.

Come fare dunque per montorare l'effettivo stato di ogni singolo switch che costituisce lo stack? La risposta è semplice: SNMP.

In particolare, gli OID da utilizzare sono reperibili su questo server FTP anonimo (la directory è /pub/mibs/oid) ed il file di riferimento è CISCO-STACKWISE-MIB.oid

Per la precisione, gli OID che indicano lo stato di funzionamento relativo alle stackport degli switch che costituiscono uno stack sono i seguenti:

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5180 (per la prima porta del primo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5181 (per la seconda porta del primo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5183 (per la prima porta del secondo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5184 (per la seconda porta del secondo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5186 (per la prima porta del terzo switch)

1.3.6.1.4.1.9.9.500.1.2.2.1.1.5187 (per la seconda porta del terzo switch)

e così via.

Per verificare che gli OID sopra citati siano effettivamente supportati nell'ambito dello stack, potete utilizzare il comando snmpget (se avete a disposizione una linux box) oppure il tool Getif (nel caso in cui la vostra workstation sia una macchina Windows).

Configuriamo ora nagios. Per prima cosa definiamo il comando che ci permette di controllare lo stato dei vari switch:

nightfly@nightbox:~$ cd /etc/nagios-plugins/config

nightfly@nightbox:~$ sudo nano snmp.cfg

Inseriamo la seguente direttiva:

 'snmp_stack' command definition
define command {
command_name    snmp_stack
command_line    /usr/lib/nagios/plugins/check_snmp -H '$HOSTADDRESS$' -C '$ARG1$' -o '$ARG2$'
}

Ora che abbiamo definito il comando, aggiungiamo il servizio per il monitoraggio degli switch all'interno del file di configurazione che identifica lo stack:

nightfly@nightbox:~$ cd /etc/nagios3/conf.d

nightfly@nightbox:~$ sudo nano host-stack_nagios3.cfg

Inseriamo quanto segue:

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 1 Stackport 1
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5181
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 1 Stackport 2
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5181
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 2 Stackport 1
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5183
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 2 Stackport 2
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5184
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 3 Stackport 1
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5186
}

define service {
use                             generic-service         ; Name of service template to use
host_name                       Stack
service_description             Status Switch 3 Stackport 2
check_command                  
snmp_stack!vostracommunitystring!1.3.6.1.4.1.9.9.500.1.2.2.1.1.5187
}

Ovviamente sono partito dal presupposto che lo stack sia composto da 3 switch.

Salviamo il file e riavviamo nagios:

nightfly@nightbox:~$ sudo service nagios3 restart

e finalmente potremo monitorare l'effettivo stato degli switch di uno stack.

A presto.

Recentemente mi è capitato di avere a che fare con un tool per il monitoraggio della rete (weathermap). Questo tool, affinchè riesca a monitorare il traffico che interessa le varie interfacce di uno switch o di un router, effettua banalmente delle query SNMP.

Ora, la versione di tale protocollo abilitata sui vari device è la 2, ergo, utilizzando snmpwalk posso interrogare l'agente (e i vari subagent) in esecuzione sul dispositivo di mio interesse semplicemente digitando:

snmpwalk -v 2c -c <community string> <ip del dispositivo> 1.3.6.1.2.1.2.2.1.1

Direte voi... cos'è quel numero strano in coda alla query? Ebbene, quello è l'OID (Object Identifier) relativo alle interfacce del Catalyst. Ogni OID viene generato a partire dal cosiddetto SMI (Structure of Management Information), che presenta una struttura "ad albero". Per maggiore completezza, un esempio di SMI è riportato nella figura sottostante:

Il VTP (Virtual Trunking Protocol) è un protocollo di livello 2 proprietario Cisco, il cui scopo è quello di mantenere allineato il database in cui sono contenute le VLAN comuni a più switch. Affinchè la propagazione delle informazioni avvenga correttamente, è necessario che tutti gli switch facciano parte dello stesso dominio VTP.

Uno switch può operare in tre modalità VTP:

Server: crea, modifica e cancella le VLAN per l'intero dominio VTP e salva le informazioni relative alle LAN virtuali all'interno dell'NVRAM. E' la modalità di default per gli switch su cui viene abilitato il VTP;

Client: non può effettuare operazioni dirette sulle VLAN di dominio (ad esempio creazione o cancellazione) e non salva nell'NVRAM le informazioni inviate dal server, occupandosi esclusivamente di propagarle ai vicini;

Transparent: può eseguire il forwarding delle informazioni inviate dal server ma è caratterizzato dalla presenza di un database locale di VLAN, il quale non influenza il database di dominio.

Alcuni casi particolari di cui bisogna tener conto sono i seguenti:

1) l'aggiornamento inviato dal server ha un revision number inferiore rispetto a quello delle informazioni possedute dal client. In tal caso il client scarterà l'update proveniente dal server.

2) gli switch non riescono a mettere in sharing le loro VLAN. E' molto probabile che il nome di dominio VTP non coincida in tutti gli switch del network.

3) il pruning mode dello switch è attivo: ciò significa che lo switch non invierà traffico broadcast, multicast o unknown (ovvero verso un'indirizzo non presente all'interno della CAM) su tutti i trunk, evitando spreco di risorse e di banda.

Inoltre, poichè in un dominio VTP possono esserci più server, si potrebbe verificare uno scenario del tutto sconveniente, in cui viene aggiunto uno switch che opera in modalità server e che possiede un revision number inferiore rispetto a quello dei server già attivi. Ciò farebbe in modo che sull'intero dominio VTP tutte le VLAN precedenti vengano sovrascritte da quelle presenti nel database del server appena aggiunto. Si potrebbe evitare ciò semplicemente aggiungendo una password nell'ambito dello stesso dominio VTP.

Per ciò che concerne la configurazione di tale protocollo, alcuni comandi utili sono i seguenti (per il server):

Switch1#vlan database

configuro il nome del dominio:

Switch1(vlan)# vtp domain CCNA

dichiaro le VLAN che dovranno essere propagate agli altri switch:

Switch1(vlan)# vlan 2 name Administration
Switch1(vlan)# vlan 3 name Students

configuro la password VTP:

Switch1(vlan)# vtp password Cisco

Nell'ambito del client mi basterà digitare:

Switch2#vlan database

dichiaro espressamente che lo switch deve operare in modalità client:

Switch2(vlan)# vtp client

configuro la password VTP:

Switch1(vlan)# vtp password Cisco

ed infine configuro il nome del dominio:

Switch2(vlan)# vtp domain CCNA

Per ciò che concerne la diagnostica possiamo digitare:

Switch# sh vtp status

il cui output è simile al seguente:

VTP Version                     : 2
Configuration Revision          : 247
Maximum VLANs supported locally : 1005
Number of existing VLANs        : 33
VTP Operating Mode              : Client
VTP Domain Name                 : Lab_Network
VTP Pruning Mode                : Enabled
VTP V2 Mode                     : Disabled
VTP Traps Generation            : Disabled
MD5 digest                      : 0x45 0x52 0xB6 0xFD 0x63 0xC8 0x49 0x80
Configuration last modified by 0.0.0.0 at 8-12-99 15:04:49

Switch# sh vtp counters

che mostra tutta una serie di statistiche associate allo scambio di pacchetti nell'ambito del protocollo in questione, ad esempio:

VTP statistics:
Summary advertisements received: 7
Subset advertisements received: 5
Request advertisements received: 0
Summary advertisements transmitted: 997
Subset advertisements transmitted: 13
Request advertisements transmitted: 3
Number of config revision errors: 0
Number of config digest errors: 0
Number of V1 summary errors: 0
VTP pruning statistics:

Trunk            Join Transmitted Join Received    Summary advts received
from on-pruning-capable device
---------------- ---------------- ---------------- ---------------------------
Fa5/8             43071            42766            5

Il post termina qui, a presto.

NB: tali comandi si riferiscono a CatOS.