Ĉu Cisco SD-WAN fortranĉos la branĉon, sur kiu sidas DMVPN?

Ekde aŭgusto 2017, kiam Cisco akiris Viptela, la ĉefa teknologio ofertita por organizado de distribuitaj entreprenaj retoj fariĝis Cisco SD-WAN. Dum la pasintaj 3 jaroj, SD-WAN-teknologio travivis multajn ŝanĝojn, kaj kvalitajn kaj kvantajn. Tiel, la funkcieco signife vastiĝis kaj subteno aperis sur klasikaj enkursigiloj de la serio Cisco ISR 1000, ISR 4000, ASR 1000 kaj Virtuala CSR 1000v. Samtempe, multaj klientoj kaj partneroj de Cisco daŭre scivolas: kiuj estas la diferencoj inter Cisco SD-WAN kaj jam konataj aliroj bazitaj sur teknologioj kiel ekzemple Cisco DMVPN и Cisco Performance Routing kaj kiom gravaj estas ĉi tiuj diferencoj?

Ĉi tie ni devas tuj fari rezervon, ke antaŭ la apero de SD-WAN en la biletujo de Cisco, DMVPN kune kun PfR formis ŝlosilan parton en la arkitekturo. Cisco IWAN (Inteligenta WAN), kiu en victurno estis la antaŭulo de plentaŭga SD-WAN-teknologio. Malgraŭ la ĝenerala simileco de kaj la taskoj solvitaj kaj la metodoj por solvi ilin, IWAN neniam ricevis la nivelon de aŭtomatigo, fleksebleco kaj skalebleco necesa por SD-WAN, kaj kun la tempo, la evoluo de IWAN signife malpliiĝis. Samtempe, la teknologioj, kiuj konsistigas IWAN, ne foriris, kaj multaj klientoj daŭre uzas ilin sukcese, inkluzive de modernaj ekipaĵoj. Kiel rezulto, interesa situacio aperis - la sama Cisco-ekipaĵo permesas elekti la plej taŭgan WAN-teknologion (klasika, DMVPN+PfR aŭ SD-WAN) konforme al la postuloj kaj atendoj de klientoj.

La artikolo ne intencas detale analizi ĉiujn funkciojn de Cisco SD-WAN kaj DMVPN-teknologioj (kun aŭ sen Performance Routing) - estas grandega kvanto da disponeblaj dokumentoj kaj materialoj por tio. La ĉefa tasko estas provi taksi la ŝlosilajn diferencojn inter ĉi tiuj teknologioj. Sed antaŭ ol diskuti ĉi tiujn diferencojn, ni mallonge rememoru la teknologiojn mem.

Kio estas Cisco DMVPN kaj kial ĝi bezonas?

Cisco DMVPN solvas la problemon de dinamika (= skalebla) konekto de fora branĉa reto al la reto de la centra oficejo de entrepreno kiam oni uzas arbitrajn specojn de komunikaj kanaloj, inkluzive de Interreto (= kun ĉifrado de la komunika kanalo). Teknike, ĉi tio realiĝas kreante virtualigitan superkovritan reton de L3 VPN-klaso en punkto-al-multpunkta reĝimo kun logika topologio de la "Stelo" tipo (Hub-n-Spoke). Por atingi tion, DMVPN uzas kombinaĵon de la sekvaj teknologioj:

• IP-vojigo
• Plurpunktaj GRE-tuneloj (mGRE)
• Protokolo pri Sekva Salteto Rezolucio (NHRP)
• IPSec Crypto-profiloj

Kiuj estas la ĉefaj avantaĝoj de Cisco DMVPN kompare kun klasika vojigo per MPLS VPN-kanaloj?

• Por krei interbranĉan reton, eblas uzi iujn ajn komunikajn kanalojn - ĉio, kio povas disponigi IP-konektecon inter branĉoj, taŭgas, dum la trafiko estos ĉifrita (kie necese) kaj ekvilibra (kie eble)
• Автоматически формируется полно связная топология между филиалами. При этом между центральным и удаленным филиалами – статические туннели, а между удаленными филиалами – динамические туннели по требованию (при наличии трафика)
• La enkursigiloj de la centra kaj fora branĉo havas la saman agordon ĝis la IP-adresoj de la interfacoj. Uzante mGRE, ne necesas individue agordi dekojn, centojn aŭ eĉ milojn da tuneloj. Kiel rezulto, deca skaleblo kun la ĝusta dezajno.

Kio estas Cisco Performance Routing kaj kial ĝi bezonas?

Kiam vi uzas DMVPN en interbranĉa reto, unu ekstreme grava demando restas nesolvita - kiel dinamike taksi la staton de ĉiu el la DMVPN-tuneloj por plenumado de la postuloj de trafiko kritika por nia organizo kaj, denove, surbaze de tia takso, dinamike fari ĉu decido pri revojigo? Fakte, DMVPN en ĉi tiu parto malmulte diferencas de klasika vojigo - la plej bona farebla estas agordi QoS-mekanismojn, kiuj permesos al vi prioritati trafikon en la elira direkto, sed neniel kapablas konsideri la staton de. la tutan vojon iam aŭ alian.

Kaj kion fari se la kanalo degradas parte kaj ne tute - kiel detekti kaj taksi ĉi tion? DMVPN mem ne povas fari tion. Konsiderante, ke la kanaloj ligantaj branĉojn povas trairi tute malsamajn telekomunikajn telefonistojn, uzante tute malsamajn teknologiojn, ĉi tiu tasko fariĝas ege ne-triviala. Kaj ĉi tie estas kie Cisco Performance Routing-teknologio venas al la savo, kiu tiam jam trapasis plurajn stadiojn de evoluo.

La tasko de Cisco Performance Routing (ĉi-poste PfR) konsistas en mezuri la staton de vojoj (tuneloj) de trafiko surbaze de ŝlosilaj metrikoj gravaj por retaj aplikoj - latenteco, latencia variado (jitter) kaj paka perdo (procento). Дополнительно может измеряться используемая полоса пропускания. Эти измерения происходят максимально близко к реальному времени (насколько это возможно и оправданно) и результат этих измерений позволяет маршрутизатору, изпользующему PfR, динамически принимать решения о необходимости изменения маршрутизации того или иного вида трафика.

Tiel, la tasko de la kombinaĵo DMVPN/PfR povas esti mallonge priskribita jene:

• Permesu al la kliento uzi iujn ajn komunikajn kanalojn sur la WAN-reto
• Обеспечить максимально возможное качество важных приложений на этих каналах

Что такое Cisco SD-WAN?

Cisco SD-WAN estas teknologio kiu uzas la SDN-aliron por krei kaj funkciigi la WAN-reton de organizo. Ĉi tio precipe signifas la uzon de tielnomitaj regiloj (programaraj elementoj), kiuj disponigas centralizitan instrumentadon kaj aŭtomatigitan agordon de ĉiuj solvkomponentoj. Male al la kanona SDN (Clean Slate-stilo), Cisco SD-WAN uzas plurajn specojn de regiloj, ĉiu el kiuj plenumas sian propran rolon - tio estis farita intence por disponigi pli bonan skaleblon kaj geo-redundon.

En la kazo de SD-WAN, la tasko uzi ajnajn specojn de kanaloj kaj certigi la funkciadon de komercaj aplikoj restas la sama, sed samtempe la postuloj por aŭtomatigo, skaleblo, sekureco kaj fleksebleco de tia reto vastiĝas.

Diskuto pri diferencoj

Se ni nun komencas analizi la diferencojn inter ĉi tiuj teknologioj, ili falos en unu el la sekvaj kategorioj:

• Arkitekturaj diferencoj - kiel estas funkcioj distribuitaj tra diversaj komponentoj de la solvo, kiel estas la interagado de tiaj komponentoj organizita, kaj kiel tio influas la kapablojn kaj flekseblecon de la teknologio?
• Funkcieco - kion unu teknologio povas fari ke alia ne povas? Kaj ĉu vere tio gravas?

В чем заключены архитектурные различия и так ли они важны?

В каждой из обозначенных технологий имеется множество «движущихся частей», у которых отличается не только роль, но и принципы взаимодействия друг с другом. От того, насколько продуманы эти принципы, и общая механика решения напрямую зависит его масштабируемость, отказоустойчивость и общая эффективность.

Ni rigardu la diversajn aspektojn de la arkitekturo pli detale:

Datumo-aviadilo – parto de la solvo respondeca por transdoni uzanttrafikon inter la fonto kaj la ricevanto. DMVPN kaj SD-WAN estas efektivigitaj ĝenerale idente sur la enkursigiloj mem bazitaj sur Multipoint GRE-tuneloj. La diferenco estas kiel la necesa aro de parametroj por ĉi tiuj tuneloj estas formita:

• в DMVPN/PfR estas ekskluzive dunivela hierarkio de nodoj kun Stela aŭ Hub-n-Spoke-topologio. Senmova agordo de la Nabo kaj senmova ligado de Spoke al la Nabo estas postulataj, same kiel interagado per la NHRP-protokolo por formi datum-ebenan konekteblecon. Sekve, farante ŝanĝojn al la Nabo signife pli malfacilarilata, ekzemple, al ŝanĝi/konekti novajn WAN-kanalojn aŭ ŝanĝi la parametrojn de ekzistantaj.
• в SD WAN estas plene dinamika modelo por detektado de parametroj de instalitaj tuneloj bazitaj sur kontrol-aviadilo (OMP-protokolo) kaj instrumentad-aviadilo (interagado kun la vBond-regilo por regilo-detekto kaj NAT-traversaj taskoj). En ĉi tiu kazo, ĉiuj supermetitaj topologioj povas esti uzataj, inkluzive de hierarkiaj. Ene de la establita superkovra tuneltopologio, fleksebla agordo de la logika topologio en ĉiu individua VPN (VRF) estas ebla.

Kontrol-aviadilo – функции обмена, фильтрации и модификации маршрутной и другой информации между компонентами решения.

• в DMVPN/PfR – осуществляется только между маршрутизаторами Hub и Spoke. Прямой обмен маршрутной информацией между Spoke невозможен. Как следствие, Sen funkcianta Nabo, la kontrolaviadilo kaj datumaviadilo ne povas funkcii, kiu trudas aldonajn altajn haveblecpostulojn al la Nabo, kiuj ne ĉiam povas esti plenumitaj.
• в SD WAN - kontrolaviadilo neniam estas efektivigita rekte inter enkursigiloj - interago okazas surbaze de la OMP-protokolo kaj estas nepre efektivigita per aparta speciala tipo de vSmart-regilo, kiu disponigas la eblecon de ekvilibro, georezervado kaj centralizita kontrolo de la signalŝarĝo. Alia trajto de la OMP-protokolo estas ĝia grava rezisto al perdoj kaj sendependeco de la rapideco de la komunika kanalo kun regiloj (en akcepteblaj limoj, kompreneble). Kiu same sukcese permesas vin meti SD-WAN-regilojn en publikajn aŭ privatajn nubojn kun aliro per Interreto.

Politika-ebeno – parto de la solvo respondeca por difinado, distribuado kaj aplikado de trafikaj administradpolitikoj en distribuita reto.

• DMVPN - estas efike limigita de politikoj pri kvalito de servo (QoS) agorditaj individue sur ĉiu enkursigilo per la ŝablonoj CLI aŭ Prime Infrastructure.
• DMVPN/PfR - PfR-politikoj estas formitaj sur la alcentrigita Master Controller (MC) enkursigilo per la CLI kaj tiam aŭtomate distribuitaj al branĉo MCoj. En ĉi tiu kazo, la samaj politikaj transigaj vojoj estas uzataj kiel por la datenaviadilo. Ne estas ebleco apartigi la interŝanĝon de politikoj, vojinformoj kaj uzantdatenoj. Politika disvastigo postulas la ĉeeston de IP-konektebleco inter la Nabo kaj Spoke. En ĉi tiu kazo, la funkcio MC povas, se necese, esti kombinita kun DMVPN-enkursigilo. Eblas (sed ne devige) uzi ŝablonojn de Prime Infrastructure por centralizita politika generacio. Grava trajto estas, ke la politiko estas formita tutmonde tra la reto sammaniere - индивидуальные политики для отдельных сегментов не поддерживаются.
• SD WAN – Trafikadministrado kaj kvalito de servo politikoj estas determinitaj centre tra la Cisco vManage grafika interfaco, alirebla ankaŭ per la Interreto (se necese). Ili estas distribuitaj per signalaj kanaloj rekte aŭ nerekte per vSmart-regiloj (depende de la speco de politiko). Ili ne dependas de datum-ebena konektebleco inter enkursigiloj, ĉar uzu ĉiujn disponeblajn trafikvojojn inter la regilo kaj la enkursigilo.

  Por malsamaj retsegmentoj, eblas flekseble formuli malsamajn politikojn - la amplekso de la politiko estas determinita de multaj unikaj identigiloj provizitaj en la solvo - branĉo numero, aplika tipo, trafikdirekto ktp.

Orkestra-aviadilo - mekanismoj kiuj permesas al komponantoj dinamike detekti unu la alian, agordi kaj kunordigi postajn interagojn.

• в DMVPN/PfR Reciproka malkovro inter enkursigiloj baziĝas sur la senmova agordo de Hub-aparatoj kaj la responda agordo de Spoke-aparatoj. Dinamika malkovro okazas nur por Spoke, kiu raportas siajn Hub-konektoparametrojn al la aparato, kiu siavice estas antaŭ-agordita kun Spoke. Sen IP-konekto inter Spoke kaj almenaŭ unu Nabo, estas neeble formi aŭ datum-aviadilon aŭ kontrol-aviadilon.
• в SD WAN instrumentado de solvkomponentoj okazas uzante la vBond-regilon, kun kiu ĉiu komponento (enkursigiloj kaj vManage/vSmart-regiloj) unue devas establi IP-konektecon.

  Komence, la komponantoj ne scias pri la konektoparametroj de unu la alia - por tio ili bezonas la interan orkestranton de vBond. La ĝenerala principo estas jena - ĉiu komponanto en la komenca fazo lernas (aŭtomate aŭ statike) nur pri la konektoparametroj al vBond, tiam vBond informas la enkursigilon pri la regiloj vManage kaj vSmart (malkovritaj pli frue), kio ebligas aŭtomate establi ĉiuj necesaj signalaj konektoj.

  La sekva paŝo estas, ke la nova enkursigilo lernu pri la aliaj enkursigiloj en la reto per OMP-komunikado kun la regilo vSmart. Tiel, la enkursigilo, sen komence scii ion ajn pri la retaj parametroj, kapablas plene aŭtomate detekti kaj konektiĝi al regiloj kaj poste ankaŭ aŭtomate detekti kaj formi konekteblecon kun aliaj enkursigiloj. En ĉi tiu kazo, la konekto-parametroj de ĉiuj komponantoj estas komence nekonataj kaj povas ŝanĝiĝi dum operacio.

Administra-aviadilo - parto de la solvo kiu provizas centralizita administrado kaj monitorado.

• DMVPN/PfR – специализированного management-plane решения не предусмотрено. Для базовой автоматизации и мониторинга возможно использование таких продуктов, как Cisco Prime Infrastructure. Каждый маршрутизатор имеет возможность управления через командную строку CLI. Integriĝo kun eksteraj sistemoj per API ne estas provizita.
• SD WAN – все штатное взаимодействие и мониторинг осуществляется централизовано через графический интерфейс контроллера vManage. Все возможности решения без исключения доступны к настройке через vManage, а также через полностью документированную библиотеку программного интерфейса REST API.

  Ĉiuj SD-WAN-retaj agordoj en vManage estas du ĉefaj konstruoj - la formado de aparato-ŝablonoj (Aparato-Ŝablono) kaj la formado de politiko, kiu determinas la logikon de retfunkciado kaj trafika prilaborado. Samtempe, vManage, elsendante la politikon generitan de la administranto, aŭtomate elektas kiuj ŝanĝoj kaj sur kiuj individuaj aparatoj/regiloj devas esti faritaj, kio signife pliigas la efikecon kaj skaleblon de la solvo.

  Per la interfaco vManage, disponeblas ne nur agordo de la solvo Cisco SD-WAN, sed ankaŭ plena monitorado de la stato de ĉiuj komponantoj de la solvo, ĝis la nuna stato de metrikoj por individuaj tuneloj kaj statistikoj pri la uzo de diversaj aplikoj. surbaze de DPI-analizo.

  Malgraŭ la centralizo de interago, ĉiuj komponantoj (regiloj kaj enkursigiloj) ankaŭ havas plene funkcian CLI-komandlinion, kiu estas necesa en la efektiviga stadio aŭ en kazo de krizo por lokaj diagnozoj. En normala reĝimo (se ekzistas signala kanalo inter komponantoj) ĉe enkursigiloj, la komandlinio disponeblas nur por diagnozo kaj ne disponeblas por fari lokajn ŝanĝojn, kio garantias lokan sekurecon kaj la sola fonto de ŝanĝoj en tia reto estas vManage.

Integrita Sekureco – ĉi tie ni devus paroli ne nur pri la protekto de uzantdatenoj kiam transdonitaj tra malfermaj kanaloj, sed ankaŭ pri la ĝenerala sekureco de la WAN-reto bazita sur la elektita teknologio.

• в DMVPN/PfR Eblas ĉifri uzantajn datumojn kaj signalajn protokolojn. Kiam oni uzas iujn enkursigilojn, fajroŝirmilo funkcias kun trafika inspektado, IPS/IDS estas aldone haveblaj. Estas eble segmenti branĉretojn uzante VRF. Eblas aŭtentikigi (unu-faktorajn) kontrolprotokolojn.

  При этом удаленный маршрутизатор по-умолчанию считается доверенным элементом сети – т.е. не предполагаются и не учитываются случаи физической компрометации отдельных устройств и возможность несанкционированного к ним доступа, нет двухфакторной аутентификации компонентов решения, что в случае географически распределенной сети povas porti gravajn pliajn riskojn.

• в SD WAN analoge kun DMVPN, la kapablo ĉifri uzantdatenojn estas disponigita, sed kun signife vastigita retsekureco kaj L3/VRF-segmentaj funkcioj (fajroŝirmilo, IPS/IDS, URL-filtrado, DNS-filtrado, AMP/TG, SASE, TLS/SSL-prokurilo, ktp.) d.). Samtempe, la interŝanĝo de ĉifradaj ŝlosiloj estas farita pli efike per vSmart-regiloj (prefere ol rekte), per antaŭestablitaj signalaj kanaloj protektitaj per DTLS/TLS-ĉifrado bazita sur sekurecaj atestiloj. Kiu siavice garantias la sekurecon de tiaj interŝanĝoj kaj certigas pli bonan skaleblon de la solvo ĝis dekoj da miloj da aparatoj en la sama reto.

  Ĉiuj signalaj ligoj (regilo-al-regilo, regilo-enkursigilo) ankaŭ estas protektitaj surbaze de DTLS/TLS. Enkursigiloj estas ekipitaj per sekurecaj atestiloj dum produktado kun la ebleco de anstataŭigo/etendo. Dufaktora aŭtentikigo estas atingita per la deviga kaj samtempa plenumo de du kondiĉoj por la enkursigilo/regilo por funkcii en SD-WAN-reto:

  • Действующий сертификат безопасности
  • Eksplicita kaj konscia inkludo de la administranto de ĉiu komponanto en la "blanka" listo de permesitaj aparatoj.

Funkciaj diferencoj inter SD-WAN kaj DMVPN/PfR

Pluirante por diskuti funkciajn diferencojn, oni devas rimarki, ke multaj el ili estas daŭrigo de arkitekturaj - ne estas sekreto, ke kiam ili formas la arkitekturon de solvo, programistoj komencas de la kapabloj, kiujn ili volas akiri finfine. Ni rigardu la plej signifajn diferencojn inter la du teknologioj.

AppQ (Aplika Kvalito) - funkcioj por certigi la kvaliton de dissendo de komerca aplika trafiko

La ŝlosilaj funkcioj de la konsiderataj teknologioj celas plibonigi la uzantsperton kiel eble plej multe dum uzado de komercaj kritikaj aplikoj en distribuita reto. Ĉi tio estas precipe grava en kondiĉoj, kie parto de la infrastrukturo ne estas kontrolita de IT aŭ eĉ ne garantias sukcesan transdonon de datumoj.

DMVPN ne mem provizas tiajn mekanismojn. La plej bona kiu povas esti farita en klasika DMVPN-reto estas klasifiki elirantan trafikon per aplikaĵo kaj prioritati ĝin kiam transdonite al la WAN-kanalo. La elekto de DMVPN-tunelo estas determinita en ĉi tiu kazo nur de ĝia havebleco kaj la rezulto de la funkciado de enrutaj protokoloj. En la sama tempo, la fin-al-fina stato de la pado/tunelo kaj ĝia ebla parta degenero ne estas enkalkulitaj laŭ esencaj metrikoj kiuj estas signifaj por retaj aplikoj - prokrasto, prokrasta vario (jitter) kaj perdoj (% ). Ĉi-rilate, rekte kompari klasikan DMVPN kun SD-WAN rilate al solvi AppQ-problemojn perdas ĉian signifon - DMVPN ne povas solvi ĉi tiun problemon. Kiam vi aldonas Cisco Performance Routing (PfR) teknologion en ĉi tiun kuntekston, la situacio ŝanĝiĝas kaj la komparo kun Cisco SD-WAN fariĝas pli signifa.

Antaŭ ol ni diskutas la diferencojn, jen rapida rigardo kiel la teknologioj similas. Do ambaŭ teknologioj:

• havas mekanismon, kiu ebligas al vi dinamike taksi la staton de ĉiu establita tunelo laŭ certaj metrikoj - minimume, prokrasto, prokrasto variado kaj paka perdo (%)
• uzu specifan aron de iloj por formi, distribui kaj apliki regulojn (politikoj) pri trafiko-administrado, konsiderante la rezultojn de mezurado de la stato de ŝlosilaj tunelaj metrikoj.
• классифицируют трафик приложений на уровнях L3-L4 (DSCP) модели OSI или по L7 сигнатурам приложений на основе встроенных в маршрутизатор DPI механизмов
• Por signifaj aplikoj, ili permesas vin determini akcepteblajn sojlovalorojn de metrikoj, regulojn por transsendi trafikon defaŭlte kaj regulojn por redirekti trafikon kiam sojlaj valoroj estas superitaj.
• Kiam ili enkapsuligas trafikon en GRE/IPSec, ili uzas la jam establitan industrian mekanismon por transdoni internajn DSCP-markadojn al la ekstera GRE/IPSEC-paka titolo, kiu permesas sinkronigi la QoS-politikojn de la organizo kaj la teleentreprenisto (se ekzistas konvena SLA) .

Kiel SD-WAN kaj DMVPN/PfR-fin-al-finaj metrikoj diferencas?

DMVPN/PfR

• Kaj aktivaj kaj pasivaj softvarsensiloj (Enketoj) estas uzataj por taksi normajn tunelajn sanmetrikojn. Aktivaj baziĝas sur uzanttrafiko, pasivaj imitas tian trafikon (en ĝia foresto).
• Ne estas fajnagordado de temporiziloj kaj detektaj kondiĉoj - la algoritmo estas fiksita.
• Aldone, mezurado de uzata bendolarĝo en la elira direkto estas disponebla. Kiu aldonas plian trafikadministran flekseblecon al DMVPN/PfR.
• Samtempe, kelkaj PfR-mekanismoj, kiam metrikoj estas superitaj, dependas de sugesta signalado en la formo de specialaj TCA (Threshold Crossing Alert) mesaĝoj kiuj devas veni de la trafikricevanto al la fonto, kiu siavice supozas ke la stato de la mezuritaj kanaloj devus esti almenaŭ sufiĉaj por dissendo de tiaj TCA-mesaĝoj. Kio plejofte ne estas problemo, sed evidente ne estas garantiebla.

SD WAN

• Por fin-al-fina taksado de norma tunela ŝtatmetriko, la BFD-protokolo estas utiligita en eĥreĝimo. En ĉi tiu kazo, specialaj sugestoj en la formo de TCA aŭ similaj mesaĝoj ne estas postulataj - izolado de malsukcesaj domajnoj estas konservita. Ĝi ankaŭ ne postulas la ĉeeston de uzanttrafiko por taksi la tunelŝtaton.
• Есть возможность тонкой настройки таймеров BFD для регулирования скорости срабатывания и чувствительности алгоритма к деградациям канала связи от нескольких секунд до минут.

  

• En la momento de skribado, ekzistas nur unu BFD-sesio en ĉiu tunelo. Tio eble kreas malpli granularecon en tunela ŝtatanalizo. Fakte, ĉi tio nur povas fariĝi limigo se vi uzas WAN-konekton bazitan sur MPLS L2/L3 VPN kun interkonsentita QoS SLA - se la DSCP-markado de BFD-trafiko (post enkapsuliĝo en IPSec/GRE) kongruas kun la altprioritata atendovico en la reto de la teleentreprenisto, tiam ĉi tio povas influi la precizecon kaj rapidecon de degenero-detekto por malalt-prioritata trafiko. Samtempe, eblas ŝanĝi la defaŭltan BFD-etikedadon por redukti la riskon de tiaj situacioj. En estontaj versioj de Cisco SD-WAN-programaro, oni atendas pli bone agorditajn BFD-agordojn, kaj ankaŭ la eblon lanĉi plurajn BFD-sesiojn ene de la sama tunelo kun individuaj DSCP-valoroj (por malsamaj aplikoj).
• BFD krome permesas al vi taksi la maksimuman pakaĵgrandecon, kiu povas esti elsendita tra aparta tunelo sen fragmentiĝo. Ĉi tio permesas al SD-WAN dinamike ĝustigi parametrojn kiel MTU kaj TCP MSS Adjust por utiligi la disponeblan bendolarĝon sur ĉiu ligo.
• En SD-WAN, la opcio de QoS-sinkronigo de telekomunikaj telefonistoj ankaŭ estas disponebla, ne nur surbaze de L3 DSCP-kampoj, sed ankaŭ surbaze de L2 CoS-valoroj, kiuj povas esti aŭtomate generitaj en la branĉa reto per specialigitaj aparatoj - ekzemple, IP. telefonoj

Kiel diferencas la kapabloj, metodoj por difini kaj apliki AppQ-politikojn?

DMVPN/PfR Politikoj:

• Difinite sur la centra branĉa enkursigilo(j) per la CLI komandlinio aŭ CLI-agordaj ŝablonoj. Generado de CLI-ŝablonoj postulas preparon kaj scion pri politika sintakso.

  

• Difinita tutmonde sen la ebleco de individua agordo/ŝanĝo al la postuloj de individuaj retsegmentoj.
• Interaga politika generacio ne estas provizita en la grafika interfaco.
• Отслеживание изменений, наследование, создание нескольких версий политик для быстрого переключения не предусмотрено.
• Distribuita aŭtomate al enkursigiloj de foraj branĉoj. En ĉi tiu kazo, la samaj komunikadkanaloj estas uzataj kiel por transdoni uzantdatenojn. Se ne ekzistas komunika kanalo inter la centra kaj malproksima branĉo, distribuo/ŝanĝo de politikoj estas neebla.
• Применяются на каждом маршрутизаторе и при необходимости модифицируют результат стандартных протоколов маршрутизации, имея более высокий приоритет.
• Por kazoj kie ĉiuj branĉoj WAN-ligoj spertas gravan trafikperdon, neniuj kompensmekanismoj disponigitaj.

SD-WAN-politikoj:

• Определяются в графическом интерфейсе vManage через интерактивный мастер шаблонов.
• Subtenas krei plurajn politikojn, kopii, heredi, ŝanĝi inter politikoj en reala tempo.
• Subtenas individuajn politikajn agordojn por malsamaj retsegmentoj (branĉoj)
• Распространяются, используя любой доступный сигнальный канал между контроллером и маршрутизатором и/или vSmart – не зависят напрямую от data-plane связности между маршрутизаторами. При этом конечно требуется IP-связность между самим маршрутизатором и контроллерами.

  

• Por kazoj kiam ĉiuj disponeblaj branĉoj de branĉo spertas signifajn datenperdojn superantajn akcepteblajn sojlojn por kritikaj aplikoj, estas eble uzi kromajn mekanismojn kiuj pliigas dissendfidindecon:
  • FEC (Antaŭen-Era Korekto) – uzas specialan redundan kodan algoritmon. Dum transdonado de kritika trafiko super kanaloj kun grava procento de perdoj, FEC povas esti aŭtomate aktivigita kaj permesas, se necese, restarigi la perditan parton de la datumoj. Ĉi tio iomete pliigas la uzatan dissendlarĝon, sed signife plibonigas fidindecon.

    

  • Duobligo de datumfluoj – Krom FEC, la politiko povas provizi aŭtomatan duobligon de trafiko de elektitaj aplikoj en la okazo de eĉ pli grava nivelo de perdoj, kiuj ne povas esti kompensitaj de FEC. En ĉi tiu kazo, la elektitaj datenoj estos elsenditaj tra ĉiuj tuneloj direkte al la ricevanta branĉo kun posta deduplikado (forlasante ekstrajn kopiojn de pakaĵetoj). La mekanismo signife pliigas kanalan utiligon, sed ankaŭ signife pliigas dissendfidindecon.

Cisco SD-WAN-kapabloj, sen rektaj analogoj en DMVPN/PfR

La arkitekturo de la Cisco SD-WAN-solvo en iuj kazoj permesas vin akiri kapablojn, kiuj estas aŭ ekstreme malfacile efektivigeblaj ene de DMVPN/PfR, aŭ estas nepraktikaj pro la postulataj laborkostoj, aŭ estas tute neeblaj. Ni rigardu la plej interesajn el ili:

Trafika-Inĝenierado (TE)

TE inkludas mekanismojn kiuj permesas al trafiko disbranĉiĝi de la norma pado formita per vojprotokoloj. TE ofte kutimas certigi altan haveblecon de retservoj, tra la kapablo rapide kaj/aŭ iniciateme translokigi kritikan trafikon al alternativa (diskosta) dissendvojo, por certigi pli bonan kvaliton de servo aŭ rapidecon de reakiro en la okazaĵo de fiasko. sur la ĉefa vojo.

Сложность реализации TE заключается в необходимости заранее вычислить и зарезервировать (проверить) альтернативный путь. В MPLS сетях операторов связи эту задачу решают, используя такие технологии, как MPLS Traffic-Engineering с расширениями IGP протоколов и RSVP протокола. Также в последнее время все большую популярность набирает технология Segment Routing, которая более оптимизирована для централизованной настройки и оркестрации. В классических WAN сетях эти технологии, как правило, не представлены или сведены до использования hop-by-hop механизмов вроде Policy-Based Routing (PBR), которые способны ответвить трафик, но реализуют это на каждом маршрутизаторе отдельно – без учета общего состояния сети или результата PBR на предыдущем или последующих шагах. Итог применения этих вариантов TE неутешительный – MPLS TE ввиду сложности настройки и эксплуатации, используют, как правило, только в самой критичной части сети (ядро), а PBR используют на отдельных маршрутизаторах без возможности сформировать некую единую PBR политику на всей сети. Очевидно, это касается и сетей на базе DMVPN.

SD-WAN ĉi-rilate ofertas multe pli elegantan solvon, kiu ne nur estas facile agordebla, sed ankaŭ multe pli bone skalas. Ĉi tio estas rezulto de la arkitekturoj kontrolebenaj kaj politikebenaj uzitaj. Efektivigo de politiko-aviadilo en SD-WAN permesas al vi centre difini TE-politikon - kia trafiko interesas? por kiuj VPN-oj? Tra kiuj nodoj/tuneloj necesas aŭ male estas malpermesite formi alternativan itineron? Siavice, la centralizo de kontrolplana administrado bazita sur vSmart-regiloj ebligas al vi modifi vojajn rezultojn sen recurri al la agordoj de individuaj aparatoj - enkursigiloj jam vidas nur la rezulton de la logiko, kiu estis generita en la vManage-interfaco kaj transdonita por uzo al. vSmart.

Servo-ĉenado

Formi servĉenojn estas eĉ pli labor-intensa tasko en klasika vojigo ol la jam priskribita Trafik-Inĝenieristiko-mekanismo. Efektive, en ĉi tiu kazo, necesas ne nur krei specialan itineron por specifa reto-aplikaĵo, sed ankaŭ certigi la kapablon forigi trafikon de la reto sur iuj (aŭ ĉiuj) nodoj de la reto SD-WAN por prilaborado per speciala aplikaĵo aŭ servo (Fajromuro, Ekvilibro, Kaŝmemoro, Inspekta trafiko, ktp.). Samtempe, necesas povi kontroli la staton de ĉi tiuj eksteraj servoj por malhelpi situaciojn de nigra truado, kaj ankaŭ necesas mekanismoj, kiuj ebligas loki tiajn eksterajn servojn de la sama tipo en malsamaj geolokoj. kun la kapablo de la reto aŭtomate elekti la plej optimuman servan nodon por prilabori la trafikon de aparta branĉo. En la kazo de Cisco SD-WAN, ĉi tio estas sufiĉe facile atingi kreante taŭgan centralizitan politikon, kiu "gluas" ĉiujn aspektojn de la celserva ĉeno en ununuran tuton kaj aŭtomate ŝanĝas la datumplanan kaj kontrolebenan logikon nur kie kaj kiam necese.

La kapablo krei geo-distribuitan traktadon de trafiko de elektitaj specoj de aplikoj en certa sinsekvo sur specialigitaj (sed ne rilataj al la SD-WAN reto mem) ekipaĵo estas eble la plej klara pruvo de la avantaĝoj de Cisco SD-WAN super klasika. teknologioj kaj eĉ iuj alternativaj SD-solvoj -WAN de aliaj fabrikantoj.

Kio en la fino?

Evidente, ambaŭ DMVPN (kun aŭ sen Performance Routing) kaj Cisco SD-WAN finas solvi tre similajn problemojn rilate al la distribuita WAN-reto de la organizo. Samtempe, signifaj arkitekturaj kaj funkciaj diferencoj en Cisco SD-WAN-teknologio kondukas al la procezo de solvado de ĉi tiuj problemoj. al alia kvalita nivelo. Por resumi, ni povas noti la jenajn signifajn diferencojn inter SD-WAN kaj DMVPN/PfR teknologioj:

• DMVPN/PfR ĝenerale uzas temp-testitajn teknologiojn por konstrui superkovrajn VPN-retojn kaj, laŭ datenaviadilo, estas similaj al pli moderna SD-WAN-teknologio, tamen, ekzistas kelkaj limigoj en la formo de deviga senmova agordo. de enkursigiloj kaj la elekto de topologioj estas limigita al Hub-n-Spoke. Aliflanke, DMVPN/PfR havas iujn funkciojn, kiuj ankoraŭ ne disponeblas ene de SD-WAN (ni parolas pri po-aplikaĵo BFD).
• Ene de la kontrolaviadilo, teknologioj diferencas fundamente. Konsiderante la centralizitan prilaboradon de signalaj protokoloj, SD-WAN ebligas, precipe, signife malvastigi malsukcesajn domajnojn kaj "malkunligi" la procezon de transsendo de uzanttrafiko de signala interago - provizora nehavebleco de regiloj ne influas la kapablon transdoni uzanttrafikon. . Samtempe, la provizora nedisponebleco de iu ajn branĉo (inkluzive de la centra) neniel influas la kapablon de aliaj branĉoj interagi unu kun la alia kaj regiloj.
• Архитектура формирования и применения политик управления трафиком в случае SD-WAN также превосходит таковую в DMVPN/PfR – значительно лучше реализовано гео-резервирование, нет привязки к Hub, больше возможностей по тонкой настройки политик, список реализуемых сценариев управления трафиком также значительно больше.
• Процесс оркестрации решения также значительно отличается. DMVPN предполагает наличие заранее известных параметров, которые должны быть каким-то образом отражены в конфигурации, что несколько ограничивает гибкость решения и возможность динамических изменений. В свою очередь SD-WAN исходит из парадигмы, что в начальный момент времени подключения маршрутизатор «не знает ничего» о своих контроллерах, но знает «у кого можно спросить» – этого достаточно не только для автоматического установления связи с контроллерами, но и для автоматического формирования полно связной data-plane топологии, которую затем можно гибко настроить/изменить с помощью политик.
• Koncerne al centralizita administrado, aŭtomatigo kaj monitorado, SD-WAN estas atendita superi la kapablojn de DMVPN/PfR, kiuj evoluis el klasikaj teknologioj kaj dependas pli multe de la CLI-komandlinio kaj la uzo de ŝablono-bazitaj NMS-sistemoj.
• En SD-WAN, kompare kun DMVPN, sekurecpostuloj atingis malsaman kvalitan nivelon. La ĉefaj principoj estas nula fido, skaleblo kaj dufaktora aŭtentigo.

Ĉi tiuj simplaj konkludoj povas doni la malĝustan impreson, ke krei reton bazitan sur DMVPN/PfR perdis ĉian gravecon hodiaŭ. Ĉi tio kompreneble ne estas tute vera. Ekzemple, en kazoj kie la reto uzas multajn malmodernajn ekipaĵojn kaj ne estas maniero anstataŭigi ĝin, DMVPN povas permesi vin kombini "malnovajn" kaj "novajn" aparatojn en ununuran geo-distribuitan reton kun multaj el la avantaĝoj priskribitaj. supre.

Aliflanke, oni devas memori, ke ĉiuj nunaj Cisco-kompaniaj enkursigiloj bazitaj sur IOS XE (ISR 1000, ISR 4000, ASR 1000, CSR 1000v) hodiaŭ subtenas ajnan operacian reĝimon - ambaŭ klasikan enrutigon kaj DMVPN kaj SD-WAN - la elekto estas determinita de nunaj bezonoj kaj la kompreno, ke ĉiumomente, uzante la saman ekipaĵon, vi povas komenci moviĝi al pli altnivela teknologio.

fonto: www.habr.com