NETWORK-AS-A-SERVICE: Cloudificatie van het netwerk

 

Het traditionele bedrijfsnetwerk schiet vaak te kort. Het blijft achter bij de cloud, servervirtualisatie en datacenterconsolidatie.

Het bedrijfsnetwerk is van strategisch belang, dus zal het moeten veranderen. Hoe ziet die transformatie eruit?

Eric van den Berg (Cisco) en Robbert van den Berg (KPN) tonen wat er moet gebeuren om tot een ‘cloudificatie van het netwerk’ te komen..
<Klik om verder te lezen in de AutomatiseringGids>

Nexus switches met 1/10/25GE poorten

Enkele weken geleden is in dit blog de nieuwe Ethernetsnelheid van 25 Gbps besproken ( http://tblog.cisco.nl/2016/02/25/25g-ethernet-waarom/ ).

Dat stuk eindigde met de woorden: “Kijk ernaar uit: er komen switches met 48 poorten 1/10/25GE om servers aan te sluiten, en met vier of zes 40/100GE uplinks.”

Een voorspelling die nu uitkomt. Niet zo vreemd, want toen ik die zin intikte, wist ik al dat op Cisco Live twee switches aangekondigd zouden worden met 1G/10G/25G poorten.    🙂

 

De Nexus 92160YC-X

De Nexus 92160 is een één rack-unit hoge switch met 48 downlink poorten en 6 uplink poorten:

De downstream-poorten zijn gebaseerd op SFP/SFP+ en ondersteunen 1GE SFP en 10G en 25G SFP+. De zes uplink-poorten zijn QSFP poorten. Je kunt in alle zes een 40GE-QSFP plaatsen of je kunt er in vier (blauw aangegeven op de switch) een 100GE-QSFP28 zetten. Als je voor vier 100GE uplinks kiest, zijn de laatste twee uplinks niet te gebruiken.

Het is een laag2/laag3 switch met VXLAN routing en bridging. De switch ondersteunt geen ACI.

In het blog van twee weken geleden is uitgelegd dat 25GE poorten niet duurder hoeven te zijn dan 10GE poorten… Laten we eens kijken: we vergelijken de N92160 met de bestaande Nexus 3172.

De N3172 heeft 48 poorten 1G/10G en 6 uplinks van 40G.Het is een laag2/laag3 switch die VXLANs kan bridgen

De N92160 heeft 48 poorten 1G/10G/25G en 6 uplinks van 40G of 4 uplinks van 100G. Het is een laag2/laag3 switch die VXLANs kan routeren en bridgen

Kosten? De switches zijn precies even duur, dus voor dezelfde prijs krijg je met de nieuwe switch 2.5x de bandbreedte.

 

De Nexus 93180YC-EX

Ook de Nexus 93180 is een één rack-unit hoge switch met 48 downlink poorten en 6 uplink poorten:

De downstream-poorten zijn gebaseerd op SFP/SFP+ en ondersteunen 1GE SFP en 10G en 25G SFP+. De zes uplink-poorten zijn QSFP poorten. Je kunt in alle zes een 40GE-QSFP zetten en ook in alle zes een 100GE-QSFP28.

Het is een laag2/laag3 switch met VXLAN routing en bridging. De switch ondersteunt indien gewenst ACI.

Om de prijs te beoordelen, vergelijken we dit keer de Nexus 93180 met de bestaande Nexus 9372.

De N9372 heeft 48 poorten 1G/10G en 6 uplinks van 40G. Het is een laag2/laag3 switch die VXLANs kan routeren en bridgen en kan gebruikt worden in een ACI fabric.

De N93180 heeft 48 poorten 1G/10G/25G en 6 uplinks van 40G/100G. Het is een laag2/laag3 switch die VXLANs kan routeren en bridgen en kan gebruikt worden in een ACI fabric. (Verder kan de switch heel uitgebreide statistieken van de flows door de switch leveren.)

Kosten? De switches zijn precies even duur, dus voor dezelfde prijs krijg je met de nieuwe switch 2.5x de bandbreedte.

 

Samengevat: als je nu voor je datacenter een 10GE-down-40GE-up-switch zoekt, kun je voor hetzelfde geld een 10G/25G-down-40G/100G-up-switch nemen, die nu met 10/40 gebruiken en naar 25/100 migreren zodra dat nodig is.

 

Cisco HyperFlex Systemen: De volgende generatie complete hyperconvergence

Ontdek de nieuwe generatie van hyperconverged infrastructuur alsmede de voordelen van deze geavanceerde gedistribueerde storage-technologie.

Cisco Hyperflex combineert compute, opslag en netwerken in een makkelijk te gebruiken systeem dat nieuwe niveaus van snelheid en efficiëntie brengt. Gebruik Hyperflex technologie om het volledige potentieel van hyperconverged infrastructuur vandaag te ontgrendelen.

Wilt u meer weten, bekijk dan onze Nederlandse campagne site: http://www.ciscohyperflex.nl/

of bekijk de video op:
http://www.cisco.com/c/en/us/products/hyperconverged-infrastructure/index.html

 

Waar laat u uw eigen speciale applicatie…

Stel: u, als netwerk beheerder, hebt een aparte applicatie die u nodig hebt en op de branch-kantoren moet draaien… Op welk platform laadt u deze applicatie?

Als er nog servers zijn in iedere branch, dan kan de applicatie op één van de servers… nadeeltje: dan wordt hij beheert door de servermensen, die gaan eisen stellen aan patches, welk OS, hoe de backup geregeld zal worden… Maar goed, het zou kunnen:

Maar vaak is er geen server in de branch, want dat is de situatie die de meeste bedrijven nastreven: geen remote servers. Nu is het al jaren mogelijk om een serverblade in de router te plaatsen:

Er staat nu inderdaad geen losse server in de branch… maar het blade is een server, met eigen cpu, memory en opslag, alleen opgeborgen in het chassis van de router.

Sinds IOS XE release 3.17 is er nog een optie, waarbij er geen extra server nodig is en alles onder controle van de netwerk-afdeling blijft. Het is namelijk mogelijk om eigen applicaties te draaien op de router CPU:

Dit gaat niet ten koste van de routers IOS en er is ook geen risico dat de applicatie de IOS stoort.

Hoe werkt het? Eerst even de architectuur van IOS XE, bijvoorbeeld op een ISR4451:

De basis van IOS XE is een Linux kernel met daarop een KVM hypervisor. IOS is een virtuele machine op deze hypervisor, die één van de cores in de CPU gebruikt. De andere drie cores in de control-plane-CPU worden niet door IOS gebruikt. Tot en met 3.16 was de hypervisor onzichtbaar voor de gebruiker van de CLI, alleen WAAS kan als extra vm worden opgestart.

Vanaf IOS XE 3.17 is dit anders. U mag uw eigen applicaties op de vrije cores zetten:

De hypervisor zorgt ervoor dat IOS ongestoord zijn eigen core heeft, met zijn eigen memory en geeft alleen IOS toegang tot de forwarding plane van de router.

Met enkele nieuwe commando’s (zoals: router# virtual-service install name my_kvm package bootflash:xxx.ova ) wordt een .ova file als virtuele machine geladen op de hypervisor…

Waarmee u dus dit

bereikt: uw eigen applicatie draait op de router.

Op welke routers? ISR 4400’s, ASR1000’s en de CSR.

(als er vanavond niets leuks op de tv is: bedenk twee redenen waarom het zinnig is om op de CSR, die zelf een virtuele machine is, een virtuele machine te kunnen starten.)

 

ITD = een high-performance load-balancer die je al hebt…

Load-balancers zijn er in soorten en maten: L3/L4 of L7 en met verschillende performances. Vaak zijn het extra appliances in een netwerk, waar het verkeer naar toe geleid moet worden en die aardig bedragje extra kosten.

Wat niet iedereen beseft: als je een Nexus 5600, 7000 of 9000 in je netwerk hebt, heb je een eenvoudige, maar heel high-performance L3/L4 load-balancer op een natuurlijke plaats in de core, waar geen extra appliances en geen extra uitgaven voor nodig zijn:

Een Nexus kan geconfigureerd worden met een Virtual Server-adres en een bijhorende pool van echte servers. De forwarding-ASICs van de Nexus zorgen voor het load-balancen. Verkeer van een client komt binnen, gericht aan het Virtual Server-adres. De ASICs kiezen op basis van L3/L4 informatie een Real Server en redirecten het verkeer naar deze echte server. Dit gebeurt geheel in de hardware, gaat niet ten koste van de performance en raakt de CPU nooit: met een Nexus7718 gevuld 12-poorts 100GE kaarten, kun je 19.2 Tbps verkeer load-balancen, zonder extra appliances, zonder performance verlies, zonder extra kosten…

Kanttekening: Nexus 7000 is de beste keuze voor ITD (Intelligent Traffic Director). Hij ondersteunt ITD met zowel IPv4 als IPv6 verkeer en NAT, terwijl de 5600 en 9000 alleen ITD met IPv4 ondersteunen en geen NAT.

Dus: zoek je een L3/L4 load-balancer en heb je een Nexus 7000? ITD doet alles voor je, met een performance die geen enkele appliance-gebaseerde loadbalancer zal halen.

 

Schrikkelseconde – 30 Juni

Nee – geen 1 April grap. Op 30 Juni wordt een schrikkelseconde ingevoerd en dit kan invloed hebben op een aantal Cisco producten. Meer informatie is te vinden op de Leap Second Adjustment pagina, en op de productinformatie tab.

To ensure the correct alignment of astronomical and atomic time, the International Earth Rotation & Reference Systems Service has called for an extra second to be added to Coordinated Universal Time (UTC) at 23:59:59 on 30 June 2015.

This will be the 26th leap second adjustment since 1972, and represents an important consideration for providers of computing, networking, and software solutions.

Waarm het IS-IS (Intermediate Systems to Intermediate Systems) routing protocol zo populair is bij de nieuwste datacenter technieken

In een datacenter is (vrijwel) altijd behoefte aan een laag-twee-netwerk dat het hele datacenter omspant. Het Spanning Tree protocol vormt de basis alle laag-twee-netwerken, maar alleen omdat er (nog) geen andere mogelijkheid is.

Voor datacenter-netwerken wordt gekeken naar alternatieven voor Spanning Tree, zoals bijvoorbeeld FabricPath, Dynamic Fabric Automation of TRILL. Voor al deze protocollen geldt:

– Ze zijn bedacht om laag-twee connectiviteit te bieden in een groot, plat netwerk, zonder paden die geblokkeerd zijn en met meer stabiliteit dan Spanning Tree.

– Dit gebeurt steeds door een extra header te plakken voor het oorspronkelijke Ethernet-pakket, welke het pakket ‘routeerbaar’ maakt. ‘Routeerbaar’ wil zeggen: aan de hand van deze extra header kan iedere switch in het netwerk bepalen waar het pakker afgeleverd moet worden.

– Ze hebben gemeen dat ze IS-IS gebruiken als routeringsprotocol om de topologie van het netwerk te ontdekken en te adverteren.

 

Een vraag die men regelmatig hoort is: Waarom IS-IS? In enterprise netwerken is IS-IS zo ongeveer het minst gebruikte routeringsprotocol. Het is onbekend en dus onbemind en het heeft een imago van ‘het is in gebruik bij service providers, dus het zal wel ingewikkeld zijn.’

Dus: waarom IS-IS? Wel , laten we de alternatieven bekijken.

– Men had een heel nieuw protocol kunnen ontwikkelen om Spanning Tree te vervangen… Dat had gekund maar dat zou jaren overleg hebben gevergd, gevolgd door testen en het daarna uitbrengen van versies twee en drie voor er een stabiele versie zou zijn. Waarschijnlijk was er dan nu nog geen vervangend protocol geweest.

Er bestaan vele routing-protocollen om de topologie van een netwerk in kaart te brengen, de meest gebruikte in enterprise-netwerken zijn EIGRP en OSPF. Men zou verwachten dat voor een vervanger van Spanning Tree in het enterprise datacenter een van deze twee gekozen zou worden.

– EIGRP is heel sterk in het afhandelen van grote hub-en-spoke netwerken met veel noord-zuid verkeer. EIGRP is heel schaalbaar als adressen in eeen hiërarchische netwerk kunnen worden geaggregeerd… Echter, in het datacenter is heel veel oost-west verkeer en is behoefte aan platte netwerken waar virtuele machines vrij heen en weer geplaatst kunnen worden maar met gevolg dat geen adressen geaggregeerd kunnen worden.

– OSPF schaalt door een netwerk op te splitsen in een backbone area met daaraan vast andere area’s. Iedere area moet in principe een aaneengesloten deel van het netwerk zijn. Nu past een aaneengesloten backbone niet zo goed op het moderne datacenter design met leafs en onderling onafhankelijke spines en ook sluiten van elkaar gescheiden area’s niet goed aan bij het idee dat virtuele machines vrij moeten kunnen bewegen in het data center.

Verder geldt voor zowel OSPF als voor EIGRP: ze zorgen voor de uitwisseling van informatie over IP-adressen. Dat is voor een routeringsprotocol normaal, maar in een datacenter moet ook MAC-adres informatie uitgewisseld worden en in een datacenter moet de mogelijkheid zijn om broadcasts en niet-IP-multicasts te versturen… Daar is binnen de bestaande definities van OSPF of EIGRP niet in voorzien.

 

Dan het IS-IS protocol: het IS-IS protocol werkt net als OSPF met een shortest path first algoritme. Echter, terwijl OSPF bij een verandering binnen een area altijd een complete herberekening van het algoritme maakt, kent IS-IS een zogenaamde ‘partial route calculation’: in de situatie waarin wel de adressen, maar niet de topologie verandert, wordt alleen een gedeelte van de berekening overgedaan. En dat is heel mooi in een datacenter, waar – als virtuele machines verplaatst worden – wel de adressen veranderen, maar niet de topologie.

In de praktijk is gebleken dat in netwerken met enkele honderden routers in één enkele area het IS-IS protocol geen performance probleem heeft, terwijl in zo’n netwerk voor OSPF allang een opsplitsing in meerdere area’s aan te raden is. Vertaald naar datacenters: IS-IS kan een groot datacenter met honderden switches probleemloos als één area behandelen.

Nog een puntje in het voordeel van IS-IS is dat alle informatie in de IS-IS-pakketten expliciet gelabeld is: voor ieder veld in een pakket staat een label dat het type informatie en de lengte aangeeft. Deze flexibiliteit maakt het mogelijk om binnen de standaard extra labels te definiëren zodat ook andere gegevens tussen de switches uit kunnen worden gewisseld, zoals – voor het datacenter belangrijk – informatie hoe broadcasts en multicasts rondgestuurd moeten worden.

 

Samengevat:

Het IS-IS protocol schaalt probleemloos naar honderden switches in een plat netwerk, zodat virtuele machines probleemloos verplaatst kunnen worden en oost-west verkeer optimaal afgehandeld kan worden.

Het IS-IS protocol is flexibel in het doorgeven van andere informatie dan alleen IP-adressen, zodat in een datacenter alles wat nodig is voor laag-twee connectiviteit moeiteloos ingepast kan worden.

Kortom, ideaal voor de nieuwe laag-twee-protocollen voor het datacenters….

 

 

Dynamic FCoE

Netwerk designs zijn aan het veranderen !

 

Van een meer traditionele North-South approach gaan we meer naar een ander model. Dit heeft te maken doordat verkeer veel meer east-west verkeer aan het worden is. Door toename van dit verkeer is het traditionele model niet meer altijd toereikend.

Ook de links tussen de Spine en Leafs zijn vaak al 40 Gb of zelfs al 100 Gb.

Maar wat is nu Dynamic FCoE ?

Door FCoE over FabricPath te vervoeren krijgen we meer schaalbaarheid, grotere betrouwbaarheid en snellere convergence.

Waarom is het Dynamisch ?

De Interswitch links worden niet handmatig meer geconfigureerd, maar door het systeem zelf geconfigureerd tussen de endpoints. Een groot voordeel is dat er minder typefouten gemaakt kunnen worden, waardoor het systeem ook betrouwbaarder wordt. De Fabricports worden dynamisch geconfigureerd om zo vFC’s interfaces te maken.

Hoe ziet dit er dan uit :

Maar hoe zit het dan met mijn SAN-A en SAN-B benadering. Dat is in dit design niet meer te zien.

Vanuit de storage devices is er logisch gezien nog steeds een SAN-A en SAN-B aansluiting. Het netwerk echter kan deze SAN-A en SAN-B op verschillende manieren vervoeren. Een groot voordeel van dit design is dat de Spine transparant is. Hierdoor kan je het design alsvolgt zien :

Maar het heeft wel de voordelen van meerdere paden, zodat indien er een “SAN-A” uitvalt, men nog steeds de volledige bandbreedte heeft. Het het traditionele model van SAN-A en SAN-B, als daar een device uitviel was men 50% van de bandbreedte kwijt. Indien er nu een Spine uitvalt, dan is in bovenstaande voorbeeld maar 25% verlies, indien de volledige bandbreedte wordt gebruikt.

Wanneer komt Dynamic FCoE ?

Het is er al voor de Nexus 5K, Nexus 6K en de Nexus 7K komt het in de volgende NX-OS release.

Configuratievoorbeelden van Dynamic FCoE kan men vinden op :

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5500/sw/fcoe/7x/b_5500_FCoE_Config_7x/b_5500_FCoE_Config_7x_chapter_0101.html

Op 13 juni tijdens de Cisco Technical Summit gaat Joost van der Made over dit onderwerp er verder op in.

 

De 40GE BiDi interface voor de Nexus switches

Samenvatting

De IEEE standaard voor 40Gbps Ethernet (40GE) over multimode fiber vereist vier/zes fiberparen, zodat bij een migratie van een datacenter van 10GE naar de standaard 40GE interface extra fibers nodig zijn.

De Cisco 40GE BiDi interface maakt het mogelijk om zonder extra fibers te installeren de migratie van 10GE naar 40GE te maken.

 

De IEEE 40GBASE-SR4 standaard

De IEEE heeft voor 40 Gbps Ethernet (40GE) een aantal interface-standaarden gestandaardiseerd, zoals bijvoorbeeld:

*  40GBASE-SR4     voor 40GE over multimode fiber

*  40GBASE-LR4     voor 40GE over singlemode fiber

*  40GBASE-CR4     voor 40GE over twinax koper

…voor al deze interfaces geldt dat de 40 Gbps bitstroom wordt verdeeld over vier parallelle kanalen van ieder 10 Gbps.

Bij het gebruik van multimode is ervoor gekozen om deze kanalen over aparte glasaders te versturen: er worden dus meerdere fibers gebruikt voor één 40GE verbinding en in alle fibers wordt 850 nm licht gebruikt.

De normale – in datacenters veelgebruikte – interface om glasvezels af te monteren is de MPO interface, waarbij twaalf of meer aders in één connector afgemonteerd worden:

Van de twaalf aders worden er vier gebuikt om ieder een kwart van een 40GE stroom te verzenden en vier om een kwart van een 40GE te ontvangen:

…en zo blijven er van de twaalf aders vier ongebruikt.

Twee 40GBASE-SR4 QSFP’s aan weerszijde van een ribbon-multimode fiber zien er dus uit als:

Merk op: het ziet er uit alsof er viermaal 10GE gechanneld wordt, maar dat is niet zo. Een pakket wordt parallel over vier aders verstuurd en er is dus echt 40Gbps per sessie mogelijk:

… en aan de ontvangende kant:

De bekabeling in het datacenter zal normaliter bestaan uit gestructureerde bekabeling van twaalf (of veelvouden van twaalf) aders in een ribbon afgemonteerd op MPO-connectors:

Nu lijkt het alsof de migratie van 10GE naar 40GE vlekkeloos kan verlopen: 40GBASE-SR4 gebruikt MPO-interfaces en deze zijn al onderdeel van de bekabling….

…echter: deze MPO interfaces worden altijd gebruikt voor meerdere 10GE verbindingen. Een extra cassette splitst de twaalf (of meer) aders uit in zes (of evenredig meer) fibers van twee aders…

Ieder van deze 10GE verbindingen is in gebruik voor verbindingen tussen switches of van switches naar servers. Als we nu deze zes verbindingen willen migreren naar 40GE….

…dan past er slechts één 40GE verbinding in de fibers waar we eerst zes 10GE verbindingen hadden. We moeten helaas fibers gaan bijtrekken voor de andere vijf verbindingen!

 

De Cisco 40GE BiDi interface

 De Cisco 40GE BiDi QSFP is beschikbaar voor alle 40GE poorten van de Nexus switches. In de BiDi QSFP wordt het 40GE signaal niet verdeeld over vier kanalen maar over twee kanalen en voor deze twee kanalen worden twee verschillende kleuren licht gebruikt:

Omdat er met twee kleuren licht wordt gewerkt, kan op beide aders zowel worden gezonden als ontvangen en hebben we aan twee aders genoeg om een 40GE verbinding te maken.

Een 40 Gbps bitstroom wordt nu gesplitst in twee 20 Gbps stromen, die parallel verstuurd worden:

Nu er nog maar twee aders nodig zijn voor een multimode 40GE verbinding… kunnen we net zoveel 40GE verbindingen maken als we eerst 10GE verbindingen hadden. Dus over onze twaalf aders van de MPO connector kan nu niet één, maar kunnen wederom zes verbindingen lopen:

De BiDi interface heeft minder transmitters en receivers nodig dan een SR4 interface en ook minder electronica om de bitstromen te scheiden en later weer te combineren. Hierdoor is zijn listprijs minder dan de helft van de listprijs van een SR4 interface. Daarbij is bij de keuze voor de BiDi interface ook nog sprake van een aanzienlijke besparing op de aanlegkosten van de bekabeling….

 

VXLAN [intro]

Al meer dan vijfentwintig jaar worden Ethernetnetwerken met hulp van het Spanning Tree Protocol (STP) samengevoegd tot grotere netwerken. Nu heeft STP twee bekende problemen: eventuele redundante verbindingen zijn geblokkeerd en als er – door fouten – actieve loops ontstaan in het netwerk, blijkt STP onstabiel te zijn.

 

Verschillende alternatieven zijn bedacht om Ethernet – laag twee – verkeer door een netwerk te sturen waarbij redundante links actief kunnen zijn en loops in de topologie het netwerk niet instabiel maken. VXLAN is een van deze alternatieven.

 

Hoe werkt VXLAN

We beginnen met een volledig gerouteerd netwerk:

 

Wanneer er nu Ethernet frames over het netwerk moeten worden getransporteerd, dus niet gerouteerd maar laag 2 geswitcht, dan wordt dit pakket ingepakt in een VXLAN envelop en wordt het pakket in feite door het gerouteerde netwerk getunneld:

 

Hierdoor lijkt het voor de eindstations op verschillende LANs alsof ze als directe buren op een Ethernet zitten.

Wat zijn de voordelen van VXLAN

Aankomende open standaard, gebaseerd op IP. In principe kunnen VXLAN eindpunten over het Internet communiceren en dus kunnen ze dit zeker over ieder bedrijfs-IP-netwerk.

 

Wat zijn de nadelen van VXLAN

De draft-RFC voor VXLAN bespreekt alleen de encapsulatie van Ethernet in IP… Nergens wordt besproken hoe eindpunten elkaar zouden moeten kunnen vinden, nergens in de draft-RFC wordt bepaald hoe de beveiliging geregeld moet worden. Natuurlijk lossen de leveranciers van een VXLAN-implementatie dat wel op, maar helaas ieder op hun eigen manier, wat ten koste van de interoperabiliteit zal gaan.

 

De overhead van VXLAN

Een ander nadeel van alle alternatieven voor STP is dat ze allemaal gebaseerd zijn op het inpakken van Ethernet in een ander protocol. Ook in het geval van VXLAN wordt een Ethernet pakket ingepakt in een serietje bijkomende headers: een extra Ethernet header, een extra IP header, een UDP header en een VXLAN header… samen minstens 50, meestal 54 bytes en deze extra 54 bytes moeten ook getransporteerd worden over de links tussen de switches.

Bijvoorbeeld als de gemiddelde frame-grootte in uw netwerk 400 bytes is, worden de frames nu ineens 454 byte. Gevolg zal zijn dat over een 10 Gbps link tussen twee switches, nu nog maar effectief 8.8 Gbps data vervoerd kan worden. De resterende 1.2 Gbps wordt gebruikt door de relatief grote VXLAN-overhead.

(Een alternatief als bijvoorbeeld FabricPath is een efficiëntere encapsulatie: daar is de overhead maar 16 bytes per pakket en kan over een 10 Gbps link 9.6 Gbps data vervoerd worden.)

 

In de praktijk is – voor zeker 90% van de data centers in Nederland – het probleem van de overhead relatief eenvoudig op te lossen: gebruik in plaats van 10 Gbps links tussen de switches 40 Gbps links. Natuurlijk is de procentuele overhead op 40 Gbps net zo groot, maar er is vrijwel geen bedrijf dat die 40 Gbps zal vullen en zolang er ruimte op de lijn is, is de overhead van geen enkel belang….

 

Is VXLAN een goed alternatief voor STP

Het is een alternatief voor STP, dat is waar, maar niet noodzakelijk het beste alternatief. Positief is dat het op IP gebaseerd is en dus probleemloos gebruik kan maken van grote, gerouteerde IP netwerken als onderliggende infrastructuur met als enorme voordeel dat IP netwerken moeiteloos én groot én stabiel kunnen zijn. Daartegenover staat dat de VXLAN-standaard alleen aandacht aan de data-plane besteedt en niet aan de control-plane. Gevolg is dat verschillende VXLAN-implementaties van verschillende leveranciers niet noodzakelijk vlekkeloos samenwerken, waarmee het voordeel van een ‘open standaard’ min of meer onderuit gehaald wordt.