Requesting some clarity (2 different questions)
1) Backbone Management
Suppose we have an L3VPN customer with 4 sites- A(2M), B(3M), C(4M) and D(6M).
And sites A, B and C, D are on opposite sides of a particular backbone link.
a) How is the bandwidth guaranteed
b) How is bandwidth reservation done in the core?
2) Bandwidth Policing:-
Let's say we have a customer who has bought 5M, out of this 2M is real-time and 3M is data-class. Is there a way where I can give entire 5M to customer when he is not forwarding any real-time bandwidth.
Please help me understand this. As evident I have just started with QoS.
I tried searching the forum and the site... couldn't find anything specific.
I am not 100% sure on the backbone management question, but here is my best educated guess. ( I would welcome anyone to counter my view based on the actual experience).
Bandwidth in the core could be guaranteed by the use of RSVP-TE to establish the tunnels for the VPN. But this just reserves the bandwidth at the control-plane and forms the tunnel. at dataplane you would have to apply qos at all the nodes in the path which would seem difficult. So my best guess is that the SP hyst polices the traffic coming in from the customer to whatever he is guaranteed. This way the backbone wont be oversubscribed and the traffic coud be guaranteed.
As far as the seconf qos question is concerned, you can have H-Qos with bandwidth and shaping to 5mbps at the parent class, and bandwidth guarantees of 2 and 3 mbps for the child classes of real time and data. The bandwidth command will give the minimum guarantee of thatmuch bandwidth also allowing the class to use more if bandwidth is available on the link.
Thanks for you response, I will surely be having RSVP-TE tunnels and will reserve the entire backbone (STM-4) bandwidth. I am doing the policing at ingress which is a 3750, I know how the allocation will happen incase of a 2 site VPN, what I am looking for is how the bandwidth will be reserved in the backbone incase of 4 sites with varying CIRs.
Regarding oversubscription that is entirely dependant on how we manage the bandwidth, which is already planned.
Regarding the second question you say that I can have HQoS, i am not sure whether that is supported by 3750, I am thinking using CIR/EIR for doing the same though.
I am not looking for specific configurations, what I was looking for are some best practices that SPs follow.
H-qos is supported by the 3750. Following are the refrences :
Also As far as I can think on this, I dont think the solution is possible without h-qos. on a single level you would have to police each class at the associated bandwidth. If you police both classes at 5M and give bandwidth at 2/3M then they may get excess bandwidth is the remaining badwidth on the link is free.
So the best solution is,
Parent class : shape @ 5M.
child class 1 : bandwidth 2M, Priority.
Child class 2 : bandwidth 3M.
As for the other question, ( this is my guess but fits the description) :
As your RSVP-TE tunnels are unidirectional, you can reserve the required bandwidth from each pe to all other PEs according to your policy. i.ie looking at your example,
3 tunnels from A to B, C and D each with 2M reserved bandwidth. Similarly, from D, you can have 3 tunnels to the other 3 with 6M reserved bandwidth.
Now while writing this, I am noticing a lot of drawbacks to this approach and might not be the right one. Do post it here if you do get the answers.
Hope atleast your other question is solved.
Thanks again for your response... I will be starting the testing very soon, want to define the policies before we get started so that things will be smooth during the testing.
Coming back to my questions, I will surely let the forum know what I will do for my backbone problem.
Regarding the CIR/PIR assignment, I am planning the testing on 3750 (Not 3750 Metro) and am looking for ways where say I have a customer who takes a package of 5 Mb out of which 2 Mb is Real Time and 3 Mb is Business Data, I want the customer to use entire 5 Mb for Business Data class when he is not transmitting Real Time. I know this is possible on 3750 Metro. I am still not sure whether this can be done on 3750... Will be mighty pleased if you prove me wrong ;-)
The second link that I provided you above gives the config guide for the non-metro switch itself. That gives config for heirarchial maps. the only catch mentioned is :
"n Cisco IOS Release 12.2(25)SE or later, you can configure hierarchical policy maps on SVIs, but not on other types of interfaces. Hierarchical policing combines the VLAN- and interface-level policy maps to create a single policy map."
So you could try to configure and see whether it is yourking.
Yes, that's the catch isn't... always is in our line of work...
Now what I am thinking is that I will do away with this PIR fight, instead I will rate limit the port for 5M and configure policy restricting Real Time to only 2M, this way the entire 5M can be used for Data Class when there is no Real Time traffic... I've not tested this but think it should work... what are your thoughts...
Can you clarify that a bit? Do you mean to say that you will use MLS qos to set the ratelimit on the port and MQC for provisioning bandwidth to classes?
Can you sive pseudo config to clearify your point?
This is what I am thinking, please note that I am yet to check this in an actual switch...
class-map match-all Real_Time
match access-group xxx
set dscp 42
police 512000 8000 exceed-action drop
set dscp 2
rate-limit input 1024000 1500 2000 conform-action transmit exceed-action drop
couple of things to look into :
1. Will rate limit and MQC police work together???
2. You are ratelimiting to 10M. So there is a chance that when there is 5 M real time traffic and also 5M data traffic, you will allow a total of 10M. Your current policy has no control on the ratio of data and realtime traffic flowing if both are coming at say 10M.
I got some more info on how this is implemented( in VSNL atleast)..
The customer is provisioned bandwidth and is policed to that rate at the ingress. After that there is no checks on the bandwidth. There is enough bandwidth in the core and RSVP-TE is run between the core routers. The tunnels are generic and not specific to a customer.LDP is run over the RSVP-te tunnels between the core. Thus the tunnels carry traffic of all customers but allow to monitor the remaining bandwidth. From the core to the pops there is just LDP running. Since the SP doesnot have a bandwidth crunch within the core, this is possible. So you end up ensuring the given bandwidth to all the 4 sites.