Cisco ACI Kellett már nekünk mint egy falat kenyér, hogy végre történjen ebben VLAN-okba költözött posványos DC rendszerekkel valami... valami új. Mit tegyünk, ha hálózati infrastruktúrát az határozza meg, hogy adott VLAN-ok, hol vagy hol nem szerepelhetnek az infrastruktúrában, ha egy létesítést 8 különböző IT vezetőnek kell jóváhagyni, ha a felelősség tolása másra fontosabb, mint a projekt végrehajtása. Cisco ACI-ról írni nehéz dolog egy olyan alternatív IT valóságban, ami ma Magyarországon van... Mert amíg azzal küzdünk bizonyos helyeken, hogy az ultrafontos IT app egy 486-os gépen fut, ami csak 10M half-ot tud, addig nem tudjuk a 20 éve EoS demarkációs switch-et lecserélni, a lassan szintén EoS státuszba kerülő "legújabb" Nexus switch-re. Addig felesleges bárminek is a infrastruktúrában alkalmazás centrikusnak lenni, amíg az alkalmazásunkat támogató csapat az eniac-os lyukkártyás időszakon mereng, és még mindig nem fogadja el 21 századot. Mint azt egy korábbi be

CCIE SP akarok lenni Eljön az ember életében egyszer az a pillanat, hogy úgy érzi megrekedt egy bizonyos szinten, és innen nem tud előre lépni. Egészen mostanáig úgy éreztem, hogy nincs lehetetlen és bármit meg tudok csinálni. Viszont az élet nem lineáris görbéjén sajnos eljutottam arra pontra, hogy talán nem így van és sok magánéleti és céges feladat annyira felemészt, hogy örülök annak ha szinten tartom a meglévő kompetenciámat. Emiatt rosszul éreztem magam, céltalanná váltam, illetve a korábban kitűzött céljaim annyira elhomályosodtak, hogy esélytelennek láttam egy professional szintnél magasabb minősítés megszerzését... Viszont tegnap/ma hajnalban számot vetettem, hogy honnan indultam, hol tartok most és mi van még hátra. Nagyjából középiskolás korom óta van kitűzött célom, ami a évek teltével szakaszosan változik: 0. szakasz: kikerülni otthonról 1. szakasz: Puskás Tivadar Távközlési Technikum  - Technikusi minősítés 2. szakasz: OE Kandó Kálmán villamosmérnöki kar - BSc 3.

South-bound APIs 2   YANG alapú leírónyelvek és API-k YANG adatstruktúra egy leíró modell arra, hogy milyen követelményeket támasztunk a API lekérdezés vagy operáció formáját tekintve, továbbá definiáljuk a konfigurációs paraméterek struktúráját. Bizonyos szempontból nézve az SNMP OID-ok is megfelelnek ennek az adatstruktúrának, így joggal merül fel a kérdés, hogy minek vesződünk mással? A koncepció egy NET/RESTCONF kapcsán az, hogy az egyszeri - speciális hálózati szaktudással nem rendelkező - programozó is tudjon kódot írni, ugyanis a programozók otthonosabban mozognak a XML, JSON vagy YALM formátumú konfigurációkban mint az SNMP OID-ban, vagy CLI-ban. JSON formátumú konfiguráció leírást már előző postomban mutattam. Így most nem térnék ki külön a formátumra. A JSON formátumon kívül, amik még különböző automatizációs és SDN rendszerek esetén népszerűek, az XML és YALM formátum. Akit érdekelnek a különböző formátumok részletes leírása annak az alábbi forrásokat javas

ITBN EXPO 2019 Számomra ez Magyarország egyik legrangosabb hazai rendezvénye, amin nem csak a partnerek és gyártók mutatják meg a biztonságtechnika és IT területén meglévő kompetenciájukat, hanem a teljes magyar szakmai gárda képviselteti magát valamilyen formában. Nekem ez volt ez első alkalom, hogy részt vehettem, mint  meghívott rendszermérnök, így nincs a tavalyi évekkel kapcsolatos összehasonlítási alapom a rendezvény színvonalát illetően. Impozáns volt látni a standokat, és az előadások helyszíni kialakítása is egy nemzetközi konferencia színvonalát hozta. Hasonlóan az idei Techtorial -hoz leginkább rövid 20 -30 perces slot-okat tartottak, így csak néhány előadás lehetett kellően deep dive számomra. Ilyenek többek között a saját előadásaink voltak, amelyek a 3-as Skybox-ban kerültek bemutatásra. Neumann Péter - Elosztott biztonság a virtualizációban (Zero trust a cégemben 2.0) Aki ezt előadást még meg fogja ismételni más rendezvényeken is newman.cloud-on   el is