PVC bandwidth issue

Unanswered Question
Jan 10th, 2008

Hello

I have several remote sites with frame relay connections back to a corporate site through two PVCs at each remote site(one goes directly to the corporate site, one routes through another secondary corporate site). I'm running QOS which is locking each PVC down to 256k mincir. I'd like to route our VOIP traffic over one PVC and data traffic over the other, however, I'd like the data PVC to burst above mincir. Is there a way to configure the PVC bandwidth separately? The current configuration locks both PVCs down to 256K. I tried cheating by configuring 512K mincir, but that resulted in occasional issues with choppy voice so I need to restrict this to actual cir, which is 256K. However, that really slows down one of our apps that needs to talk to a database at our corporate site. I'd like to configure a route map to push VOIP over S0.16 and data over S0.17 and let S0.17 burst above 256K.

Configuration on the remote router is as follows:

version 12.3

service timestamps debug datetime localtime

service timestamps log datetime localtime

service password-encryption

!

hostname

!

logging buffered 4096 debugging

enable secret

enable password

!

memory-size iomem 25

clock timezone mst -7

ip subnet-zero

!

!

no ip domain lookup

!

!

!

!

class-map match-all voice-traffic

match access-group 150

!

!

policy-map voice-policy

class voice-traffic

priority 192

class class-default

fair-queue

!

!

!

interface FastEthernet0

ip address 172.20.129.254 255.255.255.0

speed auto

!

interface Serial0

description

no ip address

encapsulation frame-relay

no fair-queue

frame-relay class voice

frame-relay traffic-shaping

frame-relay ip rtp header-compression

!

interface Serial0.16 point-to-point

description

bandwidth 256

ip address 172.20.254.30 255.255.255.252

frame-relay interface-dlci 16

!

interface Serial0.17 point-to-point

description

bandwidth 256

ip address 172.20.253.30 255.255.255.252

frame-relay interface-dlci 17

!

router eigrp 100

variance 2

redistribute connected

network 172.20.253.28 0.0.0.3

network 172.20.254.28 0.0.0.3

distribute-list 10 in

no auto-summary

eigrp stub connected summary

no eigrp log-neighbor-changes

!

ip classless

no ip http server

!

!

map-class frame-relay voice

frame-relay cir 256000

frame-relay bc 2560

frame-relay be 0

frame-relay mincir 256000

service-policy output voice-policy

no logging trap

access-list 10 deny 172.20.0.0 0.0.255.255

access-list 10 permit any

access-list 150 permit udp any 10.1.4.0 0.0.3.255

!

line con 0

exec-timeout 0 0

password

login

line aux 0

line vty 0 4

password

login

!

no scheduler allocate

sntp server 172.20.254.29

!

end

Thanks for any help.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Kevin Dorrell Thu, 01/10/2008 - 08:34

If you put the frame-relay class on the sub-interfaces rather than the physical interface, then they will apply to the individual DLCIs. You can then have a different class on each subinterface.

In fact, I'm not sure your class mapping is working at all. I thought that putting it on the physical interface would apply it only to those DLCIs that are coming through the physical interface.

If I am wrong on that last point, someone please put me right?

Kevin Dorrell

Luxembourg

In order to confirm that applying this to the physical interface is working you would need to really have specific traffic monitoring of the innterface and DLCI's to get some indication of what the PVC's were doing.

A sample would be as below, with a different map-class meeting the requirements per PVC.

!

interface Serial0.16 point-to-point

ip address 10.21.110.18 255.255.255.252

ip accounting output-packets

bandwidth 64

frame-relay interface-dlci 16

class PQ256_128K

!

!

map-class frame-relay PQ256_128K

frame-relay cir 256000

frame-relay bc 32000

frame-relay mincir 128000

frame-relay priority-group 1

bsternfield Fri, 01/11/2008 - 20:21

The class map is definitely working--I can detect the speed difference with the map applied and removed. I'll try applying the map to the individual DLCIs. If I do that, I assume I can omit the frame-relay traffic-shaping and ip rtp header compression statements on the physical interface?

Actions

This Discussion