If you want to implement any fancy queueing, this only works if there is some congestion or backpressure. For Frame Relay PVCs as they are virtual links, the backpressure can only be created via traffic shaping. Hence you need to use shaping on the data pvc.
Looking at your config, you already have a map-class for voice, so would suggest you create another one for data, apply the service policy there and enable traffic shaping on the main interface
The disadvantage of shaping is that it will actually limit you bandwidth. That is, you won't be able to use the circuit at full capacity, because of the artificial limitation induced by shaping. This is particularly true for a situation like you where the actual circuits is a leased line, and not a FR network.
A better approach would be to reconfigure for simple hdlc encap, and run VoIP instead. This way, you would have all the QOS features you need for voice and data, and be able to use the full capacity with a much simpler configuration.
Actually, even if you want to retain the FR encapsulation and the voice over FR approach, still using a single PVC would be better, for the same reasons given above.
Introduction: The "external-out enable" command is available for
configuration under the "router ospf process" in case of the IOS-XR
operating system. This command basically enables advertisement of
intra-area routes on the device as external routes in th...
IntroductionIn this article we'll discuss how to troubleshoot packet
loss in the asr9000 and specifically understanding the NP drop counters,
what they mean and what you can do to mitigate them. This document will
be an ongoing effort to improve troublesh...