Most már többet értek. Alapvetően nem javaslom az eszközt erre, mivel nem erre tervezték (itt gondolok a DDoS esetekre is). Alternatív javaslat: DDoS-ra is felkészülve kell valami egyszerű első védelmi vonal ami a leggyorsabban képes szűrni IP forrás/cél alapján a bejövő csomagokat erre valamilyen switch/router ajánlott a bejövő interfészen ahol a switchportra telepíthető egyszerű IP szabály. Gondolom IP forrás/cél szűrésen kívül nem akarsz más szabályt használni DDoS esetén. Erre bejövő forgalom és persze elmaradt jövedelem alapján 7ezer-70millió forintig elérhető hw. Ekkora forgalomra akár még a 7e Ft-os is elég lehet, persze én nem terveznék vele szolgáltatási célra. Mivel írtad, alapvetően nem a DDoS védelem a cél, arra alkalmas lehet az az eszköz(CCR1036) sőt alap konfig alapján még a DDoS védelemre is képes lehet. Azaz vázolt esetet elvileg és gyakorlatilag is bírnia kell ennek a konfignak.
A vállalt performancia a gyártó részéről:
CCR1036-8G-2S+(ROS v6.x)
64byte kpps Mbps
Bridging(fp) 41636 27313.2
Bridging(filter 5817 3816.0
Routing (fp) 41636 27313.2
Routing (filter) 3081 2021.1
512byte kpps Mbps
Bridging(fp) 6574 27873.8
Bridging(filter 5630 23871.2
Routing (fp) 6574 27873.8
Routing (filter) 2796 11855.0
Az hogy 1500 byte-os csomagokat tudja mindenképp wirespeed-el azt most hagyjuk ki, minthogy az is látható hogy max 42M pps-t tud szűrés nélkül max.
A kiemelt két mérési eredmény alapján az is látható, hogy routingban kb a felét tudja a router.
Természetesen interfész queue-val még rontható a fenti statisztika, de ezt most hagyjuk.
Ahogy fent látható a legrosszabb konfig esetén 2800e pps jut az adott eszközre és ez 512byte csomagméret alapján jön létre, ami ha súlyozva elosztjuk (azaz nem csak 2 interfésszel számolunk) az 100e pps/port a 8 beépített és 1m pps a 2 SFP+ interfészen, összesen ~11Gbyte/s forgalommal ami ugye annyi hogy még a két SFP+ port esetén se lenne elég azaz nem tud wirespeed routingot a két SFP+ interfész között, ha IP routingot használnál, mivel azonban bridge konfigról lenne szó, az is látható, azt kb wirespeed-el tudja, azaz átlag alatti normál forgalom maximális terhelés esetén szűrést tudnál bridge szűréssel.
Alapvetően tehát ebben az esetben az a kérdés, az adott csomag eljut e a kernelig, és ha igen milyen bonyolult a feldolgozás, mennyi megszakítást generál. Azonban maga a gép, az igényelt konfigra alkalmas.
A fentiekből kiderül, hogy bőven alatta van az általad említett esemény az eszköz natív képességeinek. Itt gyakorlatilag a MT elemzést befejezném mert bőven túlmegyünk ezen a kereten ami ide elfér a többi olyan meló ami általában teljesen üzleti alapú és ha kell segítség megoldod olvasással, support requestel (bocs ennél azért felröhögtem, sajnos elég sok tapasztalatom van, de talán...), ha esetleg nem menne keress meg privátban...
Visszatérve, az MT ugyanazt a kernelt használja jó eséllyel amit te is használnál ?ubuntu? alatt.
Ezért igaz az is, hogy kb ugyanazokat az eredményeket kell kapnod ugyanolyan beállítások esetén. Én javaslom még egyszer nézd át amit fent linkeltem wikipédiás képet és az MT packet flow-ját. Nézd meg hol hibáztál, a monitoring, statisztikai lehetőségeket is célszerű lenne használni.
Valamint még egyszer kiemelném, hogy ethernet csomagot akarj szűrni, jóval olcsóbb a feldolgozás.