- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- sziku69: Fűzzük össze a szavakat :)
- Ndruu: Segíts kereshetővé tenni a PH-s arcképeket!
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- gban: Ingyen kellene, de tegnapra
- Luck Dragon: Asszociációs játék. :)
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Szoszo94: Xiaomi Mi Router 3G - Padavanra fel!
- Gurulunk, WAZE?!
- Geri Bátyó: B550 szűk keresztmetszet, de mi és mié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
-
RogerP
csendes tag
Technikai kérdés: Standalone AP esetén beállítható egy olyan Guest login page, ahol nincs semmi jelszavas vagy AAA autentikáció, de mielőtt hozzáférne az Internethez feldobjon egy jogi szöveget, amit el kell fogadni, anélkül nem tud tovább menni.
Ez megoldható?
Valamint kérdés, hogy 2504-ös controller esetén van-e ilyen lehetőség. -
-
#12492
vadger
tag
Cyber_Bird
#12491
vadger
tag
válasz
Cyber_Bird
#12491
üzenetére
Jó kezekben vagyok... Megkeresett a CCIE, adtam neki jogot a dashboardhoz, azt mondja látja a licence problémát, de ha eltávolítom a 2 új AP serial numbert, akkor meg fog szűnni a licence probléma... Köszi
na várjatok, milyen gyakran frissítik a CCIE Hall of Fame-et? Mert nem találom benne az illetőt... Lehet átba*ztak és nem is CCIE kezeli az ügyet? Hogy fog így megoldódni?
-
vadger
tag
Van pár Meraki access pointunk, amiken free wifi szolgáltatást nyújtunk shopokban.
Jött 2 darab pluszban, beüzemeljük, látjuk a licence problémázik, x darabra van licence, x+2-re nincs, erre a plusz 2-re újabb licence key kellene.Megkérem a licence key-t a support cégtől, akik vették. Nem találják. Próbáljam meg a shipment numbert beadni... Nem fogadja el természetesen. Mondom nekik, srácok, licence number, kapnotok kellett ezt is mikor megvettétek.
Válasz:
Hi,One of our CCIEs will solve this matter for you.
Úgy látszik ide már igazi expert kell
-
-
crok
Topikgazda
A Win-ek így mondják meg hogy van-e Internet kapcsolat:
NCSI: Microsoft Windows Network Connectivity Status Indicatorhttps://technet.microsoft.com/en-us/library/cc766017(WS.10).aspx
http://blog.superuser.com/2011/05/16/windows-7-network-awareness/NCSI performs a DNS lookup on www.msftncsi.com, then requests http://www.msftncsi.com/ncsi.txt. This file is a plain-text file and contains only the text Microsoft NCSI.
NCSI sends a DNS lookup request for dns.msftncsi.com. This DNS address should resolve to 131.107.255.255. If the address does not match, then it is assumed that the internet connection is not functioning correctly.
-
Gery15
addikt
router1#debug pppoe packets
PPPoE control packets debugging is on
router1#deb pppoe ev
router1#deb pppoe events
PPPoE protocol events debugging is on
router1#deb pppoe errors
PPPoE protocol errors debugging is onDe most valami csodánál fogva felcsatlakozott.
Viszont nincs net, de kapok dialeren IP-t.Sh ru:
Building configuration...
Current configuration : 2302 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname router1
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
enable secret 5 $1$we/w$/F.vf4nAZIgoVICjkPTOM1
!
no aaa new-model
!
!
dot11 syslog
ip source-route
!
!
!
ip dhcp pool lan
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1
!
!
ip cef
no ip domain lookup
ip domain name teszt.hu
no ipv6 cef
!
multilink bundle-name authenticated
!
vpdn enable
!
!
!
username admin privilege 15 secret 5 $1$D8OB$de8tUGK2h/WpDEnPjIZlA/
username user privilege 15 password 0 cisco
!
!
!
archive
log config
hidekeys
!
!
ip ssh time-out 60
ip ssh authentication-retries 2
ip ssh version 2
!
!
!
interface BRI0
no ip address
encapsulation hdlc
shutdown
!
interface FastEthernet0
description uplink
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
pppoe enable group global
pppoe-client dial-pool-number 1
!
interface FastEthernet1
description lan
ip address 192.168.1.1 255.255.255.0
ip nat inside
no ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet2
!
interface FastEthernet3
!
interface FastEthernet4
!
interface FastEthernet5
!
interface FastEthernet6
!
interface FastEthernet7
!
interface FastEthernet8
!
interface FastEthernet9
!
interface Vlan1
no ip address
!
interface Dialer1
description pppoe
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp pap sent-username password 0
!
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 Dialer1
no ip http server
no ip http secure-server
!
!
ip nat inside source list nat interface FastEthernet1 overload
!
ip access-list standard nat
permit 192.168.1.0 0.0.0.255
!
dialer-list 1 protocol ip permit
!
!
!
!
!
!
control-plane
!
!
line con 0
password cisco
login
line aux 0
line vty 0 4
privilege level 15
password cisco
login local
transport input ssh
line vty 5
privilege level 15
password cisco
login local
transport input ssh
line vty 6 15
privilege level 15
login local
transport input ssh
!
end -
vadito
csendes tag
válasz
FecoGee
#12454
üzenetére
Cisco clock issues caused by faulty Intel Atom C2xxx SoC
AVR54. System May Experience Inability to Boot or May Cease Operation
Problem: The SoC LPC_CLKOUT0 and/or LPC_CLKOUT1 signals (Low Pin Count bus clock outputs) may stop functioning.
Implication: If the LPC clock(s) stop functioning the system will no longer be able to boot. -
-
kowika87
tag
Igen enis ezt feltetlezem hogy a pinekkel vagy hatul a higig interfacek esetleg i2c bus. Csak mivel iszonyu draga cuccrol van szo cisco sem forceolja a cseret. A masik gond az hogy egy olyan DC-ben van ahova nagyon magas belepesi kovetelmenyek vannak (allami cuccok). Mire szerez az ember access-t az FE-nek napok mennek el.
-
crok
Topikgazda
válasz
kowika87
#12457
üzenetére
Gondolom 0-24 online a chassis úgyhogy a régit az új helyére nem lehet(ett még) megpróbálni betenni. 6500-as tapasztalat, hogy ilyenkor chassis lesz. 5..6 év alatt egyszer volt power supply de igazából nem is azzal volt gond hanem a rail-el a chassis backplane-ben: a nem is igazán a PS hanem a PS csatlakozójájánál volt gond, nem jutott elég nafta a supengine-hez, nagy ohmos kontaktus volt valamelyik illesztésnél.
-
FecoGee
Topikgazda
Hello, mi?
„ However recently, Cisco became aware of an issue related to a component manufactured by one supplier that affects some Cisco products. In some units, we have seen the clock signal component degrade over time. Although the Cisco products with this component are currently performing normally, we expect product failures to increase over the years, beginning after the unit has been in operation for approximately 18 months. Once the component has failed, the system will stop functioning, will not boot, and is not recoverable. This component is also used by other companies.“
To support our customers and partners, Cisco will proactively provide replacement products under warranty or covered by any valid services contract dated as of November 16, 2016, which have this component. Due to the age-based nature of the failure and the volume of replacements, we will be prioritizing orders based on the products’ time in operation.
-
FecoGee
Topikgazda
Because of your impactful and valuable contributions to the IT community, you have been chosen out of hundreds of nominees to be part of the 2017 Cisco Champions program. Congratulations!
Cisco Champions is a global group of highly influential IT technical experts who enjoy sharing their knowledge, expertise, and thoughts across the social web and with Cisco. The Cisco Champions program encompasses people with interests across Cisco’s technology portfolio, including Data Center, IoT, Enterprise Networks, Collaboration, and Security.
https://communities.cisco.com/docs/DOC-54596
-
crok
Topikgazda
válasz
Gery15
#12444
üzenetére
interface Dialer1
ppp authentication pap chap callin
ppp chap host userneved
ppp chap password jelszavadEzt tedd már még fel.
Ha ezzel se indul el akkor ott valami más a baj, mert ennyit tennék még hozzá (már azon kívül hogy a user meg a pass legyen rendben):
deb pppoe packets
deb pppoe events
deb pppoe errorsIgazából már a deb pppoe packet is elég lenne nekem.. ha nem is küld PADI-t az is jel, mert akkor el se indul a folyamat..
-
Gery15
addikt
Jelen pillanat ezek vannak be pötyögve.
vpdn enable
interface FastEthernet0
description Uplink
no ip address
no ip redirects
no ip unreachables
no ip proxy-arp
pppoe enable group global
pppoe-client dial-pool-number 1
ip nat outside
no shinterface Dialer1
description PPPoE
ip address negotiated
no ip redirects
no ip unreachables
no ip proxy-arp
ip mtu 1492
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
ppp pap sent-username password 0
no shdialer-list 1 protocol ip permit
ip route 0.0.0.0 0.0.0.0 Dialer1
interface FastEthernet1
description LAN
ip address 192.168.1.1 255.255.255.0
ip nat inside
no ip virtual-reassembl
no ship dhcp pool DHCP
network 192.168.1.0 255.255.255.0
default-router 192.168.1.1ip nat inside source list NAT interface FastEthernet1 overload
ip access-list standard NAT
permit 192.168.1.0 0.0.0.255 -
crok
Topikgazda
válasz
Gery15
#12437
üzenetére
Akkor most ez egy valós, igazi internethozzáférés PPPoE-vel? Vagy PacketTracer (mert PT ábrát találtam a hozzászólásaidban)? A fa0 interface-en egészen biztosan nem fogsz IP-t kapni ha a PPPoE-t arra állítottad be mert azt a Dialer-en kell kapnod.. már ha be van állítva hogy kapjon IP-t (ip address negotiate).
Tehát akkor most egy olyanról beszélünk, hogy:
Szolgáltató DSL kábel "bejön a házba" --- esetleg azon egy splitter --- azon a megfelelő aljzatban mondjuk RJ11 csatlakozóval egy kábel megy a DSL modembe --- ami bridge módban van --- abból az RJ45 aljzat van kötve a router Fa0-ba? És erre akarunk PPPoE elérést csiholni mert a szolgáltató azt mondta hogy PPPoE van username + password-el és nem sima DHCP oszt'jónapot?
-
Gery15
addikt
Akkor kínlódtam vele, de nem jött össze. Most neki ültem megint, de továbbra sem megy. Próbáltam több konfigot már, YT videót. Teljes hálózatot másoltam már, és akkor sem. Alapból ott bukik a dolog, hogy hiába állítom, be az általatok vagy mások által leírt dolgokat nem működik. Sh ip int brief parancsra nem kapok Fa0-on IP címet és a 1812-esen a PPP led se világít, mint eddig.
Igazából valami szájbarágós ráérős segítséget kérnék, esetleg aki használna így Cisco routert PPPoe kapcsolattal.
-
crok
Topikgazda
válasz
vadger
#12435
üzenetére
JakéremhogyLWAP-ok. Akkor a WLC-n lehet ezzel trükközni:
debug ap command..
Nézd meg az AP-kat:
show ap summaryAP-kon debug bekapcsolása:
debug ap enable <LWAP AP neve>AP-n debug parancsok futtatása:
debug ap command "a parancsok amiket említettem, idézőjelek közt" <LWAP AP neve>Mintpéldául'
debug ap command "debug dot11 Dot11Radio0 carrier busy" <LWAP AP neve>A végén meg kapcsold ki a debugot:
debug disable-all
- vagy -
debug ap disable <LWAP AP neve>Biztos GUI-ban is lehet de a GUI-kkal nem vagyok jóban : D
Majd a nagyok megmondják a GUI-ban hol van. -
crok
Topikgazda
válasz
vadger
#12432
üzenetére
Akkor legalább dot11 Dot11Radio0 carrier busy és show dot11 associations az AP-kon. Brutálsokat elmondhat a hálódról, pl. mennyire túlhajtottak a csatornák és a csatlakozott eszközök signal és SNR értékeit legalább. Ez már jó kiindulási alap.
[Szerk:] És hagyd a Prime-ot a francba, szarra se jó
keress rá a hozzászólásaimban. Pl. ha jól tudom a 1130-as AP nem tud N-t. -
vadger
tag
Köszi! Leszakadás talán nem olyan gyakori mint írtam, inkább a sebességgel van baj. Tök jó lenne ha ott tudnék lenni, és vizsgálódni, wifi analyser, rouge ap keresés, ilyesmi, de sajnos távoli support vagyok, a helyi erők kb annyit tudnak hogy kicserélnek dolgokat ha szépen leírom, hogy mit és hogyan.
Van Cisco Prime, de szerintem elég rosszul van beállítva, mert nem sok dolgot mutat ezekről a problémákról. Mintha azt látnám, hogy ezek az AP-k többsége b/g/n és a/c üzemmódban is fut, lehetséges ez?
-
kowika87
tag
Pont ezt akartam irni enis, hogy vezetek nelkuli fules, keyboard, mouse mind bezavar. Tipikus saleses duma hogy csereljek ki a legujabbra es jo lesz. A nagy fenet.
En vegigjarnek egy Chanalyzer-el es megneznem SNR, RSSI, zajok, overlap, data rate stb. Most nagyon megy ez az ap-ba epitett kamera dolog ami igencsak kifingatja a channeleket. AC channel bonding 160Mhz es tarsai... -
crok
Topikgazda
válasz
vadger
#12427
üzenetére
Ha lefedettsés probléma van akkor leginkább az égvilágon semmilyen javulás nem lesz ha 1:1 ugyanoda és ugyanolyan antennairányítással teszed vissza őket ugyanazon a csatornán ugyanazon a TX power-el - akkor semmi se fog változni. Esetleg ha eddig G volt de most N vagy A lesz.. és minden eszközöd támogatja is. DE tökimindegy' lesz milyen az interface: hogy most 100Mbps vagy 1Gbps az uplink de G a wifi.. a G-n pl. 23Mbps-nél többet ha megszakadsz se fogsz tudni átpasszírozni az air time megosztás miatt (mert ugye halfduplex 54Mbps Layer1, és ebből jön le a backoff time meg az ack meg hogy half duplex..). Inkább járjatok utána hogy miért szakadnak le. Használj mindenhol át nem fedő csatornákat. Roaming-olnak-e közben vagy van-e sok bluetooth füles.. hülyén hangzik de az élő istenre esküszöm hogy megöli a wifit. Meg hogy vannak-e rogue AP-k, főleg olyanok amik nem a te általad használt csatornákon vannak mert azoknak a jele kizárólag zavar, a keretet nem tudja se az AP se a kliens értelmezni és csak rontja az SNR-t.
-
vadger
tag
Sziasztok!
Hülye kérdés lesz, de nem vagyok wifi expert jelenleg még
Adott x darab 1131-es AP, az ezeket ellátó access switchek FastEthernet porttal rendelkeznek.
Sok panasz van a wifire, lassú, leszakad, stb.
Vajon mekkora javulást várhatunk, ha ezeket lecseréljük 2702E AP-kre, viszont a switchek (és ezzek a 100Mb uplink) maradnak?Köszi!
-
Gery15
addikt
Sziasztok!
Ez mit takar pontosan?
*Jan 31 19:01:08.331: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthern et0, changed state to up
*Jan 31 19:01:16.527: %DIALER-6-BIND: Interface Vi1 bound to profile Di1
*Jan 31 19:01:16.535: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state t o up
*Jan 31 19:01:16.903: %DIALER-6-UNBIND: Interface Vi1 unbound from profile Di1
*Jan 31 19:01:16.907: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state t o downIlletve valakinek működő adsl (pppoe) kapcsolat konfigja nincs esetleg?
-
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. -
#12423
Immy
őstag
sunyijanika
#12417
Immy
őstag
válasz
sunyijanika
#12417
üzenetére
Szia,
300-210 SITCS v1.5-re gondoltam, hogy mivel lett újabb mint a korábbi verzió.
http://www.cisco.com/c/en/us/training-events/training-certifications/exams/current-list/sitcs.html -
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..
-
TheProb
veterán
válasz
soma314
#12416
üzenetére
-Látom a tököm nagy behatást tett a lelkedre, ennek miértjét nem nagyon értem, mert tudtommal nem a személyednek szólt...
-A VPN-es mondatban sem volt semmi támadó jellegű, ott se értem a kiakadásod.
-az összefoglalód hibádzik, de akkor pontosítom még 1x:
random napokon, de mindig olyan időpontokban amikor nincs érdemi hálózati forgalom nem válaszol pingre mindig ugyan abból az 5 sw-ből valamelyik. például: csütörtökön kapunk éjjel kapunk 5-6 mailt, hogy xy sw nem válaszol pingre. az első levél jön 01:11-kor, amiben x sw nem válaszol, aztán 02:33-kor y sw, 03:05-kor z sw, stb. Vagy vasárnap voltak levelek délelőttkor és du is. De egy levélben mindig csak 1 sw-ről van szó.Éppen ezért nem tartom valószínűnek, hogy a szolgáltató építené újra a kapcsolatot, mert azt egyfelől nem napi szinten változó időpontokban csinálják, másfelől általában csak max 1x. Itt meg a fentiek alapján ez az elmélet bukik szerintem, aztán lehet én vagyok rosszul informált a szolgáltatók kapcsolat újraépítési szokásait illetően. Ha ez lenne a gond, akkor mindig ugyan akkor, mindig az összes sw elszállna, nem össze-vissza jönne alert az 5 sw valamelyikéről. (összesen kb. 20 switch-ünk van)
Arról nekem sincs fogalmam, hogy a VPN-ünk milyen Layer-en van, se arról hogy pontosan milyen az internet szolgáltatásunk. Bár gyanítom, hogy más se fogja tudni hirtelen, éppen ezért utána kéne ennek nyomozni.
-
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!
-
TheProb
veterán
válasz
soma314
#12413
üzenetére
-Mi vagyunk a győri site, külföldön tököm tudja hol, meg fut az operation manager.
-Nyilván intranet-et írtam, de ahogy te is mondtad, ez persze neten keresztül megy VPN-nel. A net meg mikrohullámú, ahogy írtam lentebb.
-Többi kérdésre nem tudok választ adni, mert mivel nem mi üzemeltetjük az operation manager-t, így nem látok bele a lelki világába. Nem tudom, hogy mikor és hogyan észleli azt, hogy nem válaszol xy switch a pingre. Bár az alertek hektikus időpontú trigger idejét nézve, ez sztem elég frekventált lehet.
-Hogy pingeli-e a routert, azt megint nem tudom. Belenézni se tudok, mert a jelek szerint nincs tacacs-hoz adva, így nem tudok belépni az adminos adataimmal. -
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ő.)
-
TheProb
veterán
válasz
soma314
#12410
üzenetére
Megnéztem 1-2-nél az uptime-okat, mind 2+ hete megy.
Több aspektusból is kizárható, hogy áramot nem kapnak. Alapból szünetmentesről mennek, takinéni nem fér hozzájuk, még ha akarná se tudná őket kirántani a 230-ból.Az operation manager vmelyik külföldi site-on van, intraneten keresztül kérdez le.
Amúgy random időközönként, de egy időpontban mindig csak 1-ről kapunk mailt, hogy nem válaszol.
Pl. egyik 01:11-kor, a következő 2:43-kor, stb. -
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
-
köszi az infót!
.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Kérlek használd a keresőt, mielőtt kérdezel!
- Olvasd el a téma összefoglalót mielőtt kérdezel!
- A dumpok és a warez tiltott témának számítanak!
- BESZÁMÍTÁS! MSI Z790 i5 14600KF 64GB DDR5 512GB SSD RTX 3070 8GB Rampage SHIVA Enermax 750W
- Beszámítás! Apple Watch SE 2024 44mm Cellular okosóra garanciával hibátlan működéssel
- BESZÁMÍTÁS! ASUS ProArt Z790-CREATOR WIFI alaplap garanciával hibátlan működéssel
- Csere-Beszámítás! Számítógép PC Játékra! Intel I7 6700/ RX 580 8GB / 32GB DDR4 / 500GB SSD
- Telefon felvásárlás!! Samsung Galaxy S25, Samsung Galaxy S25 Plus, Samsung Galaxy S25 Ultra
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: Liszt Ferenc Zeneművészeti Egyetem
Város: Budapest