SD-WAN eller MPLS: fel fråga, och vad ni i stället ska jämföra

Frågan ställs nästan alltid som ett vägval: ska vi köra SD-WAN eller MPLS? Den formuleringen är en del av problemet, eftersom de två sakerna inte ligger på samma nivå. MPLS är ett sätt att transportera trafik. SD-WAN är ett sätt att styra trafik, oavsett vad den transporteras över. Det går utmärkt att köra SD-WAN med MPLS som en av transporterna, och det är i praktiken vanligare än att någon river ut allt på en gång.

Det som däremot är ett verkligt vägval är något annat: ska ert företagsnät byggas på en privat, operatörsstyrd transport där leverantören ansvarar för vägen mellan era platser — eller på vanliga internetanslutningar där ni själva, eller någon ni anlitar, styr vad som går var? Det är den frågan som avgör kostnad, felsökning, flexibilitet och vem som får telefonsamtalet när något inte fungerar.

Den här genomgången reder ut vad de två faktiskt är, vilka fem faktorer som styr valet, vad som ofta blir fel i jämförelsen och hur en rimlig migreringsväg ser ut.

Vad MPLS är, i praktisk mening

MPLS står för Multiprotocol Label Switching och är en teknik för att märka och vägleda paket inuti en operatörs nät. Som kund märker ni sällan av tekniken som sådan. Det ni köper är resultatet: ett privat nät mellan era platser, där trafiken aldrig går ut på det öppna internet, där operatören håller ihop vägen och där olika trafikslag kan hanteras med olika prioritet i operatörens nät.

Styrkan är förutsägbarhet och tydligt ansvar. Det finns en part som äger transporten mellan A och B, och som ska svara för hur den beter sig. För verksamheter där vissa applikationer är känsliga för fördröjning och paketförlust, och där det är viktigt att prioriteringen gäller hela vägen och inte bara i era egna ändpunkter, är det en verklig egenskap och inte marknadsföring.

Svagheterna är lika konkreta. Förbindelserna är dedikerade och kostar därefter per megabit. Att lägga till en ny plats är en beställning med ledtid, inte en konfigurationsändring. Och konstruktionen är byggd för en värld där applikationerna står i ett eget datacenter. Ska trafiken till slut ändå ut mot molntjänster får ni ofta en omväg: ut från kontoret, in i det privata nätet, fram till en central utgång, och därifrån ut på internet. Den omvägen är ibland helt rimlig — och ibland är den hela problemet.

Vad SD-WAN är, i praktisk mening

SD-WAN är ett styrlager ovanpå de förbindelser ni redan har. I varje ändpunkt sitter utrustning som bygger krypterade tunnlar mot de andra platserna, och som utifrån centrala regler avgör vilken trafik som ska ta vilken väg. Transporten kan vara fiber, radiolänk, mobilt eller för den delen MPLS. Poängen är att valet av väg blir en policy i stället för en kabeldragning.

Det ger tre saker som är svåra att få på annat sätt. Flera vägar kan användas samtidigt i stället för att en ligger och väntar. Trafik kan behandlas olika — affärssystemet och videomötet behöver inte dela öde med en molnbackup som råkar köra igång mitt på dagen. Och trafik till molntjänster kan gå ut lokalt på varje plats i stället för att ta omvägen via ett centralt nav.

Priset är att ansvaret flyttar. När transporten är vanliga internetanslutningar är det ingen som äger vägen mellan era kontor. Den vägen går över flera operatörers nät, och den dagen fördröjningen mot en viss molntjänst plötsligt ökar finns det ingen enskild part som kan peka på sin egen utrustning och åtgärda. SD-WAN hanterar det genom att mäta och välja väg, vilket fungerar bra — men bara så länge det finns fler än en väg att välja mellan. SD-WAN över en enda förbindelse är en dyr brandvägg.

Fem faktorer som faktiskt avgör valet

Antal platser och hur de ser ut. Ett huvudkontor och två filialer är en annan situation än fyrtio butiker. Ju fler och ju mindre platserna är, desto tyngre väger enkelheten i att sätta upp en ny site snabbt, och desto mer kostar en modell där varje plats kräver en egen operatörsbeställning med ledtid.

Var applikationerna står. Om allt väsentligt redan ligger i molntjänster är ett nät byggt för att samla trafik i ett centralt nav en lösning på gårdagens problem. Om affärssystemet står i ett eget serverrum och all personal ska nå det, är ett privat nät med tydligt ansvar för sträckan betydligt mer motiverat.

Hur känsliga applikationerna är. Telefoni, videomöten, terminalsessioner och realtidsstyrning reagerar på fördröjning, jitter och paketförlust — inte på hastighet. Här är frågan om prioriteringen gäller hela vägen eller bara i era ändpunkter en avgörande skillnad, och den skillnaden är också det starkaste kvarvarande argumentet för privat transport.

Vem som ska drifta. SD-WAN flyttar kontroll till er, och kontroll är arbete. Antingen finns den kompetensen internt, eller så köps driften som tjänst. Att välja SD-WAN för att det är billigare i transport och sedan inte ha någon som sköter policyerna är ett känt sätt att få det sämsta av två världar.

Vad som ska hända vid fel. Det här är den fråga som oftast avgör i praktiken. Med privat transport finns en part att ringa. Med internetbaserad transport är svaret i stället att konstruktionen ska klara felet själv — vilket kräver att det finns två verkligt separata vägar ut från varje plats, inte två fakturor på samma kabelväg. Hur man kontrollerar det har vi gått igenom i texten om redundant internet.

Det som oftast blir fel i jämförelsen

Den vanligaste jämförelsen ställer priset på en MPLS-förbindelse mot priset på en internetanslutning med samma hastighet, och konstaterar att skillnaden är stor. Det stämmer, och det är ändå inte hela kalkylen.

På SD-WAN-sidan tillkommer utrustning i varje ändpunkt, licenser eller prenumeration för styrningen, och drift — internt eller köpt. Dessutom tillkommer i regel en andra förbindelse per plats, eftersom hela poängen bygger på att det finns mer än en väg. På MPLS-sidan tillkommer sällan något oväntat, men den dagen ni ska lägga till platser eller ändra kapacitet gör ledtiderna sig påminda.

Den andra vanliga missen är att jämföra hastighet i stället för beteende. Två förbindelser med samma siffra i abonnemanget kan bete sig helt olika under belastning, och det är beteendet som märks i ett videomöte. Vilket underliggande nät som används, hur delad kapaciteten är och var trafiken lämnar operatörens nät spelar större roll än den nominella hastigheten. Hur man resonerar kring dimensionering har vi skrivit om separat.

En rimlig migreringsväg

Företag som byter gör det sällan över en helg, och de som gör det över en helg brukar ha en berättelse att dela med sig av efteråt.

En praktisk ordning är att börja med att lägga SD-WAN ovanpå det nät ni redan har, med MPLS kvar som en av transporterna. Då får ni styrningen och synligheten först, utan att ha rivit något. Nästa steg är att komplettera de platser där det är motiverat med en internetförbindelse som andra väg, och låta trafik som inte behöver den privata transporten gå där. Först därefter, när ni ser i era egna mätvärden vilken trafik som faktiskt kräver vad, blir det meningsfullt att minska MPLS-kapaciteten eller avveckla den på de platser där den inte längre bär något viktigt.

Två saker är värda att bevaka under hela resan. Det ena är avtalstiderna — en MPLS-uppsägning med lång bindningstid kan göra att en teknisk plan blir ekonomiskt ointressant i ett par år, och det är sådant som ska inventeras före beslutet, inte efter. Det andra är IP-adresseringen: en förändring av hur trafiken lämnar er miljö kan innebära att avsändaradressen mot en motpart ändras, och det märks hos den som har låst upp er på ett visst nummer.

Så ser vi på det

Bredband3 äger inget eget nät. Vi är operatörsoberoende, vilket innebär att vi inte har något eget MPLS-nät att fylla och ingen anledning att rekommendera den ena modellen för att den passar oss. Det som avgör är hur era platser ser ut, var systemen står, vad som är känsligt och vem som ska sköta driften.

För många företag med flera platser blir svaret en kombination: SD-WAN som styrlager, blandade transporter beroende på vad som går att leverera på varje adress, och privat transport kvar där den verkligen fyller en funktion. För andra är ett rent internetbaserat upplägg både billigare och enklare. Vilka nivåer och åtaganden som gäller beror på adress och teknik, och skrivs in i avtalet.

Har ni en lista på era adresser och en grov bild av vilka system som är känsliga, räcker det som underlag för ett första förslag. Begär offert så återkommer vi.

Vill ni gå vidare hittar ni mer om SD-WAN mellan flera siter, företagsbredband via flera tekniker, nätverkslösningar på plats, nät för logistik och transport och nät för butik och retail.