- Nem indul és mi a baja a gépemnek topik
- Melyik tápegységet vegyem?
- NVIDIA GeForce RTX 3060 Ti / 3070 / 3070 Ti (GA104)
- Milyen billentyűzetet vegyek?
- Milyen videókártyát?
- Azonnali fotós kérdések órája
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- 3DMark Vantage eredmények
- Teclast Tablet Topic
- Everest / AIDA64 topik
-
PROHARDVER!
--- Még az új vizsgarendszer előtti információk, majd frissítjük! ---
Gyakran ismételt kérdések
Olvasd el a cikkeket itt.
Új hozzászólás Aktív témák
-
soma314
tag
én megértelek ("kortárs" vagyok) de ha szenvtelenül végiggondolod, akkor nem hagyod lejárni a következők miatt:
- a mostani munkahelyeden ismernek tudják mire vagy képes, de ha úgy alakul (és az életben bármikor alakulhat is úgy) hogy váltasz, akkor bizony keményen számít.
Persze elméletben egy komoly munkahelyen odaültetnek egy terminál ablak elé... Hát nem én ahányszor felvételiztem egyszer sem "ültettek oda" akár CCNP-ként, akár CCIE-ként felvételiztem. Volt aki szakmai kérdést tett fel, de jellemzően nem azok akik tudták is mit kérdeznek és mi lenne a helyes válasz. Illetve most hogy belegondolok egy egykoron nagy nevű cégnél még "tesztet" is csináltam online, aki összeállította CCIE volt elvileg, de gyakorlatilag a kérdések "pongyolák" voltak. Már úgy értem, hogy volt egy "helyes válasz amit elvárt" amire rá is jöttem, de azt is el tudtam mondani, hogy az mért nem feltétlenül "a" helyes válasz mért csak "egy" lehetséges helyes válasz. (Amolyan Cisco vizsgás ismerős?
)
Végkép off topic, de az én személyes tapasztalatom, hogy a felvételi vizsgáknál a "mi az anyagi igénye?" kérdésnél rostálódtam ki. ezért az utóbbi években én pofátlanul előre szoktam ezt venni, hogy ne raboljuk egymás idejét a fejvadásszal, HR-essel...Arra is érdemes gondolni, hogy ha biztos vagy abban, hogy nem akarsz váltani, akkor is, ha többet "érsz" a munkaerő piacon, az jól hathat a fizetésemelésre, jutalmakra, előléptetésre...
Szóval a legtöbb helyen, aki eldönti, hogy behív-e egy személyes, vagy telefonos egyeztetésre nem fog tudni szakmailag tesztelni, ezért csak azokat hívja, akiknek van papírja, és vagy igazolható referenciája. (Ez utóbbi nálad nyilván megvan.)
A másik dolog, hogy sok cégnél "kevés" a cert az adott Cisco partnerséghez és itt nem csak a Gold/Select... partnerségekre gondolok, de az adott specializációkra. Ezeknek meg kihatása van az adott cég gazdasági eredményességére így közvetve a Te munkabiztonságodra, fizetésedre is. Szóval ez szól mellette.Ellene szólna a tanulásba, vizsgába fektetett pénz energia. Mivel a tudásod megvan, ezért "csak" a vizsgára kell tanulnod és mivel a munkahelyen ezt fizetik igazából semmi nem szól ellene.
-
soma314
tag
Nem Cisco, de vizsga téma. Egy kollégám szeretné letenni a Red Hat Linux RHCSA vizsgáját. . A kolléga vagy 15 éves általános (leginkább Debian) GNU/Linux tapasztalattal bír, tehát rendszer szinten ismeri, viszont vannak Red Hat 8 specifikus dolgok. A RHEL 8-at le lehet tölteni, de állítólag a vizsgán "kiherélt" image van, ami nem tartalmaz config file-okat, amiből a gyakorlatban kiindulna az ember. Van itt esetleg valaki akinek van ifója róla? Tanács, a felkészülésre?
-
soma314
tag
válasz
suomalainen
#15713
üzenetére
"Hány olyan MO, vagy Kelet-Európai cég van, ami elmondhatja magáról hogy multi?"
magyar: OTP, MOL hogy legismertebbeket mondjam, de mi köze ennek a claud-hoz?
Azt jelenti, hogy ismert technológiákat használsz, amihez van tapasztalat. A felhőtechnológiákhoz még nincs sok.
Elég rendesen kell tesztelni.Sőt tudok olyat is, hogy van egy "legacy" DC éles üzemben és évek óta üzemel mellette tesztben egy újabb. Csak akkor fognak átállni rá, ha megyőződtek róla, hogy kellően megbízható és érdemes migrálni. Mindegyik on premise.
Az a baj, hogy én meg pont úgy látom, hogy illuzióid vannak inkább csak.
Miattam hiheted azt, hogy az Enterprise vonal halott. Ha valakit erről meg tudsz győzni, annak úgy kell. Nekem nem fáj, kisebb lesz a konkurencia
Senki nem mondta, hogy Catalyst-tal csinálnak DC-t, bár akár. Sok sok olyan rendszert láttam, ahol Nexus switch-ekkel oldottak meg Catalyst-eknek való feladatot, mert az volt olcsóbb, azt ismerte a tervezője jobban...
Óriási különbség nincs funkciókat tekintve és az ISO-XE és az NX-OS működésében sem. Mindegyikél van MLAG, mindegyikkel meg lehet valósítani L3-as technológiákat. Midegyikből van szekrény méretű és 1 U-s is...
Ami lényegi különbség, az az FCoE (Fiberchannel over Ethernet) ha egyben akarod megvalósítani a SAN és a LAN switch feladatokat, akkor Nexus kell. Ha a klasszikus modelt követed és külön SAN hálózatot építesz ki, akkor MDS (ha már Cisco) és hagyományos FC, ha meg "trendi agy", akkor hyperkonvergens szervereket használsz és nincs is fizikai SAN hálózatod. Na és persze nem csak a Cisco-ban lehet és kell gondolkodni. Ott van például az Arista, ami DC környezetben eléggé jó piaci részesedésű. Azt udtad, hogy az Arista alapítója tervezte a Catalyst 6500-ast? És tudtad, hogy az EoS (Arista oprendszere) kísértetiesen hasonlít az ios-re? Én például megtaláltam benne ugyanazt a bug-ot No meg, hogy peren kívüli egyezséggel kötöttek békét a Cisco-val?
Ennyit arról mennyire van távol a Catalst világa a DC-től.
"Egy on-prem DCben elég komoly lehet a kapacitás kihasználatlanság, ami a cloudról nem mondható el." Ez blődség egy DC-ben függetlenül attól, hogy on premise, vagy cloud a kihasználtság attól függ milyen és mennyi task-ot, VM-t, container-t...futtatsz rajta.
Ha már építettél DC-t, vagy foglalkoztál kicsit mélyebben a kérdéssel, akkor tudod, hogy egy C környezetben a skálázhatóság korlátja, nem a szerverek száma, a memória, a storage kapacitás... hanem leginkább a hely és utána rögtön a hálózati átviteli képessége. A hagyományos hardverek (CPU, RAM...) sebessége, mérete évről évre jelentősen nő ahhoz képest, hogy a hálózatok átviteli képessége hogy alakul, különös tekintettel az internetre.
Kicserélni az összes szervert egy olyanra, ami 20%-al gyorsabb, vagy több memória bankolható bele simán megérheti, ha azt nézed, hogy mennyibe kerül egy DC kibővítése (építészetileg, tápellátásilag, klimatizálással, kezelt levegővel...). Ez a fizkai bővítés ráadásul a "zöldmezős" beruházásoknál lehet pálya, mert egy város központban lévő DC bővítéséhez nem tudod lebontani a szomszéd háztömböt. A Microsoft például ezért (is) kísérletez tengerbe merített DC-kkel.
Viszont én úgy látom, hogy nálad sem a szakmailag kiveséztük a témát a többi dologra meg annyit tudok mondani, hogy "a kutya ugat a karaván halad". -
soma314
tag
válasz
kenwood
#15710
üzenetére
Az a baj, hogy ez már megint inkább dezinformáció, mint információ. A térképen ugyanis Európa azért "zsúfolt", mert a terveket / vágyakat is tartalmazza. Ezzel szemben a rideg valóság. Európában elérhető, meglévő Azure központok: Írország, Hollandia, Norvégia, Németország, Anglia, Franciaország, Svájc
https://azure.microsoft.com/hu-hu/global-infrastructure/geographies/Az AWS: Írország, Anglia, Svédország, Franciaország, Németország, Olaszország
https://aws.amazon.com/about-aws/global-infrastructure/Google: Anglia, Belgium, Hollandia, Németország, Svájc, Finnország
https://cloud.google.com/about/locationsmindegyiknél a legközelebbi talán Németország ide, és mi még "szerencsések" vagyunk.
És ezen elérhető helyszínek jelentős része nem üzemel 2 éve. Tehát biztosan "jól ki van próbálva" és érdemes beleugrani béta tesztelőnek! -
soma314
tag
válasz
suomalainen
#15708
üzenetére
"Ez ugyanúgy igaz a cloud elérés esetében is. Becsattanhatsz bérelt vonalon is saját tűzfallal. Igy a latency probléma a cloud esetében meg is oldódott."
Ez sajnos nem így van. A DMVPN, vagy "bérelt vonal" vagy akármi, ami a te saját telephelyeidet köti össze, azok általában nem olyan nagy földrajzi távolságok, leginkább néhány 100 km. Egy felhőszolgáltatás meg akár lehet egy másik kontinensen.
Amíg magadnak rendelsz "bérelt vonalat" két vagy több telephely között, addig általában egy szolgáltatón megy keresztül egy-egy vonal. Hány szolgáltatóval kell szerződnöd egy másik kontinensen lévő felhőszolgáltatás elérésére. No meg hogyan máred, hogy betartják-e az SLA-kat? Az rendben, hogy látod, hogy a végeredmény nem fogja kiadni a szerződések együttes tartalmát, de mégis melyik szolgáltatónál reklamálj?
Arról nem is beszélve, hogy a "csőnek" az egyik vége lesz csak nálad, ha "becsattansz egy bérelsz vonallal a felhőszolgáltatóhoz. Ez popszakma meg olyan, hogy attól, hogy odafele jó a latency, jitter, svászélesség, attól még visszafele simán lehet rossz.
Technikai kérdés, de csak gondolj bele egy szolgáltató saját hálózatán át tudja vinni CE-től CE-ig mpls-en integrated service QoS-el a packet-jeidet, míg, ha szolgáltatókat váltasz, annyiszor lesz egy-egy PE-CE-PE (provider-edge, customer edge) .
A másik lényegi dolog, hogy ha a P2P vagy P2MP tunnel, amit te kértél egy szolgáltatótól az a te DC-den az általad ismert sávszélességgel csatlakozik az internetre és te állítod be ki, mely tunnel-ek tudják azokat használni és milyen esetleges QoS policy-val kit milyen mértékben korlátozol. Ezzel szemben egy felhőszolgáltató internetkapcsolatára nincs ráhatásod. Nyilvánvalóan piszkos anyagi okból oversubscibing van ott is. Egy tranziens terhelés esetén elég jó eséllyel megsínyli valakinek a szolgáltatása."Arra céloztam, hogy én azt állítottam, hogy az ACI régen a cloud irány része volt. Se többet, se kevesebbet."
Egészen pontosan ezt írtad:
" Amit a Cisco cloudnak nevezett, az gyakorlatilag az ACI volt (ma a DC irány része)."
Egyébként szerintem az ACI a DC vonal része volt és annak a része ma is."Ez igy is van, de a gyakorlatban mégis a neten keresztül csattanunk fel egy szerverre."
Már aki és már amihez. Nem csak SOHO-ból áll a világ. Léteznek komoly üzleti, ipari, katonai hálózatok is."A cloud nem úgy épül fel, hogy van egy ajtaja valahol a világban, bemész rajta meg kijössz. Az Azurenak pl rengeteg DC-je van és simán megoldható, hogy egy szolgáltatást Nyugat-Európába telepíted, de keleten van a redundáns DC-ben a backup."
És hogy megy át? És, ha vavária volt, és teszem azt a semmiből kell felépítened egy harmadik szolgáltatónál, mert az Azure-ban már nem bízol, akkor hogy kapod meg? Küldenek egy fél teherautónyí HDD-t, amit aztán upload-olsz?
Az egész felhő, de akár a hybrid technológia egyik Achiles sarka, hogy az igazán fontos dolgokhoz neked egy adatbázisra van szükséged minimum két példányban. (Ez nem a backup mielőtt ebbe valaki beleköt!) Ha az egyik kiesik, a másikról hitless menjen minden tovább. A baj ott kezdődik, hogy ehhez nagy sávszélesség és kis latency kell. Meg lehet csinálni mindezt Azurban úgy, hogy van egy ilyan "kettőzött" storage-on Berlinben, meg Hongkong-ban is, de azt nem lehet, hogy Berlin és Hongkong között legyen megosztva a storage kettőzése. Ennek az lesz a hatása, hogy amíg te azt hiszed, hogy ugyanaz van Berlinben és Hongkongban, addig a két helyszín időről időre szinkronizálja egymást. Tehát a két adatbázis a két helyszínen soha nem lesz azonos!
Ehhez jön a backup kérdés. Ugya azért van redundancia, hogy a folyamatos üzemet fenntartsuk. A backup másra szolgál. A példánál maradva: Berlinben egy ransomware tönkre teszi az adatbázist és mire észreveszed, addigra Hongkongba is átjutott a szinkronizálással a vírus. Na ilyenkor kellene elővenni azt a backup-ot, ami még garantáltan nem vírusos. Update-elni az IPS-t az őj víris szignatúrájával, majd a semmiről újradeployolni mindent a backup használatával. Ezt egy DC-ban meg lehet tenni. A felhőben is, csak ott kell lennie helyben hozzá a know-how-unak (a te szolgáltatásodhoz!) a backupnak...Na és valószínű ha egy új 0day sérülés érintett, akkor nem te voltál az egyetlen, aki így járt, ezért írtam, hogy te leszel az 1024-dik, akit helyreállítanak."Ez nem úgy működik, hogy "feltörték a cloudot" és szaladgál mindenki, mint pók a falon. Hogy a te dolgaid biztonságban legyenek te felelsz, amire rengeteg megoldás létezik. Attól még a másik customer lehet hanyag és feltörhetik a hálózatát, de ez téged semmiben nem fog érinteni."
Jaj, de most komolyan virtualizáció alapfokon: vannak vasak, amin futnak a hypervisor rendszerek (pl VMware, Proxmox, Hyper-V, Zen...). A Felhő azért éri meg, megy a vasakon, nem csak egy-egy cég VM-jai futnak, hanem folyamatosan több cégé. Sőt általában még azt sem lehet mindig előre tudni, hogy X cégé mindig csak Y, vagy Z gép virtuális gépeivel osztozkodik az adott vason, mert a VM-ek terheléstől függően a hypervisor clusterben szépen mászkálnak. Amikor egy VM-et "feltörnek", akkor azt azért is tehetik, hogy egy másik VM-hez férjenek hozzá a hypervisor-on futó virtuális hálózaton keresztül, de akár azért is, hogy a guest VM-en keresztül érjék el a host-ot, vagyik a hypervisor-t futtató vasat magát.
Persze van elvileg minden: mikroszegmentáció, meg a vas erőforrásainak korlátozása..., de mégis van minderre mód és történnek "feltörések". Ha az ember már nem kamasz, akkor ezt nem úgy képzeli el, mint a tévében, ahol a hacker egy szobából because he can alapon érzékeny adatokat lopkod, vagy éppen tölt fel, hanem esetleg már látott olyat, amikor bot-ok 10 ezreiről indítanak DDoS támadást, amitől a VM-ek memóriája, a prociterhelése túlnő azon amit a vas bír. Mert igen itt is van oversubscription: attól, hogy eladnak egy serverre 10x64 Giga RAM-nyi VM-et, attól még nem a serverben 640 Giga RAM, csak lehet 320. És akkor még nem beszéltem a containerizációról, ahol ez még akár sokkal rosszabb lehet. Hát hogy az mennyire felhő (IaaS) vagy inkább SaaS azt már nem is tudom pontosan eldönteni így hirtelen.
És igen te leszel a saját adataidért felelős, de nem lesz backup-od, nem lesz személyzeted hiszen elküldted az felhős outsource-ing miatt.
Engem nem zavar ez a tendencia, mert munkám lesz legrosszabb esetben felhő szolgáltatóknál, sokkal valószínűbb, hogy a felhő szolgáltatásban már csalódott cégeknél. A tendencia és a "felhő" ismeret nélküli imádata pont azokra a kollégákra "veszélyes" akik most SOHO szektorban dolgoznak. Elnézést, de egy batanított majom is tud egy Meraki-t beüzemelni egy fagyizóba, de egy DC-hez, nagyvállalati környezethez, felhőszolgáltatáshoz már kecskepásztor kell. -
soma314
tag
Nem akarom a vitát szítani, mert szerintem sokan akik idetévednek egyrészt nem ezt akarják olvasni, másrészt félő, hogy valaki végképp félre érti.
Ami lényeg: a felhő van, nagyon sok esetben az a jobb megoldás és a jövőben terjedni fog.Ugyanakkor az on premise DC mellé még egy nyomós műszaki érv: a helyi server farmot a lan oldalról sokszorta nagyobb sávszélességgel és saját QoS szabályokkal éred el és már alaposan kibeszéltük sokszorta alacsonyabb latency-vel éred el, mint az interneten keresztül egy távoli server farm-ot (felhőt).
Ne keverjünk fogalmakat kérem: az SD-WAN és úgy általában az SDN és a Cloud Computing két külön fogalomkör. Az egyik nem feltétele a másiknak. Az a közös bennük, hogy mindkettő az elmúlt években divatossá vált buzzword-ök. Na és mind a kettő létezett régen is, legfeljebb nem így hívták. Legalább a szakmában ne dőljünk be 1:1-ben a marketing szövegeknek!
-
soma314
tag
válasz
suomalainen
#15697
üzenetére
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.
-
soma314
tag
válasz
suomalainen
#15695
üzenetére
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.
-
soma314
tag
válasz
suomalainen
#15691
üzenetére
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! -
soma314
tag
válasz
SnoopDoggOG
#15684
üzenetére
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.
-
soma314
tag
válasz
Cyber_Bird
#15657
üzenetére
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. -
soma314
tag
válasz
kenwood
#15656
üzenetére
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.
-
soma314
tag
É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?
-
soma314
tag
válasz
gadam1
#15632
üzenetére
szerintem én is hasonlóan gondolom. Csupán arra szerettem volna rámutatni, hogy attól, hogy valaki x évet eltölt üzemeltetésben még nem jelenti azt, hogy széles körű tapasztalata lenne. Azt lehet feltételezni, hogy amit üzemeltetett azt mélységében ismeri, de nem üzemeltethet valaki "mindent".
Ha nem is leszek népszerű a véleményemmel, de továbbra is kitartok amellett, hogy egy rendszer beüzemelése jelenti a legváltozatosabb tshoot tapasztalatot, mert ott minden lehet: layer 1-től 7-ig. Semmire nem mondhatod azt, hogy ezt feltételezem, hogy jól van konfigurálva, mert eddig ment. Lehet a lefektetett optika is hibás, vagy az újonnan használatba venni kívánt switch/router szoftvere bug-os. Mert egy új rendszernél jellemzően olyan eszközt telepítenek, ami új típusként is, ezért kevés vele a tapasztalat.
Ha egy üzemelő rendszerben jönnek ki hibák, anélkül, hogy valami elromlana, akkor az az én szememben a hiányos commissioning/testing fázis sara és nem üzemeltetési feladata lenne azt kiegyengetni egy tökéletes világban.Abban is igazatok van, hogy van aki úgy üzemeltető, hogy 30 rendszert üzemeltet és akkor foglalkozik egyikkel másikkal, amikor azzal baj van, fejlesztik, migrálnak... Ez utóbbi két kategória nálam (de lehet rossz a fejemben kialakult kép) már nem klasszikus üzemeltetői feladat, hanem pont olyan, amikor egy cég külső szakcéget von be a fejlesztés megtervezésére, levezénylésére.
A másik végletet írtam le, amikor egy jól megtervezett, jól beüzemelt rendszert üzemeltet valaki. Persze akkor lehet ideje képezni magát, de akkor nem attól lesz később jó tervező, mert üzemeltetett, hanem mert képezte magát.
A CCIE RS tshoot labor INE video-iban rendszeresen visszatérő motívum, hogy a vizsga nem a "best practice"-ról szól, hanem a workaround-ról. Ahogy sokszor az élet is.
Nálam viszont a jó tervező olyan, ami törekszik a best practice-ok követésére (akár alkotására) nyilván a rendelkezésre álló keretek között. És apropó keretek: szerintem nem az a jó tervező, aki műszakilag a lehető legjobban tervezi meg, hanem az, aki a rendelkezésre álló anyagi forrásokba beférve tervezi meg a lehető legjobb rendszert.
Egy tervezőnél szerintem az is fontos, hogy jól (értsd használható módon) dokumentáljon. Ne az üzemeltető személyzetnek kelljen feltérképezni a hálózat topológiáját, hogy mit hova kell dugni.... Ez aprólékos és babra munka, de szerintem a tervezés része az, hogy egy jó LLD-ből bárki (szakma beli) meg tudja építeni a rendszert. -
soma314
tag
válasz
olloczky
#15625
üzenetére
Érdekes dolog ez a hálózatok esetén.
Csak gondoljuk végig kicsit:
Van valaki 5 éves üzemeltetői gyakorlattal, aki egy cégnél dolgozott folyamatosan. 5 év alatt ugyanazt a rendszert üzemeltette. Amikor odament már működött. Ott kezdett juniorként. Miket bíztak rá?
Mondjuk troublshooting-ot? Abból a rutint. Mondjuk csinálgatta a shutdown no shutdownt psec errordisable portoknál. Ha valami nagyobb gebasz volt, akkor azt valamelyik senior kolléga simogatta ki.
Maintenance window-kban access eszközöket cserélgetett, firmware update-elt.Követte a szervezeti változásokat vlan-ek konfigurációjával. Mondjuk volt egy dinamikus routing protokol, amit használtak például OSPFv2 single area-ban, esetleg némi site to site VPN. A saját topológiájukat álmából felébresztve fel tudta rajzolni.
Jellemzően az IPv6 is csak "zavaró" tényezőként volt jelen (mint lehetséges biztonsági rés), ha egyáltalán kezdtek vele valamit.
Az 5 év végére ismerte minden egyes használt switch típusának minden firmware verziónak minden bug-ját. Tudta a saját esign-juknak, topológiájuknak minden buktatóját.Viszont
- ha alapvetően új dolog, számottevő dolog történt a cégnél, például változtattak a topológián, cserélték a core switch-eket, átáltak egy másik routing protokol használatára ... akkor azt olyan külső cégre bízták, akik rendszeresen ilyennel foglalkoznak. Az üzemeltetők mindezt a folyamatot nagyban segítik a "helyismerettel" de alapvetően a know how-t egy külső cég hozza, az ő felelősségük lesz a migráció sikeressége.
Az üzemeltető 5 év gyakorlattal, mennyit fog tudni mondjuk a többi routing protokolról, a BGP-ről, mpls-ről, IPv6-ról...csak szigorúan az RS témakörén belül maradva?
Persze üzemeltetőként rengeteg minden nem RS témát is csinált, mert ritka az a cég, ahol külon DC-s, security-s, wifi-s személyzet van!Aki már épített komplex hálózatot akár otthon laborban az megtapasztalhatja, hogy a legtöbb troubleshooting a hálózat "felélesztése" során jön elő. Ha már egyszer beüzemelted, akkor már nem igazán hozhat újat (persze a valóságban a dolgok elromlanak, bug-osak...).
Ezzel nem lebecsülni akarom az üzemeltetéssel megszerzett tudást, tapasztalatot csak rávilágítani, hogy nem feltétlenül azonos "skill set"-et szed össze, 5 év gyakorlattal az aki egy rendszert üzemeltetett folyamatosan és mondjuk az aki 5 év alatt x rendszert telepített, migrált....
-
soma314
tag
válasz
suomalainen
#15617
üzenetére
Valóban "enyém" a reread-es story. Szóval engem nem kell meggyőzni mennyire lehet bug-os az IOU, mennyire lehet bízni a script-es javításban.
Annyiban izgalmas a dolog, hogy reread-et csak akkor kérhetsz, ha reread nélküli eredményed is közel van a sikerhez. 1000 dolcsi, amit csak akkor kapsz vissza, ha eredményes a reread (vagyis sikeres a vizsgád). Szóval nem kevés kockázat.
De pont ez is afelé mutat, hogy a vizsga letétele nem kevés áldozatot kíván (és ebből szerintem az anyagi a legkisebb áldozat) ezért sem értem a "kecskepásztoros" kijelentésed. -
soma314
tag
válasz
FecoGee
#15611
üzenetére
A 2.-3. próbálkozást, mint átlagot én évekkel korábban hallottam, olvastam, 2019 őszétől az új változat miatt besűrűsödtek a vizsga próbálkozások. Lehet úgy volt, hogy abban az időszakban minden 7. vizsgázónak volt sikeres a laborvizsgája. Most nem találom meg hol olvastam, és az is lehet, hogy rosszul emlékszem.
Arra viszont biztosan emlékszem, hogy kétféleképpen is számolják az egyikbe beleszámolják a "no show"-kat, a másikba nem.
Amikor először mentem laborra, akkor úgy voltam egyedüli vizsgázó, hogy papíron voltak mások is, csak nem jelentek meg a vizsgán. Ők a "no show" kategória.
Az elméleti vizsga úgy volt érvényes 3 évre, ha 18 hónapon belül megkezded az első labor vizsga próbálkozást és utána 12 hónapon belül a következőt. Feltételezem azért jelentkeztek be vizsgára és fizették ki a vizsgadíjat, hogy bent maradjanak az időben. Ettől ugye nem lesz nehezebb a vizsga, de feltételezhetően azért nem mentek el, mert nem tartottak ott a felkészülésben, hogy esélyt láttak volna á. -
soma314
tag
válasz
suomalainen
#15605
üzenetére
"felesleges belemenni abba, hogy kell CCIE labig eljutni, részben mert a written nekem is meglett anno, másrészt azzal is tisztában vagyok, hogy mit várnak el egy laborvizsgán."
Akkor te ráléptél arra az útra, amin én végigmentem, ezért nem lehetsz tisztában mit jelent megcsinálni a labot, csak addig tudod, hogy eljuthattál volna egy laborjelentkezésig.
Nagyon sajnálom, mert nyilván sokkal többet tanultál, mint egy CCNP, de az elméletire nem ad ott a Cisco címet.
Akármilyen nehéz is volt a beugró elméleti vizsga, hidd el az még nagyon az eleje volt a CCIE megszerzéséig. Ez volt legalábbis az én tapasztalatom, de eddig nem találkoztam olyannal, aki megcáfolt volna.Eljutni a labig eddig volt nehezebb, az új rendszerben könnyebb.
Én szerencsés voltam és végig a v5-re készültem, vizsgáztam. Annyit tudok a v4-ről hogy keményen volt benne framerelay, ami általában nem az emberek szíve csücske. A v5-ben már nem volt. Ha ezt vesszük akkor ez egy elég jelentős különbség. Akkor a v5-ös könnyebb lett, mint a v4-es?!
Az elméleti vizsgával jártam úgy, hogy bekerültek az "evolving technologies" címmel az SDN, Cloud, IoT. Nem örültem neki, de ha megcsináltad az emléletit, akkor tudod, hogy nem az volt a meghatározó.
Szerintem az új vizsgán is leginkább a CLI-ben maradnak majd a jelöltek. De el tudok képzelni némi TCLshell-t, ansible-t, esetleg a diagnál valami Cisco termék kimenetét.Jól tudhatod, mert én 2019 nov előtt vizsgáztam és az én számom 63-assal kezdődik. Azt írtam, hogy a ccie hall of fame utolsó frissítésének a száma 57k, ami 2017 nov-i adat azt akartam írni, hogy a két száma kiadása között nincs 2 év különbség, de látom 2000-et írtam. (Korán volt, elnézést.)
Na most 2019 nov és 2017 nov kb 2 év és kb 6k a különbség a két szám között. Erre mondtam, hogy évi 3k.Az, hogy egy vizsga ciklus alatt mindez nem egyenletes, az teljesen természetes. Néhány évente változtatják, amikor kijön az új még csak könyv sincs hozzá, nem hogy felkészítő VoD anyagok, bootcamp-ek...Amikor meg bejelentik az új rendszert, akkor aki teheti és esélyt érez az még elmegy a korábbira.
Én másodszorra mentem át, az első alkalommal egyedül ültem a laborban a két proktorral. A második alkalommal tele volt. Egy év telt el köztük és a második alkalomnál már lehetett tudni, hogy jön az új rendszer 4 hónapon belül. (A Covid ezt kicsit felülírta, de akkor még nem létezett.)
Szóval egy olyan statisztikát néznék meg, hogy hányan próbáltak az adott időszakban vizsgázni és abból hányan mentek át!A Cisco nem ad ki részletes információkat a vizsgád eredményeiről. Pl százalékos értékelést, sőt olvastam olyat is hivatalos forumon, hogy adott labor variációnként más-más lehet az elvárt konfig / diag arány, mert úgy fair. Vannak nehezebb és könnyebb laborok, diag kérdéssorok. Ezért simán el tudom azt is képzelni, hogy ha "mindenki megbukik" akkor a Cisco visszavesz a megkívánt eredményből, könnyíti a labort...
Ezért sem mondhatod azt, hogy az egyik verzió nehezebb, mint a másik (v4, v5, v6...) mert fogalmad sincs mit kell rajtuk elérni. Az új labornál meg gyakorlatilag még senkinek sincs semmi tapasztalata.Én is találkoztam a vizsgán olyan személlyel, aki elmondása szerint hetedik alkalommal van ott. Ránézésre, angol kiejtésre indiai származású lehetett. Persze le lehet "kecskepásztorozni", de egyrészt ez elég rasszista, mert valahol olvastam, a hogy a 7. az átlag a sikeres labor vizsgából!
Persze biztosan hirdetnek indai, kínai csoda "tanfolyamokat", amivel garantálják neked, hogy átmész, de szerintem ahhoz is érteni kell (CCNP szintnél jobban) a témához és/vagy fotógrafikus memóriával kell rendelkezni.
Én ezzel kapcsolatban egy rémtörténetre emlékszem, ami a CCDE-ket érintette néhány éve. Bizony a Cisco rámozdult és veszélybe kerültek a megszerzett CCDE-k.
CCDE-ről nem sokat tudok, de annál még inkább el tudok képzelni dump-olást a dolog tervezési jellegéből adódóan.A számok beszélnek kb 150e emberre juthat 1db CCIE/CCDE, ami mondjuk Hazánkra vetítve úgy 60-70 ember? Hát ez egy rohadt híg társaság lehet.
Egy költői kérdés:
Na most mi a valószínűbb, hogy valaki dollár tízezreket költ egy "kecskepásztor" fotografikus memóriával azért, hogy egy őt meg nem illető szakmai tanúsítványt szerezzen, amivel aztán egy rövid, de zuhanó karrierbe kezdhet tudás nélkül. Ahelyett, hogy végigjárná a casinokat és blackjack-en számolná a lapokat (könnyebb is elsajátítani) vagy az a valószínűbb, hogy azok, akiknek nincs (még) meg a CCIE azok irigységből igyekeznek degradálni azt!
Mindenki válaszolja meg magának. -
soma314
tag
válasz
suomalainen
#15591
üzenetére
"kecskepásztorként" én is had kérjem ki magamnak ezt a kijelentésedet. Sőt én nem is vagyok annyira toleráns, mint Feco!
Szóval kezdjük abban amiben van valami igazság:
-az új CCIS Enterprise Infrastructure és a "régi" (végül is már vagy1 hónapja nem lehet ebből vizsgázni) CCIE RS között az a lényegi különbség, hogy a laborba is bekerültek automatizálási / SDN témák. Hogy mindez a gyakorlatban mit jelent azt nem tudom. És úgy globálban szerintem nem sokan tudják a világon, mert február óta lehetne az új laborból vizsgázni (és ugye a régiből a Covid miatt ha jól tudom augusztusig lehetett?)
- ha régebb óta megy egy vizsgarendszer, akkor arról több információ juthat ki, mint ami most kezdődik, ami egyes "kecskepásztoroknak" elméletileg megkönnyítheti a vizsgátDE
- a CCIE RS-hez a beugró az elméleti vizsga volt, ami nem adott semmilyen címet és elég drága is volt. Persze ezt is lehetett elméletileg dump-olni, de már ittis más volt a lépték. Míg egy CCNA-n ha jól emlékszem 1,5-2 órás vizsgán volt 50-60 CCNA szintű kérdés, addig a CCIE elméletin 100 CCIE szintű. Ráadásul, ha valaki szétnézett a neten fellelhető "gyakorló" kérdésekből, akkor is kb 5-6-szoros volt az adatbázis, amiből dumpolni kellett.
A CCNA RS-t ráadásul két külön vizsgaként is le lehetett tenni. Nyilván ennek brain dump-olók szempontjából lehetett előnye, mert kisebb volt az egyes vizsgákon található kérdések "adatbázis mérete".
A CCNP RS-hez 3 vizsga kellett, amiből a troubleshooting-ra gyrosan fel lehetett készülni. A switching és routing témák szétszedése pedig megintcsak könnyítette az esetleges dump-olók esélyeit.Minden lehetséges, de a CCIE elméleti vizsgán hidd el összetettebb kérdések voltak. Ha valaki rendelkezik akkora szorgalommal, memóriával szerencsével, hogy azt letegye anélkül, hogy tudja melyik kérdésre miért az a helyes válasz, az azért elég ritka.
Na most a CCIE RS laborvizsga 8 óra és alatta nem unatkozik az ember, sőt a time management az egyik legnagyobb probléma. Kb annyit konfigurálsz, tshootolsz alatta, mint egy cégnél egy átlagos "network engineer" egy év alatt (és most nem viccelek!).
Még ha tudnád is milyen topológiák lesznek, mit kell begépelni melyik eszközbe, akkor sem tűnik olyan egyszerű feladatnak mindezt az "adatbázist" megjegyezni és vizsgakörülmények között visszaadni.
Na most ha az ember józanul belegondol, hogy mi a valószínűbb: az, hogy egy kecskepársztor egy kockázatos vállalkozásba kezd és megpróbálja brain dumping-gal letudni az elméleti és a laborvizsgát, befektetve a vizsgák, az utazás költségét (ami még akkor is több, mint két-három szakág CCNA / NP vizsgáinak költsége) mindezt azért, hogy esetleg egy olyan álláshoz jusson, ahol napok, max hetek alatt kiderül, hogy nem ért hozzá és kirúgják még a próbaidő alatt.
VAGY
az a valószínűbb, hogy egy kecspásztor abból az energiából, pénzből amit egy CCIE dump-olására fektetne, inkább más gyártók és/vagy IT terület vizsgáinak tömegét teszi le dump-olással. A Cisco vizsgáknál is biztosan lehet valamilyen szinten dumpolni, de még mindig a Cisco vizsgáit tartják a legnehezebbeknek valami oknál fogva.Még pár dolog ami megváltozott az új rendszerrel:
- nincs elméleti belépő vizsga az új CCIE-hoz! Ma elég CCNP-hez szükséges CORE vizsga megszerzése. Nem udom milyen az új Enterprise structure core vizsga, lehet, hogy nehezebb, mint az egykodi CCNP Routing és switching vizsga együtt, de én azt feltételezem, hogy könnyebb, mint az egykori CCIE RS elméleti vizsga. Ami pedig a lényeg, hogy nem "öncélú" vizsga, azaz a letételével megszereheted a jelenlegi CCNP minősítést, ami érték. (Régen a CCIE elmélet mint írom nem járt "címmel" csak beugró volt)
- meghosszabbították a CCIE érvényességi idejét, az már nem két év (ami válaszol a "költői" kérdésedre is, miszerint hány CCIE lesz 2 év múlva abból, aki mostanában vizsgázott) hanem 3
- a meghosszabbítás módján is változtattak. Régen CCIE-t csak a CCIE szintű (elméleti vagy labor) vizsgával lehetett meghosszabbítani. Ma már CCNP/Specialist szintűekkel is lehet. Ami egyébként jó dolog, mert arra ösztönzi a CCIE-t, hogy tanuljon más ágakat is.Összegezve: nem reális a scenarió, hogy egy kecskepásztor zeró tudással dump-olással megszerezze a CCIE-t csak azért, hogy bosszantsa a CCNP-ket, mert ugye tudása nem lesz és a való világban "tesznek" a címre magában.
Egy helyen lenne előnye mégpedig, ha egy cég Gold partner akar lenni, de ahhoz nem csak egy és nem csak CCIE szintű dolgozó kell. Nagyobb kedvezmény jár az eladások után. Én azonban nem hinném, hogy egy olyan cég, ahol "kecskepásztorok" nyújtják a támogatást, ott jönnének az eladási számok, de smián tévedhetek.A CCIE verzióváltásnál mindig voltak olyanok, akik elkeseredtek, mert évekig készültek a vizsgára és úgy hozta az élet, hogy megváltozott a vizsga tartalom. Minden tiszteletem azoké, akik akkor sem adták fel, hanem megrázták magukat és megtanulták mindazt az új vizsgával bejött.
Még egy dolog ami puszta metematika, tehát biztoan hazudik
A CCIE Hall of Fame-en ( https://www.cciehof.com/index.html ) a legutolsó CCIE számot 2017-én november 1-én töltötték fel és az értéke 57597. Én tudom a sajátomat, mivel kecsekepásztor vagyok, azt is tudom, hogy kb 2 évre rá vizsgáztam. A két szám között nincs 2000 a különbség, ami azt jelentheti (azt feltételezve, hogy egyesével adják ki, ami koránt sem biztos) hogy évente mintegy 3000 új CCIE lesz a világon, ami azt is jelenti, hogy naponta kevesebb mint 10!
És ebben benne van az összes szakág: RS, DC, Wireless, SP, Collaboration.... sőt a CCDE-k is.Ha azt nézzük, hogy mára a CCIE számok úgy 65-66 ezernél tarthatnak és tudva, hogy az első 1024 volt, sajnos sokan már halottak, vagy nyugdíjasak, lejárt én azt tippelem, hogy kb 50 ezer aktív CCIE/CCDE létezhet a világon, miközben emberből meg lassan 7,6 milliárd lesz.
Megértem, hogy savanyú a szőlő, de ha eddig olyan könnyű volt, akkor miért nem vizsgáztak tömegével? Te miért nem vizsgáztál le?
Szóval én "kecskepásztorként" nagyobb tiszteletet várnék el!
-
soma314
tag
válasz
Ripper17
#15546
üzenetére
Ez kicsit félremagyarázása az IGMP snooping-nak. A lényege az, hogy egy switch-en csak az a végpont kapja meg az adott multicast group forgalmát, amelyikre szükség van, a többit ne terhelje feleslegesen. Nem pedig fordítva azaz nem IGMP snooping jelzi az igényét a "listener"-nek.
Ebben az esetben, ha jól értem a szitut, csak egyetlen "listener" van az IPTV set top box. Nyilván ha lenne több bridge-elt port, akkor a többire felesleges lenne a multicast forgalmat küldenie. (Nyilván nem "minden" multicast-et, mert a link local multicast-re például mindig szükség lehet.)
A "félreérthető rész" itt az, hogy nem a switch (vagy adott esetben az ASA) jelzi a multicast joint a multicast router felé. Keresztül megy rajta, de nem "aktív" szereplője a multicast routing-nak. Másrészt pedig ha ki van kapcsolva az IGMP Snooping, a multicast forgalom akkor is működik, csak egyéb végpontokra is eljut (mintha link local multicast, vagy broadcast lenne).Röviden az IGMP snooping nem szükséges elem ahhoz, hogy működjön a multicast forgalom. L2-es switch funkció és default-ban bekapcsolva szokott lenni.
-
soma314
tag
válasz
Kohinor
#15459
üzenetére
Erre valóban pontos választ nem fogsz kapni. Egyrészt mert az új CCNA-t még kevesen tették le, a régi CCNA-k meg ahogy írod mások voltak. Másrészt nem tudjuk mennyit tudsz, nem tudjuk milyen gyorsan tanulsz.
Én annak idején fél év alatt készültem fel és vizsgáztam le CCNA RS-ből.Had kérdezzek vissza! Miért számít? Ha felkészülsz 3 hónap alatt és úgy érzed tudod, elmész vizsgázni és mondjuk nem sikerül. Akkor látod, hogy kb mennyire nem megy és még mennyit kell tanulnod. Persze a vizsga díj pénz, de az időd is az, sőt!
Amúgy az is elgondolkodtató, hogy az új CCNA önmagában mire elég. Félre ne értsed nem hiszem, hogy könnyebb most CCNA-t letenni, mint x évvel ezelőtt volt egy CCNA RS mondjuk, de akkor a CCNA vizsgák fokuszáltak egy témára (routing and switch, security, wireless, dc...) ezért gyakorlatilag is hasznosítható tudásról adhatott tanúbizonyságot. Ezzel szemben a mostani CCNA "általános" minden témából kell tudni valamit, de kevésbé mély tudást jelent. Ezért, ha az igazi kérdés a mostani rendszerben szerintem az lehet, hogy egy adott konkrét specialist vizsgát mennyi idő alatt lehet megszerezni, mert szerintem az jelent piacképes tudást. A CCNA egy jó első lépcső ehhez.
-
soma314
tag
válasz
kenwood
#15448
üzenetére
Egyrészt angol tudás nélkül is lehet braindump-olni. Egy VOD anyagot annyiszor játszol vissza, amennyiszer akarsz, amíg meg nem érted. Ez más kategória, mint egy online meeting-en élőben követni miről van szó.
Másrészt tegyük fel, hogy valóban képes valaki megérteni a hallott angol szöveget, de megszólalni, megfogalmazni írásban egy problémát nem tud. Nálam ez csak passzív nyelvtudás. Az első alkalommal, amikor egy külföldivel kell együtt dolgoznia, mert mondjuk egy hibajegyet akar nyitni, akkor elvérzik. Hidd el senki se keres ilyen munkatársat.Hát az én tapasztalatom az, hogy nincs külön "layer 1-es" osztály. Képzeld el a szitut, hogy van egy szerverszobád egy campus-ban valahol. Egy másik a másik végén. Mindkét szerver szobában van egy-egy optikai rendező, ahol látszik, hogy vannak még használaton kívüli sötét szálak. A két szerverszoba között ki kell építeni egy adott sebességű linket. Ehhez ki kell választani milyen SFP/SFP+/QSFP modulokat vetetsz az eszközökbe. Azokhoz milyen lengő kábellel fogsz csatlakozni az optikai rendező és az SFP modulok között.
Ahhoz, hogy ténylegesen tudd, hogy mit mivel kötsz össze nem árt, ha tudsz cérnarajzot olvasni (nem rakéta tudomány, de ehhez is érteni kell). Az sem baj, ha tudod, hogy "hány km"-es SFp-ket vegyél. Ha "boltba" rendelsz optikai lengő kábelt, akkor kell tudni, hogy az egyik végén kék/zöld OPC/APC csatlakozó legyen és abból is milyen, míg az SFP oldalán szintén kell tudni milyen (majdnem mindig LC manapság, de vannak hálózati eszközök, amik mást pl SC konnektort használnak).
De mondhatnál a hibakeresést is. Nem megy egy link. A megrendelőt nem érdekli, higy te csak layer 2 felett szeretsz "hibaelhárítani", hanem az érdekli, hogy működjön. Bemész valahova és látod, hogy a zöldba van dugva a kék, vagy narancs színű az optikai patch kábel, amivel bedugták a 20 km-es SFP-t. Neked kell tudni észrevenni ezeket és elmondani, hogy ez miért nem jó! Mert te vagy a hálózati szakember.
Ettől még nem fogsz az optikai száll telepítéshez érteni. Fogalmad se lesz a passzív optikai hálózatokról, nem fogsz tudni szálat hegeszteni, OTDR műszert használni...Ezeket én sem tudom, de kb szót tudok érteni azzal, aki tud.Az a baj, hogy lehet megbántalak ezzel (és nem áll szándékomban), de a legjobb példa, hogy a hozzászólásodban az ahogy egyes kifejezéseket, mint devops, vagy WDM használsz anélkül, hogy a valódi jelentésükkel tisztában lennél.
Egy klíma rendszert egy épületgépész fog tervezni. Neki viszont ehhez szükség van inputokra. Ki mondja meg a hálózati eszközök hőtermelését, ha nem a hálózati mérnök, aki kiválasztja őket? Hasonló a helyzet az épületvillamossággal, annyival megspékelve, hogy legtöbbször ugye szünetmentes tápellátásra is szükség van. Az allulképzett rögvalóságban születnek aztán olyan adatok, hogy az épületgépésznek megadják a hálózati eszközök maximális felvett teljesítményét, abból kiindulva, hogy az úgyis hővé alakul. Ami majdnem igaz, de egyrészt régen rossz, ha egy hálózati eszköz (pláne redundáns táppal) a maximális beépített teljesítményt fel is veszi, másrészt nem minden villamos teljesítmény alakul hővé helyben. Ott van például a POE.
Ehhez megint elég, ha valaki jól olvassa a Cisco dokumentációkat, de tudni kell mit keres az ember.
Az se baj, ha egy megrendelőhöz (kifejezetten SMB szinten gyakori probléma) olyan eszközpark kerül, ami egyenként bedugva szépen működik az elektromos hálózatról, aztán jön egy áramszünet és az áramszünet végén, amikor "visszajön az áram" a megszakítók mindig lekapcsolnak. Ehhez se kell villamosmérnöknek lenni, hogy az ember tudja, hogy a számítógépekben, router-ekben, switch-ekben lévő kapcsoló üzemű tápok hogy működnek. Vagy legalább annyit, hogy egy "lemerült" kapcsoló üzemű táp, amikor visszakapcsolod, az nagy áramfelvétellel jár. A gyakorlati szinten itt annyi történik, hogy habzó szájjal követeli a megrendelő a switch/router cseréjét, mert a villanyszerelő szerint zárlatos. Holott annyit kéne csinálni, hogy egyenként kellene az eszközöket visszadugni a konnektorba. Ahol van UPS rendszer ott szerencséd van, mert az UPS-est fogják hívni .A WDM a wavelength division multiplexing egy optikai technológia, ami ma már a elég sok SFP modulban is működik. Nem külön multiplexer egységekben van ilyen ma már csak. Egyébként ilyesmivel is összefuthatzs (én futottam) és tudni kell elhelyezni a hálózatban. Én olyannal még nem találkoztam, hogy bérelték volna akár a multiplexert, akár SFP modulokat, de olyannal igen, amikor egy kollega nem értette, hogy hogy lehet egyetlen optikai szálon (nem szálpáron!) duplex kapcsolatot létesíteni bidirekcionális WDM-mel. Ez megint felületes tudás, hogy tudd, hogy ilyen van és tudd, hogy lehet ilyen SFP modulokat is venni (párban kell).
Érdekes, hogy említed a VMware-t, a tűzfalakat. Egy tökéletes világban persze ezekre van külön-külön hozzáértő ember. A hálózat azonban attól hálózat, hogy ezek az eszközök kommunikálnak egymással. A security-ssel például meg kell tudni beszélni, egyezni, hogy hogyan route-olsz a tűzfalával, hogy a tűzfal nat-ol, vagy a router, vagy a tűzfal L2-es módban van és csak "átmegy rajta" minden. Esetleg neked kell zone based firewall-t csinálnod egy router-ből. A mai hálózatok pedig nem érnek véget ott, ahol a fizikai eszközök. A virtuális térben folytatódnak és egy NSX-T (VMware) bizony viszonylag fejlett hálózati funkciókkal bír. Overlay network, distributed firewall... Olyan is van, hogy nem fizikai Cisco eszközt kell telepíteni, hanem egy virtuálisat (nexus1000v, csr1000v...). Olyanba is futhatsz bele (én már futottam) hogy a "szerveres", vagy "storage-os" rád mutogat, hogy a hálózat rossz, mert nála minden rendben, ő kész van. Aztán kiderül, hogy az hitte a jumbo frame-ek átjutnak a campus hálózaton. Ehhez persze nem csak a hálózatosnak, de neki is tudni kell mi az az MTU.
-
soma314
tag
Juniperről én azt gondolom, hogy nem feltétlenül van jövője.
Én szeretem, nekem is van JNCIA-m is, de a piac beárazta. Érdemes összevetni a Cisco-val az elmult 5 év bevételeinek alakulását:
[link]
érdemes kisebb cégekkel is összevetni (a linken Fortinet és Arista):
[link]
A trend látszik a Juniper bevételei 2017-től csökkentek, míg másoké nőttek.A diploma meg nem feltétlenül azt bizonyítod, hogy értesz egy adott szakmához, hanem azt hogy elég értelmes, szorgalmas, céltudatos vagy ahhoz, hogy évekig tartó tanulással megszerezz egyet.
Nekem vannak diplomáim és van CCIE-m is, de nem tudnám megmondani melyiket volt nehezebb megszerezni.
Amúgy, ha műszaki vagy informatikai diplomád van az hálózati mérnökként külön jól jöhet. Egyrészt másokkal dolgozunk együtt, kell tudnunk kommunikálni más it szakemberekkel. Ritka az a hálózat ami csak azért megy, hogy legyen. Azok IT rendszereket szolgálnak ki és jó, ha nagy vonalakban valaki átlátja a rendszert.
Másrészt, a hálózati eszközök telepítéséhez kell kábelezés, kábeltartó szerkezetek, UPS, légkondi, táp és földelési hálózat...Ha építenek egy szerverszobát, amibe hálózati eszközök lesznek, kell egy hálózati mérnök, aki meg fogja tudni, mondani a hálózati eszközöknek mennyi lesz az áramfelvétele, a hődisszipációja, mekkora rack szekrény kell, azokba hogy kell tudni úgy elhelyezni, hogy elérjen a kábelezés....
Nem rakéta tudomány, de egy mérnök ezekkel a feladatokkal könnyebben megbirkózik.Amúgy a CCNA/CCNP/CCIE nem szól egy csomó dologról, ami műszaki dolog, egy hálózati mérnöknek kell ismernie őket. Pl. optikai kábelek. Mi a különbség a multimodusú és a monomodusú között. Melyiket, hova. A sima duplex, a bidir WDM, a DWDM. Az UPC az APC csatlakozások és azok miért különböznek, mit mivel.
Ez se varázslat és egy érdeklődő ember utána tud olvasni a neten olyan szintre, hogy helyre tudja tenni, de ezek megértése megint könnyebb egy mérnöknek szerintem.
A WiFi hullámfizikáját meg se említem.Azon túl van egy csomó adminisztratív feladat. Én se a felsőoktatásban tanultam meg a Visio használatát (nem is volt még akkor
) de műszaki dokumentációk készítése, használata feladat volt. Műszaki rajzok, szabványok....
Aztán nem árt, ha valakinek van némi gazdasági ismerete, ha mondjuk olyan céghez kerül, ahol rendszeresen pályáznak újabb és újabb hálózatépítési tenderek elnyerésére. Ha pedig valaki az üzemeltetési oldalon van, akkor bizony neki kell összeállítani a kiírásokhoz a műszaki tartalmat, vagy ép értékelni az ajánlatokat.Azon túl bár talán már nem kell, de jó ideig kellett egy diplomához nyelvvizsga is. Én simán el tudom képzelni, hogy valaki összehoz egy CCNA-t valódi használható angol tudás nélkül. Itt meg ugye minden szakirodalom angolul van. Meg hát ha reálisan nézzük egy majdnem 10 milliós országban élünk az üzleti életben összefutunk akár vállalkozóként, akár megrendelőként olyan emberrel, aki nem fog tudni magyarul, de beszélni kellene vele.
A HR-es mindezt leírhatná, az interjúkon letesztelhetné, de minek küzdjön vele, ha annyit ír, hogy szakirányú felsőfokú végzettség kell, akkor feltételezheti, hogy aki jelentkezik, az átlagnál, okosabb, szorgalmasabb céltudatosabb, beszél nyelvet és az ismeretei túlnyúlnak a szűk szakmai feladatain. Amíg lesz elég jelentkező így is, addig ezt fogja leírni.
De én azt tanácsolom, azoknak, akik úgy érzik, hogy a tudásuk versenyképez, hogy akár bevan írva feltételként, akár nincs és érdekli az állás, akkor jelentkezzen. Mi történhet?A főnök dolgot én is úgy látom, hogy sokkal több hátránnyal jár, mint előnnyel, ha amúgy megfizetik a munkádat eléggé ahhoz, hogy megélj. Sokan viszont azért akarnak főnökök lenni, hogy nekik legyen kevesebb főnökük. És ez is érthető szempont
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
soma314
tag
válasz
kenwood
#15402
üzenetére
Igen ez is egy megközelítés.
A tanár leadta, ha a diák nem érti, akkor az lusta / hülye/ stb..
Én a saját tapasztalataim alapján (két diplomát szereztem) anno. A legtöbb butaságot tanároktól hallottam és a legtöbbször azért mert "pongyolán" fogalmaztak:
Példák
A háromszög belső szögeinek összege 180 fok - ez csak a képzeletbeli Euklideszi térben igaz, a valóságban ezt már Gauss rég cáfolta. Ha így lenne, akkor a relativitás elmélet matematikai alapjai bomlanának, és az úgy tűnik működik.A folyadékok összenyomhatatlanok, nincs belső surlódásuk - csak az elméleti folyadékokra igaz. Vannak eszközök, amik a folyadékok összenyomhatósága elvén működnek. Ilyen például a batiszkáf.
Az elektromos vezető ellenállása függ a vezető keresztmetszetétől. - ez csak makroszinten igaz. Nanoszinten már más a helyzet.
Három halmazállapot van: szilárd, folyékony, gáz - és a plazmaállapottal mi van?
Matekból a felcserélhető műveletek elvégzési sorrendje tetszőleges, ugyanazt a végeredményt kapod - mi van ha végtelen tört az egyik? hány tizedesértékig fogod számolni? vagy természetes törtté alakítod, akkor már változtattál a műveleti sorrenden, amit elvégzel. A gyakorlatban, meg amikor számítógépek limitált lebegópontos regiszterekkel végzik a műveletet pláne nem mindegy.
Én nem emlékszem, hogy akár általános iskolában, akár a gimiben pár percet is mondott volna a tanár arról, hogy amit el fog mondani, azok nem általános igazságok hanem a Világ leegyszerűsítése, hogy megértsétek. Egyébként szerintem alapvetően rossz a feltételezés, hogy a valóságot nehezebben értenék meg a gyerekek. Hülyének nézi ez az el a diákokat.
A felsőoktatásban már más volt a helyzet. -
soma314
tag
válasz
Alcsi69
#15401
üzenetére
Ha erősáramos is leszel, akkor is bele fogsz futni olyan problémába, hogy a kapcsolószekrények távvezérlése IP alapon megy és egyik kolléga nem jó szubnet mask-et írt be a telepítéskor. A mérnöki tudományokba rengeteg dolgot csak azért tanulunk meg, hogy becsülni tudjuk más szakágak munkáját és ezért szótértsünk, illetve el tudjuk fogadni, az előírásaikat.
-
soma314
tag
válasz
Alcsi69
#15395
üzenetére
Érdekes volt olvasni a feladatot, sok új kifejezéssel találkoztam magyarul
Nem tudom segitség-e neked, de a feladat a variable length subnet mask -ra megy rá- Ha igy keresel rá, akkor találsz angol nyelvű videókat a témában. Ez a fórum nem arra való, hogy részletesen elmagyarázzuk, ezt valóban a tanárnak kellett volna megtenni, az ő védelmében viszont annyit, hogy ez valóban sokaknak nehezen érthető téma.
Én azt javaslom, hogy használj erre egy kalkulátort. Ilyen letölthető a playstore-ból is, de online működőek is vannak (pl http://www.vlsm-calc.net/ ).
Például az első sorban 5 subnetet kell kialakitanod a 192.168.10.0/24-en, ehhez a következőt ird be (csatoltam a képet), amire a szintén csatolt kép eredményét kapod.
Arra figyelj, hogy egy-egy subnetben a gépek száma + 1-re lesz szükséged, ahhoz, hogy route-olni is tudj közöttük. A +1 a router szubnetbe lógó interfészének cime lesz, ami a számitógépeken, mint default gateway kell legyen beállitva. Az "üzenetszórási cim" az a broadcast address.A tanár hozza a szokásos magyar pedagógust, mert a feladat kiirása pongyola, nincs meghatározva, hogy mi a cimtartomány. IPv4-nél még gondolkodhatom classful-ban és önkényesen azt mondtam, hogy 192.168.x.z az /24 lesz, de IPv6-nál nincs ilyen. Sőt a valóságban felesleges is vesződni ilyennel IPv6 esetén /64-es szubneteket használnak ilyenkor.
Marhaság az a megfogalmazás is, hogy a "legnagyobb hatékonyságú megoldás". Nyilván arra gondol, hogy a lehető legkosebb address space-t használjuk el az egyes szubnetekre. Ez az életben azért butaság, mert sokszor kiderül, hogy jó de lesz még itt két eszköz, amikek kell cim. Olyankor borul az egész cimzés. Ezért tartalékot szuktunk képezni. Példa van egy /24-es address space, amibe el kell helyezned 3 szubnetet, amiben 29 - 29 számitógép lesz. Megteheted, hogy olyan szubnetet választasz kettőnek, amiben 32 host cim van, mert elegendő, az utolsónak és még marad is lehetőség további hasolnó méretű szubnetre a jövőben (ugye 256-ból használtunk el 3*32-őt csak, mindhárom belefért volna egy /25-ös address space-be). Ha azonban az egyik szubnetbe kell még egy gépet elhelyezni, akkor minden gépet, router-t át kell cimezni az eredeti /24-es tartományon belül. Ezért inkább a gyakorlatban, ha úgyis megvan a /24-es address space a 3 subnetre, akkor csinálnék egy olyat (/25-őst) amiben 128 host cim van és két olyat (/26-ost) amiben 64 host cim van.Igy ha kell lesznek újabb host cimek. Ha mégis kell újabb szubnet, akkor pedig csak a /25-ös tartományon belül kell mindent újra cimezni.Hogy melyik a hatékonyabb megoldás? Amig nem kell változtatni, addig mindegyik egyformán működik egyik sem használ el több cimet, mint ami erre dedikálva volt (/24). És én abban hiszek, hogy az én megoldásom jövő állóbb lenne.
Az IPv6-nál nincs értelme igy számolni. Ott /64-es szubneteket használunk, még link local-hoz is. Ha abból indulunk ki, amit itt leirtak "address spacenek", ami helyesen 2000:db7:acad:: (a két kettőspont a védén azt jelenti, hogy utána csak 0 jön már) egy /48-as terület. Ebbe 2^16 db /64 subnet fér el. Elég lesz! Ezért én igy csinálnám 2000:db7:acad:0::/64, 2000:db7:acad:1::/64, 2000:db7:acad:2::/64, ....
Gateway elvileg bármilyen cim lehet ami az adott szubnetbe esik. A gyakorlatba az első használható host cimet szokták adni. Ez az IPv6-os példánál maradva 000:db7:acad:0::1/64, 2000:db7:acad:1::1/64, 2000:db7:acad:2::1/64, ....
Ezt kell a router-eken a szubnetbe lógó interfészeken beállitani.Elnézést a billentyűzetemen nincs hossz "i".
-
soma314
tag
válasz
cisco007
#15296
üzenetére
nekem az is furcsa a screenshot-on, hogy van olyan páros, ami duplikált packetnek tűnik (például a 5-6 és a 41-42), de egyrészt más a méretük, másrészt az egyiken van vlan id, a másikon nincs. (Mintha a kisebb méretű nem lenne dot1q-ba "enkapszulálva").
Az oké, hogy ha azt feltételezzük, hogy a 10.4.14.valami a végberendezés (szerver például) és a 10.169.valami.valami jön a hálózati eszköz felől, akkor a végberendezés felöl nincs rajta a vlan 144, de amikor a hálózati eszköz felöl érkezik, akkor mindig ott kellene lennie, vagy mindig nem. Hacsak nem egy trunk portra van kötve a végberendezés és hol a 144-be hol a nativ vlan-be küldi bele a hálózati eszköz.
Az is lehet, hogy fordítva van és a szerverből jön ki tag-gelt frame. Jó lenne megnézni, hogy mi hol van először! -
soma314
tag
válasz
stfreddy
#15262
üzenetére
abszolút át tudom érezni amit mondasz
én is hasonlóképen éreztem az elmúlt hetekben, de csak az előre menekülés maradt
ha évekig küzdesz és rengeteget beletoltál, akkor szerintem érdemes megpróbálni mindentérdekes módon a reread-re azok biztattak, akik engem ismernek , nem a Cisco-t és a CCIE utat. A döntő érv az volt, hogy józanul végiggondoltam: ha nem tudom most megcsinálni, akkor megint egy év vagy évek telnek el mire ilyen közel kerülök a sikerhez. Közben pedig folyton azon fogok agyalni, hogy miért nem mertem megkockáztatni azt az ezer dollárt.
Az IOU/IOL remek dolog. Minimális hardverrel lehet nagyon összetett hálózatokat emulálni vele, aki használta az tudja. A legtöbbet használt funkciók kiforrottak vele, de a CCIE laborban eléggé "csúcsra vannak járatva" funkciót tekintve. Én többektől hallottam, hogy bizony a vizsga alatt újra kellett indtani.
Azt meg sem merem említeni, hogy gyakorlás közben mi lehet a tapasztalat, mert hivatalosan csak a Cisco használhatja. Ezért is dolgozik az INE a CSR1000v-kel, ami hivatalosan is hozzáférhető.
Nem tudom februártól mi lesz a labor környezet, szerintem lehet lecserélik az IOL-t.Tudom nem lehet mindent a Software Defined Everithing szemléletre fogni, de én is úgy látom, hogy a klasszikus hálózati eszköz szemlélet:
- a monolitikus atom stabil oprendszer,
- a nem indítunk újra eszközt, mert akkor ott már nagy baj van,
- ott az eszközön a soros konzol port, mert az mindig működik és mindent látsz rajta
szemlélet leszálló ágban van. Cserében vannak/lesznek jobb(?) API-k, gyorsabb szoftverfrissítések, olcsóbb (?) eszközök.Én azt látom, hogy a Cisco "kapkod". Megjelentek az olcsó (kínai) konkurensek, akinek az eszközei papíron legalábbis tudják a standard funkciókat, amiket leginkább használnak.
A Cisco IOS hagyományosan emberi interfészre épült, mert múltja van. Megjelentek új gyártók (pl Juniper) akik tiszta laprol kezdtek ezért lehetett strukturáltabb a szintaxis. Ráadásul minden eszközön alapban ugyanaz az oprendszer van. Ezek együtt SDN szempontból marha nagy előnynek számítanak.
Abban biztosan lehet üzleti megfontolás, hogy ha csinálsz egy hardvert, amit egyszer jól beüzemelnek és az működik 10-15 évig és nem akarják lecserélni, mert minek? az csak egyszer hoz pénzt. A subscription szemlélet, hogy éves díjat fizetsz és ezért adnak felhő szolgáltatásokat, frissülő szoftvert lehet üzletileg sokkal kifizetődőbb.
A Cisco legnagyobb előnye szerintem három dologban rejlik/rejlett:
1 - a szabványos megoldásokon túlmutató protokolok (eigrp, glbp, DMVPN...) újak kifejlesztése, amiből később lesz szabvány.
Például szeritnem emgkésett a Cisco az EIGRP szabaddá tételével. A világ nagy része elvan az OSPFv2-vel (pedig sokszor az EIGRP, OSPFv3 nem kicsit jobb). Azt ismeri minden eszköz, minden hálózati szakember, ha azzal meg tudják oldani, akkor minek küzdjenek egy új megtanulásával? Az EIGRP már hosszú évek óta szabad lenne, de én csak Nokia eszközökben láttam Cisco-n kívül. Ott sem használták.
Sok esetben pedig SDN-es workaround-al helyettesítik ezeket a protokollokat. Pl SD-WAN performance routing helyett.
Szerintem a Cisco csúcs terméke Enterprise RS világban a DMVPN. Ahogy az amerikaiak mondják, a legjobb dolog a szeletet kenyér óta. Sokáig abban a hitben éltem, hogy hasonló sincs más gyártónál, de azóta megtaláltam a Fortinet ADVPN-t (Auto Discovery VPN) ami gyakorlatilag ugyanaz. Ráadásul mindez tűzfallal, ami ma már sokkal gyakoribb perem eszköz, mint egy router. A Cisco-nak szerintem gyorsan reagálni kell erre és kihozni valami olcsó tűzfalas megoldást, ami legalább a spoke-ok esetében. Nem értek hozzá, de úgy tudom ASA nem alkalmas ilyenre, félek, hogy a firepower-ek sem.2 - A jól dokumentáltság, ismertség. Szerintem sokan azért kezdtünk Cisco-val foglalkozni, mert a legkönnyebb volt hozzá valóban jó oktátási anyagokhoz jutni. Azóta annyi gyártó koppintotta le az IOS-t, hogy gyakorlatilag a Huawei-től, az Arista-n keresztül a HP-ig szinte nem tudod a CLI-ből eldönteni miben vagy. Ez hálózati emberek szempontjából jó, de a Cisco szempontjából nem.
Annak idején otthon emulálni a GNS3-ban csak az IOS image-eket lehetett hatékonyan. És azt sem jogtisztán. A Packertracer szimulátor sem volt ingyenes. A többi eszközt virtuális gépként lehet futtatni, ami a pár évvel ezelőtti hardvereken kihívás volt (nem volt annyi memória egy otthon használt gépben, hogy 3 JunOS-t futtass).
A Cisco ahelyett, hogy ingyenes IOL változatokat dobott volna ki kijött a VIRL-el, ami nem olcsó. Igaz van dcloud, ami ingyenesen használható, de kevesen ismerik és még kevesebben használják. Ezt propagálni kéne. Én a Cisco helyébe külön team-et tartanék fel, akik a dcould-on mutatnának be egyszerűbb dolgokat a nagyközönségnek a YouTube-on.
Ehhez képest a múltkor töltöttem le az Arista EOS-ét egy ingyenes regisztráció után, amit GNS3-ban simán lehet használni.
Ennek az lesz a következménye, hogy a arányaiban kevesebb Cisco kötődésű új szakember lesz. Ehhez jön az SDN "eröltetése". Egy szint felett jó ha megtanulsz programozni....Ha programozni szerettem volna programozónak mentem volna. Oké lenyelem a békát és megtanulom. Mi van ha tetszik? Mi van ha jó leszek benne? És mi van, ha nem hálózati eszközöket akarok majd programozni? Most minden területre keresnek kódfejlesztőket ezért visszanyalhat ez a fagylalt.3 - Talán a legfontosabb a Cisco hírneve. Ez persze az előző kettőből is jön. A hírnév pedig sokat számít azon a jól fizető piacon, ahol a minőség és a megbízhatóság megelőzi az árkérdéseket.Viszont pont ez a piac, ahol nagyon bizalmatlanok is. Nem szeretik a felhő megoldásokat (érthető okokból). Azt szeretik, ha a teljes költség legnagyobb költsége a beruházási költség, amire mondjuk lehet pályázni. Nehéz lesz itt felhő alapú szoftver subsciption-t eladni.
Na most nézzük, hogy mi "elkötelezett" Cisco fan-ok is fanyalgunk. A hírnév mulandó dolog.Persze a kutya ugat, a karaván halad. A Microsoft-ot is szidták amióta ismerem, de mégis elég jól megvan. Igaz ma már több a MAC-es felhasználó és a több a Linux-os is. A változás lassan indul be.
-
soma314
tag
válasz
Cyber_Bird
#15258
üzenetére
Igen így van. IOS on Linux eszközökön fut, gyakorlatilag minden router / switch egy-egy linux alkalmazás. Próbálják biztosan a legkevésbé bug-os verziókat használni, de sajnos azok sem olyan stabilak, mint az igazi hardware.
Az INE gyakorló laborjaiban CSR1000v VM-eket használsz és igazi L3-as switch-eket (3560). Sajnos a CSR1000v-knél is sokszor belefut az ember olyanba, hogy valami nem megy. Vgay nem úgy megy, mint az igazi vason. -
soma314
tag
A laborvizsgádat egy script értékeli ki alap esetben. Nekem már másnak fél ötkor megjött a score report (az emberi munkát ezért is kizárhatjuk).
Sajnos a script-el értékelés nem mindig tökéletes (pl, ha valaki bekapcsolva felejti a debuging-ot az meg tudja állítólag alaposan zavarni). Ugye maga az emulált környezet az IOL image-ek működése sem hibamentes. Nekem is kellett a TS alatt L2-es image-eket újraindítani. Ezt a script nem fogja megtenni.
Ezért ha a vizsgád értékelése nagyon közel volt a sikereshez, akkor "kérheted" a reread-et. Amikor egy hozzáértő proktor is megnézi a dolgot.
Erre a score report kézhezvételétől kapott, ha jól emlékszem 15 napod van kérni. Viszont ezzel 19-re húzol lapot: a reread költsége (RS-nél) további 1000 dollár és csak abban az esetben kaopd vissza, ha a reread eredménye az, hogy fail-ről pass-re változtatja az eredményed.
Nekem okozott pár álmatlan éjszakát, hogy megkérjem-e? Fejben sokszor végigjátszottam mit hogyan konfiguráltam, az jó lehet-e, mit ronthattam el? A score report-ot is próbáltam kielemezni, mert nem kapsz konkrétumokat. Nálam annyit lehetett tudni, hogy a TS passes, a DIAG passed, a konfig nem sikerült a script szerint és %-okat adnak meg L2, L3, VPN, Security, Services technológia bontásban. Kb tudod miből hány feladat volt, de arra már nem emlékszel, hogy melyik hány pontos lehetett. Azt sem tudni mennyi kell, hogy sikerüljön. Állítólag attól függ mennyire nehéz volt az adott konfigurációs / ts / diag labor. Annyit adnak meg, ha jól emlékszem, hogy a minimum érték 50-70% között van.
Én a TS és a DIAG esetében biztos voltam, hogy magas eredményem lett (mint a 10 hibajegy meglett, ellenőrizve), a diagnál "összeállt a puzzle", a konfiguráció 25 alfeladatból áll, amiket egyenként értékelnek vagy megkapod az adott feladatra adható 2-3-4 pontot vagy nem kapsz egyet sem. Én 24-et tudtam befejezni és menet közben tesztelgettem amit lehetett, de az overall végleges tesztre nem volt időm. Viszont a %-os értékelés alapján erős volt a gyanúm arra, hogy az egyik multilayer switch-el érintett több dolog is sikertelenre lett értékelve pedig sikeresen teszteltem. Lehet azt a switch-et kellett volna a script lefuttatása előtt újraindítani.
Ugyanakkor a szigorú értékelés miatt nem lehetsz biztos abban, hogy nem gépeltél el-e mondjuk pl router-id-t, egy named ACL-t, egy vlan nevet, egy crypto map nevet, egy host nevet... amitől még minden remekül megy minden, de a feladat 0 pontot kap, mert követelmény volt, hogy ez vagy az a névkonvenciót tartsad be.
Szóval 1000 dollárt mintha feltennél a lovira egy ismeretlen lóra. Ráadásul a neten mindenfélét lehetett olvasni. Volt ahol azt írták 300:1 a statisztika, de az még abból az időből volt, amikor igazi hardvereken ment a laborvizsga. Általában azt mondják és én is ezt követtem volna, hogy inkább tedd félre a pénzt a következőre, mert ha most olyan közel jártál, hogy felajánlották a reread lehetőségét, akkor a következőre szinte biztos sikerülni fog.
Én is úgy terveztem, hogy még december elején elmegyek újrázni.
Csakhogy február végén változik a rendszer ezért egész egyszerűen nem volt szabad időpont Brüsszelbe, sőt máshova sem. A reread-et pedig csak 15 napig kérheted.
Mondhatni utolsó szalmaszál volt a dolog. (Később lett időpont, és foglaltam is egyet febr 6-re Feltham-be, szerencsére még le is tudtam mondani.)Ja és még annyi, hogy 3 hétig tart mire megtudod mi a reread eredménye. Kétféle lehet vagy PASS lesz a vizsgád vagy marad FAIL, semmi több infót nem kapsz.
-
soma314
tag
októberben, híven a fórum hagyományokhoz, másodikra nekem is meglett a CCIE RS labor is
. Kicsit kalandos volt, mert az értékelő script nem szeretett és reread-et kellett kérnem, aminek az eredményére 3 hetet kellett várni, ezért is csak most írom.
Szeretném megköszönni mindazoknak a fórumtársaknak akik szurkoltak és támogattak/vigasztaltak a tavalyi bukta után. -
soma314
tag
válasz
kenwood
#15210
üzenetére
az IT területen sajnos nekem az a tapasztalatom, hogy szinte mindenki "mérnöknek" nevezi magát
nem lesz valaki mérnök semmilyen céges tanúsítványtól sem (még CCIE-tól sem) sőt több évtizedes tapasztalattól sem. Legfeljebb tiszteletbeli.
Mint ahogy nem lesz senki orvos, ügyvéd, tanár sem attól, ha gyógyít, tanít, vagy éppen jogügyekben képvisel valakit.
Lehet, hogy jobban tanít mint egy tanár, jobban véd mint egy ügyvéd vagy akár jobban gyógyít mint egy orvos.
Ezeknek a hivatásoknak megtartotta magának az állam a tanúsítását egyetemre, főiskolára, ezért is hívják államvizsgának. -
soma314
tag
a 2-14 egy régi módszer arra, hogy bizonyos parancsokat, parancs csoportokat hozzárendelj user-ekhez. Van egy mérnök, aki mondjuk a vlan-okért, spanning tree-ért felel. Neki kell egy account, amivel minden érintett eszközön lekérdezheti állithatja ezeket. Van aki az IGP-kért fele, kell az OSPF, EIGRP... amit használnak. Van aki a BGP-ért....
A parancsokat az érintett eszközökön különböző szintekhez rendeled:
mondjuk 5 a vlan-es kollegák eszközgyűjteménye, ő már nem fér hozzá a routing prancsokhoz egyáltalán, 6 az IGB-seké, nekik kellenek az 5 -ösök parancsai is )hibaelháitáshoz pl.), de nem kell turkálniuk a BGP-ben, 7-es a BGP-sek parancstára...MIndezt template-be kell rendezni és minden eszközön egységesen használni.
Lehet eröltetett a példa, de eröltetett ez a módszer is ezért sem divat már a használata.
Sokkal elegánsabb a parser view, de az is rosszul skálázható.A profi megoldás a AAA szerver második A betűje az authorization. A szerveren az egyes userekhez konkrétan meg lehet adni milyen parancsokat használhatnak. És ezt nem kell eszközönként egyenként csinálni.
-
soma314
tag
Nagy pofám az van, hogy a koponyám az lenne
de ha még senki nem mozdult rá, akkor:
Ami neked kell az nem a privilege level, hanem egy view hozzárendelése egy user account-hoz.
Erősen leegyszerűsítve:
privilege level 0 - no access - csak alap show parancsok, de sh run nem, nincs configuráció privilege level 1 - user mode access
privilege level 15 - privilege mode access - "superuser"
privilege level 2-14 - egyénileg állíthatóMOndjuk megadsz egy USER-t, hogy az AKARKI privilege 5-el jelentkezik be.
Ez nem jelente még semmivel sem többet, mint a privilege 1, de az egyes parancsokat hozzárendelhetet a privilege 5 levelhez:R1(config)#privilege exec level 5 sh run all
Így a show run all-t is ki tudja adni az aki 5-ös levelen vagy feljebb (pl 15-ösön) van.
Ez helyben nem biztos, hogy praktikus, de lehet TACACS+-on keresztül is parancs adatbázisokat fenntartani.
A lényeg, hogy kicsit néhézkes, de ha egy parancsot akarsz pluszban valakinak egy eszközön, akkor járható út.Helyette inkább használatos a parser view, ami re alább egy példa:
R5(config)#parser view ELSO
R5(config-view)#secret ELSO
R5(config-view)#commands exec include all show
R5(config-view)#commands exec include all configure
R5(config-view)#commands configure include all interface
R5(config-view)#commands configure include all ip
R5(config-view)#commands configure include all router
R5(config)#line vty 0 4
R5(config-line)#no privilege level 15
R5(config-line)#login local
R5(config-line)#transport input all
R5(config-line)#exit R5(config)#username USER password PW
R5(config)#username USER view ELSOItt user-hez rendelve van a view, nem pedig a parancshoz van privilege szint rendelve.
A view-t meg sokkal könnyebb configurálni, ha nem egy-egy parancsról, hanem azok csoportjairól van szó. Egy fajta fa struktúrában configurációs parancsok azon bellül mondjuk a router parancsok vagy az interfész ....
Inkább erre keress rá, hogy parser view -
soma314
tag
válasz
kenwood
#15174
üzenetére
Ezen szerintem mindenki átesik. Lapos hálózatok. Az már jó, ha van sok VLAN. Én láttam olyat is, ahol reggel elinditottam a kábelcápát a gépemen és a portástól a vezérigazgatóig végignézhettem volna hogyan kapnak IP cimet a DHCP servertől.
Azért nyomják a fejünkbe az oktató anyagok, hogy ma már az access switch is legyen L3-as ha lehet, mert a mai vasakkal azt lehet igazán jól kezelni routing technikákkal.
De gondolj bele, hogy a könyvben mindig zöld mezős beruházás van, az életben meg sokszor több évtizedes fejlődés során kialakult valami ami tart ahol tart, de legalább te látod már mi lenne a jó irány.A "tűzfalazás" jó esetben külön ember/csoport dolga. Ez azért jó eset, mert ha egy ember/csoport csinálja, akkor a mindenhez is értő szituáció van.
Az alapjai és űgy gondolom, hogy a RS világot megismerve leképződnek. Egy stateless zone base firewall-lá bármikor át lehet alakitani egy router-t. Sőt rádobsz egy NAT-olást és akár már statefull-nak is nevezhetjük.
Persze egy mai tűzfal ennél sokkal többet tud, de a lényege, ahogy nekem mint RS-es laikusnak, lejött az az, hogy ezek az eszközök leginkább egy netről frissülő adatbázisra hagyatkozva szűrik a tartalmat, akár L7-en. Na ezt nem, vagy őrült nehezen lehet router-rel megcsinálni (NBAR-ral lehet kisérletezni, de minek).
A harverekben is más céleszközök vannak. Kb azonos lóereje van egy versenyautónak autónak, meg egy jó traktornak, mégis egész másra valók.
A tűzfalak jobban tundak NAT/PAT cimforditásokat végezni, binding táblákat kezelni, kevésbé terheli le őket. Viszont általában baromi rosszak a dinamikus routing protokol támogatásban. Pl a multkor lepődtem meg, hogy nextgen firewall nem tudott BFD-t.
Egyébként a tűzfal mint egyedi eszköz, ha nem is kihalóban, de fogyóban van. Régen csak az internet felöl érkező forgalomtól féltek oda tettek egy tűzfalat, amin keresztülment az internet forgalom. Ma már egyszerű olcsó eszközökkel, akár véletlenül is lehet újabb és újabb kijárata a hálózatnak az internet felé (elég egy windows 10-es gép egy LTE modem, meg internet megosztás).
Szóval ma már csak nagyon kis része a Security technológiáknak a peremtűzfalak esete. Divatos buzzword a microsegmentáció. Az NSX-T például olyan megoldást használ, ami a végpontok közötti kapcsolatot monitorozza, szűri. Persze nem ismer igazi dinamikus routing protokolt még (bár a gyártó szerint a BGP az)És még nem beszéltünk load balancerekről, a DC világban FiberChannel-t használó SAN switch-ekről.
Nekem minden nap egy pofára esés, hogy minél többet tanulok, annál inkább látom, hogy egyre több dologhoz nem értek -
soma314
tag
ez nagyon találó, de kicsit azt juttatja eszembe, hogy az önvezető autókkal sokkal kevesebb baleset történne(?) mert nem fáradnak, kiszámíthatóan döntenek és szabálykövetőek
a probléma ott van, hogy amíg nem az összes autó önvezető, addig az emberek kiszámíthatatlansága miatt mégis több baleset lenne
és akkor még nem is beszéltünk az úton átfutó (autonóm vezetésű) szarvasról, pláne gyerekről.Valahogy ezzel is így vagyok, hogy remek az automatizáció az emberi hibák megelőzésére, de azok kijavítására alkalmatlan. Nem beszélve arról az esetről, hogy a szabályokat, amit az automatizáció követ emberek hozzák.
-
soma314
tag
válasz
kenwood
#15138
üzenetére
ha egy ember loggol be ssh-n, akkor be tudja írni, hogy reload in 10 és le tudja állítani, ha a config-ot sikeresen módosította.
Ezt még lehet akár autómatizálni is, de a probléma az, hogy ezzel csak az adott eszköz elérését biztosítod, nem pedig a mögöttes eszközökét.Példa R2 router-t R1-en keresztül éred el. R1-en frankón le megy a konfiguráció módisítása, az új konfiggal is eléred továbbra is, de az új konfiggal már nem éred el R2-őt.
A másik dolog meg az, hogy nem minden történik real time-ban. Lehetnek olyan szerencsétlen esetek, amikor egy redistribution loop csak hosszú percek alatt jelentkezik, ami alatt BGP peering-ek frissülnek. -
soma314
tag
válasz
Proci85
#15133
üzenetére
Ahhoz, hogy automation-t használj kell route-olható ip kapcsolat a controller és az eszköz között. Ahhoz hogy a controller be tudjon ssh-zni kell user, vty crypto beállítások. Ha snmp akkor pedig az. Ha nem agentless hanem komolyabb akkor az agent klienst fel kell telepítened a hálózati eszközre. Ezeket hogyan scripteled?
Nem kell a konfigban taknyolásnak lennie. Elég ha egy switch lefagy (a senior-ok már láttak ilyet) elég ha a site-okat összekötő service provider változtat valamit. De még csak az is elég ha nem jó sorrendben hajtod végre a változtatásokat az eszközökön és ettől a "távolabbi" eszközzel elveszted az ip kapcdolatodat
-
soma314
tag
válasz
Cyber_Bird
#15126
üzenetére
nyilván két eszköznél működik, de a harmadiknál más lesz a környezet, mert nem pondt úgy volt bekonfigurálva két hónappal korábban.
Nem lehet tesztelni egy-két minta alapján.
Tényleg rendesen át kell gondolni -
soma314
tag
én ezeknek csak nagyon a felszínét kapirgálom, vagy még azt sem. Olyat csináltam, hogy ansible-el egy linux szerver egyszerre cserélte le router-eken az authentikációs passworld-öt, amit kézzel nem igazán tudsz úgy megtenni, hogy a kapcsolat közben nem bomlik el. Ansible-ben egy agentless megoldás volt: ssh-n jelentkezett be a kontroller, mintha kézzel léptél volna be és beküldte a konfigot. Bár technikai akadája nincs, de nem volt semmi visszakérdezés, ellenőrzés semmi, csak bedobta az új jelszavakat és elmentette a konfigot. Pont az volt a lényeg, hogy az előtt legyen új jelszó, mielőtt elbomlik a neighborship. Nem éles rendszeren futott, csak a "móka" kedvéért csináltam. Egyébként sajnos nincs időm ilyesmivel foglalkozni mostanában, de a dolog lényege, hogy ezek nem egymás alternatívái, hanem egymás részei: nincs SND orchestration nélkül, nincs orchestration automation nélkül.
De ha lenne időm, akkor kezdenék belemerülni az ansible-es dologba, aztán kezdeni python-ozni. (Azért python, mert sok hálózati eszközön van, vagy lehet rájuk telepíteni.) -
soma314
tag
válasz
FecoGee
#15125
üzenetére
ez nálam az orchestration kategória. Tök jó és kényelmesen lehet kialakítani az egységes QoS policy-t minden bevont eszközön. A kérdés az, hogy melyik a nagyobb feladat/költség/idő ,egyszer kialakítani a QoS-t és eszközökön végigkonfigurálgatni, tesztelgetni.Végigmenni ezen az eljáráson amikor változtatni akarod a QoS policy-t újra.
-vagy az eszközöket bevonni a rendszerbe, megvenni a szoftvert, megtanulni használni...
Ez szerintem esetenként, méretenként változik.Én egyébként arra gondoltam, hogy az nem tipikus, hogy dinamikusan változik az üzleti folyamat igénye a hálózattal szemben. (Biztos van ilyen, nekem nem tűnik gyakorinak.)
Például a QoS szempontjából a Youtube streaming mondjuk a SZEMET class-be sorolódik és kapja a saját bw-jét, priority-jét, drop-ját.... De ez általában mindig igaz.
Mondjuk legyünk kreatívak és találjunk ki egy olyan vállalatot, ahol offsite mentések éjszaka mennek a serverek között. Napközben a VoIP és egyéb szokásos irodai forgalmak lesznek a prioritás, éjjel meg mondjuk SFTP.
Ezt meg lehet csinálni úgy is, hogy nappalra van egy QoS policy és éjszaka van egy másik. Ezt ki lehet cserélni eszközökön futó scripttel, de külön controlerrel mondjuk ansible-el....
DE meg lehet csinálni úgy is, hogy a QoS time based access list-eket használ ami alapján a GYEMANT class-be nappal nem kerül be semmi, de éjjel be kerül a szerverek közötti SFTP forgalom.Nálam az, hogy az eszközöket egy központi GUI-s menedzsment szoftverrel konfiguráljuk még önmagában nem SDN. Ha ilyen komplex feladatokat leegyszerűsít, ahogy a példádban írod, akkor orchestration szerintem.
-
soma314
tag
válasz
Ripper17
#15118
üzenetére
Az a baj, hogy a szakmában is sokan kevernek sok fogalmat: így az autómatizálást, orkesztrálást, SD-Networking-et.
Amiről te írsz az leginkább csak autómatizálás. Egy ismétlődő egyszerű repetitív feladat végrahajtása, visszacsatolás nélkül.
Jól hangzik, hogy nem lépsz be 50 site-on 50 switch-be egy új vlan felkonfigurálásához, hanem írsz egy sriptet, de mi van, ha nem sikerül jól és mind az 50 site-tal megszakad a kapcsolat? Akkor 50 helyre kell elautózni, telefonálni... Ezért nem látom nagyon életszerűnek, hogy a junior kollega autómatizáljon.
Vannak erre egyébként kész megoldások, ahol kattintgatással lehet autómatizálni a dolgokat és a frontend szépen elintézi a berendezésekkel mondjuk SNMP-n keresztül. Nálam még ez sem SD-Networking.Nálam az SD-Networking az, amikor van egy változó igényű üzleti folyamat, aminek a dinamikus igényeit figyeljük és az igények változásához autómatikusan alakul a hálózat.
Az az igazság, hogy egy finamoan beállított QoS mellett (ahol eleve már a QoS szabályok változnak időben time based access list-ekkel) nehezen tudok elképzelni erre valós igényt, de biztosan létezik. Én inkább sejtek mögötte marketinget, mert a Sofware Defined az aktuális megrendelés indító varázsszó, mert már oly sokszor elhangzott buzzworld.
Azt is látni kell, hogy a gyártók nem az egyszeri hardver/szoftver eladásokból járnak igazán jól, hanem az előfizetéses kapcsolatokból. Mondjunk Cisco-s példának egy Meraki-s wifi rendszert, ahol a kontroller a "felhőben van". Kérdés, hogy ami felé a világpolitika mostanában megy (Kína / USA kereskedelmi háború) akarjuk-e, hogy az adataink, a rendelkezésre állásunk kínai eszközöket (is) használva amerikai szerverektől függjön. Mennyire fog passzolni az EU-s adatvédelmi politika az ilyen megoldásokkal?Persze ez azért még ne vegye el a lelkesedésedet, mert például egy script, ami lekérdez és a munkádat / munkátokat megkönnyíti mindig hasznos. Közben meg megismered az SDN-hez kapcsolódó automatizálás egyes elemeit, ami szintén jó.
Arra azonban vigyázni kell, hogy minden újdonságot a helyén kell kezelni, mert például remek OS/2-es rendszergazdák voltak régen akikre elég csökkent igény mutatkozik manapság. -
soma314
tag
válasz
BlackJapan
#15089
üzenetére
Vállalati környezetben az AD és egyéb Microsoft-os feature-ök miatt Windows van általában a felhasználók gépein. A céges notebook-on nekem is.
Én úgy oldom meg a Linux-os igényeket, hogy feldobtam rá a VMware Station-t és azon futtatok linux-os VM-eket. Ezt MAC-el is meg tudod tenni a VMware Fusion-nal. -
soma314
tag
most találtam rá a Cisco oldalán a MIgration tool-ra: www.cisco.com/c/en/us/training-events/training-certifications/certifications/professional/ccnp-routing-switching-migration-tool.html
eszerint, ha most megvan a 3 CCNP RS vizsgád, akkor 2020 februárja után a CCNP címek:
Cisco Certified Specialist - Enterprise Core
Cisco Certified Specialist - Advanced Infrastructure Implementation -
soma314
tag
válasz
kenwood
#15013
üzenetére
Igen igazad van: átlag. De ugyanakkor nekem is igazam van mert az "átlag" maga a bullshit.
Gondolj bele a Világ nagy, még ha le is szűkítették a mintavételt mondjuk az USA-ra ott is jelentős különbség van a New York-i és kelet-taxes-i fizetések között. Az sem mindegy, hogy az illető a Nasa-nál, vagy a sherif irodában hálózati munkatárs-e.
Egy ember az IT világban általában nem csak egy tanúsítvánnyal rendelkezik. Azon kívül számos egyéb tudását bizonyító dolog is van: pl főiskolai, egyetemi diplomája akadémiai doktorija, phd-je is lehet. Beszélhet idegen nyelveket. Lehet jogosítvány autóra, motorra, helikopterre....
Ha azt hiszed, hogy az átlag ezeket a dolgokat kiegyenlíti, akkor keveset tudsz a statisztikáról.Gondolj bele van egy 20 éves srác, aki érettségi után megcsinál egy CCNA-t és elhelyezkedik, keres évi 40 ezer dollárt.
Meg van egy 55 éves szakember, aki annak idején gyengeáramú villamos mérnökként végzett elhelyezkedett a telecom világban, még nem is voltak gyártói cert-ek akkor amikor már ilyesmikkel foglalkozott. Lehet, megtanult olyan technológiákat, amiket ma nem már használnak mondjuk Novell-t, token ring-et, appletalk-ot, SDH-t, frame relay-ben ász volt a PBX-es telefonközpontokat kente vágta. Ezeket mind meg tudta tanulni amikor kellett és el tudott mélyülni bennük. Most van Juniper-es JNCIE-ja (a CCIE-nak megfelelő) mert Juniper kellett. De van egy projektje, ahol Cisco eszköz kell ezért gyorsan leteszi ő is a CCNA vizsgát. Az ő fizetése évi 200 ezer dollár. A statisztikában csak nyomokban lesz található JNCIE, mert abból bizony kevés van, viszont ő is CCNA.
Hurrá ez esetben a CCNA átlagfizetés évi 120 ezer dollár?
A statisztikáról nem tudni mennyire volt reprezentatív, hány ember töltötte ki, az saját bevallás alapján, vagy az adóbevallásuk alapján készült.
A konkrét belinkelt oldal szakmaisága pedig nálam (ahogy írtam is) ott vérzett el, hogy a PMP-t (Project Manager Professional) ami egy "vezetői módszertani" dolog keverte olyan kifejezett technikusi cert-el, mint a CCNA.Lehet az én generációm látja rosszul a dolgokat (én az 50-hez közelebb vagyok, mint a negyvenhez) de ne azért tanulj, hogy a fizetésed több legyen, mert attól nem lesz több. Sőt mostanában akár egy OKJ-s villanyszerelő tanfolyammal lehet többet keresnél, vagy akár segédmunkásként egy jó kőműves mellett, mint egy kezdő CCNA-ként. Én azt tanácsolom, hogy azért tanuljál, hogy tudjál értsél hozzá. És olyat tanulj ami érdekel, ne olyat, amit pillanatnyilag úgy tűnik megfizetnek. Ha olyat tanulsz, ami érdekel és meg is tanulod, akkor jó leszel benne. Ha jó leszel benne, akkor jó eséllyel többet fogsz keresni vele és boldogabb is leszel, mintha olyat tanultál volna, amiben csak a pénzt láttad.
Félre ne érts, bármit is tanulsz több leszel tőle, de én a saját káromból tudom, hogy hagytam annak idején befolyásolni magam másoktól és rengeteg energiát időt fektettem olyan dolgok tanulásába, amik "jó befektetésnek" tűntek akkor, de mivel nem szerettem azt csinálni nem hozták meg azt a gyümölcsöt amit vártam tőle. -
soma314
tag
sajnos semmi ötletem nincs és félek, hogy a Cisco-nál az illetékesek sincs még végleges tervük
Mert, hogy erről nincs semmi információ. Ennek két oka lehet: vagy nem akarják, hogy a jelöltek "taktikázzanak" vagy meg akarják várni a szakma reakcióit a felvázolt változásokra. Vagy akár a kettő együtt.
Csak hangosan gondolkodva a saját szituációm: RS-ből van CCNA/CCNP és megvan a valid CCIE written vizsga, wireless-ből a CCNA
Az új rendszerben ugye ez mind az enterprise része. Az új rendszerben van ugye core vizsga.
Na most, ha azt mondják, hogy elismerik a mostani CCNP RS-t core-nak, akkor az azért "torz", mert aki a jövőben szerzi meg, az a core vizsgához tanulni fog némi wireless-t is. Eddig az RS-hez nem kellett semmi wireless tudás. Mivel RS, ezért megadhatnák, az advanced routing and services specialist-ot. Érdekes módon switch-ing már nem szerepel sehol a megnevezésben.
A CCIE RS written vizsga pedig nem fog szerintem semmit sem érni, hiába kellett mélyebb tudás hozzá, mint a CCNP RS vizsgákhoz és hiába volt elég drága is.
Ami megint nehezen konvertálható az a CCNA wireless. Ez nyilván nem érhet annyit, mint egy CCNP enterprise wireless desing vagy implementation vizsga, hiszen azzal azt sugalnák, hogy az új CCNP a régi CCNA szintjét jelenti. Nem lenne jó húzás.
Így "okoskodva" bennem nő az a félelem, hogy annyit fog jelenteni a meglévő tanúsítvány, hogy a lejáratukig használhatod ezeket a címeket, illetve talán valamilyen kreditrendszerben átválthatóak lesznek valami újra. Ilyesmire gondolok: hogy ha most van mondjuk CCNA RS-ed, CCNA Wireless-ed, CCDA-d, akkor azzal kiválthatod az új CCNP enterprise core vizsgát és csak egy specialist vizsga kell a CCNP címhez.
Azt is el tudom képzelni, hogy lesznek külön "különbözeti" vizsgák 2023-ig amiket mostani CCNA-d, CCNP-d lejáratáig tehetsz le, hogy átváltsad az új vizsgák valamelyikére.
A legnagyobb félelmem pedig az, hogy egyszerűen csak olcsóbban vizsgázhat majd az, akinek most van már valamije.
Persze ezek találgatások és kár is ezen aggódni, mert minek aggódjunk azon amin nem változtathatunk?! -
soma314
tag
hát szerintem ez a 15 top paying list egy "bullshit"
egyrészt a PMP például nem is klasszikus műszaki tartalmú IT certification, a CompTIA bár nem butaság, de önmagában csak elméleti tudást adEgyébként általánosan ezekkel a listákkal az a baj, hogy van CCNP RS, aki egy hónapja az, meg van aki 10 éve az, sőt olyan is van, aki 10 évig az volt, de már nem az. Lehet a legutóbbi (akinek nincs valid cert-je) a legnagyobb tudású és van akkora neve a szakmában, hogy ne kelljen ilyesmivel vesződnie.
A cert-ek arra jók (arra nagyon) hogy gyakorlati szintű, aktuális tudásról adjanak tájékoztatást. Nem úgy nézd, hogy azért szerzed meg a CCNA-t mert akkor a fizetésed ennyi és ennyi lesz, hanem úgy, hogy a megszerzéséhez elsajátítod a tudást, ami számodra hasznos. Ha sikerül a cert az egy visszajelzés neked és jelenlegi / későbbi munkáltatóidnak, hogy kb mit tudhatsz minimum. A maximumra nincs benne információ.
-
soma314
tag
válasz
FecoGee
#14993
üzenetére
az tök jó lenne, mert az CCIE RS written az szerintem jóval nehezebb volt, mint a CCNP vizsgák, ráadásul a duplájába került. Tehát akkor újíthatsz két könnyebb vizsgával, ami kb annyiba került, mint az egy nehezebb.
Ráadásul lehet értelmesebben is újítani: ahelyett, hogy ugyanazt tanulod újra és újra, tanulhatsz más szakágat is és erre már nem 2 hanem 3 év lesz. Ez összességében még lehet jó is! Persze az ördög a részletekben rejlik.
-
soma314
tag
válasz
Ripper17
#14989
üzenetére
nem volt semmi meglepő 65 kérdés, multichoice rendszerben, illetve közölük 3-4 drag and drop
szerintem az official cert + a gyakorlatod elég kell legyen.A követelmény a "megszokott" 80%.
én szeretek vod anyagokból készülni amit lehet
CBTnuggets-nél van egy elég jó (persze önmagában baromi kevés)
Én végigmentem többek tanácsára egy CWNA sorozaton is illetve a régi wireless vizsgára készített INE-s videókon is.
Otthonra épített laborhoz volt eleve PoE-s switch-em, VM-es kontrollert használtam és 1242-es AP-t.
Na az egy komoly szívás volt, mire mindegyikből meglett az a verzió, ami hajlandó volt működni együtt.Annyit még hozzá tennék, hogy az R&S részében CCNP szint felett vagyok már egy ideje szóval azokra a részekre nem kellett külön készülni. Pl. nem kellett itt megértenem mi egy AAA szerver és miket csinál, mert ezeket már régebbről eleve kellett tudnom. Itt ki tudtam használni az átfedéseket. A wifi vonal viszont új volt.
Sokaknak nehéz a dolog fizikáját megérteni, dB-el számolni. Én ebből is "szerencsés" vagyok, mert eredetileg mérnök vagyok és nem itt találkoztam azekkel a dolgokkal először.
Egy ICND1 után közvetlenül sokkal többet kellhet készülni.Elvileg (és valóban) a station-ök dolgairől is kérdeznek, ezért Windows / MAC / Android wifis beállításokra is rákérdezhetnek. Én nem vagyok almás, de voltak kollegák akik almás dolgokat használnak és át tudtuk beszélni a témát.
Amit én utáltam, és nem is nagyon tudtam gyakorlati szinten felkészülni, az a WCS téma. Ma már korszerűtlen, de elvileg lehetne rá kérdés a vizsgán, hiszen még üzemelnek ilyen szoftverek és azokat üzemeltetni kell.
A CCNA az én meglátásom szerint értékben le fog süllyedni a mai CCENT értékére, talán egy kicsit magasabbra, de csak gondolj bele egy vizsgán kellene valakinek arról tanubizonyságod adnia, hogy, ha nem is mélyen, de ért a switching-hez, a routing-hoz, a wifihez...Eddig nem volt "reneszánsz ember" CCNA, csak valamihez értő: R&S, DC, WiFi
És ez szerintem logikus volt, mert mindegyik más világ. Sőt az oprendszerek is eltérőek.
Más az IOS CLI és más a WLC-t GUI-n matatni, még ha hasonlít is, de mégis más a cli is egy AP-n, WLC-n, mint egy switch-en, router-en....
A Junipernél van úgy, hogy az alapvizsga JNCIA témája gyakorlatilag csak a JunOS és némi routing, némi security, de ott el lehet mondani, hogy minden Juniper eszközön a JunOS az alap. -
soma314
tag
válasz
FecoGee
#14986
üzenetére
értem
viszont újabb kérdés merült fel bennem:
erre vonatkozóan:
"Pass one technology core exam and pass any one professional concentration exam."Egy esetet vegyünk végig:
1. valaki leteszi a 300-401-et, ami a CCNP Enterprise core vizsgája,
2. majd leteszi a 300-410 ENARSI vizsgát (Routing and services)
3. megcsinálja a CCIE Enterprise Infrastructure labortKérdés, ha ismételten leteszi a 300-401-t és a 300-410-et, azzal megújítja a CCIE-jét, vagy feltétlenül másik témából kell a core és concentration exam-ot letennie?
Ha az első a helyzet, akkor lehet könnyít a változás, ha a második, akkor szivatás. -
soma314
tag
válasz
suomalainen
#14984
üzenetére
az a baj, hogy ég nem nagyon látjuk át a koncepciót
az új CCIE / CCNP / CCNA hogy fog viszonyulni a jelenlegiekhezÖsszegezném én mit értettem eddig a dologból:
CCNA
- csak egyetlen vizsga lesz (nem lesz ICND1 és ICND2)
- ezáltal nem lesz CCENT szint (kivéve a DevNet, az eddigi design vonalat, ahol lesz CCT, azaz technician)
- nem lesz specializáció (R&S, wireless, security, data center, cloud....) CCNA szinten
- ezáltal lesznek speciális szintek, amik eddig csak CCNA szinten léteztek, amik beleolvadnak az általános CCNA-ba (ilyen a CyberOpps, az Indrustrial)
- a 2020 február vége előtti specializált CCNA-k kapnak valami badge-et, de senki nem tudja ez mit jelent majd a gyakorlatbanCCNP
- kevesebb vizsgát kell letenni (eddig egy CCNP R&S 3 db vizsga volt)
- ha jól értem nincsenek előfeltételek a CCNP vizsgáknál (nem kell érvényes CCNA hozzá)
- csak itt jelenik meg specializációCCIE
- ez is 3 évig lesz érvényes
- az eddigi CCIE written helyett lesz a vonatkozó CCNP vizsga előfeltétel (egyik "300-" vizsga)
- kérdés, hogy a "300-" újbóli letétele megújítja-e a CCIE-t?CCDE
- egyenlőre úgy néz ki ezt nem érintik a változásokÁltalános dolgok
- a legnépszerűbb R&S megszűnik, helyette Enterprise lesz, ami két részből a struktúrált hálózatokból és a wireless-ből áll, ahogy írtam, ilyen specializált vizsga, csak CCNP szinten lesz
- a design vonal is átnevezésre került CCDA, CCDP szinten DevNet-re
- az várható volt, hogy az autómatizáció, az SDN bele fogja magát rágni a tanúsítási rendszerbe isSzigorúan magánvélemény, de szerintem a CCNA a jövőben kevesebbet fog érni a munkaerő piacon. Amolyan svájci bicskának lehet elképzelni, amiben lesz routing, switching, de lesz wireless, autómatizáció, SDN , security is, de elég felszínesen lehet ennyi mindent egy vizsgába belezsúfolni.
Az is szinte beiztos, hogy az álláshírdetésekben pedig egyre inlább csak CCNP-ket (a vonatkozó specializációval) fognak keresni.
Sajnos legkevésbé a CCIE-t tudom értékelni. Még nem értjük pontosan a retake policy-t, ami lehet könyebb lesz a jövőben és pláne semmi gyakorlati infó a labor vizsgáról. Ami kár lehetetlenül nehéz, akár könnyebb is lehet a jelenleginél. (Nekem a CCIE written le fog "járni", ha nem megyek ismét októberig laborra, de most ezek a változások végkép elbizonytalanítottak, hogy van-e értelme menni.) -
soma314
tag
válasz
FecoGee
#14979
üzenetére
Én úgy értem, hogy továbbra is két vizsga lesz: step 1 the qualifiing exam (ez a mostani written) és step 2 thr lab exam
"After February 24, the CCIE Routing and Switching Written v5.0 exam will be replaced with ENCOR 300-401. After you pass ENCOR 300-401, you will earn the Cisco Certified Specialist - Enterprise Core certification."
-
soma314
tag
válasz
FecoGee
#14967
üzenetére
elvileg ezután is elég lesz egy CCIE written vizsgát letenned, ha jól értem az új rendszert.
A nagy kérdés persze az, hogy melyik lesz az a written, amelyik aleginkább lefedi a mai R&S-t.
Hát ősszel még próbálkoznom kellene a CCIE R&S laborral újra, de most kicsit kezdik elvenni a kedvem.A másik ami kedvetlenít, hogy kellett egy wifi-s vizsga és én a CIsco CCNA wireless-t tettem le. De lehet pár hónap mulva már nem is lesz "hivatalos" cím amit használhatok, hiszen R&S oldalról van CCNA/CCNP és nem lesz különbség az új "általános" CCNA cím és a korábban szerzett R&S, Wireless címek között. Vagy rosszúl értem?
-
soma314
tag
válasz
vadger
#14963
üzenetére
Mostanáig úgy volt, hogy nem volt szükség semmilyen CCNP tanúsítványra ahhoz, hogy mehess CCIE written-re, aztán laborra.
Bár én CCNP után (jóval) tettem le a written.t, de mindig is mondtam, hogy rosszúl van az, hogy bárki "az utcáról" leteszi a written-t (aminek nincs semmi gyakorlati része) aztán mehet a laborra.
Nem kockáztat semmit, mert nem vehetik el tőle a CCNP tanusítványt sem (mert eddig nem kellett).
Amúgy következetlen is volt a rendszer: CCNP vizsgákhoz kellett a vonatkozó CCNA vagy egy CCIE. A CCIE written-nek meg semmi előfeltétele nem volt. (Volt persze ebben is logika, hiszen, lehet, hogy valaki régen letette a CCNP-t, hagyta lejárni, aztán eljutott közben egy CCIE szint közelébe, akkor őt miért szivassák valid CCNP-vel?)Ahogy egyébként olvasom ezután sem lesz ez máskép: "There are no formal prerequisites for CCIE Enterprise Infrastructure"
-
soma314
tag
válasz
tutitibi
#14948
üzenetére
hát azért ezt pontosítanám: van álhálózat, szerintem arra gondoltál, hogy az alhálózati mask megadása nem olyan macera, mint az IPv4-nél. Ugye itt prefix-et+subnet length-et adunk meg
(Tudom, hogy te is tudod mindezt, csak ha valaki idetéved és beleolvas, akkor ne vonjon le téves következtetéseket).
Ha akarod (és néha azért akarhatod) akkor itt is lehet címfordítás, sőt van NAT64 is ami a két protocol között végez címfordítást (IPv4 to IPv6). A lényeg viszont az, hogy amíg az IPv4-nél kényszerűen együtt élünk a NAT-tal (PAT-tal) addig az IPv6 esetén nem feltétlenül van rá szükségünk.Hasonlóan nem kell hagyományos DHCP szerver sem az IPv6 működéséhez. A címek kiadása lehet sokkal egyszerűbb IPv6 esetén, mint IPv4 esetén.
Én úgy tudom, hogy a Föld felszínét borító valamennyi atomra jutna külön IPv6 cím, de bevallom nem számoltam utána
-
soma314
tag
válasz
kenwood
#14944
üzenetére
EUI64 - no nem csak 4 "karaktert" kell beszúrni a MAC cím közepébe, hanem annak a 7. bit-jét átbillenteni is (0-ról egyre, vagy 1-ről nullára) a probléma ennek a megértésével szokott lenni, hogy akkor hogy van ez a 2-es és 16-os számrendszer viszonyában?
hasonló a helyzet annak a megértésével, hogy ha a link local address space FE80::/10, akkor az FF::1 cim, akkor miért link localjunior állás CCENT-el
nem akarom sem a te sem mások lelkesedését letörni, de egy CCENT-el önmagában még szerintem nem lehet annyi tudásra szert tenni, amivel IT területen dolgozni lehessen
viszont általában mindenkinek van mellette más képessége is: mondjuk egy diploma, szakérettségi ...nagyon ritkán van az, hogy OSPF-t, STP-t kelljen konfigurálni és akkor az kifejezetten nem jó, ha belépő szintű kolléga nyúl ilyenekhez hozzá.
(Csak érdekesség képpen egy Juniperes JNCIA, ami kb a CCNA-nek felel meg Juniper világban, egyáltalán nem foglalkozik switching-el!)ezeket azért kell CCNA RS szinten ismerni, hogy értsed mi van mögötte és figyelj oda mit csinálsz, tudd, hogy egy kábel kihúzása, majd visszadugása milyen folyamatokat indít el egy hálózaton és annak mik lehetnek a következményei
hogy lelkesítőt is írjak: például egy wifi-s CCNA egy cégnél nem fog ospf-fel, úgy általában routing protokolokkal pláne stp konfigurálással találkozni viszont keményen szüksége van azokra a dolgokra, amit CCENT-ként kellett elsajátítania: vlan-ek, trunk, access port, etherchannel.
mondok még egy dolgot: mint minden gyártó specifikus tanúsítvány, így a Cisco tanúsítványok sem fókuszálnak olyan témákra, amik mindennaposak, de nem az adott gyártóhoz kötődnek.
Ilyen alapfogalmakra gondolok: mit jelent az, hogy két U-s egy router, mi a különbség egy SC meg egy LC transceiver csatlakozó között, hogy kell szakszerűen kábelezni....pláne olyan alap villamossági ismeretek, amivel tisztában kell lennie valakinek, aki ilyen gyengeáramú berendezésekkel dolgozik: mi a földelés, miért kell egy rack szekrényt bevonni az EPH-ba, mi a többszörös betáplálás, miért kell a redundáns táppal rendelkező eszközöket úgy ketötni, hogy ha van lehetőség, akkor az egyik egyik fázisról, a másik másikról menjen, vagy az egyik betápról, a másikról vagy a helyi UPS-ról és direktbe...ezek azért lehetnek fontos dolgok, mert ha valaki kezdi valahol a távközlésben, akkor bizony elég jó eséllyel olyan feladatokat kap, hogy vidd ki ezt a felkonfigurált switch-et a helyszínre és helyezd üzembe egy rajz vagy egyéb dokumentáció alapján.
Nos ha valaki akkor fog élősszőr szerverszobában járni annak nem lesz könnyű dolga. No persze nem kvantumfizika, csak ezt is meg kell tanulni.A mai hála az Égnek munkaerő-hiányos világban pedig lehet, hogy felvesznek egy kezdőt gyakornoknak aki egy CCENT-el már bizonyította, hogy hajlandó és tud is új dolgokat tanulni és majd az adott munkahelyen kitanítják, beiskolázzák, kinevelik arra, amire ott konkrétan szükség van.
-
soma314
tag
válasz
kenwood
#14942
üzenetére
AZ IPv6 szerintem semmivel sem nehezebb, mint az IPv4 (sőt bizonyos szempontból könnyebb, nem kell subnetmask-et számolgatnod). Viszont másképpen működik, mint az IPv4 és az IPv4-re állt rá a gondolkodásod.
(CCNA szinten, szerintem túl sok IPv6 nincs. Meg kell tanulni hogyan kell leírni, olvasni egy IPv6 címet, hogyan lehet EUI64-et képezni MAC címből, tudni kell, milyen tartomány a link local, multicast....) -
soma314
tag
válasz
kenwood
#14939
üzenetére
én annak idején egyben vizsgáztam, ezért csak arról van tapasztalatom
az ICND2-ben vannak témák, ami az ICND1-re épülnek, ezért lehet, hogy az "egybe vizsgán" több a komplex kérdés
szerintem a lényegi különbség nem a vizsgában, hanem a felkészülésre adott időben van
ha valami (munkahely, saját siker éhség, bizonytalanság) arra késztet, hogy a legrövidebb időn belül, ha úgy tetszik, a legkevesebb energia befektetéssel legyen egy papír a kezedben, akkor a legjobb az ICND1-en túlesni.
Ebből esetleg ki is derülhet, hogy ha nem fekszik ez a szakma és kevést pénzt/időt buktál el.Az ICND1-el meglesz a CCENT tanusítvány, ami több esetben előfeltétel egyes CCNA szintű vizsgákhoz.
Tehát, ha mondjuk te tervezői ágon szeretnél a legegyszerűbben CCDA-t szerezni, akkor az ICND1 és utána a CCDA vizsga.De ugyanez igaz a wifi, security, ipari ágra is.
-
soma314
tag
Jeremy a legjobb!
Csak az ő videoi alapján nem fogsz levizsgázni, de két dologban szerintem verhetetlen:
1 - motiváció
A lelkesedése ragadós és bizony meg tud szerettetni olyan technológiákat amiktől általában előtte idegenkednek az emberek.
2 - megértetés
Alapos tudásra csak úgy lehet szert tenni, ha alapjaitól megérted a dolgot. Ebben verhetetlen a pali. Lehet, hogy vannak akik egy szárazabb, technikai jellegű magyarázatból vagy az OCG-ből is megértenek mindent, de szerintem könnyebb Jeremy életszerű, humoros magyarázataiból.CCNP-s anyagai vannak, hasonlóan hasznosak, mint a CCNA szintűek. CCIE szintű videói nincsenek.
Amit még feltétlenül ajánlok tőle, azok a "karrier" tanácsok, meg az hálózatos életre oktató videói. Ilyenből külön van sorozata, ami nem egy-egy certification-re, hanem a valós munkára készít fel.Ja és aranyszabály, hogy felkészül több forrásból kell!
-
soma314
tag
tanácsot szeretnék kérni CCNA wireless ügyben
úgy hozta az élet, hogy lehet kicsit meg kellene ismerkednem a wireless technológiával
ez most max egy CCNA szintig terjedne
eddigi tapasztalataim szerint csak úgy tudok tanulni, ha közben laborozom is
van a CCIE RS-re készülve az itthoni laboromban, van 6 db multilayer switch, talán mind PoE-s, szóval switch már nem kell
a controllert virtuális géppel szeretném megoldani evalution licence-el
A kérdésem ezért leginkább az AP(k)-ra vonatkozik. Milyen típusban és hány darabban érdemes gondolkodni CCNA wireless labor építéséhez? -
soma314
tag
válasz
bump3r111
#14728
üzenetére
szerintem a 7200 + switch modulos 3725-ön kivül nincs szükséged másra.
Ez utóbbi ugye egy router, amibe virtuálisan beteszel egy switch modul-t. Ezzel a CCNA szintű switch-ing jelentős részét lehet gyakorolni.
Ködös emlékeim szerint CCNA szinten nem igen volt szó a multilayer switch-ekről, ezért ezen a szinten úgy praktikus, hogy a routing-ot (7200-asokkal) gyakorlod a GNS3-ban. Veszel két switch-et a switch-inget élesben gyakorlod. CCNA-hoz két olcsó 2950 is bőven elég, de ha tovább tervezel, akkor 3550 3560, 3750-t érdemes venni. Ez utobbiak újra eladhatósága is jobb, csendesebbek, kisebb az esély, hogy behalnak. Ezek ugye már nem éppen új dolgok.Egyébként GNS3+valódi hardver simán működik, de kell hozzá vagy sok hálókártya a gépbe vagy pluszban egy úgynevezett breakout switch.
-
soma314
tag
Szerintem igen előfordulhat, mert a Cisco fenntartja a jogot, hogy bármit kérdezzen. De az nem jelenti azt, hogy elő is fordul, illetve ha van olyan kérdés, ami "idegen" azt nem biztos, hogy be is számítják a vizsga eredményébe.
Tételesen:
"- az egyes kábelek pontos IEEE jelölésére"
Szerintem emiatt ne aggódj"- az ismert portok számára és hogy tcp vagy udp"
A "nagyon ismerteket" bizony tudni kell. Ami nem azt jelenti, hogy az összes well known portot, de amiket érdemes megjegyezni: telnet, ssh, www, dns, tftp, ftp (magasabb szinten azok a routing protokolok, illetve LDP amik nem saját protokolt használnak) Ez utóbbiak ICDN1 esetén jellemzőek.
Amit viszont az alapoknél érdemes megjegyezni, ha a port számokat nem is tudod, hogy a felsorolt 6 protokol közül melyik használ TCP-t, UDP-t, illetve mindkettőt. Mondjuk olyan feladatot simán el tudok képzelni (ezt is inkább magasabb szinten) hogy egy acl-ben kell megtalálnod a hibát és ki kell szúrnod, hogy a tftp az nem tcp hanem udp."- kell-e tudni az udp,tcp, ip4, frame header minden egyes mezőjéről hogy mit szolgál, mekkora a mérete"
szerintem ilyen konrét kérdésre ne számits, de általánosan nyilván kell tudni, hogy például egy udp vagy egy tcp packet header-je nagyobb-e, melyik tartalmaz több mezőt..."- illetve hogy egy show parancs konkrétan milyen értékeket ad vissza"
ha ezt úgy érted, hogy pontosan milyen táblázatot fog kiadni egy show parancs, akkor nem, de azt kell tudni, hogy ha meg akarsz valami információt tudni, akkor azt melyik show parancs adja vissza. Ilyet tudok elképzelni például, hogy válaszd ki hogy az alábbiakból melyik parancsokkal látod, hogy van-e OSPF neighborship-ed és, hogy mi a router ospf router id-je. Fel van sorolva mondjuk a show ip ospf neighbor, a show ip ospf interface brief, a show ip protocol.... -
soma314
tag
válasz
kowika87
#14657
üzenetére
Köszi a részletes leírást!
Ahogy beszéltük korábban a diagnosztikában nagyon hasonló élményeim voltak. Kezelhetetlen hosszú html lapok. És messze nem olyan egyszerű, mint "hírlik". A hírlik alatt azt értem, hogy az INE-nál is eléggé elnagyolják a témát, máshol is azt mondják, hogy úgyis ismered a technológiát mire oda jutsz annyira, hogy a diagnosztika nem hoz zavarba. Ettől függetlenül 15 perced van egy-egy diag feladatra és minden lehetséges eszközzel (értsd alatta nehezen kezelhető html doksik) nehezítik a feladatok érdemi vizsgálatát.Én annak idején pánik szerűen nekiestem a ts feladatoknak, csak fél szemmel néztem át a guidline-t. Nekem nem is tűnt fel, hogy a L2IOU bugra utaltak volna. Most így utólag végiggondolva, lehet volt ticket amit megmagyarázna.
No persze belőlem "a savanyú a szőlő" hangulat beszél, mert ahogy írtad, van a sikertelen labor vizsga utáni nyomott hangulat amiben most én vagyok
Viszont Te megcsináltad, amivel megmutattad, hogy meglehet! Ez reményt is ad nekünk, akik még próbálkozunk.Aki pedig próbálkozott már CCIE-ra való felkészüléssel az tudja, hogy mennyi munka van benne. Ezért SDN ide vagy oda az mi szemünkben nagy dolog a CCIE!
-
soma314
tag
válasz
kenwood
#14580
üzenetére
ahogy crock már megválaszolt rengeteg más hálózati eszköz cli-je "majmolja" az IOS-t
én még a listához hozzátenném az tp-link-et, de akár a linux saját quagga rendszerét isamúgy én pont nem a cli-re gondoltam, mert az inkább különbözik, hanem a fogalom elnevezésekre, ami egyszerűen csak zavaró, és nem hiszem, hogy jogdíjas kérdés. Ilyenre gondolok, mint, hogy ami a Cisco-nál QoS az a Junipernél CoS, ami a CoS meg megint kicsit más fogalom a Cisco világában.
-
soma314
tag
A Cisco-nál CCENT CCNA CCNP CCIE Technician - Associate - Professional - Expert
Emellett vannak specialisták egyes területekre (értékesítés, oktatás miegymás) no meg van az architect a tervező ágon, de kb a nnyi esély mint bejutni a Cisco igazgató tanácsába Az nem egy tanúsító vizsga.A Junepernél ahogy láttam szintén négy szint van: Associate - Specialist - Professional - Expert
Nem sokat tudok a többi Juniper-es vizsgáról, de ahogy nézem a honlapon a professional szintű vizsga is egyetlen vizsga (az assiciate, specialist után persze) ezzel szemben a Cisco-nál ez RS-nél 3: routing, switching, troubleshooting.
Az expert vizsga is "csak" egy 8 órás laborvizsga a Junipernél, a Cisco-nál van egy beugró written.
Szóval a vizsgák száma és költsége szempontjából kedvezőbb lehet a Juniper.(Ha visszatekersz volt itt valaki egy remek érdekes beszámolóval, aki Hollandiában volt expert szintű Juniper vizsgán. Érdemes elolvasni ha érdekel a téma.)
Szerintem a JNCIA egy kicsivel több mint a CCENT, de biztos, hogy kevesebb mint a CCNA RS.
Ezeknek az alapvizsgáknak olyan embereket kell képezniük, akiket ki lehet küldeni egy helyszínre, hogy egyszerűbb feladatokat önállóan elintézzenek és azzal mondjuk előkészítsék, hogy egy professional / expert távoli hozzáféréssel megoldja az összetettebb egyedi feladatokat. Ilyen mondjuk egy eszköz kiszállítása, beüzemelése, konfiguráció feltöltése, szoftver frissítés, kábelezés.
A JNCIA-nél azt hiányolom, hogy én nem mernék kiküldeni valakit kábeleket dugdosni, ha az az illető nincs tisztában a broadcast storm fogalmával, halvány fogalma sincs a spanning-tree működéséről. Ebből a szempontból a CCNA átfogóbb tudást ad. -
soma314
tag
bár nem Cisco, de megosztom az élményt
Tegnap megcsináltam a JNCIA-t.Ami nekem érdekes volt a Juniper világában: ez az alapvizsga nem Routing and Switching, max Routing. Switching-ről egyáltalán nincs benne szó.
Érdekes, hogy belekap témákba, amibe a CCNA (ami szerintem egy fél fokkal magasabb szintű vizsga) ködös emlékeim szerint nem.Ez pedig a QoS vagyis Juniperesen CoS és a virtualis routerek (VRF). Valamint belekap a route redistribucióba, ami a Juniper-nél a működési elv miatt (import export) megkerülhetetlen. Viszont nagyon sok mindent pedig kihagy, amit a CCNA tartalmazott annak idején:
- nyilván "Cisco specifikus" protokol az EIGRP. Ami nem teljesen igaz, mert más gyártóknál is van már pár éve.
- ahogy írtam a teljes switching témakör: nincs spanning-tree, nincs port security, nincs trunking (tagged port juniperesen), nincs VTP
- nekem még volt Frame Relay (emlékeim szerint a subnet masking, STP és a frame relay témakörök voltak a legküzdelmesebbek
- a routing témakör is csak két dologra szorítkozik: statikus és OSPF szigorúan single area 0 környezetben. Említi a BGP-t, az IS-IS-t, de ez gyakorlatilag említés szintjén marad.
- még annyi általános networking eszköz ismertetés nincs benne (az anyagokban amikhez hozzájutottam) mint a CCNA-nél: nincs szó a "háttértörténetről" hub - bridge - switch evolució, ami segít megérteni a switching-et és, hogy mi a routing értelme, eredete. Ezért sokan ismét kezdik ajánlani kezdőknek a tia network + -t, hogy alapfogalmakkal legyenek tisztában.(Érdekes dolog, amit sokáig a magyar oktatás sajátosságának gondoltam, de visszakanyarodva az alapokhoz itt is szembe jött: hogy az alapok oktatásánál torz információval butítják a népet. Arra gondolok, hogy általános iskola alsó tagozatában a fiamat "megszidták" amikor környezet ismeretből azt mondta, hogy nem 3 halmazállapot van, hanem 4:szilárd, folyékony, gáz, plazma. Ez itt a networking-ben is megtalálható: sz OSPF "tisztán" link state protokol, ami csak az area-kon belül igaz. A BGP dinamikus routing protokol. Igazából egy alkalmazás, nincs önálló protokja (TCP-vel működik) és valamilyen más routing protokol kell fusson a neighbor-ök között (ha más nem connected link-en vannak). Bocs a kitérőért.
Mivel Cisco oldalról a tudás magasabb szintjén állok, ezért maga a hálózati alapok témakört nem kellett újra tanulnom, csak a Juniper specifikus dolgokat. Ennek voltak jó és kevésbé jó oldalai is. Látszik, hogy a JUNOS egy fiatalabb oprendszer, mint az IOS, ezért nem "történelmileg formálódott", hanem a átgondolt, koncepcionálisan működik, logikus.
Ami viszont zavaró, az az, hogy kínosan ügyeltek arra, hogy minden kicsit más legyen, mint a Cisco-nál. Például nem administrativ distance van, hanem routing preference, ráadásul más értékekkel, sőt még a sorrend sem feltétlenül ugyanaz (Cisco-nál nincs megkülönböztetve a external OSPF az internal-tol AD-ben, viszont megvan az iBGP az eBGP-tól, Juniper-nél pont forditva). Ezen különbségekre persze a vizsga is fókuszál.
Ez persze valahol érthető, viszont ebben jó lenne valami egységesítés, ami előrébb vinné az ipart.A vizsga környezet, ahogy sokszor sokan leírták már, messze barátságosabb a Cisco vizsgáknál. Nem beszélve a ponthatárról. Ami azért érdekes, mert szerintem kicsit lehetne a ponthatár magasabb. Én azzal, hogy elolvastam egyszer egy 200 oldalnyi könyvet, végignéztem 5-6 órányi video-t, gyakoroltam GNS3-ban kb 3-4 órát, no meg persze az elmélettel rendelkezem Cisco oldalról, simán meg tudtam csinálni pár hibával a 65 kérdésből. Látva a vizsgán, hogy ez mennyivel több a minimális pass score-hoz képest, azt is el tudnám képzelni, hogy ha nem tanultam volna rá, csak a hálózati elméleti tudásra, a paraszti józan eszemre, meg a vakk szerencsére bízom magam, akkor is sikerülhetett volna.
Összegezve kezdőknek szívből ajánlom: sok nehéz témával nem kell megküzdeni az első vizsga alakalmával (pl SPT). Kifejezetten vizsgázó barát (nincsenek direkt megvezető, trükkös kérdések).
Ha az anyagi oldalát nézzük, a vizsga 200 dollár volt és egyből ad egy tanúsítványt. Ezzel 4 irányba lehet menni: Enterprise RS, SP, Data Center, Security.
A Cisco-nál ennek megfelelője a CCENT, ami valamivel olcsóbb és szintén négy irányba lehet menni: Design, RS, Security, Wireless. Tehát ha valaki tudja, hogy majd wireless-el akar foglalkozni, akkor érdemesebb Cisco vonalon indulni, mig, ha service provider, akkor Juniper vonalon.
Amiben a Cisco jobb szerintem, az az, hogy a CCENT kihagyható (nekem sincs) és lehet mindjárt CCNA szintű vizsgával kezdeni. -
soma314
tag
válasz
Montya
#14547
üzenetére
csatlakoznék az előttem szólókhoz
én is pénzkidobásnak tartom a tanfolyamot
no nem azért mert nem hasznos, hanem azért mert önmagában 10 nap semmire sem elégha most kezded a felkészülést, akkor valóban a google a legjobb barátod, de nem csak a keresője, hanem a youtube is
keress rá CCNA témára a videókban és meglepően sok és hasznos dolgot fogsz találni
sőt a comptia network+ videokat is érdemes megnézni, hogy az alapokat jól megalapozzákaz említett cbtnuggets-nél van lehetőség ingyenes próbára, ami alatt simán végig lehet nézni egy CCNA-s VOD sorozatot
szintén hasonló konstrukció a safaribooks ahol hasonló a helyzet a könyvekkel
kismillió CCNA könyv van
ügyelj arra, hogy az aktuális verzió legyen amiből tanulsz ( a régiekkel sincs semmi baj, de esetleg megtanulsz olyat ami már nem téma, illetve kimaradhat olyan ami meg az)laborozáshoz szerzd be a packet tracer-t vagy akár a GNS3-at (utóbbi ingyenes, de kell némi tudás a használatához, előbbiről nem tudom van-e ingyenes verziója, de ködös emlékeim szerint azt egyszerűbb használni kezdőként).
az egész felvetésemnek az a lényege, hogy elkezdesz elmerülni a témában anélkül, hogy pénzt költenél és kitapasztalod, hogy valóban ez érdekel-e, fekszik-e neked
-
soma314
tag
válasz
suomalainen
#14535
üzenetére
A general routing táblából akarsz valamelyik VRF-be bejuttatni route-ot és onnan vissza is akarsz a general-ba (hiszen pingelni szeretnéd kell a return path).
Az import ipv4 unicast map alatt egy target import route-map-re gondolsz?
Ha igen az ugye akkor működik, ha a route, amit importálni akarsz azt MBGP-vel "jön" extended community-vel. A global-ban lévő route-ok nem ilyenek.Kell statikus route megadása, ha a general és valamelyik vrf között akarsz közlekedni. Ha ez helyben van (egy router-en belül van a general és a vrf route amik között pingelni akarsz) akkor nem is kell más, mint a két statikus route.
Ha nem, mert mondjuk egy P router és egy PE közöt akarod megcsinálni, akkor a P és a PE közé kell MBGP és a P és PE router-eken megadott statikus route-okat redistributálnod kell a BGP vpnv4 af-jében. -
soma314
tag
@vadger
@stfreddy
@crok
@Methionyl
@FecoGee
@BlackJapan
@olloczkyMindenkinek nagyon köszönöm a biztató szavakat. Tényleg jól esik!
Pár dolgot még szeretnék leirni, az egyik, hogy a részletes vizsga eredmény nagyon hamar megérkezett. Másnap reggel 7-kor.
Ami meglepett, hogy a diag sikerült (nem mintha számitana) pedig mint irtam teljesen "rezignált" állapotban töltöttem ki.
És amit megcsináltam a konfigból (layer 2, layer 3 részben, VPN részben) az "sem lett teljesen rossz".Biztos, hogy a sebességre kell rámenni.
Sokan azt tanácsolják, hogy erősen motiváló, ha az ember időben kijelöli és be is fizeti a vizsgát. Mert akkor fog az ember teljes erővel készülni, különben az ember hajlamos húzni halasztani a dolgot.
Ebben van valami, de nálam nem működött. Bár készültem ahogy csak birtam (a családom szerint túlzásba is esve), de éreztem, hogy még nem vagyok kész vizsga előtti napokban.
Átteni a vizsgát, pepjegzet, szálloda foglalalást egy későbbi időpontra pedig szinte annyi ban van, mint egy újabb vizsga.Egyébként tegnap este esett le, hogy az első ticket-nél miért nem talaltam a hibát. Illetve megtaláltam, de azt hittem nem az az.
Természetesen konkrétumot nem írhatok, de a tanulságát igen.Én megfeledkeztem arról (amit egyébként sokszor, sokan elmondanak), hogy a vizsgakörnyezet sajátossága miatt, ha a diagram szerint két eszköz közvetlenül van összekötve is, azokat úgy kell tekinteni, mintha köztük lenne egy HUB.
Ez ugye azt jelenti, hogy attól, hogy az egyik oldalon down down-ban van egy interfész, a "kábel" másik végén lehet még up-ban. Ez ugye valódi hardvernél nem lehetne.
Ezt ugye tudtam, de akkor és ott egyszerűen nem ugrott be.Még két technikai apróság: én itthon linux alatt gyakoroltam és bár putty-t használtam, de linux alatt "okosabban" működik a copy/paste mint ahogy a vizsga környezetben be van állítva.
Azt hiszem át is lehet állítani, de talán ezt ablakonként külön-külön kellene megtenni. Nálam az is elvett pár percet, amig ráálltam, hogy a legegyszerűbb, ha simán kijelölöm a másolandó részt, majd jobb gomb és "paste".
(linuxon egyszerűen a középső gomb kijelölés után)
Szintén a youtube-on fellelhető tipp az IPExpert-től, hogy akár a Tshoot során, ha látsz egy hasznos konfigot, példának a DMVPN-t emlitik, akkor azt ki lehet jelölni és bemásolni a notepad-be.
Valaki talán kérdezte is, hogy lehet-e menteni a notepad-ből. Én kipróbáltam és a desktop-ra lehetett. Tehát, ha valaki a konfiguráció során szeret magának template-eket félre tenni, illetve mondjuk csinál egy tclsh scriptet az egyik site végig pingelésére, majd a másik site-éra, és amikor kész a site-ok közötti kapcsolat, akkor elővenni és összegyúrni, akkor nincs arra kárhoztatva, hogy egyetlen notepad ablakban kezelje mindezt.
Én egyébként legközelebb a diag-nál is meg fogom próbálni a konfigokat kimásolni notepad-be, hogy egymás mellett lássam őket. Akkor ott persze nem volt erre eszem.Remélem azért ezek a tapasztalatok valakinek hasznosak lesznek!
-
soma314
tag
Tegnap én is elmentem Brüsszelbe elbukni.
CCIE RS labor volt a téma és az első próbálkozásom volt.
Annyira nem voltam beképzelt, hogy azt higgyem van reális esélyem átmenni, de előbb utóbb meg kellett nézni személyesen is mire számíthat az ember.A körülmények ideálisak voltak. Tegnap egyedüli vizsgázó voltam. Az egyik proctor magyar volt, de mind a ketten mindent megtettek, hogy nyugodt körülmények között vizsgázzam.
Nem voltam beteg, sőt még kifejezettem jól is aludtam a vizsga előtti éjszakán.A "baj" velem volt, nem háríthatom, semmire, senkire. Tshoot-nál az első ticket-be "beleragadtam". Pedig mindenhol mondják, hogy hideg fejjel fél szemmel az órát nézve el kell engedni, ha nem megy.
Viszont a gyakorlatban teljesen bepánikoltam és azon kezdtem gondolkodni, hogy mit keresek én itt. Persze rávettem magam a továbblépésre, de akkor is az előző ticket-en gondolkodtam. Ettől aztán nem ment a következő sem. Végül elengedtem a dolgot és tapasztalatszerzésként próbáltam kezelni. Ekkor ment elkezdett menni és a 4 pontosak sikerültek (a korábbiak 2 pontosak voltak). Persze az idő elment és ettől lettem már ideges.
Elhasználtam mind a 2,5 órát, de igy sem sikerült annyi ticket-et megoldani, hogy sikerülhessen. Ezért innen tudtam, hogy vége.
A diagnosztika alatt azon gondolkodtam, hogy egyáltalán folytassam-e?
Ezért abban sem bíztam, hogy a diag meglesz.
Egyébként nekem rendkívül zavaró volt a diag felülete. Rengeteget kellett scrollozni, hogy a hasznos infók-kat össze lehessen vetni. Volt más is ami zavaró volt itt, de részletekbe sajnos nem mehetek.
Egyébként általában a Tshoot diagramja is elég rosszul látható és tologatni kell ide-oda. Ennek nem értem az értelmét, mert mindezt lehetne jól átláthatóan is. Végül is nem a szemüvegemet akarták tesztelni.A konfigurációnak már motivációmat teljesen elvesztve álltam neki, de úgy gondoltam, hogy igyekszem becsületből megcsinálni amit belefér az időbe. Nem sok fért. L2, L3 és VPN fele-fele, többi dolgot csak elolvastam, hogy mégis mire számíthattam volna services, security terén, IPv6 sem fért az időbe. A fél óra amit vesztettem a Tshoot-nál sem segített volna. Igaz nem is kapkodtam.
A tanulság, hogy bizony nehéz megmondani mikor áll valaki készen a laborvizsgára. Én nem voltam. Hiába vélem úgy, hogy értem a technológiát és itthon nyugodt körülmények között elfogadhatóan megtudom csinálni a laborokat ez még nagyon kevés a sikeres labor vizsgához.
Szokásos kérdés, hogy mennyit készültem rá. nem mintha releváns lenne, hiszen nem sikerült, de csak, hogy ne tartson senki felelőtlennek leírom mennyi felkészülés után mertem vállalni a próbálkozást:
a CCIE elmélet január eleje óta van meg és azóta minden nap átlag kb. 4 órát laboroztam, mondjuk durván olyan 1000 óra. Ebben nincs benne persze az elméleti vizsga előtti felkészülés, laborozás, vagy a CCNP/CCNA, ez csak a laborra.
Ez alatt végigmentem egyszer a Narbik CCNP to CCIE könyvén (szerintem nagyon jó kezdésnek CCIE elmélet után). Végigcsináltam az INE laborokat, a nagy és TS laborokat kétszer. Elhasználtam ami volt 1200 token (8 token egy nagy labor, kivéve a hardware-es TS laborok, ami 10 token per óra), de a gyakorlás nagyobb része saját hardveren, nem online laborral ment. (Leginkább GNS3 illetve proxmox-on 20 db CRS1000V virtualizálva + 2 db igazi switch).A továbbiakban megpróbálok beszerezni annyi TS labort gyakorolni, amennyit csak lehet.
A hardveres INE TS labokat is szeretném átdolgozni offline-ra. (Ehhez lehet kéne két db 48 port-os olcsó 2950-es switch break out-nak. Ha valaki tud esetleg megköszönöm, ha küld egy privit.)
Ha valaki tud javasolni lehetőleg ingyenes TS/konfig laborokat azt is megköszönöm.
Illetve ha vala tud valami a cisco360 programról, elérhetp laborjairól, az is hasznos infó lenne.
Most úgy érzem, hogy az INE nem tud többet nyújtani.Természetesen csalódott vagyok és nyomorultul érzem magam, de azzal tisztában vagyok, hogy nem voltam kész. És hogy mikor leszek, vagy leszek-e egyáltalán, arra most tippelni sem merek.
-
soma314
tag
válasz
BlackJapan
#14438
üzenetére
én leirtam alább hogyan lehet feltolni a 16 Mb-osra is soros konzol porton keresztül. Én kipróbáltam és elindult. Hogy mennyire stabil, és hogy az összes IOS 15 feature-t tudta-e? nem tudom, de ahogy irtam nincs is igazán jelentősége
-
soma314
tag
válasz
BlackJapan
#14435
üzenetére
Szerintem kétféle út van otthoni labor épitésére:
1 - minél olcsóbban megúszni a dolgot, hiszen, nem tudni biztosan, hogy pár év mulva mi kell majd és mi nem.
Ebből a szempontból én vennék egy darab sima router-t (nekem 2600 valamik voltak és CCNA-re teljesen elég volt. Vennék egy multilazer switch-et. Én egy 3550-est vennék az olcsó vonalon. Nekem is volt 2 db és emlékeim szerint "mindent tudtak" amire akkoriban szükségem volt. Ebből vennék 2 db-ot. Úgy rémlik a routing dolgokat egy jó IOS verzióvan és megfelelő SDM beállitásokkal tudta CCNP vizsga szintjén. Talán IPv6 és vrf aware területeken voltak hiányosságok. Már nem esküszük meg rá ha valakit érdekel, akkor a cisco feature navigátor tud segiteni a konkrét tipus tekintetében.
Vennék emellé egy darab 2950-eset.
Ezzel a szettel lesz ugye 3 db routolni és 3 db switch-elni képes eszköz ami 4 dobozban testesül meg.
Én is nagyon ösztönzöm a kábelteszter, krimpelő beszerzését. Egy "vagyont" lehet spórolni, ha 10 2 m-es kábel helyett 1 20 métereset veszel és darabolod. Mégha kell venni ugye RJ45-ös dugókat is.Ezek a régi eszközök ugyanis nem ismerik fel a másik oldalt (mdix). Ezért attól függőn, hogy router-t kötsz össze switch-el (straight) vagy router-t router-rel, switch-et switch-el (cross) másfajta kábel kellhet.
Ennek a modern eszközöknél már egyre kisebb relevenciája van.
Amit még vennék az pár darab valamilyen kábel toldó: https://ipon.hu/shop/termek/startech-utp-toldo-feher-3cm-rj45coupler/703635
A linken rendkivül drágán adják szerintem. Én kb 250 Ft vettem darabját amikor kellett. Ez akkor jó, ha kellene egy hosszabb kábel, de csak több rövidebb van, illetva, ha egy straight kábelt toldasz egy cross-szal, akkor lesz egy hosszabb cross kábeled. De lehet vele toldani a konzol port rollover kábelét is.Amit hanyagolnék, az a soros DTE-DCE kábel és a soros (pl T1) portok. Régebben nagyobb jelnetősége volt ezeknek is a fram relay miatt. Ma még talán van frame relay a CCNP RS aktuális anyagban, de biztos,ki fog kerülni. CCNA RS-ből már kikerült. Ahogy a CCIE RS-ből is.
A PPP dolgok gyakorlására pedig ott van a PPPoE (ppp over ethernet). Ehhez persze kell egy kicsit konfigolni, de ha van rá igény szivesen leirok egy template-et, amit csak be kell másolni.
Persze ha az olcsó router-ben van ilyen, az nem baj, de hogy használ is tudd, ahhoz minimum két router és a DTE-DCE kábel. Szerintem nem éri meg a befektetést.
No meg lehet a soros portos dolgokat gyakorolni a packet tracer-ben, GNS3-ban, EVE-NG-ben....szóval szimulátoron illetve virtuális eszközökön.
2 - a másik út a kicsit előre gondolkodós. Mondjuk készülsz a CCNA RS-re, de tudod, hogy akarsz majd a CCNP RS-re is menni elég jó eséllyel.
Ebben az esetben 3560-ast vennék. min 3 max 4 db-ot. Router-ből maximum valami nagyon olcsót, de akár nem is vennék router-t.Amire én nem költenék az a 3750. (Nekem 2 db 3560 és 2 db 3750-esem van).
A 3750 annyival "több" hogy úgynevezett stack-elhető eszköz. Ez a CCNP-ben téma, de kb 2 parancs az egész és a lányeg a technológiai koncepció megértése, nem a konfigurálása.
Ez a feature az életben viszont hasznos, ezért a 3750-esek jellenzően jóval drágábbak.CCIE szinten elvileg olyen 3560-ra, illetve 3750-re lenne szükség, amin ISO 15 futtatható. Sajnos amik hivatalosan támogatják az IOS 15-öt, azzok iszonyú drágák.
Maradnak azok, amik nem. Ilyen az összes PoE-es. Nekem csak ilyenek vannak. A PoE ugyanis téma a CCNP RS-en is. Persze ez sem több 2-3 parancsnál.
A CCIE laborra készülök és teljesen megteszik. 12.2 IOS-el mindent tudnak az IPv6 first hop security kivételével.
Azközök flash memóriájának mérete nem teszi lehetővé a 15-ös IOS feltolását rájuk. No de van rá mód, hogy a konyol porton keresztül töltszük fel az IOS-t és akkor működnek 15-össel is. No ez persze eltart egy darabig mégha az ember fel veszi a konyol port sebességét a maximális 115200 boud-ra, akkor is vagy 15 perc switch-enként.
A 3560/3570-esek vs 3550 témában még megfontolandó, hogy az újabbak tipusok lényegesen csendesebbek mint a 3550. Sőt én dolgoztam 3560-C-vel ami állom switch lenne az itthoni laboromba. Kicsi és passziv hűtése van! igaz portszámban nem tűl sok, de ami egy otthoni laborba kell, arra bőven sok.
3 - ez igazából a második út "oldalazó" verziója . Vagyis, ha készülsz a CCNA RS-re, de sejted, hogy érdekel majd utána más téma: wireless vagy collaboration (video, voice)
Ez esetben olyen switch kell ami tudja a PoE-net, hiszen az Access point-okat, telefonokat, ip kamerákat táplálni kell árammal is.Amire még érdemes gondolni a laborépités előtt:
- ha elmerűlsz a témában, akkor óhatatlanul egyre többet fogsz GNS3-t vagy Eve-NG -t használni. Bár az utóbbi időben sok előrelépés történt, de switch-et még mindig nem lehet teljesen virtualizálni. Ezért amikor a legelső laborodat is épited, akkor az lebegjen a szemed előtt, hogy a router csak átmenetileg fog búgni nálad, a switch-ek viszont sokáig.- vannak nagyon olcsó eszközök, de nagy részük lehet kidobott pénz. Sőt vannak drágák, amik kidobott pénzek. Én soha nem vennék például terminál server-t revers telnetre. Ezek olyan router-ek, amikre lehet "oktopusz kábelt" csatlakoztani, amit több eszköz konzol port-jába lehet csatlakoztatni. A terminál szerverbe betelnetezve pedig elérheted a többi eszközödet konzol port szinten. ("Reverse telnet") Ez nem feltétlenül butaság, ha a laborod a garázsban búg, mig te a hálóban konfigurálod. Viszont iszonyat pénzt kérnek értük.
Egyrészről ha már kicsit jobban ért már hozzá valaki, akkor egy 2 eFt-os switch-el és eszközönként egy-egy ethernet port beáldozásával simán lehet telnetezni közvetlenül minden eszközbe. Persze nem árt ha vrf aware az eszköz és a management port-ot külön vrf-ba hagyjuk.
Ha régebbi eszköz van és nem akarunk lemondani a konzolos kapcsolatról, akkor pedig egy olcsó számitógép (kb 5 eFt-os P4-es) 4 soros port-tal mér rádugható a 4 switch-re. A P4-esbe belépünk SSH-val és a minicom-mal meg a konzol port-jára az adott switch-nek. Ha valaki windows-os, akkor remote desktop vagy VNC és a P4-esről Putty.Ami viszont mindent ver ebben a kérdésben, az a már korábban emlitett RJ45 toldó csatlakozó. Ha van lehetőség fizikai kábeleket behúzni az eszközök (router-ek, switch-ek) és a munkaállomásod közé.
Búg a garázsban 4 switch (vagy akár sokkal több eszköz). Mindegyik konzol portjába bedugsz egy sima straight kábelt és behozod a hálószobába amol a számitógéped soros portjára dugtad a szép kék rollover kábelt. A toldót felhasználva pedig éppen arra az közre csatlakozol, amelyikre akarsz.
olcsó, semmi perc alatt megvan, de ezt nem lehet wifi-n ál használni.Amire szintén gondolni kell, hogy bár az igazi vas mindig a legjobb, de CCIE szinten egy full size lab 20 router + 4 multilayer switch. Ez nem csak egy kisebb vagyon, de még a biztositékot is leveri a legtöbb helyen. Ha meg nem, akkor bizony megpörgeti a villanyórát! no meg a feleségbarát elhelyezésükről ne is beszéljünk.
A másik ilyen felesleges dolog a hub. Van aki a csomagelemzések miatt minden eszközét egy hub-ra köti és arra dugva egy számitógépet lehet szépen elemezni a wireshark-al. Ez megint nem butaság, de egy hub az eszközök között bizony kihat pár dologra (pl spanning-tree-nél share media lesz a port). Erre a célra mondjuk pont jó egy sok portos 2950-es switch, amit úgy dobnak ma már az ember után, de tudja a portok kitükrözését. Persze ezt megint konfigurálni kell, de csak egyszer és nem ördöngősség. Erre is szivesen adok template-ek ha kell valakinek.
Szóval visszafogottan az elején max 1 db router, max 1 db layer 2-s switch és 2-4 multilayer switch.
-
soma314
tag
válasz
stfreddy
#14290
üzenetére
köszi a beszámolót!
Én RS vonalon küzdök, szintén INE-s anyagokból készülve. Az RS-nél csak az írásbeli része az IS-IS. A videók alapján nálam nem állt össze a kép a témában. Volt lehetőségem és megnéztem az SP-s IS-IS videókat is. Hát többet vártam...
Nemsokára kellene mennem első labor próbálkozásra és elég sok helyről olvasom, amit te is írtál az SP-re. A diagnosztikán elég könnyű elcsúszni, mert csak 30 perc és elvileg csak 3 ticket, de sok a félrevezető infó.Mostanában a nagy laborokat használom online az INE-nél és több labornál is belefutottam hibás működésbe. Írtam nekik, hogy vajon mi a bibi, ha próbaképpen feltöltetem velük az intit configeket, majd abba belemásolom a workbook-ban megadott megoldást és mégsem működik a dolog. Erre persze kaptam egy udvarias általános levelet, meg egy linket a fórumukhoz, de hetek óta semmi konkrét.
Az is "gond", hogy elég kevés a full / TS labor, DIAG gyakorlat meg talán csak 2 van. Van egy elég terjedelmes TS videorész a bundle-ban, amit megvettem, de ott olyan laborokat tárgzalnak, ami nem betölthető online. A Narbik laborokhoz hasonlóan ugyanis nem 4 hanem 8 switch-et használnak. Ezeknek ugyan megvan az init config-juk, de mire átdolgozom 4 switch-re / GNS3-ra, az sok meló lesz.
-
soma314
tag
válasz
FecoGee
#14136
üzenetére
Bár igazad van a valós világ tekintetében, de én láttam már sok hasonló Cisco vizsga kérdést, ahol a kérdés úgy szól, hogy mi lehet "a legvalószínűbb ok" és közvetetten adnak csak információt.
Lerajzoltam ezt a példát kicsit másképpen az egyszerűbb érthetőség miatt:
Bár nem adják meg sem a bridge priority értékeit, sem a MAC címeket, sem a port prioritásokat, sem, hogy milyen protokol fut, sem a cost-okat, de feltételezhetjük, hogy az ábra egy konvergencián túl lévő állapotot mutat default beállításokkal, mivel ugye más infó nincs.
Ha ebből indulunk ki, akkor tudjuk, hogy a root bridge az SW3 mivel ennek nincs egyik portja sem blocking state-ben.
Feltételezhetjük, hogy hagyományos STP (vagy PVSTP+, egy vlan-re vonatkoztatva ha Cisco) fut mindegyik switch-en, ugyanis, ha rapid vagy multiple lenne, akkor discarding state-ről beszélnénk és nem blocking state-ről. (máig nem értem egyébként miért nevezték át, ha a "bridge" megnevezés meg maradt).Látjuk, hogy mindegyik port fastethernet, tehát ha nincs más beállítva, akkor mindegyik link cost-ja azonos.
A hub csak zavarkeltésre van. Akkor lehetne jelentősége, ha meg kéne határozni a hub felé mutató port-ok státuszát rapid vagy multiple stp-nél.
A port prioritások pedig default-ban a nagyobb port szám fele emelkedik. (itt még lehetne kavarni, ha az egyik switch egyik portja mondjuk fastethernet 0/2, a másik meg gigabit 0/1 lenne. Ehhez kell tudni, hogy a stp portszám az alacsonyabb sebességű port majd a magasabb sebességű sorrendben mennek). Ugye fontos még, hogy a root oldal felöl nézzük ezt a link vonatkozásában. Ezért rajzoltam X-re a linkeket.
A valóságba nyilván nem kötne így össze switch-eket az ember. És a valóságban nem feltételezget, hanem egy show spanning-tree paranccsal megnézi mi van. Viszont lehetnek ilyen "aljas" példák a vizsgákon.
-
soma314
tag
válasz
_kovi_
#14129
üzenetére
Spanning tree-nél
Először meg kell találni (a protokolnak, vagy egy feladatban neked) melyik switch lesz a Root Bridge
A példában itt a SW3-as. Amúgy ugye a legalacsonyabb bridge id-jű azaz a legalacsonyabb bridge priority-jű vagy egyező prioritások esetén a legkisebb MAC című switch.
A root bridge minden aktív portja designated port. Azaz olyan port, amin átmennek az adatok, de nem a root bridge felé mutat, hanem attól "távolodik", downstream-ben van.Ezután meg kell keresni minden egyes switch-nél, hogy cost szerint melyik portja van a legközelebb a root bridge-hez. Ezek lesznek a root portok, amin szintén minden adat át tud menni. (Ha több linkkel is csatlakozik a root bridge felé, akkor az alacsonyabb port priority-vel rendelkező port (ami default-ban az alacsonyabb port szám) lesz. Ez a root bridge felől kell nézni! (Tehát ha az SW3 a root bridge ami csatlakozik két linkkel az SW2-höz és a két link az SW3 FA0/2 - SW2 Fa0/3 és SW3 Fa0/3 - SW2 Fa0/2, akkor az SW2-őn (default beállítások mellett) az Fa0/3-as lesz a root port hiába az a nagyobb port számú az SW2-őn.)
Ha megvannak a root portok minden switch-en, akkor az összes többi link blokkolva lesz méghozzá úgy, hogy a magasabb bridge id-vel rendelkező switch oldalán lévő port esik blocking state-be. Amin ugye a BPDU-n kívül nem megy át adat.
A példát konkrétan megnézve:
root bridge SW3root portok: SW1 fa 0/1, SW2 fa 0/2
designated portok: SW2 fa 0/0
Hogy miért nincs mind az SW1 fa 0/0 és SW2 fa 0/0 is blocking state-ben? Egyrészt, mert a spanning tree nem úgy működik! A spanning tree-nél, ahogy írtam feljebb mindig a link egyik vége (az alacsonyabb bridge id-jű oldal) van csak block-ing state-ben.
Hogy ez miért jó: mert biztosítja a hurokmentességet és egy konvergencia során a lehető legkevesebb port-nak kell konvergálnia.Másrészt, képzeld el azt a szituációt, hogy az SW1 és SW2 közötti linkbe beteszel egy hub-ot vagy egy olyan switch-et ami nem ismeri a SPT-t (vagy le van rajta kapcsolva), majd a hub-ra, switch-re végberendezéseket kapcsolsz. Ha a link mindkét vége blocking state-ben lenne, akkor a végberendezések (pl számítógépek) nem tudnának kommunikálni az SW3-al és az arra kapcsolt végberendezésekkel.
-
soma314
tag
nem mindegy, hogy egy légkondicionált irodába a szomszéd szobába telepített szünetmentes tápellátásról hajtva vagy mondjuk egy sivatagi út mellett egy forgalom irányító lámpa szerelvényszekrénybe van telepítve egy switch ahol éjjel -10 nappal +50 fok van.
Nem mindegy, hogy a rendelkezésre állás sem: nem mindegy, hogy egy tartalék switch-et a hóna alá csapva valaki lesétál egy emeletet és addig nem tud az iroda e-irodaként működni, vagy, hogy a példánál maradjak nem mindegy, hogy mondjuk egy nagyváros legforgalmasabb kereszteződésében sárgán villognak a lámpák amitől dugó lesz az egész városban pár perc alatt.
Ugye az ipari switch azért sarkalatos dolog, mert egy végponti eszköz (egy csatornán) egyszerre csak egy switch-hez tud csatlakozni, ha az elszáll, akkor az arra csatlakoztatott eszközök mindegyike elérhetetlenné válik. (Persze vannak több kommunikációs csatornát fenntartó berendezések, pl. két rezes hálókártya két subnetre csatlakozva a végberendezésben, vagy fallback-ként a második, esetleg a második wireless).
Valóban szeretik a gyűrűtopológiát sokan, pont azért mert ha kiesik egy switch, a másik irányból még működik a rendszer. Erre persze jó esetben nem a spanning tree-t alkalmazzák. Sok ipari switch gyártónak van saját gyűrű topológiát támogató rendszere (pl. Hirschmann-nál a HIPER-ring). A Cisco-s REP én úgy hittem inkább a SP területen közkedvelt (az ME-s switch-ek tudják).
Ugye ezek a gyűrűs topológiák csak gyűrű topológiában használhatóak, míg a spanning tree-nél elvileg nincs topológia megkötés (bár az RSTP-nél, MST-nél kifejezetten ellenjavalt a gyűrű topológia alkalmazása - count to infinity probléma miatt).
A gyűrű technológiák gyűrűben elvileg sokkal gyorsabb konvergenciára képesek.A robotok-kat én nem hoznám példának, legalábbis nem a gyártásban alkalmazott robotokat. Azok többnyire légkondicionált, kezelt levegőjű gyártási környezetben dolgoznak pont azért mert drágák és olcsóbb a környezetet megteremteni nekik, mint ellenállóvá tenni őket. Oda szerintem pont jó a legtöbb enterprise cucc.
Ha autómatizálásról van szó ipari környezetben akkor nekem inkább a közlekedés, a közművek, a hajózás jut eszembe, ahol jelentkeznek ezek a problémák.
Amire a jövő szempontjából érdemes fókuszálni a wireless-ben otthon lévőknek, az szerintem az önvezető autók. Itt hihetetlen lehetőségek vannak, ha az autók szinkronizálni tudják a mozgásukat egymással, egy "dugó oszlató" városi vezérlő rendszerrel...
(Műszakilag, jogilag egyébként pont az a gátja az önvezető autók elterjedésének, hogy lenne jó pár átmeneti évtized, amíg önvezető autók és ember által vezetettek együtt kellene közlekedjenek, ami sokkal nagyobb kihívás az önvezető járművekre.)
)
A Wireshark nálam eddig is #1 volt minden ingyenes program között! (Nem tudok jobb fizetős alternatívát se.) 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
. Kicsit kalandos volt, mert az értékelő script nem szeretett és reread-et kellett kérnem, aminek az eredményére 3 hetet kellett várni, ezért is csak most írom.
Új hozzászólás Aktív témák
Hirdetés
- Kérlek használd a keresőt, mielőtt kérdezel!
- Olvasd el a téma összefoglalót mielőtt kérdezel!
- A dumpok és a warez tiltott témának számítanak!
- Samsung Galaxy S23 Ultra - non plus ultra
- Borotva, szakállnyíró, szakállvágó topic
- Nem indul és mi a baja a gépemnek topik
- Synology NAS
- Kazy Computers - Fehérvár - Megbízható?
- One otthoni szolgáltatások (TV, internet, telefon)
- Melyik tápegységet vegyem?
- NVIDIA GeForce RTX 3060 Ti / 3070 / 3070 Ti (GA104)
- Milyen billentyűzetet vegyek?
- Autós topik
- További aktív témák...
- Makulátlan, új állapotú Garmin Forerunner 255 music fekete
- Szinte új állapotú Samsung Galaxy A54 5G 6/128GB
- Apple iPhone 13Pro 128GB Kártyafüggetlen 1Év Garanciával
- Garmin Fenix 8 Amoled 51mm Sapphire Carbon Gray DLC - Használt, karcmentes
- Nitro ANV15-51 15.6" FHD IPS i5-13420H RTX 4050 16GB 512GB NVMe magyar vbill ujjlolv gar
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
- HP Laptop 15-fc0026nh (AY7E1EA)
- Bomba ár! Dell Latitude 7320 - i5-11GEN I 8GB I 512SSD I HDMI I 13,3" FHD I Cam I W11 I Garancia!
- 1-12 részletre.Új noblechairs EPIC műbőr FEKETE - FEKETE. 2 év garancia!
- BESZÁMÍTÁS! Microsoft XBOX Series S 512GB játékkonzol garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest