In general all traffic is send via TRUNKS and VLAN’s between switches and between switches and servers/the firewall.
There are situations where traffic arriving from the firewall is send to the 10G-switch and from there send directly to a server having a 10G-connection but also to an other switch or endpoint with a lower connection speed.
In a non-vlan situation ‘xon-xoff’ kind of could help to stop package overrun, however in the described situation, that simple flow control mechanism is not adequate!!?
(the traffic is send via a vlan end ending on some end equipment)
So, my question is, how to configure switches in particular the CRS317 in such a way that not more vlan related packages are send to the next switch / the endpoint than the next switch or the end point can handle?
Of course buffer over run in one of the switches or end device should not happen
not on VLAN-level and not on physical-connection (trunk) level.
(this question is NOT about traffic prioritization!!)
Of course traffic towards 10G-devices should not be stopped by .e.g. 1G-devices as well
(I hope that is possible as well)
I know there is a protocol to control vlan related data streams, however how to define that in router-os, not idea! That will probably fix part but not all of the described issues.
So info on how to handle this kind traffic best, is highly appriciated!
The only available mechanisms between xon-xoff (too coarse) and application level accommodation to available bandwidth (unable to predict bursts of competing traffic) is traffic policing on ingress (more selective but not the way you need, and only some switches can do that. “Policing” means “dropping what does not fit” here so also not what you expect.
The thing is - think what you actually want to happen. For simplicity, imagine two 5 Gbps streams, each wishing to get through your 10 Gbps uplink and firewall to another PC on LAN. Both PCs are connected using a 2.5 Gbps interface each. There are only two ways to deal with the bandwidth difference - either the recipient can somehow tell the source to slow down (which is what typically the application level accommodation to available bandwidth does on WAN level, and xon/xoff on LAN level), or to drop what does not fit. Nothing in between, except queues/buffers if we talk about bursty traffic whose average speed is below the bottleneck throughput but short-time spikes exceed it.
In yet other words - xon/xoff is typically useless for any scenario where multiple unrelated flows ingress via a single higher bandwidth port and egress via different lower bandwidth ports (and multiple other scenarios too) even if the source is local and accepts the forwarded xon/xoff. So it does not matter whether those flows are separated by VLANs or just by IP addresses and ports, the key is that they share some part of the same physical path. And in any case, there is no way to deliver the xon/xoff to a source in the internet - there, only the application level accommodation can be used.
Well, as @sindy also wrote, there is no real way to achieve that, it is not part of the design of ethernet networking and IP. There is “flow control” on physical links, but its usage is discouraged nowadays because it simply stops the entire traffic flow instead of the flow that causes the problems.
E.g. when you have a 10Gbit link to a switch that has 2.5Gbit ports, at some point more traffic could be sent to the switch than one of the ports can handle, but when you then stop the traffic on the 10Gbit link using flow control, you also stop the traffic that was destined for another 2.5Gbit port that has capacity to spare.
So in general it is considered better to forget your “Of course buffer over run in one of the switches or end device should not happen” starting point and just let the overruns happen, and hope that the switch is clever enough to allocate buffer space for each port separately and not use all buffers for traffic to one port.
Furthermore, the situation will regulate itself when packages get dropped, the receiving end (the PC) will notice and send back control packets to the sender that will make it slow down to fit the slowest link in the chain.