Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Frame relay QoS on separate voice and data PVCs

How does one configure VoIPoverFR QOS on a circuit with a separate voice and data PVC? I can't find any documents on that specifically. Everything I can find is geared toward a single PVC running both voice and data. I have a voice PVC 128k and a data PVC 128k. How do you make sure the voice packets go over the voice PVC and not the data PVC? I read one doc (on the CCO) that mentioned that they should be configured the same. Is that true if you want voice to go over one and data the other? Any help would be appreciated.

6 REPLIES
Blue

Re: Frame relay QoS on separate voice and data PVCs

The preferred method is to use route filters. Advertise only voice subnets over the voice link, and only advertise data subnets over the data link. This will be simpler if you have designed your network with easily summarized voice subnets. As an example, all your voice subnets might be covered by a 10.55.X.X range. You would then need 2 standard access lists, one that denies 10.55.0.0. 0.0.255.255 and permits any, and one that permits the 10.55 and denies any. You would then apply the access lists as distribution filters for your routing protocol on the subinterfaces outbound. This would be done on both routers.

Have Fun!

Dave

Re: Frame relay QoS on separate voice and data PVCs

That sounds good. What about the map class statement for QoS? Does that get applied only to the voice PVC, or both PVCs as I had read? And what about the frame-relay traffic-shaping, applied to both interfaces? Below is the statement I'm using.

map-class frame-relay VoIP-128k

no frame-relay adaptive-shaping

frame-relay cir 128000

frame-relay bc 1280

frame-relay be 0

frame-relay mincir 128000

service-policy output QoS-128k

frame-relay fragment 160

access-list 100 permit ip any any precedence critical

access-list 101 permit ip any any precedence flash

Blue

Re: Frame relay QoS on separate voice and data PVCs

You will need a map class for each PVC, but they will not be the same. The voice packets need to be priority queued.

Here is a very good document with examples that should get you going:

http://www.cisco.com/warp/customer/788/voice-qos/voip-ov-fr-qos.html

New Member

Re: Frame relay QoS on separate voice and data PVCs

I understand the design issues you explained above. Maybe you can help with one more point. With separate voice and data PVC's, each running at 128K CIR, fragmentation must be enabled on both PVC's. However, I have had problems in the past with applications that turn on the "do not fragment" bit. Then if fragmentation is attempted, the applications have problems. How can this be addressed? Thanks.

Silver

Re: Frame relay QoS on separate voice and data PVCs

There are some alternatives to using filtering of the routing updates.

Configure a loopback on both router, and use the h323-gateway voip bind srcaddr command to force the router to use the loopback address as the sourceof the VOIP signalling and RTP. Then use static routes to point to the remote loopback using the next hop IP address of the remote voice PVC. This way the voice traffic only travels via the voice PVC, and if the IP addresses of the loopbacks and voice PVC subinterfaces are kept out of the data subnets, the data traffic won't be routed via the voice PVC.

for example -

router 1

interface loopback 0

ip address 100.1.1.1 255.255.255.0

h323-gateway voip bind srcaddr 100.1.1.1

....

interface serial 0/0.1

ip address 100.1.10.1 255.255.255.0

frame-relay interface-dlci 16

class VOIP

....

ip route 100.1.2.0 255.255.255.0 100.1.10.2

router 2

interface loopback 0

ip address 100.1.2.1 255.255.255.0

h323-gateway voip bind srcaddr 100.1.2.1

....

interface serial 0/0.1

ip address 100.1.10.2 255.255.255.0

frame-relay interface-dlci 16

class VOIP

....

ip route 100.1.1.0 255.255.255.0 100.1.10.1

Enabling FRF12 fragmentation is transparent to the upper layer protocols such as IP. the packet goes to the frame relay engine, is fragmented, has the headers wrapped around the fragment and then these fragments are queued. At the receiving side the fragments are received, glued back together to make the full packet and then sent to the destination interface. The FRF12 fragmentation should be of no conesequence to any applications that set the DF bitof the IP packet header.

New Member

Re: Frame relay QoS on separate voice and data PVCs

as far as i understand you have 256Kb/s access rate (physical interface speed) and CIR=128Kb/s for data and CIR=128Kbit/s for voice. if so, then try this config:

interface Serial0/0

bandwidth 256

encapsulation frame-relay

frame-relay traffic-shaping

frame-relay interface-queue priority

!

interface Serial0/0.1 point-to-point

description voice_pvc

bandwidth 128

ip address x.x.x.x

no cdp enable

frame-relay interface-dlci 100

class voice

frame-relay ip rtp header-compression

!

interface Serial0/0.2 point-to-point

description data_pvc

bandwidth 128

ip address x.x.x.x

frame-relay interface-dlci 200

class data

map-class frame-relay voice

no frame-relay adaptive-shaping becn

frame-relay cir 128000

frame-relay bc 1280

frame-relay be 0

frame-relay mincir 128000

frame-relay interface-queue priority high

!

map-class frame-relay data

no frame-relay adaptive-shaping becn

frame-relay cir 128000

frame-relay bc 1280

frame-relay be 0

frame-relay mincir 128000

frame-relay interface-queue priority normal

frame-relay fragment 320

123
Views
0
Helpful
6
Replies
CreatePlease to create content