- Projekt (projekty) 22
- půlsemestrální zkouška (půlsemestrální test) 18
- semstrální zkouška (ústní) (ústní část závěrečné zkoušky) 60
- Aktivita v předmětu (konzultace) 6
Přednášky jsou každý týden, demonstrační cvičení pouze v následujících termínech:
- pátek 13.2.2026 - rekapitulace síťových technologií (E104)
- pátek 20.2.2026 - představení projektu a diskuze k řešení (E104)
- pátek 27.3.2026 - půlsemestrální zkouška (D105)
- pátek 10.4.2026 - programování P4 (demo cvičení, laboratoř C304)
Půlsemestrální zkouška (písemná): pátek 27.3. od 11:10 do 12:40 v D105.
- komunikační protokol = syntax a pravidla
- potřeba standardizace komunikace
- client-server
- server statický. static ip
- clienti adhoc připojení
- peer-to-peer
- větší míra decentralizace
- simplex = pouze 1 daný směr
- half-duplex = obousměrná, ale 1 směrem v 1 okamžiku
- full-duplex = furt obousměrná
- unicast
- broadcast
- multicast
- anycast = DNS, nejsme schopni rozpoznat od anycast
- connection-oriented = vytvoření stálé připojení
- connectionless = nemám ustanovení, pouze sypu data do sítě
- UDP, IPv4
- odesílatel a příjemce na sebe nevidí
- více-uzlový TCP = neřešitelný
- historické rozdělení vrstev
- ethernet = obrovská šířka pásma, není blocker (je to naše zařízení a aplikace, podle toho, co zvládne z konzumovat)
- end-to-end princip = měníme jen vrstvu 2. a 1.
- vrstva 3 - id = IP adresa
- vrstva 2 - id = MAC adresa
- vrstva 1 - ethernet nemá id
- media access control
- rozdělení médium mezi všechny účastníky a nedám 1 pokud není sám, celý přístup k médiu
- pseudo linková vrstva
- analogový signál na třeba ethernet
- z 1 signálu jiný signál
- L1
- HUB vs switch
- Switch “je chytřejší hub” - nestačí na státnice
- CAM tabulka - mapování mezi MAC adresami na switchi a portama switche
- sloupeček číšel wlan
- hub a repeater
- rozšiřují kolize
- snižují rychlost posílání na 1/2 - pořídit další router
- hub je multiportový repeater
- switch je multiportový bridge
- L2
- Switch
- CAm tabulka - korelace portu a MAC adresy
- učící se fáze odkud rámec přijde - MAC adresa z portu
- pokud neznám, tak floodne všechny porty
- nesprávné MAC adresy zahodí
- zvětšují huby a repeatery
- zmenšují switche a bridge
- místo kde může dojít ke kolizi v médiu
- kolize - pouze v half duplexní komunikaci nebo obsazeno ve wifi
- routování
- hledání, kdo bude další po cestě
- může mít různé linkové technologie
- fragmentace = rozkrájení balíku na menší části
- routovací tabulka
- velmi dlouhá - až miliony záznamů
- longest-prefix match -
192.168.2.0/24 je lepší jak 192.168.1.0/16
- Maximum transmission unit
- čím větší balík, tím menší overhead
- čím menší balík, tím větší overhead
- pro větší balík bude dlouho trvat, než se pošlou data dalšího uživatele
- pro složení musí dostat všechny části, jinak nesloží
- L2 - samé
FF - flood
- L3 -
192.168.1.255/24, má 255 podle prefixu
- DHCP pošlu na adresu
255.255.255.255
- sdílené médium
- potřeba nastavit obě strany na stejnou rychlost
- duplexness
- síťovka vyřeší problém se špatným kabelem - desktop a switch, ale nemusí router
- 48-bit adresy
- první 3. bity podle výrobce
- částečně unikátní adresa, výrobci chtějí šetřit adresy, x-krát stejné, lze “přepsat” OS
- v 1. bytu
- unicast vs multicast
- lokální vs globální unikátní
- SFD = Start of Frame Delimiter
- 1 rámec skončil a druhý začal
- SOF = Start of Frame
- adresa 32bit
- best-effort
- ale chceme prioritizovat balíky - např od bank
- taky chceme markovat provoz
- IntServ = protokol RSVp
- delay, throughput - nemůže fungovat na celém internetu
- DiffServ
- classful
- classless
- subnetting
- variable length subnet mask
- classless interdomain routing
- 128B
- fragmentace pouze na koncovým uzlu
- path MTU discovery - musí se použít
- energeticky vysoce náročná pro IoT
- broadcast nahrazen multicast s adresou skoro jako broadcast
- cílem využít co největší balík na síti
- interface id - hostovská adresa
- subnet pro vut
/48 - 16 bitů pro sítě - až 65534
- udělání adresy z MAC adresy
- prostředek se vyplní
FFFE byty
-
- bit od začátku se dá na 1
- subnet adresa je random “hod kostkou z 2^64”
- kryptograficky náhodná adresa
- neuchytilo se
- prefix
FE80::/10
- spodní 64 bit je interface ID
- více interfacu IPv6 síťové karty se stejnou local subadresu - suffix
%13
- nová adresa
FF02::1:FF/104 a spodních 24bit a interface ID
- pro komunikaci s multicastem
- nejen unicast adresy, ale i multicast adresy pro IPv6!!
- unicast - source a dest ipv4 a mac adresa
- s routery se přidají gateways
- broadcast 255.255.255.255
- multicast - multicast adresa + na switchi mapovací tabulka s odběrem multicastu
- anycast
- ethernet unicast - 7.bit jestli je broadcast nebo unicast
- ethernet broadcast - samé FF
- ehternet multicast -
01-00-5E pro IPv4, 33-33 pro IPv6
- ARP
- ND
- lze zafirewallovat, ale rozpadne se síť
- substituce ARP
- plug and play
- řeší duplicitní adresy - DAD
- router advertisements = abych zjistil v jaké síti se nacházím
- část protocolu ICMPv6
- ND
- multicast listener protocol
- ptá se na mac adresu pomocí solicited-node multicast adresu
- zná IP adresu, zná tedy i tu multicast
- multicast
- neighbor discovery
- řeší problém, že si zařízení může přidělit samo
- aplikační vrstva
- client-server komunikace
- nad UDP
- DHCP discover -> offer -> request -> acknowledge
- request - jeli více dhcp serverů který offer si vybral
- DHCP server v jiné síti - broadcast od clientů se přeloží na unicast na server
- Stateless address autoconfiguration v IPv6
- když získá router advertisment z routeru podle
- -> prefix sítě, vygeneruje si adresu a začne ji hned používat
- chybí výchozí brána - je to kdo posílá router advertisement message
- chceme zjistit v IPv6, že někdo už v síti nemá naši adresu
- solicited multicast na danou adresu!
- obsahuje 24bit adresy
- global link - router solicitation
- multicast na adresu pro všechny routery
- dostane prefix
- znovu se zeptá, jestli někdo nemá adresu
- stateless a stateful verze
- flagy Managed a Other
- stateless
- adresa z routeru, ale dns server, doména, atd z dhcpv6
- stateful
- managed flag
- vše kromě vstupní brány a prefixu (i ip adresa, …)
- DHCPv6 klient obdrží prefix, který si subnetuje doma
- používá se jako bezpečností řešení
- port forwarding
- dest nat
- měl by měnit pouze ip
- není problém s renumberingem
- dělají i mobilní operátoři = cgnat prefix
- distribuovaná databáze
- fully-qualified names (FQDN)
- rekurzivní = dostanu odpověď od prvního serveru
- iterativní = dostanu odpověď a musím se zeptat dalšího serveru
- L4 vrstva
- porty
- tcp, udp
- adresování
- end-to-end správa spojení
- QoS (zotavení z chyb. spolehlivost, řízení toku a zahlcení)
- spousta výzkumu v aktuální době
- berkley sockets
- ip je best effort
- pokud je problém musí řešit vrstva né L2 L3
- chci const bitrate, const zpoždění, 0 věcí ztracených -> musíme mít buffer
- fixní buffer - co když buffer bude plný
- proměnné buffery = není vhodně pro routery, ale pro koncová zařízení
- sdílené buffery
- dichotomie cílů
- end-to-end systémy = servery, laptopy, …
- síť
- problém je, že buffery jsou konečné velikosti
- kapacity příjemce a síťě -> flow a congestion control
-
goodput
- v internetu mnoho routerů s různými parametry
- od určitého bodu se nám goodput začne rozpadat místo toho, aby se blížil k limitu propustnosti
-
delay
- od určitého bodu skáče na dlouhé zpoždění
-
alokace band width
- pokud chceme řešit problémy, musíme mít chytřejší routery - to se v 60. letech nechtělo, kvůli implementaci a monopolu nad routery
- je potřeba v síti, neboť omezení 1 uživatele tyto problémy nevyřeší
- problém s ip adresou je identifikátor rozhraní, stejné jako
- bitové chyby
- paketové chyby
- vytvoření spojení, zrušení spojení, pak nové spojení, a se zpožděním přijde paket z prvního spojení
- navázání spojení
- poslání balíku
- zrušení balíku
- nový request -> ack
- starý duplikát -> reject
- duplikátní connection request a duplikátní ACK -> reject
- ztratí se ACK - máme timer
- Timeout
- Negativní potvrzení - pro spolehlivé spojení!, spíš nepoužíváme
- fixní je nepraktický - ping v counter striku
- lze odvodit z Route Trip Time!
- problémy:
- dlouho čekáme na ztracený paket
- příliš malý - hází do sítě duplicitní pakety
- bere route trip time
- konstanta a
- zjemněný timeout srrt
- nejvíc ovlivňuje konstanta a a srtt0!
- znovu zaslání
- ARQ = Automatic Repeat/Request - čeká na 1 balík s time outem
- rychleji
- Stop and wait ARQ - špatná efektivita, klouzavé okno velikost 1
- Go back N ARQ
- buffer na straně odesílatele, posíláme N zpráv
- cíl = mít na cestě tolik balíku, jaké je velikost okna
- plýtvá šířku pásma
- Selektivní znovu zaslání ARQ
- 2 okna na straně příjemce a odesílatele
- fast retransmit - hned pošle který přijal
- bitová maska - pošle se na konci timeoutu / přijetí všech, které byly přijaty
- negativ ack - po nějaké době pošlu negativní ack
- SMART
- bitová maska v každém acku
- error-control window
- sliding window = klouzavé okno
- nenarůstá delay
- redundance bytů
- klesá goodput - k + m bytu
- repair vs avoid
- avoid není jenom možný - prostě někdy selže - všichni uživatelé F5
- vyhlazuji stream paketů na stejný stream
- hodně bufferů
- potřeba virtuálních okruhů
- reliable transfer
- inorder byte stream - pouze množství bytů co v balíku je
- flow control
- connection oriented
- ECN = explicit congestion notification bit
- zahájení : SYN, SYN + ACK, ACK
- ukončení : FIN, FIN + ACK, ACK
- potvrzení
- kumulativní - potvrzuji vše byty před danou velikostí
- selektivní - pokud 3x ack, nečeká na timeout a znovu pošle
- nevýhody
- head-of-line blocking
- vše je blokováno 1 ztraceným paketem (protože in order
- nepodporuje multihome - napojeno na IP
- velká režie
- ssthresh = slow start threshold, pomalejší nárůst okna
- tcp tahoe - když dolezlo na strop, tak window size na 0
- tcp westwood
- když 3 duplic ack, tak snížím na 1/2, komunikace je, jen ztrácím pakety
- pokud timeout - síť zahlcena
- tcp cubic - kubické křivky, asymptoticky se blížím ke kapacitě síťě, pak rychle zvednu
- connection less - problém se zahlcením, trpí TCP
- UDP s congestion control
- minimální overhead pouze pro congestion control
- best effort
- žádné znovu posílání
- ustanovení spojení - connection oriented
- 3way handshake
- Request + response + ack, data + ack, Close req + close + reset
- řízení zahlcení - ccid2 = tcp, ccid3 =
- TCP neumí využít více síťovek na jednom pc
- Bez HoL blockingem
- TCP problém s inorder byte streamem!
- -> message stream (hranice aplikačních dat jsou respektovány)
- zvětšila signalizační režie
- connection management
- multihoming
- 4-way handshake (zabraňuje syn-flood - spam vytvoření připojení)
- path MTU discovery - obrana proti fragmentaci
- komunikace
- spojení: INT, INT + ack, cookie echo, cookie ack
- data paket (seriove číslo + délka) + SACK
- multiplexing tcp
- použití příjmu/poslání paketů, přes více rozhraní
- řízení spojení
- při navázání dodatečný option s “tokenem”
- 2 druhy sekvenčních čísel - subflow a data
- subflow = tcp hlavička
- data = pro celková data pro poskládání dohromady
- nezávislá sliding window
- řízení zahlcení
- férové s tcp
- vlastní algoritmy
- nevýhoda = in-order byte stream!!
- over optimalizace webových služeb googlu - přenést míň dat, zrychlit doručování služby
- problém s tcp a tls -> 3x rtt před začátkem komunikace
- běží nad UDP -> problém s NATem, nechci nový protokol a učit routery
- multiplexing před UDP (do několika streamů)
- lepší než spdy - streamovat obsah webu v podobě, co není čistá txtová verze webu
- packet pacing predikce bandwith
- proaktivní znovu posílání
- zpráva
- je vědom hranic aplikačních zpráv oproti TCP
- rámec 1 obalím hlavičkou a pošlu, taky přidám rámec 1 do paketu 2 (do jiného streamu)
- “shape-shiftovací hlavičku” - hlavička má variabilní velikost!, daná public flags
- Forward error correction
- data které se ztratí, tak jsme schopni odvodit z dalších paketů. podle parity - ale posíláme více dat
- řízení toku
- znovu posílání - largest observed, missing
- odstranění ssl handshaku - stk
- znovu použití komunikace/nastavení při opakovaném připojení
- řízení zahlcení
- tcp cubic - zkoušíme se blížit thresholdu, pak zkusíme větší
- všechny spojení jsou neustálé - zbytečné počatí a ukončení spojení
- synchronizace stavu
-
- send = 3*delta t- odesílací časovač
- receive = 2*delta t - přijímací časovač
- pozoruje parametr delta t u časovačů
- management spojení
- resetování/ukončení - podle vypršení časovače - smažeme hodnoty
- podmínky pro otevření
- žádné spojení neexistuje, zahazujeme paket, které by vytvořili spojení nebo jsou duplikáty dat
- pokud spojení existuje, zahazujeme pakety z předchozího spojení
-
- randezvous mechanismu
- pomocí flow control received není schopen přijímat
- v aktuální síti neimplementovatelné
- nejsem zaručit real time čas u časovačů - časovače narostou
- analogie pošťáka
- vždy důležité adresování
- identifikátory
- IP, Port, MAC
- Flat addresses (pošťák musí znát mapu/topologie) vs Hierarchical addresses
- Unicast - typy A,B,C, 1:1
- Broadcast - 1:V, subneting, dhcp, arp
- Multicast - rozdělení
- Anycast - subset unicastu - DNS
- Port
- catalog value - není vzdálenost portu
- 16 bit
- MAC
- flat - říká něco o výrobci, ale nic o umístění
- pseudohierarchical (NetID + HostID)
- 32 bit
- BGP - fix pro firmy, které si dokoupili adresy později a mají 2 odlišně adresy fyzicky blízko sebe
- Ripe NCC pronajímá address space (konečný space)
- registrator domen (nekonečný space)
- 128 bit
- pseudo hierarchical (prefix + inter)
- větší tlak na heirachizaci
- regional registrator - /23
- LIR (O2,) - (/28-)/32
- úroveň zákazníka - /48
- subnetting - 2^16
- interface ID - 2^64
- tabulka záznamů
- metrika
- vzdálenost s jakou vidí protokol a existující síť
- menší je lepší
- adresa + prefix
- interface - odchozí
- Administrativní Distance - důvěryhodnější cesta
- next hop - must have
- source (reprezentované písmenkem)
show ip route, show ipv6 route, windows: route print- Unicast Topology - zdarma paketová laboratoř
- 2 tabulky pro IPv4 a IPv6
- stejné parametry, ale jiná tabulka
show mac address-table- mac addresa a na jakém je interface
- switching
- snaha co nejrychleji dostat
- routing
- které rozhraní použít nějak chytře
- nechceme směrovací tabulky dělat ručně
- udržuje směrovací tabulky zasynchronizované, tak že tam nejsou smyčky
- Distance vector
- neví, jak vypadá celá síť - jen, co slyšel od sousedů
- Link-state
- znají celou síť - uzly a hrany mezi nimi
- OSPF
- Path-vector
- kromě IP, taky cesta autonomních systémů, přes které má projít
- víc než 1 metrika
- Autonomous system
- 16 bit - nestačilo -> 32 bit
- exterior = jaké venkovní propojení chceme použít pro dosažení venkovní sítě
- interior = jak dosáhnout uzel u gatewaye
-
politika
-
outbound - jednoduché - my si vybereme, kam pošleme
-
inbound - složitý - můžeme říkat, kudy mají pakety chodit, ale neznamená, že se tím budou řídit
- místo placení provideru uděláme přímé spojení a platíme pouze sobě
- ripv1 - classful - class A/24
- ripv2 - classless
- Request / Response
- Zprávy
- Hop count as metric
- no neighbor detection
- každých 30 vteřin poslat celou DV
- vyžádané/nevyžádané
- nerespektuje rychlost sítě
- při výpadku sítě, nám soused tvrdí, že síť má na dosah z nějakou vzdáleností, další výměna, nám zvedne hop count, pošleme sousedovi -> jde do nekonečna
- infinity = 16
- nebudu záznam posílat zpět, ze které routerů jsem se naučil
- pouze pokud znám z jiných routerů
- posílám 16 hop count pro síť, která vypadla
- distance vector protocol
- původně cisco proprietary, poté RFC7868
- classless
- informace o IPv4, IPv6, …
- composite metric (není prostý hop count)
- neighbor detection
- Reliable transport protocol - stará se o spolehlivý přenos, musí být vlastní protokol, protože používá různé adresovací
- DUAL finite state automata
- matematický důkaz, že nevzniká smyčka
- šířka pásma
- delay
- load = vytížení linky
- reliability = spolehlivost linky - bitové chyby, …
- energy (popř jitter)
- defaultně bandwidth + delay
- feasibility condition - jestli nezná cestu přese mě
- pokud soused má kratší vzdálenost k cíli, než mám já -> nemůže cesta vést přese mě
- RFC 6126
- zprávy
- neighbor detection
- source node feasibilty jako EIGRP
- různé metriky
- k z j doručených paketů
- etx
- z3
- route trip time
- OSPFv2 - pouze IPv4
- OSPFv3 - pouze IPv6, později rozšíření přidána IPv4
- zprávy
- neighbor detection - každých 5 vteřin dotaz
- link-state advertisements
- místo tabulek se posílá od každého uzlu jaké má přímé spojení s ostatními uzly
- LSA se obnoví 30 minut
- metrika
- cena (cost) = 100 Mbps / bandwidth
- při použití areas - fog of war další areas
- rychlejší konvergence dijkstra algoritmu
- hranicové uzly si musí hodně pamatovat
- connection oriented/less
- ethernet, token ring, …
- spousta možností - jde genericky
- ES-IS: mezi end station a gateway
- IS-IS
- IRDP: mezi autonomními systémy
- clns je adresa uzlu, né interfacu!!
- adresování nemusí být fixní velikost - chceme pouze unikátní adresování
- snpa
- identifikátory připojení
- definuje 4 různé typy metrik! - to zajímavé
- EGP předchůdce, classful
- policy based
- přes TCP port 179 mezi 2 peery
- interior a exterior peers
- route selection
- 11 pravidel, jak vybrat nejlepší - admin sítě může upravovat
- CIDR - agregace sítí do 1 místo 255 různých sítí
- nezajímá detail, mnoho metrik, policies, AS
- neřešíme problém s novou technologií
- nezajímá nás dest, ale zdroj
- rozkopírování paketů - musíme řešit bez smyčkovot
- reverse path forwarding
- směrovací protokol
- dense
- sparse
- source
- bi directional
- ^ “různé” protokoly ikdyž 1 jméno
- seznam outgoing interfaces
- 1 incoming interface (ostatní cesty zahazujeme pakety, aby nevznikli duplikáty)
- Multicast source discovery protocol - někde vznikl zdroj multicastu
- IGMP, PIM, MSDP, BGPv4 - na rozjetí multicastu
- BGPv4 umí multicast
- televize a radio
- vs unicast: IGP a BGPv4
- STP = zajišťování bezsmyčkovost, odříznutí sítě
- štítky, můžeme stackovat a ovlivňovat kudy data půjdou
- náročnější na hw
- jako mpls, ale není tak náročné na hw
- hraje si s rozhodovácími tabulky
- spolehlivost, podmínky vzniku smyček, … (probublávají věci z L3)
- problém, že IP je stejné mapování jako MAC
- 2 adresy u 1 zařízení
- problém adresa je adresa interface, né zařízení!!
- CLNP v ISO-OSI
- vrstva L2 - MAC adresy
- unicast, multicast, broadcast - jako u L3
- CAM tabulka
- propustnost přepínače
- Kolik portů máme
- rychlost karet
- Buffery
- Switch fabric
- řadič - která karta může přepínat a kam, které přenosy se budou kdy dělat
- maximální propustnost
- Paralelní přenosy
- nejde, když je stejná destinace
- head of line blocking
- blokování na začátku fronty - jeden packet nám zamezí odesílat další packety
- Rozšiřitelnost
- fyzikální omezení - nejsme tak schopni tak rychle zapsat do paměti, …
- Propustnost - bit/s neudává, jak se chová pro danou velikost packetu, často tedy packet/s (pro různé velikosti packetu konkrétní rychlost)
- latence - zpoždění (doba přenosu) ze vstupu na výstup
- přenos pouze z 1 zařízení
- pokud je rychlost sběrnice má být stejný jako součet všech rychlostí na kartách, jinak bude rychlost sběrnice bottleneck
- nativní přenos broadcast, multicast
- rychlé a levné na vyprodukování
- Co se stane, když přidáme porty?
- rychlost portů
- úkol
- 1.6 Gbps a 40 bit sběrnice
- rychlosti karty - 1Gbps -> větší propustnost, ale problém se sběrnicí -> 400 bitů - zvětšit frekvenci
- 256 portů a 32/64bit sběrnice - fyzikální limit
- když 1 karta ovládá sběrnici, všechny si načtou rámec, pak se řeší pro koho je
- centrální paměť
- pevná velikost
- př větším plnění jedné fronty zahazujeme packety, i když máme místo
- flexibilní
- alokace a dealokace front
- buňky pevné velikost
- výhoda: nativní implementace multicast, broadcast
- úkol
- 5 ns, 0.5 ns, 0.125ns
- DRAM 50ns, SDRAM 5 - 10 ns
- velkou propustnost / hodně portů už neuděláme ani
- paralelní přenosy už v architektuře
- nevýhoda: když přestane fungovat 1 pole = celé vyhodit
- jeden packet blokuje celou frontu, protože čeká na port
- rozdělíme vstup na více front -> drahé řešení - virtuální fronty
- VOQ
- problém s párováním (matching)
- bipartitní graf
- Jak najít párování, aby žádné 2 hrany ze vstupních portů neměli 2 stejné výstupní porty
- největší párování - globální maximum, v praxi moc složité
- maximální - přidávám hrany, dokud nemůže přidat další hranu - lokální maximum
- maximální párování pomocí náhodné volby
- soutěžení o výstupní porty
- může přijít více povolení na různé výstupní portu - vstupní port musí 1 vybrat
- optimalizace pomocí více iterací, při první jen zarezervuji, znovu request, co nemají zarezervované, …
- problém s implementaci pseudo-náhodného generátoru - výpočetní režie na každém portu
- při soupeřní o port se používá rotující ukazatele
- ukazatele se po úspěšném přenosu posouvají
- nemusím používat náhodný generátor oproti PIMu
- naivní řešení - replikace - pomalé
- speciální fronta pro multicast
- no fanout splitting - přenos multicastu je v 1 časovém úseku
- fanout-splitting - přenos části multicastu zároveň pri unicastu
- ESLIP - implementace algoritmu
- nemůže být dynamické fronty pro multicast - bylo by jich moc - dynamicky se mění multicastové adresy
- zvětšování počtu portů, aniž by se dramaticky rozšířilo přepínací pole
- vnitřní přepínací obvody
- 3 stupňové
- m počet vnitřních křížových bloků
- n vstupní a výstupní portů
- r počet vstupních křížových přepínačů
-
- stupeň vstupní křížové přepínače
-
- stupeň vnitřní křížové přepínače
- m cest je dán počtem vnitřních bloků
- 24 portů - 4 vstupy -> Clos(x, 4, 6), m se dopočítá
- Closův teorém neblokující sítě
- modifikované řešení (rearrangeably nonblocking)
- $ m \geq n$ -> levnější
- není neblokující
- pokud chceme neblokující řešení - potřeba přeskládání
- rekurzivní přepínací síť
- základem je Clos(2,2,1)
- pro vyhledávání - smyčkový algoritmus
- neblokující výsledek
- architektura přepínačů - nejčastěji se liší v přepínacím poli
- směrování = vyhledávání cesty na základě cílových IP adres
- zjišťuje podle směrovacího protokolu
- L3 vrstva OSI/ISO
- ICMP zprávy = chyby sítě
- firewall a NAT
- fragmentace
- směrovací protokoly
- hledám záznam, co má největší prefix
- změna směrovací tabulky vyvolá změnu forwarding table - musí se vypláchnout
- to stejné s ARP cache
- src MAC - z adresy rozhraní
- dst MAC - z ARP protokolu
- next hop - soused
- Vysoká propustnost - až Terabity za sekundu
- chceme rychle přepínat -> není QoS!
- zabezpečení - první zařízení na které se útočí, protože je hraniční
- otevření tunelu z vnější sítě - nikdy otevřené spojení! - nutnost šifrování
- omezení připojení, podle toho, co stíhá šifrovat
- např univerzity
- podpora QoS
- většina komunikace uvnitř sítě (trochu se mění s cloudem)
- fyzické části - hw na kterém je funkcionality
- síťově karty, deska s procesorem, deska, porty a přepínací
-
- na vstupní kartě se řeší L2, aby se dalo pouze starat o L3
- centrální procesor - na Router Processor card
- routing table - buď kopírována na každou kartu nebo dotazy na procesor
- kontext packetu - veškeré informace z L2 a L3 ohledně paketu - slouží pro obhospodaření kam a jak se má paket poslat
- data plane = hardwarové zpracování
- control plane = zpracování na CPU
- rychlá cesta : přepínání bez účasti centrálního procesoru - máme všechny známé informace
- rozdělení zátěže - round robin
- nevýhoda: může dojít v doručením datagramů mimo pořadí
- jak zrychlit softwarové přepínání
- cachování! - ukládáme informace, které si zjistím pro daný tok -> fast caching
- problém: cache není nekonečná
- hodně různých toků
- souvisí s velikostí směrovací tabulky
- vypadne síť -> musím invalidovat cache
- zneplatnění MAC adresy - expirace ARP cache -> musíme invalidovat cache -> musí se udělat ARP záznam přes slow path
- nová síť - nic nedělá s cache, až dojde první paket
- problém rekurzivních cest
- zneplatnění, které nevím
- musel bych si pamatovat propojení - náročné na provedení
- zátěž
- rozložení podle cílové adresy - hlavně nedeterministické a asi neefektivní
- bude se používat než se neinvaliduje cache - až při zneplatnění ARP cache
- záleží na adrese SÍTĚ která je ve směrovací tabulce
- Tabulka CEF
- 256-ární strom
- vytváří se ze směrovací tabulky, hned při změně informaci se změní
- Tabulka sousedů (Adjacency table)
- next hop
- předpočítaná hlavička - src mac, dst mac, type
- rozdělení zátěže
- buď per packet
- nebo hash table z src a dst adresy ip - load share table
- pouze pro velké routovací tabulky nebo velké změny v routovacích tabulkách
- ACL a filtrovací pravidla - rozdělení provozu na ten, co projde a neprojde
- směrovače
- směrování - CAM tabulka
- QoS - kvalita služeb - rozděluje do které fronty paket dát
- na základě
- IP adresa,
- port,
- Type of Service,
- MAC adresy,
- aplikační hlavičky,
- IP protocol - TCP, UDP, …
- vyhledávání adres - pomocí cílové adresy
- firewall = ACL listy
- filtrování na 2 místech - na vstupním rozhraní a na výstupním rozhraní
- pokud zařízení generuje pakety -> pak nechodí na vstup
- může být více rozhraní -> vstupní nemusí filtrovat požadovaní filtry -> potřebujeme i na výstupu
- chybně zadané - špatné pořadí 40 a 50, bere se 1. vyhovující podle pořadí, 40 pohltí a překoná pravidlo 50
- u intrusion detect systémů
- pro každý specifický protokol musí být parser!
- potřeba bufferu na uchovávání paketů -> nebude implementováno v HW ale na control planu
- čím víc pravidel, tím víc zpožďuje
- prvních 20-30 bytů
- vyhledávání podle nejdelšího společného prefixu (LPM longest prefix match)
- nezáleží na pořadí ve směrovací tabulce
- výběr cesty podle
- administrativní vzdálenosti - číslo vzhledem k důvěryhodnosti protokolu
- metriky - podle směrovacího protokolu
- délka prefixu
- Která cesta se vybere pro paket s cílovou adresou 192.168.32.1?
- pošle se na 1. síť, protože má nejlepší prioritu podle směrovacího protokolu
- Jaké pravidlo se použije k poslání IP datagramu s Cílovou adresou 10.10.13.214?
- poslední OSPF - nejdelší prefix pro .208 a .214
>>> bin(208)
'0b11010000'
>>> bin(214)
'0b11010110'
- kontext paketu = Vybereme všechny hlavičky, které můžeme potřebovat pro filtrování (dáno pravidly)
- klasifikátor - porovnává data z hlavičky vůči pravidlům (porovnávání n-tic)
- způsoby porovnávání
- exact match
- prefix match
- interval match
- Jaká je časová složitost?
- Lineární složitost vůči počtu pravidel a počtu sloupců. $\mathcal{O}(N \times R)$
- → nepoužitelné pro stovky pravidel a několika sloupců (5+)
- pro prefixové vyhledávání - stromová struktura trie
- uzly co nemají pravidlo jsou pomocné uzly
- při stejné délce vezme se dané pravidlo
- při nenalezení přesné délky se vrací zpět, dokud nenajde pravidlo které matchuje
- složitost - nezáleží na počtu pravidel!
- $o(w)$ - w nejdelší prefix, které mám
- optimalizace - vícebitová (multibit trie)
- n-ární strom, krok může být více bitů $k$ (stride)
- prefixy dané velikosti -> potřeba transformace
- menší prefixy rozšiřujeme podle dané délky bitů
- pokud rozšířený prefix obsahuje již dané pravidlo před rozšířením -> pravidlo z rozšíření vypustíme
- implementace pomocí pole
- LC-tries - Lulea Compressed Trie = komprese na 2 pole - maska a pointer/pravidlo
- Pro každou dimenzi strom trie -> duplicity -> exponeciální prostorová složitost
- odstranění duplicit -> menší prostorová složitost, ale větší časová!!
- optimalizace - použití ukazatele (switch pointers) - chceme se vyhnout zpětnému vyhledávání
- ukazatele si mohu předpočítat dopředu!
- snížení časové složitosti
- pro jednoduchou implementaci některých firewallů
- divide and conquer
- pro každou dimenzi se udělá bitový vektor a porovná se s daty z paketu a nakonec se to sloučí pomocí bitového ANDu
- bitové vektory jsou dlouhé podle toho kolik je pravidel
- bitový vektor - bitová maska podle výskytu daného čísla v daném pravidle
- bereme první vyhovující pravidlo
- pokud adresy - daná dimenze jako trie
010001 - bereme první jedničku zleva -> tedy druhé pravidlo
- množina n-tic
- rozdělíme na jednotlivé dimenze
- najdeme nejbližší match
- dáme dohromady
- uděláme hash z n-tice a dostaneme pravidlo
- rozdělení pravidel do podprostorů/regiony
- paket je bod v prostoru - ukazuje kam patří do regionu
- rozdělení pomocí řezů - cuts
- regiony jako uzly rozhodovacího stromu
- Paměť CAM (Context addressable memory)
- opak RAM paměti - znám content a chci adresu
- využití u CAM tabulky (znám MAC adresu, chci vědět port)
- paměť TCAM (Ternary Con) - rozšířená CAM (3 hodnoty)
- hodnoty 0, 1, X (dont care)
- hodnota X je pomocí bitové masky
- prefixy sestupně podle délky
- vyhledání v 1 cyklu
- nevyhody
- čím se liší od klasické
- decentralizované
- uzly maji stejnou funkci (plní funkci klienta i serveru)
- většinou aplikační protokoly (a tedy potřebují implementaci vrstev pod nimi)
- problém s adresací, nevíme koho se přesně zeptat na potřebná data
- Lokální informace jsou velmi efektivní ve vytvoření nejkratší cesty mezi 2 body (v soc. siti)
- Propojení mezi 2 jedinci lze najít pomocí malé posloupnosti známých
- každá p2p síť je proprietární! - jak hledá, adresuje, …
- žádný uzel nemá ponětí o celé síti
- problém s identitou - zvlášť pro správu sítě - pouze zakázat - ale jak vědět, že je to p2p komunikace
- overlay - propojení/rozložení sítě
- uniformní rozložení
- jinak by se zdroje rozložili na malé množství uzlů - nerovnoměrná zátěž
- používá se metrika blízkosti
- vždy se dozvíme jestli uzel je nebo není! rozdíl vs nestrukturované
d8 - encoding- jméno trackeru musíme někde získat, nejčastěji URL
- nelegální obsah
- zátěž sítě
- nevýhody přístupu
- použijeme vlastní porty
- zapouzdření přes jiný protokol
- šifrování
- problém se signatury
- šifrování
- omezená množina - po přidání nového nová množina
- kde najít daný řetězec - celý paket vs část, …
- typicky začátek hlavička aplikačního protokolu, zbytek uživatelské data
- není jednoduchá úloha - vyhledávání řetězců
- např. tabulka s 1000 signatur, každou hledám v paketu
- omezené na pouze viděné packety jako u signatur
- blíž nule a dál od prahové hodnoty = více důvěryhodné
- čím blíže prahové hodnotě, tím méně důvěryhodně
- Entropie = míra neočekávanosti, opak informační
- nemusí fungovat - více různých aplikací může mít stejné otisky
- dost závisí na tls knihovně
- verze aplikací - nová verze tls, verze knihoven
- problém - např u web prohlížeče nefunguje moc dobře - otisk je pouze pro daný web server, různé připojení jiný server
- dobré pro identifikace malware - rozšíří se a používá stejné nastavení/knihovny
- sítě v průmyslu - ideální - omezené, predikovatelné
- daný počet zařízení - přidání je náročné a je potřeba technik
- stanovené komunikace
- dlouho nezměněný standard, ale několika násobné zvětšení rychlostí
- rychlost ethernetu roste rychleji, jak rychlost cpu!
- cpu scaluje paralelně
-
malý packet = TCP ACK
-
https://stats.ams-ix.net/sflow/index.html
-
https://makelinux.github.io/kernel/map
-
snaha alokovat 1 a pak měnit pointery/upravovat podle potřeby, kvůli době přístupu/kopírování
- vypneme přerušení pomocí masky, abych mohl zpracovat packety
- packety zpracovávám dávkově
-> latence navíc
- packety do ring bufferu, jednou za čas se podívám a zpracuji
- navýší výkon
- procesor se ptá, jestli je nějaký nový paket - větší zatížení procesoru tímto dotazováním
- zlepší latenci pro specifickou část
- jednotlivé fronty na jednotlivé jádra
- problém s hashovací funkcí, aby rozdělil rovnoměrně
- problém například s tunelem
- až N-násobně zvýšení výkonu!
- General segmentation / receiver offload
- síťovka se postará na segmentaci na 1500 bytů
- v rámci jádra mohu pracovat s pakety v násobcích MTU
- problémy
- síťovka může špatně rozsekat
- zapouzdření - tunely
- v rámci 20%
- různé výpočetní funkce udělá NIC místo kernelu
- Checksum
- VLAN stripping
- v rámci 3-5%
- ze síťovky rovnou do aplikace (vynechá kernel)
- z 0.5 M paketů na jádro -> 10M paketů na jádro
- funguje pro
- sonda
- load balancer
- analýza
- routing - re-implementuje v aplikaci - nemusí být zrychlejí
- není vidět síťová karta - např. tcpdump
- extension Barkley Packet Filter
- BPF - např filter ve wiresharku
- JIT v
- síťovka před hned po přijetí packetu
- eBPF rozhoduje co s paketem
- zahodit
- zpracovat stackem
- poslat dál
- nezajímá nás propustnost b/s
- ale výkonnost = počet paketů /s (packet rate) (bere se průměr 500b velikost packetu)
- jumbo ?? - paket 9kb - pro úložiště - např VM
- nelze změnit, protože by staré ethernety nerozuměli
- data plane
- pokud čip si neumí s paketem poradit - fragmentace, neznámý option - pošle se do control plane
- jen 2 vrstvy
- leaf musí být schopen rozhodit provoz na všechny linky!
- pokud chceme přímo adresovat (L2 síť) - mnoho mac adres
- spanning tree protocol - počítáme že je vede 1 linka k cíli - zabila by ostatní linky
- TRILL - postavený nad IS-IS (chytřejší spanning tree nad L2 co vyřeší topologii)
- spine musí mít hodně portů vyšší kapacity
- folded 3-stage clos - když chceme leaf and spine pomocí vícero stejných zařízení
- komunikace mezi GPU kartami max 1 hop
- před alokujeme cesty
- má zlepšit propustnost
- kupujeme pouze hardware
- software můžeme použít jaký chceme
- automatizovaná konfigurace mnoha zařízení
- software defined networking
- umožňuje ovládání i pro ne technicky znalé uživatele
- southbound = propojení na samotné zařízení
- northbound api = pro aplikaci, která změní nastavení sítě
- switching
- firewall
- microflow routing
- virtualizace sítě
- problémy
- mohou se vyskytovat na více místech - vs jen na vpn
- nejsme schopni odbavovat terabity, ale to není problém pro většinu sítí - ale je v hpc :)
- problém s podporou zařízení
- obecnější jak openflow
- domain specific jazyk pro práci s pakety
- místo toho se používá XDP a eBPF