--- title: RFC 2889. LAN կոմուտատորների թեստավորման մեթոդաբանություն | TEST4NET description: "RFC 2889. LAN կոմուտատորների թեստավորման մեթոդաբանություն | TEST4NET\n- Meta description: RFC 2889 CloudLAB-ում՝ full-mesh զրո կորուստով throughput բոլոր պորտերում, 30-վայրկյանանոց փորձեր, head-of-line blocking, MAC աղյուսակի տարողություն և ուսուցման արագություն, վնասված կադրեր, broadcast։ Թեստ-պլան և հաշվետվություն։" --- [Skip to content](https://test4net.com/hy/methodologies/rfc-2889#main-content) [![TEST4NET](https://test4net.com/hubfs/test4net-logo-fixed-2.svg)](https://test4net.com/?hsLang=hy) - Services - Products - Resources - Company - [Հայերեն](https://test4net.com/hy/methodologies/rfc-2889) - [English](https://test4net.com/methodologies/rfc-2889) - [Русский](https://test4net.com/ru/methodologies/rfc-2889) [Նորություններ](https://test4net.com/hy/news?hsLang=hy) [Login](https://lab.test4net.com) [Support](https://test4net.com/support?hsLang=hy) - [Հայերեն](https://test4net.com/hy/methodologies/rfc-2889) - [English](https://test4net.com/methodologies/rfc-2889) - [Русский](https://test4net.com/ru/methodologies/rfc-2889) What we test By technology Industries [Load & Performance Testing Throughput, sessions and latency up to and past the rated limit](https://test4net.com/services/load-performance-testing?hsLang=hy) [Functional & Conformance Testing Features against the spec, RFC compliance with evidence](https://test4net.com/services#functional) [Interoperability Testing Multi-vendor behaviour, before it reaches production](https://test4net.com/services#interop) [Security & Resilience Testing NGFW, IPS and VPN efficacy and performance with threats on the wire](https://test4net.com/services#security) [Test Plan & Methodology Design What to test, how, and what counts as a pass](https://test4net.com/services#test-plan) [Test Automation & CI/CD Regression suites wired into your release pipeline](https://test4net.com/services#automation) [Training Programs Hands-on courses for your test engineers](https://test4net.com/services#training) [Equipment Repair Diagnostics and repair of test equipment](https://test4net.com/services#repair) [All services](https://test4net.com/services?hsLang=hy) Routing & Switching RFC 2544 and RFC 2889 on real ports, 1G to 100G Firewalls & NGFW RFC 9411 throughput with inspection switched on SD-WAN & WAN Path selection and QoS under emulated WAN conditions Cloud & NFV Virtual appliances and cloud services under load 5G & Mobile Core Transport and core functions under subscriber traffic Wi-Fi Wi-Fi 6 clients and access points, Wi-Fi 7 in progress Storage & Infrastructure Storage networks and servers under realistic I/O AI / Switching Fabric (RoCEv2) Lossless Ethernet for GPU clusters: PFC, ECN, fabric load All technologies Telecom Operators Pre-deployment acceptance and vendor comparison Network & Security Vendors Independent validation of your product claims System Integrators Proof for the customer before the rollout Enterprise & Banks Upgrades and new platforms checked before production All industries Not sure where to start? Test plan and quote in 1–3 business days Tell us what you run and what worries you. We propose the tests, tools and timeline. [Request a test plan](https://test4net.com/contacts?hsLang=hy) CloudLAB How It Works Pick a scenario, run it in the live lab, get the report Equipment & Capabilities L2-3 to 100G, L4-7 past 200G, Wi-Fi, WAN emulation Access Plans Hourly sessions, subscriptions, dedicated racks Hosted DUT Testing Ship the box or upload the VM, we run the tests [Open the CloudLAB portal](https://lab.test4net.com) Our tools Traffic Generator L4-7 and security traffic past 200 Gbit/s, app mix library WANemu Delay, jitter, loss and bandwidth shaping per link [Book a demo](https://test4net.com/contacts?hsLang=hy) New: our own test tools Our own tools, in beta this autumn Built in our lab, priced per gigabit. Join the beta list and see them first. [Join the beta list](https://test4net.com/contacts?hsLang=hy) Read Technologies / Protocols Methodologies [Blog Case studies, test insights and lab notes](https://test4net.com/blog?hsLang=hy) [Industry News What is changing in network testing and infrastructure](https://test4net.com/news?hsLang=hy) FAQ How the lab, sessions and reports work BGP Route exchange, policy and convergence OSPF & IS-IS IGP adjacency, flooding and SPF timing MPLS & Segment Routing LDP, RSVP-TE and SR-MPLS label paths EVPN / VXLAN Overlay fabrics, MAC/IP routes, multi-homing IPsec & IKEv2 Tunnel setup, rekeying and throughput TLS / HTTPS Handshakes, cipher suites and inspection RoCEv2 Lossless Ethernet, PFC and ECN for AI fabrics Wi-Fi 6 / 6E / 7 802.11ax/be, OFDMA, MLO and roaming All protocols [RFC 2544 Throughput, latency, frame loss and back-to-back](https://test4net.com/methodologies/rfc-2544?hsLang=hy) [RFC 2889 LAN switch benchmarking: forwarding, MAC learning, congestion](https://test4net.com/methodologies/rfc-2889?hsLang=hy) [RFC 9411 / RFC 3511 Firewall and NGFW performance benchmarking](https://test4net.com/methodologies/rfc-9411-rfc-3511?hsLang=hy) RFC 6349 TCP throughput and buffer delay testing RFC 5180 IPv6 benchmarking methodology ITU-T Y.1564 Ethernet service activation: CIR, EIR, KPIs per service ITU-T Y.1731 Ethernet OAM: delay, jitter, loss and SLA monitoring TR-398 Wi-Fi in-premises performance test plan All methodologies Read [Case studies, test insights and lab notes Blog](https://test4net.com/blog?hsLang=hy) [What is changing in network testing and infrastructure Industry News](https://test4net.com/news?hsLang=hy) How the lab, sessions and reports work FAQ [About Us Independent lab in Armenia, team and history](https://test4net.com/about?hsLang=hy) [Why TEST4NET What you get that vendor slides never show](https://test4net.com/why-test4net?hsLang=hy) Lab & Certifications Bench capacity, methods and the standards we test against Partners Test tool vendors and IT partners we work with [Contacts Talk to an engineer, not a sales bot](https://test4net.com/contacts?hsLang=hy) [Support portal](https://test4net.com/support?hsLang=hy) - Services What we test [Load & Performance Testing](https://test4net.com/services/load-performance-testing?hsLang=hy) [Functional & Conformance Testing](https://test4net.com/services#functional) [Interoperability Testing](https://test4net.com/services#interop) [Security & Resilience Testing](https://test4net.com/services#security) [Test Plan & Methodology Design](https://test4net.com/services#test-plan) [Test Automation & CI/CD](https://test4net.com/services#automation) [Training Programs](https://test4net.com/services#training) [Equipment Repair](https://test4net.com/services#repair) [All services](https://test4net.com/services?hsLang=hy) By technology Routing & Switching Firewalls & NGFW SD-WAN & WAN Cloud & NFV 5G & Mobile Core Wi-Fi Storage & Infrastructure AI / Switching Fabric (RoCEv2) All technologies Industries Telecom Operators Network & Security Vendors System Integrators Enterprise & Banks All industries [Not sure where to start? Test plan and quote in 1–3 business days](https://test4net.com/contacts?hsLang=hy) - Products CloudLAB How It Works Equipment & Capabilities Access Plans Hosted DUT Testing [Open the CloudLAB portal](https://lab.test4net.com) Our tools Traffic Generator WANemu [Book a demo](https://test4net.com/contacts?hsLang=hy) [New: our own test tools Our own tools, in beta this autumn](https://test4net.com/contacts?hsLang=hy) - Resources Read [Blog](https://test4net.com/blog?hsLang=hy) [Industry News](https://test4net.com/news?hsLang=hy) FAQ Technologies / Protocols BGP OSPF & IS-IS MPLS & Segment Routing EVPN / VXLAN IPsec & IKEv2 TLS / HTTPS RoCEv2 Wi-Fi 6 / 6E / 7 All protocols Methodologies [RFC 2544](https://test4net.com/methodologies/rfc-2544?hsLang=hy) [RFC 2889](https://test4net.com/methodologies/rfc-2889?hsLang=hy) [RFC 9411 / RFC 3511](https://test4net.com/methodologies/rfc-9411-rfc-3511?hsLang=hy) RFC 6349 RFC 5180 ITU-T Y.1564 ITU-T Y.1731 TR-398 All methodologies Read [Blog Case studies, test insights and lab notes](https://test4net.com/blog?hsLang=hy) [Industry News What is changing in network testing and infrastructure](https://test4net.com/news?hsLang=hy) FAQ How the lab, sessions and reports work - Company [About Us](https://test4net.com/about?hsLang=hy) [Why TEST4NET](https://test4net.com/why-test4net?hsLang=hy) Lab & Certifications Partners [Contacts](https://test4net.com/contacts?hsLang=hy) [Նորություններ](https://test4net.com/hy/news?hsLang=hy) [Login](https://lab.test4net.com) [Support](https://test4net.com/support?hsLang=hy) Մեթոդաբանություն · LAN կոմուտատորների բենչմարք # RFC 2889. կոմուտատորի թեստ, որտեղ յուրաքանչյուր պորտ խոսում է յուրաքանչյուրի հետ RFC 2544-ը չափում է պորտերի մեկ զույգ։ RFC 2889-ը բեռնում է ամբողջ կոմուտատորը՝ full mesh տրաֆիկ N պորտի վրա, դիտավորյալ գերբեռնվածություն, MAC աղյուսակ՝ լցված մինչև flood։ 10 թեստ, 30-վայրկյանանոց փորձեր, forwarding rate՝ հաշվետվությունում տեսական գծի կողքին։ Այս էջում մեթոդն այնպես, ինչպես մենք այն վարում ենք CloudLAB-ում, և այն, ինչ պարունակում է հաշվետվությունը։ - Full mesh. յուրաքանչյուր պորտ ուղարկում է բոլոր մյուսներին հերթով, այնպես որ բեռը կրում է ամբողջ fabric-ը միանգամից - 4 պորտից բաղկացած գերբեռնվածության բլոկը ցույց է տալիս head-of-line blocking-ը և backpressure-ը մեկ 30 վ փորձով - 10 թեստ. տրաֆիկի 4 ցանց, գերբեռնվածություն, forward pressure, հասցեների աղյուսակի տարողություն, ուսուցման արագություն, վնասված կադրեր, broadcast [Ստանալ RFC 2889 թեստ-պլան](https://test4net.com/hy/methodologies/rfc-2889#lead-form) [Դեպի 10 թեստերը](https://test4net.com/hy/methodologies/rfc-2889#tests) ZERO-LOSS THROUGHPUT % OF LINE RATE PER PORT · RFC 2889 §5.1 PORT PAIR · RFC 2544 24-PORT FULL MESH · RFC 2889 LINE RATE · 100% 50% 71% 86% 96% 100% 100% 100% 100% FABRIC-BOUND: BUFFER + 24 LOOKUPS PER SLOT 64 B 128 B 256 B 512 B 1024 B 1280 B 1518 B Every port to every port, or the claim is untested Տիպիկ արդյունք 24 պորտի վրա։ Պորտերի զույգում կոմուտատորը պահում է line rate-ը ցանկացած չափի վրա։ Full mesh-ում 64 բայթի դեպքում fabric-ը և ընդհանուր բուֆերը սպասարկում են 24 lookup մեկ սլոթում, և թիվն ընկնում է մինչև 71%։ Datasheet-ում տպված է առաջին գրաֆիկը։ Որտեղ է կիրառվում ## Կոմուտատորը վաճառում են fabric-ի համար, ուրեմն թեստավորել պետք է fabric-ը RFC 2889-ը RFC 2544-ը տարածում է LAN կոմուտատորների վրա. նույն կադրի չափերը, թեստի նույն ձևանմուշը, բայց տրաֆիկն անցնում է բոլոր պորտերով միանգամից, իսկ թեստերի ցանկն ընդգրկում է այն, ինչ կոմուտատորն անում է փոխանցումից բացի՝ սովորում է հասցեներ, դիմանում գերբեռնվածությանը, դեն է նետում վնասված կադրերը և բազմապատկում broadcast-ը։ ### ToR և կամպուսի կոմուտատորներ Ցանկացած սարք, որը կոմուտացիա է անում MAC մակարդակում. 48×25 GbE leaf, 100 GbE spine, կամպուսի մուտքի stack, պահոցային ցանցի կոմուտատոր։ Full mesh և many-to-one. հենց այս տրաֆիկի սխեմաներն են վարում դրանց գնորդները։ ### «Non-blocking» և «wire speed» հայտարարություններ Երկուսն էլ գալիս են պորտերի զույգից կամ ASIC-ի datasheet-ից։ 24 պորտի ցանցը 64 բայթի դեպքում ստուգում է կոմուտացիայի մատրիցը, բուֆերը և lookup շարժիչը միասին, և այդ խոսքերը հաստատելու այլ եղանակ չկա։ ### Երթուղիչներն ու firewall-ները գնում են այլ RFC-ներ L3 փոխանցումը RFC 2544-ի և RFC 5180-ի տիրույթն է, firewall-ներն ու NGFW-ն՝ RFC 9411-ի։ RFC 2889-ը ճիշտ գործիքն է այնտեղ, որտեղ արդյունքը որոշում են MAC-ի ուսուցումը, VLAN-ները և գերբեռնվածությունը։ Թեստային ստենդ ## Թեստերի N պորտ, մեկ ժամացույց, մեկ կոմուտատոր Թեստավորվող DUT-ի յուրաքանչյուր պորտի հետևում թեստերի պորտ է։ Բոլորին տակտավորում է մեկ սարք, ուստի բոլոր պորտերը մեկնարկում են 300 մվ-ի սահմաններում, յուրաքանչյուր կադր կրում է ստորագրություն և ժամանիշ, իսկ flood-ի հաշվիչը վերցվում է յուրաքանչյուր պորտից, այդ թվում նրանցից, որոնք պետք է լռեին։ HARDWARE TESTER · PORTS 1 … N/2 TX + RX ON EVERY PORT · ONE CLOCK FRAME STREAM, PER PORT 64 · 128 · 256 · 512 · 1024 · 1280 · 1518 B 1 to 256 MAC addresses per port Round robin to all other ports, fixed order Signature field + timestamp in every frame ALL PORTS START WITHIN 300 ms N/2 PORTS BIDIRECTIONAL DUT · LAN SWITCH ONE FABRIC · ONE MAC TABLE · N PORTS STORE & FORWARD CUT-THROUGH 802.1Q · VLAN FLOW CONTROL AGING TIME AS AGREED STP · LLDP · SNMP OFF OR FILTERED N/2 PORTS COUNTED · TIMED HARDWARE TESTER · PORTS N/2+1 … N RX + TX · SAME INSTRUMENT, SAME CLOCK PER-PORT COUNTING Received: right port + right signature Flood count: frames on the wrong port DUT's own frames (STP, LLDP) excluded Timestamp delta: latency, every frame RECEIVED ≠ FLOODED ≠ MISFORWARDED LEARNING FIRST, VERIFIED a learning frame per address at 50 fps, one verification frame each, zero floods required · aging time \> learning + 30 s trial + setup ### Ապարատային թեստեր, 8-ից 48 պորտ 1, 10, 25, 100 և 400 GbE պորտեր մեկ շասսիում։ Յուրաքանչյուր պորտ ունի իր MAC հասցեները՝ 1-ից 256, և ուղարկում է բոլոր մյուս պորտերին հերթով, ինչպես պահանջում է §5.1.3-ը։ Ծրագրային գեներատորները չեն կարողանում 48 պորտ 64 բայթի վրա պահել միմյանցից 1%-ի սահմաններում, ուստի այս RFC-ի համար մենք դրանք չենք օգտագործում։ ### Կոմուտատորն այնպես, ինչպես այն կտեղադրվի ցանցում Արտադրական կոնֆիգուրացիա. VLAN-ներ, STP ռեժիմ, flow control, aging time, QoS, port security։ Այս ամենն արտահանվում է հաշվետվություն։ Արձանագրությունները, որոնք կոմուտատորն ինքն է ուղարկում (STP, LLDP, SNMP), անջատված են կամ հանված հաշվիչներից, ինչպես խորհուրդ է տալիս §5.7-ը։ ### Ցանցային տրաֆիկ ստորագրությամբ Կադրի չափեր 64-ից 1518 բայթ, 802.1Q պիտակավորված կադրեր մինչև 1522, եթե կոմուտատորն ընդունում է դրանք, ստորագրության դաշտ 56-րդ բայթից հետո յուրաքանչյուր կադրում։ «Ընդունված» նշանակում է ճիշտ նշանակման պորտ և ճիշտ ստորագրություն։ Մնացած ամեն ինչ flood է կամ սխալ փոխանցում և հաշվվում է որպես այդպիսին։ ### Նախ ուսուցում, և ստուգված Յուրաքանչյուր փորձից առաջ թեստերն ուղարկում է ուսուցման կադր յուրաքանչյուր հասցեի համար՝ վայրկյանում 50 կադր կամ ավելի դանդաղ, եթե կոմուտատորին այդպես է պետք, հետո ստուգում է, որ ոչինչ flood չի անում։ Կոմուտատորի aging time-ը դրվում է ավելի երկար, քան ուսուցումը գումարած փորձը գումարած նախապատրաստումը, այլապես հասցեները կսպառվեն փորձի կեսին, և արդյունքը forwarding rate-ի փոխարեն flood-ի հաշվիչ կլինի։ Թեստի պայմաններ ## 8 պարամետր, որոնք RFC-ն խնդրում է ամրագրել առաջին կադրից առաջ RFC 2889-ը կադրի չափեր չի ավելացնում, այն ավելացնում է տրաֆիկի ձև։ Ստորև բերված յուրաքանչյուր արժեք մտնում է թեստ-պլան և հաշվետվություն, որովհետև դրանցից որևէ մեկի փոփոխությունը փոխում է թիվը։ | Պարամետր | RFC 2889 արժեք | Միջակայք | Ինչի վրա է ազդում | | --- | --- | --- | --- | | Կադրի չափ | 64, 128, 256, 512, 1024, 1280, 1518 Բ | պիտակավորված մինչև 1522 Բ; jumbo՝ համաձայնությամբ | Lookup վայրկյանում. 64 Բ-ը 14,88 միլիոն է 10 GbE պորտի վրա | | Միջկադրային միջակայք | 96 բիթ, միջավայրի նվազագույնը | 88 բիթ միայն forward pressure թեստում | 96 բիթից ցածր առաջարկվող բեռը գերազանցում է MOL-ը 1 բայթով մեկ կադրի հաշվով | | Intended load (ILoad) | MOL-ի %-ը մեկ պորտի համար | որոնում 100%-ից ներքև | Full mesh-ը 100%-ով N պորտի վրա ոչինչ չի գերբաժանորդագրում; many-to-one-ը անում է դա դիտավորյալ | | Փնջի չափ | 1 կադր (հաստատուն բեռ) | 1-ից 930 կադր | Փնջերը հարվածում են բուֆերին, հաստատուն բեռը՝ lookup շարժիչին | | Հասցեներ մեկ պորտի վրա | 1 | 1, 2, 4 … 256 (երկուսի աստիճաններ) | Ավելի շատ հասցե, ավելի շատ lookup մեկ կադրի համար, պատահական աղբյուր-նշանակում զույգեր | | Փորձի տևողություն | 30 վ | 1-ից 300 վ | Բավական կարճ 10 թեստ × 7 չափի համար, բավական երկար՝ բուֆերները լցնելու համար | | Ուսուցման արագություն | 50 կադր/վ կամ ցածր | կախված կոմուտատորից | Չափից արագ, և աղյուսակը բաց է թողնում գրառումներ; յուրաքանչյուր բացթողում դառնում է flood | | Aging time | ավելի երկար, քան ուսուցում + փորձ + նախապատրաստում | կախված կոմուտատորից | Փորձի կեսին սպառված հասցեները փոխանցումը վերածում են flood-ի | RFC 2544-ը փորձը վարում է 60 վայրկյան; RFC 2889-ը խորհուրդ է տալիս 30, որովհետև 10 թեստ 7 կադրի չափի և տրաֆիկի մի քանի սխեմայի վրա այլապես օրեր կխլեր։ Եթե տենդերը ցանցային throughput-ի համար պահանջում է 60 վ փորձեր, մենք վարում ենք 60 և նշում ենք դա հաշվետվությունում։ ### Միշտ մեր փորձարկումներում - Learning verified before every trial (§3) - Signature field per port (§4) - Round-robin destinations, fixed order (§5.1.3) - All ports start within 300 ms (§5.1.3) - Flood count on every port (§5.1.4) - Loopback pre-test of the bed Ուսուցումը ստուգված, ստորագրություն յուրաքանչյուր պորտի համար, նշանակման հասցեներ հերթով և անփոփոխ գերբեռնվածության տակ, flood-ի հաշվիչներ ամենուր։ Սա այն է, ինչ RFC-ում նշված է որպես MUST, և այն, ինչ forwarding rate-ը տարբերում է ենթադրությունից։ ### Նախագծում համաձայնեցվող - 2 to 256 addresses per port (§5.1.2) - Burst sizes 1 to 930 frames (§5.1.2) - Half-duplex legacy ports (§5.1.2) - Tagged frames to 1522 B (§4) - Two switches over one uplink (§5.3) - Jumbo frames to 9216 B Այս կետերից յուրաքանչյուրը շարժում է թիվը։ 256 հասցե մեկ պորտի վրա full mesh-ում. RFC-ում նկարագրված ամենածանր դեպքը, և հենց այն ենք խորհուրդ տալիս leaf կոմուտատորի համար; 930 կադրանոց փնջեր. այսպես է պահոցային ցանցը երևում կոմուտատորին։ 10 թեստերը ## Ինչ է չափում RFC 2889-ը, բաժին առ բաժին Յուրաքանչյուր թեստ վարվում է կադրի յուրաքանչյուր չափի վրա։ Առաջին 4-ը բեռնում են fabric-ը տրաֆիկի տարբեր ձևերով; 5.5-ը և 5.6-ը սադրում են այն; 5.7-ը և 5.8-ը չափում են MAC աղյուսակը; 5.9-ը և 5.10-ը ստուգում են, թե ինչ է կոմուտատորն անում այն կադրերի հետ, որոնք պետք է դեն նետի, և նրանց հետ, որոնք պարտավոր է բազմապատկել։ 1. 5.1Ցանցային տրաֆիկ ### Full mesh. throughput, կադրերի կորուստ և forwarding rate Յուրաքանչյուր պորտ ուղարկում է յուրաքանչյուր մյուսին հերթով նույն intended load-ով։ Որոնումը գտնում է throughput-ը՝ ամենաբարձր բեռը բոլոր պորտերի վրա զրո կորստով։ Forwarding rate-ը գրանցվում է նաև առաջարկվող առավելագույն բեռի դեպքում (FRMOL) և գագաթնակետում (MFR), որովհետև կոմուտատորը, որը 100%-ի դեպքում կորցնում է 2%, կարող է դեռ ավելի շատ կադր փոխանցել, քան 95%-ի դեպքում։ Արդյունք. throughput, FR, FRMOL և MFR կադրի յուրաքանչյուր չափի համար, գրաֆիկում տեսական գծի կողքին 2. 5.2Ցանցային տրաֆիկ ### Մասնակի ցանց one-to-many և many-to-one Մեկ պորտն ուղարկում է N պորտի, հետո N պորտ ուղարկում են մեկին։ Երկրորդ կեսը պահոցի և պահուստավորման սխեման է. N աղբյուր մեկ պորտի մեջ, բնությամբ փնջային։ Փնջի չափը և ILoad-ը դրվում են այնպես, որ գումարը մնա ընդունող պորտից ցածր, կամ նրանից բարձր, երբ գնորդն ուզում է չափել բուֆերը։ Արդյունք. throughput և կադրերի կորուստ ըստ ուղղությունների և կադրի չափերի, փնջի չափը նշված 3. 5.3Ցանցային տրաֆիկ ### Մասնակի ցանց. երկու կոմուտատոր մեկ uplink-ով Երկու DUT բազմաթիվ մուտքի պորտերով և մեկ uplink-ով նրանց միջև, տրաֆիկ մի կոմուտատորի պորտերից մյուսի պորտերին։ Uplink-ը նեղ տեղն է ըստ մտահղացման; թեստը ցույց է տալիս, թե արդյոք կոմուտատորները այն արդարացիորեն են կիսում և որքան են կորցնում, երբ մուտքի տրաֆիկը գերազանցում է այն։ Արդյունք. throughput, կադրերի կորուստ և forwarding rate uplink-ով, կադրի յուրաքանչյուր չափի համար 4. 5.4Ցանցային տրաֆիկ ### Մասնակի ցանց միակողմանի տրաֆիկով Պորտերի կեսը փոխանցում է, մյուս կեսը միայն ընդունում, բոլոր հոսքերը մեկ ուղղությամբ։ Սա ռեպլիկացիայի կամ հայելայնացման սխեման է և ամենահեշտը կոմուտատորի համար, այնպես որ այստեղ կորուստը նշանակում է կորուստ ամենուր։ Այն նաև առանձնացնում է փոխանցման ուղին ընդունման ուղուց նույն պորտի վրա։ Արդյունք. throughput և forwarding rate կադրի յուրաքանչյուր չափի համար; սովորաբար լավագույն թիվը, որը ստանում է կոմուտատորը 5. 5.5Գերբեռնվածություն ### Գերբեռնվածության կառավարում. head-of-line blocking և backpressure 4 պորտից բաղկացած բլոկ։ A աղբյուրն ուղարկում է 100%-ով՝ հերթափոխելով չգերբեռնված և գերբեռնված ընդունիչները; B աղբյուրն ուղարկում է 100% գերբեռնվածին։ Չգերբեռնված պորտը պետք է ստանա յուրաքանչյուր կադր. այնտեղ կորուստը head-of-line blocking է։ Գերբեռնված պորտը ստանում է 150% և պետք է կորցնի 33%. այնտեղ զրո կորուստը նշանակում է, որ կոմուտատորը կիրառել է backpressure (flow control) և դանդաղեցրել աղբյուրները։ Արդյունք. կադրերի կորուստ չգերբեռնված և գերբեռնված պորտի վրա; վճիռ. HOLB կա թե ոչ, backpressure կա թե ոչ 6. 5.6Գերբեռնվածություն ### Forward pressure և առավելագույն forwarding rate Երկու մաս։ Forwarding rate-ը չափվում է, մինչ intended load-ը քայլերով բարձրանում է throughput-ից մինչև MOL; ամենաբարձր արժեքը MFR-ն է։ Հետո կադրերն ուղարկվում են 96-ի փոխարեն 88 բիթ միջակայքով՝ գերբեռնելով մուտքը 1 բայթով մեկ կադրի հաշվով։ Ելքում MOL-ից բարձր forwarding rate-ը նշանակում է, որ կոմուտատորը փոխանցում է անթույլատրելի միջակայքով. forward pressure հայտնաբերված է։ Արդյունք. MFR՝ ILoad-ի նշումով; FR 88 բիթ միջակայքի դեպքում; «Forward pressure detected», երբ FR-ը գերազանցում է MOL-ը 7. 5.7Հասցեների աղյուսակ ### Հասցեների աղյուսակի տարողություն 3 պորտ. ուսուցման, թեստային և վերահսկման։ Ուսուցման պորտն առաջարկում է N աղբյուրի հասցե, հետո թեստային պորտն ուղարկում է N կադր հետ՝ դրանց։ Եթե վերահսկման պորտը տեսնում է որևէ կադր, կամ ուսուցման պորտն ավելի քիչ է ստանում, քան ուղարկվել է, աղյուսակը N-ի դեպքում լիքն էր։ Երկուական որոնումը 0-ի և վաճառողի առավելագույնի միջև, իտերացիաների միջև aging-ի լրիվ դադարով, ավարտվում է իրական տարողության վրա։ Արդյունք. հասցեներ մեկ պորտի վրա, յուրաքանչյուր իտերացիայի flood-ի հաշվիչով բոլոր 3 պորտերի վրա 8. 5.8Հասցեների աղյուսակ ### Հասցեների ուսուցման արագություն Նույն 3-պորտանի սխեման, հասցեների քանակն ամրագրված է 5.7-ում գտնված տարողության վրա, փոխվում է ուսուցման կադրերի արագությունը։ Ամենաբարձր արագությունը, որի դեպքում յուրաքանչյուր հասցե սովորված է, վերահսկման պորտի վրա զրո flood-ով, ուսուցման արագությունն է։ Այն որոշում է, թե որքան երկար է կոմուտատորը կույր մնում տոպոլոգիայի փոփոխությունից կամ ՎՄ-ների միգրացիայի ալիքից հետո։ Արդյունք. ուսուցման կադրեր վայրկյանում 0 flood-ով; աղյուսակ՝ արագություն, առաջարկված, փոխանցված, flood 9. 5.9Ամբողջականություն ### Վնասված կադրերի զտում 5 տեսակի կադր կոմուտատորով. oversize (1518 Բ-ից մեծ), undersize (64 Բ-ից փոքր), CRC սխալ, dribble bits և հավասարեցման սխալ։ Undersize-ը, CRC-ն և հավասարեցման սխալը չպետք է դուրս գան մյուս կողմից; oversize-ը չպետք է, եթե միայն չեն աջակցվում պիտակավորված կադրեր մինչև 1522 Բ; dribble bits-ը պետք է ուղղվեն, իսկ կադրը փոխանցվի։ Pass կամ fail յուրաքանչյուրի համար, հաշվիչները պահվում են արձանագրության համար։ Արդյունք. pass / fail × 5, կադրերի հաշվիչները կցված; cut-through կոմուտատորը սովորական թեկնածուն է CRC-ով fail-ի 10. 5.10Ամբողջականություն ### Broadcast-ի փոխանցում և ուշացում Մեկ պորտն ուղարկում է broadcast կադրեր տրված բեռով; յուրաքանչյուր մյուս պորտ չափում է forwarding rate-ը և կորուստը։ Հետո ուղարկվում է մեկ broadcast կադր, և չափվում է ուշացումը մինչև յուրաքանչյուր ընդունող պորտ։ Broadcast-ի բազմապատկումը ASIC-ում առանձին գործառույթ է, և 48-ից 1 պորտը, որը կադրը ստանում է 40 մկվ ուշ, հենց այն է, ինչի համար այս թեստն է։ Արդյունք. broadcast-ի forwarding rate և կորուստ կադրի յուրաքանչյուր չափի համար; ուշացում յուրաքանչյուր ընդունող պորտի համար Ընթացակարգ ## Ինչպես է անցնում փորձարկումը. դատարկ ստենդից մինչև ստորագրված հաշվետվություն 5 փուլ։ Ցանցային թեստերը խլում են լաբորատոր ժամանակի մեծ մասը; գերբեռնվածության բլոկը և հասցեների թեստերը՝ ինժեներական աշխատանքի մեծ մասը։ 1. 00 ### Ստենդն առանց DUT-ի Թեստերի պորտերը փակված են նույն մալուխներով, օպտիկայով և վահանակով։ Full mesh-ը 64 բայթի վրա պետք է վերադարձնի 100% զրո կորուստով և զրո flood-ով, այլապես նախ ուղղվում է ստենդը։ 2. 01 ### Ուսուցում, հետո ապացույց Aging time-ը կարդացված է կոմուտատորից և դրված ուսուցում + 30 վ + նախապատրաստումից բարձր։ Ուսուցման կադրեր յուրաքանչյուր հասցեի համար 50 կադր/վ-ով։ Ստուգման կադր յուրաքանչյուր հասցեի համար; ցանկացած flood, և ուսուցումը կրկնվում է ավելի դանդաղ։ 3. 02 ### Ցանցային փորձեր Full mesh, one-to-many, many-to-one, միակողմանի։ Throughput-ի երկուական որոնում կադրի յուրաքանչյուր չափի համար, հետո FR MOL-ի դեպքում և MFR-ի անցում։ 30 վ փորձեր, բոլոր պորտերը մեկնարկել են 300 մվ-ի սահմաններում։ 4. 03 ### Գերբեռնվածություն և ճնշում 4-պորտանի բլոկը HOLB-ի և backpressure-ի համար կադրի յուրաքանչյուր չափի վրա, հետո 88 բիթ միջակայքով փորձը։ Հաշվիչները կարդացվում են կոմուտատորից յուրաքանչյուր փորձից հետո և համեմատվում թեստերի հետ։ 5. 04 ### Աղյուսակ, զտիչներ, broadcast Հասցեների տարողության երկուական որոնում՝ յուրաքանչյուր իտերացիայում aging-ի դադարով, ուսուցման արագության անցում այդ տարողության վրա, վնասված կադրերի 5 տեսակը և broadcast զույգը։ Հաշվետվությունը հավաքվում է նույն օրը։ CONGESTION CONTROL · 4-PORT BLOCK · RFC 2889 §5.5 100% OF MOL PER SOURCE · 30 s · EVERY FRAME SIZE SOURCE A · 100% 1st frame to the uncongested port, 2nd to the congested one, repeat SOURCE B · 100% every frame to the congested port same frame count as source A 50% → UNCONGESTED 50% → CONGESTED 100% → CONGESTED DUT OUTPUT QUEUES UNCONGESTED · 50% IN, 50% OUT +50% CONGESTED · 150% IN, 100% OUT Where does the 50% go: dropped here, or elsewhere? 50% OUT 100% OUT, LINE RATE UNCONGESTED PORT receives 50% of source A's frames expected loss: 0 CONGESTED PORT offered 150%, can carry 100% expected loss: 33% LOSS ON THE UNCONGESTED PORT = HEAD-OF-LINE BLOCKING 0 LOSS ON THE CONGESTED PORT = BACKPRESSURE (FLOW CONTROL) 33% CONGESTED, 0 UNCONGESTED = CLEAN OUTPUT QUEUING Գերբեռնվածության բլոկն այնպես, ինչպես RFC-ն է նկարում. երկու աղբյուր, երկու ընդունիչ, line rate-ի 150%-ը դրանցից մեկի մեջ։ Թե որտեղ կընկնի կորուստը, ասում է, թե ինչպես է կառուցված կոմուտատորը։ Միայն գերբեռնված պորտի վրա. մաքուր սխեմա ելքային հերթերով։ Երկուսի վրա. head-of-line blocking ընդհանուր մուտքային բուֆերից։ Ոչ մի տեղ. flow control, որը դանդաղեցրել է ձեր աղբյուրները։ ### 4 թիվ, որոնք որոշում են pass կամ fail - 0 Կորցրած կադրեր գերբեռնվածության բլոկի չգերբեռնված պորտի վրա։ Այնտեղ ցանկացած կորուստ head-of-line blocking է, իսկ HOLB-ով կոմուտատորը թույլ է տալիս մեկ զբաղված սերվերին դանդաղեցնել պորտ, որը նրա հետ կապ չունի։ - 33% Սպասվող կորուստ գերբեռնված պորտի վրա 150% առաջարկվող բեռի դեպքում առանց flow control-ի։ 0% նշանակում է backpressure. կոմուտատորը դադարեցրել է աղբյուրները՝ կադրեր դեն նետելու փոխարեն։ Ինքնին ոչ մեկը սխալ չէ; հաշվետվությունն ասում է, թե որն ունեք դուք։ - ≤ MOL Forwarding rate ելքային պորտի վրա, մինչ մուտքը սնվում է 88 բիթ միջակայքով։ MOL-ից բարձր արժեքը նշանակում է, որ կոմուտատորը փոխանցում է անթույլատրելի միջակայքով, որը հաջորդ սարքը կարող է սխալ համարել։ - 0 Կադրեր վերահսկման պորտի վրա հասցեների թեստերի ընթացքում։ Այնտեղ մեկ կադրը նշանակում է, որ աղյուսակը լիքն էր, և կոմուտատորը flood արեց; այսպես է «32K MAC-ի աջակցություն» հայտարարությունը գործնականում դառնում 16 384։ ### 30-վայրկյանանոց փորձի անատոմիան - **Ուսուցում**Ուսուցման կադր յուրաքանչյուր հասցեի համար 50 կադր/վ-ով, aging-ի ժամաչափերը զրոյացված, DUT-ին ժամանակ է տրված flood-ն ավարտելու։ - **Ստուգում**Մեկ կադր յուրաքանչյուր հասցեի համար; flood-ը ցանկացած պորտի վրա փորձը վերադարձնում է ուսուցման։ - **Փորձ, 30 վ**Բոլոր պորտերը փոխանցում են միմյանցից 300 մվ-ի սահմաններում; կադրերը հաշվվում են որպես ընդունված կամ flood յուրաքանչյուր պորտի վրա, ժամանիշները պահվում են։ - **Դատարկում և հաշվիչներ**2 վ ճանապարհին գտնվող կադրերի համար, թեստերի հաշվիչները սառեցված, կոմուտատորի ինտերֆեյսների հաշվիչները կարդացված և կցված։ Հաշվետվություն ## Ինչ եք ստանում փորձարկումից հետո Մեկ PDF յուրաքանչյուր կոմուտատորի համար՝ RFC-ի պահանջած յուրաքանչյուր թվով և փորձարկումը կրկնելու համատեքստով։ Թեստերի հում արտահանումները և կոմուտատորի կոնֆիգուրացիան կցված են։ ### Արդյունքներ, կադրի յուրաքանչյուր չափի համար - Full mesh throughput, FRMOL և MFR, գրաֆիկում տեսական գծի կողքին - One-to-many, many-to-one և միակողմանի throughput՝ փնջի չափի և ILoad-ի նշումով - Գերբեռնվածության բլոկ. կորուստ երկու ընդունող պորտերի վրա, HOLB-ի և backpressure-ի վճիռները - Forward pressure. FR 88 բիթ միջակայքի դեպքում MOL-ի դիմաց - Հասցեների տարողություն և ուսուցման արագություն՝ յուրաքանչյուր իտերացիայի flood-ի հաշվիչներով - Վնասված կադրեր. 5 pass/fail տող; broadcast-ի forwarding rate և ուշացում ըստ պորտերի ### Համատեքստ, որպեսզի փորձարկումը հնարավոր լինի կրկնել - Կոմուտատորի մոդելը, սարքավորման ռևիզիան, ԾԱ-ի տարբերակը և կոնֆիգուրացիայի լրիվ արտահանումը - Պորտերի քարտեզ. թեստերի որ պորտը DUT-ի որ պորտի վրա, արագություն, օպտիկա, VLAN անդամակցություն - Հասցեներ մեկ պորտի վրա, ուսուցման արագություն, aging time և փնջի չափ յուրաքանչյուր թեստի համար - Թեստերի մոդելը, որոնվածը և պորտերի արագությունները; loopback նախաթեստի արդյունքը - DUT-ի սեփական կադրերը (STP, LLDP, SNMP) և ինչպես են դրանք հանվել հաշվիչներից - Փորձի տևողությունը և մեկնարկի ցրվածությունը պորտերի միջև, յուրաքանչյուր թեստի համար RFC 2889 · TEST REPORT 24 × 25 GbE · FULL MESH · 30 s TRIALS 5.1Full mesh throughput, 64 B 5.1Full mesh throughput, 1518 B 5.5Head-of-line blocking, 64 B 5.5Backpressure 5.6Forward pressure, 88-bit IFG 5.7Address caching capacity 5.8Address learning rate 5.9Errored frames filtering 71.4% 100% 9% lost none ≤ MOL 16,384 1,200/s 4 of 5 26.6 Mfps per port of 37.2 · datasheet: wire speed, non-blocking 2.03 Mfps per port · 0 lost of 1.46 G sent uncongested port lost 9% · shared input buffer congested port lost 33% at 150% offered · no flow control FR 37,202,380 fps at 88-bit gap · MOL 37,202,381 datasheet: 32K · floods on Mport from 16,385 · 15 iterations 16,384 addresses, 0 floods · 1,500/s floods 212 CRC-errored frames forwarded in cut-through mode ATTACHED CONFIG EXPORT PORT MAP GRAPHS PER SIZE COUNTERS · PCAP Values are illustrative. Your report carries your numbers, per frame size and per traffic pattern. ### Երբ թեկնածուները 2-ն են - Մեկ թեստ-պլան, մեկ ստենդ, մեկ թեստեր երկու կոմուտատորների համար; արդյունքները մեկ աղյուսակում նույն տրաֆիկի սխեմաներով և հասցեներով մեկ պորտի վրա - Էջ յուրաքանչյուր նշանակալի տարբերության համար. որտեղ է մի կոմուտատորն առաջինը flood անում, արգելափակում կամ կորցնում - Կարճ առաջարկություն, որն անվանում է ձեր տրաֆիկի համար ավելի լավ կոմուտատորը և թեստը, որտեղ դա որոշվեց Պրակտիկայից ## Non-blocking թղթի վրա, 71% ցանցում Պատվիրատուն ընտրում էր 48 պորտանի 25 GbE leaf պահոցային fabric-ի համար և ուներ վաճառողի RFC 2544 հաշվետվությունը. wire speed կադրի յուրաքանչյուր չափի վրա, պորտերի զույգ, երկկողմանի։ Մենք վարեցինք RFC 2889 24 պորտի վրա։ Full mesh 1518 բայթի վրա. 100%։ Full mesh 64 բայթի վրա. line rate-ի 71%, կադրերի 29%-ը կորած։ Գերբեռնվածության բլոկն ամեն ինչ բացատրեց։ 9% կորուստ չգերբեռնված պորտի վրա. head-of-line blocking ընդհանուր մուտքային բուֆերից։ Պահոցային fabric-ի համար, որտեղ many-to-one փնջերն ամբողջ օրն են, դա մեկ զբաղված հոսթ է, որը դանդաղեցնում է մնացածին։ Երկրորդ թեկնածուն կորցրեց 33% գերբեռնված պորտի վրա և 0 մյուսի վրա, ճիշտ այն, ինչ RFC-ն սպասում է առանց HOLB-ի կոմուտատորից։ Այն 12%-ով թանկ էր, և գնեցին հենց այն։ Fabric-ը հենց ապրանքն է։ Թեստավորեք fabric-ը։ SAME SWITCH · 64 B · TWO TRAFFIC SHAPES PORT PAIR · THE RFC 2544 RUN 37.2 Mfps of 37.2 per port · wire speed, as printed 100% 24-PORT FULL MESH · THE RFC 2889 RUN 26.6 Mfps of 37.2 per port · 29% of frames lost at line rate 71% LOSS ON THE UNCONGESTED PORT 9% Head-of-line blocking: one busy host slowed down the other 23. Ինչ ենք վարում ## RFC 2889 որպես ծառայություն, CloudLAB-ում կամ ձեր հարթակում Ապարատային թեստեր ձեր կոմուտատորի համար բավարար պորտերով, ինժեներ, որն այս RFC-ն 20 տարի վարել է վաճառողների սարքերի վրա, և հաշվետվություն, որը կարող եք դնել տենդերի մեջ։ ### Մեկ կոմուտատորի բենչմարք Բոլոր 10 թեստերը կամ 4 ցանցայինները, ձեր կադրի չափերի, հասցեների մեկ պորտի վրա և VLAN դասավորության վրա, այնքան պորտով, որքան ունի կոմուտատորը։ Ֆիզիկական սարքը միացված է Հայաստանում կամ ուղարկված մեզ։ Արդյունքները ձեր բրաուզերում, մինչ փորձարկումն ընթանում է։ [Հարցնել թեստ-պլան](https://test4net.com/contacts?hsLang=hy) ### 2 կամ 3-ի շորթ-լիստ Նույն պլանը, նույն ստենդը, նույն օրը յուրաքանչյուր թեկնածուի համար։ Արդյունքների աղյուսակ, որտեղ full mesh-ը, HOLB-ը և հասցեների տարողությունը կողք կողքի են, և նշված է, թե որտեղ է ավելի էժանը բավարար։ [Համեմատել թեկնածուներին](https://test4net.com/contacts?hsLang=hy) ### Ընդունում ներդրումից առաջ Ձեր կոմուտատորը, ձեր կոնֆիգուրացիան, ձեր տրաֆիկի սխեմաները, վարված որպես pass կամ fail պայմանագրի թվերի դիմաց։ Հաշիվ-ապրանքագրից առաջ, վաճառողը կարող է ներկա լինել։ [Կազմակերպել ընդունման փորձարկում](https://test4net.com/contacts?hsLang=hy) ### Ձեր ինժեներները, մեր ստենդը CloudLAB մուտք թեստերի պորտերին՝ բեռնված RFC 2889 պլանով։ Վարեք ինքներդ, որքան անգամ պետք է, մեր ինժեների հետ չաթում։ [Մուտք CloudLAB](https://lab.test4net.com/) - Անկախ. մենք վաճառում ենք թեստը, վաճառողը՝ կոմուտատորը - Ապարատային թեստեր յուրաքանչյուր պորտի վրա, մեկ ժամացույց, մեկնարկի ցրվածություն 300 մվ կամ ավելի լավ - Հաշվետվության յուրաքանչյուր թիվ վերարտադրելի է կցված պլանից և արտահանումներից ### Կարդալ հաջորդը - [ՄեթոդաբանությունRFC 2544. զրո կորուստով բենչմարք կոմուտատորների և երթուղիչների համար](https://test4net.com/methodologies/rfc-2544?hsLang=hy) - [ՄեթոդաբանությունRFC 9411. firewall-ների և NGFW-ի բենչմարք բոլոր գործառույթները միացրած](https://test4net.com/methodologies/rfc-9411-rfc-3511?hsLang=hy) - [Ինչու TEST4NETԻնչու է անկախ ստենդն ավելի լավ, քան վաճառողի դեմոն](https://test4net.com/why-test4net?hsLang=hy) ՀՏՀ ## Հարցեր, որոնք տալիս են RFC 2889 փորձարկումից առաջ Մենք ունենք վաճառողի RFC 2544 հաշվետվությունը։ RFC 2889-ն իսկապե՞ս տարբեր է։ RFC 2544-ը բեռնում է պորտերի մեկ զույգ; RFC 2889-ը բեռնում է բոլոր պորտերը միանգամից և ավելացնում գերբեռնվածության, MAC աղյուսակի և զտման թեստեր։ Կոմուտատորը 2544-ն անցնում է միայն պորտի ASIC-ով։ 2889-ը նա անցնում է fabric-ով, ընդհանուր բուֆերով և lookup շարժիչով միասին։ «Non-blocking»-ը 2889-ի հայտարարություն է, իսկ datasheet-ների մեծ մասում վարել են միայն 2544։ Դուք թեստավորո՞ւմ եք բոլոր 48 պորտերը։ Այնքան, որքան թեստերն ունի այդ արագության վրա, սովորաբար 16-ից 32 25 GbE-ի վրա և 8-ից 16 100 GbE-ի վրա։ RFC-ն թույլ է տալիս ցանցը ցանկացած ենթաբազմության վրա; հաշվետվությունում գրված է, թե որ պորտերի վրա։ «Non-blocking» հայտարարության համար մենք լցնում ենք ASIC-ի ամբողջ թողունակությունը, իսկ 100 GbE-ի վրա դրա համար ավելի քիչ պորտ է պետք, քան 10-ի վրա։ Ինչո՞ւ 30-վայրկյանանոց փորձեր, երբ RFC 2544-ն ասում է 60։ RFC-ն խորհուրդ է տալիս 30 վ և թույլ է տալիս 1-ից 300։ 10 թեստով, 7 կադրի չափով և տրաֆիկի մի քանի սխեմայով 60 վ փորձերը կկրկնապատկեին 2-օրյա փորձարկումը։ Ժամանակակից կոմուտատորների բուֆերները լցվում են միլիվայրկյանների ընթացքում, այնպես որ 30 վ-ը բավական է կորուստը տեսնելու համար։ Եթե տենդերում նշված է 60 վ, վարում ենք 60 վ։ Կոմուտատորը թեստի ընթացքում flood է անում։ Ո՞վ է մեղավոր։ Սովորաբար կարգավորումը. ուսուցման կադրերն առաջարկվել են չափից արագ, aging time-ը փորձից կարճ է, կամ հեշավորման սխեման չի տեղավորում ընտրված MAC ձևանմուշը։ RFC-ն նկարագրում է բոլոր 3-ը, ուստի մենք ուսուցումը դանդաղեցնում ենք մինչև 50 կադր/վ, aging-ը դնում փորձից բարձր և փոխում հասցեների ձևաչափը, նախքան կոմուտատորին մեղադրելը։ Եթե այն N հասցեի դեպքում դեռ flood է անում, դա էլ տարողության թիվն է։ Head-of-line blocking թե backpressure. ո՞րն է ավելի վատ։ HOLB-ն ավելի վատ է ցանցերի մեծ մասի համար։ Այն նշանակում է, որ գերբեռնված պորտը ստիպում է անկապ պորտին կադրեր կորցնել, այնպես որ մեկ զբաղված սերվերը դանդաղեցնում է հարևաններին։ Backpressure-ը նշանակում է, որ կոմուտատորը դադարեցնում է աղբյուրները դեն նետելու փոխարեն, ինչը հարմար է պահոցային ցանցին և խանգարում է ուշացման նկատմամբ զգայուն ցանցին։ Հաշվետվությունը ցույց է տալիս, թե որն ունեք; ընտրությունը ձերն է։ RFC 2889-ը կիրառելի՞ է 100 GbE և 400 GbE կոմուտատորների համար։ Այո։ RFC-ն գրվել է 10, 100 և 1000 Մբիթ/վ-ի շուրջ, բայց յուրաքանչյուր պարամետր սահմանում է միջավայրի նկատմամբ. նվազագույն միջկադրային միջակայք, MOL, կադրի չափեր RFC 2544-ից։ Մենք այն վարում ենք 25, 100 և 400 GbE-ի վրա նույն ընթացակարգով։ Միակ ճշգրտումը քայլի չափն է MOL-ի մոտ, որտեղ սահմանը դնում է թեստերի միջակայքի լուծաչափը։ ## Դրեք կոմուտատորը ցանցի մեջ Ուղարկեք մոդելը կամ շորթ-լիստը, պորտերի քանակն ու արագությունը և տրաֆիկի սխեման, որը վարում եք. պահոց, կամպուս, leaf-spine։ Ի պատասխան ստանում եք RFC 2889 թեստ-պլան. թեստեր, հասցեներ մեկ պորտի վրա, լաբորատոր օրեր և գին։ Test. Compare. Decide. [Հարցնել թեստ-պլան](https://test4net.com/hy/methodologies/rfc-2889#lead-form) [Մուտք CloudLAB](https://lab.test4net.com/) Ուղարկեք ցուցակը ## Մեթոդը ձեր ձեռքին է։ Մնում է ստանալ թվերը։ Ուղարկեք ցուցակը և ձեզ համար կարևոր ցուցանիշները։ Ինժեները կպատասխանի մեկ աշխատանքային օրվա ընթացքում թեստային պլանի նախագծով և գնահատականով։ Հարմար է զրուցե՞լ։ [Գրել ինժեներին WhatsApp-ով](https://wa.me/37491612709) Ուղարկվածն օգտագործում ենք միայն ձեզ պատասխանելու համար։ Տե՛ս [գաղտնիության քաղաքականությունը](https://test4net.com/hy/privacy-policy?hsLang=hy)։ [Ուղարկեք ցուցակը](https://test4net.com/hy/methodologies/rfc-2889#lead-form) [![TEST4NET LLC](https://test4net.com/hubfs/test4net-logo-fixed.svg)](https://test4net.com?hsLang=hy) Independent testing and validation for telecom, information security and cloud infrastructure – real insights, not assumptions. [mailto:sales@test4net.com](mailto:sales@test4net.com) #### Navigate - [Home](https://test4net.com/?hsLang=hy) - [Why TEST4NET](https://test4net.com/why-test4net?hsLang=hy) - [About us](https://test4net.com/about?hsLang=hy) - [Contact](https://test4net.com/contacts?hsLang=hy) - [Բլոգ](https://test4net.com/blog?hsLang=hy) - [Ոլորտի նորություններ](https://test4net.com/news?hsLang=hy) #### Get in touch Sales [sales@test4net.com](mailto:sales@test4net.com) Support [support.test4net.com](https://support.test4net.com) © 2026 TEST4NET LLC. All rights reserved. [Privacy Policy](https://test4net.com/hy/privacy-policy?hsLang=hy) [Legal](https://test4net.com/legal?hsLang=hy) ```json { "@context" : "https://schema.org", "@id" : "https://test4net.com/#organization", "@type" : "Organization", "address" : { "@type" : "PostalAddress", "addressCountry" : "AM", "addressLocality" : "Yerevan", "postalCode" : "0033", "streetAddress" : "3 Hakob Hakobyan Street (Mergelyan Hub)" }, "alternateName" : "TEST4NET", "contactPoint" : { "@type" : "ContactPoint", "availableLanguage" : [ "en", "ru", "hy" ], "contactType" : "sales", "email" : "sales@test4net.com", "telephone" : "+374-60-88-88-99" }, "description" : "Independent, vendor-neutral lab for testing network and cybersecurity products — NGFW, WAF, IPS, DLP and SASE — and an authorized distributor of test, measurement and network infrastructure solutions.", "email" : "sales@test4net.com", "foundingDate" : "2024", "image" : "https://test4net.com/hubfs/og-t4n.png", "logo" : "https://test4net.com/hubfs/test4net-logo-fixed-2.svg", "name" : "TEST4NET LLC", "sameAs" : [ "https://www.linkedin.com/company/test4net/", "https://t.me/TEST4NET", "https://www.facebook.com/people/Test4net-LLC/61591470856077/" ], "telephone" : "+374-60-88-88-99", "url" : "https://test4net.com/" } ``` ```json { "@context" : "https://schema.org", "@id" : "https://test4net.com/#website", "@type" : "WebSite", "inLanguage" : "en", "name" : "TEST4NET", "potentialAction" : { "@type" : "SearchAction", "query-input" : "required name=search_term_string", "target" : { "@type" : "EntryPoint", "urlTemplate" : "https://test4net.com/hs-search-results?term={search_term_string}" } }, "publisher" : { "@id" : "https://test4net.com/#organization" }, "url" : "https://test4net.com/" } ```