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.