YES, the respective "BW" will only be allocated for the Customer, includes the BURST Value as in Command.
Answer to Question:2
The Customer Traffic (inbound / outbound) will not go beyond the reserved one as in command. But the Query is: What is the Traffic Type (Source / Destination Traffic) to be allowed to Access / reserved in the BW Limit ?
Does this rate-limiting provide proper way of allocating bandwidth?
Rate-limiting is one method of restricting bandwidth. Allocation of bandwidth might also include methods like CQ or CBWFQ.
With regard to "proper", I prefer shaping.
"What effect does this rate-limiting command has on bandwidth allocation?"
It sets a hard limit on maximum bandwidth usage. It behaves much like a physical interface with that much bandwidth using a FIFO queue. The burst size behaves much like a physical interface's FIFO queue size.
"Considering the sub-interface used, will this command actually limit the customers?"
I'm unsure. If it works as you've configured it, it should apply to all traffic across the subinterface. You might want to make an exception for some traffic, e.g. management traffic.
Not clear whether you asking about where service policies might be applied, inbound and outbound, or traffic control in general, or both. So, I'll try to briefly cover all. Hopefully, I'll answer your question.
I don't recall whether you can use a shaper within an inbound service policy. However, if you're unable to, and assuming you don't have multiple outbound interfaces the inbound traffic can go to, you could place the shaper on the outbound interface. This could be done in the OP's case since each customer appears to have a unique subnet.
It is possible to have both an inbound and outbound service policy on the same interface. Again, there might be restrictions on what such a policy might contain.
Whether you use a shaper or policier (rate limiter) against inbound traffic, the inbound link might have already suffered congestion above the configured limits before it arrives at the shaper or policier. The shaper or policier will regulate the traffic downstream of it. Of the two, by default, an inbound policier usually offers less buffering and may better keep inbound traffic from bursting higher on the inbound link.
In other words, you can control or regulate inbound TCP traffic to some extent, although it's very weak in comparison to outbound control or regulation. For non TCP traffic, that isn't rate adaptive to packet discards, we can not influence the sender's transmission rate.
In the OPs case though, we're not trying to regulate inbound traffic volume, only the traffic rate permitted to/from a particular customer. I.e. the customer will not see or obtain end-to-end bandwidth beyond the limits we've configured.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...