SPB ondersteunt Multicast, hoe werkt dat?

Laten we beginnen met een wat vreemde vraag... hebben we Multicast echt nodig? Nou, er zijn de afgelopen jaren zeker meer services gekomen die een multicast scheme gebruiken om diensten te leveren aan de geabonneerde gebruikers en/of apparaten. Veel netwerkengineers hebben echter moeite met het implementeren van multicast. Eén kant van het probleem wordt veroorzaakt door het feit dat Multicast van origine geen onderdeel was van IP, dus er moesten aanvullende (en vaak complexe) protocollen zoals PIM of DVMRP worden toegevoegd om dit te ondersteunen. Om het nog ingewikkelder te maken is PIM, het meest gebruikte protocol, zelf afhankelijk van een Interior Gateway Protocol zoals OSPF om de netwerktopologie op te bouwen en routeringsinformatie te verstrekken.

En naarmate we meer en meer lagen aan protocol toevoegen, wordt het niet alleen complexer, maar ook de convergentietijd neemt toe. Daardoor wordt het moeilijker om het netwerk te troubleshooten en te schalen.

Dus kunt je gerust zijn als je iedere soort Multicastverkeer moet ondersteunen, bijvoorbeeld voor videodistributie, en je problemen hebt met PIM of een ander complex Multicast-protocol. Met Extreme Fabric Connect pluk je niet alleen de vruchten van SPB, zoals we in eerdere artikelen hebben besproken, maar krijg je ook de krachtigste Multicast-oplossing die er is! Zonder te overdrijven: hij schaalt niet alleen verder dan iedere andere multicast-oplossing op de markt; hij convergeert ook veel sneller en is veel eenvoudiger te implementeren.

Deze twee afkortingen maken de tekst voor mij makkelijker te schrijven, en voor jou makkelijker te lezen:

In het vervolg gebruik ik dus in dit artikel (en in toekomstige artikelen in onze serie ‘SPB voor beginners’) hoofdzakelijk de afkortingen L2VSN en L3VSN.

Het inschakelen van IP-multicast-ondersteuning in een SPB-netwerk is heel makkelijk. Laten we eens van dichtbij kijken hoe dit werkt. Allereerst moeten we stellen dat er twee ‘soorten’ multicast zijn:

Begrijpen hoe de eerste ‘soort’ werkt, helpt ons ook bij het begrijpen van de tweede ‘soort’.

Zoals eerder vermeld, is de SPB data plane gebaseerd op Ethernet, en werkt het net als Ethernet, met een paar uitzonderingen: er is geen broadcast en geen ‘flooding and learning’. Zoals iedere netwerkengineer weet, zijn we in een broadcastdomein afhankelijk van het broadcasten van verkeer om alles draaiende te krijgen. Met andere woorden, we moeten mechanismes zoals ARP ondersteunen.

Ieder L2VSN dat we in een SPB-netwerk bouwen, is een broadcastdomein, dus moeten we broadcast ondersteunen binnen ieder L2VSN. Dan vraag je je al snel af: ‘De SPB data plane ondersteunt geen broadcast, hoe wordt broadcastverkeer dan ‘gebroadcast’ in die L2VSN’s?’ Het antwoord is Multicast. Broadcast kun je zien als een speciaal soort Multicast, waar iedereen de Multicast ontvangt. Dus, als Multicast het antwoord is, hoe werkt het dan? Nou, dat is een beetje ingewikkeld, maar dit is ongeveer hoe het mechanisme eruit ziet:

Er wordt bij iedere I-SID (dat een virtueel layer-netwerk identificeert) een ‘shortest path tree’ berekend, vanaf iedere BEB-node (edge node) naar alle andere BEB-nodes die onderdeel zijn van dit specifieke virtuele netwerk. Dat is niets nieuws, maar het is belangrijk om te begrijpen dat er bij iedere I-SID vele shortest path trees kunnen zijn: één vanuit iedere BEB-node die deze I-SID heeft geconfigureerd.

Laten we eens kijken naar een netwerk zoals afgebeeld in Afbeelding 1 hieronder. We kijken naar een L2VSN met een I-SID-nummer van 200 dat wordt beëindigd op BEB1, BEB2, BEB3 en BEB4. Het betekent dat er vier shortest path trees zullen zijn: één geworteld in BEB1 (figuur 2), één geworteld in BEB2 (figuur 3) enzovoort.

Elke BEB-node maakt een (48-bits) groeps-MAC-adres (dat we vaak 'multicast MAC-adres' noemen) voor de boom die erop is geworteld. Het groeps-MAC-adres wordt gemaakt met behulp van het volgende eenvoudige algoritme:

3 ‘plus’ SPSourceID ‘plus’ I-SID-nummer, dat er als volgt uit zal zien:

Dit behoeft misschien wat meer uitleg:

Elke node heeft een unieke SPSourceID die wordt geleverd door de configuratie. (Opmerking: in IETF RFC6329/Extreme Networks-terminologie noemen we het ‘Nickname’ in plaats van 'SPSourceID'). De SPSourceID is 20-bits en gaat als volgt: x:xx:xx (hex), b.v. 0:40:01.

We beginnen met het plaatsen van 3 (binair 11) in bit 0 en 1 van octet 0. We stellen bit 2 en 3 in op 00 zodat dit een source-rooted shortest path tree is. (Onthoud: bit 0 = 1 betekent dat dit een groeps-MAC-adres is, bit 1 = 1 betekent dat dit een lokaal beheerd adres is).

Vervolgens 'voegen' we de SPSourceID 'toe', die de tweede nibble van het octet 0 vult, en de volgende twee bytes (octet 1 en 2).

Vervolgens zetten we het (24-bit) I-SID nummer van deze specifieke L2VSN in octet 3, 4 en 5.

Nog steeds lastig? Misschien helpt een voorbeeld. Terugverwijzend naar figuur 1 en 4:

Laten we aannemen dat we hebben besloten om BEB1 een SPSourceID = 0.40.01 te geven, BEB2 een SPSourceID = 0.40.02, BEB3 een SPSourceID = 0.40.03 en tot slot BEB4 een SPSourceID = 0.40.04.

Dus voor de L2VSN met het I-SID-nummer 200 (wetende dat decimaal 200 hex C8 is), zal BEB1 het volgende multicast MAC-adres maken:

Die wordt als volgt gelezen in hex:

03:40:01:00:00:C8

So far, so good. Maar hoe geeft dit ons de multicast-mogelijkheden? Nou, dat werkt als volgt:

Alle SPB-nodes hebben de SPSourceID van alle andere SPB-nodes in het netwerk geleerd. Dit betekent dat alle nodes die zich in de tree met het kortste pad voor een bepaalde I-SID bevinden, ook de SPSourceID van de hoofdnode van deze boom kennen. Met zowel de SPSourceID- als de I-SID-waarde kunnen ze het groepsadres samenstellen.

Dus voor de shortest path tree geworteld in BEB1, zullen de volgende nodes een groeps-MAC-adres = 03:40:01:00:00:C8 construeren en opslaan in hun multicast forwarding-database: BCB1, BCB3, BCB4, BEB1, BEB2, BEB3 en BEB4.

Evenzo zal BEB2 een groeps-MAC-adres construeren dat gelijk is aan 03:40:02:00:00:C8. En dat geldt ook voor BCB1, BCB2, BEB1, BEB3 en BEB4.

Hetzelfde geldt voor BEB3 en BEB4.

Opmerking: de nodes zullen hetzelfde doen voor alle L2VSN (=I-SID) waarvan ze deel uitmaken. Dus als BEB1 ook een L2VSN had met een I-SID = 10010 erop, zou het het volgende groeps-MAC-adres creëren voor deze specifieke L2VSN:

03:40:01:00:27:1A

(en dat geldt ook voor alle nodes die deel uitmaken van I-SID = 10010)

Dus uiteindelijk, wanneer (bijvoorbeeld) BEB1 een ARP-verzoek ontvangt op een UNI-interface die is toegewezen aan I-SID 200, zal het dit inkapselen in een nieuw Ethernet-frame, het bestemmings-MAC-adres gelijk stellen aan het multicast MAC-adres (=03 :40:01:00:00:C8), en het doorsturen naar NNI-interfaces die zich bevinden in de shortest path tree voor I-SID 200. De volgende nodes die dit frame ontvangen, inspecteren het bestemmings-MAC-adres; en aangezien het een multicast MAC-adres is, zullen ze het doorsturen naar alle NNI-poorten die deel uitmaken (branches) van de shortest path tree. En dus zal het frame worden gerepliceerd en gedistribueerd totdat het uiteindelijk wordt ontvangen door BEB2, BEB3 en BEB4. Omdat ze BEB-nodes zijn, zullen ze de outer/SPB Ethernet-header strippen en het originele Ethernet-frame (wat toevallig een ARP request broadcast frame is) doorsturen naar alle UNI-poorten die zijn gekoppeld aan de L2VSN geïdentificeerd door I-SID = 200.

Ondersteuning van IP (S,G) multicast is vrijwel identiek. Vrijwel, omdat:

Zoals eerder vermeld, maakt ondersteuning van IP-multicast geen deel uit van de Shortest Path Bridging-standaard. Om de 'ingebouwde' multicast-mogelijkheden ter ondersteuning van IP-multicast te benutten, heeft Extreme drie (TLV) uitbreidingen voor IS-IS gedefinieerd. Deze TLV's worden gebruikt voor het aankondigen van de aanwezigheid van afzenders. Dus ja, dit is een eigen mechanisme, maar alleen de edge nodes (BEB's) hoeven dit te ondersteunen. Voor de kern-nodes (BCB's) is het gewoon normaal doorsturen.

Er is een extra eigen mechanisme dat wordt gebruikt voor IP-multicast en daar kom ik later nog op terug.

Ter opfrissing: om multicast in te schakelen, moet je de volgende reeks opdrachten gebruiken op de BEB-nodes waar je zenders en ontvangers hebt:

Voor een L2VSN gebruik je de volgende commando's om multicast in te schakelen op b.v. VLAN 10 en 20:

Voor een L3VSN zou je de volgende opdrachten gebruiken om multicast in te schakelen op de subnetten/VLANS waar u zenders en ontvangers heeft; bijv. subnet/VLAN 100 en 200

Maar hoe werkt dit? Beginnend aan de kant van de multicast-afzender (ervan uitgaande dat je multicast hebt ingeschakeld met behulp van de hierboven getoonde opdrachten):

Wanneer een BEB-node een multicast-stream ontvangt (voor een bepaald bron-IP- en groeps-IP-adres) op een UNI-interface, zal het een I-SID toewijzen in het bereik van 16 000 001 en hoger (dit is waar ik eerder naar verwees, als het aanvullende eigen mechanisme). Deze nieuwe I-SID kan worden gezien als parallel aan de I-SID die wordt gebruikt voor standaard dataverkeer en wordt puur gebruikt voor het streamen van IP-multicastverkeer.

De BEB-node zal ook een nieuw multicast-MAC-adres creëren volgens wat hierboven is beschreven, gebruikmakend van zijn SPSourceID en de toegewezen multicast I-SID. Dus als we aannemen dat BEB1 met een SPSourceID = 0.40.01, en ook aannemen dat dit de eerste IP multicast-stream is die het ontvangt, zal het I-SID 16 000 001 toewijzen voor de stream en het volgende multicast MAC-adres maken:

03:40:01:f4:24:01

De BEB zal IS-IS-updates gebruiken om zijn buren te informeren over het bron-IP en groeps-IP, en de I-SID die voor deze multicast-stream wordt gebruikt. Het bevat ook een Tx-vlag (transmit), die aangeeft dat het de afzender zal zijn.

Voor de echte geïnteresseerden: de BEB zal in feite een standaard TLV (TLV 144) gebruiken om de toegewezen I-SID en de Tx-bit te signaleren. Het zal ook een Extreme-gedefinieerde TLV gebruiken om het bron-IP- en groeps-IP-adres aan te kondigen en opnieuw de Tx-vlag instellen om aan te geven dat dit de bron van de multicast-stream zal zijn.

De informatie wordt vervolgens doorgegeven aan alle SPB-nodes in het netwerk. Uiteindelijk zullen alle BEB-nodes de beschikbaarheid kennen van de multicast-stream (de bron- en groeps-IP) en I-SID om te gebruiken om deze multicast-stream te verzenden. Deze informatie wordt opgeslagen in de ISIS LSDB, die hetzelfde is voor elke node in de SPB Fabric.

Als dezelfde BEB-node een andere multicast-stream ontvangt (een ander S,G-paar), wijst het de volgende beschikbare I-SID toe in het bereik van 16 000 001 en hoger. Dus, ervan uitgaande dat het multicast-stream nummer twee ontvangt, zal het I-SID 16 000 002 toewijzen en zal het multicast-MAC-adres voor deze stream zijn:

03:40:01:f4:24:02

En tot slot: hoe worden de abonnees geïdentificeerd en hoe wordt de multicast daadwerkelijk naar hen gedistribueerd? Dit gebeurt met IGMP (Internet Group Management Protocol) en IS-IS.

Wanneer we IP-multicast inschakelen op een BEB-node voor een specifiek netwerk (laten we zeggen op het VLAN dat is toegewezen aan I-SID 200), maken we van de BEB ook een IGMP Querier voor dit specifieke VLAN. Het zal met regelmatige tussenpozen IGMP-query's verzenden. Host op dit netwerk die zich wil abonneren op een stream, stuurt een IGMP Host-rapport om deel te nemen.

Na ontvangst van een verzoek om lid te worden, controleert de BEB de IS-IS LSDB-database om te zien of het S,G-paar bestaat. Als dat niet het geval is, wordt het deelnameverzoek gewoon genegeerd. Anders stuurt het een IS-IS-update met de I-SID die voor deze multicast-stream wordt gebruikt en de Rx-bitset (receive). Dit verspreidt zich door het netwerk en bereikt uiteindelijk het BEB-node waarop de zender is aangesloten. Wanneer deze BEB een update ontvangt over de eerste abonnee, zal het beginnen met het doorsturen van het multicast-verkeer op de I-SID (tree) die is toegewezen aan deze specifieke multicast-stream. Nodes die zich op het kortste pad naar de ontvanger bevinden, zullen de multicast-frames doorsturen (ze hebben het multicast MAC-adres al geïnstalleerd in hun forwarding database).

Als dit de eerste abonnee is, kan de multicast forwarding tree slechts een subset zijn van de volledige unicast tree. Onderstaande figuur 5 toont de multicast tree met abonnees op BEB3 en BEB4. Als er abonnees zijn op alle BEB-nodes, is de multicast-tree identiek aan de unicast-tree. Maar het is heel belangrijk op te merken dat de multicast-paden altijd congruent zijn met de unicast-paden.

Als/wanneer de BEB een IGMP Leave-bericht ontvangt, wordt de Rx-flag gereset en wordt een IS-IS-update uitgegeven zodat de stream wordt gesnoeid.

Het bovenstaande mechanisme beschrijft de IP-multicastdistributie in een L2VSN. Het mechanisme voor IP-multicast in een virtueel Layer 3-netwerk is identiek.

Ik moet er ook op wijzen dat de multicast-stream zich bevindt in het virtuele netwerk waarvan het afkomstig is. Extreme heeft echter ook een PIM-gatewayfunctie gecreëerd, zodat SPB-multicast-domeinen kunnen worden geïntegreerd met PIM-multicast-domeinen.

Ik hoop dat je na deze (enigszins lange) beschrijving een redelijk goed begrip hebt van hoe multicast werkt in een Shortest Path Bridging-netwerk, en waarom we multicast kunnen ondersteunen zonder de extra complexiteit van PIM (of andere multicast-protocollen)!

In het volgende deel van de ‘Shortest Path Bridging voor Beginners’