alcoma ping problémy?

[rouchi]

Ahoj poslední dobou taky pozoruji problémy s alcoma spoji...
máme v síti jen dva (máme ještě sikli, raye, summit orcave)
na alcomách mi cca před měsícem a půj začlo jebat...
jedná se mi přesně o podobné problémy, které se ale po určité době stávají tak znatelné, že za spojem net je prakticky nepoužitelný.
co je hlavně divné, tak alcoma vyhodí chybu na dohledu a ten přestane odečítat data ze snmp (v tu chvíli je už hodně zle)
po rebootu jednotek (musí se resetnout obě strany - jinak na té neresetlé problém zůstane)
a pak to zase jede OK... každopádně po tomhle posledním rebootu to vydrželo cca týden jet OK a dnes přesně nastal tenhle problém...
každopádně jsem to předal p. tůmovi, spoje postavil na VIPku a počítám, že to chlapci otestují a zjistí kde je problém... ono svést to, že za to může switch je jednoduché, ale divný, že to fungovalo cca půl roku ve stejné konfiguraci bez problémů...
flow control je na switchích (připojeno do UBNT switche a yetstreamu) je zapnuto....

[okoun]

no já jsem nastavil tu forntu na 1500 a hle najednou je po PL, takže díky za rady.
jinak tento problém s tím SNMP byl opraven v nějaké verzi FW, byl to problém na MP600.

[ok1vaw]

Pro lepší pochopení, jak je to s PINGem u našich spojů přeposílám následující info:

-Obecně pro jakákoliv pojítka platí, že PING typicky přijímá a odpověď na něj vrací centrální kontrolér datového terminálu pojítka.


-Pokud se jedná o zařízení typu Mikrotik, je tento kontrolér obvykle společný pro zpracování PINGu i pro zpracování pojítkem přenášených uživatelských dat (tj. je využit i jako datový procesor). V tomto případě tedy lze dle testu odezvou na PING zjednodušeně posuzovat a vyhodnocovat i průchozí datový přenos.

-Pojítka Alcoma využívají centrální kontrolér pouze pro dohledové funkce, průchozí uživatelská data tento kontrolér nijak nezpracovává. Odezva na PING může být v souvislosti se zaneprázdněním centrálního kontroléru zpožděná a v extrémní situaci i neodeslaná, nicméně tato situace nijak neovlivňuje kvalitu a rychlost přenášených uživatelských dat. V případě Alcomy tedy test odezvou na PING téměř nic o vlastním průchozím datovém přenosu nevypovídá a nelze z jeho výsledku usuzovat na kvalitu vlastního přenosu uživatelských dat.

Vojta, vývoj ALCOMA.

[okoun]

Pro lepší pochopení, jak je to s PINGem u našich spojů přeposílám následující info:

-Obecně pro jakákoliv pojítka platí, že PING typicky přijímá a odpověď na něj vrací centrální kontrolér datového terminálu pojítka.


-Pokud se jedná o zařízení typu Mikrotik, je tento kontrolér obvykle společný pro zpracování PINGu i pro zpracování pojítkem přenášených uživatelských dat (tj. je využit i jako datový procesor). V tomto případě tedy lze dle testu odezvou na PING zjednodušeně posuzovat a vyhodnocovat i průchozí datový přenos.

-Pojítka Alcoma využívají centrální kontrolér pouze pro dohledové funkce, průchozí uživatelská data tento kontrolér nijak nezpracovává. Odezva na PING může být v souvislosti se zaneprázdněním centrálního kontroléru zpožděná a v extrémní situaci i neodeslaná, nicméně tato situace nijak neovlivňuje kvalitu a rychlost přenášených uživatelských dat. V případě Alcomy tedy test odezvou na PING téměř nic o vlastním průchozím datovém přenosu nevypovídá a nelze z jeho výsledku usuzovat na kvalitu vlastního přenosu uživatelských dat.

Vojta, vývoj ALCOMA.

njn takže vlastně alcoma zk... celou trasu protože potom bude ping nepoužitelný pro diagnostiku? co tedy použít na diagnostiku? za tou alcomou třeba dalších 10 různých spojů že...

[ludvik]

Tak si vyber ... buď spoj který neovlivňuje data, protože je vše řešeno v hardware, nebo přesný opak, kdy i skrz přenášená data jdou přes nějaký pársetmegahertzový procesor.

Diskutovat se dá. Velikost bufferu v alcomě, víc dat zveřejněných přes SNMP ...

[okoun]

jenže mě jde o ty spoje zatím, o alcomu mi nejde vůbec ta jede vždy OK , pustím si snmp sondu na BER a hotovo... vadí mi tedy že ta alcoma potom zkreslí všechny spoje zatím, když tu píšete že ping přenáší podřadně, ale nechápu proč? měl jsem za to že alcoma vše přenáší naprosto bez úprav a bez zásahů...

[GRFS]

Obavam se, ze si to prohlaseni od Vojty z Alcomy spatne vysvetlujete.

1) Nikde neni napsano, ze to plati 100%. Napriklad pri nastaveni inband dohledu pres VLAN pingate stejnou trubkou, jakou tecou data.

2) Alcoma nic nezkresli, tim mene spoje za sebou. Rec je pouze o zpusobu, jakym zpracovava icmp echo requesty management CPU v Alcome samotne. Mineno ty requesty, ktere prichazeji na adresu IP stacku konkretni Alcomy. Pokud budete pingat na ipko uplne jiny technologie za Alcomou, tak se to datove prenasi stejne jako jakykoliv jiny provoz a vubec to neprochazi pres management CPU Alcomy.

V realu je to boure ve sklenici vody, protoze maximalne se da hovorit o tom, ze se muze, pri pripadnem vytizeni CPU prioritnejsimi ukoly, mirne zhorsit latence odpovedi IP stacku na icmp echo request. Vse ale jeste silne zavisi na tom, jak a cim krome pingu CPU zatezujete. Napriklad, pokud do toho CPU paralelne jdou icmp echo requesty a SNMP komunikace, tak se proste musi nejak rozhodnout, cemu da prednost.

[dagus]

Přenáší vše stejně, jen ping na alcomu samou je podřadnej a použitelnej max na dohled jede, nejede. Ale o to tu dle mě nešlo a ničemu to nevadí.

[okoun]

Přenáší vše stejně, jen ping na alcomu samou je podřadnej a použitelnej max na dohled jede, nejede. Ale o to tu dle mě nešlo a ničemu to nevadí.

uff tak to je dobře, ipky alcomy vůbec nepingám pač to je jak to píšete totálně vysoká latence a vleký PL, to už jsem byl poučen od techniků alcomy, že takto ne...

[GRFS]

U Oknouna je vsechno jinak, zda se Ja ten ping normos pouzivam a ze to obcas hodi odpoved o par ms horsi, je vec, ktera me fakt nepali. Protoze ho pouzivam na zjisteni jede, nejede. Nic vic.

[Dalibor Toman]

U Oknouna je vsechno jinak, zda se Ja ten ping normos pouzivam a ze to obcas hodi odpoved o par ms horsi, je vec, ktera me fakt nepali. Protoze ho pouzivam na zjisteni jede, nejede. Nic vic.

takhle vypada to sem tam na MP600 ze ktere se vycita po SNMP signal a dalsich par veci co ma smysl ukladat:

(a neni to kusova zalezitost)

IMHO by si to radio zaslouzilo CPUcko s rozumnejsim vykonem. Ona i odezva na SNMP dotaz se pocita. Pokud by takovehle odezvy mela vsechna zarizeni na siti, pak by sly grafy i dohledove systemy rychle do kolen.

[okoun]

U Oknouna je vsechno jinak, zda se Ja ten ping normos pouzivam a ze to obcas hodi odpoved o par ms horsi, je vec, ktera me fakt nepali. Protoze ho pouzivam na zjisteni jede, nejede. Nic vic.

takhle vypada to sem tam na MP600 ze ktere se vycita po SNMP signal a dalsich par veci co ma smysl ukladat:
smokeping.rrd-day.png
(a neni to kusova zalezitost)

IMHO by si to radio zaslouzilo CPUcko s rozumnejsim vykonem. Ona i odezva na SNMP dotaz se pocita. Pokud by takovehle odezvy mela vsechna zarizeni na siti, pak by sly grafy i dohledove systemy rychle do kolen.

ano u mě je to prakticky stejné, takže vážený GRFS není to u mě jiné

[GRFS]

Nezbyva nez znovu zopakovat, ze prumer RTT odpovida beznemu chovani Alcomy. Pro ucely zjisteni stavu zije/nezije je to vic nez dostatecne a osobne jsem nemel dosud potrebu to menit. Pokud je odezva stejna i u Okouna, postradam trochu smysl zalozeni tohoto vlakna

[Dalibor Toman]

Nezbyva nez znovu zopakovat, ze prumer RTT odpovida beznemu chovani Alcomy. Pro ucely zjisteni stavu zije/nezije je to vic nez dostatecne a osobne jsem nemel dosud potrebu to menit. Pokud je odezva stejna i u Okouna, postradam trochu smysl zalozeni tohoto vlakna

mozna by stalo za to si prohlednout/precist prispevek na ktery Okoun reagoval

[GRFS]

A ktery mate konkretne na mysli ?