För ett tag sedan skrev jag på LinkedIn och frågade vad en SD-WAN-lösning ska bestå av. Inlägget var avsett att skapa en diskussion och det fanns många bra svar. Vissa av funktionerna är ”måsten” medan andra är ”trevligt att ha”. Jag hävdar inte att jag har alla svar men här är några av mina tankar om ämnet ”Vad är SD-WAN?”.
Automatiserad VPN – Det bör finnas en mekanism som hjälper dig att bygga IPSec-tunnlarna. Du bör inte behöva konfigurera dem manuellt. Traditionellt använde vi ofta något som DMVPN för att bygga tunnlarna för oss. Tänk på följande:
- Hur är enheter är onboardade? Vem kan gå med i Overlay?
- Byggs tunnlar med certifikat eller pre-shared key?
- Hur ofta roteras nycklarna, om överhuvudtaget?
- Hur förhindrar du att en stulen router från att delta i Overlay?
Separation av kontroll- och dataplan – Det här kan diskuteras men det bör finnas en central mekanism för att påverka topologin för Overlay och orkestrering av Edge-enheter. Med DMVPN hade vi förmågan att bygga Hub and spoke eller full mesh, men det fanns ingen granulär kontroll. Vi kan påverka hur trafiken flödar genom att använda till exempel BGP-communities. Saker att ta i beaktande:
- Kan jag påverka topologin i mitt Overlay från en central plats?
- Kan detta göras per VPN?
- Kan jag ändra forwarding av mina routrar?
- Hur kan jag göra det här?
Transportoberoende – Denna punkt är enkel men ändå viktig. Stöder lösningen användandet av alla typer av transport som MPLS eller internet och stödjer den också LTE och inte bara Ethernet?
Separat transport- och servicesida – Är transportsidan verkligen åtskild från servicesidan? Vi brukade göra detta genom att använda en VRF så att transportgränssnitten separerades från LAN-gränssnitten. Detta gav oss ett par saker:
- Isolera tillgängligheten från utsidan till vårt LAN
- Minimera risken för Route recursion-loopar
- Möjlighet att använda adressering i LAN:et utan någon konflikt med transportsidan
Ovan kan låta uppenbart men jag har hört talas om att SD-WAN-lösningar har problem där adresseringen som används av operatören krockar med kundens egen adressering. Inte en kul situation att hamna i.
Applikationsmedveten routing – Vi har använt saker som IP SLA och PfR för att tillhandahålla applikationsmedveten routing, det vill säga möjligheten att skicka trafik i olika tunnlar beroende på hur en transport presterar, där mängden paketförluster , latens och jitter mäts. Detta ger möjligheten att skydda mot brownouts och inte bara blackouts. Dessutom behövs en DPI-motor för att kunna identifiera applikationer. Kom ihåg följande:
- Hur mäts transportens prestanda? Är det ICMP? BFD? Eller mäta prestandan för den faktiska trafiken?
- Vilka typ av förhållanden kan den reagera på?
- Kan den mäta för olika QoS-klasser? Baserat på DSCP?
- Kan den reagera på olika mängder bandbredd? Tänk ett RF-baserat WAN
API – Att ha ett GUI är trevligt men det måste också finnas ett sätt att interagera med lösningen med hjälp av kod. På så sätt kan du ha en mjukvarupipeline där en ny webbplats kan spinnas upp och du kan till och med göra CI/CD för att kontrollera att allt kom upp som planerat.
Segmentering – Segmentering blir allt viktigare. Du kanske vill separera gäster från anställda, olika affärsenheter från varandra eller ha ett sätt att integrera nyförvärvade verksamheter. Segmentering bör göras och helst skall du då kunna utnyttja samma tunnlar och inte bygga nya. Frågor att tänka på:
- Stöder min lösning segmentering?
- Hur många VPN: er?
- Olika topologier per VPN?
- Kräver segmenteringen nya tunnlar?
Det är många saker jag inte har tagit upp. Jag har inte pratat om molntjänster, säkerhetsfunktioner och FEC eller paketduplicering och många andra saker. Dessa är alla saker att ta hänsyn till men jag tror att en lösning ska uppfylla de saker jag nämnde i det här inlägget för att kvalificeras som SD-WAN. Som jag sade tidigare hävdar jag inte att jag har alla svar, jag ger dig bara några saker du bör tänka på för att komma igenom all marknadsföring och hype.
Lycka till med dina SD-WAN-implementationer!
Läs mer i Conscias kostnadsfria SD-WAN white paper!
Hör gärna av dig till oss om du har frågor.
Daniel Dib är en av tre Cisco Design-certifierade experter på Conscia Netsafe (CCDE) och även CCIE samt AWS Solutions Architect Associate. Han är den enda svenska representanten på Cisco CCIE Advisory Council som driver och utvecklar CCIE-programmet. Daniel är en känd skribent i branschen som håller utbildningar åt Cisco på deras Cisco Learning Community och har fem år i rad blivit utsedd till Cisco Designated VIP för sina insatser. Han är en Cisco Learning Network VIP samt Cisco Champion. Daniel driver en av de mest populära bloggarna i nätverksbranschen, Lostintransit, från vilken vi fått översätta denna bloggpost. Daniel har även skrivit i Network Computing, i IDG/Techworld och i Ciscos egen blogg.
