Introduzione
In questo periodo della mia vita lavorativa, sto affrontando diversi progetti basati su SPBm ( Fabric ) di Extreme Networks.
Il protocollo Shortest Path Bridging ha diversi vantaggi rispetto alle reti tradizionali , uno di questi è la facilità e l’efficienza nel trasporto di un L2 attraverso una rete anche molto complessa.
Le L2 VSN (Virtual Service Network) rappresentano il modo più semplice per estendere un dominio di Broadcast
Una vlan all’edge della rete può essere facilmente trasportata, mappandola, su un Service identifier ( I-SID):
Es : vlan i-sid 20 100
Con questo comando ho mappato la vlan 20 sul servizio 100 .
Avvenuto il mapping tra VLAN e I-SID , il protocollo IS-IS propagherà questa informazione a tutti i nodi della rete Fabric utilizzando i TLV. Di conseguenza tutti i nodi aggiorneranno il proprio Forwarding Data Base con questa informazione.
Questo articolo è dedicato a chi ha un po’ di background sulla Fabric ( SPBm) di extreme networks.
Come vengono inviati i broadcast
Quello che mi incuriosiva era cercare di capire come venissero inviati i broadcast all’interno del Fabric, un processo tutt’altro che banale. Il metodo utilizzato influisce notevolmente sulla scalabilità e sull’efficienza di questa tecnologia quando è necessario estendere i servizi L2.
Nelle reti tradizionali il traffico broadcast è inviato mettendo come indirizzo destinazione tutte FF, pensiamo ad una arp request.
Nella Fabric invece il traffico broadcast viene inviato come multicast .
L’indirizzo destinazione non sarà più FF, ma è una concatenazione tra il nick-name SPBM sorgente e l’I-SID, consentendo di ricostruire sempre a quale nodo della Fabric è connesso il client che ha generato il broadcast e a quale VLAN (I-SID) appartiene quel broadcast. In questo modo, è possibile inviare il broadcast solo ai nodi che hanno annunciato tramite TLV quell’I-SID.
Nello specifico dato un Nick-Name=e.44.01 e un I-SID 200100 :
La prima operazione è rendere multicast la prima parte dell’indirizzo facendo un & 3 con il nick-name , la seconda è trasformare la parte riguardante i-sid in esadecimale.
Il risultato finale sarà : e3:44:01:03:0d:a4
Ora mostriamo in pratica attraverso un esempio e un tracciamento come vengono inviati i broadcast nella fabric.
Esempio: Invio dei broadcast nella Fabric SPBm
Di seguito mostro il laboratorio GNS3 che ho impostato per fare questo test sull’invio dei broadcast :
Quando si crea un servizio e lo si associa ad un i-sid , contemporaneamente , viene popolato anche il multicast fib (Forwarding Information Base) necessario all’invio dei broadcast nella fabric , per esempio:
Prendiamo ad esempio lo switch2 e lo switch 3 :
– il nickname dello swich 2 è b.00.84 e 03:0d:a4 è l’esadicimale di 200100 , di conseguenza l’indirizzo destinazione, che usarà lo switch2 per inviare quel broadcast sarà b3:00:84:1e:84:b2 .
– il nickname dello swich 3 è 3.00.84 e 03:0d:a4 è l’esadicimale di 200100 , di conseguenza l’indirizzo destinazione, che usarà lo switch3 per inviare quel broadcast sarà 33:00:84:03:0d:a4.
Per capire meglio i tracciati wireshark , mostrati successivamente , riportiamo anche la tabella degli unicast fib , necessaria per l’invio degli unicast all’interno della fabric:
Vediamo ora il flusso di pacchetti di un ping tra il PC2 il PC3 che sono entrambi sulla vlan 100 (i-sid 200100), ponendo attenzione sui MAC ADDRESS utilizzati per l’invio dei pacchetti all’interno della Fabric:
Per inviare il ping dal PC2 ( 10.1.1.1) al PC3 ( 10.1.1.2) essendo sulla stessa vlan, il PC2 deve recuperare il mac address attraverso un ARP Request. Il mac address sorgente sarà il mac address dello switch 2 sulla Backbone vlan 4052 ( essendo 200100 pari, verrà scelta la 4052 come backbone vlan ) il mac address destinazione sarà un multicast costruito come abbiamo visto precedentemente. Questo pacchetto verrà ricevuto da tutti gli switch che hanno definito il servizio 200100.
Dopo questa operazione lo swich 3 popolerà la sua mac address table , inserendo un entry per il PC-2 collegato allo switch-2.
Arp reply sarà un unicast e quindi verranno utilizzati i due mac address degli switch nella backbone 4052. E’ un unicast perché lo switch3 conosce il mac address del PC 2:
Dopo questa operazione lo switch 2 popolerà la sua mac address table , inserendo un entry per il PC-3 collegato allo switch-3.
A questo punto entrambi gli switch, sanno reciprocamente dove sono mappati i mac address dei due PC. Di seguito il dialogo completo
A volte può capitare che i due switch non aggiornino le proprie tabelle mac , e quindi continuino ad utilizzare i multicast come destinazione, anche se il pacchetto trasportato è un unicast come in questo esempio :
Al pacchetto 85 i due pc, conoscono i rispettivi mac address, vedi le due colonne C-Source e C-Destination. I due switch invece inviano i pacchetti come unicast solamente al pacchetto 87. Di fatto i pacchetti 85 e 86,inviati a mac address destination multicast, vengono ricevuti anche da altri switch con i-sid 200100 , inutilmente.
Anche la Fabric fa Flooding … 😊
