- Milyen okostelefont vegyek?
- Apple iPhone 16 Pro - rutinvizsga
- Amazfit Active 2 NFC - jó kör
- Milyen hagyományos (nem okos-) telefont vegyek?
- Samsung Galaxy S23 Ultra - non plus ultra
- Motorola Edge 50 Ultra - szépen kifaragták
- Apple Watch Sport - ez is csak egy okosóra
- Redmi Note 12 4G - valaki fizetni fog
- iPhone topik
- Samsung Galaxy A56 - megbízható középszerűség
-
Mobilarena
--- 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
-
-
-
FecoGee
Topikgazda
válasz
TheProb
#13006
üzenetére
Eloszor nezd meg, miden stackport OK -e es teljes -e a gyuru (nem lehet -e split-brain ahogy crok irta).
>sh sw stack-ring spee
Stack Ring Speed : 32G
Stack Ring Configuration: Full
Stack Ring Protocol : StackWisePlus>sh sw stack-ports
Switch # Port 1 Port 2
-------- ------ ------
1 Ok Ok
2 Ok Ok
3 Ok OkHa igen, egyszerre egyet kihuzva nem lesz gond.
-
soma314
tag
válasz
TheProb
#12418
üzenetére
Elnézést nem vagyok kiakadva csak valahogy úgy tűnt, hogy ötletelünk jó szándékkal, de az infók beszerzése, felvázolt elméleti lehetőségek leellenőrzése valahogy elmarad és nyűgnek tűnik.
végül is valahol nyilván neked a legfontosabb tudni mi lehet az okaakkor összefoglalom azokat amiket leirtak itt többen lehetséges elméletekként és érdemes leellenőrizned
- "takaritónő elmélet" lehet, hogy az adott időszakban valaki valamit csinál. kihúz egy kábelt, bedug egy kábelt. Lan partin nyomják a doom-ot a biztonsági őrök....
- legvalószínűbb: szolgáltató oldali kinyirbálása azon host-oknak, amik nincsenek használatban. Lehet, hogy a ti oldalatokról úgy tűnik, hogy folyamatos internet kapcsolat van, de az is lehet, hogy az internetszolgáltató lekapcsol mindenkit akinek nincs forgalma. Kívülről ilyenkor hiába próbálnak kapcsolatot kezdeményezni.
- CAM table timeout. Amig folyamatos forgalom van, addig a switch cam táblájában van melyik porton melyik MAC cim lakozik. Ha ez eléri a timeout-ot (Cisco-nál ez általában default-ban 300 sec), akkor újabb unknown unicast-ként keres mindenkit, ami tranziens jelleggel megnöveli a broadcast jellgű forgalmat. Ettől simán lehet egy pár elveszett ping.
Simán lehet az is, hogy egyszerűen csak az üzemidőn kívüli switch-ek és router üres CAM táblákkal mire kiküldi az ARP-okat elveszik egy ping válasz és lehet, hogy már az generál egy riasztást (ez persze nem tarthat percekig, sőt másodpercekig sem)- STP/L3 konvergencia. Ha hagyományos STP fut default beállításokkal, akkor 50- mp-es kieséssel számolhatsz egy konvergenciánál. Ha RapidSTP, vagy MST akkor ugyan a konvergencia (egy jól megtervezett hálózaton) mondjuk csak 2 mp, de minden RSTP konvergencia (Topology Change Notification) esetén a root bridge küld egy TCA-t (TC Acknowladgement-et) aminek hatására a switchek kitörlik a CAM táblájukat és lásd előző pont. Ha layer 3 routing konvergencia van akkor ahogy irtam, ha nincs optimalizálva, akkor akár percekig is tarthat.
- azt is el tudom képzelni, hogy egy állapottartó tűzfal van az internet felé. Lehet, hogy amig termelés van és a switch-ek forgalom alapján rendszeresen küldenek valami riportokat (SNMP, netflow...) addig tűzfal a site-ról indított forgalom miatt nyitva hagyja a pingelésre is használt port-ot a switch-ek menedzsment címére. Amikor nincs termelés a switch-ek nem generálnak riportokat kifelé, nem jön be semmi befelé, ezért a tűzfal lezárja a host címre irányuló forgalmat.
- lehet az is (hogy mivel fogalmunk sincs milyen) a VPN tunnel sem állandó, hanem on demand jelleggel létezik, ezért üzemidőn kivül ha nincs forgalom, akkor elbontódik, mire kiépül, már sikertelen lesz a pingelése egy vagy több switch-nek
Még biztos tudunk vagy 25 lehetséges scenario-t kitalálni, ami az általad megadott szegényes információra ráillik, de ez nem fog előrébb vinni a probléma megoldásában.
Ez csípőből lövöldözés. Módszerességgel lehet a probléma okához eljutni. -
crok
Topikgazda
válasz
TheProb
#12421
üzenetére
Olyanom volt, hogy non-user interface-re (vagyis uplinkekre.. vagy non-user end-device felé) volt téve switchport block unicast [link] ami miatt a lentebbi switchekre volt hogy nem lehetett belépni mert ugye a parancs hatására ha inaktivitási ideig nem érkezik keret az interface-en akkor az interface alól TCAM-ből kiszedett MAC címre nem tud kimenni a L3 eszköztől a unicast packet mert a keretben található destination MAC nincs a TCAM-ben és nem fogja minden interface-re replikálni (egy nagyon hülye standardot akartak ezzel csinálni hogy "védjék a hálózatot"). A helyzet viszont az, hogy egy switch ha nem történik semmi vele tehát mondjuk static routing van rajta (nincs routing info exchange semmilyen protokollon senkivel) és "nem is történik vele semmi" (nem logol interface up/down, nincs mit SNMP-vel jelenteni.. érted.. semmi..) akkor bizony 5 perc és a management IP-je time-out-ol a TCAM-ből és a switchport block unicast miatt nem is lesz a packet megkeresve se flood-al.. így elhal a telnet, elhal az ssh, elhal a ping.. még a legelső L3 hopról is, még akkor is ha az L3 def.gw. directly connected (: ha a switch valamiért mégiscsak csinálni akar valamit és generál csomagot tehát küld egy darab frame-et és a MAC bekerül a TCAM-be akkor már megint menni fog minden.. mintha mi se történt volna. Ez egyébként megesett már switchekkel is.. meg hálózati nyomtatókkal.. a nyomtató is olyan állat ami magától nem nagyon generál forgalmat hiszen általában őt kérik meg hogy dolgozzon, nem ő kezdeményezi a forgalmat..
-
soma314
tag
válasz
TheProb
#12414
üzenetére
tételesen
- a tököd biztos azt is tudja, hogy miért nem elérhetőek a switch-ek. Ne felejtsed el, hogy te tettél fel egy kérdést, amire ha értelmes választ válrsz akkor információval kell szolgálni.-nem nyilvánvaló, hogy interneten keresztüli VPN kapcsolat van csak azért mert távol, akár nagyon távol vannak egymástól a site-ok
akkor összefoglalmom mennyi derült ki:
- néha nem elérhető egy switch
- vagy néhe nem elérhető több switch ezt nem sikerült eldöntened,
- a kiesés 1-2 perces
- interneten keresztüli VPN kapcsolat köti össze a site-ot, ahol a switch-ek vannak a site-al ahol a monitorozó szerver fut
- nem tudjuk, hogy a VPN kapcsolat L2-es vagy L3-as,
- ha L2-es akkor lehet, hogy a helyi core switch simán swithc portként csatlakozik valamihez a külföldi site.on. Ekkor nem kerülhet szóba IP cím kérdés.
- ha L3-as akkor kell egy router, tüzfal, valamilyen L3-as eszköz ami az itteni site-on biztosítja a kapcsolatot az internet felé, ennek kellene tudni, hogy állandó statikus IP címe van-e, vagy az internetszolgáltató oszt ki neki IP címet. Ha a szolgáltató osztja ki, akkor milyen leased time-al.Itt többünk leírta, hogy a legvalószínűbb scenario az, hogy az internet felé lévő kapcsolatot "újítja" meg a szolgáltató, akár úgy, hogy kigyomlálja az inaktívakat, akár úgy, hogy újabb IP címeket oszt ki nekik.
Ez alapján egy hozzáértő már tudja miket kell megnézni, hogy közelebb jussatok a megoldáshoz de úgy nem működik, hogy elmész az autószerelőhöz, hogy sokat fogyaszt az autóm és amikor megkérdezi, hogy milyen az a válasz, hogy piros (mikrohullámú az internetkapcsolatod fizikai rétegben).
Amit például meg tudsz tenni, hogy ráakasztasz egy számítógépet az egyik adott switchre és megpróbálod trace-elni a monitorozó szerver IP címét, amikor hiba jelentkezik. Vagy kitükrözöl mindent ami a switch management vlan-jére -ről jön/megy.
De ami a legegyszerűbb és már leírta más: megnézed a internetszolgáltatótok mit szolgáltat!
-
soma314
tag
válasz
TheProb
#12412
üzenetére
na most kezdem nem érteni
van egy site-od, ahol vannak a switch-ek és egy külföldi site-od, ahol a monitorozó szerver van
eddig jól értem?mi a kapcsolat a külföldi és a helyi site között, ha nem internet?
(akkor is használod az internetet, ha vpn kapcsolatként intranet-en lévőnek látja a szerver a switch-t)a másik dolog, ami nem tiszta
egyszerre egy switch-et kérdez le véletlenszerűen, vagy véletlenszerű időpontban lekérdezi mind, amiből bizonyos switch-eket nem ér el?(van mondjuk 5 switch és 1:22-kor megpingeli az 1-est, 1:45-kor a 3-ast....
vagy 1:22-kor megpingelni mind az 5-öt?)mi a topológia? a switch-ek hogy vannak az internetre kötve? egy router-en keresztül nem?
a router-t is pingeli a szerver? mi a router uptime-ja?
egyáltalán a router állandóan ugyanazt az IP címet kapja, vagy mint egy otthoni internetszolgáltatásnál időnként kap újat (ez utóbbi esetben is lehet "állandó" overlay IP címe a szerverről nézve)(Pl, ha egy DMVPN topológia van az intersite kommunikációhoz akkor elég ha a központi - HUB site-on van statikus IP cím, míg a remote site-okon , a spoke-okon lehet dinamikus is. Ha ez van nálatok, akkor amikor a szolgáltató új IP címet ad a site router-ének, akkor addig, amig nem épül fel a NHRP-al az új címmel a VPN kapcsolat, addig a remote site-on semmi nem lesz elérhető. De ezt tiszta ha adott időpontban semmi, vagy csak egy switch nem elérhető.)
-
soma314
tag
válasz
TheProb
#12403
üzenetére
én is a takaritónőre tippelek
a monitorozó szoftver gondolom egy olyan szerveren fut, ami a switch-ekkel azonos lan-ben van vagy legalábbis nem az interneten keresztül próbálja elérni őket ugye?mennyi ideig nem lehet pingelni 1-2 perc és eygenként jelentkezik vagy egyszerre több switchnél
ha egyszerre több switch-nél, akkor azok tápellátása nem azonos forrásról megy
vicces a takaritónő, de simán el tudom képzelni, hogy megy végig valaki és kihúzkodja a switch-eket és amig újraboot-olnak, nem elérhetőek
vagy szünetmentes ellátásról mennek
a switch-eken nem lehet lekérdezni az uptime-ot egy ilyen elérhetőségi szünet után?
nincs STP konvergencia a hálózatban? vagy akár routing protokol gyári timerekkel?
Egy nem optimalizált OSPF konvergencia is eltarthat egy pár percig is akár! Lehet akár 120 mp broadcast network type-nál a dead timer -
crok
Topikgazda
válasz
TheProb
#12403
üzenetére
Pont ebben befolyásolhatja: ha távolról akarod elérni és a kifelé menő vonalad szakad akkor ami mögötte van az nem lesz elérhető. Azért kérdeztem az ADSL/PPPoE-t mert a legtöbb szolgáltató 24h-s időközönként eldobatja a PPP kapcsolatokat és újraépítteti hogy a halott de ki nem jelentkezett PPP klienseket kigyomlálja. Nekem ez így idle timeout dolognak tűnik így elsőre - mindig akkor szakad ha nincs forgalom..? Ha meg mikró akkor simán lehet PPP.. a Verizon adjon már valami logot. Meg én megnézném hogy a "központi" helyen, ahol a Microsoft Operation Manager fut ott a WAN routing táblában a annak a switchnek a prefix-e mióta van bent a routing táblában - gyanúra adhat okot ha pont azóta amióta megint elérhetőek a switchek..
-
TheProb
veterán
-
soma314
tag
válasz
TheProb
#12360
üzenetére
minek neked trunk, ha mindent hagytál egy vlan-be?
conf t
int gi0/1
switchport mode access
switchport access vlan X - az általad használt vlan számautána mennie kellene
még valami a 2950 nem tud MDIX-et, elvileg a router felé straight kábellel kéne menned, azzal mész?
A routeren van MDIX?
speed mindkét oldalon auto vagy mindkét oldalon gbps?
full halfduplex?
a switch nem dob fel CDP üzeneteket?
esteleg érdemes nem kikapcsolni az auto negotiation-t -
soma314
tag
válasz
TheProb
#12329
üzenetére
van egy sokkal egyszerűbb módszer is, bizonyos szempontból még professzionálisabb is, mint a router on a stick subinterface-ekkel és az asus routereddel simán meg tudod csinálni:
a routered egyik interfészét a switch egyik vlan-hez tartozó portjához csatlakoztatod, a másikat a másikhoz. Ezután a routeren kersztül már átjárható két vlan között az adatforgalom.
(attól professzionálisabb, hogy a router on a stick esetén a sávszélességet lefelezed azzal, hogy oda-vissza azonos linken megy minden)
-
soma314
tag
válasz
TheProb
#12321
üzenetére
hogy ne lehetne értelme, nem csak az eszközön belül tudsz route-olni a vlan-ek között
erre keress rá: router on a stickAmúgy el tudok képzelni olyan speciális helyzetet is, amikor egy hairpin-el van összekötve két vlan (egy olyan kábellel, ami kijön az switch egyik vlan-jéhez hozzárendelt portjából és egy másik vlan-hez rendelt porthoz megy). Az is lehet, hogy ez a link pedig csak ideiglenesen van bekapcsolva.
De igazából te tudod mire van szükséged!
-
FecoGee
Topikgazda
válasz
TheProb
#12318
üzenetére
Nem lehet beallitani mert az egy layer2-es switch. Catalyst 3xxx series ahol lehet. Uplink port altalaban trunk.
Int g0/1
Des -- uplink to X --
Sw mode trunk
Sw trunk all vlan x,y,z
Sw noneg
Priority-q out
Storm-control broadcast level x
Storm-control multicast level Y
Spanning-tree uplinkfastFejbol kb. ennyi.
-
crok
Topikgazda
válasz
TheProb
#12037
üzenetére
A twinax-ra vagy az aktív optikára gondolsz?
Itt meg a Cisco dokban:
Cisco SFP+ Twinax Copper Cables
Cisco SFP+ Active Optical Cables(Ja, igen.. ez nem SFP hanem SFP+ mert ilyen sima SFP-ben nincs ha jól tudom)
-
-
crok
Topikgazda
válasz
TheProb
#12017
üzenetére
1, igen, kellene mégegy stack kábel, mert így féllábú csak.
A backplane most csak half duplex a kettő közt és csak fél sávszél.
(Két kábellel 80Gbps a két switch közti stack link.)2, Igen, az SFP-ket kellen használni uplink/downlinknek, azok
a portok külön ASIC-ot kaptak pont ezért. Ha kevered a user
portokat és abból használsz fel uplink/downlinknek is azzal
megintcsak a belső sávszéllel babrálsz ki (24 portos a két "user
port" ASIC és ha egyikből a másikba kell továbbítani keretet
egy nagy sávszéligényű appnál (pl. backup) akkor kevés lesz
a 4MB buffer is meg a két ASIC közti 1+1Gbps link is, hidd el..)És brutál +1 a magyarítások ellen.. a szakma nyelve az angol. Pont.
-
FecoGee
Topikgazda
-
crok
Topikgazda
válasz
TheProb
#11146
üzenetére
Egyszerű: a nyomtatók meg az egyéb céleszközök a legritkábban küldenek csak úgy, maguktól bárkinek is csomagot, frame-et.. így amikor üresjárat van nincs forgalom, a port MAC timeout meg épp 5 perc.. így már tudod miért tűnik el a MAC a portról. Pingeld meg a szórási címet a VLAN-ban vagy pingeld végig az összes IP-t a VLAN-ban (apró tcl script is megteszi..) és akkor 5 percig biztos, hogy minden élő IP-hez lesz MAC-ed.
-
-
crok
Topikgazda
válasz
TheProb
#11140
üzenetére
Csodálkoznék ha mentene bármit bárhova hiszen a példámban szereplő 1.1.1.1 IP-re TFTP-zné a konfigot, ami valószínűleg nem a te szervered IP-je (meg ne felejts el a TFTP szerveren egy üres file-t csinálni mielőtt másolsz és tedd írhatóvá).
A putty-nd-ben a "ogin" meg az "assword" azért van így írva, mert tulajdonképp ez egyfajta expect regex kifejezés: ha a router/switch CLI ezt a kifejezést dobja vissza akkor a putty-nd visszaírja azt amit beírtál neki, jelesül ha "ogin" van akkor username, ha "asswörd" van akkor password.. Azért nincs ott az "l" vagy a "p" mert sok helyen "L" van "l" helyett és/vagy "P" van "p" helyett, viszont a többi általában ugyan az, így univerzálisabb.. ja, meg szerintem ugyan írtál be a send részbe dolgokat, user, pass, parancsok, de szinte biztos, hogy nem kapcsoldad be.. szóval a sor elején kell lennie egy pipának is, az az "Apply" : D
De ha már itt járunk és ennyire kell az a kimenet.. ez működik?
(Persze a megfelelő részeket töltsd ki megfelelő adatokkal):plink -ssh -l <user> -pw <pass> 10.54.38.35 < "command.txt" > kimenet.txt
..és egyelőre a command.txt tartalma legyen csak ennyi:
term len 0
sh run
quitAztán futtasd le a parancsot és nézd meg mi van a kimenet.txt-ben.
-
crok
Topikgazda
válasz
TheProb
#11138
üzenetére
Jó, de én nem putty-ot hanem putty-nd-t írtam és linkeltem, azt nézd már meg.
A command file-t meg szerkeszd notepad++-al és állítsd át
a sorvégeket UNIX type-ra (Edit > EOL Conversion > UNIX)Valamint a parancsot add ki így:
plink -ssh -l <user> -pw <pass> 10.54.38.35 < command.txt
esetleg ha kell a kimenet egy fileba
plink -ssh -l <user> -pw <pass> 10.54.38.35 < "command.txt" > kimenet.txt -
crok
Topikgazda
válasz
TheProb
#11134
üzenetére
Ez konkrétan bármire szól..
De ha a putty-nd linket megnyitod és leszeded a programot meglátod mit tudsz csinálni benne.. adhatsz hozzá session-t, abban megadod az eszköz IP-jét, telnet/ssh és a login user + pass meg után az a parancsot amit akarsz.. de szedd le, próbáld ki, könnyebb mint így írni róla. -
crok
Topikgazda
válasz
TheProb
#11120
üzenetére
RANCID + Cygwin = epic fail
Elba##ol majd egy csomó időt és rájössz, hogy teljesen felesleges volt az egész mert nem működik a függőségek miatt..
De ha már ott a cygwin akkor lesz bash+expect+grep+netsnmp+tftp+awk+telnet+opensshclient+minden, ami ahhoz kell hogy megírd magadnak a scripted.
-
crok
Topikgazda
válasz
TheProb
#11117
üzenetére
Én spec' írtam magamnak.. többet is ( : alapvetően nem bonyolult (a nagyon alapokhoz elég egy bash+expect), de (mint mindig, itt is) minden a kivételkezelésen múlik.. ám ha nem akarod magadnak megírni és tweak-elni akkor mittomén' tegyél fel egy RANCID-ot vagy OpenNMS-t esetleg.. de inkább a RANCID (faék.. nemis', inkább huzalszeg egyszerűség..).
RANCID official: http://www.shrubbery.net/rancid/
RANCID howto: https://networklore.com/rancid-getting-started/
OpenNMS official: http://www.opennms.org/en
OpenNMS live demo: https://demo.opennms.org -
crok
Topikgazda
válasz
TheProb
#11088
üzenetére
E l k é p z e l n i s e m tudom, hogy normál körülmények közt bejön a keret a nyomtatóból és teljesen más MAC-et tanulna meg a switch - vagy valami borzasztó bug van a switch hardware-ben.. de ilyet én még 10+ év alatt nem láttam. Vagy a porton van mégegy switch (amiről te nem tudsz) és azon lóg a nyomtató.. és amellé pattintanak még valamit, szóval a porton 2 eszköz SRC MAC-jével tűnnek fel keretek.. persze vannak kivételes működések ás protokollok.. de egy ilyen mutatványt egy szál nyomtatótól amiben a TCP/IP stack normálisan van implementálva hát nem tudok elképzelni.. nem lehet hogy a kollega multicast MAC-et látott mert a nyomtató próbált keresgélni a helyi hálón? Vagy nem fejtené ezt ki kicsit hogy milyen eset volt ez a fals MAC-es dolog?
-
jerry311
nagyúr
válasz
TheProb
#10937
üzenetére
A mellékelt kép első 3 sor szövege a lényeg.
Van egy env_vars fájlod és ~8 MB üres helyed. Ez a hely kb. annyi mint a platformra elérhető legújabb (10 éves
) IOS.
Lehet nem írja a guide, de ha felrakod a switch és a soros portod sebességét is 115200 bps-re akkor 12x gyorsabb lesz. Azért nem mindegy, hogy 10 perc vagy 2 óra.
. Ja, az mar nem rossz. 
) IOS.
Ú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!
- AKCIÓ! Lenovo Thinkpad T14 Gen 3 üzleti notebook - i5 1245U 16GB RAM 512GB SSD Intel Iris XeW11
- Amazon Kindle 10th Generation ébresztős tok
- KIÁRUSÍTÁS - REFURBISHED és ÚJ - Lenovo ThinkPad Ultra Docking Station (40AJ)
- Huawei P20 Lite 64GB, Kártyafüggetlen, 1 Év Garanciával
- Honor Pad X8 64GB, Wi-Fi, 1 Év Garanciával
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest