Łącze Dzierżawione – Publikacja Artykułu w ICT Professional

Łącze dzierżawione

Łącze dzierżawione

Dawniej sytuacja była prosta – łącza dzierżawione bazowały na technologiach WAN takich jak: SDH/ SONET, ATM czy FrameRelay, które natywnie zostały przystosowane do świadczenia usług dzierżawionych. Rozwiązania te dawały przede wszystkim przewidywalność działania i jasno zdefiniowane metody testowania łącza przed odbiorem. Były to w większości usługi z dedykowanymi zasobami co znacząco wpływano na ich cenę. Jeszcze 15 lat temu nikogo nie dziwiły ceny rzędu 100tys. Złotych za dedykowane łącze E1 (2Mbps) z Londynu do odległej Afryki czy Azji.

Jednak rynek usług WAN ok. 10 lat temu zaczął się zmieniać. Operatorzy zaczęli migrować w kierunku technologii Ethernet, która w sieciach lokalnych i małych ISP była obecna od dawna. Jednak ta zmiana nie odbyła się bez problemów. Z uwagi na to, iż Ethernet nie był projektowany do świadczenia usług WAN, pojawiły się problemy z MTU, obsługą wielu vlanów, QinQ, czy przesyłaniem ramek sterujących protokołów L2 (np. STP czy LACP). Wystąpiła potrzeba jasnego zdefiniowania co oczekiwane jest od usług WAN realizowanych za pomocą Ethernetu. Na rynku od wielu lat istnieje MEF (Metro Ethernet Forum), które utworzyło specyfikację usług realizowanych z użyciem Ethernetu. Ich dokumenty dokładnie specyfikują co musi być zrobione (ale co ważne nie specyfikuje jak ma to zostać zrobione) żeby uznać daną usługę za zgodną ze specyfikacją.

Ethernetowe usługi L2

E-Line, to najprostsza i zarazem najczęściej realizowana usługa. Innymi słowy to po prostu łącze punkt-punkt. Najprostsza realizacja takiej usługi to zwykły kabel ethernetowy – co „wleci” na jednym końcu, to „wyleci” na drugim. Oczywiście nikt nie zrealizuje dla klienta bezpośredniego kabla na odległość kilkuset czy kilku tysięcy kilometrów. W rzeczywistości ruch klienta będzie przechodził przez dziesiątki urządzeń aktywnych z wykorzystaniem różnych technologii (np. QinQ, MPLS, DWDM itd.), co implikuje najróżniejsze problemy.

Inne usługi wyszczególnione przez MEF to:

E-LAN, inaczej usługa typu wielopunkt-wielopunkt. Najprostsza implementacja to wiele kabli ethernetowych połączonych w jednym centralnym punkcie (switchu). Wszystkie końce usługi mogą komunikować się bezpośrednio ze wszystkimi innymi.

E-Tree, nazywana usługą punkt-wielopunkt (lub też „Hub and Spoke”). W tej usłudze węzeł centralny (Hub) może komunikować się ze wszystkimi pozostałymi węzłami (Spokes), jednak one nie mogą komunikować się bezpośrednio między sobą.

Usługi E-LAN i E-Tree wykorzystywane są rzadziej, a ich konfiguracja jest nieco bardziej skomplikowana niż E-Line. Z tych względów w dalszej części przyjrzymy się jedynie usłudze E-Line.

Ale jak to się ma do MiŚOTa?

Najczęściej MiŚOT jest liderem gęstości sieci na swoim terenie, jednak oprócz powszechnych usług dla abonentów i biznesu (Internet, telewizja), mało kiedy świadczy usługi transmisji danych dla podmiotów na swoim obszarze. Najczęściej operator skupia się na świadczeniu dostępu do ostatniej mili dla dużych operatorów tego rynku. Dzięki powstaniu inicjatywy MDO (lub generalnie rodziny inicjatyw MDx), może się to jednak zmienić. W przyszłości zrzeszeni mali operatorzy mogą świadczyć usługi dla banków czy instytucji publicznych, nie tylko w zakresie dostępu do Internetu. Dlatego też, specyfikacja MEF będzie podstawowym modelem odniesienia do tego jak powinna wyglądać usługa L2 realizowana przez ISP. Realizując usługi transmisji danych, każdy operator musi zdawać sobie sprawę z wyzwań jakie przed nim stoją. Nawet gdy usługa konfiguracyjnie wydaje się być prosta to wiele kwestii nadal wymaga odpowiedniego doprecyzowania.

Oto lista rzeczy, które dobrze jest przeanalizować przed rozpoczęciem świadczenia usługi L2.

Vlany – zestawienie zwykłego vlanu dla klienta zadziała tylko w przypadku podłączenia przez klienta routerów, (ew. jako rozszerzenie sieci LAN, jednak jest to rozwiązanie nie skalowalne i rzadko używane). Może się jednak zdarzyć, że klient chce przesłać przez łącze wiele vlanów (tj. trunk 802.1Q). W takiej sytuacji musimy tagowane ramki klienta przetransportować przez naszą sieć – najczęściej poprzez QinQ lub MPLS.

Translacja Vlanów – to już znany przypadek z projektu MDO. Często będzie zachodzić potrzeba zmiany numeru vlanu (czasami na prośbę klienta, ale głównie z uwagi na kolizję vlanów wewnątrz sieci ISP).

Stack vlanów (QinQ) i złożone operacje na tagach – o ile obsługa QinQ w tranzycie dla większości urządzeń nie jest problemem, to już rozszywanie QinQ na pojedyncze vlany, translacja C-vlanów, czy selektywne zdejmowanie i dokładnie tagów może sprawiać kłopoty. Może okazać się, że u klienta port ma przyjmować ruch z tagiem 400, i ruch ten za zostać oddany na punkcie styku (np. w EPIX) na podwójnym tagu np. 100, 300. Tu już konieczny będzie sprzęt Carrier Ethernet np. Cisco ASR 920 lub NCS 540.

Transparentność – Czyli jak usługa L2 będzie przenosić ramki. O ile transport „zwykłych” ramek tagowanych (czy podwójnie tagowanych) zwykle nie jest problem, to występują jednak ramki sterujące różnych protokołów L2, które często sprawiają ból głowy. Najczęściej spotykane to: SpanningTree, CDP/LLDP, PAgP, LACP, VTP i inne.

Czemu te ramki są tak problematyczne? Jednym przykładem może być sytuacja w której klient posiada dwa łącza L2 z których korzysta jako trunk. Aby zrealizować redundancję chce użyć protokołu STP. Switch ISP, zamiast przesłać ramki STP na drugi koniec łącza, domniema iż są to ramki skierowane do niego, i finalnie ramki nie zostają przesłane. Powoduje to powstanie pętli, gdyż STP „nie widzi” tego łącza.

Innym przykładem ramek sprawiających problemy to ramki LACP. Są to ramki służące negocjacji LAGów (PortChanneli, czyli wielu łącz sklejonych w jedno). W najlepszym przypadku zamiast obu łączy będzie wykorzystywane jedno, w najgorszym powstanie pętla.

Oczywiście najlepiej jest przesyłać jak najwięcej ramek L2 przez łącze, jednak czasem może okazać się że potrzebujemy nie tyle przesyłać co „rozmawiać” protokołami L2 z urządzeniami klienta. Przykładem może być właśnie LACP. W sytuacji, gdy klientowi dostarczamy łącza używając dwóch portów 1G złączonych w PortChannel. W takim przypadku potrzebujemy rozmawiać poprzez LACP z urządzeniami klienta aby zestawić LAGa, a nie przesyłać ramki LACP dalej (tzw. opcja peer a nie forward).

MTU – ponieważ transportujemy ramki Ethernet klienta, a w warstwie L2 nie ma fragmentacji ramek, musimy zapewnić, że cała ramka enkapsulowana w QinQ czy MPLS przejdzie na drugą stronę. Standardowe MTU to 1500 bajtów, jednak jeśli będzie to ramka tagowana to potrzebujemy już MTU przynajmniej 1504 bajtów obsługiwanego przez WSZYSTKIE urządzenia biorące udział w transmisji. Jednak w praktyce powinniśmy umożliwiać klientowi przesyłanie ramek z większym MTU (minimum 1508 bajtów na podwójnego taga 802.1Q).

Niestety problemy związane z MTU bywają bardzo trudne do identyfikacji. Pingi standardowego rozmiaru przechodzą bez problemu, jednak żadna strona www nie chce się załadować. Najlepiej po zestawieniu łącza przetestować MTU używając pinga o założonym rozmiarze MTU z flagą DF (Do Not Fragment).

Mogą zdarzyć się również wymagania na dużo większe MTU, np. 1600 bajtów gdy klient będzie szyfrować ruch z użyciem IPSEC, i jednocześnie chce utrzymać MTU 1500 dla pakietów szyfrowanych. Potrzeba bardzo dużego MTU (rzędu 8-9 tyś), pojawia się stosunkowo rzadko, jednakże jeżeli klient będzie używał protokołów Storage (np. iSCSI) to taka wartość jest w pełni uzasadniona.

Obecnie sprzęt mało kiedy stanowi ograniczenie w tej kwestii. Jednak może okazać się, że łącze przechodzi przez 10 urządzeń, z czego 3 są starszego typu i po zmianie MTU wymagają restartu. To wszystko trzeba zaplanować i wcześniej skonfigurować.

Pomiary – klienci coraz częściej wymagają wykonania pomiarów przed odbiorem łącza. Dawniej sytuacja była stosunkowa prosta, zwykle zakładano po jednej stronie łącza fizyczną pętlę a po drugiej podłączano miernik. W przypadku Ethernetowych łączy dzierżawionych jest nieco trudniej. Najprostszym rozwiązaniem było by wykonywanie pomiaru „miernik na miernik”, jednak wymaga to dwóch mierników, dwóch zaangażowanych osób itd. Niestety przy podejściu z zapętleniem jednego końca łącza wszystkie urządzenia po drodze będą widziały tę sytuację jako pętlę i może to spowodować uruchomienie mechanizmów zabezpieczających, które uniemożliwią przeprowadzenie pomiaru. Dodatkowo jeśli testowane łącze przechodzi przez inne podmioty (np. EPIX) może wystąpić czasowa blokada portu po wykryciu pętli. Jeśli jednak łącze realizowane jest za pomocą MPLS to problem ten nie występuje gdyż MPLS na łączach P2P nie uczy się MAC adresów.

Pętle na żądanie – Co w sytuacji gdy klient poprosi nas o wystawienie odpowiedniej pętli bo chce ze swojej lokalizacji wykonać pomiar? Istnieją na rynku specjalne urządzenia tzw. loop-terminatory, które tworzą fizyczną pętlę, niemniej dla Ethernetu potrzebujemy najczęściej pętli „inteligentnej” (która zamieni SRC-MAC z DST-MAC). Jednak dużo lepiej zorientować się czy wasze urządzenia tego nie potrafią. Np. popularne urządzenia Carrier Ethernet wśród MiŚOT jak Cisco ASR920 potrafią takie inteligentne pętle utworzyć zdalnie przy użyciu zaledwie kilku komend.

QoS – w szczególności policing. W przypadku oddawania kilku usług o różnych SLA na jednym porcie nie wystarczy „przycięcie” całościowe tego portu (policer musi rozróżniać usługi). Bardzo istotne jest także zapewnienie odpowiedniej jakości dla świadczonych usług L2 wewnątrz sieci ISP. Szczególnie jeśli ruch Internetowy transmitowany jest tymi samymi łączami tranzytowymi co usługi L2. W takim przypadku łącza dzierżawione mogą być wrażliwe na bursty czy ataki DDoS.

Jak widać kwestii, które należy rozważyć przy uruchamianiu łącza L2 dla klienta jest bardzo dużo. Jednak dobrej jakości łącza L2 mogą przynosić znacznie większe dochody, niż świadczenie jedynie zwykłego dostępu do Internetu, a zacieśnienie współpracy pomiędzy operatorami w zakresie wspólnego świadczenia usług transmisji L2 daje szanse na znaczy wzrost tego typu usług w najbliższym czasie.

Link do wersji opublikowanej w najnowszym wydaniu magazynu Ict Professional: https://bit.ly/2OdrGhV

Od samego początku naszej działalności stawialiśmy na profesjonalne podejście do naszych Klientów

Network w liczbach

0
lat na rynku
0
realizacji
0
Klientów
0
projektów powyżej 100,000zł

Od samego początku naszej działalności stawialiśmy na profesjonalne podejście do naszych Klientów

Network w liczbach

0
lat na rynku
0
realizacji
0
Klientów