... tak switch to bude davat jen do urcite miry (soucet techto paralelnich toku se u switchu udava jako paramater "total non-blocking throughput") ale rika se tomu wirespeed. Je to dano tim ze se chip switche je na tuto cinnost vysopce optimalizovany, jen kouka do hlavicky ARP paketu a porovnava s CAM tabulkou, nic jineho nedela/neumi.
Opravdu nemístně si na okraj rejpnu: on L2 switch se učí adresy z jakéhokoli L2 paketu. Pravda je, že po připojení jednotlivého počítače (L3 zařízení) může být ARP dotaz jedním z prvních paketů, které ten switch na dotyčném portu uvidí. A pokud se ten počítač za jízdy nestěhuje v L2 topologii, tak se záznam v CAM tabulce už nikdy nezmění...
U všech switchů včetně levných SoHo modelů, pokud mají uvnitř jediný čip (tzn. cca do 8 portů) jsem zvyklý vídat udávaný switching bandwidth jako prostý součet jmenovitých rychlostí per port. Jasně je tam full duplex, ale osobně bych to x2 nenásobil, protože co jedním portem přiteče, jiným odteče a je to pořád tentýž traffic. Musel byste posílat krátké pakety (třeba pod 100B) aby to switch nestíhal forwardovat na L2 "at wire speed".
Na druhou stranu chip ktery umi byt jak router tak switch, nutne musi byt mene optimalizovany a vice variabilni, pripadne nektere cinnosti emuluje. Vezmete si ze jako router musi packety rozebirat na uroven L3, koukat do hlavicek IPv4 i IPv6, koukat do routing table, do firewall table, prepisovat hlavicky v pripade NATu, atp. To proste nikdy nemuze byt stejne efektivni jako v pripade prosteho switche.
Já bych především rozlišoval mezi L2 a L3.
L2 je v hardwaru a funguje v zásadě vždycky "at wire speed" - ovšem pozor na úzká hrdla vnitřní topologie u víceportových switchů.
L3 forwarding je cosi navíc, nadstavba. Pokud switch obsahuje nějaké L3 funkce, tak si troufám tvrdit, že to nijak neomezuje jeho průchodnost pro čistý L2 provoz. Pravda je, že tyhle pokročilé switche mívají o něco delší a hlavně méně deterministické průchozí latence, prostě protože toho zpracování je víc a taky vnitřní architektura pokročilých switchů (kaskáda sběrnic) bývá složitější.
Přestože Cisco svého času tvrdilo, že jsou softwarová firma, jejich proprietární uspořádání backplanů a akcelerátorů jsou jinačí liga než katalogové zapojení malých švábů od Marvellu s propojením přes SGMII. Pokud se správně pamatuju, když vezmete do ruky nějakou zásuvnou desku od Cisca, půlka velkých švábů na ní budou FPGA.
Někteří výrobci označují jako "L3 switch" i hardware, který má prostě jenom
interní VLAN trunk do management CPU a ten relativně neduživý procesor softwarově forwarduje traffic na L3 (každý paket vezme do ruky). Podle mého do této ligy patří Turris.
Provoz v rámci VLANy je switchovaný na L2 hardwarově, a tedy "at wire speed" (v rámci topologických možností). Provoz mezi VLANami musí skrz interní VLAN trunk do "hlavy členovce", kde se forwarduje na L3 rychlostí "kolik dá procesor" a jeho OS (zde Linux) - a zase trunkem zpátky do L2 hardwaru. Na nějaké offloady forwardovacích rozhodnutí do hardwaru se tu myslím moc nehraje.
Zrovna v Turrisu je L2 matice oddělená od L3 procesoru. Fakt je, že v levných SoHo krabičkách se tuším vyskytují švábi (Broadocom, Atheros) kde je switchovací matice (5 vnějších PHY portů + trunk), management CPU jádro (MIPS) a třeba i WiFi rádio pohromadě v jednom čipu (SoCu). Mám pocit že ani tady se žádný HW offload L3 forwardingu nekoná, a třeba WiFi provoz se musí softwarově bridgovat do metalického ethernetu i na L2, protože WiFi rádio má rozhraní PCI-e a další svérázné okrajové vlastnosti...
V Cisco názvosloví "Fast switching IP" je podle mého jakási cache v routeru (L3), stále ještě na softwarové straně, která urychluje per-packet routovací rozhodnutí - tím, že se neprochází sekvenčně řetězec pravidel, ale předžvýkaný binární strom (= rychlejší algoritmus). Nebo jestli už to mělo nějakou lehkou HW akceleraci... nevím.
První skutečný offload L3 forwardingu do L2 HW, o kterém vím, je Cisco MLS. Tuším nám to předváděli jako novinku někdy okolo přelomu století... Hardware switchovací matice je schopen sledovat L3 "toky" (flows, definované zdrojovou a cílovou L3 adresou, snad i zdrojovým a cílovým portem?), CPU dostane "k rozhodnutí o next hopu" pouze první paket vznikajícího "toku", hardware switche si toho rozhodnutí všimne, a další pakety už switchuje "at wire speed" podle nakešovaných next-hopů. Toto se dalo nakonfigurovat už na nějakém L2 catalystu s externě připojeným L3 routerem, ale velice rychle se to stalo základní vlastností další generace L3 switchů.
Tušímže další level byl CEF/dCEF (možná záležitost spíš čistých routerů než switchů?), a další bylo PXF, což byl už dost volně programovatelný "paralelní koprocesor"... ale to jsme pořád na začátku století - dávno jsem ztratil přehled, kam se vývoj ubíral dál. Už pomocí PXF toho Cisco "switche" uměly v hardwaru opravdu hodně, vedle forwardingu na L3 taky filtrovat snad až do L5, nevím jestli NATovat apod. Jenom jak už jsem řekl, čím víc věcí ten switch musí s každým paketem provést, a čím větší/složitější je vnitřní "signálová cesta", obvykle taky vnitřní strom sběrnic, a tím větší je jitter průchozí latence (mluví ze mně IEEE1588, kloužu off topic, takže končím).
@kurtn: není zač... :-)