Ugrás a fő tartalomra

HPE TSS Network view day 2


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ázata. Viszont a Labor teljesíthető volt időn belül, és ujjgyakorlatnak tényleg elég jó volt és összetett.

VMware and (sales)
Sok mindent nem tudok írni róla, mint hogy eddig is jól meg voltak együtt eztán is meglesznek. Sajnos az egész előadás műszaki tartalma a 0-hoz konvergált, így jövőálmodáson kívül nem sok minden derült ki.
Focus on Value (Geo session, sales)

No comment.... helyette itt van néhány süti:

(Cisco) ACI integration with HPE Synergy (professional)
Joggal merül fel a kérdés bennetek, hogy hálózatosként én mit keresek egy Synergy témájú előadáson. Két dolog vonzott be ide:
  1. Tágítsam a látó köröm és más szemszögből is értsem az igényeket, és a hozzájuk kapcsolódó feladatokat.
  2. Azért egy HPE rendezvényen Cisco ACI-ról hallani, ha csak 1 slide-ot is, igazi kuriózum

Kellemes csalódás ért az előadáson, ugyanis lélekben én arra készültem, hogy semmit nem fogok majd érteni, mert 90%-ban a Synergy-ről lesz szó. Nem így lett, mert miután túl lendültünk az új Virtual Connect képességein és bekötésén, a slide-kon megjelent az ACI GUI, amin a hálózati paraméterek lettek beállítva, sőt még CLI -t is mutattak egy-egy slide-on. DE! a lényeg, illetve a hangsúly azon volt, hogy REST API (gondolom) segítségével, a HP ONEView-ból, miként lehet orkesztrálni az APIC-ot... mi ez, ha nem a megvalósult DevOPS modell, illetve hálózat-virtualizáció és automatizáció kérem? Nagyon oda voltam az előadástól, mert emberünk értette és elmagyarázta (peresze Server-es szemmel), hogy hogyan működik az ACI, mik a VLAN-ok PVLAN-ok, EPG-k, contract-ot, ACL, és ezeknek hol van értelme az ACI-ban, OneView-ban stb... Good job guys!

Hackathons workshop (expert)

Kicsit ódzkodtam bemenni, mert nem sokat szoktam programozni. Persze írtam néhány scriptet már, ráadásul olyat amit ügyfél is használt de az más, mert van mögötte egy jól kitesztelt magabiztos tudás. Végül az előadó meggyőzött azzal, hogyha láttam már valamilyen programozási nyelvet, és értem nagyjából a REST API működését akkor menjek... Így neki láttam OneView-hoz saját App-ot írni... Sajnos csak eddig jutottam:



De kezdetnek ez se rossz, főleg hogy kaptam érte ingyen pólót:


Összefoglalva
Izgalmas és összetett volt mára betervezett előadások struktúrája, túlnyomó részt ez annak is köszönhető, hogy ilyen szerencsésen alakítottam ki ezt a napot, ma is azt mondom megérte eljönni :).

Holnap vizsga... addig is:

Érdekesebb bejegyzések

Hálózat-virtualizáció a gyakorlatban - ACI fabric E01

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

SD-WAN vagy SD-NINCS II. epizód Cisco (Viptela) 1

Cisco SD-WAN első rész Bevezető Élek az alkotói szabadság jogával, és ellentétben az eddigiekkel kicsit rövídítek a post címén. Eredetileg ez a sorozat Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS II.rész Cisco (Viptela) 1 címet kapta volna, csak hát: Kib@#&0tul hosszú lenne. Az SD-WAN témakör önmagában megér egy post sorozatot. A Cisco SD-WAN-ról sok mindent lehet írni, így ez is megér egy önálló post sorozatot. Cisco SD-WAN-nak nem kis történelmi háttere van már, hiszen a megoldást szakmai berkekben leánykori néven viptelának is hívják. A Cisco 2017 májusában fejezte be a Viptela akvizícióját, és termékeit saját megoldásként, immáron 3 éve Cisco SD-WAN megoldás részeként kínálja az ügyfelei felé. Azért hivatkozunk a szakzsargonban Viptela néven a megoldásra, mert a Cisco-nak további SD-WAN megoldásai léteznek, illetve léteztek: SD-BRANCH (ENCS platform) Meraki SD-WAN IWAN (performance routing alapú, APIC-EM vezérelt kezdeményezés, ami sajnos kihalt )

Hálózat-virtualizáció a gyakorlatban SD-WAN vagy SD-NINCS I. epizód Fortigate

SD-WAN vagy SD-NINCS I. rész Ez a bejegyzés sorozat ötlete, akkor merült fel bennem, amikor különböző gyártók SD-WAN-nak titulált megoldásait próbáltam összegezni magamban... Figyelemebe véve az alap elképzelést és a technikai megvalósíthatóságot, három kategóriát állítottam fel ezekre megoldásokra: SD-WAN megoldások - melyek biztosítják a transzport agnosztikus átvitelt, lehetőséget adnak a szolgáltatótól független topológia kialakítására központi orkesztráció és kontroll segítségével, továbbá az üzleti alkalmazások számára északi irányú API integrációra adnak lehetőséget. SD-NINCS megoldások - melyek marketing anyagokban szerepeltetik az SD-WAN-t, viszont technikai oldalról csak egy jól komponált policy based routing, ami  maximum megvalósítható. SD-LESZ megoldás - valahol a kettő között... Fortigate SD-WAN Március 13-ka óta HOME-OFFICE-ban dolgozom. Nem volt egyszerű az átállás, legalábbis mentálisan mindenképpen megterhelő a napi feladatok elvégzése úgy, hogy közbe

IPAR 4.0 - Okos megoldások, hülyén megvalósítva

IPAR 4.0 Telekommunikációs és informatikai berkekben, az IPAR 4.0 eszközöket valahogy úgy definiáljuk, hogy ipari cuccok amik IP hálózaton is kommunikálnak... Természetesen ez egy durva egyszerűsítés, de ebből a szögből nézve a gyártásban betöltött szerepe nem annyira fontos, mint a hálózatban elfoglalt helye. Ezek olyan tipikusan beágyazott-rendszer alapú megoldások, melyek saját operációs rendszerrel rendelkezhetnek, és IP kommunikációra, egy már korábban lefejlesztett általában valamilyen linux alapú kernel modult használnak. Az ilyen eszközök mondhatni semmilyen tűzfal vagy végpontvédelmi megoldással nem rendelkeznek, kommunikációjuk az adatgyűjtő berendezésekkel általában nem titkosított, így potenciális veszélyforrást jelentenek a hálózatunkban. Nos eddigi tapasztalataim alapján az IoT és/vagy SMART termékek terén az, hogy minél olcsóbban, minél több szolgáltatást legyenek képesek nyújtani a végfelhasználó felé. A ipari plc-k vezérlő szoftvere - amin keresztül menedzs