kdavid píše:
Prave proto chci zarizeni ktere to umi na urovni HW. Zadne CPU reseni.
to neexistuje .. všechno to je software, bohužel.
kdavid píše:
Prave proto chci zarizeni ktere to umi na urovni HW. Zadne CPU reseni.
DarkLogic píše:Jen rychlý dotaz, abych se neco priucil. Mam za to, ze shaping muzu delat na stroji, ktery je hranici mezi dvema rozhranimi. Typicky tedy hlavni GW, na ktere delam taky NAT. Jak rozdelite tyto dve funkce na dva stroje? Teda za predpokladu, ze chci shapovat vsechny zakazniky z jednoho mista.
TTcko píše:kdavid píše:
Prave proto chci zarizeni ktere to umi na urovni HW. Zadne CPU reseni.
to neexistuje .. všechno to je software, bohužel.
kdavid píše:
To mi je jasne Ale neni jedno zda je to CPU na nejakem RBcku, nebo ISIC od cisca na to urcenej. A jak koukam cisco ma pri routing a qos vlast karty takze se to rozklada. Jen ty prachy
TTcko píše:kdavid píše:
Prave proto chci zarizeni ktere to umi na urovni HW. Zadne CPU reseni.
to neexistuje .. všechno to je software, bohužel.
rsaf píše:Jak se to vezme. Jsou různé úrovně toho, jak speciálním hardwarem (tedy něčím co není Von Neumannova architektura) zvýšit výkon v networking úlohách. Občas je to nějaký chip, který funguje na základě "flow cache" (první packet jde přes CPU, další již přes vzniklou flow), u těch lepších (a drahých) boxů je to něco na bázi TCAM. Např. dříve zmíněný Catalyst 6500 dokáže routing i access-listy odbavit kompletně v TCAM na PFC (mj. je tomu úplně jedno, jestli je třeba v routovací tabulce 1000 nebo 100000 záznamů), rovněž zde zmíněná architektura ASR1k má QFP (quantum flow processor), který taky využívá TCAM.
TTcko píše:rsaf píše:Jak se to vezme. Jsou různé úrovně toho, jak speciálním hardwarem (tedy něčím co není Von Neumannova architektura) zvýšit výkon v networking úlohách. Občas je to nějaký chip, který funguje na základě "flow cache" (první packet jde přes CPU, další již přes vzniklou flow), u těch lepších (a drahých) boxů je to něco na bázi TCAM. Např. dříve zmíněný Catalyst 6500 dokáže routing i access-listy odbavit kompletně v TCAM na PFC (mj. je tomu úplně jedno, jestli je třeba v routovací tabulce 1000 nebo 100000 záznamů), rovněž zde zmíněná architektura ASR1k má QFP (quantum flow processor), který taky využívá TCAM.
to jo, ale tady se řeší NAT, ne routing...
edit: dost by mě překvapilo, když by někdo měl chip na NAT, ono to totiž je pořád jen "hack", ale možná se pletu. máš to prostudovaný?
rsaf píše:Jasně že i NAT se řeší v TCAM. Běžný CPU router (aka Mikrotik) má nějakou conntrack tabulku, každý paket se v ní musí dohledat což samozřejmě chvíli trvá, ale především to trvá různě dlouho podle počtu záznamů v tabulce a další zátěži na CPU... "Opravdový" router drží "conntrack" tabulku v TCAM => vyhledává v ní "na jeden šup" bez ohledu na to, kolik je v tabulce záznamů. Stejně to funguje s routingem/acl/firewallem/netflow... Druhá věc je, jak probíhá přidávání záznamů do tabulky. To je většinou za asistance CPU (v TCAM se zjistí, že ještě není potřebný záznam a že se má NATovat, vznik záznamu je pak ale většinou v režii CPU)
Např. ASR 1002-HX má v datasheetu napsáno:
● NAT: 6,000,000 sessions and 300,000 sessions-per-sec setup rate
● Carrier-Grade NAT: 12,000,000 sessions
tedy 6mil záznamů a 300k nových každou sekundu. Po přepnutí do CGN režimu tam vleze až 12mil záznamů (vypnou se pro ISP zbytečné feature jako portforwarding zvenčí dovnitř, čímž se výrazně sníží složitost záznamů a tak se toho do TCAM vleze víc).
Určitá nevýhoda je ovšem v tom, že pokud má tabulka napsáno třeba 2mil záznamů (ASR 1001-X), není možné tohle překročit.
kdavid píše:Nooo pri ipv4 nat zere nejvetsi vykon propocitavani crc co dela cpu. Zminene cisco ma pri router card 2 jen dualcore 2,2 ghz cpu pricen je deklarovany vykon pro nat 100gb/s. Kromne toho psal jeden na cisco foru ze pri cca 20gig natocani mnel cpu na 5% takze asi to maji fakt zmaknute vramci qfp
TTcko píše:to jo, ale tady se řeší NAT, ne routing...
alestr píše:TTcko píše:to jo, ale tady se řeší NAT, ne routing...
Hardwarově-asistovaný NAT umí i kdejaký chipset od Broadcomu.