mpcz ....
co jsem tak vypozoroval, tak jsi asi starsiho veku. Takze trosku chapu, ze to neznas, jako vetsina z nas. Ale castokrat si rikam, ze ty otazky co tu pokladas, snad poklada nekdo, kdo absolutne nema tuseni co dela a nema se v tomhle hrabat a delat neco jako ISP. Ty tu obcas narazis, ze nekteri z nas pisou necesky, na druhou stranu ty se snazis delat ISP a dost tomu nerozumis ... Obcas jsou tve otazky totalni zaklad, co by clovek mel znat ...
Znam hromadu lidi, co misto sveho snazeni se jen ptaji okolo a cekaji, ze jim nekdo problem vyresi. Nasledne ani kolikrat neumi podekovat. Bohuzel casem se tohle stava dost otravne ...
Jeden priklad ... clovek, ktery nastesti zmizel z dane oblasti se castokrat ptal. Dokonce i na rozmer A4 a odpoved byla, vsak si to najdi na google a jeho reakce? Tam to neni ... Ksakru a prvni odpoved googla na rozmer A4 byl primo rozmer A4 ...
Neber to nijak osobne, ale zkus se nad timhle zamyslet a mozna i nekteri dalsi ...
Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Verze 6.43.2
pgb píše:Zpět k tématu: ta změna v rstp Je naopak moc fajn. Konečně to funguje s vlany jak člověk očekává. Předtím totiž kombinace rstp+vlany vytvářela s různými switchi různé divokosti. Ubnt na svých switchichich mělo kdysi defaultně myslím stp a mk rstp a nebo naopak a když jsem to zapojil do sebe tak bylo o zábavu postaráno. Teď mám všude kde potřebuji rstp/mstp a je klid.
jo jo, ubnt má teď aktuálně všude taky default RSTP takže celkem pohoda. Mišmaš na síti dělal dost bordel, poslední dobou toho hodně vymizelo pokud člověk aspoň trochu udržuje novější verze. Ty fantasmagorie co to dělalo byly fakt úžasný. Nebylo obvyklý když se půlka sítě odmlčela a řekněme si na rovinu, v L2 se problém hodně blbě hledá.
1 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
iTomB píše:mpcz ....
co jsem tak vypozoroval, tak jsi asi starsiho veku. Takze trosku chapu, ze to neznas, jako vetsina z nas. Ale castokrat si rikam, ze ty otazky co tu pokladas, snad poklada nekdo, kdo absolutne nema tuseni co dela a nema se v tomhle hrabat a delat neco jako ISP. Ty tu obcas narazis, ze nekteri z nas pisou necesky, na druhou stranu ty se snazis delat ISP a dost tomu nerozumis ... Obcas jsou tve otazky totalni zaklad, co by clovek mel znat ...
Znam hromadu lidi, co misto sveho snazeni se jen ptaji okolo a cekaji, ze jim nekdo problem vyresi. Nasledne ani kolikrat neumi podekovat. Bohuzel casem se tohle stava dost otravne ...
Jeden priklad ... clovek, ktery nastesti zmizel z dane oblasti se castokrat ptal. Dokonce i na rozmer A4 a odpoved byla, vsak si to najdi na google a jeho reakce? Tam to neni ... Ksakru a prvni odpoved googla na rozmer A4 byl primo rozmer A4 ...
Neber to nijak osobne, ale zkus se nad timhle zamyslet a mozna i nekteri dalsi ...
Tohle beru jako výplod typu "přání otec myšlenky". Jak jsi to dotáhl daleko profesně ty, když tady píšeš takové bludy? Nikdo jiný tě neposlouchá, tak si ulevuješ alespoň zde, na fóru, kde si každý píše, ce se mu zachce? Pochlub se! Ať víme, jaký máš mandát k takovému moralizování a jak vážně tu kritiku mám(e) brát!
Děkuji, mpcz, 8may2019
0 x
Když jsem 6.38 nasadil poprvé, tak jsem si dával pozor na tuhle změnu a zkontroloval jsem si, že to po upgradu běží, ale .... 1 switch + 6x vlan => upgradnu, běží to a pak jsem z hrůzou sledoval, že po nějaké době přestávají vlany náhodně komunikovat. Kouknu do stavu portů na mk a na switchi a tam vidím stp blocking .... no super a už jsem to řešil.
off topic
mpcz: nevztekej se, nemáš proč, prostě tvůj projev tak zní ... jsem rád, že ti to od "polka" pomohlo, nicméně dotazy a myšlenky co předkládáš jsou občas dost absurdní. Linux nekazí lidi, naopak nutí uživatel číst a učit se v příkazové řádce, ne jen slepě kopírovat/klikat, ale chápat co píše. To se hodí všude možně - při programování, v konzoli na routerech různých výrobců a klidně i na windows. Mám jednoho kolegu, který když píše subnetmask, tak netuší jakou to má vazbu na ip adresu, potažmo bránu.... po těch XX letech akorát k vzteku. Rozhodně na tebe nemám zájem dělat ramena, jen mi přijde že spoustu věcí najdeš v dokumentaci a není třeba plevelit fóru. (což teď dělám já
)
- tvůj program když si ho zkompiluješ může běžet kdekoliv, kde si ho rozchodíš (jestli win/unix/linux/osx ... to je jedno)
- JAK CHCEŠ DETEKOVAT VÝPADEK POMOCÍ UDP, KDYŽ JAK SÁM PÍŠEŠ NENÍ POTVRZENÍ Z PROTISTRANY (promiň za ten capslock, ale je to tak absurdní)
- do jaké krabičky? No do jakékoliv se rozhodneš, klidně do desktopu, nebo do raspberry, to záleží na tobě (klidně si můžeš dát na obě strany desktop s windows)
- udp generátorů je mnoho, dá se použít třeba i obyčejný iperf
Edit: Obecný postup hledání nedostupnosti z mojí zkušenosti:
1. ping naráz na všechny prvky po trase
2. když zjistím kde se mi něco ztrácí, tak na obou dvou stranách kabelu hledám ve statistikách countery, které idikují problém (tx/rx errors na daném zařízení i na protistraně a další)
3. když nejsou errory, tak to musí způsobovat nějaká sw služba => zapnu si debug do logu a za chvilku vidím (v tomhle případě že došlo k stp/rstp změně - pokud sis toho nevšiml v bodě 2)/ospf topology change/bgp down
DODATEK: ta správná zábava pro debug začíná s MPLS síti
off topic
mpcz: nevztekej se, nemáš proč, prostě tvůj projev tak zní ... jsem rád, že ti to od "polka" pomohlo, nicméně dotazy a myšlenky co předkládáš jsou občas dost absurdní. Linux nekazí lidi, naopak nutí uživatel číst a učit se v příkazové řádce, ne jen slepě kopírovat/klikat, ale chápat co píše. To se hodí všude možně - při programování, v konzoli na routerech různých výrobců a klidně i na windows. Mám jednoho kolegu, který když píše subnetmask, tak netuší jakou to má vazbu na ip adresu, potažmo bránu.... po těch XX letech akorát k vzteku. Rozhodně na tebe nemám zájem dělat ramena, jen mi přijde že spoustu věcí najdeš v dokumentaci a není třeba plevelit fóru. (což teď dělám já
)mpcz píše:Nikdo nic. Mezitím jsem si vzpoměl na svůj starý SW, který mi dokázal odesílat do linky UDP pakety na druhou IP bez potřeby potvrzování z druhého konce. Předpokládám, že se takto dá zjistit poměrně rychle a spolehlivě, která strana spoje je po dobu těch cca 3 sekund zavzdušněná. Nemá někdo s takovou metodou zkušenost? Podotýkám, že přístup k obou koncům spoje (=antény) je velmi problematický a raději bych to vyřešil nějakým testem najisto a pak tam šel to vyměnit/opravit. S tím souvisí dotaz, do jaké krabičky by šel nahrát co nejjednodušejí tento SW, pokud ho zkompiluji do Linuxu?, protože je nyní napsán pro Windows. Dík, mpcz, 7may2019
- tvůj program když si ho zkompiluješ může běžet kdekoliv, kde si ho rozchodíš (jestli win/unix/linux/osx ... to je jedno)
- JAK CHCEŠ DETEKOVAT VÝPADEK POMOCÍ UDP, KDYŽ JAK SÁM PÍŠEŠ NENÍ POTVRZENÍ Z PROTISTRANY (promiň za ten capslock, ale je to tak absurdní)
- do jaké krabičky? No do jakékoliv se rozhodneš, klidně do desktopu, nebo do raspberry, to záleží na tobě (klidně si můžeš dát na obě strany desktop s windows)
- udp generátorů je mnoho, dá se použít třeba i obyčejný iperf
Edit: Obecný postup hledání nedostupnosti z mojí zkušenosti:
1. ping naráz na všechny prvky po trase
2. když zjistím kde se mi něco ztrácí, tak na obou dvou stranách kabelu hledám ve statistikách countery, které idikují problém (tx/rx errors na daném zařízení i na protistraně a další)
3. když nejsou errory, tak to musí způsobovat nějaká sw služba => zapnu si debug do logu a za chvilku vidím (v tomhle případě že došlo k stp/rstp změně - pokud sis toho nevšiml v bodě 2)/ospf topology change/bgp down
DODATEK: ta správná zábava pro debug začíná s MPLS síti
1 x
No konečně se v tobě probudila i ta lidská stránka člověka, nezasažená Linuxem. Na vysvětlenou, nemám na mysli tu technickou stránku, ale povahovou. Takže rád odpovím na položené otázky, seč mi budou síly stačit.
1/ - tvůj program když si ho zkompiluješ může běžet kdekoliv, kde si ho rozchodíš (jestli win/unix/linux/osx ... to je jedno)
To vím samozřejmě taky, ale na mysli jsem měl konkrétní řešení, protože SW a jeho kompilace je jedna věc, ale vybrat krabičku, běžící prostředí, nasát měřící SW a spustit ho je věc druhá. Že to lze jsem si ověřil na 2,4G AP před deseti lety, kde jsem výrobci AP kompilát poslal, on ho zabudoval, do webu přidal tlačítko Start a Stop a SW a běží spolehlivě dodnes. Samozřejmě - tyto AP jsou již historie, sice by to službu udělalo i pro tento případ, ale je to udělané tak, že musel být zpětný datový kanál, takže nic. Ten kompilát se sice podařilo podstrčit Sergejovi do Mikrotiku a dokonce ho i spustit, ale na systém spuštění z Winboxu nestačily síly.
2/ - JAK CHCEŠ DETEKOVAT VÝPADEK POMOCÍ UDP, KDYŽ JAK SÁM PÍŠEŠ NENÍ POTVRZENÍ Z PROTISTRANY (promiň za ten capslock, ale je to tak absurdní).
Rád prominu. Na druhé straně stačí pustit graf trafiku na adaptéru nebo v PC přijímací stranu "hltiče" a výpadek je tam krásně vidět. Vyzkoušeno a i tímto způsobem jsem dospěl k závěru, kde je problém. Nikoliv však k tomu, čím je přesně způsoben. Ale i to se vyřešilo, díky radě kolegů. Zkusil jsem i obyčejný Btest, také to funguje, ale dost to kolísá, speciální hltič je mnohem lepší. Myslím, že jsem vynaložil na tento problém dost energie i času, takže ty hloupé poznámky typu, že sedím a třesu se netrpělivostí, kdy mi kolega iTomB poradí, přijdou k smíchu společně i s jejich autory.
3/ - udp generátorů je mnoho, dá se použít třeba i obyčejný iperf
Generátor UDP(hltič) Linux/Windows mám, takže jiný nepotřebuji a ani nechci. Protože takhle alespoň vím, co to přesně dělá a bude dělat a vím, že mi to linku nezahltí, protože to řeže přesně jak nastavím už ve zdroji. A to je pro tento případ zásadní věc.
4/ - Edit: Obecný postup hledání nedostupnosti z mojí zkušenost ...
Pro tento účel mám oblíbenou utilitku, která zaráz pingá jednotlivé IP trasy a pak je krásně vidět, kde to vázne (výstup současně do souboru). Pro tento případ je to samozřejmě k ničemu, protože kde to vázne moc dobře víme, ale proč to vázne, to jsme nevěděli.
C:\Users\ACER>pingtime 192.168.0.154 192.168.0.207 192.168.0.30 192.168.0.215 192.168.0.111
Start
08.05.2019 19:17:02,241 192.168.0.154 3 ms 192.168.0.207 1 ms 192.168.0.30 3 ms 192.168.0.215 3 ms 192.168.0.111 2 ms
08.05.2019 19:17:03,239 192.168.0.154 1 ms 192.168.0.207 4 ms 192.168.0.30 error 192.168.0.215 error 192.168.0.111 error
08.05.2019 19:17:04,251 192.168.0.154 2 ms 192.168.0.207 3 ms 192.168.0.30 1 ms 192.168.0.215 1 ms 192.168.0.111 1 ms
08.05.2019 19:17:05,272 192.168.0.154 5 ms 192.168.0.207 8 ms 192.168.0.30 4 ms 192.168.0.215 3 ms 192.168.0.111 3 ms
Odpovídám víceméně ze slušnosti, protože nadnesený problém s výpadkem 3 sekund je (asi) beze zbytku vyřešen. mpcz, 8may2019
1/ - tvůj program když si ho zkompiluješ může běžet kdekoliv, kde si ho rozchodíš (jestli win/unix/linux/osx ... to je jedno)
To vím samozřejmě taky, ale na mysli jsem měl konkrétní řešení, protože SW a jeho kompilace je jedna věc, ale vybrat krabičku, běžící prostředí, nasát měřící SW a spustit ho je věc druhá. Že to lze jsem si ověřil na 2,4G AP před deseti lety, kde jsem výrobci AP kompilát poslal, on ho zabudoval, do webu přidal tlačítko Start a Stop a SW a běží spolehlivě dodnes. Samozřejmě - tyto AP jsou již historie, sice by to službu udělalo i pro tento případ, ale je to udělané tak, že musel být zpětný datový kanál, takže nic. Ten kompilát se sice podařilo podstrčit Sergejovi do Mikrotiku a dokonce ho i spustit, ale na systém spuštění z Winboxu nestačily síly.
2/ - JAK CHCEŠ DETEKOVAT VÝPADEK POMOCÍ UDP, KDYŽ JAK SÁM PÍŠEŠ NENÍ POTVRZENÍ Z PROTISTRANY (promiň za ten capslock, ale je to tak absurdní).
Rád prominu. Na druhé straně stačí pustit graf trafiku na adaptéru nebo v PC přijímací stranu "hltiče" a výpadek je tam krásně vidět. Vyzkoušeno a i tímto způsobem jsem dospěl k závěru, kde je problém. Nikoliv však k tomu, čím je přesně způsoben. Ale i to se vyřešilo, díky radě kolegů. Zkusil jsem i obyčejný Btest, také to funguje, ale dost to kolísá, speciální hltič je mnohem lepší. Myslím, že jsem vynaložil na tento problém dost energie i času, takže ty hloupé poznámky typu, že sedím a třesu se netrpělivostí, kdy mi kolega iTomB poradí, přijdou k smíchu společně i s jejich autory.
3/ - udp generátorů je mnoho, dá se použít třeba i obyčejný iperf
Generátor UDP(hltič) Linux/Windows mám, takže jiný nepotřebuji a ani nechci. Protože takhle alespoň vím, co to přesně dělá a bude dělat a vím, že mi to linku nezahltí, protože to řeže přesně jak nastavím už ve zdroji. A to je pro tento případ zásadní věc.
4/ - Edit: Obecný postup hledání nedostupnosti z mojí zkušenost ...
Pro tento účel mám oblíbenou utilitku, která zaráz pingá jednotlivé IP trasy a pak je krásně vidět, kde to vázne (výstup současně do souboru). Pro tento případ je to samozřejmě k ničemu, protože kde to vázne moc dobře víme, ale proč to vázne, to jsme nevěděli.
C:\Users\ACER>pingtime 192.168.0.154 192.168.0.207 192.168.0.30 192.168.0.215 192.168.0.111
Start
08.05.2019 19:17:02,241 192.168.0.154 3 ms 192.168.0.207 1 ms 192.168.0.30 3 ms 192.168.0.215 3 ms 192.168.0.111 2 ms
08.05.2019 19:17:03,239 192.168.0.154 1 ms 192.168.0.207 4 ms 192.168.0.30 error 192.168.0.215 error 192.168.0.111 error
08.05.2019 19:17:04,251 192.168.0.154 2 ms 192.168.0.207 3 ms 192.168.0.30 1 ms 192.168.0.215 1 ms 192.168.0.111 1 ms
08.05.2019 19:17:05,272 192.168.0.154 5 ms 192.168.0.207 8 ms 192.168.0.30 4 ms 192.168.0.215 3 ms 192.168.0.111 3 ms
Odpovídám víceméně ze slušnosti, protože nadnesený problém s výpadkem 3 sekund je (asi) beze zbytku vyřešen. mpcz, 8may2019
0 x
mpcz píše:Tohle beru jako výplod typu "přání otec myšlenky". Jak jsi to dotáhl daleko profesně ty, když tady píšeš takové bludy? Nikdo jiný tě neposlouchá, tak si ulevuješ alespoň zde, na fóru, kde si každý píše, ce se mu zachce? Pochlub se! Ať víme, jaký máš mandát k takovému moralizování a jak vážně tu kritiku mám(e) brát!
No narozdil od tebe se v tom celkem vyznam ... Vlastni servery na linuxu s upravym jadrem (celkova spotreba serveru do 40W
), L7 priorizace a rychlosti v radech stovek Mbit/s za zakladni cenu a to i v malych obcich a bez optiky ...Pomohl jsem dat dohromady 2 cizi site. Par lidi odsud me zna osobne a vi ze neco umim ...
0 x
Dík, takže osobnost postižená Linuxem. Nespletl jsem se. (Nic proti Linuxu). Kromě toho, pouze ty se samozvaně vytahuješ, jak se v tom vyznáš. Já se zde slušně ptám, od toho přece fórum je nebo už není? A protože tyhle řádky s tématem nijak nesouvisí, upozorňuji, že se jedná pouze na reakci, odpovědět je slušnost, někdy nutnost. K pozornosti bych dal i to, že právě ti, kteří k vyřešení tohoto problému nepřispěli ani čárkou, vytvářejí zde další a další balast a zbytečně toto vlákno nafukují.
Dovolím si to pro názornost shrnout: můj dotaz 5 řádků, odpověď 3 ř. Polk +1 ř. Pepulis = 8 řádků, beze zbytku vyřešeno. Za pár minut. mpcz, 9may2019
Dovolím si to pro názornost shrnout: můj dotaz 5 řádků, odpověď 3 ř. Polk +1 ř. Pepulis = 8 řádků, beze zbytku vyřešeno. Za pár minut. mpcz, 9may2019
0 x
Kolega Pgb se ptal, tak jen pro ukázku, jak lze touto metodou pro určité případy krásně a jednoduše detekovat místo i směr krátkodobého a náhodného zarušení. mpcz, 10may2019
- UDP_test.jpg (133.77 KiB) Zobrazeno 3758 x
0 x
No jasně že ti to ukáže, že to na druhou stranu nedorazí. Ale aby jsi zjistil kde, tak si ty všechny zařízení po trase musíš otevřít a čekat až to vypadne a koukat na provoz .....to ten ping na všechny zařízení po trase naráz ti to řekne taky hned kde máš poslední hop.
0 x
No ještě se nad tím zamysli, myslím, že jsi to nepochopil. Čekat u toho nemusíš, na přijímači si nastavíš v roletce detekci výpadku a ten ti ho spolehlivě zaloguje. Pro ten zde diskutovaný případ bylo ohledně haprující strany spoje jasno do minuty.
Zrovna tak ten tvůj navrhovaný ping po celé trase ti neukáže v tomto směru nic. mpcz, 10may2019
Zrovna tak ten tvůj navrhovaný ping po celé trase ti neukáže v tomto směru nic. mpcz, 10may2019
0 x
Asi to nechápu a je mi to jedno. Třeba pojem roletka mi je opravdu neznámý. Nevím co má co dělat detekce výpadku (asi myslíš netwatch) s měřením objemu provozu. Prosím nesnaž se mi to vysvětlovat. Vůbec totiž nerozumím pojmům které používáš.
0 x
OK, třeba ti někdo jiný vysvětlí, co to je roletka, když nechceš vysvětlení mé. Ale spíše to je postižení Linuxem. Netwatch nemyslím, mám na mysli funkci toho UDP_testeru. mpcz, 10may2019
0 x
hmm, mikrotik v sobě nemá udp test kterej ukazuje losty...? resp. nedokáže konstantně vytížit jeden směr? Opravdu mi uniká smysl toho řešení.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
hapi píše:hmm, mikrotik v sobě nemá udp test kterej ukazuje losty...? resp. nedokáže konstantně vytížit jeden směr? Opravdu mi uniká smysl toho řešení.
Mikrotik má UDP test, ale ten potřebuje k funkci i zpětný kanál. Takže když to celé spadne, nepoznáš z toho nic nebo se to vůbec nerozběhne. Tento SW ho nepotřebuje. V tom je ten rozdíl. mpcz, 11may2019
0 x
mpcz píše:Mikrotik má UDP test, ale ten potřebuje k funkci i zpětný kanál. Takže když to celé spadne, nepoznáš z toho nic nebo se to vůbec nerozběhne. Tento SW ho nepotřebuje. V tom je ten rozdíl. mpcz, 11may2019
No a pokud je cast na L2, tak z toho stejne nic nepoznas
Mno mikrotik je postaveny na linuxu ... Takze ten kdo pouziva mikrotik, je taky postizenej linuxak
Pokud to je na L3, tak je hodne super mikrotik traceroute. Detekuje vypadky i tam, kde normalni ping jede bez vypadku. Kdyz to clovek vic proveri, tak zjisti, ze to tam neni v poradku. Jak to testuje fakt nevim.
0 x