- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Mr. Y: Motoros sztorik #06
- Magga: PLEX: multimédia az egész lakásban
- sziku69: Fűzzük össze a szavakat :)
- bambano: Bambanő háza tája
- vrob: Az IBM PC és a játékok a 80-as években
- Tomasz72: Ventilátor upgrade
- Parci: Milyen mosógépet vegyek?
- eBay-es kütyük kis pénzért
-
LOGOUT
--- 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
-
Ripper17
tag
válasz
cisco007
#16614
üzenetére
APkra ez a legtisztább megoldás: https://www.ipmechanic.net/2017/07/correct-way-to-factory-reset-cisco-ap.html
Switchekre, routerekre szerintem amit mondasz az elég. WLCkre pedig ugyanúgy factory reset kellene.
szenzitiv adat nem marad ezeken, ha az nvramot ès a flasht legyalulod (delete /f /r flash:* vagy megküldheted format paranccsal is
)Régebbi eszközökön a squeeze is hasznos lehet: https://ccie20728.wordpress.com/2013/07/08/c2811-cf-memory-cards-and-the-squeeze-command/
-
#16471
Cyber_Bird
senior tag
cisco007
#16470
Cyber_Bird
senior tag
-
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! -
crok
Topikgazda
válasz
cisco007
#15299
üzenetére
Adott pl. egy router egy LAN interface-el. Mondjuk ő a HSRP primary. Mindenki neki küldi a csomagját ha ki akar jutni az adott hálóból. A routeren van mondjuk kifelé egy default route. De van mondjuk pár cél IP amit "kiszervezel" egy másik routeren keresztül elérhetővé, mondjuk mert egy Zscaler proxy tunnel felé ne az MPLS-en keresztül hanem az Internetet termináló routeren keresztül menjen alapvetően a forgalom. Erre mondjuk csinálhatsz egy track-et (hogy van-e net) és egy track-elt policy-based routing-ot ami ha bejön a csomag akkor LAN-on átküldi a másik routerenek amin keresztül elérhető az Internet és a Zscaler proxy szolgáltatás. Ha a track elmegy mert nincs net mert pl. rossz a net linkje akkor az MPLS-en még mehet a forgalom egy másik Internetkijárón, failover-ként.. Nem szeretem ezt a megoldást, nagyon nem, de sokszor látom valamiért mert mások meg szeretik. Csak a kis ISR-eket nagyon le tudja terhelni.. meg a nagyobb routereket is. Na ha ilyenkor a LAN interface-en csinálsz pcap-et vagy a router felé menő switchportra csinálsz SPAN-t akkor előfordul hogy oda és vissza is látod a csomagokat, ugyanazt. Ezt az IP Identification-ből tudod megmondani (mert ilyenkor az ID ugyanaz, vagyis ugyanazt látod kétszer, egyszer a router felé, egyszer meg visszafelé mikor a másik router felé tart a csomag).
Esetleg oszd meg a pcap-et data nélkül, csak a fejléceket, azzal sokat könnyítenél annak aki meg szeretné válaszolni neked ezt ( : Minket nem érdekel a data része úgyse ( :
-
-
FecoGee
Topikgazda
válasz
cisco007
#14112
üzenetére
Hat azert az ipari Cisco picit mas vilag ahogy en latom. Mi vagyunk az IT, az meg az OT (operational technology). A ketto kozott eleg nagy hezag van. A Cisco a Rockwell hatan akar bemaszni ebbe a vilagba mert oriasi zseton van benne. De itt gyuruk vannak, REP, Profinet, CIP meg tarsai. A CCNA Industrial az en ugy tudom hogy pont arrol szol hogy az OT-s ember is ertsen picit az IT-hoz. Nem rossz ebben az iranyban sem tanulni mert egyre nagyobb alatta a piac, de az IT tudasbol ott nem nagyon fogsz megelni, es az IT-ben sem nagyon az OT-s tudasbol
. -
soma314
tag
válasz
cisco007
#14109
üzenetére
azok alapján amiket írsz szerintem a tipikus HR-es hirdetésbe futottál, ahol mindenhez kell érteni (RandS, security) és mindent kell csinálni és beletettek minden divatos frázist a témában (SDN, Cloud, IoT).
Utility cégnél el tudom képzelni az IoT-t, ha távleolvasással megy a mérők leolvasása. Véletlenül nem szolgáltat internetet is?
Ha tényleg mindezt kell majd csinálnod is, akkor az szerintem egy CV-ben jól mutat. Különben is te fogod irni a CV-det, abban aztán azt domborítasz ki amit akarsz. Meg különben is, nem feleséget választasz, hanem munkahelyet ott lesz a próbaidő és ha nem jön be lehet váltani, nem szégyen ott hagyni egy munkahelyet ma már ahol nem azt kapod, amit ígértek/reméltél.
-
soma314
tag
válasz
cisco007
#14106
üzenetére
nem tudom mennyire vehetem magamra a kérdésedet, mert ipari jellegű hálózatokkal van némi tapasztalatom, de én első sorban nem Cisco eszközökkel találkoztam.
Az ipari jelleg is speciális volt. Fogalmazzunk úgy, hogy a területen a működtetett rendszerek üzemzavara, rendelkezésre állása rendkívül kritikus volt. És ezt nem úgy kell érteni, hogy sok pénz esik ki, ha nem megy a hálózat, hanem úgy, hogy emberek kerülhetnek veszélybe.Az én tapasztalatom erre a területre vonatkozik és ennek semmi köze az IoT-hez (sőt szerintem az IoT és az Ipar2.0 is elég távol állnak egymástól).
Amit én tapasztaltam:
- az eszközök tudásukhoz képest drágák voltak az enterprise eszközöktől. Ami ugye abból adódik, hogy a környezettel szemben sokkal ellenállóbbak (hőmérséklet, páratartalom, savas/lugos környezet....).
- Uplinkben találkoztunk csak Gigabit-el, vagy nagyobb sebességgel.
- nagy hangsúlyt kellett fektetni az eszközök szünetmentes tápellátására. Jellemzően egy apró Din sínre pattintható switch is rendelkezik kettős betáplálással.
- voltak speciális, jellemzően gyűjtött hibajelek, amik nem a hálózaton, hanem egy analóg feszmentes kontaktuson jelentek meg
- a készülékeke galavanikus elváláasztása és vagy a távolság miatt a linkek nagy számban relatív alacsony sebességű (100, 1000 Mbps) optikai linkek voltak.
- nagy távolságú digitális átvitelre rézen ISDN volt használva. (A sebesség nem volt szempont.)
- igen a PLC-k miatt nem csak IPv4/IPv6 szaladgált rajtuk (Profinet, serial over IP...). Ezekkel a protokollokkal én max ethernet szintig kellett foglalkozzak. Nem is értek hozzájuk.
- adatbiztonsági okból volt ethernet-TCP/IP to serial layer 1-es váltás is, hogy egy rendszerből egy másik rendszerbe adat jusson át a lehetséges visszahatás minimalizálásávalA fentiek miatt mérnökileg érdekes volt, de hálózati szempontból az enterprise világ sokszor összetettebb. Ott az egyszerűség a rendszerek miatt "követelmény" volt. Ebből adódtak a hálózati problémák. Földrajzilag nagy kiterjedésű layer 2-es kapcsolatok, broadcast domain-ek....
Enterprise világhoz képest a hangsúly a fizikia, adatkapcsolati réteg-en volt hibaelhárítás esetén, nem volt jellemző layer 3-as probléma.Engem megfizettek, nem panaszkodtam emiatt soha. Viszont rendszermérnök is voltam, nem csak hálózati mérnök. Ott elvárás volt, hogy ne csak a hálózat működését, de valamelyest a komplex rendszert is átlásd.
Kb ez olyan, mintha egy bankban lennél hálózati rendszergazda, de át kéne látnod a banki pénzügyek folyamatait is.Ami még negatívum volt, hogy sokat kellett menni, a rendszerek természetéből adódóan ugyanis nem volt lehetőség jellemzően távadminisztrációra.
Találkoztam sok hálózati szempontból ostoba szoftveres megoldással, ami "történelmileg" alakult. Na az érdekes volt, hogy ezekre a szoftver problémákra hogyan találtam hálózati megoldást. A szoftvereket ugyanis "kőbe vésettnek" kellett tekinteni. A módosításuk rendkívül drága lett volna. -
soma314
tag
válasz
cisco007
#12846
üzenetére
Ha a szimulátorok / emulátorok (bár az általad felsoroltak közül egyetlen egy a szimulátor, a többi emulátor) a téma, akkor még van pár dolog, aminek érdemes utána nézni:
- IOU, IOL (IOS on UNIX/LINUX)
- virtuális routerek futtatása hyperviser-en
-UnetlabA VPN önmagában akkora téma, ami kimeríthetetlen, esetleg egy szakdolgozat, ezek általános bemutatására alkalmas. De én kivennék közölük egyek, és azt mutatnám be részletesen.
A WLAN-hez bár nem értek, de szerintem az is eléggé összetett téma. Egyébként már eleve rossz a hozzáállás mérnökileg, ha a termékből akarsz tervezni (buttom up tervezés) és nem a feladathoz kiválasztani az "ideális" terméket a tervezés során.
Én a helyedben maradnék a szimulátorok / emulátorok használatánál és bemutatni, hogy milyen hasznos lehet ez egy új rendszer bevezetése előtt a tesztelés során még a staging előtt. Vagy egy hibakeresésnél, troubleshooting-nál, hogy az éles rendszeren történő változtatás előtt, annak virtuális modelljén végigcsinálva előre nem várt következmények is felismerhetőek.
Nyilvánvaló, hogy az oktatásban van a legnagyobb szerepük, de szerintem a fenti modellezésről lehetne egy szép dolgozatot összeröffenteni. És még szerintem eredeti téma is lenne. -
)
.
Új hozzászólás Aktív témák
Hirdetés
FecoGee
crok- 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!
- GARIS! Lian Li HydroShift !!!! LCD !!!! 360TL (RGB)
- Nitro ANV15-51 15.6" FHD IPS i5-13420H RTX 4050 16GB 512GB NVMe magyar vbill ujjlolv gar
- KFA2 RTX 3060 12GB GDDR6 1-CLICK OC Eladó!
- ZOTAC RTX 3060 12GB GDDR6 GAMING Eladó!
- DELL LATITUDE 7400, 14" FHD IPS, i7-8665U CPU, 16GB DDR4, 256GB SSD, W11, 27% áfás számla, 1 év gara
- Csere-Beszámítás! Asus Tuf RTX 5070Ti 16GB GDDR7 Videokártya! Bemutató darab!
- DELL PowerEdge R630 rack szerver barebone - 2xSocket 2011v4 , 24x DDR4 DIMM, H330 RAID, 39369Ft+ÁFA
- BESZÁMÍTÁS! Asus B760M i7 12700KF 32GB DDR4 512GB SSD RX 6800 16GB Rampage SHIVA FSP 700W
- Azonnali készpénzes Microsoft XBOX Series S és Series X felvásárlás személyesen/csomagküldéssel
- DELL PowerEdge R640 rack szerver - 2xGold 6138 (20c/40t, 2.0/3.7GHz), 64GB RAM,4x1G, H730 1GB, áfás
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest