classic.ISPforum.cz

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.

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.

Pri takejto architekture blbo. Pri pripajani zakaznikov cez PPPoE uplne trivialne, pouzitim viacerych PPPoE koncentratorov, klienti sa medzi nich rozlozia automaticky.

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.

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

Vsak shaper rozlozit muzes taky, staci vnitrni sit rozdelit a je to. Ohledne NATu, tak to taky neni velky problem prece

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

v tý kartě je cpu a nějakej *nix ..

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.

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 - flows jsou uloženy nejspíše v jednoduché TCAM), 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.

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ý?

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ý?

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

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.

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.

Prave proto asi vypada lepe napriklad starsi 1006tka s router 2 kartou....

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

Nemyslím si, že by výpočet checksum měl být ten hlavní žrout výkonu. Vždyť na tohle má offload každá trošku lepší síťová karta. Hlavní problém je vyhledávání v různých tabulkách, často s miliony záznamů. Proto např. na Mikrotiku/Linuxu velmi pomáhá, když se "firewall napíše dobře".

TTcko píše:to jo, ale tady se řeší NAT, ne routing...

Hardwarově-asistovaný NAT umí i kdejaký chipset od Broadcomu.

alestr píše:

TTcko píše:to jo, ale tady se řeší NAT, ne routing...

Hardwarově-asistovaný NAT umí i kdejaký chipset od Broadcomu.

hahaha, díky za info, a umí to v 10G rychlostech? a stovky tisíc NAT záznamů?

Neumí, ale gigabit v pár stovkách tcp/udp spojeních to dá levou zadní (samotné CPU by dávno hořelo). Velké routery to dělají podobně, jen ve větším (velikost/složitost/cena TCAM je ten zásadní rozdíl).