Archivi tag: 3750

Stack Catalyst 3750 ed SNMP

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$' -r '$ARG3$'
}

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!1
}

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!1
}

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!1
}

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!1
}

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!1
}

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!1
}

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.

Snmpwalk: visualizzare informazioni sulle interfacce di un Cisco Catalyst 3750

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:

Snmp.gif
Grazie alle MIB (Management Information Base), inoltre, è possibile identificare mediante una determinata stringa parte di un OID. La tabella seguente può far capire in modo abbastanza banale che cosa si intende per MIB:
OID                     MIB
1.3                      org
1.3.6                   dod
1.3.6.1               internet
1.3.6.1.1            directory
1.3.6.1.2            mgmt
1.3.6.1.3            experimental
1.3.6.1.4            private
1.3.6.1.4.1         enterprises
Quindi l’OID utilizzato nell’ambito della query effettuata mediante snmpwalk equivale a:
mgmt.1.2.2.1.1
Infine, occorre precisare che del protocollo in questione esistono ben 3 versioni: la 1 e la 2 piuttosto insicure, in quanto non cifrano la community string (neanche quando le query vengono effettuate da remoto attraverso Internet). La versione 3, invece, prevede un meccanismo di cifratura che la rende molto più sicura rispetto alle versioni precedenti.
Bye.

Abilitare SSH su switch Cisco Catalyst 3750

Prima di introdurre questa mini-guida, occorre precisare che non tutte le IOS Cisco supportano SSH. Nella fattispecie, quelle abilitate a ricevere connessioni mendiante Secure SHell riportano la dicitura K9 nell’ambito del filename.

Ma veniamo a noi. Per prima cosa, occorre creare la chiave RSA da utilizzare come fingerprint. Per fare ciò basta digitare il comando:

Switch(config)# crypto key generate rsa general-keys label ssh-fingerprint

Dopodichè digitiamo:

Switch(config)# ip ssh version 2

in modo da abilitare sul dispositivo la versione 2 del protocollo SSH (più robusta della 1).

Adesso definiamo username e password di accesso:

Switch(config)# username <vostro username> password <vostra password>

A questo punto disabilitiamo l’accesso telnet e consentiamo solo quello ssh usando il comando transport input (e già che ci siamo aggiungiamo username e password appena creati come credenziali per il login):

 Switch(config)# line vty 0 15
 Switch(config)# login local
 Switch(config-line)# transport input ssh
 Switch(config-line)# end

Infine salviamo la configurazione:

Switch# copy run start

ed il gioco è fatto.

A presto.