Köszi, meglesem ezeket.
Kevin Wallace - CCNA 200-301 Complete Video Course and Practice Test -ről mi a vélemény vagy tapasztalat ? Recommended kat ?

Abszolut ok. Nem annyira reszletes, mint Neil Anderson, vagy David Bombal, de amit elmond azt jol,erthetoen. Jo hallgatni, nagy beleelessel beszel, de nincs tultolva, mint mondjuk Jeremy Cioranal.

Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben

Gyors kérdés (már amennyire): CCNP-re készülnék, már nagyon ideje lenne, ehhez csinálnék egy layer2 labot. Layer3-ra ott a gns, eve-ng, valódi eszközök külön. Rendelkezésemre áll elég sokféle Cisco switch (2960c-től felfele), de főleg 2960x környéke.
Ha irodában futna, ti mit raknátok össze? Egy 5 tagból állóra gondoltam, amiben van egy stack is, így kvázi 4 eszköz. Távolról piszkálnám néha, főleg olyankor, mikor otthon nem lesz mit tenni HO-ban covid miatt.

Az ENCOR vizsga témáiban és az OCG-t átfutva semmi olyat nem látok, amire egy alapvető labor topológia ne lenne elég. Én a következőt csinálnám:
- 4x2960x, bekötve egy full meshbe
- néhány helyen etherchannel
- köss mindegyikre vagy egy konzol routert, vagy egy dedikált, külön VPNen át elérhető mgmt VLANt csinálj. Ne kelljen bemenni, ha valami nem adja ki

Ezen a topológián szerintem mindent meg tudsz oldani, ami kellhet. Azt nem látom, hogy egy sima 2960x stack miben adna többet neked, melyik "CCNP" protokoll vagy technológia, ahol ez számíthat.

Én így kötném össze, ha ragaszkodsz a remote labor elgondoláshoz. Fontos, hogy legyen a külön management hálózatod, mert ha bármi félrekonfigurálsz, akkor is legyen esélyed elérni az eszközöket. Nyilván azoka a management portokra csatlakoztatnám a switch-ek oldalán és a rendes portokra a management switch-en. Ha van L2VPN elérési lehetőséged, akkor akár aközvetlenül SSH-zhatsz be a 4 switch-re a management switch-en keresztül. (Nyilván ehhez kell legyen rajtuk aktív management interfész és működő SSH)- Készülj fel, hogy a gyakorlás során kerülhetsz olyan helyzetbe, hogy kizárod magad az egyikről még ebben a felállásban is.

Ezért én inkább a következőt csinálnám: hazavinnék 3 db L2-es switch-et (abból 2 stack-elhetőt) stack kábeleket, pár UTP kábelt és otthon konzol kábellel küzdenék velük.
Már csak környezetvédelmi szempontból sem mindegy, hogy 24 órában fognak-e menni, vagy csak, ha bekapcsolod, de tanulás szempontjából sem feltétlenül mindegy. Például a stack-nél azt gyakorolni, hogy melyik switch legyen az elsődleges, hogyan veszik át a vezető szerepet, ahhoz le kell kapcsolni, stack kábeleket kell kihúzkodni, bedugni....
Aztán kell majd csinálnod storm-ot, hogy lásd milyen az, hogyan "uralod" storm control mellett. Ha egy remote laborban csinálsz storm-ot és esetleg nem uralod, úgy marad, az nem fog jót tenni, sem a switch-eknek, sem a szerver szobának, amit melegít, búgat.
Szóval szerintem sokkal több lehetőséged van tanulásra, ha fizikailag eléred az eszközöket. Főleg, ha 2960c-hez is van hozzáférésed, ami nem búg! Annál csak a 3560c jobb home lab switch!

De egyébként belegondolva, akár Eve-NG-vel, akár GNS3-al a stack-en, password recovery-n kívül mi az aminek a konfigjának gyakorlásához valós hw kell neked?

[ Szerkesztve ]

Ha van console terminal server, vagy async octopus, akkor meg ssh sem kell. Broadcast stormnal az is necces, oda mar a konnektorhoz kellene tavoli eleres. APC-nek van ilyen megoldasa is, de szinte sehol nem hasznaljak. GNS3 layer 1ben gyenge, amikor layer 1 connectivitivel jatszottam, a speed mismatchet eszre se vette. Ccna szinten is sok videot lattsm, ahol mondta az oktato, hogy a config ok, tuti a gns3 a hulye. Neha 1-2 perc utan eszhez tert, neha ott is flappelni kellett, ahol fizikai vason nem. Mondjuk nem ezen fog mulni a sikeres felkeszules , mert ezek eleg ritka esetek.

[ Szerkesztve ]

Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben

A megoldas, raspberry pi ssh-val es switch darabszamu usb to serial adapter + cisco console kabel. filleres megoldas, en ezt hasznaltam.

Kreativ.
Gondolom, valami ilyesmi kellene : [link]
Azert is jo, mert a malnara akar egy drotcapat is ra tudsz ereszteni.
Wifis uplink, es akkor az Ethertnet lehet a monitor port, vagy akar a AAA/DHCP server is

[ Szerkesztve ]

Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben

Akar, bar ez feleslegesen draga, ez tokeletesen eleg, csak annyit veszel belole amennyi switched/routered van: [link]
Meg persze egy-2 usb hubot hozza, ha nem lenne eleg port.

linux alatt szinte minden usb to serial kabel mukodik, igy nem kell aggodni miatta. Nem szep megoldas, de annyira olcso, hogy nekem megerte. raspberry pibol is boven eleg egy rpi 1 akar. De igen, ha nagyobbat veszel tcpdumpolhatsz helyben amit redircetelni lehet wiresharkba localba. [link] A lehetosegek hatartalanok

[ Szerkesztve ]

Layer 2 amit gyakorolni szeretne, l1-et csak a valóságban lehet. GNS3 is csak egy frontend, azt teszel bele, amit "akarsz" (IOL L2-es image-eket például vagy akár Nexxus 7k VM-eket, ha elég erős a vas) de ha nem jut hozzá, vagy nem akar bajlódni a nyűgeik megismerésével, akkor még mindig ott van a jó öreg dynamaps-es switch modulos router. Arra az is jó, hogy az etherchannel, spanning tree konfigokat gyakorolja. Persze mondjuk a MST-t már nem fogja tudni. A DHCP snooping és társai sem tudom mennyire mennek ezen (IOL-en igen). Arra viszont 1 db igazi switch is elég.

nálam ez már agyúval verébre kategória
Egyrészt szerintem a Rpi túl drága erre (sajnos zer-t már nem kapni, kell hozzá táp, SD kártya, doboz, esetleg USB OTG átalakító). Én használtan 3eFt-os D-Link és TP-Link USB porttal rendelkező otthoni "routereket" használok hasonló célra. Fel rá az OpenWRT (ami ugye Linux) arra fel az USB2serial chip drivere meg a minicom. Be SSH-zol, elindítod a minicom-ot pont mint ahogy az Rpi-vel csinálnád. Nem kell hozzá venni külön tápot, SD kártyát, sőt valószínű jobb wifi van benne, mint az Rpi-ben. (Nálam a wifi volt a lényeg, mert leginkább úgy használtam eddig, de akár a LAN WAN portján közvetlenül mehet akár az internetre).

De még ez is erős túlzás, ha olyan switch van, amin gyárilag van management port ott sincs másképp megoldva, mint, hogy külön Mgmt VRF-be van rakva a port.
Itt (mivel csal L2-es switch-ekről beszéltünk) még ez sem kell elég, ha egy portot külön dedikált vlan-be tesz és az ábra szerint csillagpontosan beköti egy management swich-be.
Sajnos hajlamosak vagyunk túllihegni a feladatot: arra kell megoldás, hogy laborozni tudjon CCNP szinten l2 protokolok gyakorlására. Mivel hozzáfér jóféle switch-ekhez, akkor miért ne, de minden más esetben azt ajánlanám, hogy használtan venni 3 db L3-as Catalyst switch-et (3550, 3650, 3750) és azzal a routing-ból is lehet gyakorlatilag mindent CCNP szinten gyakorolni. Ha meg megvan a vizsga ha eladja feléért, akkor sem volt nagy luxus.

GNS3 serveres módban is futhat, kis túlzással korlátlan erőforrás áll rendelkezésemre, szóval bármi mehet bele.

Köszönöm mindenkinek a javaslatokat, szerintem marad a 2960c lab, 4 darab, full mesh. Ez a setup hangtalan és alig fogyaszt, amit esetleg nem tud, majd bent személyesen megnézegetem a nagyobb vasakon A lerohadás miatt nem aggódok, legrosszabb esetben bemegyek és újralököm őket, igazából pár percre van a munkahelyem.

Igen, nullarol vasarolni mindent, kicsit overkill, de nekem amugy is volt egy mukodi rpi-m, igy az usb -> serialok extra koltsege minimalis volt, nekem otthoni routert lett volna sokkal dragabb venni, mivel ubiquiti eszkozeim vannak itthon es semmi ertelme nem lett volna erre egy uj routert megvenni. De nyilvan kinek mi van otthon abbol foz

Wifi-nek minimalis ertelme volt szamomra, megiscsak minimalis forgalomrol beszelunk, es jo volt a jel amit vett.

Persze, megoldas az is, hogy ugy konfigolod fel, hogy legyen egy mgmt vlan es ennyi, de nekem a fentebb emlitett dolgok miatt kenyelmesebb volt igy, raadasul biiztosan nem zartam ki magam az eszkozbol sehogy sem.

Amugy az igazsag az, hogy ccnp szintre szerintem meg a fizikai eszkoz is tulzas, de artani nem art, ha lat az ember igazi vasat.

Sziasztok. Ciscoban jartas ember segitseget kernem. Van egy C9115AXI Ap-m amit ezek alapjan [link] [link] megprobaltam ewc modba rakni. Sajna recovery modba kerult ujrainditas utan. Hiaba probalom vele letoltetni ujra a bin filet. 90-92% korul megall a letoltes mintha elfogyna a hely (lehet hulyeseg) es csak ismetelgeti "EWC-AP in Recovery Mode......
Please use 'archive download-sw' to upgrade AP and Controller image.
Please use 'show flexconnect ewc-ap launch-log' to check EWC-AP launch log."
Tudna nekem ebben segiteni valaki?

Sziasztok még a régi vizsgarendszerben letettem a 300-115 CCNP-SWITCH modult, de mást nem, ugye az új rendszer felülírta a dolgokat.

Ha én most CCNP-t szeretnék akkor ha jól vettem ki a 350-401 CCNP and CCIE ENCORE-t kell letennem kezdésnek?

Igen. Itt a migration tool.

CCNA RS, Security és egyéb hálózati témák oktatása: https://ccnaoktatasmagyarul.hu

Sziasztok! Vásárolt már valaki Cisco Press oldalon olyan könyvet, ami még nem jelent meg, tehát preorder vásárlás volt? Nyáron vettem a Devnet Associate könyvet, most már published, de nem jelenik meg a letöltés az accountomon belül. Eközben ha most venném meg, akkor le lehetne tölteni. Support síri csendben szokás szerint, emailt írtam nekik.

CCNA RS, Security és egyéb hálózati témák oktatása: https://ccnaoktatasmagyarul.hu

Vettem mostanában kettőt is így (SD-Access és SD-WAN), amint megjelentek a könyvek jött az email hogy letölthető.

En is vettem pre-orderben konyvet,es meg is erkezett.
Ki kell keresni a visszaigazolo mailt,es az ott talalhato sorszamok alapjan bejelenteni a problemat.
Szerintem meg aznap valaszolnak.

(#15665)
Ha Enterprise a cel, akkor a 350-401 az alap, es utana lehet valasztani ezek kozul.
300-410 ENARSI Implementing Cisco Enterprise Advanced Routing and Services (ENARSI)
300-415 ENSDWI Implementing Cisco SD-WAN Solutions (SDWAN300)
300-420 ENSLD Designing Cisco Enterprise Networks (ENSLD)
300-425 ENWLSD Designing Cisco Enterprise Wireless Networks (ENWLSD)
300-430 ENWLSI Implementing Cisco Enterprise Wireless Networks (ENWLSI)
300-435 ENAUTO Implementing Automation for Cisco Enterprise Solutions (ENAUI)

Indulhatsz DC, SP, vagy Secu vonalon is, ott is van egy Core vizsga,es utana 3-5 szakvizsga kozul lehet valasztani.
Ezeket itt talalod meg :
https://www.cisco.com/c/en/us/training-events/training-certifications/certifications/professional.html

[ Szerkesztve ]

Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben

En kiolvastam ket ocg-t a kindleon,mire rajottem, hogy el lehet forditani 90 fokban
Allitva necces, de igy mar vallalhato.

Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben

Detto ugyan ez.
SD-WAN és Devnet vettem meg egyszerre, de csak az sd-wan lett elérhető az e-book letöltésnél.

They can break you but not your promise, even death won't keep you apart. Through this darkness you will find him in your sword still beats, a heart.

Wireshark 3.3.0 development release: jön a packet diagram. Szerintem tanuláshoz baromi hasznos lesz.

Sziasztok!

Adott egy Cisco ASR9k IOS XR, rommon módban 0x2102 vel ignorálva lett a rajta lévő konfig, de kiderült hogy az mégis kellene.

Hogy lehet vissza állítani sztenderd módra hogy úgy töltsön be mint a rommon mode os mókolással előtte?

Simán rommon ban 0x2100 ra rakom?

[ Szerkesztve ]

0x2100 al némi töltés után vissza dob rommon mode ba, nem bootol vissza.

Na jó félrenéztem 2102, így már persze jó.

Sziasztok, megéri elkezdeni tanulni erre az új CCNP-re vagy az Aws+Python jobb irány és a CCNP ráér később? kb. CCNA vizsgaképes szinten vagyok most.

Az egyik devops irány, a másik az enterprise networkinget tekinti át mélyebben, ezen a téren továbbira is az irányadó cert senior pozik felett. A cert megszerzéséhez egy mélyebb, networking területböl is kell concentration vizsgát tenned.
Azt neked kell tudnod, hogy az overlay+automatizálás vagy az underlay érdekel-e jobban. python alatt is mit értünk? Kvázi univerzális, magasszintü nyelv. Ha a szoftverfejlesztöi része érdekel a szakmának esetleg nézd meg a DevNet irányt, nagyon ráfeküdt most erre a Cisco.

[ Szerkesztve ]

Szerintem egyre kevesebb értelme van a Cisco felé fordulni. Az Enterprise irány teljesen életképtelen lesz rövidesen, aminek van értelme az a service provider és a data center. AWS és Azure valamint python alapok az automatizáláshoz, ma már ezek felé tekintgetnék.

Miért gondolod így?

Talán itt is leírta valaki korábban, amit én is gondolok: attól, hogy a DC/cloud irányt sulykolják a gyártók (+persze az SDN is 10 éve váltja meg a világot...) ez a networkök töredéke; a szervezetek 95%-a tökéletesen elégedett az on-premise megoldásokkal + valami alap data-center megoldással.

Azért gondolom így, mert a cloud annyira komplex és költséghatékony megoldást kínál a customereknek, amiket rövid időn belül ki is fognak használni.
A SDN folyamatosan váltja meg a világot, egyre növekvő mértékben.

"szervezetek 95%-a tökéletesen elégedett az on-premise megoldásokkal"
Erre azt tudom mondani, hogy évszázadokig lovon ültünk, amig meg nem jelent az első autó.
Az on-premise megoldás addig életképes, amig nem hasonlítod össze a fenntartási költségeit a cloud megoldásokkal. Ez is egy folyamat, amíg kifutnak a customer hálózatában lévő eszközök, licenszek és folyamatosan fognak átmigrálni cloudba.

[ Szerkesztve ]

Lehet, hogy így lesz, de azért nem csak az eszközök, licenszek kifutása a kérdés itt. Nálunk például megvan az akarat, a cloud az irány, de az application-ök egyszerűen nem olyanok, amiket egyszerű átültetni cloud környezetbe. És akkor ott tartunk, hogy a cloud-ban is úgy csinálunk mindent, mintha on-prem környezetünk lenne. Telerakjuk tűzfalakkal, nem cloud loadbalancerekkel, és aztán csodálkozunk, hogy a működés nem olyan zökkenőmentes, és az operation ugyanúgy le van terhelve és lassan mozdul, mint on-prem környezetben.

CCNA RS, Security és egyéb hálózati témák oktatása: https://ccnaoktatasmagyarul.hu

Azert, azt tegyuk hozza, hogy a cloud az tovabbra is csak somebody else's computer.
Nincs uj a nap alatt, voltak a mainframe-ek, aztan jottek az on-prem DC-k aztan most van a cloud. Persze koltseghatekony, meg skalazodik meg capex helyett opex es igy jobban tervezheto, de en azert nem erzem, hogy a kozeljovoben ne lenne szukseg entreprise networkosre.
Ezt elmondva, azert szerintem minden enterprise networkingben dolgozonak erdemes legalabb alapszinten megismerkednie egy-ket cloud provider szolgaltatasaival, aki meg most kezdi siman specializalodhat arra, mert boduletes osszegeket fizetnek erte szerte a vilagban, mert aranylag kevesen ertenek hozza Persze ettol fuggetlenul alap szintu networking tudas mindenkinek, ha nem is kell, de ajanlott, es hasznos.

Mitől lesz egy applikáció nem-cloud kompatibilis? Miért kell telerakni nem-cloud loadbalancerekkel és tűzfalakkal?

[ Szerkesztve ]

Nem feltétlenül azt írtam, hogy nem cloud kompatibilis (bár olyan is lehet, ami speciális hardveren fut csak pl). Hanem inkább úgy értettem, hogy néha architektuális változtatások kellenének egy alkalmazásnál, hogy igazán cloud alkalmazás legyen. És ezt sok cég nem lépi meg, sokszor nem is lehetséges egyáltalán. Cloud migrációs stratégiák, nálunk leginkább a lift and shift van.

Mi például nagy F5 felhasználók vagyunk, nagyon sok alkalmazásunknál a traffic különböző advanced loadbalancing szabályok alapján kerül továbbításra (iRule-ok, cookie insert, SSL offload, http header változtatások). Mivel az alkalmazás ilyen körülmények között fut az on-prem környezetben is, ezért ez a fejlesztők elvárása cloud-ban is, mert nem fogják átírni az appot. És ezeket a dolgokat a cloud native loadbalancerek nem tudják.

Aztán ott vannak a tűzfalak. Cloud native tűzfalak sokszor csak layer 4, vagy ha layer 7 is, akkor nem olyan szintű, mint amit nálunk a security elvár, inspection, logolás, stb.

Így már ott tartunk, hogy egy sima web stack elérése így nézhet ki (leegyszerűsítve):
cloud LB --> F5 LB --> cloud LB --> tűzfal --> cloud LB --> webszerver
És mivel redundásnak kell lennie, minden nem natív cuccból legalább egy pár kell, mert a cloud provider bármikor lelőheti az egyiket kérdezés nélkül.

Ilyenkor már annyi licenszes cuccot futtatsz, sokszor ugyanúgy túlméretezve, ergo drágán, kihasználatlanul, hogy árban már ki tudja, megéri-e... Egy igazán cloud alkalmazásnál, natív cloud szolgáltatásokkal jobban működne az, amiért a cloud igazán vonzó lehet, a horizontális és vertikális rugalmasság.

[ Szerkesztve ]

CCNA RS, Security és egyéb hálózati témák oktatása: https://ccnaoktatasmagyarul.hu

Attól függ mit akarsz: sok mindenhez érteni "felületesen" vagy egyvalamihez érteni mélyebben. Egyik sem jobb vagy rosszabb irány, az élethelyzet adja meg mikor melyik lehet a hasznosabb.

Mert mondjuk alacsony latency-t követel meg, vagy multicast-et. Ezek nincsenek az interneten.
De elég csak abba belegondolni, hogy a TCP hogy működik: a küldő nyugtázást vár a fogadótól. Ha a küldő és a fogadó két külön kontinensen van (ami felhő alapon sokszor megtörténik) akkor az nem teszi hatékonnyá a TCP-t. (Erre is vannak "megoldások" lásd Riverbed, de nem az igazi.)

Miért van hardveres loadbalancer? Mert mondjuk a hypervisorok között is elosztja a terhelést vagy csak azért, mert sokkal hatékonyabb, mint a szoftveres (ASICS vs software általános hardveren).

Cloude vs Enterpsie network.
Igen talán a SOHO-ban lesznek felhő alapú hálózatmenedzsment megoldások (Meraki és társai), de nagy vállalalatoknák nem valószínű.
Az Enterpsire pedig nem SOHO.
Hogy mit gondolhat erről a Cisco: nemrég még volt CCNA Cloud, mára csak egy általános CCNA van. Régen R&S-nek hívták most Enterprise Structured Network-nek a szakágat. Talán ezzel is a nagy vállalati mivoltára akarhattak utalni.

No meg attól, hogy a DC-k jó része, az alkalmazások kiköltöznek a felhőbe még nem lesz kisebb igény a vállalati hálózatokkal szemben. Sőt a jelenlegi trendek szerint az Access oldali biztonság lesz a kritikus a jövőben.

Millió helyzet van, amikor nem érdemes / szabad felhőbe költözni. Persze ez nem általános. Most az a trend, hogy mindent outsource-oljanak a felhőbe.
Persze, de volt idő, amikor a csapból is az folyt, hogy az OS/2 lesz a jövő oprendszere és "csak" egy IBM állt mögötte. Azt mégse így lett!

Nem teljesen értek egyet az érveiddel.
Az alacsony latency mindig is szempont volt, már pl. a dmvpn idejében is, ezért van georedundancia a cloud esetében is.
Az a tény, hogy volt CCNA cloud, ma pedig nincs, nem jelenti azt, hogy a Cisco elfordul a cloudtól. Ezzel az erővel elfordul a voicetól és a securitytól is, mert kivonta az összes CCNA irányát. Amit a Cisco cloudnak nevezett, az gyakorlatilag az ACI volt (ma a DC irány része).
Az access oldali biztonság szerintem mindig is kritikus szempont volt és ez a cloud esetében is így van.
"No meg attól, hogy a DC-k jó része, az alkalmazások kiköltöznek a felhőbe még nem lesz kisebb igény a vállalati hálózatokkal szemben" Dehogynem. Mivel egymás "konkurenciái", ahol nő a kereslet ott a másik oldalon csökken.
Szerintem a cloud nem egy trend, hanem egy logikusan megtervezett és felépített modell, ami komoly vetélytársa az enterprise alapú megoldásoknak.
Az, hogy voltak közösségek, akik az OS/2-t szerették volna a jövő oprendszerének egy vágyálom volt, teljesen mindegy, hogy mi állt mögötte.

[ Szerkesztve ]

A DMVPN-t nem értem hogy jön ide a latency-hez?

Nem azt jelenti. Ez nyilván csak elméleti okoskodás, mert nem tudjuk mit akar a Cisco, de ezek a dolgok (CCNA szakirányok megszűnése, CCNA általános "felületesedése", R&S Enterprise-á válása...) nálam azt sugallja, hogy a Cisco arra számít, hogy a SOHO-ban felhő alapon menedzselt megoldások terjednek majd el, ezért nem lesz igazán szüksig alacsonyabb szintű tudással rendelkező CCNA specialistákra (lásd CCNA Cloud, Security, R&S....)
A voice-ot nem rángatnám ide, mert az már jóval korábban megszűnt és a collaboration vette át. Egyébként nálam is életszerűtlen a "klasszikus" VoIP 2020-ban egy zöld mezős irodai megoldásnál. Ma már nem kérdés szerintem, hogy a mobiltelefon a hanghívás fő eszköze. (A személyt akarod hívni, nem az asztalát.)

Nem, nem mindig volt kritikus az access oldali biztonság. Nézd meg egy átlagos vállalati rendszerben még nagyvállalati szinten sem áltanás a vezetékes eszközök dot1x-es authentikációja, a wifi-t még ma is sok helyen egyszerű jelszóval védik. És "régen" még elég általános model volt, hogy a végberendezések nem rendelkeztek internet eléréssel, hanem proxy-ztak.
Na próbálj meg proxy-zva felhőszolgáltatásokat igénybe venni. Nem lesz könnyű.

Nem a Cisco soha nem nevezte az ACI-t cloud-nek. Miért is nevezte volna? SDN-nek nevezte/nevezi.
Szerintem a fogalmak terén nem egy malomban örlünk: a felhő lehet konkurenciája a DC-nek, de nem lehet a strukturált enterprise network-nek. Függetlenül attól, hogy a szerverek egy helyi DC-ben vagy az interneten egy távoli DC-ben működnek a végberendezéstől az internetig kell hálózat. Az interneten keesztül kellenek VPN-ek. Hogy esetleg egyszerűsödik az enterprise hálózat azáltal, hogy a helyszínek egymás közti kommunikációját hanyagoljuk, és csak az "internetben lévő felhővel" kommunikálnak. Ebben még lehetne valami, de ez megint visszalépés: volt már ilyen hub and spoke topológia.
Képzeld csak el van egy videokonferencia, amit egy vállalat 3 városában lévő telephelyei között rendeznek. Egy on premise megoldásban ez simán működhet bidirekcionális multicast-el, aza a 3 helyszínről a kimenő hang/kép információ eljut a másik kettőhöz. A latency a lehető legkisebb lesz, mert a csomag nem jár meg felesleges köröket. Ugyanez egy felhő megoldásnál minden helyszínről eljut minden egy központi szerverhez ami valahol az interneten üzemel, majd onnan vissza mind a három helyszínre. A kettő műszaki megoldás közül " modernebbnek" mondott felhő rosszabb felhasználói élményt, több biztonsági rést és rosszabb hatékonyságot okoz.

Szóval én még emlékszem az OS/2-es időkre. Szerintem nem volt nagyobb vágyálom, mint ma a felhő. Akkor az IBM még meghatározóbb cég volt, mint a Microsoft.
Továbbra se mondom azt, hogy nem lesz felhő megoldás, mert sok mindenre alkalmas, főleg ha a privát felhőt is idevesszük.
Viszont van egy csomó helyzet amit nem tudsz felhő megoldással kezelni:
- kezdem a legextrémebben: mit teszel, ha mindened a felhőben van. A felhő egy USA cég felügyelete alat és Magyarország hadat üzem az USA-nak? Ugye extrém?! De kétszer már megtörtént a történelemben.
- hogyan oldod meg a allback-et, ha egyszerűen pénzügyi okból összerúgod a port a felhőszolgáltatóddal? Nem lesz se eszközöd, se személyzeted, know how-d, se backup-od a saját adataidról, teljesen ki vagy szolgáltatva a felhő szolgáltatónak. Hogy ilyen nincs, mert a felhőszolgáltatók jók? Lásd Fortnite Apple store esetet.
- mit csinálsz, ha a felhőszolgáltató leáll, feltörik...Persze kártérítést követelsz, vagy akár perelsz. Ja jó eséllyel perelsz egy sok milliárd dolláros céget, miközben a saját cégednek legjob esetben nincs bevétele, és nem működik az IT rendszere, nincsenek bizonyítékul szolgáló adataid mert a felhőben vannak. Rosszabb esetben, meg már te fizetsz kártérítést az ügyfeleidnek. Hogy ilyen nincs, mert a felhőszolgáltatók nagy IT cégek, ahol mindíg minden működik és nem törik fel! Hát erre két szavam van a közelmultból: Zoom és Garmin.
- talán a legkevésbé extrém, de talán a legfontontosabb: hogyan oldod fel azt, hogy ahol a saját szolgáltatásodat végzed, mondjuk EU és ahol az igénybe vett felhőszolgáltatást felügyelik, mondjuk USA különböző jogszabályi feltételeket szab az adatkezeléssel kapcsolatosan? Vállalod a kockázatát? Auditálod a felhő szolgáltatót és folyamatosan felügyeled?
- hogy oldod meg a backup kérdését: rábízod a felhő szolgáltatóra? És mi van, ha a gebasz olyan, hogy a felhő szolgáltatót teljesen érinti (lásd összerugod vele a port ketegória). Vgay helyben tárolod, amit letöltögettél a felhőről. Ez már egy fokkal jobb, de kb mennyi idő alatt állítasz fel egy működő rendszert a backup-jaidból egy másik felhőszolgáltatón? Ugye kell hozzá hozzáértő személyzet (akiket korábban elküldtél és már a felhőszolgáltatónál dolgoznak) és ha van is ott lesz a tömérdek adat, amit fel kell töltened egy másik felhő szolgáltatóra. Az aztán gyors lesz!

Igazából a hybrid on premise és felhő DC-kben lenne a jövő, de itt jön be a latency kérdés. Én nem tudok olyan strech clusterről, ami így működne, mert hatalmas sávszélességet és alacsony latency-t igényelnek, ami az interneten nem megy. Vannak amit úgy hírdetnek, de kiderül, hogy csak a winess kerül fel a felhőbe, ami hát nem nagy előny.

Úgy jön ide a dmvpn, hogy ha Budzsumurából, vagy Kathanduból csattansz a hubra, akkor meg kell oldani, hogy georedundáns legyen a hub, különben irgalmatlan nagy lesz a latency.

"Nem a Cisco soha nem nevezte az ACI-t cloud-nek. Miért is nevezte volna? SDN-nek nevezte/nevezi."
https://www.cisco.com/c/dam/en_us/training-events/certifications/shared/docs/cloud_overview.pdf
300-507 CLDACI : Building the Cisco Cloud with Application Centric Infrastructure (CLDACI)

"A voice-ot nem rángatnám ide, mert az már jóval korábban megszűnt és a collaboration vette át."
Krumpli, burgonya.

"Szerintem a fogalmak terén nem egy malomban örlünk"
Végre valamiben egyetértünk.

"Függetlenül attól, hogy a szerverek egy helyi DC-ben vagy az interneten egy távoli DC-ben működnek a végberendezéstől az internetig kell hálózat."
Akkor meg nem mindegy, hogy hol van a szerver?

"Képzeld csak el van egy videokonferencia, amit egy vállalat 3 városában lévő telephelyei között rendeznek. Egy on premise megoldásban ez simán működhet bidirekcionális multicast-el, aza a 3 helyszínről a kimenő hang/kép információ eljut a másik kettőhöz."
Corner case szituáció.

"- kezdem a legextrémebben: mit teszel, ha mindened a felhőben van. A felhő egy USA cég felügyelete alat és Magyarország hadat üzem az USA-nak? Ugye extrém?! De kétszer már megtörtént a történelemben."
Mivel üzenünk hadat, gulyáságyúval? Ma nem az USA kormánya kormányoz hanem a multinacionális cégek.

"hogyan oldod meg a allback-et, ha egyszerűen pénzügyi okból összerúgod a port a felhőszolgáltatóddal?"
Ez mégis milyen esetben következhet be, amikor centre pontosan, előre meghatározott módon megadják, hogy melyik felhőszolgáltatás mennyibe fog kerülni?

"mit csinálsz, ha a felhőszolgáltató leáll, feltörik."
Ez bőven megtörténik privát DC-vel is.

"talán a legkevésbé extrém, de talán a legfontontosabb: hogyan oldod fel azt, hogy ahol a saját szolgáltatásodat végzed, mondjuk EU és ahol az igénybe vett felhőszolgáltatást felügyelik, mondjuk USA különböző jogszabályi feltételeket szab az adatkezeléssel kapcsolatosan?"
Átviszed egy európai régióba a szolgáltatásodat.

"hogy oldod meg a backup kérdését"
Erre van a hybrid cloud, ha már annyira nem bízol a cloud backupjában.

Ehhez nincs köze a DMVPN-nek, legfeljebb anyiban, hogy DMVPN-t jellemzően hagyományos internetkapcsolaton építenek ki. De ezt nem kell feltétlenül így csinálni, lehet akár "bérelt vonalon" keresztül is.
A latency-nek a távolsághoz, meg a "sima" internetkapcsolathoz van köze: a fizikát nehéz megkerülni, a távolságot nem kell magyarázni. A sima internetkapcsolat meg mikor ilyen, mikor olyan, de nincs rá mód, hogy integrated service QoS modelben végponttól végpontig garantált sávszélességet, és latency-t kaphatsz.

"Building the Cisco Cloud with Application Centric Infrastructure" Hát ebben a mondatban sem nevezi az ACI-t felhőnek, hanem egy eszköznek, amit felhőszolgáltatásokhoz létrehozásához ajánl.

Voice- collaboration
Nem krumpli burgonya, sőt! Pont az a lényeg, hogy régen a VoIP technológia a telefonálást hivatott kiváltani és arra épült az egész architektúrája, addigra ma megváltozott az igény vállalati eszközökben. Már nem igen tudok arról, hogy komoly cég tömegével telepítetne IP telefonokat. Szoftfon alkalmazás még csak-csak, de leginkább már mindenhol olyan collaboration tool-okat használnak, ahol a hang mellett videó, file megosztás is történik. Mondjuk Webex, ha már Cisco. És igen ebben is van on premise és vannak előnyei és nyomják a felhősödést itt is.

Nem, nem mindegy, hogy hol van a szerver. Milló oka van miért előnyös az on premise és miért a felhős megoldás, de mindig az adott cég, alkalmazás, piaci helyzet...határozza meg melyik a jobb az adott cégnek.

Miért lenne corner case szituáció? Mert rámutat a felhős megoldás hiányaira? Az elmúlt hónapokban szerinted mennyi videókonferencia zajlott, zajlik nap mint nap? Egy átlagos konferencia résztvevőidől 10-ből 7-en néhány 100 méter közelségből egy cég különböző irodáiból kapcsolódnak (ha nem home office helyzet van éppen). Ez azt jelenti, hogy feleslegesen küldjül el a packetek nagy részét az internetre és vissza.

Látom vannak érveid és érted a Világot! Hadat üzenni levéllel szoktak. Lehet ma e-mail-ben menne. Abszurd a példa elismerem, de 2x megtörtént!

Milyen esetben következhet be pénzügyi vita gazdasági szereplők között? Most komolyan? A sulinet-ről írsz?
Hallotál az Apple-ről és az Epicgames-ről például?

Mer' az csak úgy megy, hogy a szolgáltatásodat átviszed egyik kontinensről a másikra! És átküldöd a ki tudja mekkora adatmennyiségedet e-mail csatolmányként?

Persze, hogy megtörténhet privát DC-vel is, de egy privát DC-t te felügyelsz, te tudod milyen óvintézkedések vannak, hogy ne történjen meg. Ha meg havária van, akkor a privát DC minden embere a te DC-d helyreállításán dolgozik, míg amikor egy felhőszolgáltató döl be, akkor az 1024-dik leszel, akit helyreállítanak.
Arról nem is beszélve, hogy mennyire nagyobb célpont egy nagy felhőszolgáltató, mint egy külön DC. No meg attól, hogy a "szomszéd cég" DC-jét feltörik, még nem fog a tied veszélybe kerülni. Ezzel szemben a felhőnél bizony vannak helyzetek, amikor igen.

Sajnos nincs hybrid cloud pont ezt írtam le. Nem tudok olyan technológiáról, amivel streched cluster-t lehet csinálni on premis és cloud között. Ahogy már írtam csak olyan van, ahol a witness-t tudod felhőbe tenni.

a cloud-nak megvan a létjogosultsága, de szerintem is meredek dolog "csak" cloud-ra támaszkodni. Most csak hálózati szempontból, van az internet, amin keresztül eléred a cloud szolgáltatást. Eleve rosszabb szokott lenni az SLA az internetes "bérelt vonal"-akra. Az egy dolog hogy nincs QoS, de ráadásul az egész infrastruktúra könnyen megbicsaklik: egyre növekvő szolgáltatói kapacitásproblémákból adódó magasabb latency és packetloss, esetleg valami BGP flowspec félrekonfig miatt teljes outage órákon át bizonyos régiókban (lásd Level3 1 hónapja), vagy csak véletlen vagy szándékos fals BGP hirdetés elterjesztés... mert még csak alapvető BGP védelmi mechanizmusok sincsenek implementálva bizonyos szolgáltatóknál, nem beszélve az RPKI-ról... és akkor ilyen infrastruktúrán keresztül akarjuk elérni a cloud-ot, aminek amúgy szintén megvannak a saját bajai.
(ha van privát, nem internet fölötti kapcsolat a cloud felé, az más, de általában arra már nem szeretnek költeni...)
Egy olyan autópályán (internet) száguldunk, aminek útburkolata folyamatosan romlik, és bár nem lehetne, de van szintbeli kereszteződése ahonnan néha oldalról is meg szemből is telibekapnak...

Ez a DNS-re is vonatkozik ?
Azt is erdemes on prem tartani ?

Mi kell az alaplapba? Procibol egy, Rambo 2. <> Egyetlen vizmolekulaban tobb hidrogen atom van,mint ahany csillag az egesz naprendszerben