@paul driver wrote:
See attached for a possible solution..
Again, much of what Paul suggests is not "wrong", but perhaps more a question of style or taste.
For example, consider:
class-map match-any tenent1_cm
match any
class-map match-any tenent2_cm
match any
policy-map tenent1_pm
class tenent1_cm
police 30000000 conform-action transmit exceed-action drop violate-action drop
policy-map tenent2_pm
class tenent2_cm
police 1000000000 conform-action transmit exceed-action drop violate-action drop
interface GigabitEthernet2.900
bandwidth 30000
encapsulation dot1Q 900 native
service-policy input tenent1_pm
service-policy output tenent1_pm
interface GigabitEthernet2.901
bandwidth 100000
encapsulation dot1Q 901 native
service-policy input tenent2_pm
service-policy output tenent2_pm
Is perfectly functional, but it might be also written as:
policy-map tenent1_pm
class class-default
police 30000000 conform-action transmit exceed-action drop violate-action drop
policy-map tenent2_pm
class class-default
police 1000000000 conform-action transmit exceed-action drop violate-action drop
interface GigabitEthernet2.900
bandwidth 30000
encapsulation dot1Q 900 native
service-policy input tenent1_pm
service-policy output tenent1_pm
interface GigabitEthernet2.901
bandwidth 100000
encapsulation dot1Q 901 native
service-policy input tenent2_pm
service-policy output tenent2_pm
The latter eliminates the need, in this case, for the class maps.
You might also write this as:
policy-map 30Mbps
class class-default
police 30000000 conform-action transmit exceed-action drop violate-action drop
policy-map 100Mbps
class class-default
!original police value was for 1Gbp, but I believe 100 Mbps was intended, as in the bandwidth statement
police 100000000 conform-action transmit exceed-action drop violate-action drop
interface GigabitEthernet2.900
bandwidth 30000
encapsulation dot1Q 900 native
service-policy input 30Mbps
service-policy output 30Mbps
interface GigabitEthernet2.901
bandwidth 100000
encapsulation dot1Q 901 native
service-policy input 100Mbps
service-policy output 100Mbps
Which to use, per tenant or per bandwidth allocation, depends on your expectations. Certainly having a policy for every tenant provides much flexibility, and is fine for a handful. However, as the number of tenants increase, you'll likely want to share the same policy across multiple tenants. In this case, one policy for a specific bandwidth allowance, might be sharable.
In the above, we have police statements that ignored OP's Bc/Be and explicitly coded the conform/exceed/violate actions.
So, I tried the following in CML with the noted results:
policy-map test
class class-default
police 3000000
!actually, when I entered the police command I used 30m for the bit rate
!an option, I recall, not available on earlier IOS versions
interface GigabitEthernet0/0
no ip address
shutdown
duplex auto
speed auto
media-type rj45
service-policy input test
service-policy output test
inserthostname-here#sh policy-map interface g0/0
GigabitEthernet0/0
Service-policy input: test
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
police:
cir 30000000 bps, bc 937500 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps
Service-policy output: test
Class-map: class-default (match-any)
0 packets, 0 bytes
5 minute offered rate 0000 bps, drop rate 0000 bps
Match: any
police:
cir 30000000 bps, bc 937500 bytes
conformed 0 packets, 0 bytes; actions:
transmit
exceeded 0 packets, 0 bytes; actions:
drop
conformed 0000 bps, exceeded 0000 bps
!defaults can vary between platforms - but if you wanted the OP's Bc, you could add it
!unless you're really aware of how to use Bc, I would suggest just allowing the default
!notice no Be, or violate actions, both make sense as we drop out of Bc
Next we have the proposed egress policy:
Shaping - egress
---------------------
policy-map shape_child
class tenent1_cm
bandwidth 30000
class tenent2_cm
bandwidth 100000
class class-default
bandwidth 250000
fair-queue
policy-map shape_parent
class class-default
shape average 1000000000
service-policy shape_child
interface GigabitEthernet0/0/0
bandwidth 1000000
service-policy output shape_parent
Firstly, as g0/0 is gig, and assuming we have all gig, shaping isn't necessary (or useful or effective). It would be needed if were working with a logical bandwidth cap.
Secondly, although it seems reasonable to have class statements for each tenant, OP only contrasted all tenants' bandwidth with client's usage, wanting to give priority to tenants' traffic.
The can be pretty closely accomplished by something like:
class-map client
match input-interface g0/1
policy-map toInternet
class client
bandwidth 1
fair-queue !optional
class class-default
bandwidth 999999
fair-queue !optional
interface g0/0
bandwidth 1000000
service-policy output toInternet
The above, though, doesn't totally starve client bandwidth, so if tenants have been allocated the full gig, they are going to be shortchanged (by a very minimal value).
If you truly wanted to preclude taking bandwidth from tenants, on later platforms, you might try:
policy-map toInternet
class client
priority level 2
class class-default
priority level 1
The above, should exactly meet your "ask", except for one thing. What about Internet ingress?
Actually, as even tenant policing is downstream of the Internet connection, one tenant can pull more data down the Internet connection than will be passed through the policer. I.e. they won't receive it, but it uses bandwidth on the Internet link. Hopefully (and usually), not a lot more bandwidth, as most apps will have issues with a high packet lost rate and often slow their transmission rate.
However, the client isn't capped at all. So they could really slam their tenants on downloads. If they want to preclude this, they can also rate limit themselves, on g0/1 (only egress), and try to insure there's some "headroom" above and beyond the aggregate of all the (egress) policers (client and tenants).
This latter issue is the dead end, I alluded to in my prior reply. It's very difficult to manage bandwidth downstream of the bottleneck.
Upstream, in theory, we have g0/1 and g0/2 that can send twice as much data as g0/0 can transmit. But, the g0/0 egress policy can manage such congestion as we desire.
However, downstream, g0/0 is already limited to gig, but we can only indirectly influence the client and/or tenant bandwidth usage coming in. Yea, we can control what the client or tenants actually receive, bandwidth wise, but that's not the same as controlling usage of the Internet bandwidth coming to us.
Years past, there were some 3rd party products (e.g. Packeteer) that could often much better manage ingress bandwidth (especially for TCP), but even they couldn't work as well as upstream QoS egress for bandwidth arbitration (they could also make TCP work even "better"). (These products never really seemed to catch on, possible because the benefits they offered weren't well understood and/or the cost of these products. [Sort of like trying to convince those paying for network equipment why more expensive Cisco devices are "better" than Brand X. Or, laugh, trying to convince many network engineers the benefits of QoS beyond protecting VoIP, etc.])
