2 FR PVCs & Shared QOS Policy

[z08mjk2374]

Background Info:

I have a customer who has a pair of 3825s with DS-3 cards. They have remote sites with 4 pvcs per site. Two of the PVCs are running in one VRF and the other two are running to the other VRF. OSPF is configured so that one pvc from each VRF is running as a backup PVC with a high OSPF cost.

Under normal conditions, one of the 3825s is routing for both vrfs and the other 3825 is there as a backup.

All of the PVCs can burst to a t-1 line speed  so FRTS isn't required. I should never see DE packets under this setup.

One vrf/pvc carries voice and one vrf/pvc carries data on each 3825 for each site.

Question:

I need to make sure that the pair of DLCIs per site on each 3825 router operate as one from a QOS point of view. In other words, the data PVC needs to be aware of the voice PVC. The voice PVC will be a typical LLQ setup.

I can't have the data PVC consume all of the bandwidth on the t-1 at the remote end.

I know I can police the data side down to make the bandwidth available, but I would prefer to have all of the bandwidth until voice traffic is going over the link.

Is it possible to do this?

[Joseph W. Doherty · Accepted solution]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

It might be possible to shape for all the PVCs passing through the main egress interface.  In fact, I vaguely recall some kind of dual shaping or QoS for the situation where need to manage congestion both for the physical interface and for PVCs, and I think it was for frame-relay.  Not sure, though.

BTW, from what you've described, if have multiple PVCs sharing a physical interface, and aggregate bandwidth of the other side of the PVCs physical interface(s) exceeds the receiver's physical interface, to manage bandwidth, you need to shape.

[z08mjk2374]

The shaping part makes sense. The DS-3 will crush the t-1s without it.

[Joseph W. Doherty]

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

z08mjk2374 wrote:
The shaping part makes sense. The DS-3 will crush the t-1s without it.

Exactly!

If you have multiple senders that can send to the same destination, you can have a similar issue.  For example, if hub side has T1 and spoke side has T1, no need to shape.  If there are two hub routers, each with a T1 and PVC to the spoke, then you can overwhelm the spoke's T1.  In this case, you could shape each hub so that their aggregate doesn't exceed the spoke's T1, or set route cost so there's a primary path and a secondary path, i.e. only one hub will send to the spoke.  If the two hubs each have T3s, then best option is to shape traffic to the spoke for the spoke's T1 and also use the primary and secondary costed path approach.

Instead of having multiple PVCs between the same source and destination, like your voice and data PVCs, you can have just one PVC and use QoS to give priority to the voice.  This works well if your frame-relay PVC are in, for example, USA.  You'll see your frame with DE markings as they might exceed CIR, but unlikely to see FECN/BECNs or have frames actually delayed or dropped.  Elsewhere in the world, where underlying frame-relay bandwidth is not so plentiful, and CIR is significant, you might need individual traffic type PVCs to obtain your guaranteed CIR, especially for voice, and then we have the PVC bandwidth sharing issue that's part of your original posting.

The latter situation is where we ideally need two levels of shaping.  On a hub's T3 you want to shape all traffic to the same spoke T1 at T1 bandwidth while giving priority to voice traffic, as you would in a shared PVC, but now across PVCs.  You also want to shape the voice PVC for the CIR, to obtain the guaranteed bandwidth you're seeking for voice.  You could let the data PVC bandwidth be controlled by the overall shaper, ideally it could use all the physical spoke T1's bandwidth not being used by actual voice traffic.

PS:

I also vaguely recall, when sharing a frame-relay PVC, some feature where you can also explicitly tag some traffic with DE.  This assumes traffic such as voice frames could be protected by never having DE on their frames, only non-voice frames, when aggregate exceeds CIR, would be marked (by this feature) with DE.

Sorry for being so vague on some of these frame-relay features, its been years since I've used frame-relay circuits.