Mo\u017cliwo\u015bci funkcjonalne \u2013 co jedna technologia potrafi, a inna nie? Czy to jest naprawd\u0119 wa\u017cne?<\/li>\n<\/ul>\n<\/p>\n
Na czym polegaj\u0105 r\u00f3\u017cnice architektoniczne i czy s\u0105 one istotne?<\/h3>\n \nW ka\u017cdej z wymienionych technologii znajduje si\u0119 wiele \"ruchomych cz\u0119\u015bci\", kt\u00f3re r\u00f3\u017cni\u0105 si\u0119 nie tylko rol\u0105, ale tak\u017ce zasadami wsp\u00f3\u0142pracy ze sob\u0105. To, jak przemy\u015blane s\u0105 te zasady, bezpo\u015brednio wp\u0142ywa na skalowalno\u015b\u0107, odporno\u015b\u0107 na awarie oraz og\u00f3ln\u0105 efektywno\u015b\u0107 rozwi\u0105zania. <\/p>\n
Przyjrzyjmy si\u0119 bardziej szczeg\u00f3\u0142owo r\u00f3\u017cnym aspektom architektury:<\/p>\n
Data-plane<\/b> \u2013 cz\u0119\u015b\u0107 rozwi\u0105zania odpowiedzialna za przesy\u0142anie ruchu u\u017cytkownik\u00f3w pomi\u0119dzy \u017ar\u00f3d\u0142em a odbiorc\u0105. W DMVPN i SD-WAN jest to zrealizowane w zasadzie identycznie na samych routerach bazuj\u0105cych na tunelach Multipoint GRE. R\u00f3\u017cnica polega na tym, na podstawie czego formowany jest niezb\u0119dny zestaw parametr\u00f3w tych tuneli:<\/p>\n\ndo DMVPN\/PfR<\/b> \u2013 to wy\u0142\u0105cznie dwupoziomowa hierarchia w\u0119z\u0142\u00f3w z topologi\u0105 typu \u201eGwiazda\u201d lub Hub-n-Spoke. Wymagana jest statyczna konfiguracja Huba i statyczne powi\u0105zanie Spoke z Hubem, a tak\u017ce wsp\u00f3\u0142praca z protoko\u0142em NHRP w celu utworzenia \u0142\u0105czno\u015bci data-plane. W rezultacie, zmiany na Hubie s\u0105 znacznie utrudnione,<\/b>np. zwi\u0105zane z zmieniaj\u0105cymi si\u0119 lub nowymi \u0142\u0105czami WAN lub zmian\u0105 parametr\u00f3w istniej\u0105cych.<\/li>\ndo SD-WAN<\/b> \u2013 to w pe\u0142ni dynamiczny model wykrywania parametr\u00f3w zak\u0142adanych tuneli oparty na control-plane (protoko\u0142y OMP) i orchestration-plane (interakcja z kontrolerem vBond w celu wykrywania kontroler\u00f3w i NAT traversal). Mo\u017cliwe s\u0105 dowolne na\u0142o\u017cone topologie, w tym hierarchiczne. W ramach ustalonej nak\u0142adanej topologii tuneli mo\u017cliwa jest elastyczna konfiguracja topologii logicznej w ka\u017cdym osobnym VPN(VRF).<\/li>\n<\/ul>\n Control-plane<\/b> \u2013 funkcje wymiany, filtrowania i modyfikacji informacji o trasach oraz innych danych pomi\u0119dzy komponentami rozwi\u0105zania. <\/p>\n\ndo DMVPN\/PfR<\/b> \u2013 odbywa si\u0119 wy\u0142\u0105cznie pomi\u0119dzy routerami Hub i Spoke. Bezpo\u015brednia wymiana informacji o trasach pomi\u0119dzy Spoke jest niemo\u017cliwa. W rezultacie, bez dzia\u0142aj\u0105cego Huba nie mo\u017cna funkcjonowa\u0107 w control-plane i data-plane.<\/b>, co nak\u0142ada na Hub dodatkowe wymagania dotycz\u0105ce wysokiej dost\u0119pno\u015bci, kt\u00f3re nie zawsze mog\u0105 by\u0107 spe\u0142nione.<\/li>\ndo SD-WAN<\/b> \u2013 komunikacja kontrolna nigdy nie odbywa si\u0119 bezpo\u015brednio mi\u0119dzy routerami \u2013 interakcja odbywa si\u0119 na podstawie protoko\u0142u OMP i zawsze jest realizowana przez osobny, wyspecjalizowany typ kontrolera vSmart, co zapewnia mo\u017cliwo\u015b\u0107 bilansowania, geo-redundancji i centralnego zarz\u0105dzania ruchem sygnalizacyjnym. Inn\u0105 cech\u0105 protoko\u0142u OMP jest jego znacz\u0105ca odporno\u015b\u0107 na straty i niezale\u017cno\u015b\u0107 od pr\u0119dko\u015bci \u0142\u0105cza z kontrolerami (w rozs\u0105dnych granicach, oczywi\u015bcie). To r\u00f3wnie skutecznie pozwala na umieszczanie kontroler\u00f3w SD-WAN w chmurach publicznych lub prywatnych z dost\u0119pem przez Internet.<\/li>\n<\/ul>\n Policy-plane<\/b> \u2013 cz\u0119\u015b\u0107 rozwi\u0105zania odpowiedzialna za definiowanie, rozpowszechnianie i stosowanie polityk zarz\u0105dzania ruchem w rozproszonej sieci.<\/p>\n\nDMVPN <\/b>\u2013 w rzeczywisto\u015bci ograniczone politykami jako\u015bci us\u0142ug (QoS), ustawianymi indywidualnie na ka\u017cdym routerze przez CLI lub szablony Prime Infrastructure.<\/li>\nDMVPN\/PfR<\/b> \u2013 polityki PfR s\u0105 tworzone na scentralizowanym routerze Master Controller (MC) przez CLI i nast\u0119pnie automatycznie rozpowszechniane do lokalnych MC. W tym przypadku u\u017cywane s\u0105 te same \u015bcie\u017cki transmisji polityk, co dla data-plane. Nie ma mo\u017cliwo\u015bci rozdzielenia wymiany polityk, informacji o trasach i danych u\u017cytkownik\u00f3w. Rozpowszechnianie polityk zak\u0142ada obowi\u0105zkow\u0105 obecno\u015b\u0107 IP po\u0142\u0105czenia mi\u0119dzy Hub a Spoke. Przy tym funkcja MC mo\u017ce by\u0107 w razie potrzeby \u0142\u0105czona z routerem DMVPN. Mo\u017cliwe (ale nie wymagane) jest u\u017cycie szablon\u00f3w Prime Infrastructure do centralnego tworzenia polityk. Wa\u017cn\u0105 cech\u0105 jest to, \u017ce polityka jest tworzona globalnie w ca\u0142ej sieci w ten sam spos\u00f3b \u2013 indywidualne polityki dla poszczeg\u00f3lnych segment\u00f3w nie s\u0105 wspierane.<\/b>.<\/li>\nSD-WAN<\/b> Polityka zarz\u0105dzania ruchem i jako\u015bci\u0105 us\u0142ug jest okre\u015blana centralnie za pomoc\u0105 interfejsu graficznego Cisco vManage, dost\u0119pnego r\u00f3wnie\u017c przez Internet (je\u015bli zajdzie taka potrzeba). Rozprzestrzenia si\u0119 przez kana\u0142y sygna\u0142owe bezpo\u015brednio lub po\u015brednio przez kontrolery vSmart (w zale\u017cno\u015bci od rodzaju polityki). Nie zale\u017cy od \u0142\u0105czno\u015bci data-plane mi\u0119dzy routerami, poniewa\u017c wykorzystuje wszystkie dost\u0119pne \u015bcie\u017cki przesy\u0142ania ruchu mi\u0119dzy kontrolerem a routerem.\n Dla r\u00f3\u017cnych segment\u00f3w sieci mo\u017cliwe jest elastyczne formu\u0142owanie r\u00f3\u017cnorodnych polityk \u2013 zakres stosowania polityki jest okre\u015blany przez wiele unikalnych identyfikator\u00f3w przewidzianych w rozwi\u0105zaniu \u2013 numer oddzia\u0142u, typ aplikacji, kierunek ruchu itp.\n<\/li>\n<\/ul>\n
Orkiestracja<\/b> \u2013 mechanizmy umo\u017cliwiaj\u0105ce komponentom dynamiczne odkrywanie si\u0119 nawzajem, konfigurowanie i koordynowanie dalszej interakcji.<\/p>\n\ndo DMVPN\/PfR<\/b> Wzajemne odkrywanie router\u00f3w opiera si\u0119 na statycznej konfiguracji urz\u0105dze\u0144 Hub i odpowiednich ustawieniach urz\u0105dze\u0144 Spoke. Dynamiczne odkrywanie ma miejsce tylko dla Spoke, kt\u00f3ry informuje o swoich parametrach po\u0142\u0105czenia urz\u0105dzenie Hub, kt\u00f3re z kolei jest wcze\u015bniej wprowadzone do konfiguracji Spoke. Bez \u0142\u0105czno\u015bci IP Spoke z przynajmniej jednym Hubem niemo\u017cliwe jest utworzenie ani data-plane, ani control-plane.<\/b><\/li>\ndo SD-WAN<\/b> Orkiestracja komponent\u00f3w rozwi\u0105zania zachodzi przy u\u017cyciu kontrolera vBond, z kt\u00f3rym ka\u017cdy komponent (routery i kontrolery vManage\/vSmart) musi najpierw nawi\u0105za\u0107 \u0142\u0105czno\u015b\u0107 IP.\n Pocz\u0105tkowo komponenty nie znaj\u0105 parametr\u00f3w po\u0142\u0105czenia z innymi \u2013 potrzebuj\u0105 do tego po\u015brednika-orkiestratora vBond. Og\u00f3lna zasada jest nast\u0119puj\u0105ca \u2013 ka\u017cdy komponent na wst\u0119pnym etapie dowiaduje si\u0119 (automatycznie lub statycznie) tylko o parametrach po\u0142\u0105czenia z vBond, a nast\u0119pnie vBond informuje router o kontrolerach vManage i vSmart (wcze\u015bniej odkrytych), co umo\u017cliwia automatyczne ustanowienie wszystkich niezb\u0119dnych po\u0142\u0105cze\u0144 sygna\u0142owych. <\/p>\n
Nast\u0119pnym krokiem nowy router dowiaduje si\u0119 o pozosta\u0142ych routerach w sieci poprzez wymian\u0119 OMP z kontrolerem vSmart. Dzi\u0119ki temu router, nie znaj\u0105c z g\u00f3ry parametr\u00f3w sieci, jest w stanie ca\u0142kowicie automatycznie odkry\u0107 i po\u0142\u0105czy\u0107 si\u0119 z kontrolerami, a nast\u0119pnie r\u00f3wnie\u017c automatycznie odkry\u0107 i utworzy\u0107 po\u0142\u0105czenie z pozosta\u0142ymi routerami. Przy tym parametry po\u0142\u0105cze\u0144 wszystkich komponent\u00f3w s\u0105 pocz\u0105tkowo nieznane i w trakcie eksploatacji mog\u0105 si\u0119 zmienia\u0107.\n<\/li>\n<\/ul>\n
P\u0142aszczyzna zarz\u0105dzania<\/b> \u2013 cz\u0119\u015b\u0107 rozwi\u0105zania zapewniaj\u0105ca centralne zarz\u0105dzanie i monitorowanie.<\/p>\n\nDMVPN\/PfR<\/b> \u2013 nie przewiduje si\u0119 specjalizowanego rozwi\u0105zania dla p\u0142aszczyzny zarz\u0105dzania. Do podstawowej automatyzacji i monitorowania mo\u017cna wykorzysta\u0107 takie produkty, jak Cisco Prime Infrastructure. Ka\u017cdy router ma mo\u017cliwo\u015b\u0107 zarz\u0105dzania przez interfejs wiersza polece\u0144 CLI. Integracje z zewn\u0119trznymi systemami przez API nie s\u0105 przewidziane.<\/b><\/li>\nSD-WAN<\/b> \u2013 ca\u0142e standardowe interakcje i monitorowanie odbywaj\u0105 si\u0119 centralnie przez graficzny interfejs kontrolera vManage. Wszystkie funkcjonalno\u015bci rozwi\u0105zania bez wyj\u0105tku s\u0105 dost\u0119pne do konfiguracji przez vManage oraz przez w pe\u0142ni udokumentowan\u0105 bibliotek\u0119 interfejsu programistycznego REST API.\n Wszystkie ustawienia sieci SD-WAN w vManage sprowadzaj\u0105 si\u0119 do dw\u00f3ch g\u0142\u00f3wnych konstrukcji \u2013 tworzenia szablon\u00f3w urz\u0105dze\u0144 (Device Template) i tworzenia polityki, kt\u00f3ra okre\u015bla logik\u0119 dzia\u0142ania sieci i przetwarzania ruchu. Przy tym vManage, transmituj\u0105c polityk\u0119 uformowan\u0105 przez administratora, automatycznie wybiera jakie zmiany i na jakich indywidualnych urz\u0105dzeniach\/kontrolerach nale\u017cy wprowadzi\u0107, co znacznie zwi\u0119ksza efektywno\u015b\u0107 i skalowalno\u015b\u0107 rozwi\u0105zania.<\/p>\n
Przez interfejs vManage dost\u0119pna jest nie tylko konfiguracja rozwi\u0105zania Cisco SD-WAN, ale tak\u017ce pe\u0142ne monitorowanie stanu wszystkich komponent\u00f3w rozwi\u0105zania, a\u017c do aktualnego stanu metryk poszczeg\u00f3lnych tuneli oraz statystyk wykorzystania r\u00f3\u017cnych aplikacji na podstawie analizy DPI.<\/p>\n
Mimo zcentralizowanej interakcji, wszystkie komponenty (kontrolery i routery) posiadaj\u0105 pe\u0142noprawny interfejs wiersza polece\u0144 CLI, kt\u00f3ry jest niezb\u0119dny na etapie wdra\u017cania lub w przypadku sytuacji wyj\u0105tkowych do lokalnej diagnostyki. W trybie normalnym (przy istnieniu kana\u0142u sygna\u0142owego mi\u0119dzy komponentami) na routerach interfejs wiersza polece\u0144 jest dost\u0119pny tylko do cel\u00f3w diagnostycznych i nie jest dost\u0119pny do wprowadzania lokalnych zmian, co zapewnia zar\u00f3wno lokalne bezpiecze\u0144stwo, jak i jedyne \u017ar\u00f3d\u0142o zmian w takiej sieci \u2013 vManage.<\/li>\n<\/ul>\n
\nZintegrowane bezpiecze\u0144stwo<\/b> \u2013 w tym przypadku nale\u017cy m\u00f3wi\u0107 nie tylko o ochronie danych u\u017cytkownik\u00f3w podczas przesy\u0142ania przez otwarte kana\u0142y, ale tak\u017ce o og\u00f3lnym bezpiecze\u0144stwie sieci WAN opartej na wybranej technologii.<\/p>\n\ndo DMVPN\/PfR<\/b> przewiduje si\u0119 mo\u017cliwo\u015b\u0107 szyfrowania danych u\u017cytkownik\u00f3w i protoko\u0142\u00f3w sygna\u0142owych. Przy u\u017cyciu okre\u015blonych modeli router\u00f3w dodatkowo dost\u0119pne s\u0105 funkcje zapory sieciowej z inspekcj\u0105 ruchu, IPS\/IDS. Istnieje mo\u017cliwo\u015b\u0107 segmentacji sieci oddzia\u0142owych z wykorzystaniem VRF. Istnieje mo\u017cliwo\u015b\u0107 uwierzytelniania (jednoetapowego) protoko\u0142\u00f3w kontrolnych.\n Przy tym zdalny router domy\u015blnie uznawany jest za zaufany element sieci \u2013 tzn. nie przewiduje si\u0119 i nie uwzgl\u0119dnia przypadk\u00f3w fizycznej kompromitacji poszczeg\u00f3lnych urz\u0105dze\u0144 oraz mo\u017cliwo\u015bci nieautoryzowanego dost\u0119pu do nich, nie ma uwierzytelniania dwusk\u0142adnikowego komponent\u00f3w rozwi\u0105zania, co w przypadku geograficznie rozproszonej sieci mo\u017ce wi\u0105za\u0107 si\u0119 z powa\u017cnymi dodatkowymi ryzykami.<\/b> <\/li>\ndo SD-WAN<\/b> na wz\u00f3r DMVPN przewidziano mo\u017cliwo\u015b\u0107 szyfrowania danych u\u017cytkownik\u00f3w, ale z znacznie rozszerzonymi funkcjami bezpiecze\u0144stwa sieci i segmentacji L3\/VRF (MSE, IPS\/IDS, filtrowanie URL, filtrowanie DNS, AMP\/TG, SASE, proxy TLS\/SSL itp.). Przy tym wymiana kluczy szyfrowania odbywa si\u0119 bardziej efektywnie przez kontrolery vSmart (a nie bezpo\u015brednio), przez wcze\u015bniej ustalone kana\u0142y sygna\u0142owe, chronione szyfrowaniem DTLS\/TLS na podstawie certyfikat\u00f3w bezpiecze\u0144stwa. Co z kolei gwarantuje bezpiecze\u0144stwo tej wymiany i zapewnia lepsz\u0105 skalowalno\u015b\u0107 rozwi\u0105zania nawet do dziesi\u0105tek tysi\u0119cy urz\u0105dze\u0144 w jednej sieci.\n Wszystkie po\u0142\u0105czenia sygna\u0142owe (kontroler-kontroler, kontroler-router) s\u0105 r\u00f3wnie\u017c zabezpieczone na podstawie DTLS\/TLS. Routery s\u0105 wyposa\u017cane w certyfikaty bezpiecze\u0144stwa podczas produkcji z mo\u017cliwo\u015bci\u0105 wymiany\/odnowienia. Podw\u00f3jna weryfikacja to\u017csamo\u015bci osi\u0105gana jest poprzez jednoczesne spe\u0142nienie dw\u00f3ch warunk\u00f3w dla funkcjonowania routera\/kontrolera w sieci SD-WAN:<\/p>\n
\nAktywny certyfikat bezpiecze\u0144stwa<\/li>\n Jawne i \u015bwiadome dodawanie przez administratora ka\u017cdego komponentu do bia\u0142ej listy dozwolonych urz\u0105dze\u0144.<\/li>\n<\/ul>\n\n<\/li>\n<\/ul>\n
Funkcjonalne r\u00f3\u017cnice mi\u0119dzy SD-WAN a DMVPN\/PfR<\/h2>\n \nPrzechodz\u0105c do om\u00f3wienia r\u00f3\u017cnic funkcjonalnych, nale\u017cy zaznaczy\u0107, \u017ce wiele z nich stanowi kontynuacj\u0119 r\u00f3\u017cnic architektonicznych \u2013 nie jest tajemnic\u0105, \u017ce przy formu\u0142owaniu architektury rozwi\u0105zania, deweloperzy bazuj\u0105 na mo\u017cliwo\u015bciach, kt\u00f3re chc\u0105 uzyska\u0107 na ko\u0144cu. Przyjrzyjmy si\u0119 najwa\u017cniejszym r\u00f3\u017cnicom mi\u0119dzy tymi dwiema technologiami.<\/p>\n
AppQ (Jako\u015b\u0107 Aplikacji) \u2013 funkcje zapewnienia jako\u015bci transmisji ruchu aplikacji biznesowych<\/h3>\n \nKluczowe funkcje rozwa\u017canych technologii maj\u0105 na celu, w miar\u0119 mo\u017cliwo\u015bci, popraw\u0119 do\u015bwiadcze\u0144 u\u017cytkownik\u00f3w podczas korzystania z aplikacji krytycznych dla biznesu w zdystrybuowanej sieci. Jest to szczeg\u00f3lnie istotne w warunkach, gdy cz\u0119\u015b\u0107 infrastruktury nie jest kontrolowana przez IT lub nie gwarantuje pomy\u015blnej transmisji danych.<\/p>\n
DMVPN samodzielnie nie zapewnia takich mechanizm\u00f3w. Najlepsze, co mo\u017cna zrobi\u0107 w klasycznej sieci DMVPN, to klasyfikowa\u0107 wychodz\u0105cy ruch wed\u0142ug aplikacji i priorytetowa\u0107 go podczas przesy\u0142ania w kierunku kana\u0142u WAN. Wyb\u00f3r tunelu DMVPN w tym przypadku jest uzale\u017cniony jedynie od jego dost\u0119pno\u015bci oraz wynik\u00f3w dzia\u0142ania protoko\u0142\u00f3w trasowania. Przy tym w \u017caden spos\u00f3b nie uwzgl\u0119dnia si\u0119 stanu \u0142\u0105czno\u015bci tunelu i jego ewentualnej cz\u0119\u015bciowej degradacji z punktu widzenia kluczowych metryk istotnych dla aplikacji sieciowych \u2013 op\u00f3\u017anienia, wariacji op\u00f3\u017anienia (jitter) i strat (%). W zwi\u0105zku z tym bezpo\u015brednie por\u00f3wnywanie klasycznego DMVPN z SD-WAN w kontek\u015bcie rozwi\u0105zywania problem\u00f3w AppQ traci sens \u2013 DMVPN nie mo\u017ce rozwi\u0105za\u0107 tego problemu. Wprowadzenie w ten kontekst technologii Cisco Performance Routing (PfR) zmienia sytuacj\u0119, a por\u00f3wnanie z Cisco SD-WAN staje si\u0119 bardziej zasadne. <\/p>\n
Zanim przejdziemy do om\u00f3wienia r\u00f3\u017cnic, kr\u00f3tko o tym, w czym technologie s\u0105 podobne. Tak wi\u0119c obie technologie:<\/p>\n
\nmaj\u0105 mechanizm, kt\u00f3ry pozwala na dynamiczn\u0105 ocen\u0119 stanu ka\u017cdego zainstalowanego tunelu w odniesieniu do okre\u015blonych metryk \u2013 przynajmniej op\u00f3\u017anienia, wariacji op\u00f3\u017anienia i straty pakiet\u00f3w (%)<\/li>\n u\u017cywaj\u0105 okre\u015blonego zestawu narz\u0119dzi do tworzenia, rozpowszechniania i stosowania regu\u0142 (polityk) zarz\u0105dzania ruchem z uwzgl\u0119dnieniem wyniku pomiaru stanu kluczowych metryk tuneli.<\/li>\n klasyfikuj\u0105 ruch aplikacji na poziomach L3-L4 (DSCP) modelu OSI lub wed\u0142ug sygnatur L7 aplikacji na podstawie wbudowanych w router mechanizm\u00f3w DPI.<\/li>\n pozwalaj\u0105 zdefiniowa\u0107 akceptowalne warto\u015bci progowe metryk dla znacz\u0105cych aplikacji, domy\u015blne regu\u0142y przesy\u0142ania ruchu, regu\u0142y przekierowywania ruchu, gdy progowe warto\u015bci s\u0105 przekraczane.<\/li>\n podczas enkapsulacji ruchu w GRE\/IPSec stosuj\u0105 ju\u017c ustabilizowany w bran\u017cy mechanizm przenoszenia wewn\u0119trznego oznaczenia DSCP do zewn\u0119trznego nag\u0142\u00f3wka pakietu GRE\/IPSEC, co pozwala synchronizowa\u0107 polityki QoS organizacji i operatora telekomunikacyjnego (przy istnieniu odpowiedniego SLA).<\/li>\n<\/ul>\n\n
Jak r\u00f3\u017cni\u0105 si\u0119 mechanizmy oceny metryk end-to-end SD-WAN i DMVPN\/PfR?<\/h3>\n \nDMVPN\/PfR <\/b><\/p>\n\nDo oceny standardowych metryk stanu tunelu wykorzystuje si\u0119 zar\u00f3wno aktywne, jak i pasywnie programowe czujniki (Probes). Aktywne \u2013 na podstawie ruchu u\u017cytkownik\u00f3w, pasywne emuluj\u0105 taki ruch (w jego braku). <\/li>\n Drobna regulacja timer\u00f3w i warunk\u00f3w wykrywania degradacji jest nieobecna \u2013 algorytm jest sta\u0142y.<\/li>\n Dodatkowo dost\u0119pne jest pomiar u\u017cywanej przepustowo\u015bci w kierunku wychodz\u0105cym. Co dodaje DMVPN\/PfR dodatkow\u0105 elastyczno\u015b\u0107 zarz\u0105dzania ruchem.<\/li>\n W tym przypadku niekt\u00f3re mechanizmy PfR w przypadku przekroczenia metryk polegaj\u0105 na zwrotnej sygnalizacji w postaci specjalnych komunikat\u00f3w TCA (Threshold Crossing Alert), kt\u00f3re powinny pochodzi\u0107 od odbiorcy ruchu w kierunku \u017ar\u00f3d\u0142a, co z kolei sugeruje, \u017ce stany mierzone kana\u0142y powinny by\u0107 przynajmniej wystarczaj\u0105ce do przesy\u0142ania takich komunikat\u00f3w TCA. Co w wi\u0119kszo\u015bci przypadk\u00f3w nie stanowi problemu, ale oczywi\u015bcie nie mo\u017ce by\u0107 gwarantowane. <\/li>\n<\/ul>\n\nSD-WAN <\/b><\/p>\n\nDo oceny standardowych metryk stanu tunelu w trybie echo u\u017cywany jest protok\u00f3\u0142 BFD. W tym przypadku nie jest wymagana specjalna informacja zwrotna w postaci TCA lub podobnych komunikat\u00f3w \u2013 zachowywana jest izolacja domen awarii. Nie jest r\u00f3wnie\u017c konieczna obecno\u015b\u0107 ruchu u\u017cytkownika do oceny stanu tunelu.<\/li>\n Istnieje mo\u017cliwo\u015b\u0107 zaawansowanego dostosowania timer\u00f3w BFD do regulacji pr\u0119dko\u015bci wyzwalania i reakcji algorytmu na degradacj\u0119 \u0142\u0105cza od kilku sekund do minut.\n
W momencie pisania artyku\u0142u w ka\u017cdym z tuneli przewidziana jest tylko jedna sesja BFD. Potencjalnie mo\u017ce to stworzy\u0107 mniejsz\u0105 granularno\u015b\u0107 przy analizie stanu tunelu. W praktyce mo\u017ce to sta\u0107 si\u0119 ograniczeniem tylko w przypadku wykorzystania po\u0142\u0105czenia WAN opartego na MPLS L2\/L3 VPN z uzgodnionym SLA QoS \u2014 je\u017celi znakowanie DSCP ruchu BFD (po enkapsulacji w IPSec\/GRE) zgadza si\u0119 z kolejk\u0105 o wysokim priorytecie w sieci operatora, mo\u017ce to wp\u0142yn\u0105\u0107 na dok\u0142adno\u015b\u0107 i szybko\u015b\u0107 wykrywania degradacji dla ruchu niskoprzywilejowanego. Istnieje jednak mo\u017cliwo\u015b\u0107 zmiany domy\u015blnego znakowania BFD w celu zmniejszenia ryzyka wyst\u0105pienia takich sytuacji. W nast\u0119pnych wersjach oprogramowania Cisco SD-WAN oczekiwane jest wprowadzenie bardziej zaawansowanego dostosowania BFD oraz mo\u017cliwo\u015b\u0107 uruchomienia kilku sesji BFD w ramach jednego tunelu z indywidualnymi warto\u015bciami DSCP (dla r\u00f3\u017cnych aplikacji).<\/li>\n BFD umo\u017cliwia r\u00f3wnie\u017c ocen\u0119 maksymalnego rozmiaru pakietu, kt\u00f3ry mo\u017cna przes\u0142a\u0107 przez dany tunel bez fragmentacji. Pozwala to SD-WAN dynamicznie dostosowa\u0107 takie parametry, jak MTU i TCP MSS Adjust, aby maksymalnie efektywnie wykorzysta\u0107 dost\u0119pne pasmo na ka\u017cdym kanale.<\/li>\n W SD-WAN dost\u0119pna jest tak\u017ce opcja synchronizacji QoS z operatorami nie tylko na podstawie pola L3 DSCP, ale r\u00f3wnie\u017c na podstawie warto\u015bci L2 CoS, kt\u00f3re mog\u0105 by\u0107 automatycznie formowane w sieci lokalnej przez specjalistyczne urz\u0105dzenia \u2014 na przyk\u0142ad, telefony IP.<\/li>\n<\/ul>\n<\/p>\n
Jak r\u00f3\u017cni\u0105 si\u0119 mo\u017cliwo\u015bci, metody okre\u015blania i stosowania polityk AppQ?<\/h3>\n <\/p>\n
Polityki DMVPN\/PfR:<\/h4>\n <\/p>\n
\nOkre\u015blane na routerze(-ach) centralnej siedziby (CFS) za pomoc\u0105 interfejsu wiersza polece\u0144 CLI lub szablon\u00f3w konfiguracji CLI. Tworzenie szablon\u00f3w CLI wymaga przygotowania i znajomo\u015bci sk\u0142adni polityk.\n
Okre\u015blone globalnie bez mo\u017cliwo\u015bci indywidualnej konfiguracji\/zmiany zgodnie z wymaganiami poszczeg\u00f3lnych segment\u00f3w sieci.<\/b><\/li>\nInteraktywne tworzenie polityk w interfejsie graficznym nie jest przewidziane.<\/li>\n \u015aledzenie zmian, dziedziczenie, tworzenie wielu wersji polityk do szybkiego prze\u0142\u0105czania nie jest przewidziane.<\/li>\n S\u0105 automatycznie rozpowszechniane na routery zdalnych oddzia\u0142\u00f3w. U\u017cywaj\u0105 tych samych kana\u0142\u00f3w komunikacyjnych, co do przesy\u0142ania danych u\u017cytkownik\u00f3w. W przypadku braku kana\u0142u komunikacyjnego mi\u0119dzy central\u0105 a zdalnym oddzia\u0142em, rozpowszechnienie\/zmiana polityk jest niemo\u017cliwe.<\/li>\n Stosowane na ka\u017cdym routerze i w razie potrzeby modyfikuj\u0105 wyniki standardowych protoko\u0142\u00f3w routingu, maj\u0105c wy\u017cszy priorytet. <\/li>\n W przypadkach, gdy wszystkie kana\u0142y WAN oddzia\u0142u do\u015bwiadczaj\u0105 znacznych strat ruchu, mechanizmy rekompensacji nie s\u0105 przewidziane<\/b>.<\/li>\n<\/ul>\n <\/p>\n
Polityki SD-WAN:<\/h4>\n <\/p>\n
\nOkre\u015blane w interfejsie graficznym vManage za pomoc\u0105 interaktywnego kreatora szablon\u00f3w.<\/li>\n Wspieraj\u0105 tworzenie wielu polityk, kopiowanie, dziedziczenie, prze\u0142\u0105czanie mi\u0119dzy politykami w czasie rzeczywistym.<\/li>\n Wspieraj\u0105 indywidualn\u0105 konfiguracj\u0119 polityk dla r\u00f3\u017cnych segment\u00f3w (oddzia\u0142\u00f3w) sieci<\/li>\n Rozpowszechniane, wykorzystuj\u0105c jakikolwiek dost\u0119pny kana\u0142 sygna\u0142owy mi\u0119dzy kontrolerem a routerem i\/lub vSmart \u2013 nie s\u0105 bezpo\u015brednio zale\u017cne od \u0142\u0105czno\u015bci data-plane mi\u0119dzy routerami. Wymagana jest jednak \u0142\u0105czno\u015b\u0107 IP mi\u0119dzy samym routerem a kontrolerami.\n
W przypadkach, gdy wszystkie dost\u0119pne kana\u0142y oddzia\u0142u do\u015bwiadczaj\u0105 znacznych strat danych, przekraczaj\u0105cych dopuszczalne warto\u015bci progowe dla krytycznych aplikacji, mo\u017cliwe jest wykorzystanie dodatkowych mechanizm\u00f3w zwi\u0119kszaj\u0105cych niezawodno\u015b\u0107 przesy\u0142u:\n\nFEC (Korekcja b\u0142\u0119d\u00f3w na poziomie przekazywania)<\/b> \u2013 wykorzystuje specjalny algorytm nadmiarowego kodowania. Przy przesy\u0142aniu krytycznego ruchu przez kana\u0142y o znacznych procentach strat, FEC mo\u017ce by\u0107 automatycznie aktywowany i pozwala na ewentualne przywr\u00f3cenie utraconej cz\u0119\u015bci danych. Przy tym niewielko zwi\u0119ksza si\u0119 wykorzystywana szeroko\u015b\u0107 pasma, ale znacznie zwi\u0119ksza niezawodno\u015b\u0107.\n
Duplicacja strumieni danych<\/b> Opr\u00f3cz FEC polityka mo\u017ce przewidywa\u0107 automatyczne duplikowanie ruchu wybranych aplikacji w przypadku jeszcze powa\u017cniejszych strat, kt\u00f3rych nie da si\u0119 skompensowa\u0107 za pomoc\u0105 FEC. W takim przypadku wybrane dane b\u0119d\u0105 przesy\u0142ane przez wszystkie tunele w kierunku filii odbiorczej, z p\u00f3\u017aniejszym odduplication (odrzucaniem zb\u0119dnych kopii pakiet\u00f3w). Mechanizm znacz\u0105co zwi\u0119ksza wykorzystanie kana\u0142\u00f3w, ale tak\u017ce znacznie podnosi niezawodno\u015b\u0107 przesy\u0142u.<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n <\/p>\n
Mo\u017cliwo\u015bci Cisco SD-WAN, bez bezpo\u015brednich odpowiednik\u00f3w w DMVPN\/PfR<\/h3>\n \nArchitektura rozwi\u0105zania Cisco SD-WAN w niekt\u00f3rych przypadkach pozwala na uzyskanie mo\u017cliwo\u015bci, kt\u00f3rych realizacja w ramach DMVPN\/PfR jest albo niezwykle trudna, albo nieop\u0142acalna ze wzgl\u0119du na konieczne nak\u0142ady pracy, albo w og\u00f3le niemo\u017cliwa. Przyjrzyjmy si\u0119 najciekawszym z nich:<\/p>\n
In\u017cynieria ruchu (TE)<\/h4>\n \nTE obejmuje mechanizmy, kt\u00f3re pozwalaj\u0105 na odga\u0142\u0119zianie ruchu od standardowej \u015bcie\u017cki, uformowanej przez protoko\u0142y routingu. TE jest cz\u0119sto wykorzystywana do zapewnienia wysokiej dost\u0119pno\u015bci us\u0142ug sieciowych, dzi\u0119ki zdolno\u015bci do szybkiego i\/lub wcze\u015bniejszego przekierowania istotnego ruchu na alternatywn\u0105 (nieprzecinaj\u0105c\u0105 si\u0119) \u015bcie\u017ck\u0119 przesy\u0142u, w celu zapewnienia lepszej jako\u015bci us\u0142ugi lub szybko\u015bci jej przywracania w przypadku awarii na g\u0142\u00f3wnym szlaku. <\/p>\n
Wyzwanie zwi\u0105zane z wdro\u017ceniem TE polega na konieczno\u015bci wcze\u015bniejszego obliczenia i zarezerwowania (sprawdzenia) alternatywnej \u015bcie\u017cki. W sieciach MPLS operator\u00f3w telekomunikacyjnych problem ten rozwi\u0105zuj\u0105, wykorzystuj\u0105c takie technologie jak MPLS Traffic Engineering z rozszerzeniami protoko\u0142\u00f3w IGP i RSVP. Ostatnio rosn\u0105c\u0105 popularno\u015b\u0107 zyskuje technologia Segment Routing, kt\u00f3ra jest lepiej zoptymalizowana do centralnej konfiguracji i orkiestracji. W klasycznych sieciach WAN technologie te zazwyczaj nie s\u0105 dost\u0119pne lub ograniczaj\u0105 si\u0119 do mechanizm\u00f3w hop-by-hop, takich jak Policy-Based Routing (PBR), kt\u00f3re mog\u0105 przekierowa\u0107 ruch, ale realizuj\u0105 to na ka\u017cdym routerze z osobna \u2014 bez uwzgl\u0119dnienia og\u00f3lnego stanu sieci lub wyniku PBR na poprzednich lub kolejnych krokach. Rezultat zastosowania tych wariant\u00f3w TE jest niezadowalaj\u0105cy \u2014 MPLS TE, ze wzgl\u0119du na skomplikowan\u0105 konfiguracj\u0119 i eksploatacj\u0119, zazwyczaj stosuje si\u0119 tylko w najbardziej krytycznych cz\u0119\u015bciach sieci (j\u0105dro), a PBR u\u017cywa si\u0119 na poszczeg\u00f3lnych routerach bez mo\u017cliwo\u015bci stworzenia jednorodnej polityki PBR w ca\u0142ej sieci. Oczywiste, \u017ce dotyczy to r\u00f3wnie\u017c sieci opartych na DMVPN.<\/p>\n
Service-chaining (Sercisowe \u0142a\u0144cuchy) <\/h4>\n \nTworzenie \u0142a\u0144cuch\u00f3w us\u0142ug to znacznie bardziej pracoch\u0142onne zadanie w klasycznym routingu ni\u017c wcze\u015bniej opisany mechanizm Traffic-Engineering. W tym przypadku trzeba nie tylko stworzy\u0107 specjaln\u0105 tras\u0119 dla okre\u015blonej aplikacji sieciowej, ale r\u00f3wnie\u017c zapewni\u0107 mo\u017cliwo\u015b\u0107 wydobywania ruchu z sieci na okre\u015blonych (lub wszystkich) w\u0119z\u0142ach sieci SD-WAN, aby by\u0142 on przetwarzany przez specjaln\u0105 aplikacj\u0119 lub us\u0142ug\u0119 (MPLS, Balansowanie, Kaskadowanie, Inspekcja ruchu itp.). Nale\u017cy przy tym mie\u0107 mo\u017cliwo\u015b\u0107 monitorowania stanu tych zewn\u0119trznych us\u0142ug, aby unika\u0107 sytuacji black-holing, a tak\u017ce potrzebne s\u0105 mechanizmy pozwalaj\u0105ce umieszcza\u0107 takie jednorodne zewn\u0119trzne us\u0142ugi w r\u00f3\u017cnych lokalizacjach geograficznych z mo\u017cliwo\u015bci\u0105 automatycznego wyboru najbardziej optymalnego w\u0119z\u0142a serwisowego do przetwarzania ruchu dla danego oddzia\u0142u. W przypadku Cisco SD-WAN mo\u017cna to osi\u0105gn\u0105\u0107 stosunkowo \u0142atwo, tworz\u0105c odpowiedni\u0105 centraln\u0105 polityk\u0119, kt\u00f3ra \u201epo\u0142\u0105czy\u201d wszystkie aspekty docelowego \u0142a\u0144cucha us\u0142ug w ca\u0142o\u015b\u0107 i automatycznie zmieni logik\u0119 data-plane i control-plane tylko tam i wtedy, gdzie jest to potrzebne.<\/p>\n
Co z tego wynika?<\/h2>\n \nOczywi\u015bcie zar\u00f3wno DMVPN (wsp\u00f3lnie lub bez Performance Routing), jak i Cisco SD-WAN rozwi\u0105zuj\u0105 w ko\u0144cu bardzo podobne zadania<\/b> w odniesieniu do rozproszonej sieci WAN organizacji. Przy tym istotne r\u00f3\u017cnice architektoniczne i funkcjonalne technologii Cisco SD-WAN podnosz\u0105 proces rozwi\u0105zywania tych zada\u0144 na wy\u017cszy, jako\u015bciowy poziom<\/b>. Podsumowuj\u0105c, mo\u017cna wskaza\u0107 na nast\u0119puj\u0105ce istotne r\u00f3\u017cnice mi\u0119dzy technologiami SD-WAN i DMVPN\/PfR:<\/p>\n\nDMVPN\/PfR w zasadzie korzystaj\u0105 ze sprawdzonych technologii budowy nak\u0142adanych sieci VPN, a w zakresie data-plane s\u0105 podobne do nowocze\u015bniejszej technologii SD-WAN, z pewnymi ograniczeniami w postaci obowi\u0105zkowej statycznej konfiguracji router\u00f3w oraz ograniczonymi topologiami, kt\u00f3re musz\u0105 by\u0107 Hub-n-Spoke. Z drugiej strony, DMVPN\/PfR maj\u0105 pewne funkcjonalno\u015bci, kt\u00f3re na razie nie s\u0105 dost\u0119pne w ramach SD-WAN (mowa o per-application BFD).<\/li>\n W ramach technologii control-plane r\u00f3\u017cni\u0105 si\u0119 one zasadniczo. Bior\u0105c pod uwag\u0119 scentralizowane przetwarzanie protoko\u0142\u00f3w sygnalizacyjnych, SD-WAN pozwala w szczeg\u00f3lno\u015bci znacznie zaw\u0119zi\u0107 domeny awarii i 'rozwi\u0105za\u0107' proces przesy\u0142ania ruchu u\u017cytkownik\u00f3w od interakcji sygnalizacyjnej - czasowa niedost\u0119pno\u015b\u0107 kontroler\u00f3w nie wp\u0142ywa na mo\u017cliwo\u015b\u0107 przesy\u0142ania ruchu u\u017cytkownika. Z drugiej strony, czasowa niedost\u0119pno\u015b\u0107 kt\u00f3regokolwiek z oddzia\u0142\u00f3w (w tym centralnego) nie wp\u0142ywa na mo\u017cliwo\u015b\u0107 interakcji pozosta\u0142ych oddzia\u0142\u00f3w z sob\u0105 nawzajem i z kontrolerami.<\/li>\n Architektura formu\u0142owania i stosowania polityk zarz\u0105dzania ruchem w przypadku SD-WAN r\u00f3wnie\u017c przewy\u017csza t\u0119 w DMVPN\/PfR - znacznie lepiej zrealizowano geo-redundancj\u0119, brak jest powi\u0105zania z Hubem, wi\u0119cej mo\u017cliwo\u015bci drobnego dostosowywania polityk, lista realizowanych scenariuszy zarz\u0105dzania ruchem jest r\u00f3wnie\u017c znacznie wi\u0119ksza.<\/li>\n Proces orkiestracji rozwi\u0105zania tak\u017ce znacznie si\u0119 r\u00f3\u017cni. DMVPN zak\u0142ada obecno\u015b\u0107 z g\u00f3ry znanych parametr\u00f3w, kt\u00f3re musz\u0105 by\u0107 w jaki\u015b spos\u00f3b odzwierciedlone w konfiguracji, co nieco ogranicza elastyczno\u015b\u0107 rozwi\u0105zania i mo\u017cliwo\u015b\u0107 dynamicznych zmian. Z drugiej strony, SD-WAN opiera si\u0119 na paradygmacie, \u017ce w momencie pocz\u0105tkowego po\u0142\u0105czenia router 'nie wie nic' o swoich kontrolerach, ale wie 'od kogo mo\u017cna zapyta\u0107' - to wystarczy nie tylko do automatycznego nawi\u0105zania po\u0142\u0105czenia z kontrolerami, ale tak\u017ce do automatycznego tworzenia w pe\u0142ni po\u0142\u0105czonej topologii data-plane, kt\u00f3r\u0105 nast\u0119pnie mo\u017cna elastycznie dostosowa\u0107\/zmieni\u0107 przy u\u017cyciu polityk.<\/li>\n W zakresie centralnego zarz\u0105dzania, automatyzacji i monitorowania SD-WAN niespodziewanie przewy\u017csza mo\u017cliwo\u015bci DMVPN\/PfR, kt\u00f3re sta\u0142y si\u0119 wynikiem rozwoju klasycznych technologii i w wi\u0119kszym stopniu polegaj\u0105 na interfejsie wiersza polece\u0144 CLI oraz stosowaniu system\u00f3w NMS opartych na szablonach. <\/li>\n W SD-WAN w por\u00f3wnaniu do DMVPN wymagania dotycz\u0105ce bezpiecze\u0144stwa osi\u0105gn\u0119\u0142y nowy poziom. G\u0142\u00f3wne zasady to zaufanie zerowe, skalowalno\u015b\u0107 i uwierzytelnianie dwusk\u0142adnikowe.<\/li>\n<\/ul>\n\nZ tych prostych wniosk\u00f3w mo\u017ce powsta\u0107 mylne wra\u017cenie, \u017ce tworzenie sieci na bazie DMVPN\/PfR straci\u0142o dzisiaj na znaczeniu. Oczywi\u015bcie nie do ko\u0144ca jest to prawda. Na przyk\u0142ad w przypadkach, gdy w sieci u\u017cywane jest wiele przestarza\u0142ych urz\u0105dze\u0144 i nie ma mo\u017cliwo\u015bci ich wymiany, DMVPN mo\u017ce umo\u017cliwi\u0107 po\u0142\u0105czenie 'starych' i 'nowych' urz\u0105dze\u0144 w jedn\u0105 geo-rozproszon\u0105 sie\u0107 z wieloma opisanymi wy\u017cej korzy\u015bciami.<\/p>\n
Z drugiej strony nale\u017cy pami\u0119ta\u0107, \u017ce wszystkie aktualne korporacyjne routery Cisco oparte na IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) dzisiaj wspieraj\u0105 ka\u017cdy tryb pracy \u2013 zar\u00f3wno klasyczn\u0105 routingu, jak i DMVPN oraz SD-WAN \u2013 wyb\u00f3r zale\u017cy od bie\u017c\u0105cych potrzeb oraz zrozumienia, \u017ce w ka\u017cdej chwili na tym samym sprz\u0119cie mo\u017cna zacz\u0105\u0107 przechodzi\u0107 w kierunku bardziej zaawansowanej technologii.<\/b>habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0421 \u0430\u0432\u0433\u0443\u0441\u0442\u0430 2017 \u0433\u043e\u0434\u0430, \u043a\u043e\u0433\u0434\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044f Cisco \u043f\u0440\u0438\u043e\u0431\u0440\u0435\u043b\u0430 \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u044e Viptela, \u043e\u0441\u043d\u043e\u0432\u043d\u043e\u0439 \u043f\u0440\u0435\u0434\u043b\u0430\u0433\u0430\u0435\u043c\u043e\u0439 \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u0435\u0439 \u043e\u0440\u0433\u0430\u043d\u0438\u0437\u0430\u0446\u0438\u0438 \u0440\u0430\u0441\u043f\u0440\u0435\u0434\u0435\u043b\u0435\u043d\u043d\u044b\u0445 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u044b\u0445 \u0441\u0435\u0442\u0435\u0439 \u0441\u0442\u0430\u043b\u0430 Cisco SD-WAN. \u0417\u0430 \u043f\u0440\u043e\u0448\u0435\u0434\u0448\u0438\u0435 3 \u0433\u043e\u0434\u0430 SD-WAN \u0442\u0435\u0445\u043d\u043e\u043b\u043e\u0433\u0438\u044f \u043f\u0440\u043e\u0448\u043b\u0430 \u043c\u043d\u043e\u0436\u0435\u0441\u0442\u0432\u043e \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u0439, \u043a\u0430\u043a \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e, \u0442\u0430\u043a \u0438 \u043a\u043e\u043b\u0438\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e\u0433\u043e \u0445\u0430\u0440\u0430\u043a\u0442\u0435\u0440\u0430. \u0422\u0430\u043a \u0437\u043d\u0430\u0447\u0438\u0442\u0435\u043b\u044c\u043d\u043e \u0440\u0430\u0441\u0448\u0438\u0440\u0438\u043b\u0438\u0441\u044c \u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e\u0441\u0442\u0438 \u0438 \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u043f\u043e\u0434\u0434\u0435\u0440\u0436\u043a\u0430 \u043d\u0430 \u043a\u043b\u0430\u0441\u0441\u0438\u0447\u0435\u0441\u043a\u0438\u0445 \u043c\u0430\u0440\u0448\u0440\u0443\u0442\u0438\u0437\u0430\u0442\u043e\u0440\u0430\u0445 \u0441\u0435\u0440\u0438\u0439 Cisco ISR 1000, ISR 4000, ASR 1000 \u0438 […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":91349,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-91348","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t