What is the best practice for putting 802.3x flowcontrol on a userport and does this inhibit performance if the application/system isn't designed for it?
Eg)
interface gig0/1
flowcontrol receive [desired | on | off]
What is the best practice for putting 802.3x flowcontrol on a userport and does this inhibit performance if the application/system isn't designed for it?
Eg)
interface gig0/1
flowcontrol receive [desired | on | off]
Most often Cisco devices can only receive PAUSE frames. They can't send them.
If you are running storage over your network I can understand why you would be looking at implementing it and some server/storage vendors even recommend you to do so.
Note however that PAUSE frames is a very blunt tool as it can pause all traffic meaning you can't differentiate between packets. That means your high priority packets will be treated the same as low priority packets. If you run a separate storage network then it's no issue and you can safely enable it.
There is a standard 802.1Qbb that enables to send PAUSE frames per class so not all the traffic gets paused.
This article describes how 802.3x works and the implications of running it like adding delay to RTT for TCP packets and such.
It's a negotiated feature, so if a device doesn't support it, it won't be negotiated and thus won't be active. As Dib points out, it is a bit of a hammer, but given the way most systems use it ("oh, sh*t, my buffers are full"), it's still useful as the alternative is a lost frame.
That said, there have been bugs where an interface would act on a pause frame and then never process the unpause. But that should be rare today.