South-bound APIs Déli-irányú API-k esetén nem olyan "egyszerű" a helyzet mint északi-irányban. Ugyanis még nincs - és talán sosem lesz - olyan egységes, kvázi sztenderdizált protokoll mint a REST API. Hogy miért? Hát kérdezzük meg a gyártókat! Miért nem a NETCONF, vagy a SNMPv3, vagy az OpenFlow mellett tették le a voksukat egységesen. Mint a korábbi bejegyzésemben írtam már, a gyártók az SDN megoldásaikat sokkal inkább csomagolt termékként kínálják, mint egymással együtt működő standardoknak megfelelő részegységeket. Ezért van az, hogy a déli-irányú SDN integrációt nem lehet, egy protokollal megvalósítani egy heterogén rendszerben. Déli-irányban, így gyakorlatilag bármi lehet API, amit az SDN kontroller és a hálózati eszköz is támogat... Azért próbáljunk meg néhány protokollt kiemelni, mert azokban megvan minden olyan funkcionalitás, ami alkalmassá teszi az orkesztráció megvalósítására.   YANG adatmodell RFC6020 - Yet Another Next Generation... A fenti k

ITBN19 Közeledik egy igen fontos és rangos esemény az ITBN, ahol a hálózatbiztonság mellett sok egyéb érdekes témával is találkozhatunk. Idén abban a szerencsés helyzetben vagyok a munkáltatómnak köszönhetően, hogy részt tudok venni az eseményen, illetve akit érdekel annak a regisztrációját is tudom fogadni, a céges email címmel. Idén több kiváló kollégám is fog előadni,így javaslom az alábbi előadásokra üljetek be mindenképp: Elosztott biztonság a virtualizációban   Szeptember 25. szerda 1:30PM  99999 Skybox Szeptember 26. csütörtök 1:30PM  99999 Skybox   VMWS1UEM&TMMSAPX1 – Felhasználói élmény és biztonság egyszerre az eszközeinken. Lehetséges ez? Szeptember 25. szerda  2:40PM 99999 Skybox Szeptember 26. csütörtök 2:40PM 99999 Skybox 5 keys to successfully use Machine Learning in Cyber security Szeptember 26. csütörtök  2:45 PM Anniversary Room Az előadásokról és programok menetéről itt olvashattok bővebben: https://hub.it

Application Programming Interfaces - APIs API-król az SDx bejegyzések során már röviden beszéltem, de most tegyük nagyító alá a témát, és nézzük meg az egyes API-k működését, hogyan kapcsolódnak az egyes orkesztrációs szintekhez (kontrollerekhez). Tehát mindenkinek megvan, hogy az SDN architektúra referencia középpontja maga az SDN kontroller. Ez alapján azok az API-k amik a kontrollert alkalmazás oldalról érik el (tipikusan REST-API), észak-irányú API-nak - North-bound - amikkel pedig a kontrollerrel érjük el az infrastruktúrát azokat pedig déli-irányú API-nak - South-bound - szoktuk nevezni. A fentiek alapján, és felhasználásuk szempontjából megpróbálom leírni ezeket a protokollokat, annyi extra csavarral, hogy bevezetem az integration-API fogalmát, ami bizonyos szempontból észak-irányú API-nak is tekinthető, de szerintem ez inkább külön kategória, mert ez kontroller, vagy kontroller jellegű alkalmazások összekötését teszi lehetővé. North-bound API REST

Kedves Olvasók! Megújult formában változatlan tartolammal, vagy annak hiányával... indítom útjára, Linkedin-ről levált blogomat... A témák változatlanok, a korábbi anyagok is migrálásra kerülnek! Remélem sikerül havi rendszerességgel egy-egy post... majd meglátjuk!  Addig is mindenkinek kellemes nyarat! Üdv Telecommer, aka Makesz ;)

 SD-BRANCH WS in Brussel Diegem Olyan tengersok ideje van az embernek, hogy nem tudjon mit is kezdjen vele… Ha látok ilyet, akkor majd szólok, most viszont sebtében (még a kobakomban van), innen a reptérről megírom a tapasztalataimat, az HPE által szervezett partnerek szóló 2 és fél napos Aruba SD-Branch workshop-ról. Ahhoz, hogy mindenki értse miről is beszélek, indítsuk onnan, hogy az Aruba (vagy HPE) Brand-estített SDN megoldás mi célt szolgálhat az életünkben. Alapvetően jár a piros pont az Arubának azért, hogy ezt a meglévő termékportfóliójára építette fel és nem akviráltak már egy befutott SD-WAN megoldással rendelkező gyártót (pl Riverbed). Igen az Aruba SD-Branch célja, hogy Branch-ek és az adatközpont (DC) és vagy a HQ között SD-WAN hálózatot építsünk fel. A HPE TSS kapcsán, amit írtam a SD-Branch-ről az így a 2,5 nap fényében már nem állja meg a helyét. Ugyanis eltérő módban kell használni az Aruba Mobility Controllereket, és nem Wireless c

Techtorial19  Április 2-3 Avagy a magyar hálózati szakemberek nemzeti ünnepe... Idén is – mint minden évben eddig – megrendezésre került a Cisco Magyarország, és partnerei jóvoltából a Techtorial Siófokon a Hotel Azúrban, ami szerintem az egyik legrangosabb hazai szakmai rendezvény. Mivel a Cisco a hálózati technológiák terén élen jár, ez az a fórum, ahol jó eséllyel találkozunk azokkal a technológiákkal, amik meghatározzák a következő 5-10 évet. A jelenlegi volt életemben a 4-ik alkalom, hogy részt vehettem, és másodjára ért az a megtiszteltetés, hogy elő is adhattam valamilyen témában, amiről még a bejegyzés során említést teszek. Idén is, mint minden évben szekciókra volt bontva a rendezvény, ami hagyományosan így néz ki: Nagyvállalati megoldások – Enterprise Biztonsági megoldások – Security Adatközponti megoldások – DC Szolgáltatói megoldások – SP Együttműködési megoldások – Collaboration A rendezvény reggel technikailag 8:00-kor kerül me

HPE TSS Network view day 3 Exam day 1 Tegnap este a HPE Magyarország megvendégelt minket egy impozáns helyen így a harmadik nap nehezített pálya volt, mind koncentrációban, mind a feladatok összetettségében is, ugyanis eldöntöttem, hogy kihasználom az alkalmat és levizsgázom ACDP-ből. Mivel erre konkrét időt külön nem csináltam az előadások között, így 2 előadást kellett áldoznom erre a feladatra. Lentebb leírom, hogy melyik kettő volt az és miért. Deep dive into network architecture with Aruba SD-Branch (professional) A téma izgalmasnak ígérkezett, de a figyelmem hamar lankadni kezdett, mert olyan érzésem volt mintha a Software Defined rész nem kapott elég hangsúlyt. Kicsit mintha az SD-Branch csak SD-Brand-esített Aruba kontroller architektúra lett volna Aruba Central-al, és ClearPass-al kiegészítve, ami azért elég sok ügyfél igényét lefedi, de nem biztos hogy igazi SDN megoldás... Ez annyira felbosszantott, hogy kijöttem az előadás közepén és bementem a Test Ce

Eljött a partnerek és ügyfelek számára a második nap itt már teljesen szabadon választott előadásokra lehetett bemenni, így próbáltam olyan tartalommal feltölteni a napot, ami teljesen a hasznomra válik. EVPN Hands-On-Lab (expert) A tegnapi EVPN előadás folytatása gyanánt megnéztük, hogy a előadáson bemutatott konfiguráció részletek működnek-e a "valóságban", persze H3CL szoftverben emulált környezet biztosította számunkra a Spine-Leaf architektúrát, amin a labor első felében underlay network-nek OSPF-et kellett kialakítani, és felette unicast ingrees replication módban (vagy ahogy Aruba-nál nevezik Static) kellett VXLAN tunnel-ket kihúzni a Leaf-ek között... A labor második fele pedig a BGP EVPN , anycast GW, inter-VLXAN routing kialakításáról szólt. Amennyiben a labor célja az volt, hogy lássunk egy példa konfigot és ehhez kapcsolódó cli kimenetet, akkor elérte a célját, viszont számomra kiábrándító volt az, hogy a LAB-Guide-ból elmaradt ezeknek a magyará

HPE TSS Network view day 1 Rendhagyó módon, most nem a szokásos témát (Network virtualization) folytatom tovább, ugyanis olyan szerencsés helyzetbe kerültem, hogy eljutottam Párizsba a HPE Technology Solutions Summit rendezvényre, ahol a HPE újabbnál-újabb megoldásait ismerhetem meg, és vizsgázhatok is technológia ismeretből. Ezt a írást egyébként Neumann Péter kollégám inspirálta aki Systems/Server/Virtiualization expert-ként network témájú előadásokon is részt vett és vizsgázni is fog Aruba témakörben (Newman üdv a klubban!). https://newman.cloud/2019/03/11/parizs-hpe-tss-2019/ Keynote(s) Hálózatos szemmel az első nap első 3 órája nem indult túl izgalmasan, hiszen a HPE és a TSS-t támogató gyártók Keynote-jai nem pusztán az új hálózati technológiákról szóltak közvetlenül, viszont közvetve mégis érdekeltek vagyunk abban, hogy milyen igényeket támasztanak velünk szemben. Röviden összefoglalva: DataCenter Gyorsabb CPU, gyorsabb Memória, gyorsabb Storage, nagyob

Network Function Virtualization  Ezt a bejegyzést rövidítésjegyzékkel kezdem, hogy bátran spórolhassak a karakterekkel, ugyanis nem másra kell felkészülnünk mint, hogy az ETSI által szabványosított NFV architektúrát körvonalazzuk az alábbi sorokat követően. Joggal merül fel a kérdés, mi különbség hálózat-virtualizáció és a hálózati funkciók virtualizálása között… A másik kérdés az, hogy milyen igények mentén jutottunk oda, hogy kidobjuk a vasat, és szoftverből valósítsunk meg hálózati eszközökhöz szorosan kapcsolódó feladatokat? Hogy fenti kérdéseket megválaszoljuk, és a még több kérdés tudjunk feltenni ebben a témában, ezért tekintsünk át alapoktól az NFV architektúrát. Rövidítésjegyzék NFV – Network Function virtualization ETSI – Europian Telecomunication Standard Institute VM – virtual machine VNF – Virtual Network Function PoP – Point of Presence Virtualizáció  A virtualizációt mint fogalom már bevezettük (!!!absztrakció!!!), így most mint technológ