Frame Relay Traffic Shaping to Frame Realy MPLS

[lffrwatson]

I have a customer who had a frame relay circuit that we were doing frame relay traffic shaping on. The voice quality between the two sites worked fine. They currently switched to a frame-relay mpls system offered by Bellsouth.

The voice quality is very bad now because of this. Can anyone see anything wrong with the config?

class-map match-all VoIP-Ingress

match access-group 100

!

!

class-map match-all VoIP-Egress

match ip dscp ef

policy-map QoS-Egress-WAN

class VoIP-Egress

priority percent 50

police cir percent 50

conform-action transmit

exceed-action transmit

class class-default

police cir percent 50

conform-action transmit

exceed-action transmit

!

policy-map QoS-Ingress-LAN

class VoIP-Ingress

set ip dscp ef

class class-default

set ip dscp 0

!

!

!

interface FastEthernet0/0

ip address x.x.x.x 255.255.255.192

service-policy input QoS-Ingress-LAN

speed 100

full-duplex

!

interface Serial0/0

no ip address

encapsulation frame-relay IETF

service-module t1 timeslots 1-8

frame-relay lmi-type ansi

max-reserved-bandwidth 100

service-policy output QoS-Egress-WAN

!

interface Serial0/0.1 point-to-point

ip address x.x.x.x 255.255.255.252

frame-relay interface-dlci xxx

!

interface FastEthernet0/1

ip address x.x.x.x 255.255.255.0

service-policy input QoS-Ingress-LAN

duplex auto

speed auto

!

!

!

[mheusinger]

Hi,

I would change some things:

class-map match-all VoIP-Ingress

match access-group 100

!

!

class-map match-all VoIP-Egress

match ip dscp ef

policy-map QoS-Egress-WAN

class VoIP-Egress

priority percent 50

class class-default

fair-queue

!

policy-map QoS-Ingress-LAN

class VoIP-Ingress

set ip dscp ef

class class-default

set ip dscp 0

!

!

!

interface FastEthernet0/0

ip address x.x.x.x 255.255.255.192

service-policy input QoS-Ingress-LAN

speed 100

full-duplex

!

interface Serial0/0

no ip address

encapsulation frame-relay IETF

service-module t1 timeslots 1-8

frame-relay lmi-type ansi

frame-relay traffic-shaping

max-reserved-bandwidth 100

!

interface Serial0/0.1 point-to-point

bandwidth 512

max-reserved-bandwidth 100

ip address x.x.x.x 255.255.255.252

frame-relay interface-dlci xxx

class FR

!

interface FastEthernet0/1

ip address x.x.x.x 255.255.255.0

service-policy input QoS-Ingress-LAN

duplex auto

speed auto

!

map-class frame-relay FR

frame-relay cir 512000

frame-relay fragment 900

service-policy output QoS-Egress-WAN

!

!

The output policy-map should be applied to the IP interface. Check with "show policy-map interface", if you have any matches in the voip class - before and after the changes. Also do not police voip, which could lead to unwanted drops even if the bandwidth is not used for other traffic.

I also applied LFI to reduce the jitter (fragement size 900).

I am assuming your ACL 100 grabs the voip traffic ...

Finally, make sure the SP also applies QoS to his end of the FR PVC and throughout the MPLS cloud.

Hope this helps!

Regards, Martin

[tony.parker]

Not sure about this.

I am not able to apply the 'class' command under the DLCI once I have put 'frame-relay traffic-shaping' in the main interface.

I think the map class would need to be applied to the sub-interface using 'frame-relay class FR'

[mohammedmahmoud]

Hi,

I just want to add to Martin's fabulous explaination, that i've been to a case where when applying the policy-map under the map-class frame-relay it didn't work, and then when applying it under the serial subinterface it worked fine, and i thought that it is an IOS bug.

HTH,

Mohammed Mahmoud.

[tony.parker]

HELP!

Can anyone explain this please?

Thanks for your reply Mohammed. I thought I was going crazy.