3Com hírek 2010. január 4. szám T a r t a l o m A nagyvállalati VCX telefonrendszer új tagja jelent meg, az MSR routerekbe tehető VCX MIM modul, amely 100 mellékig bővíthető 2. oldal Egyirányú forgalom? A DLDP és BFD sok problémától megkímélhet bennünket, amely csatlakozó, takarító vagy rendszergazda hibájából eredhet 3. oldal A vállalati forgalmak szétválasztása Layer2- n a VLAN-ok használatával egyre elterjedtebb. De milyen eszközeink vannak a Layer3 fogalom szeparációra? 5. oldal Miért jó a QoS switch-elt környezetben, milyen eszközök vannak a kezünkben, hogyan használhatjuk ezeket? 6. oldal Ajánló mi jöhet még?! utolsó oldal Bevezető Megújultunk. Ennek látható eredménye, hogy tavaly ősszel új, magyar hírek szekció keletkezett, amely elérhető e-mailen, weben és partneri FTP-n keresztül (részletek hátul). Segítségével az aktualitások és fókuszban lévő újdonságok gyorsabban és érthetőbben jutnak el a tervezőkhöz, rendszerintegrátorokhoz, megkönnyítve a termékválasztást. A munkához sok sikert és spanning-treeben kószáló bitet kíván a magyar csapat: Takács Gergely Rab Gergely Gergely_takacs@3com.com Gergely_rab@3com.com +36 30 250-8070 +36 20 9123-475 Kereskedelmi képviselet vezető, a sales A műszakis 1
3Com H3C újdonságok VCX MIM modul MSR 30-as routerekbe A VCX a 3Com IP Telefóniás rendszereinek egyike (a másik az NBX). Főként nagyvállalati alkalmazásként használják bővíthetősége, integrációs lehetőségei és a támogatott IP Telefonos elrendezések miatt. A VCX 9.0 verzióval, amely 2008-ban jelent meg, számos újdonság került a rendszerbe, ezek egyike a továbbfejlesztett SIP támogatás és az MSR routerek PSTN voice gateway-ként 1. ábra - VCX MIM modul használata. Az MSR routerekbe eddig is kaphatóak voltak hang képes ISDN BRI, ISDN Primer, FXO, FXS és E&M kártyák, a VCX integráció és minősített hang átjáróként használata azonban váratott magára. A 9.0 verzióval ez is megtörtént, és a hagyományos 6000-es és 7000-es sorozatú integrált voice gateway-ek mellett az MSR routerek is használhatóak voice gateway célokra. Az MSR 30 routerek 1-6 MIM modul slottal rendelkeznek, amely slotokba az újonnan megjelent VCX modul is konfigurálható. A modul egy teljes értékű IP Telefóniás megoldás, jellemzőiben teljesen lefedi a különálló szerverre telepített Classic, Enterprise és Expand feature-eit. A modul IP Telephony Partner és IP Telephony Elite Partner minősítéssel rendelkező viszonteladók számára elérhető. Skálázhatóság: 100 mellék és postafiók Hangposta: 4000 óra feletti kapacitás Voice gatewayként használható eszközök: MSR 20, MSR 30, MSR 50, V6000 és V7000 Modulhoz adott licenszek: A VCX Connect Primary és VCX Connect Secondary MIM-hez VCX IP Telephony and IP Messaging 9.x Server License, 25 darab Business Phone License, 25 darab IP Messaging Seat License, 25 darab Desktop Communicator Soft Phone License, 25 darab Convergence Client Soft Phone License és 4 Analog/Entry Phone License jár. A VCX Enterprise Branch MIM-hez VCX V6100/EBM IP Telephony and IP Messaging 9.x Server License (3CV6100TM9L) megvásárlása szükséges Cikkszám Megnevezés Listaár (USD) 0231A0D2 VCX Connect Primary MIM (CPM) $ 2,500 0231A0D3 VCX Connect Secondary MIM (CSM) $ 2,300 0231A0D4 VCX Enterprise Branch MIM (EBM) $ 1,900 2
3CRBVCXMSR01A MSR 3040 VCX Enterprise Branch MIM Bundle $ 3,850 3CRBVCXMSR02A MSR 3016 VCX Enterprise Branch MIM Bundle $ 3,250 3CRBVCXMSR03A MSR 3016 VCX CPM 4FXO, 2FXS Bundle $ 3,700 3CRBVCXMSR05A MSR 3040 VCX CPM 8FXO, 4FXS Bundle $ 5,350 3CRBVCXMSR06A MSR 3040 VCX CPM 8BRI, 4FXS Bundle $ 6,900 3CRBVCXMSR08A MSR 3040 VCX CPM 1 E1, 4BRI, 4FXS Bundle $ 7,500 További információk a mellékletben és az alábbi linken érhetőek el: http://www.h3c.com/portal/products Solutions/Products/ http://paweb17.3com.com/secure/global/mktfiles4.nsf/html/convergence-vcxcollateral/$file/3com_401052-005_15jan10.pdf http://paweb17.3com.com/secure/global/mktfiles4.nsf/html/convergence-vcxcollateral/$file/3com_400956-007_15jan10.pdf Technológiai sarok DLDP, UDLD, BFD, CFM, SmartLink, RRPP, RPR, ABC, MZ/X Csak térerő legyen meg egészség! és kétirányú link a két switch között, hogy a spanning-tree nehogy összedőljön. Ha két eszköz között csak az egyik irányban megy a forgalom, akkor a furcsa hibák mellett a hálózaton futtatott Layer2 és Layer3 nem session-alapú protokollok kapnak a szomszédoktól információkat, és a küldött csomagokról is úgy gondolják, hogy elküldték, viszont ezek a csomagok soha nem érkeznek meg ezáltal kör alakul ki a hálózatban. A switchek és routerek az egyirányúsodást gátló protokollok tekintetében nagyban különböznek egymástól, és ez az eszközök árában is megmutatkozik. Beruházáskor felmerül a kérdés, hogy például egy 4200G vagy 4800G GigabitEthernet switchet szerezzünk be, amelyek ára között a kétszeres szorzó által ásott szakadék húzódik, jellemzők tekintetében a 4800G a vizsgált protokollok közül támogatja a DLDP-t és RRPP-t, a 4200G nem. Mennyit ér meg a hálózat egyirányúsodása elleni védelem? Mennyi kiesést okoz, és mekkora pénzbe kerül a hibát detektálni és kijavítani? Egy kis hálózatban, 4-5 switches környezetben igen hamar ki lehet zárni, hogy melyik switch terheli túl a hálózatot, e felett azonban a hibadetektálásra legalább két órát számolhatunk. Ez idő alatt az 5 switchre csatlakoztatott 200 felhasználó nem éri el a szervereket. Minimálbérrel számolva ez 219.084 Ft-os veszteséget okoz a vállalkozásnak. Vajon mekkora a valószínűsége, hogy 3-5 éven belül a rengeteg, switcheinket összekötő kábel közül az egyik többnyire külső behatásra meghibásodik? 3
A DLDP (Cisco-s terminológia szerint az UDLD) réz és üveg kapcsolatokat véd Layer 2-n az egyirányúsodás ellen. Mindkét oldali switchnek kell támogatnia a funkciót, mivel a switch visszavárja a kiküldött DLDP csomagot, és ellenőrzi, hogy a benne lévő azonosító a sajátja-e. A BFD komplett utak kiesése ellen véd, azaz felhasználható routerek közötti elérés, különösképpen MPLS hálózatok feletti hiba detektálására. Ennek előnye, hogy hálózati gerinc sérülését a végponti eszköz is képes detektálni, így lehetővé téve, hogy a forgalomnak más utat válasszon. Ethernet Link OAM (802.3ah) és CFM (802.1ag) bűvszavak főként szolgáltatói környezetben elterjedtek, ahol egy Layer2 link hogylétéről távolról szeretnek tájékozódni, és az egészségi állapot függvényében döntéseket hozni (pl. csomagok másfelé route-olása, riasztás küldése, stb.). Ennek kiterjesztése az, amikor nem csak egy Layer2 link, hanem egy egész út (link switch link switch link) vizsgálata fontos, különböző hozzáférési szinteken és például Layer2 traceroute lehetőséggel. Az RRPP gyűrűs protokoll, amely 50-250ms védelmi idővel lát el hagyományos Ethernet hálózatokat. Jelenleg a 4800G kategória feletti switchek támogatják (az 5500G kivételével). Az RPR-t H3C 9500-tól felfelé és SR88 routereken támogatjuk: speciális interface-ekkel megvalósított gyűrűs protokoll, főként szolgáltatói környezetre optimalizálva. A másik két betűszó megoldásait várjuk a gergely_rab@3com.com címre hírlevél extra tárggyal További információk az alábbi linken érhetőek el: http://www.h3c.com/portal/products Solutions/Technology/ 2. ábra - Forrás: http://www.infraexpert.com Forgalmak szétválasztása végponttól végpontig MPLS a vállalati hálózatban Kezdetben volt a hub, ahol minden forgalom egy collision domainben és egy Layer2 broadcast domainben volt. Aztán jött a switch, ahol minden egyes port egy külön collision domaint alkotott, de az egész switch egy nagy Layer2 broadcast domainben volt. Ezt fűszerezték meg a Virtuális LAN-ok, azaz VLAN-ok kialakításának lehetőségével, ahol már egy fizikai switchen belül több különböző VLAN cimkével ellátott Layer2 broadcast doamain kapott helyet. A routerben azonban megállt a forgalmak hermetikus szétválasztása. Gondoljuk csak el: két telephely, a telephelyeken belül két VLAN, egyik a 4
hangnak másik az adatnak, és a két telephely közötti vonalat 1-1 router kezeli. Célunk a forgalmak szétválasztásával az, hogy a biztonság növekedjen (pl. hang, adat, menedzsment és védett forgalom külön kezelése a betörési lehetőségek csökkentésére, lehallgatási lehetőségek minimalizálására) vagy a hálózatmenedzsment egyszerűsödjön. A kártyás fizetéssel foglalkozó vállalatokra vonatkozó PCI (Payment Card Industry) előírások meg is követelik a kártyás és a többi forgalom külön kezelését (https://www.pcisecuritystandards.org/pdfs/pci_scanning_procedures_v1-1.pdf illetve http://en.wikipedia.org/wiki/payment_card_industry_data_security_standard ). Amikor megérkezik egy forgalom az adott telephelyi routerbe, honnan fogjuk tudni, hogy melyik VLAN-ból indították? Csak a forrás IP címet ismerjük a feladó oldaláról, és mint tudjuk, a routing lokális döntés, a cél cím alapján. Persze alkalmazhatunk policy based routingot, de az annyira lelassítja a routerünket, hogy nagyobb forgalmak esetén ellenjavallt. A megoldás erre az MCE vagy VRF lite, amely MPLS nélküli Layer3 forgalomszétválasztást jelent (a VRF jelentése: VPN Routing Forwarding). A jobb oldali ábrán látható kék és piros forgalmak a switchekben külön VLANként jelennek meg, és a fekete színű trunkön külön-külön VLAN-ban mennek tovább. Az egyes VRF instance-ok külön routing táblával és routing protokol adatbázissal rendelkeznek, így a routing protokollok is akár más-más utat választhatnak a VRF-ek függvényében. Igen, a routing után is külön VLAN-ban mennek, mivel a különböző VRF-ekhez 3. ábra - Forrás: http://www.packetlife.net/blog/2009/apr/30/intro-vrflite/ különböző interface-eket kell hozzárendelni, a routerben ez a VLAN interface-ek hozzárendelését jelenti (interface Vlan-interface XX alatti MPLS parancs a tényleges módja). Azaz az MCE vagy VFR-lite éppen olyan skizofrén állapot létrehozása Layer 3-on, mint a VLAN-ok létrehozása és kezelése volt Layer2-n. Felmerül a kérdés, hogy vajon mekkora adminisztrációval jár egy VLAN létrehozása és a routing végigkövetése az összes routeren, ami azzal jár, hogy az újonnan bekonfigurálandó VLAN számára vagy külön VRF-et kell létrehozni vagy valamelyik már meglévő VRF-hez kell hozzárendelni azt? A válasz egyszerű: nagy. Ezért (és sebességnövelési szempontok miatt) találták ki, hogy az összes csomagot lássák el egy címkével, amely egyértelműen megjelöli, hogy melyik VRF-be tartozik és melyik Layer3 eszköz felé igyekszik: ez a címkézéses útválasztási mód lett az MPLS (Multi-Protocol Label Switching). Ennél a fizikai linkeket Layer3-on nem kell VLAN-okra feldarabolni, mivel a csomagok elején lévő címkék egyértelműen azonosítják a VPN-t, így minden csomag egy nagy közös csövön utazik. Adminisztrációját tekintve a Label Distribution Protocol (LDP) felállítása és automatikus karbantartása az egyetlen feladatunk (amelyet 5
végezhetünk ismert routing protokollal), így a hálózat bonyolultsága bár az MPLS bevezetésével nő, az adminisztrációs igénye már 10-20 VLAN felett jelentősen kisebb a hasonló megoldásokhoz viszonyítva. Gyakorlati tanácsok QoS switchelt hálózatokban A QoS szükségessége switchelt hálózatban A gyártók váltakozó állásponton vannak a Layer2 QoS szükségességének mértékét illetően, azonban a vezető gyártók egyetértenek abban, hogy alapvető Layer2 QoS nélkül nem lehet felsőbb szintű QoS-t sem implementálni. A csomagot legalább az indulásakor vagy az első aktív eszközbe érkezésekor meg kell jelölni, és ezután a jelölésnek megfelelő módon kezelni (DiffServ modellel összhangban). Mért kell bárhogyan is kezelni ezeket a csomagokat? Azért, mert a hálózatok általában alultervezettek: az uplink sávszélessége nem nagyobb, mint az access portok maximum sávszélességeinek összege. Ritka az a hálózat, ahol 48 portnyi 10/100-as kapcsolatra legalább 5Gbit/s felszálló sávszélesség esik (általában ez 1-2 Gbit/s). Mi történik, ha mindenki egy e-learning tanfolyam anyagát hallgatja, és közben egy kolléga FTP-zni kezd, vagy egyszerűen csak elküld egy nagy melléklettel rendelkező levelet? Jó esetben csak szakadozni fog a hang, rossz esetben az egész alkalmazás time-outra fut. Fontos tehát, hogy a hálózaton kavargó forgalmak között rendet tegyünk, és megmondjuk, hogy - milyen fontossági sorrendet tudunk felállítani (megjelölés prioritás szerint) - mit teszünk a torlódás elkerülése érdekében, miből dobunk el (torlódás elkerülés) - hogyan szolgáljuk ki a prioritási osztályba tartozó forgalmakat torlódás esetén (queuing) - milyen sávszélességet rendelünk hozzá az egyes forgalmakhoz (queuing szintén) - milyen egyéb technikákat vonunk be (többnyire Layer3) a késleltetés és késleltetés változás minimalizálására A QoS tehát nem csak queuing (pl. WRR, SP, CBWFQ, FIFO), hanem a forgalommenedzsment technikák összessége. Fontos alaptétel, hogy queuing addig hatásosan nem történik, amíg nincs torlódás. A QoS fajtái Queuing FIFO First In First Out, vagyis minden csomagot érkezési sorrendben továbbítunk. A várakozási sorunk tulajdonképpen egy csővezeték, ami bement, az előbb-utóbb ki is jön. A fontos vagy sürgős csomagok nem előzik meg a kisebb prioritású csomagokat. 6
Queuing Priority Queuing (PQ) és Strict Priority (SP) A csomagokat érkezéskor a négy vagy nyolc prioritási szint egyikébe soroljuk megjelölésük alapján. A prioritási sorokból úgy szolgáljuk ki a forgalmakat, hogy amíg a felsőbb (fontosabb) prioritási sorban van csomag, addig az alsóbb prioritási sorban lévő sorokból nem továbbítunk csomagot. Ez a kisebb prioritású várakozási sorok kiéheztetését eredményezheti. Queuing Custom Queuing (CQ) és Weighted Round Robin (WRR) Amíg a PQ és SP mindig a fontosabb, feljebb lévő várakozási sorban lévő forgalmakat feltétel nélkül kiteszi a kimenő interface-re, addig a CQ és WRR esetén megadható, hogy a teljes sávszélesség hány százalékát kapja meg egy várakozási sor, illetve mekkora csomagmennyiség után ugorjon az ütemező a következő várakozási sor kiszolgálására. Queuing Wighted Fair Queuing (WFQ) A WFQ egy nagyon könnyen beállítható, automatikusnak mondható önkonfiguráló queuing algoritmus, amely a flow-k, vagyis folyamok sávszélesség igényének megfelelően és a csomagméretekhez alkalmazkodva próbál kiegyensúlyozott sávszélességet nyújtani. A kis csomagokat beágyazza a nagy sávszélesség igényű stream-ek nagy csomagjai közé az élni és élni hagyni számítógépes implementációjának megfelelően. Az algoritmus hibája, hogy jelentős túlterhelés esetén a működése nem lesz megjósolható. 7
Queuing Class Based Weighted Fair Queuing (CBWFQ) és Low Latency Queuing (LLQ) A CBWFQ a CQ és a WFQ ötvözéséből született. A forgalmakat osztályokba soroljuk, és ezekre az osztályokra határozzuk meg, hogy CQ vagy WFQ legyen a queuing algoritmus. LLQ kiterjesztés esetén ehhez még hozzáveszünk egy PQ besorolási lehetőséget, amely a késleltetés érzékeny alkalmazásokat (pl. hang és videó) a többi forgalom elé sorolja. A teljes modell tehát a következő: Forgalomhoz prioritás rendelése Prioritások osztályokba sorolása osztályok kiszolgálása (először PQ, majd CQ és WFQ) Torlódás elkerülés - Weighted Random Early Detection (WRED) Mielőtt a torlódás kialakulna, és ezért queuingra lenne szükség vagy nagymértékű torlódás kialakulna, választhatjuk azt, hogy megelőző csapást mérünk a TCP stream-ekre, és véletlenszerűen eldobálunk belőlük. Az eldobás hatására a TCP mérsékli az ablakméretét és újraküldi a csomagot, ezáltal csökkentve a stream által igényelt sávszélességet. A várakozási sorok betelése előtti véletlenszerű eldobás azt is lehetővé teszi, hogy a várakozási sor betelésekor fellépő sorvégi eldobás (tail drop) a stream-eket sokkal érzékenyebben érintse a stream-eket (néha-néha eldobni egy csomagot sokkal jobb megoldás, mint egyszer csak 10 egymás utáni csomag eldobása). A WRED még a queuing előtt valósul meg, így a várakozási sorokba már olyan forgalmak jutnak, amiket megegyeltünk (WRED másként: http://www.ezermester.hu/articles/article.php?getarticle=2122). Sávszélesség szabályozás Traffic Policing és Traffic Shaping Beszélhetnénk most mindenféle egy, két és háromszínű többvödrös policingról, de nem tesszük, mert ezt majd a Layer3 QoS-nél kifejtjük. A fontos azonban az, hogy a Traffic Policing egyértelmű sávszélesség határnál vágja le a forgalmat és nem bufferel, míg a Traffic Shaping bufferel. A késleltetés változás érzékeny felhasználások (pl. hang, videó) nem tesz jót a bufferelés, ezért ezeknél legfeljebb a Policing alkalmazható. A Traffic Policing másik neve a CAR (Committed Access Rate), míg a Traffic Shaping-é a GTS (Generic Traffic Shaping). 8
5. ábra - Traffic Policing 4. ábra - CAR vs. GTS 6. ábra - Traffic Shaping 7. ábra A QoS lépései Általánosságban elmondható, hogy a switchek és routerek QoS konfigurálása abban különbözik, hogy a switchekben a QoS támogatása hardveres, így azok erősen kötődnek a hardver queue-khoz. A switchekben a forgalmakat a 802.1p prioritás (Layer2) vagy DSCP érték (Layer3) alapján Local 9
Precedence (LP) értékkel feleltetik meg, amely a hardveres várakozási sorral megfeleltetést jelenti. Vagyis ha egy forgalom LP értéke 4, akkor az a 4-es hardver queue-ba fog sorolódni. A porton egyedileg vagy globálisan megadható, hogy a 4-es queue WRR vagy SP legyen. Az ütemező a legmagasabb számú hardveres várakozási sortól a 0 felé haladva vizsgálja az ütemezés típusát és a sorban lévő forgalmat. 802.1p LP, DP hozzárendelés Csomag prioritási értéke érkezéskor dot1p-lp hozzárendelés dot1p-dp hozzárendelés 802.1p prioritás (dot1p), csak 802.1Q megléte esetén! Local precedence (lp; hardver queue szám) Drop precedence (dp; eldobási precedencia) 0 2 0 1 0 0 2 1 0 3 3 0 4 4 0 5 5 0 6 6 0 7 7 0 DSCP LP, DP, dot1p hozzárendelés Csomag prioritási értéke érkezéskor DSCP érték dscp-lp hozzárendelés dscp-dp hozzárendelés dscp-dot1p hozzárendelés Local precedence (lp; hardver queue szám) Drop precedence (dp; eldobási precedencia) 802.1p prioritás (dot1p) 0-7 0 0 0 8-15 1 0 1 16-23 2 0 2 24-31 3 0 3 32-39 4 0 4 40-47 5 0 5 48-55 6 0 6 55-63 7 0 7 10
QoS példa egy switchre acl number 2100 rule 0 permit source 10.10.1.0 0.0.0.255 acl number 2101 rule 0 permit source 10.10.11.0 0.0.0.255 acl number 2102 rule 0 permit source 10.10.12.0 0.0.0.255 traffic classifier rede0 operator and if-match acl 2100 traffic classifier rede1 operator and if-match acl 2101 traffic classifier rede2 operator and if-match acl 2102 traffic classifier rede3 operator and if-match dscp cs6 traffic behavior limit3 car cir 320 cbs 4000 ebs 4000 green pass red discard yellow pass traffic behavior limit2 car cir 256 cbs 4000 ebs 4000 green pass red discard yellow pass traffic behavior limit1 car cir 192 cbs 4000 ebs 4000 green pass red discard yellow pass traffic behavior limit0 car cir 128 cbs 4000 ebs 4000 green pass red discard yellow pass qos policy Policy0 classifier rede0 behavior limit0 classifier rede1 behavior limit1 classifier rede2 behavior limit2 classifier rede3 behavior limit3 interface GigabitEthernet6/0/1 qos wrr sflow enable inbound sflow enable outbound interface GigabitEthernet6/0/3 qos trust dscp interface Ten-GigabitEthernet2/0/1 port link-type trunk port trunk permit vlan 1 200 250 qos apply policy Policy0 outbound 11
Ajánló Következő hírleveleinkből: - 3Com H3C újdonságok - SFP, SFP+, XFP, BiDi SFP-k és XFP-k - QoS route-olt hálózatokban - Egy beruházás haszna és az eszközjellemzők esettanulmány - Pover over Ethernet história - Ethernet alapú storage hálózatok méretezése Fel- és leiratkozás: gergely_rab@3com.com-ra küldött levéllel Webes letöltés http://www.comteq.hu/nl FTP hozzáférés: szerver: ftp12.maxer.hu bejelentkezés: comteq_hu_3community jelszó: comit 12