hledat:

3   Provoz a rozvoj páteřní sítě CESNET2

V období roku 2003 prošla páteřní síť CESNET2 celkovou přestavbou jak z hlediska logické topologie, tak i z pohledu technologie a provozovaných služeb i jejich stability a celkové dostupnosti. Většinu stanovených cílů se podařilo splnit, ale v průběhu prací se ukázalo, že bude v některých případech nutno využít náhradních řešení. Konečného plánovaného stavu bude dosaženo až počátkem roku 2004. Částečné zdržení bylo způsobeno zpožděním dodávek nového hardware (Supervizor Engine Sup720 s HW podporou IPv6 do přístupových směrovačů jádra sítě OSR7609), s jejichž vývojem a výrobou měl výrobce velké problémy. Síť CESNET2 je prvním zákazníkem Cisco Systems, který tyto nové výkonné řídící karty nasazuje v produkční síti.

Stručně lze vývoj a změny v páteřní síti shrnout do několika bodů:

• Nasazení nových přístupových směrovačů Cisco OSR7609 (dočasně se Supervizor2/PFC2 Engine) do provozu a celková rekonfigurace všech GigaPoP (období březen-květen).
• Zprovoznění přímého peeringu se slovenskou akademickou sítí SANET (duben).
• Zdvojení jádra sítě a vytvoření zálohovaných připojení všech GigaPoP (květen).
• Zálohování připojení na Telia International Carrier (poskytovatel zahraniční konektivity) a připojení do NIXu (červen).
• Implementace IPv6 v produkční části sítě a dual-stack IPv4/IPv6 peeringu se sítí GÉANT (červen).
• Celkové zvýšení stability a dostupnosti sítě s využitím Cisco NSA services.
• Přechod z pronajatých datových okruhů (služeb) na pronajatá optická vlákna osazená vlastní technologií.

3.1   Topologie páteřní sítě

Základní logickou topologii páteřní sítě tvoří deset uzlů (GigaPoP) vzájemně propojených datovými okruhy s přenosovou kapacitou nejméně 1 Gb/s (viz obrázek). Páteřní okruhy využívají GE (gigabitový Ethernet) a POS STM-16/OC-48 pro přenosové kapacity 2,5 Gb/s. Většina gigabitových uzlů sítě je připojena do páteřní sítě dvěma datovými okruhy pro zálohování přístupu. Vlastní optické okruhy jsou osazeny několika různými způsoby:

GBIC-CWDM-1550

CWDM GBIC lze použít jen pro GE na kratších trasách. Využíváme provedení pro vlnovou délku 1550 nm, pro kterou je útlum signálu nejnižší (výrobce udává typický dosah kolem 100 km a překlenutelný útlum 32 dBm). Jsou využívány např. na trasách Praha-Pardubice, Praha-Ústí nad Labem, Ústí nad Labem-Liberec a Olomouc-Zlín.

Tyto GBIC jsou též nasazeny na mezinárodní trase Brno-Bratislava, kde bylo nutné s ohledem na celkovou délku trasy použít přepínač Catalyst 3524 jako regenerátor signálu.

Optické EDFA zesilovače

Využitím těchto zesilovačů se zabývá projekt Optické sítě a jejich rozvoj (viz dále). V současné době jsou nasazeny na většině delších optických tras (Praha-Plzeň, Plzeň-České Budějovice, České Budějovice-Brno, Brno-Ostrava, atd.). Osazení jednotlivých tras je navrženo tak, aby se aktivní prvky nacházely jen na koncích tras (NIL). Optické trasy jsou navíc protokolově transparentní.

Optické SDH regenerátory STM-16/OC-48

Optickými regenerátory Cisco ONS15104 jsme osadili první optické trasy páteřní sítě (např. Praha-Brno). Regenerátory provádějí kompletní opto-elektro-optickou regeneraci dle ITU SONET/SDH standardů (zpoždění signálu cca. 20 us) na úrovni line a section layer. Pro in-band management využívají 192 kb/s SDCC kanál (telnet/ssh přístup a SNMP). Nevýhodou regenerátorů je relativně malý dosah (cca 80 km), takže je nutné je nasazovat v průběhu optické trasy (např. na trase Praha-Brno o délce 320 km jsou použity tři), a protokolová závislost (pouze SONET/SDH).

Z hlediska možností správy, jejich funkcí a spolehlivosti plně vyhovují potřebám provozu sítě, neboť od doby osazení trasy (v roce 1999) s nimi nebyly žádné problémy. V následujícím období předpokládáme vybudování nové trasy Praha-Brno s využitím DWDM, která nahradí stávající technické řešení.

Přechod všech páteřních tras na optická vlákna bude dokončen během ledna roku 2004. Topologii sítě jsme byli nuceni přizpůsobit dostupnosti optických tras mezi jednotlivými uzly. Některé plánované trasy se nepodařilo realizovat, nebo by jejich osazení bylo příliš drahé (velké vzdálenosti), případně některé z nich procházejí lokalitami jiných uzlů a je vhodnější je ukončit v nich (např. trasa Ústí nad Labem-Plzeň prochází přes Prahu a byla proto ukončena v pražském uzlu).

Z nových tras budou realizovány trasy Hradec Králové-Olomouc a Olomouc-Ostrava, které nahradí stávající trasu Hradec Králové-Ostrava. V rámci dokončení přechodu na vlastní optická vlákna zbývá ještě dořešit některá náhradní řešení, která vznikla zpožděním dodávek optických zesilovačů či jako následek technických problémů s osazováním některých tras.

Základním přenosovým protokolem páteřní sítě je IP/MPLS. Jako IGP protokol MPLS sítě používáme OSPFv2. Vlastní logická topologie sítě je rozdělena do dvou funkčních úrovní, kterým je přizpůsobena topologie jednotlivých GigaPoP:

Jádro sítě (Core Backbone Area)

Vlastní jádro sítě tvoří směrovače GSR12016 (na obrázku znázorněny červeně), na kterých jsou ukončeny všechny páteřní datové okruhy. S výjimkou multicastu zajišťují pouze MPLS funkce (používané verze IOS 12.0(21)S7 podporují pouze TDP) a z pohledu přenosu vyšších IP protokolů jsou transparentní. Převedení provozu na záložní okruhy je zajišťováno na úrovni protokolu OSPF (pro rychlejší konvergenci jsme snížili časové parametry, např. ospf-hello na 1 s). Používaný typ HW rozhraní a přechod k GE neumožní využít efektivnější a rychlejší mechanismy pro přesměrování provozu (Fast Rerouting, DPT), kde se doba přesměrování pohybuje okolo 50 ms.

Přístupová část sítě (GigaPoP Area)

Jako přístupové směrovače využíváme Cisco OSR7609 (se Supervizor2/PFC2 Engine) a Cisco 7206-VXR s NPE-G1 v menších uzlech (Ústí nad Labem, Zlín) ve funkci MPLS PE. Tyto směrovače zajišťují veškeré funkce a služby páteřní sítě (MPLS, MPLS VPN, QoS, IPv4 směrování, IPv4 multicast, export NetFlow statistik, přístupové filtry) pro připojené účastníky.

Akademické metropolitní (PASNET, BAPS,..) a univerzitní sítě jsou připojeny gigabitovým Ethernetem, ostatní účastnící a detašovaná pracoviště menšími kapacitami (Ethernet, Fast Ethernet). Propojení přístupových směrovačů a směrovačů jádra sítě je vždy dvěma rozhraními GE nebo POS STM-16/OC-48 s rozkládáním zátěže na úrovni OSPF.

Menší uzly sítě (PoP) jsou připojeny na tyto přístupové směrovače optickými okruhy 100 Mb/s (jednovláknové připojení, zelené okruhy na obrázku), radiovými okruhy 34 nebo 10 Mb/s (v případě 34 Mb/s je využita konverze na 100BASE-T na koncích okruhů) a pronajatými pevnými okruhy. V těchto uzlech jsou použity menší směrovače s omezenou funkčností (MPLS CE) řady C2621/C2651-XM/C2691), které podporují pouze VRF Lite.

Typická topologie GiGaPoP je uvedena na obrázku - jako příklad je použita architektura libereckého uzlu. S ohledem na omezenou podporu MPLS v HW směrovače OSR7609 (se stávajícím Supervizor2/PFC2 je MPLS podporováno jen na OSM modulech) je připojení na směrovač jádra realizováno dvěma rozhraními modulu OSM-4GE-WAN. Na přístupových modulech WS-X6516-GBIC a WS-X6548-RJ45 není MPLS podporováno. Pro připojení dalších směrovačů s podporou MPLS jsme museli vytvořit MPLS Intra-PoP externí propojení (port modulu OSM-4GE-WAN 3/3 a GE1/2 na supervizoru) a distribuovat MPLS signalizaci na příslušný LAN port přes 802.1Q VLAN.

Logická topologie uzlu je rozdělena na tři části: s podporou MPLS, připojení služebních serverů, připojení koncových účastníků. V MPLS části jsou připojeny C7500 jako 6PE směrovače (řešení je popsáno dále), případně testovací PE/6PE směrovače pro ověřování např. IPv6 multicastu . Služební segment zahrnuje OOB přístup, VoIP gateway, UPS a další služební zařízení a servery. Připojení koncových účastníků je realizováno přes virtuální sítě 802.1Q. V případě potřeby MPLS VLAN lze využít 802.1Q trunk a zajistit mapování MPLS VLAN do 802.1Q VLAN.

3.2   Směrování IPv4

Jako interní směrovací protokol v rámci páteřní sítě využíváme interní BGPv4 (iBGP) mezi PE směrovači (viz obrázek). Na externích směrovačích R84, R85 a R21 jsou (dočasně) nakonfigurovány route reflectory RR1, RR2 a RR3 pro zajištění redundance směrování (na obrázku jsou zobrazeni iBGP sousedé pouze pro RR1). Na ostatních PE směrovačích využíváme route reflector clienty. Použití route reflectorů snižuje potřebný počet sousedů v páteřní síti.

Na přístupových směrovačích GigaPoP používáme statické agregované bloky, není prováděna redistribuce z vnitřních směrovacích protokolů. S výjimkou sítě PASNET a ČVUT, pro jejichž připojení využíváme BGPv4 a privátní autonomní systémy (AS 65001 a 65002), jsou metropolitní sítě směrovány pomocí OSPFv2 (s jiným identifikátorem OSPF procesu, než je využíván na páteřní síti) a menší sítě statickými cestami.

3.3   Směrování IPv4 multicastu

Pro výměnu multicastových směrovacích informací využíváme interní MBGP. Konfigurace iMBGP je podobná konfiguraci iBGP na PE směrovačích s třemi route reflectory na směrovačích R84, R85 a R21 (dočasně). Route reflector klienti jsou však konfigurováni na všech P a PE směrovačích (viz obrázek), neboť i na směrovačích jádra je nutné zajistit správnou funkci RPF (Reverse Path Forwarding), který jako součást předávacího procesu zajišťuje ochranu proti smyčkám či duplicitním multicastovým paketům. Tato kontrola je v prostředí páteřní sítě zajišťována iMBGP (za předpokladu, že veškeré multicastové zdroje jsou oznamovány v aktualizacích tohoto protokolu), který má nastavenu interní administrativní vzdálenost 100 (IGP směrovací protokol MPLS sítě OSPF má implicitní vzdálenost 110, takže se neuplatní).

V celé páteřní síti používáme PIMv2-SM. Páteřní síť je rozdělena do samostatných PIM domén (viz obrázek). Výhodou PIMv2-SM je implementace kontrolních bodů (Rendezvous Point, RP) v uzlech. Každý zdroj multicastových dat se nejdříve registruje k nejbližšímu RP, který vytvoří tzv. SPT (Shortest-path Tree) stavový záznam (S,G) od RP směrem ke zdroji. Nejbližší směrovač na cestě k příjemci (last hop designated router) se registruje postupně k RP (hop by hop) a vytváří tzv. sdílený strom, shared tree (*,G), kde hvězdička označuje jakýkoliv zdroj. Zároveň dochází k modifikaci RPF mechanismu, který přidává stavový záznam (*,G), kde jako zdroj dat je využit stav (S,G). Počáteční přenos dat probíhá směrem k RP přes SPT a pak směrem k příjemci dat pro tuto multicastovou skupinu po cestě vedoucí sdíleným stromem. Přenos multicastových dat však nebývá optimální a závisí na na umístění RP. Po zahájení přenosu dat se provádí optimalizace přenosové cesty pomocí SPT-switchover mechanismu a počáteční sdílený strom je nahrazen optimalizovanou nejkratší cestou od zdroje k příjemci (shortest path tree).

V rámci každé multicastové domény je její RP využíván pro všechny připojené účastníky (s výjimkou PASNETu a ČVUT). RP je oznamován dynamicky s využitím protokolu Auto-RP (firemní protokol Cisco), případně protokolu BSR (Boot Strap Router), který je jako obecný standart podporován i na směrovačích jiných výrobců. Většina účastníků je připojena rozhraním PIMv2-SM, někteří však ještě PIMv2-DM s ohledem technologii, kterou používají (např. přepínače Extreme Networks). Cílovým stavem, který řeší problémy s tímto problematickým přechodem SM/DM v uzlech, je použít výhradně PIMv2-SM.

Pro přenos informací o aktivních zdrojích multicastových dat používáme protokol MSDP v konfiguraci full-mesh group mezi všemi uzly, což je z hlediska správy sítě poměrně komplikované. Použití mesh group snižuje množství přenášených MSDP zpráv mezi jednotlivými sousedy a umožňuje výměnu SA (Source Active) zpráv mezi všemi iMSDP směrovači bez ohledu na mechanismus RPF check.

Uplatnění tohoto mechanismu v případě MSDP bylo hlavní příčinou problémů s multicastem v páteřní síti (směrovače jádra nemají z iBGP směrovací informace o dostupnosti aktivních sítí, takže RPF check zablokoval posílání SA zpráv ostatním směrovačům). Současná logická topologie multicastu není kongruentní - unicast je přenášen přes MPLS, ale multicast bez MPLS značek. Na úrovni MSDP je rovněž ve všech uzlech prováděna filtrace oznamovaných aktivních zdrojů a skupin dle doporučení Cisco Systems a sítě GÉANT (omezení provoz Novell NDS, ImageCast a dalších služeb využívajících multicast, které nejsou určeny pro oznamování do páteřní sítě a MBone).

V současné době připravujeme ve spolupráci s podporou Cisco NSA nový návrh IPv4 multicastu v páteřní síti. Předpokládáme implementaci Anycast RP, jejíž výhodou je rozložení multicast provozu (load balancing) a vytvoření redundance RP pro spolehlivou distribuci multicastu. Konfigurace RP je v tomto případě výhradně statická, což umožňuje jednodušší řešení problémů a zvyšuje i odolnost proti útokům (flooding) na síti.

Implementace technologie Anycast RP si však vyžádá zásadní změnu konfigurace multicastu v uzlech sítě i v sítích připojených účastníků (nutnost konfigurace vlastních RP a použití protokolu MSDP na přípojných rozhraních). Rovněž připravujeme HP OpenView NNM Multicast Monitor na druhé sledovací stanici pro monitorování multicastu na páteřní síti. Statistické vyhodnocení multicastového provozu závisí na podpoře SNMP výrobce směrovačů i na podpoře NetFlow v9 (IOS pro Sup720).

Distribuce multicastu na úrovni páteřní sítě je bezproblémová, nicméně stále přetrvávají problémy na straně připojených účastníků (různé technologie a výrobci síťových prvků,atd.), takže nelze hovořit o zaručené end-to-end službě vhodné pro spolehlivé použití v praxi (např. videokonference).

3.4   Implementace IPv6

Jedním z úkolů provozu a rozvoje páteřní sítě v roce 2003 bylo převést experimentální IPv6 páteř, která byla realizována na linuxových PC směrovačích propojených tunely do produkčního prostředí páteřní sítě. Výběr nových směrovačů OSR7609 byl podmíněn hardwarovou podporou IPv6. Nicméně dodávky nové supervizor engine Sup720, které měly být splněny do poloviny roku, se kvůli problémům výrobce s vývojem opozdily a bylo nutné hledat náhradní řešení.

Sice se objevily beta verze IOS se softwarovou podporou IPv6 pro stávající Supervizor2/Engine2 se (což by s ohledem na objem IPv6 provozu plně postačovalo), nicméně nebyly použitelné v produkčním provozu a výrobce další vývoj v této oblasti prakticky zastavil. Jako vhodné řešení se nabízelo využít stávající směrovače řady C7500, které byly až na výjimky nahrazeny novými OSR7609 v rámci rekonfigurace páteřní sítě. Směrovače C7500 používáme jako 6PE pro IPv6 over MPLS a ke sloučení IPv4 a IPv6 provozu dochází na OSR7609 s využitím VLAN - viz obrázek.

Výhodami tohoto řešení jsou:

• snadná implementace na vyhrazených směrovačích
• nebyla nutná žádná rekonfigurace či upgrade páteřní sítě
• možnost kombinace s tunely
• dostatečná výkonnost směrovačů (CEF6)

V rámci implementace 6PE jsme řešili celou řadu různých chyb a problémů s IOS. V současné době na těchto směrovačích provozujeme engineering verzi odvozenou z řady IOS 12.3.

Dosud není podporován IPv6 multicast a architektura řešení vyžaduje použít 6PE směrovače proti externím sousedům. Stávající řešení peeringu se sítí GÉANT (směrovač OSR7609 R85 s rozhraním POS STM-16/OC-48) neumožňovalo použít stejné řešení jako v ostatních GigaPoP. Jako jediná možná varianta nativního IPv6 peeringu bylo dočasně použit směrovač GSR12008 (R21) s IOS 12.0(25)S1, který podporuje IPv4/IPv6 dual-stack. Současná topologie IPv4/IPv6 je uvedena na obrázku.

Jako interní směrovací protokol pro IPv6 používáme iBGP (stejně jako pro IPv4) se dvěma route reflectory na externích směrovačích R1 (POS STM-1 okruh na 6NET) a R62. Pro IPv6 peering v NIXu využíváme směrovač R1 a sloučení IPv4 a IPv6 provozu je prováděno na L2 přepínači Cat43, kde končí druhý GE okruh. Mimo směrovače R21 jsou v režimu dual-stack provozovány C7206-VXR s NPE-G1 v GigaPoP Ústí nad Labem a Zlín (R90 a R91) s IOS řady 12.(3)1. Připojení koncových účastníků je realizováno buď tunely (neboť ve většině případů nejsou na IPv6 technologicky připraveni), nebo nativně (např. přes vyhrazené VLAN) s využitím statického směrování.

Připojení menších PoP, které nejsou součástí MPLS jádra sítě, bude též realizováno nativně s využitím OSPFv3. Tuto konfiguraci v současné době využíváme mezi GigaPoP Ostrava a PoP Karviná a Opava. Je však nutné používat IOS verze 12.2(15)T, který vyžaduje minimálně 128 MB paměti. Ve starších směrovačích řady 2600, které jsou provozovány v řadě dalších menších PoP (např. C2621), nelze tento IOS provozovat. Pro další rozšíření nativního IPv6 v rámci celé páteře bude tedy nutné inovovat příslušné směrovače.

Nutnými podmínkami přechodu celé páteřní sítě na dual-stack IPv4/IPv6 je upgrade na nové supervizor engine Sup720 a dostupnost stabilní verze IOS vhodné pro nasazení v našem MPLS prostředí. Sup720 oproti používaným Supervizor2/PFC2 engine má vyšší příkon a větší nároky na chlazení systému. Ve stávajících šasi OSR7609 nevyhovují kapacity napájecí sběrnice, kapacity napájecích zdrojů a chladící výkony systému ventilátorů, takže není možné zaručit bezproblémovou funkci směrovače. V rámci dodávky Sup720 proto dodavatel provádí výměnu všech šasi za nová s potřebnými parametry.

Pro nasazení Sup720 do produkčního provozu není dosud k dispozici stabilní verze IOS (plánovaná verze 12.2S Tetons-2) s požadovanými vlastnostmi, která by měla být k dispozici na začátku roku 2004. Výrobce nám poskytl beta verzi vyvíjeného IOS, který v současné době testujeme na servisních zařízeních. V rámci tohoto EFT (Early Field Test) předáváme objevené problémy přímo vývojářům, kteří je dále využívají pro opravy chyb v IOS. Cílem naší účasti v EFT je jednak seznámit se s vlastnostmi nového IOS, jednak ovlivnit jeho úpravy tak, abychom mohli směrovače se Sup720 nasadit v co nejkratším termínu do reálného provozu. Jejich nasazení očekáváme začátkem roku 2004.

V rámci upgrade bude nutné přesunout všechny moduly v šasi, neboť stávající Supervizor2/PFC2 obsazuje pozice 1 a 2, kdežto pro Sup720 je nutné použít pozice 5 a 6 (původně vyhrazené pro přepínací matici), a provést patřičné úpravy konfigurací.

OSR7609 se Sup720 pak nahradí stávající 6PE směrovače C7500, ale pouze pro unicastové směrování IPv6. Podpora IPv6 multicastu není v této době zcela jasná a jako náhradní řešení využijeme C7500 s tunely (ověřování tohoto řešení v současné době probíhá).

3.5   Externí připojení

Síť CESNET2 využívá následující externí připojení a peering (viz obrázek):

3.5.1   Zahraniční konektivita (běžný Internet)

Globální zahraniční konektivitu nám poskytuje Telia International Carrier. Kapacita připojení je 800 Mb/s (softwarově omezená) na okruhu POS STM-16/OC-48 (2,5 Gb/s) na směrovač R84. Záložní spojení je zajištěno analogickým okruhem na pražský uzel Telia (směrovač R85).

Telia nám poskytuje unicastovou konektivitu pro IPv4 (IPv4 multicast plánujeme) a IPv6 (prostřednictvím tunelu).

3.5.2   Připojení do sítě Géant

Připojení do sítě Géant je realizováno propojením POS STM-16/OC-48 na místní uzel Géantu s omezením na 1,2 Gb/s. Pro zajištění nativního IPv6 připojení je dočasně ukončeno na dual-stack IPv4/IPv6 směrovači R21 (GSR12008). Přes toto připojení je zároveň zajišťován přístup k síti MBone (IPv4 multicast).

Pražský uzel Géantu je připojen kapacitou 10 Gb/s do Německa (Frankfurt nad Mohanem) a dvěma POS STM-16/OC-48 okruhy do Polska (Poznaň) a na Slovensko (Bratislava).

Géant poskytuje síti CESNET2 pouze spojení do ostatních sítí národního výzkumu (NREN) a nenabízí téměř žádnou konektivitu na ostatní panevropské poskytovatele Internetu, ani do peeringových center. Podrobnější informace o topologii sítě GÉANT lze nalézt na www.geant.net.

3.5.3   Národní peering v NIX.CZ

Přístup do NIX.CZ je zajištěn dvěma GE okruhy, které jsou zakončeny na externích směrovačích R84 a R85 (z důvodu zálohování). Okruhy jsou realizovány na pronajatých optických vláknech a osazeny příslušnými GBIC (GBIC-LX/LH a CWDM-GBIC na delší záložní trase). Nativní peering IPv6 je realizován 6PE směrovačem R1, sloučení IPv4 a IPv6 provozu zajišťuje Cat43 na druhé vrstvě.

3.5.4   Peering se sítí SANET

Propojení se slovenskou akademickou sítí SANET je realizováno po optických vláknech Brno-Bratislava. Trasa je osazena CWDM-GBIC-1550 a je zde použit přepínač Catalyst 3524 jako opakovač.

Využíváme zde 802.1Q VLAN pro správu zařízení a PtP pro propojení hraničních směrovačů R98 v Brně a SANETu. Kromě vzájemného peeringu našich sítí poskytujeme na tomto propojení peering SANETu v NIX.CZ a naopak SANET síti CESNET2 peering v SIXu, což oběma sítím šetří zahraniční konektivitu. Vzájemné oznamování sítí do peeringových center provádíme na základě BGP communities (tagů).

3.6   Zajištění správy páteřní sítě

Centrální dohled páteřní sítě zajišťuje NOC Cesnet (Network Operating Centre) nepřetržitě (24 hodin, 7 dní v týdnu, 365 dní v roce). Řešení problémů s provozem sítě, kdy je potřeba podrobnější diagnostika a zásahy do konfigurací aktivních prvků, provádí odpovědný administrátor ve službě na vyžádání operátora. Na veškerá síťová zařízení máme rozšířený HW a SW servis se zaručenou dobou odstranění poruch (do 4 hodin u klíčových zařízení). K eskalaci řešení problémů a poruch je využíván NSA support Cisco (Advanced Services). V rámci této podpory jsou pro síť CESNET2 vyhrazeni dva TAC inženýři, kteří mají detailní přehled o topologii sítě, používaných službách a přímý přístup k provozním zařízením.

Pro správu páteřní sítě využíváme tyto prostředky:

Správa celé páteřní sítě

HP OpenView NNM 6.31 s ET (Extended Topology) licencí (UltraSparc 420R , Solaris 2.8), sledování aktuálního stavu sítě a vyhodnocování událostí (events). Záložní stanice pro správu sítě bude využita ke sledování multicastu. Instalace HP OpenView NNM Multicast monitoru se v současné době připravuje.

Správa aktivních prvků sítě (směrovače, přepínače,...)

CiscoWorks 2000 RWAN 1.3 s podporou protokolu ssh pro bezpečný přístup k zařízením. Z funkcí balíčku CiscoWorks je využíván zejména RME (Resource Management Essential) pro vytváření HW a SW přehledů zařízení a automatické zálohování konfigurací a Syslog Analyzer pro vyhodnocování specifických záznamů o provozu zařízení.

Monitorování služeb sítě

Program Nagios v1.0 (www.nagios.org), který je pokračovatelem dříve používaného NetSaintu, používáme pro sledování dostupnosti služeb na síťových serverech (mail, DNS, WWW). Server systému Nagios je rovněž používán pro sledování nativní IPv6 sítě. Výhodou systému Nagios je, že jde o otevřený systém s možností vlastních úprav a rozšíření.

Statistické systémy

Námi vyvinutý systém GTDMS je doplněn řadou alarmů pro překročení mezních stavů na směrovačích (přetížení CPU, velikost volné paměti, napájecí zdroje, vnitřní teplota) i datových okruzích (přetížení, zvýšená chybovost). Pro zpracování NetFlow statistik používáme vlastní systém NetFlow Monitor (viz dále). Je určen jednak pro statistické vyhodnocení provozu jednotlivých účastníků, jednak pro řešení bezpečnostních incidentů (vyhodnocení aktuálních toků dle zadaných podmínek). NetFlow data exportují všechny hraniční směrovače sítě (PE směrovače). V současné době je vyhodnocován pouze IPv4 provoz, neboť implementace exportu NetFlow v9 (zahrnujícího statistiky IPv6 a multicastového provozu) není zatím v produkčních verzích IOS dostupná.

Request Tracker (RT)

Jedná se o trouble ticket sytém určený pro zpracování požadavků (vytváření, sledování řešení a archivaci) v rámci provozu sítě. Bližší popis tohoto systému lze nalézt na www.fsck.com. Pro provoz sítě CESNET2 slouží řada front (noc, trouble, admin,...), které využívá daný okruh uživatelů (správci sítě, NOC, uživatelé).

Out-of-Band management (OOB)

Dálkový přístup k aktivním prvkům sítě v případě jejich nedostupnosti po páteřní síti je implementován ve všech uzlech sítě.

3.7   Statistické vyhodnocení provozu sítě

3.7.1   Průměrné dlouhodobé využití jádra páteřní sítě

Přestože jádro páteřní sítě disponuje na první pohled doposud poměrně značnou rezervou v oblasti volné kapacity, nemusí již za všech okolností platit, že se jedná o tzv. "předimenzovanou" síť. Faktem je, že průměrná zátěž většiny gigabitových páteřních tras nedosahuje v dlouhodobém měřítku více jak 15 % jejich celkové kapacity. Nicméně provozní špičky přesahující tuto hladinu přestaly být v průběhu roku 2003 na některých linkách nahodilým a krátkodobým jevem. V průběžné zprávě za rok 2002 jsme demonstrovali vliv časového kroku měření na výsledný průběh zátěže linky. Skutečná krátkodobá zátěž (jednotky sekund) vysoce přesahuje hodnoty získané provozním dlouhodobým měřením s časovým krokem snímání hodnot v oblasti jednotek minut. Během roku 2003 již nastaly případy, kdy průměrná hodnota přeneseného objemu v rámci celého intervalu provozního měření (typicky 5 minut) vysoce převyšovala dlouhodobý průměr a příslušné linky dosahují dlouhodobé špičkové zátěže až 30 %.

Výrazný úbytek výskytu vysokých hodnot špiček ve výše uvedené ukázce v období před zářím 2003 je způsoben především nakonfigurovanou strategií agregace zastarávajících dat v měřícím systému.

3.7.2   Vývoj provozu sítě CESNET2 v roce 2003

Ve srovnání s rokem 2002 došlo v oblasti vývoje objemů přenášených dat k minimálním změnám. To znamená, že vývojové tendence byly průběžně mírně rostoucí s patrnou typickou stagnací v letním období. V dlouhodobém kontextu je především na linkách, které mají agregující charakter, zajímavý dynamický nárůst přenášených objemů v podzimních měsících.

3.7.3   Využití sítě CESNET2 v roce 2003

V oblasti absolutních objemů přenesených dat došlo obzvláště na některých linkách jádra páteřní sítě k výraznému nárůstu. Pro přehlednost u většiny linek uvádíme oba směry přenosu odděleně, a to včetně sumarizace přenesených objemů dat. Neúplnost některých průběhů je dána buď změnami v architektuře sítě (změny topologie, změny přenosových tras) nebo změnami v konfiguraci měřícího systému. Absence výskytu špiček v uvedených jednosměrných ukázkách v období před zářím 2003 je opět způsobena nakonfigurovanou strategií agregace zastarávajících dat v měřícím systému.

3.7.4   Externí přenosové trasy

Všechny externí přenosové trasy kromě linky do globálního Internetu v odchozím směru disponují dostatkem okamžité volné kapacity. Kapacita linky do globálního Internetu je omezena softwarovými nástroji, a proto mohou provozní špičky tuto hranici místy překračovat. Výpadek v průběhu zátěže této linky není způsoben výpadky provozu, ale konfigurací měřícího systému. V ukázkách opět uvádíme oba směry přenosu odděleně včetně sumarizace přenesených objemů dat.

3.8   Plány rozvoje páteřní sítě v dalším období

V dalším obdobích plánujeme dokončení přechodu na Sup720 a implementaci IPv4/IPv6 dual-stack na všech PE směrovačích (1. čtvrtletí 2004). V rámci přechodu rekonfigurujeme multicast a jeho správu. V oblasti IPv6 dokončíme nativní distribuci IPv6 unicastu do všech PoP a bude pokračovat implementace náhradního řešení pro IPv6 multicast (v využitím 6PE C7500 a tunelů).

V případě požadavků projektů či účastníků lze poskytovat další služby sítě jako je MPLS VPN (např. Ethernet over MPLS VPN dle [MTV01] poskytujeme produkčně pro potřeby projektů), MPLS VPN či QoS (vzhledem k dostatku přenosového pásma nebyla praktická motivace je implementovat).

S ohledem na další vývoj optických přenosových tras (např. DWDM) plánujeme postupný přechod na 10GE na trase Praha-Brno (pro tento přechod je též potřeba provést odpovídající povýšení propojení externích směrovačů a upgrade směrovačů jádra sítě). Další vývoj sítě závisí především na specifických požadavcích projektů (přenosové pásmo, QoS) a připojených účastníků.

předchozí

obsah

následující