Policy based networking

 Policy based networking

Požadavky aplikací

QoS, network policy apod. jsou dnes  módní pojmy. Ne každý si však dokáže představit, co znamenají a především jaký může být jejich praktický přínos. V současné době lze vidět dva základní trendy jak zajistit kvalitu služeb v síti.

QoS, network policy apod. jsou dnes  módní pojmy. Ne každý si však dokáže představit, co znamenají a především jaký může být jejich praktický přínos. V současné době lze vidět dva základní trendy jak zajistit kvalitu služeb v síti.

Prvním  je zajištění "hrubou silou". Není to ani deset let, kdy byl samozřejmostí sdílený desetimegabitový Ethernet a málokdo si uměl představit  "něco" výkonnějšího. Dnes je téměř samozřejmostí Gigabit Ethernet a usilovně se pracuje na standardizaci 10 Gigabitového Ethernetu.

Druhým přístupem je snaha rozlišovat aplikace i uživatele a zajistit, aby se síť přizpůsobila jejich potřebám.

Oba přístupy mají své opodstatnění. Praxe však ukazuje, že zahltit lze libovolně rychlou síť. Speciálně to platí ve WAN, kdy jsou dostupné rychlosti řádově nižší a upgrade na vyšší rychlost se projeví velice výrazně na výši poplatků. Objevují se stále nové aplikace, se kterými se při návrhu protokolů jako je Ethernet, IP apod. prakticky  nepočítalo. Přenos hlasu (VoIP)nebo videokonferenceklade  na síť naprosto odlišné požadavky než klasický přenos dat.  Jinými slovy každá aplikace potřebuje zajistit různé parametry.

Jaké parametry jsou pro různé typy aplikací důležité? Jsou to především:

·        rychlost neboli šířka pásma (bandwith) - jde vlastně o kapacitu spoje, udává se  v Kbps nebo Mbps;

·        zpoždění (delay) - doba mezi odesláním a příjmem paketu. Do této doby se zahrnují veškerá zpoždění způsobená průchodem zařízením, kompresí/dekompresí...;

·        proměnlivost zpoždění (jitter) - časový rozptyl zpoždění při přijímání paketů;

·        ztrátovost paketů (packet loss) - průměrná ztráta paketů v procentech za jednotku času;

·        dostupnost (availability) - dostupnost služby v procentech za jednotku času.

Z čeho vlastně vyplývají rozdílné požadavky aplikací? Uveďme si několik  konkrétních příkladů.

Multimediální aplikace (např. zmíněné videokonference nebo VoIP) jsou citlivé na zpoždění.  Lidské ucho je poměrně nedokonalé a zpoždění v desítkách milisekund není schopno zaznamenat. Větší zpoždění se projevuje jako echo, jinými slovy slyšíme sami sebe. Ještě větší zpoždění pak může způsobovat, že si budete skákat do řeči – partner začne hovořit, ale než se jeho hlas dostane k Vám, začnete hovořit taky. Rovněž proměnlivost zpoždění může působit v lepším případě komicky, v horším případě si pak nebudete rozumět. Naproti tomu zmíněná nedokonalost lidského ucha si paradoxně poradí s určitou mírou ztrátovosti.

Opačné požadavky na síť má  přenos souborů eventuálně mailů. Zpravidla není důležité, zda se soubor přenese za pár sekund nebo za pár minut. Důležité je, aby se přenesl bez ztráty jediného bitu. Mail odeslaný s velkou přílohou dokáže zahltit celou dostupnou šířku pásma.

Obchodní aplikace typu SAP, Oracle apod. zpravidla fungují v režimu klient-server, nemají příliš velké  požadavky na šířku pásma (aspoň ty dobře napsané), ale jsou citlivé na zpoždění. Nepotvrzené požadavky se opakují a mohou způsobit zahlcení sítě.

Současné sítě  se chovají ke všem aplikacím stejně. Snaží se vyhovět všem požadavkům co nejlépe (best-effort). Pokud se v jednom okamžiku objeví mnoho rozdílných požadavků, síť je nedokáže zároveň obsloužit a dostává se do nepředvídatelných stavů, které mohou způsobit nedostupnost služeb a aplikací. Například rozeslání hromadného mailu může spolehlivě zahltit síť na dlouhou dobu. Pro firmy závislé na e-business, e-commerce, prodeji přes internet takový stav znamená přímou finanční ztrátu, ale i u všech ostatních se projeví minimálně snížením produktivity práce. Jak předejít takovým problémům?

Jak je uvedeno výše, šířka pásma není jediný parametr a proto upgrade na vyšší rychlost je zpravidla pouze dočasným a ne vždy správným řešením. Rozumnější cestou je definovat pravidla, jak se má síť chovat k různým aplikacím a uživatelům. Jaká pravidla?

Například taková, že kritické aplikace (SAP, Baan, Oracle, ...) mají vždy absolutní přednost. Mail bude mít vyhrazeno maximálně 64 Kbps, hlasové komunikaci  VoIP zajistíme maximální zpoždění 50 ms, a browsování na internetu necháme "co zbude". Dále zakážeme přístup na nevhodné www stránky a stahování MP3 souborů během pracovní doby. Účetní oddělení bude mít pro přístup k SAPu zajištěnu prioritu před všemi ostatními uživateli kromě vedení.

Základní pojmy a model

V první části nového seriálu o prosazování pravidel síťového provozu jsme si definovali parametry, které jsou důležité pro různé typy aplikací, vyplývajících z jejich naprosto odlišných požadavků na síť. Z pohledu sítě se jedná o vysoce abstraktní pravidla, která odrážejí obchodní a provozní potřeby organizace. Nyní si definujeme základní pojmy a model pro tzv. policy-based networking.

V první části nového seriálu o prosazování pravidel síťového provozu jsme si definovali parametry, které jsou důležité pro různé typy aplikací,  vyplývajících z jejich naprosto odlišných požadavků na síť. Z pohledu sítě se jedná o vysoce abstraktní pravidla, která jsou snadno srozumitelná uživatelům resp. provozovatelům sítě. Tato pravidla odrážejí obchodní a provozní potřeby organizace.

Na druhé straně budou těžko srozumitelná síťovým prvkům. Ty jsou schopny rozumět pojmům jako  IP adresa, TCP nebo UDP port.  Lze namítnout, že mnohé dokáže administrátor sítě zajistit už nyní na směrovačích, firewallu, L3 přepínačích atd. Nicméně v okamžiku, kdy je v síti takových zařízení několik desítek, znamená to konfigurovat postupně jedno za druhým, vědět, který uživatel má kterou IP adresu, vědět jaký TCP/UDP port ta či ona aplikace používá.  Jinými slovy se jedná o práci na několik týdnů a o vzájemně optimalizované konfiguraci nelze v tomto případě vůbec hovořit . V případě změny nebo nasazení nové aplikace lze pak začít znovu od začátku.  Přes otázky "Jak tato pravidla jednoduše definovat?" a "Jak zabezpečit jejich jednotné prosazení v síti?" se dostáváme k pojmu Policy-based networking.

Policy se překládá do češtiny nejčastěji jako politika. Slovo politika v této souvislosti je poněkud nešťastné, v některých slovnících lze najít vhodnější zásada, podmínka. Pokud bychom chtěli být přesnější, bylo by v dané souvislosti vhodné asi použít opis – "definování, řízení  a prosazení pravidel síťového provozu".

Dále bude používán podle kontextu překlad jako pravidla nebo bude tento termín ponechán bez překladu. Rovněž jiné pojmy jsou z důvodu jednoznačnosti vždy aspoň zmíněny v angličtině.

Původní myšlenka je jednoduchá - definovat pravidla pouze jednou centrálně a automaticky je rozeslat všem zařízením v síti.V obecné rovině tato pravidla zahrnují množinu parametrů, pro které se pravidla definují (uživatelská jména, síťové protokoly, aplikace...) a množinu akcí pro zajištění resp. prosazení pravidel (garantování šířky pásma, řízení přístupu...). Znamená to, že základní model by měl zahrnovat dvě základní komponenty: policy server a policy enforcer.

Policy server zajišťuje centrální administraci pravidel a policy enforcer pak jejich prosazení v síti. Pokud se budeme držet řeči standardů, jedná se o PDP (Policy Decision Point) a PEP (Policy Enforcement Point).  PDP rozhoduje o pravidlech a PEP zajišťuje jejich prosazení v síti (anglicky enforce = prosadit). Zde je potřeba zdůraznit,  že se jedná pouze o logické dělení.  PEP může zároveň obsahovat LPDP (Local PDP) a rozhodovat o pravidlech samostatně, ať už úplně nebo aspoň částečně (viz obrázek 1).

Obr. 1 - Základní komponenty

Policy Enforcer a Policy server

Policy Enforcer může být obyčejný směrovač nebo specializované zařízení, které dokáže provádět policing. Policy server koordinuje vstupy administrátora s jinými relevantním informacemi o parametrech týkajících se pravidel síťového provozu a překládá je do formy, kterým bude rozumět síť, resp. policy enforcer.

Policy Enforcer může být  obyčejný směrovač nebo specializované zařízení, které dokáže provádět tyto akce (policing):

·        formování provozu (traffic shaping), tj. řízení šířky pásma, přidělování priorit…;

·        řízení přístupu (access control), ověřování uživatelů (authetication)…;

·        zajištění signalizace (tagging/signal provisioning), tj. překlad a posílání řídících resp. signalizačních informací (RSVP, 802.1p, MPLS, Differentiated Services).

Výhodou specializovaného zařízení je mj. to, že dokáže analyzovat provoz i na vyšších protokolových vrstvách. Směrovač,  případně L3 přepínač se dokáže "podívat" jen na 4. vrstvu.  Zpravidla je policy enforcer umístěn na rozhraní sítě, resp. policy domény, typicky mezi LAN a WAN.

Policy server koordinuje vstupy administrátora s jinými relevantním informacemi o parametrech týkajících se pravidel síťového provozu a překládá je do formy, kterým bude rozumět síť, resp. policy enforcer.

Pro komunikaci mezi PEP a PDP byl definován protokol COPS (Common Open Policy Service – RFC 2748), jednoduchý protokol "dotaz – odpověď" nad TCP. Pro zařízení, která tento protokol nepodporují lze použít SNMP, LDAP (Lightweight Directory Access Protocol) nebo i TELNET a příkazy z příkazové řádky (CLI – Command Line Interface).

Poslední nutnou komponentou jsou adresářové služby. Adresářové služby nepředstavují samozřejmě nic nového a jsou běžnou součástí sítě. Nová je pouze myšlenka využít informace v nich uložené i pro definování pravidel síťového provozu. Obsah těchto informací je definován v obecném informačním modelu (CIM – Common Information Model) resp. v jeho části.

CIM se vlastně zabývá taxonomií (systematikou) sítě a snaží se vytvořit obecný popis celé sítě, od tiskárny až po uživatele. Na tomto objektovém modelu pracuje skupina DMTF (Distributed Management Task Force). Současná verze je 2.5 a je dostupná na http://www.dmtf.org/spec/cims.html.  Část modelu týkající se Policy informací je popsána ve standardu RFC 3060. Po "namapování" informací z CIM modelu do adresářových služeb vznikne DEN (Directory Enabled Network). Pro přístup k těmto informacím se pak používá standardních prostředků, což protokol je LDAP. Pro úplnost lze dodat, že RFC standardy jsou volně dostupné na webu IETF http://www.ietf.org/rfc.html.

Policy based networking - základní komponenty

Pokud jde o architekturu "policy-based" sítě, zahrnuje základní komponenty jako jsou Policy management, Rozhraní k adresářovým službám, QoS gateway, Bandwith broker a Centrální monitorování a accounting. Dnes se podíváme na první část výše zmíněných komponent podrobněji.

Pokud se podíváme na architekturu "policy-based" sítě podrobněji (viz obrázek 2), zahrnuje následující základní komponenty:

Obr. 2 - Architektura "policy-based" sítě

·        Policy management: slouží pro definování a distribuci pravidel, koordinuje a řídí pravidla mezi management systémem, adresářovými službami a zařízeními pro "prosazování" pravidel.

·        Rozhraní k adresářovým službám: umožňuje přístup k informacím o uživatelích a aplikacích uložených v adresářových službách (např. Novell NDS, Microsoft Active Directory). Díky tomu lze transformovat pohled na úrovni uživatelů, skupin uživatelů i aplikací do pravidel.

·        QoS gateway: zabezpečuje end-to-end prosazování a řízení definovaných pravidel v síti, zpravidla pomocí standardních signalizačních protokolů jako je RSVP, ToS, 802.1p, MPLS…

·        Bandwith broker: zprostředkovává dohodu o úrovni služeb mezi více QoS doménami.

·        Centrální monitorování a accounting: umožňuje centrální monitorování a záznam informací pro zpětné vyhodnocení dodržování pravidel (accounting). Poskytovatelům služeb může sloužit  pro účtování služeb (billing) a prokázaní dodržení dohody o kvalitě služeb (SLA – Service Level Agreement).

Podívejme se na výše zmíněné komponenty podrobněji.

Funkcí policy managementu je koordinovat vstupy administrátora s jinými relevantním informacemi o síti a aplikacích a přeložit je do formy, které bude rozumět síť, resp. policy enforcer. Policy management může řídit více domén, může být distribuován a může mít hierarchickou strukturu, tzn. že pravidla definovaná na vyšší úrovni (např. na úrovni celého podniku) mohou být "zděděna" na nižší úrovni (např. na úrovni oddělení). Využívá se tak výhody objektového modelu CIM.

Obr. 3 - Policy Management

Policy management je tvořen několika logickými  částmi (viz obrázek 3): Policy Editor, samotné rozhraní k adresářovým službám a Policy Decision Administrator. Toto členění je pouze logické a jednotlivé komponenty mohou fungovat samostatně nebo být součástí jednoho celku.

Policy Editor umožňuje správci centrálně definovat pravidla na úrovni uživatelů a aplikací. Tato pravidla jsou pak  uložena v databázi adresářových služeb, komunikace probíhá před LDAP. Adresářové služby tak mohou obsahovat nejen informace o uživatelích, ale i informace o pravidlech, která se jich týkají z hlediska provozu sítě. Jednoduše tak lze vytvářet dynamická pravidla aniž bychom se zabývali konkrétními IP adresami, protokoly, TCP nebo UDP porty na 4. vrstvě OSI.  Policy editor může být samostatná aplikace např. v JAVě nebo může být integrován v jiných management systémech jako je např. HP OpenView.

Policy Decision Administrator plní funkci centrálního řídícího centra a dokáže:

·        překládat pravidla a parametry uložené v adresářových službách do akcí a pravidel srozumitelných síti;

·        komunikuje s policy enforcer zařízením i ostatními zařízeními, která jsou schopna pracovat s těmito informacemi a předává jim informace o aktuálních pravidlech, zpravidla pomocí standardních protokolů COPS, LDAP, SNMP, eventuálně TELENTu a  CLI (Command Line Interface);

·        spolupracuje s Policy Editorem, ukládá informace definované administrátorem v adresářových službách (LDAP) a dále je rozesílá (už ve formě srozumitelné síťovým zařízením);

·        centrálně shromažďuje informace pro monitoring a accounting.

Policy based networking – další komponenty

Policy Decision Administrator zaručuje, že pravidlo definované centrálně z pohledu uživatelů a aplikací bude automaticky uloženo na adresářovém serveru a rozdistribuováno všem zařízením. QoS gateway pak identifikuje pakety přicházející z jedné domény. Bandwith broker zprostředkovává automatickou dohodu o úrovni služeb mezi více QoS doménami. Nutností je i on-line monitoring a dlouhodobý záznam provozu tzv. accounting.

Policy Decision Administrator zaručuje, že pravidlo definované centrálně z pohledu uživatelů a aplikací bude automaticky uloženo  na adresářovém serveru a rozdistribuováno všem zařízením. Konkrétní implementace opět může být různá - buď aplikace přímo běžící na adresářovém serveru nebo samostatná aplikace komunikující s adresářovými službami prostřednictvím LDAPu. Část může být přímo součástí enforcer zařízení, které se pak může rozhodovat do jisté míry nezávisle a policy manager představuje vyšší úroveň rozhodování.

Obr. 4 - Policy Decision Admistrator

Z pohledu funkčnosti lze rozčlenit Policy Decision Administrator na dvě vrstvy:

Data Abstaction Layer. Tato vrstva spolupracuje s adresářovými službami a rozumí struktuře i obsahu definovaných pravidel.

Device Abstraction Layer. Tato vrstva překládá pravidla tak, aby byla srozumitelná konkrétním zařízením a následně je těmto zařízením odesílá pomocí standardních protokolů jako je COPS, LDAP, SNMP, případně pomocí řádkových příkazů.

Například administrátor definuje v adresářových službách novou proměnou "Typ služby" a pro konkrétního uživatele  X definuje typ služby jako Gold. Typ služby je nyní jako proměnná v adresářových službách přístupná přes Policy Editor a administrátor s ní může dále pracovat, může například přidat časové upřesnění, definovat kterých protokolů se bude týkat atd.  Nakonec "přeloží" typ služby Gold, jinými slovy definuje, že se jedná minimální šířku pásma 128 Kbps, maximálně pak 256 Kbps. Uživatel  X je pro potřeby enforceru přeložen na konkrétní IP nebo MAC adresu. Díky tomu, že je pravidlo definováno na jméno uživatele, které se nemění, bude platit toto pravidlo i v případě, že se uživatel přihlásí z jiného PC apod.

QoS gateway identifikuje pakety přicházející z jedné domény. Pokud splňují definovná  pravidla, pošle je dále s odpovídající signalizací - doplní například 802.1p tag nebo  provede označení nebo změnu TOS políčka v IP paketu. Může taky provádět překlad různých signalizací mezi doménami nebo provádět lokální řízení šířky pásma. Například podle pravidla, že "veškerý provoz od uživatelů s prioritou 2 má garantovanou šířku pásma 100 Kbps". Jedná se de facto o Policy Enforcer pro danou doménu.

Bandwith broker zprostředkovává automatickou dohodu o úrovni služeb mezi více QoS doménami. Dlouhodobě sleduje síť. Pokud přijde požadavek na zřízení nového spojení, vezme v úvahu aktuální stav sítě, počet aktuálně garantovaných spojení atd. a na základě toho rozhodne, zda může být spojení zřízeno a s jakými konkrétními parametry. Pokud je pro uživatele definována maximální šířka pásma 384 Kbps a minimální 128 Kbps, může podle aktuálního stavu sítě přidělit např. 256 Kbps.

Rozhodnout, jaká pravidla definovat a zpětně vyhodnotit, zda byla definována správně, předpokládá jednak podrobnou analýzu provozu sítě a detailní záznam co se v síti děje. Nutností je proto on-line monitoring i dlouhodobý záznam provozu tzv. accounting. Accounting je pak naprosto nezbytný pro poskytovatele služeb. Pokud uzavře s uživateli dohodu o poskytování služeb a jejich kvalitě (SLA – Service Level Agreemenet), pak může na základě zaznamenaných údajů prokázat zda SLA dodržel nebo ne. Zároveň jsou to vstupní údaje pro účtování služeb (billing). Na tomto místě je potřeba zdůraznit nezbytnost zpětné kontroly. Podmínky v síti se průběžně mění, přibývají aplikace i uživatelé. Definování pravidel je proces a je nutné průběžně udržovat a vyhodnocovat, zda jsou definována správně vzhledem k aktuálnímu stavu sítě.

Řešení Allot Communications

V současné době už prakticky všichni velcí výrobci uvedli na trh svá řešení pro policy networking. Příkladem takového řešení může být např. Cajun Rules  společnosti Avaya.  Na druhé straně jsou menší firmy, které patří k průkopníkům tohoto řešení. Příkladem může být Allot Communications.

V současné době už prakticky všichni velcí výrobci uvedli na trh svá řešení pro policy networking. Příkladem takového řešení může být např. Cajun Rules  společnosti Avaya.  Na druhé straně jsou menší firmy, které patří k průkopníkům tohoto řešení. Příkladem může být Allot Communications (viz obrázek 5). Výhodou takového řešení je, že se tito výrobci museli vypořádat s interoperabilitou s jinými výrobci. Dokážou tak maximálně sladit výhody svého řešení, např. analýzu a zpracování až po 7. vrstvu OSI, s řadou standardních mechanismů (COPS, LDAP, DiffServ...).

Obr. 5.- Řešení firmy Allot Communications

Základním produktem je NetEnforcer. Jde o "policy enforcer" dostupný ve třech variantách

podle rychlosti linky (připravuje se gigabitová verze):

·        AC101 do  512 Kbps;

·        AC201 do 10 Mbps;

·        AC301  do 100 Mbps.

NetEnforcer lze volitelně doplnit o softwarové moduly:

·        CacheEnforcer - optimalizuje využití cache a určuje, který provoz půjde přímo a který přes cache;

·        NetBalancer - zajišťuje optimální využití a vysokou dostupnost serverů na základě IP load balancingu;

·        NetAccountant - detailně sleduje provoz sítě a vytváří podrobné reporty o provozu sítě.

Díky NetPolicy, volitelnému policy management software pro řízení QoS, lze pak centrálně konfigurovat pravidla pro síť a to i ve spolupráci s prvky dalších výrobců (CISCO, RadGuard...).

Nástup "Policy based networking" byl poněkud pomalejší než mnozí výrobci pravděpodobně čekali. Hotová řešení jsou však již na trhu běžně dostupná a mají za sebou období "dětských nemocí".  Mnozí uživatelé si uvědomují výhody definování pravidel provozu na WAN linkách. Zde je úspora prakticky okamžitá. S nástupem VoIP a videokonferencí  se takové řešení stane nutností i v lokálních sítích. Při pořizování nových síťových prvků se to však vyplatí zohlednit už nyní.