Archivi tag: switch

Hub vs switch: facciamo un po’ di chiarezza

Qualche tempo fa un mio collega (che svolge tutt’altra mansione rispetto alla mia e che quindi non è un tecnico), mi ha chiesto quale fosse la differenza tra hub e switch, dato che i primi sono ormai quasi del tutto irreperibili sul mercato (a meno di qualche aggeggio usato).

In soldoni, gli hub non sono altro che dei repeater “multiporta” (lasciatemi passare il termine), ovvero il traffico ricevuto su ciascuna porta viene inoltrato, indifferentemente, su tutte le altre. Toccherà poi alle schede di rete dei dispositivi connessi all’hub “capire” se il MAC address di destinazione del frame è il proprio (in questo caso lo accetteranno) oppure è associato a qualche altra macchina, scartandolo. L’ultima affermazione è vera solo ed esclusivamente se la suddetta scheda di rete non è configurata in modalità promiscua. Questa modalità, infatti, le consentirebbe di “accettare” tutti i frame, indifferentemente dal fatto che siano destinati ad essa o meno (e ciò è indispensabile nel caso in cui si voglia sniffare il traffico dei dispositivi connessi all’hub).

comparison

Ad esempio, per mettere un’interfaccia in modalità promiscua su una macchina Linux, occorre digitare il comando:

[root@linuxbox ~]# ifconfig <nome_interfaccia> promisc

Inoltre, tale modalità viene abilitata in automatico nel caso in cui sulla Linux box sia installato ed attivo un software che funge da NIDS, quale snort.

Un’altra peculiarità dell’hub riguarda la gestione dei cosiddetti domini di collisione. Infatti, tutti i dispositivi collegati ad esso faranno parte del medesimo dominio di collisione, mentre gli switch, per definizione, riescono a garantire un dominio di collisione ad-hoc per ciascuna porta di cui sono dotati. Per essere più precisi, gli switch sono caratterizzati dalla presenza di una memoria interna, in gergo CAM (acronimo che sta per Content Access Memory), in cui vengono memorizzate le accoppiate MAC address sorgente/porta su cui è stato ricevuto. Tale fase di popolamento della CAM avviene per gradi, ovvero man mano che i dispositivi collegati a ciascuna porta iniziano a trasmettere: quando lo switch vede come MAC sorgente un dato indirizzo L2 su una specifica porta, memorizzerà tale accoppiata all’interno della CAM. Successivamente, quando un frame recante uno specifico MAC di destinazione verrà ricevuto dallo switch, esso lo inoltrerà solo ed esclusivamente sulla porta in cui il dispositivo recante il suddetto MAC è collegato.

Il vantaggio di tale meccanismo di gestione del traffico è abbastanza chiaro: mettendo in comunicazione solo mittente e destinatario, si viene a creare una sorta di “mezzo trasmissivo” dedicato tra di essi, riducendo notevolmente (ma non eliminando completamente) il rischio di collisioni (almeno per quanto riguarda le reti half duplex in cui tale fenomeno può verificarsi). Tirando le somme, è proprio per questo motivo che lo switch “garantisce” un dominio di collisione dedicato per ciascuna porta di cui è dotato. Inoltre, lo sniffing del traffico risulta impossibile, a meno che su una delle porte dello switch sia configurato il cosiddetto port mirroring (che la Cisco chiama SPANCatalyst Switched Port Analyzer). Nella fattispecie, essa consente di inoltrare il traffico ricevuto (su una o più porte) su quella in cui è configurato il mirroring (solitamente utilizzo allo scopo l’ultima porta dello switch o le ultime 2). Va da se che anche in questo caso l’interfaccia del PC adibito a sniffer deve essere configurata in modalità promiscua.

Spero di aver fatto un po’ di luce sulla questione.

Alla prossima.

Gli IP Plan non aggiornati

In un ambiente enterprise mantenere un IP plan aggiornato è un’operazione alquanto ardua (soprattutto se coloro che devono gestire l’infrastruttura IT sono dislocati su sedi diverse).

 

networking.jpg

Quello che mi è capitato di recente mi ha fatto capire quanto un IP plan attendibile possa essere importante. Nello specifico, dopo aver installato e configurato un nuovo server, ho richiesto un indirizzo IP privato da poter assegnare alla suddetta macchina, senza creare eventuali conflitti con gli altri apparati già in produzione.

La prima cosa che ho fatto è stata quella di consultare l’IP Plan, scegliendo un indirizzo libero. Successivamente ho comunicato l’indirizzo in questione al sistemista network, il quale mi ha confermato la disponibilità dello stesso.

Per scrupolo ho effettuato un ping, il quale non ha fornito alcuna risposta, ergo tutti gli indizi mi lasciavano pensare che l’indirizzo scelto fosse effettivamente disponibile.

Fast forward di 30 minuti: una volta patchata la porta del server ed attestata sulla porta dello switch appartenente alla VLAN di riferimento, ho iniziato a ricevere degli ICMP echo reply a singhiozzo.

Tentando di connettermi via RDP alla suddetta macchina, con mio enorme stupore, ho notato che l’hostname del server su cui ero atterrato era differente da quello da me configurato, ergo vi era già una macchina che utilizzava l’indirizzo IP che credevo libero.

Nuovo giro di telefonate, altri check al volo e finalmente sono riuscito ad individuare un indirizzo IP effettivamente disponibile.

Contromisure

Per non incappare in una simile problematica è necessario aggiungere altri check al semplice ping ed alla consultazione dell’IP plan. Infatti, alcuni SO, quali Windows Server 2008 R2, hanno il firewall embedded configurato in modo da droppare le richieste ICMP. Quindi, per sincerarsi dell’effettiva disponibilità di un indirizzo, occorre dapprima consultare l’arp table dello switch su cui sono attestati i server della farm (generalmente trattasi di un core switch). Tale check va fatto a server disconnesso e partendo dal presupposto che non vi siano degli switch intermedi.

Per i Cisco, il comando da lanciare è il seguente:

Switch# sh arp | i <indirizzo IP>

Se l’arp table non restituisce alcun risultato significa che l’indirizzo IP scelto è libero. Ovviamente, se il server è stato disconnesso immediatamente prima di effettuare il suddetto controllo, è necessario aspettare che scada il cosiddetto aging time delle entry relative alla arp table (che varia in base alla tipologia ed al vendor dello switch, sempre che i valori impostati siano quelli di default).

Successivamente, a server connesso, si potrebbe individuare il MAC address della sua scheda di rete e controllare se l’associazione IP-MAC presente nella tabella ARP contiene il suddetto indirizzo fisico.

Infine, controllando le entry della CAM, ci si può sincerare che il MAC individuato sia stato letto sulla porta dello switch sul quale il server è effettivamente attestato.

Per i Cisco il comando da utilizzare è questo:

Switch# sh mac-address-table | i <indirizzo MAC>

Da notare che il MAC dovrà essere digitato nella forma aaaa.bbbb.cccc

In alternativa a tale procedura (che richiede comunque una certa familiarità con il networking), si potrebbe utilizzare un port scanner, ad esempio nmap.

Esiste anche una versione per Windows, scaricabile da qui, ed il comando da lanciare è il seguente:

nmap -P0 <indirizzo IP>

In particolare, con la flag -P0 sto imponendo al software di non lanciare dei ping preliminari per testare l’effettiva raggiungibilità dell’IP (evitando quindi i falsi negativi), procedendo immediatamente con la scansione delle porte.

State tranquilli, il port scan non è reato se non è seguito da dei tentativi di accesso non autorizzati (verificate comunque le policy aziendali prima di lanciarlo).

E’ tutto. Alla prossima.

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.

VTP (Virtual Trunking Protocol)

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, invece, 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.

Cisco port-channel

Ora, premesso che il port-channeling NON E’ argomento CCNA come ho sentito spesso dire (almeno per quanto riguarda l’esame 640-801), il seguente post ha lo scopo di chiarire a cosa serve effettivamente la feature in questione.

Nella fattispecie, mediante il port-channeling è possibile fare in modo che più interfacce vengano coinvolte da un unico flusso logico di informazioni (in pratica è come se costituissero un’unica interfaccia), semplificando notevolmente la vita agli amministratori, soprattutto in caso di guasti o nel caso in cui si vogliano evitare i loop senza la necessità di utilizzare il protocollo STP.

Ora, le condizioni necessarie per garantire il corretto funzionamento del port-channeling sono le seguenti:

– Stessa velocità e duplex (half/full) delle porte coinvolte (è impensabile creare un port-channel tra una FastEthernet ed una GibabitEthernet);

– Le porte devono appartenere alla medesima VLAN (se il port-channeling non viene utilizzato per un trunk);

– Nel caso in cui il port-channeling riguardi un trunk, è indispensabile che tutte le porte coinvolte siano caratterizzate dallo stesso tipo di trunk, abbiano le stesse VLAN native e permettano il traffico proveniente dalle stesse VLAN (identificate con il termine VLAN-allowed);

– Nel caso in cui venga utilizzato l’STP per la gestione dei loop, le porte coinvolte devono avere il medesimo costo nell’ambito delle VLAN di appartenenza;

– Sulle interfacce coinvolte non deve essere implementato il port-mirroring (SPAN), il cui scopo è quello di mandare una replica dei frame ricevuti su una data porta dello switch verso un’altra porta dello stesso switch a cui è collegato un sistema di monitoring (ad esempio un IDS).

Detto questo, occorre fare alcune precisazioni:

1) quasi tutti gli switch marcati Cisco permettono la creazione di un numero massimo di port-channel pari a 64;

2) Ciascun canale può coinvolgere dalle 2 alle 8 interfacce, in modo tale da favorire le operazioni di bilanciamento del traffico (load-balancing).

Per ciò che concerne proprio il load-balancing, è possibile implementare un metodo di bilanciamento diverso per ogni port-channel. I metodi applicabili possono basarsi su alcuni parametri riguardanti i livelli 2, 3 e 4 della pila ISO/OSI. Nella fattispecie, le discriminanti possono essere:

1) Indirizzo MAC sorgente – src-mac;

2) Indirizzo MAC di destinazione dst-mac;

3) Entrambi gli indirizzi MAC (sia sorgente che di destinazione) src-dst-mac;

4) Indirizzo IP sorgente src-ip;

5) Indirizzo IP di destinazione dst-ip;

6) Entrambi gli indirizzi IP (sia sorgente che di destinazione) src-dst-ip;

7) Porta (UDP o TCP) sorgente src-port;

8) Porta (UDP O TCP) di destinazione dst-port;

9) Entrambe le porte UDP o TCP (sia sorgenti che di destinazione) src-dst-port.

Per scegliere il metodo pù adatto alle nostre esigenze ed implementarlo sullo switch basta digitare il comando:

Switch(config)# port-channel load-balance <opzione>

Per quanto riguarda, invece, la possibilità di formare i port-channel in modo dinamico, possono essere utilizzati i seguenti protocolli:

– PAgP (proprietario CISCO);

– LACP 802.1AD

Per mettere in piedi il port-channel vero e proprio è necessario digitare:

Switch(config-if)# channel-group <identificativo numerico> mode <modalità di funzionamento>

nell’ambito del sottomenù delle interfaccie che devono essere coinvolte durante formazione del port-channel stesso.

Le modalità di funzionamento sono le seguenti:

on (non fa uso nè di PAgP nè di LACP 802.1AD, disabilitando di fatto la formazione dinamica dei port-channel);

off (fa in modo che la porta non venga coinvolta nell’ambito del port-channel);

auto (fa uso del PAgP in modalità passiva);

desirable (fa uso del PAgP in modalità attiva);

passive (fa uso del protocollo LACP in modalità passiva);

active (fa uso del protocollo LACP in modalità attiva).

Ma qual è la differenza esistente tra la modalità attiva e quella passiva? Semplicemente nel primo caso l’interfaccia rimarrà in attesa di ricevere pacchetti appartenenti al protocollo utilizzato (PAgP  o LACP). Nel secondo caso sarà proprio l’interfaccia ad inviare i pacchetti necessari alla formazione dinamica del port-channel.

Ora, per risparmiare tempo e fatica, è stato implementato un utilissimo comando che consente di settare i parametri necessari per la creazione del port-channel su tutte le porte coinvolte (o su alcune di esse). Tale comando è il cosiddetto range:

Switch(config)# interface range fa0/0 - 4

E, successivamente, il prompt dei comandi apparirà nel seguente modo:

Switch(config-range-if)#

Possiamo dunque digitare (ad esempio):

Switch(config-range-if)# channel-group 1 mode on

Infine, alcuni comandi che possono tornare utili per eventuali operazioni di troubleshooting sono i seguenti:

Switch(config)# sh interfaces port-channel <identificativo del group-channel>

oppure:

Switch(config)# sh etherchannel <identificativo del group-channel> summary

e ancora:

Switch(config)# test etherchannel load-balance interface port-channel <identificativo> ip <IP sorgente> <IP di destinazione>

A presto.