Ugrás a fő tartalomra

HPE TSS Network view day 3

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 Center-be vizsgázni, hogy megnyugodjak :). Így aki többet szeretne megtudni a technológiáról annak figyelmébe ajánlom az alábbi linkeket:

https://www.hpe.com/us/en/newsroom/press-release/2018/06/aruba-introduces-integrated-sd-wan-lan-and-security-solution-to-power-the-software-defined-branch.html

https://packetpushers.net/aruba-networks-joins-sd-wan-crowd-sd-branch-release/

Ennek következményeképpen lemaradtam a szintén ígéretesnek hangzó:
Aruba ClearPass Authentication Technologies DeepDive-ról... :(

HPE6-A67 Designing Aruba Solutions 
Nem volt könnyű a vizsga, megszenvedtem vele, sokat a Candidate agreement miatt nyilván nem mondhatok el, de aki megveszi a hivatalos Study Guide-ot és lelkiismeretesen (nem úgy mint én) átolvassa, ha nincs előképzettsége megtanulja a leírtakat, akkor az jó eséllyel sikeresen teljesíti a vizsgát.
Szerencsém volt mert a gyártó specifikus dolgokat azért megtanultam, a többit meg basic Networking-es tudásból pótoltam, és az is sokat segített, hogy a kollégákkal együtt tanultunk úgyhogy:

bada-bumm-tsss
Na de térjünk vissza az előadásokhoz... A következő előadás amire bementem az a:
AMD-Optimizing your AMD EPYC based HPE ProLiant DL385 and ... (expert)

Newmannal ketten mentünk, így aki az AMD-re és DL3x5-re kíváncsi annak ajánlom ezt az írást:

https://newman.cloud/2019/02/14/epyc-battle/

Mert én egészen más aspektusból vizsgáltam a CPU architektúrát, persze hasonló következtetéssel mint Newman.

Netwörkösként (:D) és a hálózat-virtualizáció híveként, én azt próbáltam kihámozni az előadás során, hogy az EPYC processzoros architektúrák vajon mennyire NFV képesek. Az előadáson elhangzott a lányoktól - igen lány mérnökök voltak az előadók - hogy NFV ready... Miért is?
AMD - 32 core 128 PCIe bus, 8 ch DIMM, 2TB RAM-ig skálázható platform
Intel - 28 core ... a lényeg hogy kevesebb mint az AMD-nél
Több vCPU, több vRAM, erősebb VNF...
Sajnos nem ilyen egyszerű, mert az AMD 32 magos architektúrája nem 1*32 core, hanem 4*8 core, ami nagy VM-ek esetén - pl: 10 vCPU vagy 20GB RAM - nagyobb késleltetést okoz NUMA miatt... Így arra következtetésre jutottam, hogy inkább ez lesz a NFV infrastruktúra esetén a megoldás:
32 core = 4*8vCPU VNF vagy 8*4vCPU VNF vagy 16*2vCPU VNF, vagy 32 1vCPU VNF javasolt 2-16 GB RAM mellett....


NFV platform esetén AMD processzorral szerelt szerver akkor lesz jó, ha nekem nem egy nagy teljesítmény igényű (virtual PE) VNF-et kell létesítenem, hanem sok kis kapacitású service VNF-re van szükség. PL: vCPE, vagy kisebb vFW. Az előbbinél inkább maradjunk Intel alapú platformon.

Aruba Instant WLAN with HA (professional)
Hasznos és érdekes volt az előadás, sajnos engem még WLAN nem köt le annál jobban mint amit egy-egy vizsgára meg kell tanulni, így tehát akit érdekel a téma az kérdezze a kiváló Wifi-s szakembereinket.
Aruba VSX indepth demo (expert)
ArubaOS-CX alapú rendszerek, nagyon kifinomult (ProvisionOS-hez képest) képességekkel rendelkeznek, ilyen például a VSX is, ami csak két betűben tér el a VPC(virtual Port-channel)-től. Ez egy Aruba properitary protokoll, ami azért VPC-hez képest azért sokat fejlődött és javult. Pl VPC-ben összerakott SW-k esetén a konfig-nak csak a FEX része szinkronizálódhatott(amikor én ezzel találkoztam) , és ami azon kívül volt az kézzel kellett a VPC peer-eken felkonfigurálni. Az Aruba VSX-nél a konfigurációban megadhatom, hogy melyek azok a részek amik szinkron Control Plane-t igényelnek, és melyek azok amik egyedi konfigurációk. Ami ennek kapcsán tetszett még, az a
vsx upgrade tftp:....

Ami VSX tagok szinkron upgrade-jét indítja el anélkül, hogy a másik eszközre bármilyen console session-t indítottunk volna. Az upgrade procedúra persze az, hogy előbb primary, aztán a secondary VSX tag indul újra. Ami még szempilla rebegtető volt, hogy VSX failover kevesebb mint 300ms alatt kiesést okozott egy komplex L2 és L3-ot tartalmazó hálózatban. Ez Enterprise kategóriában lenyűgöző teljesítmény.

DataCenter InterConnect (professional)
Röviden ugyanaz volt az előadás lényege mint BGP-EVPN-nél (Day 1 és Day 2-ben leírtam ugyanaz volt az előadó is), a lényeg DCI-re BGP-EVPN-t és VXLAN-t használj!!! ComwareOS alapú Aruba switch-en támogatott... Itt most azért sem kezdek bele nagy litániába a BGP-ről meg Overlay-Underlay hálózatról, mert külön bejegyzést szánok neki gyártótól függetlenül...
Deep dive into User-Based and Port-Based tunneling deployments (expert)
Elfáradtam, és ez már sok volt, így sok mondani valóm nem lesz ezzel kapcsolatban. A lényeg annyi, hogy CLI-ben megmutatták, hogy mi a különbség a user és port based tunneling között, ez leginkább akkor és ott érdekes ha valami hiba, ha troubleshoot-olni kell, ha sikerül valamilyen kis Aruba Demo környezetet ClearPass-al aruba SW-vel és AP-val MC kialakítanom mondjuk félig virtuálisan, akkor ezt a kérdéskört megvizsgálom magam részletesen...


Aztán partytime:

Összefoglalva

Ma változatosra sikerült számomra a rendezvény, reggel sok izgalom után estére elfáradtam így a lelkesedésem is visszaesett, aminek új erőt a holnapi ACSP-re készülés ad...


É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