Not an expert at this level of switching, but my understanding, as your suggesting is to enable Flow Control on the ports, possibly more on the 1G ports because they are the bottle neck. If the 10G port is receiving full speed and passing on to a 1G port which can't pass fast enough, then the buffers fill up instantly.
If flow control is enabled, it will signal to the 10G port that the buffers are full and things should pause while the 1G port catches up. I've read similar examples between Netonix and AirFibers. I forget which devices needed the flow control enabled on the switch, but it seems like it was the slower port, thus allowing the slow port to signal when their buffers were full. I don't remember exactly which devices should have flow control enabled to avoid the problems, but this sounds like one of those cases. Definitely interested in better understanding what to do here. On Mon, Nov 7, 2016 at 8:52 AM, Fred Goldstein <f...@interisle.net> wrote: > On 11/7/2016 10:40 AM, Josh Reynolds wrote: > > Negative, layer2 flow control is an axe when you need a scalpel. Turn it > off everywhere! > > Layer3 has automatic mechanisms to help handle bandwidth saturation, and > packet loss is part of that process. Furthermore, proper ToS/DSCP queueing > is equally important. > > > Well, technically no, Layer 3 has NO mechanisms to deal with capacity. It > was a known issue among the network working group members in 1973 and a > known issue in 1974 when TCP v1 was written, but the team had turned over > by 1978 when TCP/IPv4 came out, and that group forgot about it until 1986 > when things fell apart. The temporary short-term not very good fix was in > layer 4 (TCP Slow Start) and that doesn't even apply to all streaming, > though many do cooperate. Of course it was "good enough", so 30 years later > it is taken as gospel. TCP/IP is the *chabuduo *of protocol stacks. > > There could be issues with using flow control on the Ethernet port, but > really flow control should have been part of every layer. Loss should > generally be localized. > > On Nov 7, 2016 9:36 AM, "Judd Dare" <judd.d...@gmail.com> wrote: > >> So you're saying, make sure Flow Control is enabled on the ports? >> >> On Mon, Nov 7, 2016 at 8:22 AM, Josh Reynolds <j...@kyneticwifi.com> >> wrote: >> >>> Microbursts causing buffer drops on egress ports to non-10G capable >>> destinations. The switch wants to send data at a rate faster than the 1G >>> devices can take it in, so it has to buffer it's data on those ports. >>> Eventually those buffers fill up, and it taildrops traffic. TCP flow >>> control takes over and eventually slows the transfer rate by reducing >>> window size. It doesn't matter if its only sending 100M of data, its the >>> RATE that it is sending the data. >>> >>> On Nov 7, 2016 8:58 AM, "TJ Trout" <t...@voltbb.com> wrote: >>> >>>> I have a 10G switch that is switching everything of mine at my NOC, >>>> including peers, router wan, router lan, uplink to tower, etc >>>> >>>> During peak traffic periods ~2gbps I'm seeing 1% packet loss and >>>> throughput will drop to 0 for just a second and resume normal for a few >>>> minutes before dropping back to zero for just a second. doesn't seem to be >>>> affecting the wan side of my router which connects to peers through the >>>> same switch. Doesn't happen during the day with low periods of traffic. >>>> >>>> I've enabled / disabled STP, Flow control. >>>> >>>> I believe I've isolated it to not be a single port, possibly have a bad >>>> switch but that seems hard to believe... >>>> >>>> Port isn't flapping, getting small amounts of fcs errors on receive and >>>> lots of length errors but i think those shouldn't be a problem? >>>> >>>> It's an IBM G8124 10G switch >>>> >>>> Ideas? >>>> >>>> _______________________________________________ >>>> Wireless mailing list >>>> Wireless@wispa.org >>>> http://lists.wispa.org/mailman/listinfo/wireless >>>> >>>> >>> _______________________________________________ >>> Wireless mailing list >>> Wireless@wispa.org >>> http://lists.wispa.org/mailman/listinfo/wireless >>> >>> >> >> _______________________________________________ >> Wireless mailing list >> Wireless@wispa.org >> http://lists.wispa.org/mailman/listinfo/wireless >> >> > > _______________________________________________ > Wireless mailing > listWireless@wispa.orghttp://lists.wispa.org/mailman/listinfo/wireless > > > > -- > Fred R. Goldstein k1io fred "at" interisle.net > Interisle Consulting Group > +1 617 795 2701 > > > _______________________________________________ > Wireless mailing list > Wireless@wispa.org > http://lists.wispa.org/mailman/listinfo/wireless > >
_______________________________________________ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless
