mtu=300 for Vo/IP QOS, but Internet slow from branch office.

[wdawes]

From recommendations for Vo/IP QOS, the mtu=300 was used on a 3640 router serial interface at HQ, and also at the branch office 1751v router. HQ provides Internet access for the branch office, the branch office has a frame-relay conenction back to HQ. Both routers have a Vo/IP/Frame configuration, and voice calls are working fine. However, now when the branch office tries to access some web servers on the Internet, it is very slow, and some sites timeout when being connected to. We are seeing the "need to fragment (mtu 300)" message at the 3640 router (verified through TCPCUMP utility on the customer's Check Point firewall.)

So, we are thinking that the small MTU is not compatible with the ISP's access router (a 2600 at HQ.)

Is it possible to set the router configs so that the MTU=300 is only used for Vo/IP packets?

Alternatively, couldn't we just remove the MTU=300, so that there is a larger window? If so, will the Vo/IP QOS suffer much?

For brevity, here is part of the 3640 config:

voice rtp send-recv

!

interface Serial0/0

description frame-relay for HQ to: San Fran.,CA;

mtu 300

bandwidth 768

no ip address

encapsulation frame-relay

service-module t1 timeslots 1-12

frame-relay traffic-shaping

frame-relay lmi-type cisco

frame-relay ip rtp header-compression

!

interface Serial0/0.1 point-to-point

description PVC to San Fran; DLCI=120

ip address 10.1.252.1 255.255.255.252

frame-relay interface-dlci 120

class VoIPovFr192

!

map-class frame-relay VoIPovFr192

no frame-relay adaptive-shaping

frame-relay cir 192000

frame-relay bc 1920

frame-relay fair-queue

frame-relay fragment 240

frame-relay ip rtp priority 16384 16383 48

!

dial-peer voice 4010 voip

destination-pattern 2100

session target ipv4:10.1.252.2

dtmf-relay h245-alphanumeric

ip qos dscp cs5 media

!

and, here is part of the 1751v config:

voice rtp send-recv

!

interface Serial0/0

description frame-relay for San Fran, CA to HQ

mtu 300

bandwidth 384

no ip address

encapsulation frame-relay

service-module t1 timeslots 1-6

frame-relay traffic-shaping

frame-relay lmi-type cisco

frame-relay ip rtp header-compression

!

interface Serial0/0.1 point-to-point

description PVC to HQ

ip address 10.1.252.2 255.255.255.252

frame-relay interface-dlci 100

class VoIPovFr192

!

map-class frame-relay VoIPovFr192

frame-relay cir 192000

frame-relay bc 1920

no frame-relay adaptive-shaping

frame-relay fair-queue

frame-relay fragment 240

frame-relay ip rtp priority 16384 16383 48

!

dial-peer voice 2100 voip

destination-pattern 4010

session target ipv4:10.1.252.1

dtmf-relay h245-alphanumeric

ip qos dscp cs5 media

!

[asparrowhawk]

The idea is to stop large data frames getting in the way of voice frames and causing variable delays between voice frames (jitter). The "frame-relay fragment 240" statement in your frame relay map class acheives this, so restricting the MTU is redundant - large frames may be getting chopped to 300 bytes because of the MTU, then each fragment further chopped to 240 and 60 bytes at the DLCI. Try opening out the MTU to standard and retesting, there will be some degradation in performance caused by fragmentation but it shouldn't be too severe.

[bharath.mallik]

hi

Make this MTU has 1500 then check the speed of internet as well as voice quality it will be fine.

[pacameron]

Get rid of the MTU setting on the main serial interface - you have already configured FRF12 under the subinterface. The FRF12 will transparently fragment the traffic at layer 2 - you don't need both.

Many upper layer protocol servers such as HTTP and FTP will often set the DF (Don't Fragment) bit of the IP header to make transfers as efficient as possible, so if the packet gets to a interface where the MTU has been reduced it will often be dropped, hence the application either stops or slows right down.

[f.huynh]

I have an E1 link that run on frame-relay, with 2 heavy data pvc and 1 voice pvc. I also implemented pvc priority with queue depth (high, med, normal, low) 10 30 100 200. Voice pvc is set to high, while the 2 data pvc is set to med and low. Is this the probably way to do qos for this scenario. FRF12 is also configured base on the lowest cir, 128k.