Slik velger du riktig SD-WAN løsning og finner riktig leverandør.

SD-WAN er et hot buzzword i nettverksindustrien for tiden. SD-WAN står for Software Defined Wide Area Network, og er ment å beskrive en WAN-løsning realisert på SDN-prinsipper (Software Defined Networks). Det er mange ulike leverandører som angivelig leverer SD-WAN, og det kan være vanskelig å vite hva som skiller de ulike variantene fra hverandre. Jeg skal forsøke å rydde litt i begreper, bidra til å øke forståelsen rundt SD-WAN og SDN generelt, samt hjelpe med å skille mellom ulike SD-WAN-varianter.

SD-WAN har vært et begrep i mange år, men det har ikke eksistert noen formell standard på hva det er, eller rettere sagt, hva som kvalifiserer til å kunne kalle en løsning for SD-WAN. Det er imidlertid nå kommet en relativt fersk tjenestestandard publisert av Metro Ethernet Forum (MEF) som forsøker å beskrive hva en managed SD-WAN-tjeneste skal tilby. Men det er f.eks. ingen standardiserte protokoller for kontrollplanet osv. Siden det inntil nylig ikke har eksistert noen standard eller referanse-beskrivelse har mange aktører kastet seg på, og leverer angivelig «SD-WAN»-løsninger i jakten på å tilby det nyeste og hotteste innen nettverk. Men det kan være store forskjeller mellom de ulike løsningene, og selv om det er kommet en slags tjenestestandard er det ikke gitt at alle løsninger oppfyller denne – og den beskriver ikke nødvendigvis alle aspekter man bør ta hensyn til. Dermed kan det være vanskelig å vite hva som er det beste valget for akkurat deg og din bedrift. Det er også viktig å være klar over at dagens SD-WAN-varianter er for produsenteid å regne – det er p.t. ingen interoperabilitet mellom ulike produsenter.

Når det så kommer til SD-WAN er det samme prinsipper som gjelder her. Det som kjennetegner de mest solide og funksjonsrike SD-WAN løsningene er som regel at de er bygget på ett godt designet kontrollplan i bunnen. Noe som gjør løsningen robust og fleksibel, samtidig som alt provisjoneres, administreres og overvåkes sentralt. Det som ellers kjennetegner en SD-WAN løsning sammenlignet med mer tradisjonelle WAN er typisk følgende funksjonalitet:

• Zero-touch Provisioning

  • Det er tilrettelagt for at nye enheter typisk kun trenger Internett-forbindelse for å bli automatisk onboardet– ingen forhåndskonfigurasjon nødvendig

• Enhetlig WAN uavhengig av transport

  • Målet er at man i mindre grad må forholde seg til type transport-forbindelse

• Sikker lokal Internett-aksess

  • Slipper backhaul av Internett-trafikk til sentral lokasjon

• Brannmurfunksjonalitet lokalt på hver enhet

  • L4-7 brannmur, WAF, Secure DNS / Umbrella, IPS/IDS etc.

• Rask utrulling / deployment

  • Nye lokasjoner, og nye tjenester/VPN

• Intelligent trafikkstyring per applikasjon - Application Aware Routing

  • Styring av trafikk per applikasjon/trafikktype til optimal transport, basert på aktiv måling av SLA-parametre

• Optimalisering av trafikk

  • Optimal ruting til skytjenester (O365, SalesForce etc.)

  • WAN-optimalisering for TCP-trafikk etc.

  • Redusere påvirkning fra pakketap/korrupte pakker (FEC, Packet duplication etc.)

• Enkel integrasjon mot skytjenester (AWS, Azure, GCP)

  • Forleng hele WAN-løsningen inn i skyen (Cloud onRamp for IaaS)

Alt dette er ting som også er mulig å oppnå i tradisjonelle WAN-nettverk, men det innebærer gjerne stor andel manuell konfigurasjon og tilpasning – med mindre man kjøper WAN som en driftet tjeneste. Da spiller det mindre rolle om leverandøren realiserer dette på en plattform som kalles «SD-WAN», eller over infrastruktur basert på f.eks. MPLS. Som kunde trenger man primært bare forholde seg til hvilken funksjonalitet WAN-tjenesten leverer, ikke om den heter «SD-WAN» eller ikke. Tradisjonelle WAN-løsninger som IP VPN over MPLS har også fordeler som SD-WAN løsninger isolert ikke kan oppnå, som ende-til-ende QoS, etterlevelse av strenge latency/jitter-krav, større MTU og SLA-nivå for diversitet og feilretting.

SD-WAN er i kategorien overlay-baserte nettverksløsninger, hvor de aller fleste benytter IPsec-tunneler for å transportere data mellom enhetene. Så godt som alle SD-WAN løsninger er basert på at man har et annet nettverk i bunnen for å levere selve transporten, typisk i form av en standard Internett-forbindelse (kablet/fiber eller mobil), eller en privat transport (f.eks. MPLS VPN).

For en del litt enklere SD-WAN-varianter er det primære fokuset automatisk oppsett av P2P IPsec VPN-tunneler, med hovedfokus på Internett som transport. Imidlertid er det ofte betydelige begrensninger forbundet med disse. De største forskjellene finner man som tidligere nevnt gjerne i kontrollplanet for løsningen, som er viktig for å håndtere alt av VPN-tunneler, annonsering av ruting, segmentering, feil-deteksjon, reruting ved feil osv. på en god måte. Enklere SD-WAN varianter har ofte et ganske begrenset kontrollplan, noe som påvirker graden av funksjonalitet, fleksibilitet og robusthet sammenlignet med de kraftigere løsningene. Mange av disse, som kan legges i kategorien «SD-WAN Light», vil ofte ha lang failovertid, mangler typisk muligheter for ende til ende segmentering, og kan gjerne ikke håndtere mer enn to ulike transport-linker – i et aktiv/standby-oppsett. Dette betyr at skal man ha mange ulike VRF- eller sikkerhetssoner må det settes opp dedikerte transporttunneler for hver enkelt av disse, dersom løsningen støtter det overhodet, og skalering kan fort bli en utfordring. Alternativt går all transport i én og samme sone, og segmentering skjer utelukkende vha. brannmurfunksjonalitet på endene – som da kan bli komplisert å administrere.

En såkalt «Light»-variant av SD-WAN kan likevel være det riktige valget i enkelte sammenhenger, men det er viktig å være klar over ulikhetene mellom varianter/produsenter, samt mulighetene og begrensningene som gjelder når man skal velge en konkret løsning. Definer derfor konkrete krav til hva WAN-et skal og bør levere. Sett gjerne opp en punktvis liste over de viktigste parameterne, og vurder de ulike alternativene opp mot disse. Da blir det enklere å sortere for å finne den mest optimale løsningen i hvert enkelt tilfelle. Nedenfor følger et forslag til noen av de viktigste parameterne å ta stilling til i vurderingen av WAN-løsning:

• Er det lokasjoner i mange ulike land som skal omfattes av løsningen? (eller er det primært lokasjoner i Norge, evt. Norden)

• Skal WAN-løsningen driftes og opereres internt i organisasjonen? (eller skal det kjøpes som en tjeneste)

• Er det viktig med lokal Internett-aksess og brannmur/sikkerhetsfunksjoner på hver lokasjon? (eller er trafikkmønsteret slik at trafikken primært skal til sentral lokasjon uansett)
  

Hvis svaret er ja på minst to av disse punktene, er det mye som tyder på at en SD-WAN-løsning kan være riktig vei å gå. For å sortere mellom ulike SD-WAN-varianter kan man videre se på hvordan de ulike løsningene håndterer f.eks.:

• Zero-touch provisioning (det er forskjell på zero touch og «nesten» zero touch...)

  • Hvilke krav setter evt. ZTP-løsningen til transport-leveransen for at det skal fungere

  • Hvor enkelt fungerer det dersom transport-leveransen krever statisk IP-adresse etc.

• Hvilken funksjonalitet finnes for segmentering mellom ulike soner/VPN

  • Har påvirkning på skalering (f.eks. antall IPsec-tunneler), samt operasjonell kompleksitet

• Konvergenstid ved feil/utfall

  • Hvordan detekteres ulike typer feil, og hvor raskt kan løsningen agere på hendelser i nettet – både på enheter som er del av løsningen, og på hendelser i transporten

  • Hvordan håndterer kontrollplanet reruting ved feil, distribusjon av ruting, endringer i policy osv.

• Ytelse/kapasitetstall – hvilke forutsetninger ligger bak de spesifiserte tallene fra produsenten

  • Ytelsen oppgis ofte med båndbreddetall, noe som er vanskelig å sammenligne på tvers av produsenter da mange faktorer påvirker hvordan det er målt. Ettergå om oppgitt ytelsestall er med eller uten tjenester som QoS, NAT, Brannmur, IPS etc. aktivert, og ikke minst hvilke pakkestørrelser det gjelder. De fleste SD-WAN-løsninger benytter som nevnt IPsec for transport og kryptering, og IPsec er lineært mer krevende for maskinvaren per pakke – uansett størrelsen på denne. Antallet pakker per sekund maskinvaren klarer å håndtere er derfor den mest korrekte angivelsen på ytelsen, ikke antall megabit/gigabit.