Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages wha2tsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
What would be a reason to apply QoS policy on the LAN interface?
Same reason you apply to any other interface, to meet some QoS goal.
For LAN interface ingress, assuming router's forwarding performance isn't a bottoleneck, there should be no reason to apply a QoS policy as traffic in this direction already has a policy on the same device WAN egress.
Probably not, but much depends on what you're trying to accomplish. For example, although you note you don't have a bottleneck, just as with ACLs, policing sooner is more "efficient". Or, for example, traffic on an ingress interface goes to different egress interfaces, and you want to manage it there.
For LAN interface egress, if there is no bottoleneck on the LAN, is there any reason to apply a policer/shaper here? Marking might has some valid use cases. But isn't that better done on the WAN ingress interface?
You can not shape with an ingress policy. Again, there can be cases where it's better to police on ingress. For example, if you police user LAN edge ingress ports, you can limit max EF marked traffic to what's expected per user. Trying to do similar, on an aggregate interface, on many platforms, can be more difficult.
