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

• #12425 soma314 tag TheProb #12418

  Új Válasz 2017-01-31 19:20:18 #12425

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

  akkor ö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.

• #12419 FecoGee Topikgazda TheProb #12418

  Új Válasz 2017-01-31 11:57:27 #12419

  Ú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 TheProb #12418 üzenetére

  STP konvergencia? Broadcast storm esetleg? Nem megy valami utemezett job valami szerveren? Felrekonfiguralt statikus port-channel szerver es switch kozott?

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