On 4/13/21 9:38 PM, Ivo Chutkin wrote: > Hello guys, > > Thanks for replies. To add some more info for the case. > > We have DWDM network with star topology. Switches will be connected to > center point with 100G uplink (currently 10G or 2x10G) via DWDM lambda. > Customers are connected to 10G ports. > > We carry Internet traffic and IPTV multicast to regional ISPs over VLANs. > > What is important for me is switch to be capable to carry traffic on > wire speed without packet loss. Latency is not big issue here. > > I will also have a look at Arista switches. > > Thanks a lot for the help, > Ivo
In a previous day job, I did large-scale benchmarking of switches and routers from Arista, Cisco, Huawei, Juniper, and many other vendors. Switch ASICs have been commodities for years. Anything sold to enterprises or service providers runs at wire speed* without loss, provided the traffic pattern doesn't create oversubscription. You can force loss by creating an oversubscribed traffic topology (e.g., directing traffic from two or more ingress ports to one egress port), but then the loss is due to the traffic pattern (and to a small extent, the amount of buffer memory), not the switching silicon. Key point is that in terms of the RFC 1242 definition of throughput, you're going to see wire-speed performance for pretty much any enterprise-class switch, for any frame length. You're likely to see differences in latency and jitter, but not throughput. dn *This is really an edge case, but the definition of "wire speed" can differ between transmitting and receiving Ethernet ports because (a) Ethernet is asynchronous (each device uses its own free-running clock) and (b) device clocks can run at slightly different speeds and (c) even within a single device, its clock will vary around that speed by different amounts, depending on the precision of its clocking chip (a timing crystal with 10-ppm precision costs a LOT more than one with 100-ppm precision). As a result, you will see frame loss over time if a transmitter's clock runs slightly faster than a receiver's clock. Many benchmarks are run for a relatively short duration (e.g., 60-300 seconds) where buffering will cover for clocking differences. Run a test long enough, and frame loss may occur. There's no one correct answer here. The IEEE spec says every Ethernet interface must tolerate +/- 100 ppm of clocking variation, which can lead to loss for the reasons discussed above. The IETF RFC 1242/2544 and 2285/2889 specifications on router and switch testing define throughput as a zero-loss condition. There's been much discussion at the IETF about an acceptable loss threshold, but the only number everyone agrees on is zero. > > On 10.4.2021 г. 00:10 ч., Tom Smyth wrote: >> +1 re arista switches... >> >> On Friday, 9 April 2021, Diana Eichert <deich...@wrench.com> wrote: >> >>> I second Arista switches, in my day job we use a lot of Arista >>> switches. Though one of the "issues" we see is Arista >>> drops older tech regularly. I believe their last presentation to us >>> was 25G/100G/400G switches. >>> >>> On Thu, Apr 8, 2021 at 1:18 PM Mischa <obs...@high5.nl> wrote: >>>> >>>> Hi Ivo, >>>> >>>> I don’t have any experience with the Dell switches but what about the >>> Arista DCS-7050QX-32 or DCS-7050QX-32S? >>>> 32x40G QSFP+ for the 7050QX-32 >>>> 32x40G QSFP+ of which one QSFP+ can act as a dual personality to 4xSFP+ >>> for the 7050QX-32S. (mind the S) >>>> >>>> There are converters for the QSFP+ to turn them into a SFP+ port if you >>> need more 10G but want to have a way to migrate to 40G. >>>> You can do this with the Mellanox 655902-001 QSA adapter. >>>> >>>> Which is pretty much what we have in production. :) >>>> Are you planning to buy new or eBay? There are some pretty good >>>> deals on >>> eBay. >>>> >>>> Mischa >>> >>> >> >
