[c-nsp] FR QOS

[Oliver Boehmer (oboehmer)]

> Oliver,
>   I believe in your example explained below, both PVCs over the
> provider network should be configured to be able to peak to the full
> line speed. If PVCs were limited at the provider network each to a
> specific bandwidth, this QoS approah won't work.   
> 
> Do you agree with me here ?

Yes. This configuration assumes that both PVCs are able to burst to the
full physical speed.

	oli

> 
> "Oliver Boehmer (oboehmer)" <oboehmer@ .com> wrote:
> 
> 
> 	> I have some queries
> 	>
> 	> policy-map Out-s4/1/0
> 	> class dlci-401
> 	> bandwidth percent 50
> 	> service-policy customer-1
> 	> class dlci-402
> 	> bandwidth percent 25
> 	> service-policy customer-2
> 	>
> 	>
> 	> In the above statements, you are hardcoding a bandwidth
percent
> 	value > under of the class Like "dlci-401" and "dlci-402" .
After
> 	you define > this , does the Router allow us to share bandwidth
> between VPNs. 
> 
> 	Sure, this is the reason why you need to apply the policy at the
> 	physical interface. If VPN-1 doesn't use "his" bandwidth, VPN-2
can
> 	use it.
> 
> 	oli
> 
> 	>
> 	> -----Original Message-----
> 	> From: Oliver Boehmer (oboehmer) [mailto:oboehmer at cisco.com]
> 	> Sent: Saturday, March 05, 2005 2:51 PM
> 	> To: Akella Vardhana Srikant; cisco-nsp at puck.nether.net
> 	> Subject: RE: [c-nsp] FR QOS
> 	>
> 	>
> 	>> I need some help with respect to the FR QOS. In our scenario,
we
> 	have >> 2 PVC's configured under single E1 Link and PVC belongs
to
> 	respective >> customer. The respective PVC has again 4 different
> 	types of traffic >> such as Voice, FTP, etc.
> 	>>
> 	>> The Demand is that Total E1 BW should be utilized among to
the 2
> 	>> VPN's and again among the respective classes of traffic such
as
> 	>> Voice, FTP, etc. The QOS config should be defined in such a
way
> 	that >> in case PVC-1 is down then PVC-2 should utilize all the
E1
> 	BW and >> then sub divide among all the 4 classes.
> 	>>
> 	>> Similarly it should be other way round also.
> 	>>
> 	>> Can some body tell me what sort of QOS config has to deployed
for
> 	>> achieving this ?
> 	>
> 	> You need some form of hierarchical CBWFQ using the "match
fr-dlci"
> 	> class-map classification in the parent and your
customer-specific
> 	> classes at the child. you would then apply the policy-map at
the
> 	> physical FR interface, not at the customer-specific
sub-interfaces.
> 	> Please note that some platforms (for example 3600) require you
to
> 	> shape
> 	> at the parent.
> 	>
> 	> Here's an example:
> 	>
> 	> class-map match-all platin
> 	> match ip precedence 5
> 	> class-map match-all gold
> 	> match ip precedence 3
> 	> class-map match-all silber
> 	> match ip precedence 2
> 	> !
> 	> class-map match-all dlci-402
> 	> match fr-dlci 402
> 	> class-map match-all dlci-401
> 	> match fr-dlci 401
> 	> !
> 	> !
> 	> policy-map customer-1
> 	> class platin
> 	> priority 64
> 	> class gold
> 	> bandwidth 64
> 	> class silber
> 	> bandwidth 64
> 	> class class-default
> 	> random-detect
> 	> bandwidth 64
> 	> !
> 	> policy-map customer-2
> 	> ....
> 	> !
> 	> policy-map Out-s4/1/0
> 	> class dlci-401
> 	> bandwidth percent 50
> 	> service-policy customer-1
> 	> class dlci-402
> 	> bandwidth percent 25
> 	> service-policy customer-2
> 	> !
> 	> interface Serial4/1/0
> 	> bandwidth 512000
> 	> no ip address
> 	> no ip directed-broadcast
> 	> encapsulation frame-relay
> 	> load-interval 30
> 	> frame-relay intf-type dce
> 	> service-policy output Out-s4/1/0
> 	> !
> 	> int Serial4/1/0.1
> 	> ip address ...
> 	> frame-relay interface-dlci 401
> 	> int Serial4/1/0.2
> 	> ip address ...
> 	> frame-relay interface-dlci 402
> 	>
> 	> oli
> 
> 	_______________________________________________
> 	cisco-nsp mailing list cisco-nsp at puck.nether.net
> 	https://puck.nether.net/mailman/listinfo/cisco-nsp
> 	archive at http://puck.nether.net/pipermail/cisco-nsp/