Co inżynierowie chcą wiedzieć o SD-WAN?

Mówi się, że kto pyta, nie błądzi. Odkąd wdrożyliśmy pierwszy SD-WAN Cisco w Polsce, odpowiedzieliśmy na dziesiątki pytań o SD-WAN, zarówno dotyczących działania, jak i możliwości tych sieci. W dzisiejszym wpisie zebraliśmy pytania, które pojawiają się na różnych etapach rozmów z inżynierami i managerami odpowiedzialnymi za zapewnienie bezpiecznej i wydajnej infrastruktury sieciowej.

O tym jak działa SD-WAN i jak realizuje koncepcję SDN (Software Defined Network) pisaliśmy w poście Co to jest SD-WAN? Zachęcamy do potraktowania go jako wstępu do poniższej dyskusji. Dziś skupimy się na konkretnych wątpliwościach dotyczących sieci SD-WAN.

1. Czy SD-WAN jest alternatywą dla łączy MPLS? Co na to działy bezpieczeństwa?

Coraz częściej operatorzy telekomunikacyjni oferują SD-WAN oparty na Internecie (czy to kabel, czy LTE) jako alternatywę dla klasycznych łącz MPLS. W zależności od tego na jakim rynku się poruszamy, wymagania stawiane przez działy bezpieczeństwa mogą być różne. Przykładem może być rynek regulowany, w ramach którego regulator narzuca np. konieczność szyfrowania transmisji danym algorytmem. W takim przypadku to czy transmisja odbywa się w ramach MPLS czy innego rodzaju usług transmisji jest kwestią wtórną. Innym przykładem może być brak regulacji na poziomie regulatorów, a wypełnienie wewnętrznej polityki bezpieczeństwa. Jednak coraz rzadziej spotyka się wymóg transmisji w ramach MPLS jako jedynego bezpiecznego medium.

2. Czy jeśli organizacja posiada dwa łącza WAN identycznej klasy, czy „application awareness” SD-WANu ma sens?

Może mieć sens, jeśli spojrzymy na ten przypadek, jak na scenariusz równomiernego rozłożenia obciążenia przez róźne aplikacje. Chcąc wysycić dostępne łącza równomiernie musiemy zdefiniować pewien zestaw aplikacji A i B. Definiujemy je właśnie dzięki funkcjonalności AAR (application-aware routing).

3. Czy ma sens budowanie rozwiązania MPLS + SD-WAN, czy wystarczy tylko SD-WAN na łączach fizycznych?

Dla rozwiązań, w których strategicznym punktem jest utrzymanie parametru gwarantowanego zapewnianego przez biznesowy MPLS, np. Jitter, może mieć to sens. Wtedy Jedną ze ścieżek dla naszych aplikacji będzie MPLS i może być to właśnie aplikacja np. voice, która jako jedyna będzie korzystała z wymiarowanego MPLS. Praktyka pokazuje, że coraz częściej jednak aplikacje głosowe i collaboration są obsługiwane z wysoką jakością bazując na „łączach Internet”. Przykładem sa rozwiązania Collaboration typu Teams Voice.

4. Po co rozdzielać warstwy Data Plane i Control Plane?

Jest to związane ze skalowaniem. Różnice widać nie przy trzech czy dziesięciu lokalizacjach, tylko przy kilkudziesięciu lub kilkuset. W momencie kiedy mamy dużą sieć, każdy router, lokalizacja i urządzenie musiałoby zestawić Control Plane, czyli informacje routingowe ze sobą. Rozdzielenie pozwala na bardzo duże skalowanie sieci WAN, co jest szczególnie przydatne w przypadku firm dysponujących wieloma oddziałami, które muszą się ze sobą sprawnie komunikować.

5. Co się dzieje z kontrolerami, gdy wygasają nam subskrypcje?

Nawet w przypadku wygaśnięcia licencji, ruch Data Plane jest zachowany, co nie powoduje przestojów w pracy systemu. W przypadku licencji Cisco, mamy możliwość uruchomienia funkcjonalności SD-WAN nawet po kilku latach od zakupu bazowej licencji Network Essentials, na której bazie możemy stworzyć dotychczas znane konstrukcje WAN jak np. DN VPN. W tym poście na naszym anglojęzycznym blogu przedstawiamy, jak działają licencje SD-WAN od Cisco.

6. Gwarancja SLA w SD-WAN, co z nią?

Spotykamy się z głosami, że w MPLS czy w IP VPN mamy zapewnioną pewną gwarancję SLA. Natomiast gdy zbudujemy SD-WAN w oparciu o czyste łącza internetowe bez gwarancji, dalej np. na pierwszej mili, to wykonawca nam “coś” zagwarantuje.

W przypadku SD-WAN mamy trochę inną sytuację. Proaktywnie nie chcemy doprowadzić do zerwania połączenia. Oczywiście możemy mieć jedną ścieżkę gwarantowaną end to end typu MPLS. W momencie gdy następuje na niej degradacja usługi, pakiet zroutuje się samoistnie, a my w  konsekwencji nie tracimy ani minuty. W ciągu pięciu sekund zachodzi re-routing np. na drugą stronę, dzieje się to automatycznie. Chwilowo połączenie może wolniej działać, mogą pojawić się dropy czy zwiększenie latency, ale przede wszystkim nie tracimy naszego biznesu.