Keresés

Új hozzászólás Aktív témák

  • 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 Yeffy #14560 üzenetére

    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

    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 is

    amú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

    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 kavik #14720 üzenetére

    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 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

    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 FecoGee #14775 üzenetére

    köszönöm a választ és a linkeket
    pedig olvastam is őket, amikor felkerültek a blog-odra, de valahogy kiesett már

  • soma314

    tag

    válasz Yeffy #14918 üzenetére

    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

    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.

    [ Szerkesztve ]

  • 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 #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 local

    junior á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 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 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"

    [ Szerkesztve ]

  • soma314

    tag

    én egyébként pont ma tettem le a CCNA wireless.t a 200-355-öt, de ahogy látom ebből már nem lesz CCNP-m :)
    van CCNP R&S-em, ilyenkor a CCNP wireless megszerzéséhez kellene letenni a 300-401-et is, vagy csak elég lenne a 300-425 és 300-430?

    [ Szerkesztve ]

  • 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?

    [ Szerkesztve ]

  • 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 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 gyakorlatban

    CCNP
    - 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 is

    Szigorú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 #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 labort

    Ké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 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 #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 ÁrPi2 #15002 üzenetére

    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 ad

    Egyé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 ÁrPi2 #15012 üzenetére

    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

    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

    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 tusi_ #15059 üzenetére

    Essentials-al VRRP sincs 9200l-hez? mert azzal azért kiváltható lenne az HSRP hiánya

    Én a csatolt infót találtam, de hogy az alapjána VRRP benne van-e, vagy nincs, azt nehéz eldönteni

    [ Szerkesztve ]

  • 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

    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 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 Yeffy #15124 üzenetére

    é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 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

    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 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 crok #15134 üzenetére

    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 kmisi99 #15161 üzenetére

    Tudom, hogy aki régebben megcsinálta az konnyen beszél, de szerintem is simán meg lehet csinálni a routibgot és a ts-t ennyi idő alatt. A ts-re nem kell külön készülni csak atismetelned majd a switching-et

  • 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

    válasz Yeffy #15194 üzenetére

    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 ELSO

    Itt 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 Yeffy #15198 üzenetére

    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

    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

    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 Yeffy #15255 üzenetére

    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.

    [ Szerkesztve ]

  • 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.

    [ Szerkesztve ]

  • 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 evilskati #15269 üzenetére

    én arra gondoltam, hogy kihoznak olyan enterprise-nak szánt eszközöket, ahol nincs már konzol port
    hát igen a reportolás van ahol az fontos

  • 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 cisco007 #15306 üzenetére

    ez a duplikációt megmagyarázná, de azt, hogy duplikált csomagok között, látszólag következetlenül hol rákerül a dot1q tag hol nem, azt nem
    nekem minden esetre furcsa

Új hozzászólás Aktív témák