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

• #12847 Poultier tag cisco007 #12846

  Új Válasz 2017-03-17 18:07:50 #12847

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Poultier

  tag

  válasz cisco007 #12846 üzenetére

  Szia!
  A jó szakdolgozatból nagyon tudsz profitálni hosszabb távon, sztem nem érdemes kommersz témákkal "elkummantgatni". Egy SDN-el nem lőhetsz mellé, eléggé "curious" tudásra tehetsz szert vele, igaz melósabb, mint a többi téma.

• #12850 soma314 tag cisco007 #12846

  Új Válasz 2017-03-17 18:26:02 #12850

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

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

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

• #12855 FecoGee Topikgazda cisco007 #12854

  Új Válasz 2017-03-17 22:07:06 #12855

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  FecoGee

  Topikgazda

  válasz cisco007 #12854 üzenetére

  Ha slagertemat akarsz, esetleg IoT. Abbol is szepet lehetne irni.

  [ Szerkesztve ]

• #14107 soma314 tag cisco007 #14106

  Új Válasz 2018-03-25 10:19:40 #14107

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

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

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

• #14110 soma314 tag cisco007 #14109

  Új Válasz 2018-03-25 13:35:42 #14110

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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.

• #14113 FecoGee Topikgazda cisco007 #14112

  Új Válasz 2018-03-25 18:13:50 #14113

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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 .

• #15297 crok Topikgazda cisco007 #15296

  Új Válasz 2019-12-12 13:38:16 #15297

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  crok

  Topikgazda

  válasz cisco007 #15296 üzenetére

  Hogy készült a pcap, milyen eszközön, milyen setup-al? Biztos hogy ez egy és ugyanaz a TCP stream? Nem véletlen egy LAN interface-en készült amin van policy-based routing és visszatolja kifelé is a router ugyanazt a csomagot csak egy másik eszköznek?

  [ Szerkesztve ]

  Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..

• #15300 crok Topikgazda cisco007 #15299

  Új Válasz 2019-12-12 14:43:27 #15300

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

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

  [ Szerkesztve ]

  Ha egy hozzászólásomban linket látsz az hasznos referencia, hivatkozás vagy leírás és erősen ajánlott vagy minimum érdemes elolvasni. A Logout bejegyzéseim tele vannak hasznos Android tippekkel-trükkökkel, alkalmazásajánlással..

• #15301 soma314 tag cisco007 #15296

  Új Válasz 2019-12-12 15:02:59 #15301

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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!

• #15307 soma314 tag cisco007 #15306

  Új Válasz 2019-12-13 12:36:34 #15307

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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

• #16471 Cyber_Bird senior tag cisco007 #16470

  Új Válasz 2023-04-19 13:56:45 #16471

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Cyber_Bird

  senior tag

  válasz cisco007 #16470 üzenetére

  Lehet ez lenne a helyes megoldas, de ebben az esetben is ket ASAv-t kellene felhuzni.
  Plusz heggeszhetem ossze kezzel a templatet.
  A jovoben, ha valami hasonlo request lesz, szerintem ezt fogom csinalni, szoval koszi a megerositest, hogy ez igy mukodhet.

  [ Szerkesztve ]

• #16615 Ripper17 tag cisco007 #16614

  Új Válasz 2023-11-08 00:29:37 #16615

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  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/

  [ Szerkesztve ]

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