Příspěvky

1

Sítě / Re:8-port switch 2.5Gbps?

« kdy: 28. 09. 2023, 13:32:11 »

Skoda ze tomu dali SFP+, šiknul by se tam 10G RJ45.

Nastesti to ma SFP+. Z toho 10G metaliku udelate snadno. Z metaliky udelat optiku jaxi nejde.

Btw ten zyxel dava 2,5G i na 70 metru cat5. Vyzkouseno, zmereno.
A kdyz jsme u 10Gb SFP+ - tam jsme zkouseli moduly od mikrotiku a 120(!) metru naboreny trasy na cat5 (nekolik spojek v ceste) a hadejte ;-)
Fungovalo to. Ani merak nenasel problem.

2

Sítě / Re:rtsp stream přes ffmpeg

« kdy: 02. 08. 2023, 21:21:11 »

chybka v syntaxi:

Kód: [Vybrat]

ffmpeg -i rtsp://....

3

Sítě / Re:Doporučte WiFi router pre optický Internet 1Gbps

« kdy: 02. 08. 2023, 21:18:24 »

Pokud je to optický internet, nemělo by tam být rozhraní pro optiku? Jak je zapojený WAN port?

muze to byt FTTH, kde optika konci nekde ve sklepe panelaku. Nahoru pak muze jit uz klasicky UTPko, ci nejaka lepsi alternativa (coz jsem zatim asi nikde nepotkal).

i po 100m utp cat5 dneska protahnete 10Gb (cimz priznavam, ze me desive bavi ty sahodlouhle rozpravy "co natahat v baraku za kabely")

4

Sítě / Re:Přístup na WAN z lokálních adres - povolit či nikoliv?

« kdy: 12. 01. 2023, 05:11:57 »

Oni musia mat nejaku verejku, aj ked spolocnu. Staci isp donutit aby sa museli otocit cez jeho wanove rozhranie smerom k tebe a nie ako teraz, ze mozu ist priamo na teba.

Coz je prave v nekterych topologiich siti takrka neresitelny problem. Napriklad v pripade globalniho NATu, kdy natujete lidi bez verejek az ve chvili, kdy opousti hranu vasi site. Zalezi na tom, jak ma kdo sit postavenou.

5

Server / Re:Záloha desítek GB u kamaráda

« kdy: 25. 02. 2022, 09:07:30 »

to nebude tragikomedie, ale proste pru$er.

Osobne jsem zazil, jak firma prisla o komplet data (ransomware), no ve vysledku jeden den na to prisli, druhej den v poledne fungovali uz na 100%. Stacilo vymenit disky v serveru (stejne to potrebovaly, puvodni byly jeste plotny), nasypat system, nainstalit ucto, ze zaloh natahnout komplet data a bylo hotovo.

Naklady cca 10kKc (cas + disky). Ztraty zpusobene vypadkem veskere nulove.

Cim jednodussi je system zalohovani, tim snaz se to pak obnovuje.

Samozrejme jsou firmy, kde takovy vypadek serveru znamena daleko vetsi pru$er, ale tam taky nepatri tyto primitivni styly zalohovani a obnovy, to uz je ale jine tema.

A ano, znam nekolik firem (nastesti jsem se tam nepodilel na jakekoliv sprave), ktere o data prisly - no, neni to hezky pohled.

6

Server / Re:Záloha desítek GB u kamaráda

« kdy: 25. 02. 2022, 06:46:57 »

Jednou tydne plna zaloha, kazdy den rozdilova vuci plne. Nu a drzel jsem 4 plne zalohy + vsechny aktualni rozdilove.

To zní strašně neefektivně (4x zabrané místo a každý týden přenos celé zálohy - to bych třeba já se svým domácím internetem nedal). A pro obnovu jednoho souboru je potřeba stáhnout celou zálohu?

nerikam, ze to je extra efektivni, ale je to extra levne, jednoduche a funkcni.
Neresim zalohy vyssich stovek GB, ale dulezitych dat (co si budeme povidat, nejdulezitejsi data jsou rodine fotky, pak nejake ucto a pak tuny dokumnentu). Pro male firmicky to je jeste jednodussi.  A jak jsem psal - pokud jsou archivy trosku logicky rozdelene, neni potreba sosat celou zalohu, ale jenom spravnou cast (+ rozdilovku k dane casti).
Navic co se tyka tech linek do internetu - vzdyt je jedno, jestli zaloha odtece za 10 minut, nebo za 6 hodin.  (za 6 hodin na 10Mb lince odsypete cca 20GB dat).

btw u male firmy s cca 40ti zamestnanci maji kompletni ostra data vcetne X let ucta, po zabaleni asi 12GB. To odleze po (takrka) cemkoliv.

7

Server / Re:Záloha desítek GB u kamaráda

« kdy: 24. 02. 2022, 20:11:37 »

Pokud zrojovy pocitac je na windowsech, existuje (stary dobry) cobian backup. Pokud je zdrojem linux a spol, bude tu jiny soft, nicmene pozadavky asi budou stejne.

Resil jsem to nekolikrat a vzdycky bylo reseni +- stejne:
Jednou tydne plna zaloha, kazdy den rozdilova vuci plne. Nu a drzel jsem 4 plne zalohy + vsechny aktualni rozdilove.

Kazda zaloha znamenala zabalit, zasifrovat, odeslat na vzdalenou lokalitu. Co tam slouzi jako uloziste je vicemene jedno, vzhledem k tomu, ze zaloha uz je zasifrovana. Odesilalo se to pres ftp nebo scp, dulezite je, aby vzdalene uloziste nebylo trvale pripojene ke zdroji dat, pak vam ho nesezere ransomware a mate se k cemu vratit. Uz nekolikrat se mi tento postup vyplatil.

V kazdem pripade si obcas overte, ze zalohu dokazete rozbalit, abyste po nejake nehode nemel hromadu nepouzitelnych zaloh.

Ostrych dat nebyva mnoho, ve vysledku nejvic zaberou rodinne fotky/videa.

Vyplatilo se mi delat vice archivu, ale urcite ne archiv per soubor - to silene zdrzuje jak pri baleni/sifrovani, tak pri vlastnim prenosu.

8

Sítě / Re:Mikrotik - jaké porty povolit ve firewallu

« kdy: 22. 01. 2022, 15:08:59 »

pokud mas jako prvni established/related, tak nemusis resit odpovedi na dotazy vznesene z tvy site/mikrotiku.
pak budou dst naty pro portforwarding
a pak firewalling.

a pokud se bojis, ze se odriznes, tak si prihod jeden port, na kterej staci zaklepat a adresa ze ktery na nej zaklepes se z firewallu vykopne. (to pravidlo musi bejt samozrejme na zacatku firewallu)

samozrejme to bude chtit poladit, odzkouset, ale melo by to makat.

9

Sítě / Re:Zkušenost multicast (video) a levné switche

« kdy: 21. 12. 2021, 19:22:08 »

1920 jsou soho switche s jakymsi managementem. Ve starsi verzi multicast snesly docela slusne, ty novejsi (jsou asi 3 roky na trhu, +-) jsou jeste orezanejsi a multicast jim ocividne nesvedci.

Chce to alespon rady 5120/5130, pak to dela co ma a na siti o nich proste nevite.

10

Sítě / Re:Zkušenost multicast (video) a levné switche

« kdy: 20. 12. 2021, 20:54:58 »

vemu to pokud mozno zkratka:

Multicast bez IGMP by se měl chovat jako broadcast. Nepochopím, jak tohle může fungovat chvíli a pak už ne :-)

Switch proste neustoji tu zatez broadcastu a zacne kravnout. U nizsich switchu naprosto bezna vec

Ještě mě napadá - pokud by se multicast bez IGMP choval jako "nenaučený unicast", asi by se to dalo zabít odesláním paketu se zdrojovou příslušnou multicastovou L2 adresou ;-)

Prekvapko: mac adres odpovidajicich IP adresam multicastu neni nejak extra moc, stava se, ze vice multicastu ma stejnou macovku. Krabice si to pak musi prekousat na vyssich vrstvach.

Měl jsem pocit, že to že pakety mohou dorazit "out of order", není v paketových sítích chyba ale vlastnost :-)

Ten counter v hlavicce multicastu ma 4 bity. Takze 16 packetu v rade a pak jede od nuly. Nic moc rezerva.

...soudím, že zde srovnáváme 1) ani ne tak s unicastovou adresací, jako spíš 2) s TCP vrstvou, která garantuje doručení při mírné ztrátě paketů a re-ordering při doručení s proházeným pořadím.

vsechny videosluzby jedou nad TCP, mam dojem ze vyjimkou je google ktery snad ma nasazen protokol quic nebo jak tomu hybridu rikaji, nejak vic jsem se tomu nevenoval. Vsichni resi bufferovani v radu minimalne desitek vterin, aby dokazali zakaznikum dopravit videoobsah i na nekvalitnich linkach. Z principu UDP nema vetsi bufferovani u multicastu zadny smysl - co nedorazilo ve spravnou chvili to uz nedorazi.

Předpokládám, že multicastovat video v mixu s normálním provozem má smysl jedině v kombinaci s priorizací videa - jinak se budou ztrácet pakety toho videa, s popsanými důsledky.

jakakoliv prioritizace je jenom berlicka, jedine overene reseni je dostatecna kapacita linek. To uz dneska neni takovy problem, 10Gb lasery stoji par korun. A na vsech switchich (pokud zrovna na nich zrovna neni PIM) musi byt zapnuty igmp snooping, jinak napriklad zakaznikovi v panelaku dorazi do boxu vsechny mulsticasty prihlasene na dane lokalite -> to box vazne neukousa.

Asijské levné managed/websmart switche zvládají bez problému zhruba statické VLANy a 802.1q a snad STP. Jakékoli chytristiky navíc jsou příjemný bonus, ale nelze a priori spoléhat na bezchybnost :-(

Bez urazky, testy switchu stredni tridy asijskych vyrobcu nedopadly pri vetsim zatizeni multicasty zrovna na jednicku. Proste jakmile je tech multicastu vic, maji s nimi problem. Vic jsme se tim nezabyvali a nasadili overene reseni.

Osobni nazor, o kterem zde ale nechci diskutovat: v uvahu pro nas pripadaji Cisco / HP switche. Cisco bohuzel hraje hru s licencemi na vyssi funkce, HP je na druhou stranu za polovicni cenu a taky dostatecne funkcni.

11

Sítě / Re:Zkušenost multicast (video) a levné switche

« kdy: 18. 12. 2021, 21:23:35 »

V sitarine jsou multicasty pro IPTV osina v zadku. Ano, maji sve vyhody, ale jakejkoliv problem v siti je hned (doslova) videt a zakaznici jsou nervozni.

konzumni trida switchu vubec nema sanci iptv v multicastu odbavit, proste jsou potreba slusny switche (hp, cisco a spol). To samy plati pro radia - cokoliv halfduplexniho, MIMO a spol nema sanci ten provoz odbavit - ono totiz zalezi i na poradi packetu a jakmile se prehazi, je to v haji.

priklad: kdyz chybuje trasa, treba 5 chyb za minutu, tak v klasickym pouziti to nikoho netrapi a prijde se na to vicemene nahodou (samozrejme dohledovej soft by to mel ohlasit). Pro iptv v multicastu uz to znamena smrt, potazmo rozpad obrazu do rubikovky.

Ve vysledku to je strasne jednoducha matematika - pokud chce clovek provozovat IPTV v multicastu, musi mit sit na 100% funkcni. Jinak z toho bude vzdycky rubikovka.

12

Sítě / Re:Dotaz k Native VLAN mismatch

« kdy: 17. 09. 2021, 14:43:41 »

"Korektne dle vyrobce". Mas asi na mysli IEEE 802.1Q.  "STP je peklo", "dokaze odpalit port"..  Jasne. Achjo..

ano, mluvime o vlanach, cisla IEEE si taky umim najit nebo si je pamatuju.
a ten zbytek? ano, to je vecne vyjadreni nazoru
mozna by to chtelo trosku rozepsat.

13

Sítě / Re:Dotaz k Native VLAN mismatch

« kdy: 15. 09. 2021, 06:04:57 »

v praxi by to udelal naprosto stejne, nez se delat s precislovanim vlany tak jak by to melo bejt udelany korektne dle vyrobce.

a STP je peklo, ktery je dobry akorat vypnout. Naprosto bezduvodne (teda ono si mysli, ze duvod ma) dokaze odpalit port (nejlepe privodni). Provideri by mohli vypravet

14

Sítě / Re:Netflix snižuje rozlišení na gigabitové lince

« kdy: 31. 05. 2021, 19:11:12 »

jsou jenom dve moznosti -
1) nestiha provider (coz v pripade optiky nebyva moc bezne)
2) nebo spis CDNka netflixu. po prepojeni na souseda to jde na jinou CDN, ktera stiha.

kdo nevi co je CDN: velmi jednoduse receno je to vyrovnavaci pamet, fyzicky se jedna o X serveru ktetre jsou "nekde bliz" po siti, typicky u providera nebo jeho upstreamu a je z nich odbavovan provoz.
Vice viz google: content delivery network

15

Sítě / Re:10G switch Mikrotik?

« kdy: 14. 04. 2021, 18:52:27 »

myslim, ze vam dokaze odpovedet jenom clovek, ktery hodil dany switch na rfc merak.

objemove ten switch urcite nevytizite, uzke misto muze nastat v pps - corosync pri oprave (umrely disk a spol) umi vygenerovat i statisice PPS - a to ne kazdy switch prezije bez uhony. Matne si vzpominam, ze kdyz kolega mel blbej den a vyskubnul ze tri stroju po jednom disku (zbylo jich tam dalsich 3x15) aniz by je odpojil od clusteru, tak PPS se limitne blizilo k 1M. Ruku za to do ohne ale nedam.