[c-nsp] LLQ/QoS over Frame Relay? - advice sought

David Freedman david.freedman at uk.clara.net
Mon May 16 16:07:23 EDT 2005


Hiya,

I'm wanting to implement LLQ  over a Frame Relay bundle.

I was reading an earlier thread with a similar theme some months ago
(https://puck.nether.net/pipermail/cisco-nsp/2005-March/thread.html#17919)

but I'm not sure of how to proceed in my environment.




Basically, I've a setup like such:


I've an clear E1 (2MB) over a TDM network linking two routers , over 
which I'm running frame-relay encapsulation (to provide a VPN application)


The Frame bundle looks like such:


  FRAME BUNDLE
---------------

    ------> PVC w/DLCI 100 for Management

    ------> PVC w/DLCI 150 for Customer Internet Traffic

    ------> PVC w/DLCI 200+ for Customer VPN(s)



There is no Frame-Relay switching equipment inbetween the routers, just 
a clear-cut E1 channel.

None of the PVCs are constrained in any way initially.



I'd like to be able to provide the following:


1. Management PVC gets 64Kbps all the time

2. Data PVC performs LLQ with 1 Priority Class, 2 Weighted Classes and a 
fair-queued default class.

3. Internet PVC scavenges the remaining bandwidth fairly.




 From reading various material , I understand that this can be provided
in one of two ways. Either :


A. Hierarchical model


So something like:

class-map match-all GOLD
  match ip precedence 5
class-map match-all SILVER
  match ip precedence 4
class-map match-all BRONZE
  match ip precedence 3
!
class-map match-all MGMT-PVC
  match fr-dlci 100
class-map match-all INET-PVC
  match fr-dlci 150
class-map match-all DATA-PVC
  match fr-dlci 200
!
policy-map BUNDLE
  class MGMT-PVC
   bandwidth 64
  class DATA-PVC
   service-policy LLQ
  class INET-PVC
   random-detect
   fair queue
!

policy-map LLQ
  class GOLD
   priority <x>
  class SILVER
   bandwidth <y>
  class BRONZE
   bandwidth <z>
  class class-default
   random-detect
   fair-queue
!

!
interface SerialX/Y
service-policy output BUNDLE
!

I understand this may require shaping to work, I wouldn't really want to 
shape the PVCs as they should be dynamically resizable.
Allthough I can see the benefit in sizing the MGMT-PVC to 64k,
I want the Internet PVC to be as big as possible when the data PVC is
not doing anything



B. Mixed Model

Which was the other suggestion, that both the dlci and the service-class
were matched at the same time, like such:


!
class-map match-all MGMT
  match fr-dlci 100
class-map match-all GOLD
  match fr-dlci 200
  match ip precedence 5
class-map match-all SILVER
  match fr-dlci 200
  match ip precedence 4
class-map match-all BRONZE
  match fr-dlci 200
  match ip precedence 3
!
policy-map LLQ
  class GOLD
   priority <x>
  class MGMT
   bandwidth 64
  class SILVER
   bandwidth <a>
  class BRONZE
   bandwidth <b>
  class class-default
   fair-queue
   random-detect

!
interface SerialX/Y
service-policy output LLQ
!



I quite like (B) as it appears to do the same job in a simpler fashion.


I also understand that since the link is not *really* low-bandwidth,
I don't have to bother with FRF.12.



I'm about to lab both of these now, but I was wondering if either method 
would be preferred in this scenario, and are there any potential 
pitfalls to worry about.


As usual, thanks for any input.


Dave.












More information about the cisco-nsp mailing list